From BillD at cait.wustl.edu Tue Oct 2 17:10:37 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Tue, 2 Oct 2007 16:10:37 -0500 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested Message-ID: Hello, As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would like to ask the community to once again consider this proposal in advance of the Albuquerque Public Policy and Membership Meetings (http://www.arin.net/ARIN-XX/index.html) and voice support or non-support for this proposal with concise reasoning. More information about this proposal and other active proposals can be found at http://www.arin.net/policy/proposals/proposal_archive.html Such an effort will refresh this discussion and perhaps air more recently conceived viewpoints. It will also aid the Advisory Council in their efforts to assess industry consensus about this proposal. Thank you for your interest and involvement in the ARIN Internet Resource Policy Evaluation Process (IRPEP). More information about IRPEP can be found at http://www.arin.net/policy/irpep.html Bill Darte ARIN Advisory Council -------------- next part -------------- An HTML attachment was scrubbed... URL: From sleibrand at internap.com Tue Oct 2 17:48:53 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 02 Oct 2007 14:48:53 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: References: Message-ID: <4702BCC5.2040201@internap.com> As mentioned before, I support the IPv4 Soft Landing proposal. I think it strikes a good balance, not significantly impairing networks' ability to obtain IPv4 space, but at the same time encouraging/requiring adoption of IPv6 where appropriate, thereby reducing demand for remaining IPv4 space. -Scott Bill Darte wrote: > > Hello, > > > > As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would > like to ask the community to once again consider this proposal in > advance of the Albuquerque Public Policy and Membership Meetings > (http://www.arin.net/ARIN-XX/index.html) and voice support or > non-support for this proposal with concise reasoning. More information > about this proposal and other active proposals can be found at > http://www.arin.net/policy/proposals/proposal_archive.html > > > > Such an effort will refresh this discussion and perhaps air more > recently conceived viewpoints. It will also aid the Advisory Council > in their efforts to assess industry consensus about this proposal. > > > > Thank you for your interest and involvement in the ARIN Internet > Resource Policy Evaluation Process (IRPEP). More information about > IRPEP can be found at http://www.arin.net/policy/irpep.html > > > > > > Bill Darte > > ARIN Advisory Council > > > > ------------------------------------------------------------------------ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From Keith at jcc.com Tue Oct 2 17:56:17 2007 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 2 Oct 2007 17:56:17 -0400 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested Message-ID: <9efbc034c6fca5a1fa2d0d4e496a5cee4702be8a@jcc.com> Bill, I don't know for sure what it means to demonstrate efficient utilization of 100% of an IP allocation. For the definitions I can think of, I'm sceptical that is possible to honestly demonstrate efficient utilization of 100% of an IP allocation. If this can be turned into something that doesn't require applicants to lie, I don't object to it. Keith _____ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Bill Darte Sent: Tuesday, October 02, 2007 5:11 PM To: ppml at arin.net Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested Hello, As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would like to ask the community to once again consider this proposal in advance of the Albuquerque Public Policy and Membership Meetings (http://www.arin.net/ARIN-XX/index.html) and voice support or non-support for this proposal with concise reasoning. More information about this proposal and other active proposals can be found at http://www.arin.net/policy/proposals/proposal_archive.html Such an effort will refresh this discussion and perhaps air more recently conceived viewpoints. It will also aid the Advisory Council in their efforts to assess industry consensus about this proposal. Thank you for your interest and involvement in the ARIN Internet Resource Policy Evaluation Process (IRPEP). More information about IRPEP can be found at http://www.arin.net/policy/irpep.html Bill Darte ARIN Advisory Council -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Tue Oct 2 18:08:23 2007 From: dlw+arin at tellme.com (David Williamson) Date: Tue, 2 Oct 2007 15:08:23 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: <4702BCC5.2040201@internap.com> References: <4702BCC5.2040201@internap.com> Message-ID: <20071002220823.GF23649@shell01.cell.sv2.tellme.com> I think the IPv4 Soft Landing proposal is the least objectionable of the array of similar proposals. That said, I'm still on the fence in terms of support. I'm not yet convinced that there's a need to "ease" the transition. My crystal ball is very fuzzy on that topic - current policy isn't horribly broken for IPv4. Once it runs out, it runs out. Does it matter if that happens slower as a result of policy changes? We need to get onto IPv6 sooner, rather than later, but I'm not sure how related that is to IPv4 runout. It's clear that running out will trigger much more interest in v6. I'm more inclined to push for more education about how to use v6 and the impending doom for v4, and let the community do the right thing from there. Again, that doesn't involve policy changes. To answer Bill's original question, I think I don't support any of these proposals at this time, but I'm not yet firm on that decision. If someone convinces me that we do need to change policy, I think I would support this proposal over the other similar ones. -David On Tue, Oct 02, 2007 at 02:48:53PM -0700, Scott Leibrand wrote: > As mentioned before, I support the IPv4 Soft Landing proposal. I think > it strikes a good balance, not significantly impairing networks' ability > to obtain IPv4 space, but at the same time encouraging/requiring > adoption of IPv6 where appropriate, thereby reducing demand for > remaining IPv4 space. > > -Scott > > Bill Darte wrote: > > > > Hello, > > > > > > > > As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would > > like to ask the community to once again consider this proposal in > > advance of the Albuquerque Public Policy and Membership Meetings > > (http://www.arin.net/ARIN-XX/index.html) and voice support or > > non-support for this proposal with concise reasoning. More information > > about this proposal and other active proposals can be found at > > http://www.arin.net/policy/proposals/proposal_archive.html > > > > > > > > Such an effort will refresh this discussion and perhaps air more > > recently conceived viewpoints. It will also aid the Advisory Council > > in their efforts to assess industry consensus about this proposal. > > > > > > > > Thank you for your interest and involvement in the ARIN Internet > > Resource Policy Evaluation Process (IRPEP). More information about > > IRPEP can be found at http://www.arin.net/policy/irpep.html > > > > > > > > > > > > Bill Darte > > > > ARIN Advisory Council > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN Public Policy > > Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > > Help Desk at 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From michael.dillon at bt.com Wed Oct 3 05:54:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 3 Oct 2007 10:54:50 +0100 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: References: Message-ID: > As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I > would like to ask the community to once again consider this > proposal in advance of the Albuquerque Public Policy and > Membership Meetings (http://www.arin.net/ARIN-XX/index.html) > and voice support or non-support for this proposal with > concise reasoning. First it is an overly complex proposal made worse by using "cute" terminology like "Phase 0" which is not explained until the very end of the proposal. I am opposed to this policy because it weaves together too many actions. Some of the actions are rather mild such as the survey requirement which I support. Others, are not so mild such as tightening the screws on ISP customers and tightening the screws on ISPs. In addition, the numbers tossed out, e.g. 85%, are meaningless. Things do not necessarily scale linearly and the hierarchical structure of IPv4 sub-allocation makes 100% allocation impossible for anyone to attain. I'd like to see the mild actions separated out from this proposal and dealt with first. Yes we should require everybody to fill in an IPv6 survey and get it signed by a company financial officer before gettinga additional IPv4 addresses. Yes we should require increasingly stringent internal audits of IPv4 utilisation so that we don't give new addresses to companies who have lots of it scattered around in old forgotten corners. Yes, we should require evidence of movement towards IPv6 deployment starting with planning, then test labs in place, then actual IPv6 infrastructure. I would not be opposed to a policy that bundled a bunch of such actions along with a phased deployment plan. --Michael Dillon From tedm at ipinc.net Wed Oct 3 16:45:46 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 3 Oct 2007 13:45:46 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: Message-ID: I am opposed to this policy for the following reasons: 1) No public mechanism is specified for proof of utilization. The requestor is required to prove to ARIN they have efficient utilization. The requestor is not required to publically publish to the world efficient utilization. Under this policy a requestor could make a single SWIP entry for a /23 allocated to Wonklulating Gronkulator corporation, with this corporation not registered in any government entity, not carrying a business license of any kind, no website, and a telephone number that rings the phone in the local public school's janitor's closet. - and that would be perfectly fine. Sure they may be required to demonstrate to ARIN efficient utilization of the /23 - maybe they tell ARIN that Wonkulating is a cover alias for the CIA or some such - but I don't care for this cloak and dagger stuff. The existing SWIP/RWHOIS is adequate to demonstrate efficient utilization and requestors should be required to use this mechanism, and extend it when appropriate. If it cannot be publically proved to most people's satisfaction with entries in SWIP and RWHOIS that a particular block is efficiently utilized - then the requestor hasn't met the requirements, simple as that. 2) No mechanism is specified for continuing proof of 100% utilization. Suppose for example a requestor demonstrates efficient utilization and gets their /16 under these increased requirements. Then 2 years later they go bankrupt and for the next 10 years a bankruptcy court is paying the registration fee for the addresses. The whole point of this proposal is to tighten IPv4 requirements because the author is assuming that the current requirements are loose enough that over the years a lot of "slop" has accumulated in addresseing that is already assigned. In other words it is easier to just request more blocks than vacuum out the corners of your network looking for the usable /25 or so and combining them. I don't know that I agree with this but for the moment lets assume it's a valid supposition. If so, it is then illogical to require requestors to jump through hoops cleaning up their allocations then once more numbers are handed out, they ride off into the sunset and go right back to their slovenly ways. Statements in the policy exist like "demonstrate a one year requirement of 90% utilization" But no mechanism in the policy exists for going back to the requestor a year after they get their /8 and seeing if they actually DID use 90% - and if they didn't, then taking some of that allocation back. Note that I am not opposed to the IDEA of trying to increase the size of the stick and the carrot to convince heavy consumers of IPv4 to "mend their ways" and see the IPv6 light. But this policy is like a roosters mouth - much sound and it has no teeth at all. Give the thing some dentures at least, for crying out loud. Ted -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Bill Darte Sent: Tuesday, October 02, 2007 2:11 PM To: ppml at arin.net Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested Hello, As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would like to ask the community to once again consider this proposal in advance of the Albuquerque Public Policy and Membership Meetings (http://www.arin.net/ARIN-XX/index.html) and voice support or non-support for this proposal with concise reasoning. More information about this proposal and other active proposals can be found at http://www.arin.net/policy/proposals/proposal_archive.html Such an effort will refresh this discussion and perhaps air more recently conceived viewpoints. It will also aid the Advisory Council in their efforts to assess industry consensus about this proposal. Thank you for your interest and involvement in the ARIN Internet Resource Policy Evaluation Process (IRPEP). More information about IRPEP can be found at http://www.arin.net/policy/irpep.html Bill Darte ARIN Advisory Council -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean at av8.com Thu Oct 4 15:39:52 2007 From: dean at av8.com (Dean Anderson) Date: Thu, 4 Oct 2007 15:39:52 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? Message-ID: "Counsel recently made a statement that it doesn't appear that ARIN has any legal obligation to maintain registry services for legacy assignments" Where is this counsel statement? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Wed, 3 Oct 2007 19:00:33 -0500 From: Stephen Sprunk To: John Day Cc: ietf at ietf.org Subject: Re: IPv4 to IPv6 transition Thus spake "John Day" > If IANA had any resolve there are at least 25 -30 Class A blocks > that should be reclaimed and are not or should not be part of the > public Internet address space. AFAIK, IANA does not have any reclamation procedures, nor have any every been assumed to exist. In any event, the legacy assignments were transferred to their respective RIRs during the ERX process, so it's the RIRs' problem now. I don't know what has been going on in the other RIRs, but in ARIN it's been (heatedly) discussed many times what to do with legacy assignments. Counsel recently made a statement that it doesn't appear that ARIN has any legal obligation to maintain registry services for legacy assignments, though it does have a moral one since that was a condition of ARIN's creation. Counsel also stated, however, it is unclear that ARIN could assign those same numbers to someone else later. There's quite a bit of history there, including the possibility that assignments made during the ARPAnet days (particularly to universities and defense contractors) were "Government Furnished Equipment" and thus only the government can take them back. There's a counter-theory that numbers cannot be property at all and ARIN can do whatever it wants. Nobody's really sure, least of all the lawyers who'd inevitably be arguing the issue in court when one (or more likely all) of those /8 holders sued ARIN for trying to reclaim them. It doesn't matter who's right in the end; ARIN would be bankrupted just trying to defend itself against several dozen Fortune 100 companies' legal departments... We're working on policy proposals to address the issue the best we can, though, and if you wish to contribute please subscribe to PPML (and read the archives to get up to speed). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ Ietf mailing list Ietf at ietf.org https://www1.ietf.org/mailman/listinfo/ietf From stephen at sprunk.org Thu Oct 4 16:25:09 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 4 Oct 2007 15:25:09 -0500 Subject: [ppml] Counsel statement on Legacy assignments? References: Message-ID: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> Thus spake "Dean Anderson" > "Counsel recently made a statement that it doesn't appear that > ARIN has any legal obligation to maintain registry services for > legacy assignments" > > Where is this counsel statement? http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 "MR. RYAN: I've thought a little bit about what a stick might look like here. So for example, it's very clear to me that denial of service by ARIN is legally permitted. In other words, I don't believe we, as the non-profit trying to carry out the community's wishes, have a duty to provide free services for legacy address holders. And the denial of those free services to legacy address holders pursuant to their lack of agreement is perfectly permitted, in my judgment, as a matter of law." S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From dean at av8.com Thu Oct 4 18:21:20 2007 From: dean at av8.com (Dean Anderson) Date: Thu, 4 Oct 2007 18:21:20 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> Message-ID: Holy context batman, that is quite a bit different than your statement. You also cut off the part where he says he hasn't thought about it much, and the part where he notes 'the government gave away something without any strings attached'. That is an agreement with the government. So Mr. Ryan appears to have mis-spoken about some lack of agreement between the government and legacy holders. And you left off the part about: "I've thought about whether I could ask the United States Congress for authority to have the government obtain back that which the government gave. I don't know if that's constitutional, actually. I mean, I've started to play with different theories here." So the answer is that the ARIN Lawyer doesn't know. ARIN hasn't offered any definitive opinion as you assert. Please tell the IETF you were wrong. --Dean On Thu, 4 Oct 2007, Stephen Sprunk wrote: > Thus spake "Dean Anderson" > > "Counsel recently made a statement that it doesn't appear that > > ARIN has any legal obligation to maintain registry services for > > legacy assignments" > > > > Where is this counsel statement? > > http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 > > "MR. RYAN: I've thought a little bit about what a stick might look like > here. So for example, it's very clear to me that denial of service by ARIN > is legally permitted. In other words, I don't believe we, as the non-profit > trying to carry out the community's wishes, have a duty to provide free > services for legacy address holders. And the denial of those free services > to legacy address holders pursuant to their lack of agreement is perfectly > permitted, in my judgment, as a matter of law." > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From drc at virtualized.org Thu Oct 4 18:24:41 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 4 Oct 2007 15:24:41 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: <9efbc034c6fca5a1fa2d0d4e496a5cee4702be8a@jcc.com> References: <9efbc034c6fca5a1fa2d0d4e496a5cee4702be8a@jcc.com> Message-ID: Keith, On Oct 2, 2007, at 2:56 PM, Keith W. Hare wrote: > I don't know for sure what it means to demonstrate efficient > utilization of 100% of an IP allocation. For the definitions I can > think of, I'm sceptical that is possible to honestly demonstrate > efficient utilization of 100% of an IP allocation. I was told by ARIN staff that 100% utilization of all previous allocations is an _existing_ requirement. Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: From drc at virtualized.org Thu Oct 4 18:27:40 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 4 Oct 2007 15:27:40 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: <20071002220823.GF23649@shell01.cell.sv2.tellme.com> References: <4702BCC5.2040201@internap.com> <20071002220823.GF23649@shell01.cell.sv2.tellme.com> Message-ID: David, On Oct 2, 2007, at 3:08 PM, David Williamson wrote: > Does it matter if that happens slower as a result of policy changes? The point of a "soft landing" proposal is to extend the runway for transition, but do so in a way as to discourage procrastination. The answer to whether it matters is likely a subject opinion. Clearly I think it does (or I wouldn't have bother to make the proposal), but opinions vary. Regards, -drc From drc at virtualized.org Thu Oct 4 18:31:38 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 4 Oct 2007 15:31:38 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: References: Message-ID: <3758245C-C8EA-4C48-B5C4-A337FB3534D7@virtualized.org> Michael, On Oct 3, 2007, at 2:54 AM, wrote: > First it is an overly complex proposal made worse by using "cute" > terminology like "Phase 0" which is not explained until the very > end of > the proposal. I agree it is complex. I'm not sure how it could be made less complex. > I am opposed to this policy because it weaves together too many > actions. > Some of the actions are rather mild such as the survey requirement > which > I support. Others, are not so mild such as tightening the screws on > ISP > customers and tightening the screws on ISPs. In addition, the numbers > tossed out, e.g. 85%, are meaningless. I will note that the current number is 80%. Is that somehow less meaningless? > Things do not necessarily scale > linearly and the hierarchical structure of IPv4 sub-allocation makes > 100% allocation impossible for anyone to attain. As mentioned in a previous note, ARIN staff have told me explicitly that 100% utilization of previous allocations is an existing requirement. > I'd like to see the mild actions separated out from this proposal and > dealt with first. Yes we should require everybody to fill in an IPv6 > survey and get it signed by a company financial officer before > gettinga > additional IPv4 addresses. Yes we should require increasingly > stringent > internal audits of IPv4 utilisation so that we don't give new > addresses > to companies who have lots of it scattered around in old forgotten > corners. Yes, we should require evidence of movement towards IPv6 > deployment starting with planning, then test labs in place, then > actual > IPv6 infrastructure. I would not be opposed to a policy that bundled a > bunch of such actions along with a phased deployment plan. So what parts do you not agree with? Thanks, -drc From drc at virtualized.org Thu Oct 4 18:34:11 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 4 Oct 2007 15:34:11 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: References: Message-ID: <377DE49C-A352-4B3A-A3C8-AA5CF9FC72BA@virtualized.org> Ted, On Oct 3, 2007, at 1:45 PM, Ted Mittelstaedt wrote: > I am opposed to this policy for the following reasons: > > 1) No public mechanism is specified for proof of utilization. > 2) No mechanism is specified for continuing proof of 100% utilization. No mechanism is specified because I assume ARIN staff will use the same mechanism they use today. Regards, -drc From arin-contact at dirtside.com Thu Oct 4 18:34:28 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 4 Oct 2007 18:34:28 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> Message-ID: <3c3e3fca0710041534k798f75a5n343941555481a4af@mail.gmail.com> On 10/4/07, Dean Anderson wrote: > Holy context batman, that is quite a bit different than your statement. I read all of Ryan's comments at http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 I interpreted them to mean the following: 1. ARIN has no legal standing to revoke or reissue legacy IP address assignments. 2. ARIN has no legal obligation to provide Reverse DNS or WHOIS services for legacy IP address assignments. Besides Dean, is there anyone else who read Ryan's comments and interpreted them to mean something else? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jhg at omsys.com Thu Oct 4 18:46:10 2007 From: jhg at omsys.com (Jeremy H. Griffith) Date: Thu, 04 Oct 2007 15:46:10 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> Message-ID: On Thu, 4 Oct 2007 15:25:09 -0500, "Stephen Sprunk" wrote: >> Where is this counsel statement? > >http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 > >"MR. RYAN: I've thought a little bit about what a stick might look like >here. So for example, it's very clear to me that denial of service by ARIN >is legally permitted. In other words, I don't believe we, as the non-profit >trying to carry out the community's wishes, have a duty to provide free >services for legacy address holders. And the denial of those free services >to legacy address holders pursuant to their lack of agreement is perfectly >permitted, in my judgment, as a matter of law." Perhaps not, but it would put ARIN right in the middle of this ICANN issue: http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=302552 It would certainly ensure continued full employment for attorneys... ;-) --Jeremy From tedm at ipinc.net Thu Oct 4 19:26:27 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 4 Oct 2007 16:26:27 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <3c3e3fca0710041534k798f75a5n343941555481a4af@mail.gmail.com> Message-ID: >>-----Original Message----- >>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>William Herrin >>Sent: Thursday, October 04, 2007 3:34 PM >>To: Dean Anderson >>Cc: ppml at arin.net >>Subject: Re: [ppml] Counsel statement on Legacy assignments? >> >> >>On 10/4/07, Dean Anderson wrote: >> Holy context batman, that is quite a bit different than your statement. >> >>I read all of Ryan's comments at >>http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html# >anchor_13 >I interpreted them to mean the following: So did I >1. ARIN has no legal standing to revoke or reissue legacy IP address >assignments. >2. ARIN has no legal obligation to provide Reverse DNS or WHOIS >services for legacy IP address assignments. >Besides Dean, is there anyone else who read Ryan's comments and >interpreted them to mean something else? Not me! But, as the old SNL sketch ran "The Point is Moot!" The legacy holders are all IPv4 and as we all know IPv4 is going away in the future. This is a self-correcting problem that will disappear if ignored. The only possible gain to removal of whois records would be to free up IPv4 to delay the IPv4 runout date. And what IPv4 requestor would be interested in a IPv4 block that was once owned by a legacy holder who still regards themselves as the rightful owner of that block, and is still advertising it. Ted From tedm at ipinc.net Thu Oct 4 19:29:09 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 4 Oct 2007 16:29:09 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Jeremy H. Griffith >Sent: Thursday, October 04, 2007 3:46 PM >To: ppml at arin.net >Subject: Re: [ppml] Counsel statement on Legacy assignments? > > >On Thu, 4 Oct 2007 15:25:09 -0500, "Stephen Sprunk" > wrote: > >>> Where is this counsel statement? >> >>http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html >#anchor_13 >> >>"MR. RYAN: I've thought a little bit about what a stick might look like >>here. So for example, it's very clear to me that denial of >service by ARIN >>is legally permitted. In other words, I don't believe we, as the >non-profit >>trying to carry out the community's wishes, have a duty to provide free >>services for legacy address holders. And the denial of those free >services >>to legacy address holders pursuant to their lack of agreement is >perfectly >>permitted, in my judgment, as a matter of law." > >Perhaps not, but it would put ARIN right in the middle of >this ICANN issue: > >http://www.computerworld.com/action/article.do?command=viewArticleB >asic&articleId=302552 > What issue? The controversy here concerns whois on domain names, not whois records on IP address block assignments. Ted From tedm at ipinc.net Thu Oct 4 19:55:20 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 4 Oct 2007 16:55:20 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: <377DE49C-A352-4B3A-A3C8-AA5CF9FC72BA@virtualized.org> Message-ID: >-----Original Message----- >From: David Conrad [mailto:drc at virtualized.org] >Sent: Thursday, October 04, 2007 3:34 PM >To: Ted Mittelstaedt >Cc: Public Policy Mailing List >Subject: Re: [ppml] IPv4 Soft Landing - Discussion and >Support/Non-SupportRequested > > >Ted, > >On Oct 3, 2007, at 1:45 PM, Ted Mittelstaedt wrote: >> I am opposed to this policy for the following reasons: >> >> 1) No public mechanism is specified for proof of utilization. >> 2) No mechanism is specified for continuing proof of 100% utilization. > >No mechanism is specified because I assume ARIN staff will use the >same mechanism they use today. > Your ignoring the issue. I will remind you that your in a public forum and if you take shortcuts to respond to criticism of the proposal, it will definitely be voted down as people will rightly conclude that you have not thought things through. This proposal is like the Dutch boy sticking his finger in the dike, and ignoring the real problem which is the water behind the dike is rising because the pumps can't return it back to the sea fast enough. Sure, patching a few holes will reduce the water coming through the dike, but it's not a complete solution. If you really want to keep behind the dike dry, you have to both patch the holes AND beef up the pumps. Your just patching the holes a bit. The "mechanism ARIN uses today" that follows up to be sure that people keep the additional promises of 100% utilization in a year and suchlike, that your proposing, were not designed for your proposal. They were designed for the EXISTING IPv4 justification requirements - which are laxer than yours. They will need to be changed if your proposal were to work. For example, ARIN depends on fees as one of the levers to keep people from requesting a lot of IP numbers then not using them. This works as long as IPv4 is plentiful and not difficult to get. Orgs that request a lot of it then later on find out they don't need so much, have a financial incentive to save money by returning unused IPv4 and thus lowering their yearly fee. The orgs know that since it is plentiful and cheap that if they ever need it again, they can just go back to ARIN and get it again. Your proposal makes IPv4 more difficult to get. Well when you restrict availability of something, you drive up it's value. That's why DeBeers vaults diamonds it pulls out of South Africa. As the monopoly owner of most of the investment grade diamond mines in the world they artificially increase the price of diamonds by restricting their availability. Your proposals drive up the value of IPv4 and thus undercut the financial incentive to return unused IPv4. Now, orgs that get extra IPv4 will look at your proposal and think Gee I better just keep paying the fees on it because if I return it I might not be able to get it back. In order to counteract this side effect, you need increased enforcement of the utilization demands your proposing. This is why when towns and municipalities decrease speed limits on in-town roads that they then increase police presense on those roads. Lowering the speed limit makes the old way of just "trusting drivers to do the right thing" not work anymore. Ted From randy at psg.com Thu Oct 4 20:00:59 2007 From: randy at psg.com (Randy Bush) Date: Fri, 05 Oct 2007 09:00:59 +0900 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> Message-ID: <47057EBB.6010609@psg.com> > "MR. RYAN: I've thought a little bit about what a stick might look like > here. So for example, it's very clear to me that denial of service by ARIN > is legally permitted. In other words, I don't believe we, as the non-profit > trying to carry out the community's wishes, have a duty to provide free > services for legacy address holders. And the denial of those free services > to legacy address holders pursuant to their lack of agreement is perfectly > permitted, in my judgment, as a matter of law." if arin does not want to carry out its commitment to the community and to the USG when it was chartered [0], i am sure the community can find an organization more interested in public service. probably such a change would be good for the community; at least this puff and bluff would cease. randy -- [0] http://rip.psg.com/~randy/970414.fncac.pdf foil 9 From jhg at omsys.com Thu Oct 4 20:14:03 2007 From: jhg at omsys.com (Jeremy H. Griffith) Date: Thu, 04 Oct 2007 17:14:03 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: On Thu, 4 Oct 2007 16:29:09 -0700, "Ted Mittelstaedt" wrote: >>From: Jeremy H. Griffith >>Sent: Thursday, October 04, 2007 3:46 PM >> >>On Thu, 4 Oct 2007 15:25:09 -0500, "Stephen Sprunk" >> wrote: >> >>>> Where is this counsel statement? >>> >>>http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 >>> >>>"MR. RYAN: I've thought a little bit about what a stick might look like >>>here. So for example, it's very clear to me that denial of service by ARIN >>>is legally permitted. In other words, I don't believe we, as the non-profit >>>trying to carry out the community's wishes, have a duty to provide free >>>services for legacy address holders. And the denial of those free services >>>to legacy address holders pursuant to their lack of agreement is perfectly >>>permitted, in my judgment, as a matter of law." >> >>Perhaps not, but it would put ARIN right in the middle of >>this ICANN issue: >> >> >> > >What issue? The controversy here concerns whois on domain names, not >whois records on IP address block assignments. They are related. The primary concern in the domain-name issue is one of accountability. If ARIN dropped the WHOIS services for the address block assignments to legacy users, that accountability is broken. All someone has to do is use a legacy IP number instead of a domain name, and they become effectively untraceable for anyone not in LE or the NSA... ;-) So one result of such a policy would be to raise the value of such addresses on the black market. Not a good idea, IMHO. --Jeremy From tedm at ipinc.net Thu Oct 4 20:38:54 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 4 Oct 2007 17:38:54 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Jeremy H. Griffith >Sent: Thursday, October 04, 2007 5:14 PM >To: ppml at arin.net >Subject: Re: [ppml] Counsel statement on Legacy assignments? > > >On Thu, 4 Oct 2007 16:29:09 -0700, "Ted Mittelstaedt" >wrote: > >>>From: Jeremy H. Griffith >>>Sent: Thursday, October 04, 2007 3:46 PM >>> >>>On Thu, 4 Oct 2007 15:25:09 -0500, "Stephen Sprunk" >>> wrote: >>> >>>>> Where is this counsel statement? >>>> >>>>http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.ht >ml#anchor_13 >>>> >>>>"MR. RYAN: I've thought a little bit about what a stick might look like >>>>here. So for example, it's very clear to me that denial of >service by ARIN >>>>is legally permitted. In other words, I don't believe we, as >the non-profit >>>>trying to carry out the community's wishes, have a duty to provide free >>>>services for legacy address holders. And the denial of those >free services >>>>to legacy address holders pursuant to their lack of agreement >is perfectly >>>>permitted, in my judgment, as a matter of law." >>> >>>Perhaps not, but it would put ARIN right in the middle of >>>this ICANN issue: >>> >>>leBasic&articleId=302552> >>> >> >>What issue? The controversy here concerns whois on domain names, not >>whois records on IP address block assignments. > >They are related. The primary concern in the domain-name issue is >one of accountability. If ARIN dropped the WHOIS services for the >address block assignments to legacy users, that accountability is >broken. All someone has to do is use a legacy IP number instead of >a domain name, and they become effectively untraceable for anyone not >in LE or the NSA... ;-) So one result of such a policy would be to >raise the value of such addresses on the black market. Not a good >idea, IMHO. > A great many networks will not accept advertisements from people who do not have a listing for the blocks they want to advertise in WHOIS. And, any admin of any network who is worried about traffic from black market addresses can simply elect to block out networks that are not visible in WHOIS. So I don't see that it would raise the value of them on the black market. In any case, speaking about the black market, I can assure you that the criminal Pishers can obtain all of the compromised machines that they want. An entire industry exists of people who are paid to break into machines. An IP address by itself isn't much good, it has to have connectivity and CPU time available on a machine with it, in order to become a problem. IMHO withholding WHIS on IPv4 legacy numbering only has value when it is used on a case-by-case basis, to prod a legacy holder into either giving up a block they aren't using, or more efficiently using a block that they have. Ted From jr at jrw.org Fri Oct 5 00:01:31 2007 From: jr at jrw.org (J. R. Westmoreland) Date: Thu, 4 Oct 2007 22:01:31 -0600 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <47057EBB.6010609@psg.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> Message-ID: <001b01c80704$6cf83a90$46e8afb0$@org> Right. If we're really wanting to stir the pot maybe we should say "well, we will charge $100 per class C" so if you have a class B that means 256 * $100 / year for it? And think about those class A's. Then they would really be able to buy a lot of lowyers, right? That would be like financing a MAJOR corporation. J. R. ---------------------------------------- J. R. Westmoreland Email: jr at jrw.org > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Randy Bush > Sent: Thursday, October 04, 2007 6:01 PM > To: Stephen Sprunk > Cc: ppml at arin.net > Subject: Re: [ppml] Counsel statement on Legacy assignments? > > > "MR. RYAN: I've thought a little bit about what a stick might look > like > > here. So for example, it's very clear to me that denial of service by > ARIN > > is legally permitted. In other words, I don't believe we, as the non- > profit > > trying to carry out the community's wishes, have a duty to provide > free > > services for legacy address holders. And the denial of those free > services > > to legacy address holders pursuant to their lack of agreement is > perfectly > > permitted, in my judgment, as a matter of law." > > if arin does not want to carry out its commitment to the community and > to the USG when it was chartered [0], i am sure the community can find > an organization more interested in public service. probably such a > change would be good for the community; at least this puff and bluff > would cease. > > randy > > -- > > [0] http://rip.psg.com/~randy/970414.fncac.pdf foil 9 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From drc at virtualized.org Fri Oct 5 01:09:56 2007 From: drc at virtualized.org (David Conrad) Date: Thu, 4 Oct 2007 22:09:56 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: References: Message-ID: On Oct 4, 2007, at 4:55 PM, Ted Mittelstaedt wrote: >> On Oct 3, 2007, at 1:45 PM, Ted Mittelstaedt wrote: >>> I am opposed to this policy for the following reasons: >>> >>> 1) No public mechanism is specified for proof of utilization. >>> 2) No mechanism is specified for continuing proof of 100% >>> utilization. >> >> No mechanism is specified because I assume ARIN staff will use the >> same mechanism they use today. > > Your ignoring the issue. ? > I will remind you that your in a public forum > and if you take shortcuts to respond to criticism of the proposal, > it will > definitely be voted down as people will rightly conclude that you > have not thought things through. Thanks for the reminder, although I'm entirely unclear as to why you think (a) that I wasn't already aware of it (I have been trying to respond directly to any issue anyone raises) and (b) you felt it necessary. > The "mechanism ARIN uses today" that follows up to be sure that people > keep the additional promises of 100% utilization in a year and > suchlike, > that your proposing, were not designed for your proposal. They were > designed for the EXISTING IPv4 justification requirements - which > are laxer than > yours. They will need to be changed if your proposal were to work. According to ARIN staff, current requirements for additional address space allocations (according to section 4.2.4 of the NPRM) are: a) 100% utilization of all previous allocations b) 80% utilization of the most recent allocation Presumably, ARIN staff have mechanisms in place to verify both requirements. If they felt additional mechanisms were required to meet the increased restrictions the Soft Landing proposal imposed, I would have thought they would have told me in their comments to me on the previous draft of the policy. They did not nor do I feel it is appropriate for me to tell ARIN staff how to do their job. > Your proposals drive up the value of IPv4 and thus undercut the > financial > incentive to return unused IPv4. Even if there was a financial incentive to return unused IPv4 addresses (something I think many people would argue), the fact that IPv4 is nearing exhaustion would do this independent of any attempts to encourage conservation and promotion of IPv6. Regards, -drc From Kavalec at BSWA.com Fri Oct 5 02:41:37 2007 From: Kavalec at BSWA.com (G. Waleed Kavalec) Date: Fri, 5 Oct 2007 00:41:37 -0600 Subject: [ppml] Counsel statement on Legacy assignments? References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> Message-ID: > if arin does not want to carry out its commitment to > the community and to the USG when it was chartered [0], I see no contractual obligation to legacy non-members in [0]. -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Randy Bush Sent: Thursday, October 04, 2007 6:01 PM To: Stephen Sprunk Cc: ppml at arin.net Subject: Re: [ppml] Counsel statement on Legacy assignments? > "MR. RYAN: I've thought a little bit about what a stick might look like > here. So for example, it's very clear to me that denial of service by ARIN > is legally permitted. In other words, I don't believe we, as the non-profit > trying to carry out the community's wishes, have a duty to provide free > services for legacy address holders. And the denial of those free services > to legacy address holders pursuant to their lack of agreement is perfectly > permitted, in my judgment, as a matter of law." if arin does not want to carry out its commitment to the community and to the USG when it was chartered [0], i am sure the community can find an organization more interested in public service. probably such a change would be good for the community; at least this puff and bluff would cease. randy -- [0] http://rip.psg.com/~randy/970414.fncac.pdf foil 9 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From michael.dillon at bt.com Fri Oct 5 04:26:16 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 5 Oct 2007 09:26:16 +0100 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <47057EBB.6010609@psg.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> Message-ID: > if arin does not want to carry out its commitment to the > community and to the USG when it was chartered [0], i am sure > the community can find an organization more interested in > public service. probably such a change would be good for the > community; at least this puff and bluff would cease. > [0] http://rip.psg.com/~randy/970414.fncac.pdf foil 9 "Randy made a commitment" is not the same as "ARIN made a commitment". This is what the ninth slide says: ---------- ARIN - more Defensible than Status Quo * No cross-subsidy from sale of names * Non-profit, RIPE has even reduced rates * Stakeholders have a say * No plan to change policy * Current and old allocations and their DNS will be maintained with no policy changes ---------- Note the part where it says "Stakeholders have a say". That is the bit that led to PPML and the structure wherein the public has the ability to *CHANGE* ARIN policies. In any case, ARIN's commitment to the USG when it was chartered is embedded in its Articles of Incorporation http://www.arin.net/about_us/corp_docs/artic_incorp.html. Hopefully your huff and bluff about this phantom pronise will cease. --Michael Dillon From michael.dillon at bt.com Fri Oct 5 04:34:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 5 Oct 2007 09:34:22 +0100 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: <3758245C-C8EA-4C48-B5C4-A337FB3534D7@virtualized.org> References: <3758245C-C8EA-4C48-B5C4-A337FB3534D7@virtualized.org> Message-ID: > > Things do not necessarily scale > > linearly and the hierarchical structure of IPv4 > sub-allocation makes > > 100% allocation impossible for anyone to attain. > > As mentioned in a previous note, ARIN staff have told me > explicitly that 100% utilization of previous allocations is > an existing requirement. That does not change the fact that 100% utilization is technically impossible. That's probably why the existing practice is to only audit the last allocation for 80% utilization and ignore all previous allocations. > > IPv6 infrastructure. I would not be opposed to a policy > that bundled a > > bunch of such actions along with a phased deployment plan. > > So what parts do you not agree with? Not particularly relevant. I am opposed to the whole policy, not just because it has bad parts, but because it is too big, too overreaching, and has too many implications to properly evaluate in the short amount of time between the submission of the proposal and the meeting. --Michael Dillon From michael.dillon at bt.com Fri Oct 5 04:36:56 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 5 Oct 2007 09:36:56 +0100 Subject: [ppml] FW: [arin-announce] Updated ARIN Fee Schedule Message-ID: > In addition, the Board approved a multi-year fee waiver structure for > IPv6 allocations that will take effect on 1 January 2008. > Under this fee structure, IPv6 initial allocation and annual > subscription renewal fees will be partially waived, at a declining > annual rate, over the next four years. The amount of the waiver and > the resulting fees are detailed in a table under the "Future IPv6 > Waivers" section of the fee schedule at > http://www.arin.net/billing/fee_schedule.html#waivers Thank you for giving us clear and PREDICTABLE fees and removing the uncertainty of the previous waivers that came with an expiration date. --Michael Dillon From drc at virtualized.org Fri Oct 5 05:24:49 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Oct 2007 02:24:49 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: References: <3758245C-C8EA-4C48-B5C4-A337FB3534D7@virtualized.org> Message-ID: Michael, On Oct 5, 2007, at 1:34 AM, wrote: >> As mentioned in a previous note, ARIN staff have told me >> explicitly that 100% utilization of previous allocations is an >> existing requirement. > > That does not change the fact that 100% utilization is technically > impossible. That's probably why the existing practice is to only > audit the last allocation for 80% utilization and ignore all > previous allocations. The fact that you believe existing practice differs from what ARIN staff states is the current requirements raises interesting questions. I modified my proposal to its current form based on input from ARIN staff that if my previous version were to be implemented, it would actually reduce utilization requirements. If you believe the existing utilization requirements are "impossible", this is something that you may wish to raise with ARIN staff and/or via the public policy process. Regards, -drc From jcurran at istaff.org Fri Oct 5 07:41:32 2007 From: jcurran at istaff.org (John Curran) Date: Fri, 5 Oct 2007 07:41:32 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <47057EBB.6010609@psg.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> Message-ID: At 9:00 AM +0900 10/5/07, Randy Bush wrote: >if arin does not want to carry out its commitment to the community and >to the USG when it was chartered [0], i am sure the community can find >an organization more interested in public service. Intestesting enough, the presentation specifically includes commitment to following RFC2050, and RFC2050 states: "The IANA reserves the right to invalidate any IP assignments once it is determined the the requirement for the address space no longer exists. " I imagine there'd be a lot less discussion on not providing services to the legacy community, if indeed we're were indeed following the original guidance. One can reiterate that those assignments predate the RIR's, but they certainly don't precede the IANA, who was both an RFC2050 author and ex-officio trustee of ARIN. Either they're bound by this, and we can't change the rules at all, or they're not and it's perfectly reasonable to revise other assumptions in handling legacy assignments. /John From Keith at jcc.com Fri Oct 5 07:46:40 2007 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 5 Oct 2007 07:46:40 -0400 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested Message-ID: With the explanation that the 100% efficient utilization of the previous IP allocation is part of the current requirements, I think I understand how this proposal fits in with the current policies. I don't have an objection to this proposal. Keith _____ From: David Conrad [mailto:drc at virtualized.org] Sent: Thursday, October 04, 2007 6:25 PM To: Keith W. Hare Cc: Bill Darte; ppml at arin.net Subject: Re: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested Keith, On Oct 2, 2007, at 2:56 PM, Keith W. Hare wrote: I don't know for sure what it means to demonstrate efficient utilization of 100% of an IP allocation. For the definitions I can think of, I'm sceptical that is possible to honestly demonstrate efficient utilization of 100% of an IP allocation. I was told by ARIN staff that 100% utilization of all previous allocations is an _existing_ requirement. Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Keith at jcc.com Fri Oct 5 08:14:50 2007 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 5 Oct 2007 08:14:50 -0400 Subject: [ppml] Counsel statement on Legacy assignments? Message-ID: <05625205784bec75c9e483e3183fe0bf47062ac5@jcc.com> >From the discussions I've read about legacy assignments, I see the following points: 1. Removing the reverse DNS entries, etc. for legacy assignments would have a detrimental affect on the entire internet community, not just on the legacy assignment holders. 2. Maintaining the existing reverse DNS entries, etc. for legacy assignments costs ARIN very little. Most of the cost is in changes and the information doesn't change often. 3. Freezing changes to the reverse DNS entries, etc. for legacy assignments will lead to more errors in the data, which will as detrimental to ARIN and the entire internet community as it is to the legacy assignment holders. 4. Re-assigning addresses that have been held by legacy assignment holders will lead to chaos, unless the legacy assignment holders really are defunct, dead, or otherwise non-existent. 5. Telling a legacy assignment holder that if you don't join ARIN, we will do ... to you is more likely to tick off the legacy assignment holder than to get them to join ARIN. 6. Getting legacy assignment holders involved in the ARIN process is an advantage to ARIN and the internet community. 7. Spending a lot of time discussing whether or not ARIN has authority over the legacy address assignments is a complete waste of time -- it would be much more productive to explain to the legacy assignment holders why it is a benefit to join ARIN. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of John Curran Sent: Friday, October 05, 2007 7:42 AM To: Randy Bush Cc: ppml at arin.net Subject: Re: [ppml] Counsel statement on Legacy assignments? At 9:00 AM +0900 10/5/07, Randy Bush wrote: >if arin does not want to carry out its commitment to the community and >to the USG when it was chartered [0], i am sure the community can find >an organization more interested in public service. Intestesting enough, the presentation specifically includes commitment to following RFC2050, and RFC2050 states: "The IANA reserves the right to invalidate any IP assignments once it is determined the the requirement for the address space no longer exists. " I imagine there'd be a lot less discussion on not providing services to the legacy community, if indeed we're were indeed following the original guidance. One can reiterate that those assignments predate the RIR's, but they certainly don't precede the IANA, who was both an RFC2050 author and ex-officio trustee of ARIN. Either they're bound by this, and we can't change the rules at all, or they're not and it's perfectly reasonable to revise other assumptions in handling legacy assignments. /John _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From arin-contact at dirtside.com Fri Oct 5 08:23:42 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 5 Oct 2007 08:23:42 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> Message-ID: <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> On 10/5/07, John Curran wrote: > At 9:00 AM +0900 10/5/07, Randy Bush wrote: > >if arin does not want to carry out its commitment to the community and > >to the USG when it was chartered [0], i am sure the community can find > >an organization more interested in public service. > > Intestesting enough, the presentation specifically includes > commitment to following RFC2050, and RFC2050 states: John, Relatively few legacy assignments were made after RFC 2050 was published. Even if RFC 2050 could be considered "the law" for address assignments, it couldn't apply retroactively. Randy's point about replacing ARIN for RDNS is not unsupported by law. Consider the following scenario: 1. ARIN drops RDNS for legacy registrants. 2. The legacy registrants band together and produce an organization qualified to handle RNDS delegation. 3. The legacy registrants ask ARIN to transfer the RDNS duty to this new organization. 4. ARIN refuses. 5. The legacy registrants suffer problems with email and authentication due to the lack of RDNS. In this hypothetical scenario, ARIN doesn't just decline to provide services to legacy holders; they obstruct legacy holders from receiving the service from anyone else as well. Look up the term "tortious interference." It would be an interesting case to litigate. On 10/5/07, michael.dillon at bt.com wrote: > > [0] http://rip.psg.com/~randy/970414.fncac.pdf foil 9 > > "Randy made a commitment" is not the same as "ARIN made a commitment". Michael, This is one record that's part of the whole process which justified ARIN taking on management of the swamp instead of just managing new /8's like the other RIRs. For better or for worse, that "Current and old allocations and their DNS will be maintained with no policy changes" is a part of ARIN's heritage. It doesn't create an indefinate legal obligation on ARIN because the law makes that very difficult to do and this statement doesn't have the required elements. It does, however, create a moral obligation. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jr at jrw.org Fri Oct 5 08:35:56 2007 From: jr at jrw.org (J. R. Westmoreland) Date: Fri, 5 Oct 2007 06:35:56 -0600 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> Message-ID: <000001c8074c$49fd5ff0$ddf81fd0$@org> ---------------------------------------- J. R. Westmoreland Email: jr at jrw.org > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > William Herrin > Sent: Friday, October 05, 2007 6:24 AM > To: John Curran > Cc: Randy Bush; ppml at arin.net > Subject: Re: [ppml] Counsel statement on Legacy assignments? > > On 10/5/07, John Curran wrote: > > At 9:00 AM +0900 10/5/07, Randy Bush wrote: > > >if arin does not want to carry out its commitment to the community > and > > >to the USG when it was chartered [0], i am sure the community can > find > > >an organization more interested in public service. > > > > Intestesting enough, the presentation specifically includes > > commitment to following RFC2050, and RFC2050 states: > > John, > > Relatively few legacy assignments were made after RFC 2050 was > published. Even if RFC 2050 could be considered "the law" for address > assignments, it couldn't apply retroactively. > > Randy's point about replacing ARIN for RDNS is not unsupported by law. > Consider the following scenario: This has already happened once in the name registration arena. It once used to be Internic, now NSI. Now, you have a very large number of choices. You can shop for cost, services provided, friendliness of staff (grin) or almost whatever you wish. I see no reason that IP address space, ASNs and all other items managed by ARIN couldn't go the same way. This may not be the best but it is certainly possible. > > 1. ARIN drops RDNS for legacy registrants. > 2. The legacy registrants band together and produce an organization > qualified to handle RNDS delegation. > 3. The legacy registrants ask ARIN to transfer the RDNS duty to this > new organization. > 4. ARIN refuses. > 5. The legacy registrants suffer problems with email and > authentication due to the lack of RDNS. > > In this hypothetical scenario, ARIN doesn't just decline to provide > services to legacy holders; they obstruct legacy holders from > receiving the service from anyone else as well. Look up the term > "tortious interference." It would be an interesting case to litigate. > > > On 10/5/07, michael.dillon at bt.com wrote: > > > [0] http://rip.psg.com/~randy/970414.fncac.pdf foil 9 > > > > "Randy made a commitment" is not the same as "ARIN made a > commitment". > > Michael, > > This is one record that's part of the whole process which justified > ARIN taking on management of the swamp instead of just managing new > /8's like the other RIRs. For better or for worse, that "Current and > old allocations and their DNS will be maintained with no policy > changes" is a part of ARIN's heritage. > > It doesn't create an indefinate legal obligation on ARIN because the > law makes that very difficult to do and this statement doesn't have > the required elements. It does, however, create a moral obligation. > > 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From plzak at arin.net Fri Oct 5 08:41:52 2007 From: plzak at arin.net (Ray Plzak) Date: Fri, 5 Oct 2007 08:41:52 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > William Herrin > Sent: Friday, October 05, 2007 8:24 AM > To: John Curran > Cc: Randy Bush; ppml at arin.net > Subject: Re: [ppml] Counsel statement on Legacy assignments? > > On 10/5/07, John Curran wrote: > > At 9:00 AM +0900 10/5/07, Randy Bush wrote: > > >if arin does not want to carry out its commitment to the community > and > > >to the USG when it was chartered [0], i am sure the community can > find > > >an organization more interested in public service. > > > > Intestesting enough, the presentation specifically includes > > commitment to following RFC2050, and RFC2050 states: > > John, > > Relatively few legacy assignments were made after RFC 2050 was > published. Even if RFC 2050 could be considered "the law" for address > assignments, it couldn't apply retroactively. > Regarding the applicability of RFC 2050 the abstract states the following: "This document replaces RFC 1466, with all the guidelines and procedures updated and modified in the light of experience." RFC 1466 states: "This document proposes a plan which will forward the implementation of RFC 1174 and which defines the allocation and assignment of the network number space." RFC 1174 provides further reference to the allocation and assignment and in effect documents the status quo in 1990. Thus John's statement regarding RFC 2050 pertaining to allocation and assignment activity predating its publication date would appear to be valid. Ray > Randy's point about replacing ARIN for RDNS is not unsupported by law. > Consider the following scenario: > > 1. ARIN drops RDNS for legacy registrants. > 2. The legacy registrants band together and produce an organization > qualified to handle RNDS delegation. > 3. The legacy registrants ask ARIN to transfer the RDNS duty to this > new organization. > 4. ARIN refuses. > 5. The legacy registrants suffer problems with email and > authentication due to the lack of RDNS. > > In this hypothetical scenario, ARIN doesn't just decline to provide > services to legacy holders; they obstruct legacy holders from > receiving the service from anyone else as well. Look up the term > "tortious interference." It would be an interesting case to litigate. > > > On 10/5/07, michael.dillon at bt.com wrote: > > > [0] http://rip.psg.com/~randy/970414.fncac.pdf foil 9 > > > > "Randy made a commitment" is not the same as "ARIN made a > commitment". > > Michael, > > This is one record that's part of the whole process which justified > ARIN taking on management of the swamp instead of just managing new > /8's like the other RIRs. For better or for worse, that "Current and > old allocations and their DNS will be maintained with no policy > changes" is a part of ARIN's heritage. > > It doesn't create an indefinate legal obligation on ARIN because the > law makes that very difficult to do and this statement doesn't have > the required elements. It does, however, create a moral obligation. > > 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From jcurran at istaff.org Fri Oct 5 08:56:26 2007 From: jcurran at istaff.org (John Curran) Date: Fri, 5 Oct 2007 08:56:26 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> Message-ID: At 8:23 AM -0400 10/5/07, William Herrin wrote: >On 10/5/07, John Curran wrote: >> At 9:00 AM +0900 10/5/07, Randy Bush wrote: >> >if arin does not want to carry out its commitment to the community and >> >to the USG when it was chartered [0], i am sure the community can find >> >an organization more interested in public service. >> >> Intestesting enough, the presentation specifically includes >> commitment to following RFC2050, and RFC2050 states: > >John, > >Relatively few legacy assignments were made after RFC 2050 was >published. Even if RFC 2050 could be considered "the law" for address >assignments, it couldn't apply retroactively. Bill - Everyone who received address space received it under the direction of the IANA (and indirectly, the US government) prior to their respective RIR being formed. The absence of a formal contract for such assignments means that there are many possible interpretations as to the particular rights and obligations of the parties. In any case, both legacy holders and ARIN appear to have obligations to the community. ARIN will certainly do as the community directs, but one wonders if the legacy community would like us all to forget their community obligations and simply pretend that their assignments were done in a total contractual and community obligation vacuum... /John From info at arin.net Fri Oct 5 09:33:14 2007 From: info at arin.net (Member Services) Date: Fri, 05 Oct 2007 09:33:14 -0400 Subject: [ppml] ARIN XX Reminders Message-ID: <47063D1A.80402@arin.net> Agenda Updates The panel on Wednesday morning is "IP Markets?"; it's about "Physics, Economics, Law, and FUD (get in line early)." Thursday morning now includes a presentation called "IPv6 Support Among Commercial Firewalls." Information on all sessions is available at: http://www.arin.net/ARIN-XX/agenda.html The Open Policy Hour Sign up today to present your ideas at the ARIN XX Open Policy Hour, Tuesday, 16 October, from 6:00-7:00 PM (MDT). If you have a policy proposal you?d like to receive feedback on prior to submitting it to the community on the PPML, here is your opportunity. Those who sign up by 12 October will be given the first opportunity to speak. Send an e-mail to policy at arin.net with your name, organization, and a general description of the policy subject you wish to present. Everyone is invited to attend the session and raise ideas and suggestions. You do not need to have a formal presentation in order to participate. Signing up just guarantees you the opportunity to present. Registration and Remote Participation You still have time to register for ARIN XX. If you are unable to attend in person, you can still participate remotely. Register for the meeting at: http://www.arin.net/ARIN-XX/ Comments received from remote participants will be moderated and presented during normal question and answer periods. ARIN will use e-mail to provide the interactive portion of the remote participation effort. All remote participants are subject to the Remote Participation Acceptable Use Policy (AUP). Additional information about remote participation, including the Remote Participation AUP, is available at: http://www.arin.net/ARIN-XX/webcast.html We look forward to your participation in ARIN XX. Please contact Member Services at info at arin.net if you have any questions. Regards, Member Services Department American Registry for Internet Numbers (ARIN) From arin-contact at dirtside.com Fri Oct 5 09:46:14 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 5 Oct 2007 09:46:14 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> Message-ID: <3c3e3fca0710050646v3a1426f9vd82f3444c66d6e28@mail.gmail.com> On 10/5/07, John Curran wrote: > In any case, both legacy holders and ARIN appear to have > obligations to the community. ARIN will certainly do as the > community directs, but one wonders if the legacy community > would like us all to forget their community obligations and > simply pretend that their assignments were done in a total > contractual and community obligation vacuum... John, Don't take me wrong; I think the current ARIN process is a sound one and I think it would be healthy to bring as many folks into the fold as possible. I'm particularly fond of proposals which encourage IPv4 assignments to segue into IPv6 assingments with both coming under the ARIN RSA in the process. I don't think the "stick" approach is healthy. Even just having discussions about discontinuing folks' RDNS creates a comment record where any legacy registrant lurking about must think we're all a bunch of a-holes. How that activity and perception furthers ARIN's mission completely escapes me. 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 Fri Oct 5 09:58:16 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 5 Oct 2007 08:58:16 -0500 Subject: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested In-Reply-To: References: Message-ID: "I don't have objection to this proposal"...seems to abdicate responsibility to others who have stronger feelings. If we think of the ppml in the context of 'show of hands'.... You are neither raising your hand FOR nor AGAINST.... I for one could like a clearer declaration if you can arrive at one before we have to judge consensus. Sorry...you were convenient 'to pick on' for this reiteration of the ACs need for clear guidance by the industry.... ;-) Bill Darte ARIN Advisory Council ________________________________ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Keith W. Hare Sent: Friday, October 05, 2007 6:47 AM To: David Conrad; ppml at arin.net Cc: Bill Darte Subject: Re: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested With the explanation that the 100% efficient utilization of the previous IP allocation is part of the current requirements, I think I understand how this proposal fits in with the current policies. I don't have an objection to this proposal. Keith ________________________________ From: David Conrad [mailto:drc at virtualized.org] Sent: Thursday, October 04, 2007 6:25 PM To: Keith W. Hare Cc: Bill Darte; ppml at arin.net Subject: Re: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested Keith, On Oct 2, 2007, at 2:56 PM, Keith W. Hare wrote: I don't know for sure what it means to demonstrate efficient utilization of 100% of an IP allocation. For the definitions I can think of, I'm sceptical that is possible to honestly demonstrate efficient utilization of 100% of an IP allocation. I was told by ARIN staff that 100% utilization of all previous allocations is an _existing_ requirement. Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Keith at jcc.com Fri Oct 5 10:25:10 2007 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 5 Oct 2007 10:25:10 -0400 Subject: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested Message-ID: Since you asked... It is unclear (to me, at least) whether or not the policy change in this proposal will achieve its stated goals. However, I don't think the policy will hurt things as the available IPv4 address space approaches exhaustion. I don't expect to need any additional IPv4 space -- the /24 we got 16 years ago is sufficient for our needs, particularly with NAT. Therefore, I don't have an objection to this proposal. Keith _____ From: Bill Darte [mailto:BillD at cait.wustl.edu] Sent: Friday, October 05, 2007 9:58 AM To: Keith W. Hare; David Conrad; ppml at arin.net Subject: RE: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested "I don't have objection to this proposal"...seems to abdicate responsibility to others who have stronger feelings. If we think of the ppml in the context of 'show of hands'.... You are neither raising your hand FOR nor AGAINST.... I for one could like a clearer declaration if you can arrive at one before we have to judge consensus. Sorry...you were convenient 'to pick on' for this reiteration of the ACs need for clear guidance by the industry.... ;-) Bill Darte ARIN Advisory Council _____ From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Keith W. Hare Sent: Friday, October 05, 2007 6:47 AM To: David Conrad; ppml at arin.net Cc: Bill Darte Subject: Re: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested With the explanation that the 100% efficient utilization of the previous IP allocation is part of the current requirements, I think I understand how this proposal fits in with the current policies. I don't have an objection to this proposal. Keith _____ From: David Conrad [mailto:drc at virtualized.org] Sent: Thursday, October 04, 2007 6:25 PM To: Keith W. Hare Cc: Bill Darte; ppml at arin.net Subject: Re: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested Keith, On Oct 2, 2007, at 2:56 PM, Keith W. Hare wrote: I don't know for sure what it means to demonstrate efficient utilization of 100% of an IP allocation. For the definitions I can think of, I'm sceptical that is possible to honestly demonstrate efficient utilization of 100% of an IP allocation. I was told by ARIN staff that 100% utilization of all previous allocations is an _existing_ requirement. Regards, -drc -------------- next part -------------- An HTML attachment was scrubbed... URL: From BillD at cait.wustl.edu Fri Oct 5 10:26:13 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 5 Oct 2007 09:26:13 -0500 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <3c3e3fca0710050646v3a1426f9vd82f3444c66d6e28@mail.gmail.com> References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com><47057EBB.6010609@psg.com> <3c3e3fca0710050523h7fe8ea84sfd239c7f6362e7ac@mail.gmail.com> <3c3e3fca0710050646v3a1426f9vd82f3444c66d6e28@mail.gmail.com> Message-ID: Seems to me that since there exists a vocal segment of the community that wants ARIN to engage the legacy holders and to encourage or impose upon them some obligations or limit their 'free' services, it is wise that ARIN consider what authority exists...should the broader community come to believe as the vocal segment. Discussion of this authority and options to BOTH encourage or impose... in an open and straightforward manner is the right thing to do. IMO. If the legacy community feels threatened by such, then I encourage all to better understand the process in which such discussion is taking place and the means that exists to influence those discussions and community perspective...by engaging the community at large and ARIN through participation. Bill Darte ARIN Advisory Council -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Friday, October 05, 2007 8:46 AM To: John Curran Cc: ppml at arin.net Subject: Re: [ppml] Counsel statement on Legacy assignments? On 10/5/07, John Curran wrote: > In any case, both legacy holders and ARIN appear to have > obligations to the community. ARIN will certainly do as the > community directs, but one wonders if the legacy community > would like us all to forget their community obligations and > simply pretend that their assignments were done in a total > contractual and community obligation vacuum... John, Don't take me wrong; I think the current ARIN process is a sound one and I think it would be healthy to bring as many folks into the fold as possible. I'm particularly fond of proposals which encourage IPv4 assignments to segue into IPv6 assingments with both coming under the ARIN RSA in the process. I don't think the "stick" approach is healthy. Even just having discussions about discontinuing folks' RDNS creates a comment record where any legacy registrant lurking about must think we're all a bunch of a-holes. How that activity and perception furthers ARIN's mission completely escapes me. 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 (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From Ed.Lewis at neustar.biz Fri Oct 5 10:32:44 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 5 Oct 2007 10:32:44 -0400 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: References: Message-ID: At 16:10 -0500 10/2/07, Bill Darte wrote: >As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would like to >ask the community to once again consider this proposal in advance of the >Albuquerque Public Policy and Membership Meetings >(http://www.arin.net/ARIN-XX/index.html) >and voice support or non-support >for this proposal with concise reasoning. It would certainly be bad to "abdicate responsibility"... On the one hand I like the way this proposal thinks, but it thinks like an engineer. It certainly has the mechanics in it to achieve the goal of softening the transition pains. But I also waver over whether it is worth the effort. At the APNIC meeting (yes, I know, not "our" region, yet a public policy meeting none the less) there was a discussion between two proposals. The two were similar up to a parameter. Each proposal mandated that IANA operate as is until there were either 1x5 or 2x5 /8's left (assuming the number of RIRs is 5). Once the last 5 or 10 /8's were left they were handed out evenly to the RIRs regardless of burn rates. Of the two, I preferred the handing out of 1 /8 (not the 2 /8). The reason is that this approach is largely ceremonial. While it is true that the burn rate of a /8 varies region to region, for 1 /8, this isn't a significant difference. (There could be a sharp rise in membership at the lower burn rate organizations, but really, there isn't much to get at that point.) In the lower burn rate regions, the symbolism of being given as much a the higher rate seems somewhat important. Those proposals are lightweight work-wise, least command-econonmyish, have probably the right dose of ceremonial benefit, and aren't trying to delay the pain of the IPv4 run out. So, on the other hand, I think that the IPv4 Soft Landing might be "trying to hard" to protect ourselves. Ultimately, in a vacuum, it's a good proposal. But considering other ideas floating around I have doubt that it's the right mechanism. As an aside - if we delay the run out of IPv4 by 12 months, is there an indication that the obstacle to IPv6 will be removed in that 12 month period? If it is the routing system, will 12 more months improve/strengthen it? (I guess I have never understood the rationale for "rationing" the remaining IPv4 addresses. They aren't a consumable {water, oil} and the last won't tide us over until there's a rescue.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlw+arin at tellme.com Fri Oct 5 10:54:15 2007 From: dlw+arin at tellme.com (David Williamson) Date: Fri, 5 Oct 2007 07:54:15 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: References: <4702BCC5.2040201@internap.com> <20071002220823.GF23649@shell01.cell.sv2.tellme.com> Message-ID: <20071005145414.GR23649@shell01.cell.sv2.tellme.com> On Thu, Oct 04, 2007 at 03:27:40PM -0700, David Conrad wrote: > David, > > On Oct 2, 2007, at 3:08 PM, David Williamson wrote: > >Does it matter if that happens slower as a result of policy changes? > > The point of a "soft landing" proposal is to extend the runway for > transition, but do so in a way as to discourage procrastination. The > answer to whether it matters is likely a subject opinion. Clearly I > think it does (or I wouldn't have bother to make the proposal), but > opinions vary. That explains how your proposal is intended to work, and also explains why you think it is important, but I don't think it answers my question. You note that my question is a matter of opinion...that's almost certainly true, given that predicting the behavior of groups of humans is fundamentally hard, even at the scale we're discussing. Perhaps I'm pessimistic, but I think the extra time achieved from your proposal is probably just more time to avoid dealing with IPv6. I personally really dislike v6 - it's just going to be a PITA with little real value besides the fact that there's more of it than v4. That said, I'm the primary cheerleader with my organization because I understand the consequences of not pushing the transition *now*. Organizaions that lack someone pushing them through the transition are unlikely, in my opinion, to benefit from the delay. As someone else noted, there's nothing mechanically wrong with the proposal, but that's hardly a vote of support. Bill's original question required an answer in the form of a definitive statement of support or non-support, which I have thus far failed to provide. I think I can resolve my fence sitting: "do no harm" is a nice idea, but "if it ain't broke, don't fix it" is a stronger criterion. I don't think this will do much good, so current policy isn't broken. That implies there's no need to change anything, which is effectively a lack of support for this. It's the best of the lot, but the problem it tries to solve likely cannot be solved in policy. -David From peter at boku.net Fri Oct 5 11:07:28 2007 From: peter at boku.net (Peter Eisch) Date: Fri, 05 Oct 2007 10:07:28 -0500 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: After months of reading "interesting" email about legacy holders, what direct communication has happened to these organizations to bring them into the fold? Until they are here (or a party to another less general list) the discussion continues to be engaged by only the mostly non-affected elite. In this forum the discussions are typically emotional, theoretical and rarely based on facts. This is typical of a guidance list. It's good to get ideas bounced around and get the input from a wide audience. Could some effort be spent on getting the attention of the legacy holders and establish a communication channel with them? You have maybe a dozen [individual] readers here with legacy holdings. I'll suspect that we're not the majority and we surely can't speak for the balance. Until they're present and a part of the process this discussion continues to be little more than "us" and "them" and clearly without community perspective. peter On 10/5/07 9:26 AM, "Bill Darte" wrote: > Seems to me that since there exists a vocal segment of the community > that wants ARIN to engage the legacy holders and to encourage or impose > upon them some obligations or limit their 'free' services, it is wise > that ARIN consider what authority exists...should the broader community > come to believe as the vocal segment. > > Discussion of this authority and options to BOTH encourage or impose... > in an open and straightforward manner is the right thing to do. IMO. > > If the legacy community feels threatened by such, then I encourage all > to better understand the process in which such discussion is taking > place and the means that exists to influence those discussions and > community perspective...by engaging the community at large and ARIN > through participation. > > Bill Darte > ARIN Advisory Council > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > William Herrin > Sent: Friday, October 05, 2007 8:46 AM > To: John Curran > Cc: ppml at arin.net > Subject: Re: [ppml] Counsel statement on Legacy assignments? > > On 10/5/07, John Curran wrote: >> In any case, both legacy holders and ARIN appear to have >> obligations to the community. ARIN will certainly do as the >> community directs, but one wonders if the legacy community >> would like us all to forget their community obligations and >> simply pretend that their assignments were done in a total >> contractual and community obligation vacuum... > > John, > > Don't take me wrong; I think the current ARIN process is a sound one > and I think it would be healthy to bring as many folks into the fold > as possible. I'm particularly fond of proposals which encourage IPv4 > assignments to segue into IPv6 assingments with both coming under the > ARIN RSA in the process. > > I don't think the "stick" approach is healthy. Even just having > discussions about discontinuing folks' RDNS creates a comment record > where any legacy registrant lurking about must think we're all a bunch > of a-holes. How that activity and perception furthers ARIN's mission > completely escapes me. > > Regards, > Bill Herrin > From BillD at cait.wustl.edu Fri Oct 5 11:32:39 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 5 Oct 2007 10:32:39 -0500 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: And do you have specific suggestions on how ARIN might/should proceed to do this as a means of communication....and on content of the message? A guidance forum should proffer 'guidance' if not outright policy proposals for the community to consider. "Interesting" discussion is a useful preparation for such. Thanks for you discussion. bd -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Peter Eisch Sent: Friday, October 05, 2007 10:07 AM To: ppml at arin.net Subject: Re: [ppml] Counsel statement on Legacy assignments? After months of reading "interesting" email about legacy holders, what direct communication has happened to these organizations to bring them into the fold? Until they are here (or a party to another less general list) the discussion continues to be engaged by only the mostly non-affected elite. In this forum the discussions are typically emotional, theoretical and rarely based on facts. This is typical of a guidance list. It's good to get ideas bounced around and get the input from a wide audience. Could some effort be spent on getting the attention of the legacy holders and establish a communication channel with them? You have maybe a dozen [individual] readers here with legacy holdings. I'll suspect that we're not the majority and we surely can't speak for the balance. Until they're present and a part of the process this discussion continues to be little more than "us" and "them" and clearly without community perspective. peter On 10/5/07 9:26 AM, "Bill Darte" wrote: > Seems to me that since there exists a vocal segment of the community > that wants ARIN to engage the legacy holders and to encourage or impose > upon them some obligations or limit their 'free' services, it is wise > that ARIN consider what authority exists...should the broader community > come to believe as the vocal segment. > > Discussion of this authority and options to BOTH encourage or impose... > in an open and straightforward manner is the right thing to do. IMO. > > If the legacy community feels threatened by such, then I encourage all > to better understand the process in which such discussion is taking > place and the means that exists to influence those discussions and > community perspective...by engaging the community at large and ARIN > through participation. > > Bill Darte > ARIN Advisory Council > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > William Herrin > Sent: Friday, October 05, 2007 8:46 AM > To: John Curran > Cc: ppml at arin.net > Subject: Re: [ppml] Counsel statement on Legacy assignments? > > On 10/5/07, John Curran wrote: >> In any case, both legacy holders and ARIN appear to have >> obligations to the community. ARIN will certainly do as the >> community directs, but one wonders if the legacy community >> would like us all to forget their community obligations and >> simply pretend that their assignments were done in a total >> contractual and community obligation vacuum... > > John, > > Don't take me wrong; I think the current ARIN process is a sound one > and I think it would be healthy to bring as many folks into the fold > as possible. I'm particularly fond of proposals which encourage IPv4 > assignments to segue into IPv6 assingments with both coming under the > ARIN RSA in the process. > > I don't think the "stick" approach is healthy. Even just having > discussions about discontinuing folks' RDNS creates a comment record > where any legacy registrant lurking about must think we're all a bunch > of a-holes. How that activity and perception furthers ARIN's mission > completely escapes me. > > Regards, > Bill Herrin > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From sethm at rollernet.us Fri Oct 5 12:38:04 2007 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Oct 2007 09:38:04 -0700 Subject: [ppml] FW: [arin-announce] Updated ARIN Fee Schedule In-Reply-To: References: Message-ID: <4706686C.4020700@rollernet.us> michael.dillon at bt.com wrote: >> In addition, the Board approved a multi-year fee waiver structure for >> IPv6 allocations that will take effect on 1 January 2008. >> Under this fee structure, IPv6 initial allocation and annual >> subscription renewal fees will be partially waived, at a declining >> annual rate, over the next four years. The amount of the waiver and >> the resulting fees are detailed in a table under the "Future IPv6 >> Waivers" section of the fee schedule at >> http://www.arin.net/billing/fee_schedule.html#waivers > > Thank you for giving us clear and PREDICTABLE fees and > removing the uncertainty of the previous waivers that came > with an expiration date. > Although it does seem to mean if you want to get IPv6 PI space and you're an end user like myself, you'd better do it now before the price goes up next year. I guess that means I'll be getting mine soon. ~Seth From tedm at ipinc.net Fri Oct 5 13:38:25 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 5 Oct 2007 10:38:25 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David Conrad >Sent: Friday, October 05, 2007 2:25 AM >To: >Cc: ppml at arin.net >Subject: Re: [ppml] IPv4 Soft Landing - Discussion >andSupport/Non-SupportRequested > > >Michael, > >On Oct 5, 2007, at 1:34 AM, > wrote: >>> As mentioned in a previous note, ARIN staff have told me >>> explicitly that 100% utilization of previous allocations is an >>> existing requirement. >> >> That does not change the fact that 100% utilization is technically >> impossible. That's probably why the existing practice is to only >> audit the last allocation for 80% utilization and ignore all >> previous allocations. > >The fact that you believe existing practice differs from what ARIN >staff states is the current requirements raises interesting questions. > I think the problem here isn't in the percentages it is in the definition of "utilization" When filling out a address registration request I could state for example that I have allocated a total of 32 /29's to customers. ARIN doesen't require further justification on /29's that are allocated to end users. I could then claim 100% utilization on a /24. This of course would in no way impact the fact that I could likely go back to 80% of the customers that those /29's are allocated to and re-subnet them into /30s with no ill effects, and thereby generate more IP addresses for me to use. Or I could go into my network and remove all /30's on all serial links and replace them with IP unnumbered, or with private addresses, to generate further numbers. Or I could require some customers to use translation and port forwarding to reduce public number use. Or require virtual websites or some such. A "technical" full utilization would be ALL IP addresses in a given CIDR block to be IN USE as either host IPs, network IP's or broadcast IPs. I believe Michael was using "technically" in it's slang usage meaning "virtually impossible in most cases from a practical standpoint" In most production subnets it is virtually impossible in most cases from a practical standpoint that you will get full utilization for a long enough period of time to be able to see a IP request through. Ted From drc at virtualized.org Fri Oct 5 13:40:14 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Oct 2007 10:40:14 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: References: Message-ID: <84D4760A-4F07-47B2-9747-D63B6B6289A4@virtualized.org> Ed, On Oct 5, 2007, at 7:32 AM, Edward Lewis wrote: > As an aside - if we delay the run out of IPv4 by 12 months, is > there an indication that the obstacle to IPv6 will be removed in > that 12 month period? Unlikely. The obstacle (IMHO) to IPv6 deployment is that it doesn't solve a problem anyone thinks they have. However, with that said, the IPv4 Soft Landing proposal does try to go around this obstacle (see below). > If it is the routing system, will 12 more months improve/strengthen > it? No. I always thought the RIRs didn't focus on routing. > (I guess I have never understood the rationale for "rationing" the > remaining IPv4 addresses. They aren't a consumable {water, oil} An interesting assertion. I'd argue the IPv4 _free pool_ is a consumable. It is the free pool that will be rationed, either incrementally (via increased requirements) or in a binary way (yesterday: yes, you can have your address space. today: nope. no more address space available, period.) > and the last won't tide us over until there's a rescue.) The point of any "soft landing"-style proposal is to attempt to buy more time for folks who need it to make the transition by imposing some form of rationing. In my proposal the rationing is based on increased requirements to document ratcheted up utilization. My proposal also goes a step further in that it attempts to encourage IPv6 deployment (given it seems the general consensus is that moving to IPv6 is better than increased proliferation of IPv4+NAT). In the ideal world, the increased restrictions on obtaining IPv4 would impose sufficient additional administrative (or other) cost that when taken in the context of the encouragement of IPv6, would reduce the barriers for ISPs to deploy IPv6 despite there being insufficient customer demand. In other words, the goal is to create an environment that breaks the IPv6 chicken-and-egg problem. No other proposal I am aware of attempts to do this. To be honest, the two other proposals you mention feel a lot to me like rearranging deck chairs on the Titanic -- shuffling where the End Days free pool resides might encourage investment in unanticipated places but it does nothing to either extend the lifetime of the free pool nor encourage the transition to IPv6. Neither proposal hurts anything, of course, rather I just don't see what advantage they bring. Regards, -drc From drc at virtualized.org Fri Oct 5 13:42:18 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Oct 2007 10:42:18 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: <20071005145414.GR23649@shell01.cell.sv2.tellme.com> References: <4702BCC5.2040201@internap.com> <20071002220823.GF23649@shell01.cell.sv2.tellme.com> <20071005145414.GR23649@shell01.cell.sv2.tellme.com> Message-ID: <82801DFA-ED7D-4162-9B8C-33C4B9A9A3BE@virtualized.org> David, On Oct 5, 2007, at 7:54 AM, David Williamson wrote: > That explains how your proposal is intended to work, and also explains > why you think it is important, but I don't think it answers my > question. My response to Ed may be a more direct answer. Regards, -drc From tedm at ipinc.net Fri Oct 5 14:05:23 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 5 Oct 2007 11:05:23 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <000001c8074c$49fd5ff0$ddf81fd0$@org> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >J. R. Westmoreland >Sent: Friday, October 05, 2007 5:36 AM >To: 'William Herrin'; 'John Curran' >Cc: 'Randy Bush'; ppml at arin.net >Subject: Re: [ppml] Counsel statement on Legacy assignments? > >> Randy's point about replacing ARIN for RDNS is not unsupported by law. >> Consider the following scenario: > >This has already happened once in the name registration arena. >It once used to be Internic, now NSI. Now, you have a very large number of >choices. You can shop for cost, services provided, friendliness of staff >(grin) or almost whatever you wish. Technically this has NOT happened in the name registration arena. You are confusing the difference between a retailer of domain names and the actual DNS infrastructure itself. Domain names are USUALLY purchased by RETAIL customers. Sally Sue wants a domain name, she goes to GoDaddy or someplace like that and gets it. That's where your very large number of choices exist. But, ALL of those registrars have to abide by a SINGLE point of control on the DNS infrastructure - meaning IANA. A registrar cannot simply make up a TLD out of thin air for example and start using it. IP addresses are USUALLY requested by RETAIL customers. Sally Sue wants an IP address, she goes to EarthLink or some other ISP and gets it. That's where your very large number of choices exist. But, ALL of those North American ISPs have to abide by a SINGLE point of control on the IP infrastructure - meaning ARIN. An ISP cannot simply make up an IP address out of thin air for example and start using it. >I see no reason that IP address space, ASNs and all other items managed by >ARIN couldn't go the same way. >This may not be the best but it is certainly possible. > What Randy is proposing about ARIN is equivalent in the DNS system with replacing IANA with "something else" That hasn't happened for many good reasons, and it likely will not happen. Just as it is unlikely for ARIN to ever be replaced. You have seen how difficult it is to get consensus on ARIN's activities. ANY replacement "thing" will have just as difficult a time as getting consensus - plus they will have another group, the "old ARIN supporters" who will be out for blood and looking for any possible way to hamstring them. Randy is essentially talking out his ass. The political reality is that every day that passes merely continues to solidify the existing governmental apparatus over the Internet and over IP addressing. The days of revolutionary changes on the Internet governance are over. The real activity these days is where it is right now - working out policies for those existing organizations to work with. Remember that Randy is one of the old guard in this business - he was participating back in the days when there was revolutionary change in Internet governance. You have to have some sympathy for him - he's obviously having a difficult time understanding how rapidly the political realities of the situation have changed over the last few years. :-) Ted From michael.dillon at bt.com Fri Oct 5 14:25:44 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 5 Oct 2007 19:25:44 +0100 Subject: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested In-Reply-To: References: Message-ID: > A "technical" full utilization would be ALL IP addresses in a > given CIDR block to be IN USE as either host IPs, network > IP's or broadcast IPs. > I believe Michael was using "technically" in it's slang usage > meaning "virtually impossible in most cases from a practical > standpoint" Not slang. The word utilization is technical jargon to network engineering and operations staff. They use it to mean that a particular subnet is full, i.e. every IP addr is assigned to a host or an active switch port or something like that. This TECHNICAL meaning is very different from the administrative meaning used by ARIN. However, even though ARIN uses the word differently from the plain English meaning, they still have not bothered to define the term. This is one of many vague areas in ARIN policy that leads the uninitiated to misunderstand what is going on. --Michael Dillon From BillD at cait.wustl.edu Fri Oct 5 14:30:28 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 5 Oct 2007 13:30:28 -0500 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: <000001c8074c$49fd5ff0$ddf81fd0$@org> Message-ID: Ted said below.... " The days of revolutionary changes on the Internet governance are over."....given the ITU and UN's WSIS and WGIG processes, I can only hope that he is correct.... Bill Darte ARIN Advisory Council -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Friday, October 05, 2007 1:05 PM To: J. R. Westmoreland; 'William Herrin'; 'John Curran' Cc: ppml at arin.net Subject: Re: [ppml] Counsel statement on Legacy assignments? >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >J. R. Westmoreland >Sent: Friday, October 05, 2007 5:36 AM >To: 'William Herrin'; 'John Curran' >Cc: 'Randy Bush'; ppml at arin.net >Subject: Re: [ppml] Counsel statement on Legacy assignments? > >> Randy's point about replacing ARIN for RDNS is not unsupported by law. >> Consider the following scenario: > >This has already happened once in the name registration arena. >It once used to be Internic, now NSI. Now, you have a very large number of >choices. You can shop for cost, services provided, friendliness of staff >(grin) or almost whatever you wish. Technically this has NOT happened in the name registration arena. You are confusing the difference between a retailer of domain names and the actual DNS infrastructure itself. Domain names are USUALLY purchased by RETAIL customers. Sally Sue wants a domain name, she goes to GoDaddy or someplace like that and gets it. That's where your very large number of choices exist. But, ALL of those registrars have to abide by a SINGLE point of control on the DNS infrastructure - meaning IANA. A registrar cannot simply make up a TLD out of thin air for example and start using it. IP addresses are USUALLY requested by RETAIL customers. Sally Sue wants an IP address, she goes to EarthLink or some other ISP and gets it. That's where your very large number of choices exist. But, ALL of those North American ISPs have to abide by a SINGLE point of control on the IP infrastructure - meaning ARIN. An ISP cannot simply make up an IP address out of thin air for example and start using it. >I see no reason that IP address space, ASNs and all other items managed by >ARIN couldn't go the same way. >This may not be the best but it is certainly possible. > What Randy is proposing about ARIN is equivalent in the DNS system with replacing IANA with "something else" That hasn't happened for many good reasons, and it likely will not happen. Just as it is unlikely for ARIN to ever be replaced. You have seen how difficult it is to get consensus on ARIN's activities. ANY replacement "thing" will have just as difficult a time as getting consensus - plus they will have another group, the "old ARIN supporters" who will be out for blood and looking for any possible way to hamstring them. Randy is essentially talking out his ass. The political reality is that every day that passes merely continues to solidify the existing governmental apparatus over the Internet and over IP addressing. The days of revolutionary changes on the Internet governance are over. The real activity these days is where it is right now - working out policies for those existing organizations to work with. Remember that Randy is one of the old guard in this business - he was participating back in the days when there was revolutionary change in Internet governance. You have to have some sympathy for him - he's obviously having a difficult time understanding how rapidly the political realities of the situation have changed over the last few years. :-) Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From tedm at ipinc.net Fri Oct 5 14:37:37 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 5 Oct 2007 11:37:37 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: Message-ID: >-----Original Message----- >From: David Conrad [mailto:drc at virtualized.org] >Sent: Thursday, October 04, 2007 10:10 PM >To: Ted Mittelstaedt >Cc: Public Policy Mailing List >Subject: Re: [ppml] IPv4 Soft Landing - Discussion and >Support/Non-SupportRequested > > > >According to ARIN staff, current requirements for additional address >space allocations (according to section 4.2.4 of the NPRM) are: > >a) 100% utilization of all previous allocations >b) 80% utilization of the most recent allocation > >Presumably, ARIN staff have mechanisms in place to verify both >requirements. Once more, this is merely sidestepping the issue. I am not arguing that ARIN doesen't have mechanisms in place to verify both requirements. I am telling you point blank that nothing in your policy requires ARIN to use those mechanisms to -continue to make sure- that the requestors do what they say they are promising, after they get their addressing, and you have nothing in your policy that specifices penalties if they do not live up to their promises. You really are sinking your own ship here. "Presumably?" In short, you have the audacity to propose modifying requirements but you have no understanding of how enforcement relates to those very requirements your trying to propose? I don't think I am going to have any success trying to explain this to you any further. You need to research lawmaking and policymaking. At least, read the arguments in the US over the gun control debate to get some understanding of the problems that happen when people make laws that are impossible to enforce and put them on the books. All I'm going to say is that if you ignore the enforcement aspect you risk creating a policy that is impossible to implement - and as a result, will not be implemented. That is what I am saying your doing here. David I'm trying to HELP you here. I LIKE the idea of your policy. I don't want to see it put in, in it's current form because there are holes in it large enough to drive a truck through. One of the biggest is that a requester merely writes a business plan saying he's going to need a great gob of addresses in the next year - gets those addresses - then tosses the business plan in the trash. Meanwhile those addresses stagnate unused. And unless policy is written that stalemates people from doing this, they are going to do it during the IPv4 end-game. Your policy makes people make a bunch of promises to obtain addressing but it doesen't hold them to those promises. Well, people have been making promises then breaking them for the last million or so years so I don't see that IPv4 is any different. Maybe if you were a woman you might understand that better. >If they felt additional mechanisms were required to >meet the increased restrictions the Soft Landing proposal imposed, I >would have thought they would have told me in their comments to me on >the previous draft of the policy. They did not How do you know? Did you ask them? What is preventing you from doing so now? Why don't you go ask them right now to look at your policy and tell you if it was implemented, would they be following up a year later with the requestors to make sure they had actually carried out the 50% demonstrated requirement in Phase 0 & 1, the demonstrated 75% requirement in Phase 2 and the demonstrated 90% requirement in Phase 3. And if they were, what would happen if those requirements hadn't been met in that year? >nor do I feel it is >appropriate for me to tell ARIN staff how to do their job. > Then I would suggest you withdraw the proposal because that is EXACTLY what anyone does when they write a proposal. If you do not have the guts to tell someone how to do their job then you certainly shouldn't be writing policy. Do you even have anyone working under you at all in your real job? You might consider that ARIN regards the community as "it's boss" and people in ARIN have said this on this list before. Perhaps ARIN feels it isn't appropriate for them to tell YOU how to do YOUR job - which, as a member of the community - YOUR job is to tell ARIN what to do! >> Your proposals drive up the value of IPv4 and thus undercut the >> financial >> incentive to return unused IPv4. > >Even if there was a financial incentive to return unused IPv4 >addresses (something I think many people would argue) There is - but as we get closer to IPv4 runout, that incentive is getting smaller and smaller. Soon, it will disappear. >, the fact that >IPv4 is nearing exhaustion would do this independent of any attempts >to encourage conservation and promotion of IPv6. > That is true - under CURRENT policy. That has, in fact, already been discussed on this list. You might additionally consider that policymaking should address this problem. Ted From Lee.Howard at stanleyassociates.com Fri Oct 5 14:47:29 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 5 Oct 2007 14:47:29 -0400 Subject: [ppml] FW: [arin-announce] Updated ARIN Fee Schedule In-Reply-To: <4706686C.4020700@rollernet.us> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4073853C5@CL-S-EX-1.stanleyassociates.com> > michael.dillon at bt.com wrote: > >> http://www.arin.net/billing/fee_schedule.html#waivers > > > > Thank you for giving us clear and PREDICTABLE fees and removing the > > uncertainty of the previous waivers that came with an > expiration date. Thanks for the suggestion. Of course, if the membership wants a change in fee structure, something else will happen. > Although it does seem to mean if you want to get IPv6 PI > space and you're an end user like myself, you'd better do it > now before the price goes up next year. I guess that means > I'll be getting mine soon. Seems like a good idea. Lee > > ~Seth > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > From bicknell at ufp.org Fri Oct 5 15:00:52 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 5 Oct 2007 15:00:52 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: <20071005190052.GA47690@ussenterprise.ufp.org> In a message written on Fri, Oct 05, 2007 at 10:32:39AM -0500, Bill Darte wrote: > And do you have specific suggestions on how ARIN might/should proceed to > do this as a means of communication....and on content of the message? > > A guidance forum should proffer 'guidance' if not outright policy > proposals for the community to consider. "Interesting" discussion is a > useful preparation for such. I think this is an area where staff could be more proactive without any policy changes. Specific suggestions: 1) E-mail should be sent to every legacy holder every 1-2 years with a copy of their whois data asking if it is up to date and pointing them to information on how to update the data if it is not correct. 2) ARIN needs a web page explaining what legacy space is, how to update legacy records, and how to return now unused legacy space. A lot of legacy holders probably don't even know they are legacy holders. 3) ARIN should search whois on all new requests for IP space to see if the same group has legacy space. If they do ARIN should ask (not require) if they would like to bring it under the same RSA as their new space. None require policy and could be implemented by ARIN staff. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mike at mathbox.com Fri Oct 5 15:06:26 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 5 Oct 2007 15:06:26 -0400 Subject: [ppml] [arin-discuss] Counsel statement on Legacyassignments?(fwd) In-Reply-To: <8DC42B89-997F-4167-97C7-6117276FF195@delong.com> Message-ID: <200710051506352.SM01552@mikesplace> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, October 05, 2007 1:01 PM > To: Michael Thomas - Mathbox > Subject: Re: [arin-discuss] SPAM-WARN:Re: [ppml] Counsel > statement on Legacyassignments?(fwd) > > > On Oct 5, 2007, at 9:35 AM, Michael Thomas - Mathbox wrote: > > > Owen, > > > > Then ARIN should state the flat fee for processing a block. The > > price per IP > > should be the same. ARIN _does not manufacture_ IP > addresses. There > > is no > > cost savings in _not manufacturing_ a smaller block versus a large > > block. In > > fact it costs ARIN _MORE_ to support the large block, because the > > large > > block requires more RDNS entries. > > > That's simply not true. A /16 requires 1 RDNS entry. A /20 > requires > 16. > A /24 requires 1. > > However, the cost of generating the RDNS entries is not > linear, either. > > The increased costs in a block come more from things like the > churn rate > of SWIPs, the number of SWIPs the block is subdivided into, > and a number > of other ancillary functions which cannot be accurately > measured at the > time of issuance. To ARIN, a /24 to a customer of an ISP is virtually > identical in incremental costs to a /29 to a customer of an ISP. > > You are right that ARIN does not manufacture IPs. However, it does > often > cost ARIN more to process an application for a smaller block than a > larger > one because the smaller applications often come from ISPs whose > personnel > are less familiar with the process and policies and thus > require more > hand-holding > and staff time. Staff time is probably the biggest cost factor in > ARIN IP > allocations. > > I know that for the assignments and allocations I have > requested over > the > last 3 years, I simply cannot compare the process to pulling teeth. > It has > been relatively quick, simple, and painless to me. In fact, my last > assignment > was processed in less than 24 hours from initial paperwork through > billing > and RSA all the way to addresses. > > An ISP who has a total of fewer than 4096 IP addresses pays > $1,250/year. > That works out to approximately $0.31/IP address. > > An ISP who has between 4097 and 8192 IP addresses pays $2,250/year. > That works out to approximately $0.27/IP address. > > From 8193 to 65536 total IP addresses, the cost is $4,500/year. > This is approximately $0.07/IP address. > > However, if we consider it along these lines... Let's assume > that the > fixed costs > for preserving an allocation in the system are on the order of $750/ > year, then, > we see something that looks like this: > > x-Small (<=4096 IPs) = $750 + $500 = $0.12/IP > Small (4097-8192 IPs) = $750 + $1500 = $0.18/IP > Medium (8193-65536 IPs) = $750 + $3750 = $0.05/IP > Large (65537-262144 IPs) = $750 + $8250 = $0.03/IP > > As you can see, $750 is probably the wrong fixed cost number, but, > probably not > too far off. The cost per IP at the low end remains slightly high, > but, the taper at > the higher end is relatively linear. I believe this accurately > reflects the fact that > on x-Small and Small allocations, staff tends to have to spend more > time working > with the ISP on their requests. Medium and bigger > organizations tend > to have > people who manage the IP records as their full-time job and the > become quite > skilled with the ARIN process and the record keeping necessary to > make that > happen smoothly. As such, it costs less for ARIN to deal with them, > and, these > cost savings are reflected in the pricing. > > BTW, before you think I represent some large ISP and have > some gain from > the status quo of pricing, in actual fact, most of my ARIN > transactions are > end-user direct assignments. The majority of them do not > exceed a /20. > > Owen > > > Michael Thomas > > Mathbox > > 978-683-6718 > > 1-877-MATHBOX (Toll Free) > > > >> -----Original Message----- > >> From: Owen DeLong [mailto:owen at delong.com] > >> Sent: Friday, October 05, 2007 11:49 AM > >> To: Michael Thomas - Mathbox > >> Cc: 'Michael Lambert'; arin-discuss at arin.net > >> Subject: Re: [arin-discuss] SPAM-WARN:Re: [ppml] Counsel > >> statement on Legacyassignments?(fwd) > >> > >> > >> On Oct 5, 2007, at 8:35 AM, Michael Thomas - Mathbox wrote: > >> > >>>> We are, with respect to IPv6. So let's not put too much > >> effort into > >>>> solving the pricing problem of legacy assignments in > legacy address > >>>> space. > >>> > >>> Actually everyone _is not_ treated the same for either. > The pricing > >>> structure for both IPV4 and IPV6 indicates that there are > >> first class > >>> citizens, second class citizens, third class, etc. Otherwise, > >>> everone would > >>> pay exactly the same price per IP address. > >> > >> Not true. The pricing structure indicates that IP addresses are a > >> mixture > >> of fixed and incremental costs. This is also common in > >> transactions of > >> wholesale goods. Companies that buy a container of a product get a > >> much better price than companies that purchase a pallet of the > >> product > >> at a time. Companies that buy a pallet receive a better price than > >> companies that buy a case at a time. > >> > >> While ARIN is not selling IP addresses, the reality is that > >> to evaluate > >> an allocation request requires a certain amount of effort > regardless > >> of the size of the request. Beyond that, a certain amount > of effort > >> tends to be roughly proportionate to the size of the > request. Thus, > >> as the size of the address space allocated to a given organization > >> increases, the price per IP appears to decrease, but, that > is because > >> the fixed cost portion of the price is not growing as the > size of the > >> allocations grows. > >> > >> Example (absurd numbers used to keep math easy): > >> > >> Fixed costs to maintain an organization in the system: $1000 > >> > >> Per IP cost to maintain customers allocation records: $1 > >> > >> Customer with a /22: $1000 + $1024 = $2024 > $2024/1024 = 1.9765625 > >> > >> Customer with a /19: $1000 + $8192 = $9192 > $9192/8192 = 1.1220703 > >> > >> Customer with a /16: $1000 + $65536 = $66536 > $66536/65536 = 1.0152588 > >> > >> As you can see, the "apparent price" per IP drops somewhat > >> substantially, > >> but, the reality is that the pricing is quite linear. > >> > >> I have not evaluated the ARIN fee structure to see what > this constant > >> is, and, there are some rounding and smoothing errors introduced > >> into ARIN pricing to simplify the fee structure vs. a > unique price > >> for > >> every customer. However, it does roughly approximate such a > >> pricing structure, and, this is a very common practice for > both sales > >> and service pricing. > >> > >> Owen Owen, For several reasons, I honestly do not believe that your cost allocation is accurate. 1. In another message unrelated to this one, you point out to Jeremy that someone returning for another allocation does not pay separately for each allocation. 2. In the second and subsequent years of an allocation, one still pays the entire fee. If your argument held water, the second and subsequent year fees would be reduced by the application processing cost and would reflect only the maintenance cost. 3. Comparing the time to review an intial /24, /23, /22, /21 allocation to a /14 or larger allocation as taking longer due to the applicant being unfamiliar with the process is questionable. The allocation of a larger block should actually be scrutinized more heavily, because it removes more resources from the available pool. 4. If in fact the total cost is based on application costs and maintenance costs, the fees would reflect that. 5. I just paid my second annual fee. The cost was the same as last year. I did not make any applications this year. 6. The fees are based on the total size of all allocations. You have said so. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From drc at virtualized.org Fri Oct 5 15:17:29 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Oct 2007 12:17:29 -0700 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-SupportRequested In-Reply-To: References: Message-ID: <60AA0A45-20C4-4815-BC1D-4A0D630FAF69@virtualized.org> Ted, On Oct 5, 2007, at 11:37 AM, Ted Mittelstaedt wrote: > I am not arguing that ARIN doesen't have mechanisms in place to > verify both requirements. I am telling you point blank that > nothing in your policy requires ARIN to use those mechanisms to - > continue to make sure- that the requestors do what they say they > are promising, after they get their addressing, and you have > nothing in your policy that specifices penalties if they do not > live up to their promises. I also have nothing in my policy stating ARIN staff should use e-mail to communicate where appropriate. The IPv4 Soft Landing proposal has already been criticized for being overly complex, yet you are suggesting I provide specifics on how ARIN staff should implement verification process even when said verification process is the same as what ARIN is currently using. > In short, you have the audacity to propose modifying requirements > but you have no understanding of how enforcement relates to those > very requirements your trying to propose? I am not proposing to change enforcement mechanisms currently in use at ARIN. I gather you believe the incremental increase in the percentage of utilization of the last allocation implies the need to revise the enforcement mechanisms. I guess I don't see why that would be the case. > ... > Maybe if you were a woman you might understand that better. Um? > ... > If you do not have the guts to tell someone how to do their job > then you > certainly shouldn't be writing policy. > > Do you even have anyone working under you at all in your real job? Who me? I'm just a no life geek with no experience in this field, no management experience, and clearly no understanding of the issues. However despite this, I don't think I'll withdraw the proposal as you so kindly suggest. Thanks for the input. Regards, -drc From michael.dillon at bt.com Fri Oct 5 15:27:47 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 5 Oct 2007 20:27:47 +0100 Subject: [ppml] IPv4 Soft Landing - Discussion andSupport/Non-SupportRequested In-Reply-To: References: Message-ID: > All I'm going to say is that if you ignore the enforcement > aspect you risk creating a policy that is impossible to implement > - and as a result, will not be implemented. That is what I > am saying your doing here. And you can't enforce a policy if you don't know what is going on. This is the reason why I think that the focus should be on things like surveys, reporting, auditing of past allocations. This can make things better all by themselves. For instance a survey that requires the signature of the CFO will raise the profile of IP addressing in all organizations using IP addresses. Reporting could be designed to give a clearer idea of whether or not an organization actually has good management controls for IP addresses internally. And auditing will help organizations find unused addresses in their organization and will also help them improve their controls. In previous companies I have worked at, we stopped giving out new IP addresses and miraculously, we were still able to install new customers. The ops people found a few assignments that were bigger than they needed to be and clawed them back. And there were some disconnections whose addresses had not been returned to the pool. In another company, I remember a program to get rid of the $2 million that was being paid EVERY MONTH for circuits (mainly access circuits) that we no longer used. It seems that cancelling circuits was a really low priority. A significant number of IP addresses are allocated to companies who are large enough to suffer from these types of internal process problems. By helping companies to address these problems in a non-adversarial way, we can accelerate deployment of IPv6, at least to the test-lab and trial stages, and we can find enough IP addresses to give another 6 months to a year after ARIN runs out. > Why don't you go ask them right now to look at your policy > and tell you if it was implemented, would they be following > up a year later with the requestors to make sure they had > actually carried out the 50% demonstrated requirement in > Phase 0 & 1, the demonstrated 75% requirement in Phase 2 and > the demonstrated 90% requirement in Phase 3. You highlight another major problem with this proposal. Implementation of such a complex policy will not be done quickly. If it takes 18 months, then we are already in a different part of the IPv4 exhaustion endgame and this kind of soft-landing simply won't work. --Michael Dillon From mike at mathbox.com Fri Oct 5 15:44:38 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 5 Oct 2007 15:44:38 -0400 Subject: [ppml] SPAM-WARN:Re: IPv4 Soft Landing - DiscussionandSupport/Non-SupportRequested In-Reply-To: Message-ID: <200710051544366.SM02808@mikesplace> Michael, > better all by themselves. For instance a survey that requires the > signature of the CFO will raise the profile of IP addressing in all > organizations using IP addresses. Reporting could be designed CFO? First, there are indivuals involved in this process. Does it say somewhere in the ARIN charter that an individual cannot request and receive IP resources? Second, much of this discussion irks me to no end. Rules, rules, rules, raise more barriers. Between government rules and regulations, forms to file, taxes to report, and _all_ of the proposed ARIN rules, how does an one start a small business in this industry? One would need a staff of tens, just to deal with the paperwork. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From michael.dillon at bt.com Fri Oct 5 16:23:11 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 5 Oct 2007 21:23:11 +0100 Subject: [ppml] SPAM-WARN:Re: IPv4 Soft Landing - DiscussionandSupport/Non-SupportRequested In-Reply-To: <200710051544366.SM02808@mikesplace> References: <200710051544366.SM02808@mikesplace> Message-ID: > > better all by themselves. For instance a survey that requires the > > signature of the CFO will raise the profile of IP addressing in all > > organizations using IP addresses. Reporting could be designed > > CFO? > > First, there are indivuals involved in this process. Does it > say somewhere in the ARIN charter that an individual cannot > request and receive IP resources? Clearly, any requirement for the signature of a CFO would only apply to an organization and not a natural person. In any case, ARIN has done a lot to ensure that IP addresses are available to small organizations and individuals. That's why ARIN policy allows end-sites to apply directly to ARIN for provider independent IPv4 and IPv6 assignments. > Second, much of this discussion irks me to no end. Rules, > rules, rules, raise more barriers. Then why are you on this mailing list? The purpose of the PPML list is to discuss the rules so that is why there is so much discussion of rules. This is as it should be. > Between government rules > and regulations, forms to file, taxes to report, and _all_ of > the proposed ARIN rules, how does an one start a small > business in this industry? One would need a staff of tens, > just to deal with the paperwork. Clearly you have never done this. I have personal experience with a startup getting its first allocation and it took one person a few hours over the course of a week. Most of the work was in documenting the network, something which really should have been done earlier as good business practice. The paperwork is minimal, there is an online course you can follow on the ARIN website, or you can send email (or phone) to the hostmasters for help and advice. If you have a real business and aren't trying to hoard IP addresses just in case you start building a network a year from now, then it is easy. On the other hand, if you have nothing but a plan, i.e. no funding, no premises, no network equipment, then you will find it darn near impossible to get addresses from ARIN. The fundamental reason is that you don't have a technical need for addresses until you are just about to start building your network. That's when you apply for them, maybe two to three weeks in advance. --Michael Dillon From dean at av8.com Fri Oct 5 16:23:04 2007 From: dean at av8.com (Dean Anderson) Date: Fri, 5 Oct 2007 16:23:04 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: On Fri, 5 Oct 2007, John Curran wrote: > > Everyone who received address space received it under the > direction of the IANA (and indirectly, the US government) > prior to their respective RIR being formed. The absence of > a formal contract for such assignments means that there > are many possible interpretations as to the particular rights > and obligations of the parties. Yes, a court determines implied contract terms, sometimes by looking at previous performance of a long period of time. Of course, there is no dispute that a contract exists, just a dispute about the terms of the contract. ARIN is not giving out any free services to people without a contract. > In any case, both legacy holders and ARIN appear to have > obligations to the community. ARIN will certainly do as the > community directs, but one wonders if the legacy community > would like us all to forget their community obligations and > simply pretend that their assignments were done in a total > contractual and community obligation vacuum... And just what, exactly, is ARIN spending on maintaining Legacy records? ARIN already has such a huge surplus that it strains non-profit status to have such profit: ARIN can now operate for something like 7 years with no further income. If the crowd that says IPv4 will end in 3 years is right, we should be expecting __payments__ from ARIN, instead of fees. It seems a bit disingenuous to argue that ARIN needs to reduce costs by doing something to Legacy holders. As space runs out, Legacy holders (and non-legacy holders, too) will find ways to utilize their space more effectively. Market forces will take care of that. There is no credible argument that they aren't utilizing that space pretty well now. Its that simple. The argument that somehow legacy holders aren't meeting their obligations to the community is entirely groundless, baseless, offensive nonsense. The legacy holders made this network; if it weren't for the legacy's you'd be running something from ISO, the ITU, SNA, Decnet, Novell, etc. There would certainly be commercial networks, but it wouldn't be this network. If it weren't for companies like OSF, Nearnet wouldn't have had a backup link to DEC for its flaky Microwave, and John Curran wouldn't be a 'hero'. If it weren't for the OSF, none of you would be running FreeBSD, or OpenBSD; OSF funded the completion of the free BSD 4.4 source, on which all these are based. There's a lot more, and that's just my little corner. Other Legacy's did much more. Personally, I'm getting kind of tired of people bashing legacy's, especially those people who benefited so handsomely from the quiet, unpaid help that Legacies gave them. ARIN has no legal or moral authority to take Legacy space and give it to someone else, merely because those new people are better connected with ARIN staff. Basically, all that is going on is a fabricated pretension of anarchy and a defamation of Legacy holders in order to justify a theft of government assigned rights from legacy holders. However, the question that started this particular thread still hasn't been answered: Has ARIN made a definitive statement on the legal rights of Legacys? Sprunk says yes. I say no. ARIN? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From tedm at ipinc.net Fri Oct 5 17:02:00 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 5 Oct 2007 14:02:00 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: >-----Original Message----- >From: Bill Darte [mailto:BillD at cait.wustl.edu] >Sent: Friday, October 05, 2007 11:30 AM >To: Ted Mittelstaedt; J. R. Westmoreland; William Herrin; John Curran >Cc: ppml at arin.net >Subject: RE: [ppml] Counsel statement on Legacy assignments? > > > >Ted said below.... " The days of revolutionary changes on the Internet >governance are over."....given the ITU and UN's WSIS and WGIG processes, >I can only hope that he is correct.... > > >Bill Darte >ARIN Advisory Council > Bill, that's not a revolution, that's a coup. The UN wants to lop the head off and take it over. They would be horrified if they would have to create an entire governance structure out of scratch. They have no interest in actually grubbing around and doing things like replacing root servers, etc. They just want to be the king that tells the rest of the world how to do things. Google "History of the United Nations" along with "analysis of the effectiveness of the UN from 1950 to the present" to get an idea of what the UN likes to do. If there's not an atomic bomb buried somewhere, the UN isn't going to be of any use at all. Ted From cliffb at cjbsys.bdb.com Fri Oct 5 12:24:39 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Fri, 5 Oct 2007 12:24:39 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? Message-ID: <200710052114.l95LEMDK020056@cjbsys.bdb.com> I originally sent this to John Curran directly but after reading more comments, I thought I'd post it to the group As a legacy holder who has recently joined the PPML list, I can see certain advantages to joining ARIN. I'm just not sure of the best way to keep my network number safe if I join. I have a Class C (/24) and use it actively but don't use 50% of the numbers at the current time. If ARIN were to have an RSA that lets us join, pay our $100.00 per year and leave us alone with our networks, I'd be happy to join. Do I want to pay $100.00 per year? No but it won't break my small consulting firm and it's probably a good thing to do. I tend to be suspicious of groups that say "We're from the governmet and we're here to help you" I have never seen a government/quasi-government group shrink or give up any power/control except at the point of a gun and I expect most legacy users feel the same way. I expect most are willing to take their chances by maintaining their "legacy" status of being grandfathered into ARIN's in-addr-ARPA service unless there is a very strong specific RSA protecting their status quo. This is not to say that if they need more resources, they should have free rein to get them. People keep working around this but all proposals seem to have more stick than carrot. It would seem to me that the ARIN leadership needs to look at the way to get people to join. There seems to be no concensus on the list about how to do this but if ARIN's goal is to get people to join, they need to take a pro-active stance to get it done. The choices seem to be to leave the legacy owners alone and codify their right to ARIN in-addr service or take strong action to make them default members of ARIN by whatever means necessary. This could go to the point of offering free membership and guarantees of safe harbor for existing numbers with limited other benefits (maybe no voting etc) and then allow full membership for a nominal fee. As others have stated, this is a v4 problem only and will disappear when v6 takes over. I think it is to ARIN's advantage as the numbers get tight toward the end to have as many as possible legacy folks under the ARIN/other RIRs umbrella. The problems of hijacked legacy numbers will only cost ARIN more time and money for lawyers and dispute resolution and I think any action that ARIN takes to get legacy users under ARIN should be taken. This would/should/could include free limited membership and any other incentives needed. Is it fair to the newcomers? In some ways probably not but if they have to pay increased fees to cover the costs of dispute resolution because the legacy users have not joined, they won't be happy about that either. I look at this somewhat like Ford's pardon of Nixon. Was it "fair" for Nixon to walk? No but it was better for the country to get past the embarrassment and back to more important things. ARIN's board needs to decide what is really important and take the appropriate action to achieve that. Food for thought Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From mike at mathbox.com Fri Oct 5 17:52:12 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 5 Oct 2007 17:52:12 -0400 Subject: [ppml] IPv4 Soft Landing -DiscussionandSupport/Non-SupportRequested In-Reply-To: Message-ID: <200710051752853.SM00852@mikesplace> > Then why are you on this mailing list? The purpose of the PPML list is > to discuss the rules so that is why there is so much discussion of > rules. This is as it should be. Michael, I am on the list and remain on the list, because: 1. I am a dues paying member. Got the rule book, the card, and every thing needed... 2. It seems obvious to me that the list needs balance and I think it is my duty as a member to provide that balance. 3. I think some of the proposed rules are simply not needed, not going to accomplish the stated task, and not useful except as a barricade 4. I believe that it is the duty of ARIN to manage internet number resources. I believe ARIN gets the authority to do that through common consensus and only through common consensus, because the alternative would be chaos. 5. I do not believe ARIN should be involved in routing policy (meaning aggregation). That does not mean that I think that ARIN should not plan around aggregation. Aggregation is a technical issue not a poilcy issue and should not impact any ARIN policy. 6. I think that I can provide IP services to my customers and save them the hassle of getting and managing their own block of IP addresses. I also firmly believe that anyone, including your customers and mine should be able to request and be allocated an IP block with no more document resources (figuratively) than are required to register a vehicle. I believe that plunking down $100 and identity should get you an IP block. Finding someone to route an IP block is block owner's problem. If owner is willing to pay enough, someone will route it. So Michael, why are you on this list? Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From mike at mathbox.com Fri Oct 5 18:54:03 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 5 Oct 2007 18:54:03 -0400 Subject: [ppml] SPAM-WARN:Re: Counsel statement on Legacy assignments? In-Reply-To: <200710052114.l95LEMDK020056@cjbsys.bdb.com> Message-ID: <200710051854173.SM02832@mikesplace> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Cliff Bedore > Sent: Friday, October 05, 2007 12:25 PM > To: ppml at arin.net > Subject: SPAM-WARN:Re: [ppml] Counsel statement on Legacy assignments? > > I originally sent this to John Curran directly but after reading more > comments, I thought I'd post it to the group > > > As a legacy holder who has recently joined the PPML list, I > can see certain > advantages to joining ARIN. I'm just not sure of the best > way to keep my > network number safe if I join. I have a Class C (/24) and > use it actively but > don't use 50% of the numbers at the current time. If ARIN > were to have an RSA > that lets us join, pay our $100.00 per year and leave us > alone with our > networks, I'd be happy to join. Do I want to pay $100.00 per > year? No but it > won't break my small consulting firm and it's probably a good > thing to do. I > tend to be suspicious of groups that say "We're from the > governmet and we're > here to help you" I have never seen a > government/quasi-government group shrink > or give up any power/control except at the point of a gun and > I expect most > legacy users feel the same way. I expect most are willing to > take their chances > by maintaining their "legacy" status of being grandfathered > into ARIN's > in-addr-ARPA service unless there is a very strong specific > RSA protecting their > status quo. This is not to say that if they need more > resources, they should > have free rein to get them. People keep working around this > but all proposals > seem to have more stick than carrot. > > It would seem to me that the ARIN leadership needs to look at > the way to get > people to join. There seems to be no concensus on the list > about how to do > this but if ARIN's goal is to get people to join, they need to take a > pro-active stance to get it done. The choices seem to be to > leave the legacy > owners alone and codify their right to ARIN in-addr service > or take strong > action to make them default members of ARIN by whatever means > necessary. This > could go to the point of offering free membership and > guarantees of safe harbor > for existing numbers with limited other benefits (maybe no > voting etc) and > then allow full membership for a nominal fee. > > As others have stated, this is a v4 problem only and will > disappear when v6 > takes over. I think it is to ARIN's advantage as the numbers > get tight toward > the end to have as many as possible legacy folks under the > ARIN/other RIRs > umbrella. The problems of hijacked legacy numbers will only > cost ARIN more > time and money for lawyers and dispute resolution and I think > any action that > ARIN takes to get legacy users under ARIN should be taken. This > would/should/could include free limited membership and any > other incentives > needed. Is it fair to the newcomers? In some ways probably > not but if they > have to pay increased fees to cover the costs of dispute > resolution because > the legacy users have not joined, they won't be happy about > that either. > > I look at this somewhat like Ford's pardon of Nixon. Was it > "fair" for Nixon > to walk? No but it was better for the country to get past > the embarrassment > and back to more important things. ARIN's board needs to > decide what is > really important and take the appropriate action to achieve that. > > Food for thought > > Cliff > > > -- > Cliff Bedore > 7403 Radcliffe Dr. College Park MD 20740 > cliffb at cjbsys.bdb.com http://www.bdb.com > Amateur Radio Call Sign W3CB For info on ham radio, > http://www.arrl.org/ Cliff, I would encourage you to continue to particpate. Likely, there are a lot of lurkers on the list. Your particpation may help draw them out. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From drc at virtualized.org Fri Oct 5 19:00:55 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 5 Oct 2007 16:00:55 -0700 Subject: [ppml] SPAM-WARN:Re: IPv4 Soft Landing - DiscussionandSupport/Non-SupportRequested In-Reply-To: <200710051544366.SM02808@mikesplace> References: <200710051544366.SM02808@mikesplace> Message-ID: Michael, On Oct 5, 2007, at 12:44 PM, Michael Thomas - Mathbox wrote: > Second, much of this discussion irks me to no end. Rules, rules, > rules, > raise more barriers. Between government rules and regulations, > forms to > file, taxes to report, and _all_ of the proposed ARIN rules, how > does an one > start a small business in this industry? One would need a staff of > tens, > just to deal with the paperwork. TANSTAAFL. The Internet community long ago decided that the appropriate way to manage address resources was to impose administrative constraints to impose control over the allocation of address space (that is, "to each according to need"). In order to maintain that control in the face of decreased availability, either the administrative burden must increase or some other constraint must be imposed. Since the most obvious constraint is politically infeasible (at least for now), we're left with more red tape. Of course, the other option would be loosen control, but that would almost certainly result in a "run on the bank". Pick your poison... Note that obtaining IPv6 address space is much less administratively constrained. Regards, -drc From randy at psg.com Fri Oct 5 19:54:10 2007 From: randy at psg.com (Randy Bush) Date: Sat, 06 Oct 2007 08:54:10 +0900 Subject: [ppml] IPv4 Soft Landing -DiscussionandSupport/Non-SupportRequested In-Reply-To: <200710051752853.SM00852@mikesplace> References: <200710051752853.SM00852@mikesplace> Message-ID: <4706CEA2.6040106@psg.com> > 5. I do not believe ARIN should be involved in routing policy (meaning > aggregation). That does not mean that I think that ARIN should not plan > around aggregation. Aggregation is a technical issue not a poilcy issue and > should not impact any ARIN policy. brilliant point. so we can stop worrying about ipv4 free pool run-out, not be bothered by irrelevant (to policy) technical issues, and just set policy that we continue assigning from what we now call D/E space and just continue northward, and eventually assign from 256/8 and so forth. right. please get someone in your organization to show you a router. randy From mike at mathbox.com Fri Oct 5 20:09:46 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 5 Oct 2007 20:09:46 -0400 Subject: [ppml] SPAM-WARN:Re: IPv4 Soft Landing -DiscussionandSupport/Non-SupportRequested Message-ID: <20071005200993.SM02724@mikesplace> Sorry! Forgot to reply all. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) > -----Original Message----- > From: Michael Thomas - Mathbox [mailto:mike at mathbox.com] > Sent: Friday, October 05, 2007 8:05 PM > To: 'Randy Bush' > Subject: RE: SPAM-WARN:Re: [ppml] IPv4 Soft Landing > -DiscussionandSupport/Non-SupportRequested > > Randy, > > Yes, aggregation is a technical issue. If you have issues > with aggregation, get a bigger, smarter router. But John Doe > (the living one) should be able to plunk down his $100 and > get an IP block, irrespective aggregation issues. > > Michael Thomas > Mathbox > 978-683-6718 > 1-877-MATHBOX (Toll Free) > > > -----Original Message----- > > From: Randy Bush [mailto:randy at psg.com] > > Sent: Friday, October 05, 2007 7:54 PM > > To: Michael Thomas - Mathbox > > Cc: ppml at arin.net > > Subject: SPAM-WARN:Re: [ppml] IPv4 Soft Landing > > -DiscussionandSupport/Non-SupportRequested > > > > > 5. I do not believe ARIN should be involved in routing > > policy (meaning > > > aggregation). That does not mean that I think that ARIN > > should not plan > > > around aggregation. Aggregation is a technical issue not a > > poilcy issue and > > > should not impact any ARIN policy. > > > > brilliant point. so we can stop worrying about ipv4 free > > pool run-out, > > not be bothered by irrelevant (to policy) technical issues, > > and just set > > policy that we continue assigning from what we now call D/E > space and > > just continue northward, and eventually assign from 256/8 and > > so forth. > > right. > > > > please get someone in your organization to show you a router. > > > > randy > > > > From randy at psg.com Fri Oct 5 20:14:55 2007 From: randy at psg.com (Randy Bush) Date: Sat, 06 Oct 2007 09:14:55 +0900 Subject: [ppml] SPAM-WARN:Re: IPv4 Soft Landing -DiscussionandSupport/Non-SupportRequested In-Reply-To: <20071005200993.SM02724@mikesplace> References: <20071005200993.SM02724@mikesplace> Message-ID: <4706D37F.3050202@psg.com> > Yes, aggregation is a technical issue. If you have issues with > aggregation, get a bigger, smarter router. But John Doe (the living > one) should be able to plunk down his $100 and get an IP block, > irrespective aggregation issues. and pay 10 million dollars for a router that can connect to the internet. and force everybody else to as well. do you perchance work for a giant telephant? randy From mike at mathbox.com Fri Oct 5 20:43:58 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 5 Oct 2007 20:43:58 -0400 Subject: [ppml] SPAM-WARN:Re: IPv4 Soft Landing -DiscussionandSupport/Non-SupportRequested In-Reply-To: <4706D37F.3050202@psg.com> Message-ID: <200710052044794.SM02808@mikesplace> Randy, > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Friday, October 05, 2007 8:15 PM > To: Michael Thomas - Mathbox > Cc: ppml at arin.net > Subject: Re: [ppml] SPAM-WARN:Re: IPv4 Soft Landing > -DiscussionandSupport/Non-SupportRequested > > > Yes, aggregation is a technical issue. If you have issues with > > aggregation, get a bigger, smarter router. But John Doe (the living > > one) should be able to plunk down his $100 and get an IP block, > > irrespective aggregation issues. > > and pay 10 million dollars for a router that can connect to the If you wish to do so. > internet. and force everybody else to as well. do you perchance work > for a giant telephant? What I am is a card carrying member of ARIN, so where I work is irrelevent. > randy ARIN serves the North American region, all 335 million of us. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From jcurran at istaff.org Fri Oct 5 20:58:23 2007 From: jcurran at istaff.org (John Curran) Date: Fri, 5 Oct 2007 20:58:23 -0400 Subject: [ppml] IPv4 Soft Landing -Discussion In-Reply-To: <200710052044794.SM02808@mikesplace> References: <200710052044794.SM02808@mikesplace> Message-ID: At 8:43 PM -0400 10/5/07, Michael Thomas - Mathbox wrote: >But John Doe (the living >one) should be able to plunk down his $100 and get an IP block, >irrespective aggregation issues. That's probably achievable with IPv6, as long as you don't care about being able to route the block. With IPv4, we've got some issues with unconnected networks stranding otherwise badly needed addresses and came up with these great RFC 1918 addresses for private network which can be used for *free*, and won't even conflict with any publicly assigned IPv4 address. In either case, if you want address space that your ISP will route, then you need to ask your ISP for the assignment. Which scenario is your John Doe upset about? /John From mike at mathbox.com Fri Oct 5 23:13:10 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 5 Oct 2007 23:13:10 -0400 Subject: [ppml] IPv4 Soft Landing -Discussion In-Reply-To: Message-ID: <200710052313695.SM02808@mikesplace> John, > -----Original Message----- > From: John Curran [mailto:jcurran at istaff.org] > Sent: Friday, October 05, 2007 8:58 PM > To: Michael Thomas - Mathbox > Cc: ppml at arin.net > Subject: SPAM-WARN:Re: [ppml] IPv4 Soft Landing -Discussion > > At 8:43 PM -0400 10/5/07, Michael Thomas - Mathbox wrote: > >But John Doe (the living > >one) should be able to plunk down his $100 and get an IP block, > >irrespective aggregation issues. > > That's probably achievable with IPv6, as long as you don't care > about being able to route the block. Well, lets examine that one. Lets see $1250 per /48 * 2 ^ 80 = ***** ooops, my calculator just overflowed and dumped its guts on the floor. > With IPv4, we've got some issues with unconnected networks > stranding otherwise badly needed addresses and came up with > these great RFC 1918 addresses for private network which can > be used for *free*, and won't even conflict with any publicly > assigned IPv4 address. Yes, everybody I know uses RFC 1918 space. RFC 1918 space has its place. > > In either case, if you want address space that your ISP will > route, then you need to ask your ISP for the assignment. > > Which scenario is your John Doe upset about? Neither I nor anyone I know is upset. However, I have been lurking on this list for months now. For whatever reason, some of the conversations struck a nerve, but I certainly hope I haven't sounded upset. You could tag me with contentious or argumentative without bothering me. :) I believe that there is still room for small entrepreneurial companies on the internet who could need IP addresses. My position is that many of the rules that people are proposing are simply more barricades to entry. It is much harder to remove a rule than it is to make one. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From peter at boku.net Sat Oct 6 02:24:35 2007 From: peter at boku.net (Peter Eisch) Date: Sat, 06 Oct 2007 01:24:35 -0500 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: Thanks Bill, here's a start: Dear You were issued by the IANA before the creation of ARIN. ARIN has supported your assignment for the past years by providing in-addr.arpa delegation, whois services as well as providing you the means to keep your records current. Please review the current registration. As a steward of the Internet community ARIN would like to ask you for your stewardship back to the community. If you have unused address blocks that you're able and willing to return to the pool for others to potentially use, the Internet community would be appreciative. With the pending IPv4 exhaustion, your contribution back to the community can help extend the open availability for others to use. We understand that this probably means that you'll need to make some changes to your internal routing as well as your upstream providers as well as peers, ARIN would like to extend a courtesy for your effort. We're not asking you to renumber or abandon your assignment but simply apply some common conservation practices as you'd expect others in the community to practice. What is the incentive? Here again is where you can help. ARIN members have been trying to identify what could be offered to your organization. We've been unable to get a good grasp on what a suitable incentive would be and we'd like your ideas. Things that have been discussed in the past include discounted or free membership to ARIN as well as deeply discounted pricing for access to IPv6 addresses. Might you have similar or other ideas? We've created a [mailing list] just for legacy holders. We'll specifically discuss ideas surrounding how to approach this process as well as the opportunity to provide incentives through this process. We've also created a [legacy holder's risks] page. ARINs goal through this process isn't to inconvenience your and your organization in any way. ARIN is looking to encourage your continued stewardship. mailing list: http://www.arin.net/lists/legacy legacy risks: http://www.arin.net/risks Thank you, xxxx xxxxx On 10/5/07 10:32 AM, "Bill Darte" wrote: > And do you have specific suggestions on how ARIN might/should proceed to > do this as a means of communication....and on content of the message? > > A guidance forum should proffer 'guidance' if not outright policy > proposals for the community to consider. "Interesting" discussion is a > useful preparation for such. > > Thanks for you discussion. > > bd > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Peter Eisch > Sent: Friday, October 05, 2007 10:07 AM > To: ppml at arin.net > Subject: Re: [ppml] Counsel statement on Legacy assignments? > > > After months of reading "interesting" email about legacy holders, what > direct communication has happened to these organizations to bring them > into > the fold? Until they are here (or a party to another less general list) > the > discussion continues to be engaged by only the mostly non-affected > elite. > > In this forum the discussions are typically emotional, theoretical and > rarely based on facts. This is typical of a guidance list. It's good > to > get ideas bounced around and get the input from a wide audience. > > Could some effort be spent on getting the attention of the legacy > holders > and establish a communication channel with them? You have maybe a dozen > [individual] readers here with legacy holdings. I'll suspect that we're > not > the majority and we surely can't speak for the balance. > > Until they're present and a part of the process this discussion > continues to > be little more than "us" and "them" and clearly without community > perspective. > > peter > > On 10/5/07 9:26 AM, "Bill Darte" wrote: > >> Seems to me that since there exists a vocal segment of the community >> that wants ARIN to engage the legacy holders and to encourage or > impose >> upon them some obligations or limit their 'free' services, it is wise >> that ARIN consider what authority exists...should the broader > community >> come to believe as the vocal segment. >> >> Discussion of this authority and options to BOTH encourage or > impose... >> in an open and straightforward manner is the right thing to do. IMO. >> >> If the legacy community feels threatened by such, then I encourage all >> to better understand the process in which such discussion is taking >> place and the means that exists to influence those discussions and >> community perspective...by engaging the community at large and ARIN >> through participation. >> >> Bill Darte >> ARIN Advisory Council >> >> >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf > Of >> William Herrin >> Sent: Friday, October 05, 2007 8:46 AM >> To: John Curran >> Cc: ppml at arin.net >> Subject: Re: [ppml] Counsel statement on Legacy assignments? >> >> On 10/5/07, John Curran wrote: >>> In any case, both legacy holders and ARIN appear to have >>> obligations to the community. ARIN will certainly do as the >>> community directs, but one wonders if the legacy community >>> would like us all to forget their community obligations and >>> simply pretend that their assignments were done in a total >>> contractual and community obligation vacuum... >> >> John, >> >> Don't take me wrong; I think the current ARIN process is a sound one >> and I think it would be healthy to bring as many folks into the fold >> as possible. I'm particularly fond of proposals which encourage IPv4 >> assignments to segue into IPv6 assingments with both coming under the >> ARIN RSA in the process. >> >> I don't think the "stick" approach is healthy. Even just having >> discussions about discontinuing folks' RDNS creates a comment record >> where any legacy registrant lurking about must think we're all a bunch >> of a-holes. How that activity and perception furthers ARIN's mission >> completely escapes me. >> >> Regards, >> Bill Herrin >> > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. > From mike at mathbox.com Sat Oct 6 06:45:18 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Sat, 6 Oct 2007 06:45:18 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses Message-ID: <200710060645430.SM02832@mikesplace> On the ARIN web site at: http://www.arin.net/billing/fee_schedule.html#ipv4_alloc The price for an X-large allocation (blocks larger than /14, I.E. a /13 qualifies) is $18,000.00. That is the top fee for IP addresses. If the same ARIN subscriber needs more IP addresses, up to and including another /13 or more, there is no additional charge. No additonal charge! Free! I have two issues with this fee structure. First, lets price that /13 at the /22 rate. The /22 rate is $1.22 per IP address ($1250 / 1024 = $1.22). For those who do not know how many IP addresses there are in a /13 (I didn't without calculating it), there are 524,288. Now $1.22 * 524288 = $639631.36. No wonder small allocation subscribers think IP pricing is unfair. Should ARIN decrease the smaller allocation rates or increase the larger allocation rates? Second, while there have been proposals to "charge legacy holders a fee", "increase the allocation fees to promote conservation", and , "increase the IPV4 allocation fees to push subscribers to IPV6", ARIN is willing to provide any IPV4 address block over the initial /13 for free. Is this good stewardship? Do you think that fee schedule promotes conservation? I do not. Before we ask others to conserve more and pay more, lets cleanup our own act. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From arin-contact at dirtside.com Sat Oct 6 09:58:08 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 6 Oct 2007 09:58:08 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: <3c3e3fca0710060658m74538410jbbde6371090f19c8@mail.gmail.com> On 10/6/07, Peter Eisch wrote: > "As a steward of the Internet community ARIN would like to ask you for your > stewardship back to the community. If you have unused address blocks that > you're able and willing to return to the pool for others to potentially use, > the Internet community would be appreciative. With the pending IPv4 > exhaustion, your contribution back to the community can help extend the open > availability for others to use." Hi Peter, The problem with a letter like this is that while this is the message we want to convey, its intellectually dishonest and we will get called on it. Let me explain what I mean. If you release address space back to ARIN's pool, there is somewhere north of an 80% chance that next year it appears within an allocation to one of a few hundred megacorps that has a voracious appetite for IP addresses. ARIN's process is very top-heavy in that respect; at the rate it makes single /20 and longer allocations it could continue for decades. Its the big allocations to folks who already hold a lot of addresses which are expected to exhaust the free pool in three years. The odds favor your old addresses showing up at Verizon, AT&T or another like them. Worse, under ARIN's price structure those guys don't even have to pay more for it... Just the xxlarge annual fee. Megacorps being what they are, you or someone you know has in the past been screwed or treated like a peon by the one who ended up with your old IP addresses. That's a pretty foul outcome for someone who has generously returned addresses. I'd go so far as to call it a betrayal of trust: It would be like volunteering to pick up trash on a highway like you see the signs for, only to have the county come in and turn it into a toll road. Then, when we go back for round two, we'll have zero credibility. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Sat Oct 6 10:11:23 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 6 Oct 2007 10:11:23 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <200710060645430.SM02832@mikesplace> References: <200710060645430.SM02832@mikesplace> Message-ID: <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> On 10/6/07, Michael Thomas - Mathbox wrote: > Is this good > stewardship? Do you think that fee schedule promotes conservation? I do not. > Before we ask others to conserve more and pay more, lets cleanup our own > act. Michael, I concur. ARIN's price structure is reasonable for an asset of which there is a plentiful supply. Its based on the ARIN staff workload necessary to process the paperwork, provide servers and handle record keeping. These functions do not cost excessively more for large allocations than for small ones. The price structure is entirely inappropriate for a rapidly diminishing asset like IPv4 free pool. Where conservation is desired, large allocations per year should made to cost more per address than small ones. That having been said, this discussion is moot. The xlarge entities have the votes to keep the favorable fee structure. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jcurran at istaff.org Sat Oct 6 10:31:11 2007 From: jcurran at istaff.org (John Curran) Date: Sat, 6 Oct 2007 10:31:11 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> Message-ID: At 10:11 AM -0400 10/6/07, William Herrin wrote: >That having been said, this discussion is moot. The xlarge entities >have the votes to keep the favorable fee structure. I have no particular viewpoint on the matter of whether our fee schedule needs to be changed, but want to be clear on the ability to change the fees. The ARIN Board sets the fee schedule, and it's been generally based on the feedback we receive at the member meetings. There is no formal member votes on these matters, although we have on occasion asked for a show of hands as a gauge of opinion in the room. ARIN Board votes on financial matters are done by 2/3 majority, and to my knowledge there's been no particular representation of any category of members, i.e. the trustees are to consider the needs of all of members and the community at large in weighing their decision. The current list of trustee members of the ARIN Board is here: /John John Curran Chair, ARIN Board of Trustees From arin-contact at dirtside.com Sat Oct 6 11:15:06 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 6 Oct 2007 11:15:06 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> Message-ID: <3c3e3fca0710060815m9b8273cq3889f4e87c11cd7a@mail.gmail.com> On 10/6/07, John Curran wrote: > At 10:11 AM -0400 10/6/07, William Herrin wrote: > >That having been said, this discussion is moot. The xlarge entities > >have the votes to keep the favorable fee structure. > > I have no particular viewpoint on the matter of whether our > fee schedule needs to be changed, but want to be clear on > the ability to change the fees. The ARIN Board sets the fee > schedule, and it's been generally based on the feedback we > receive at the member meetings. There is no formal member > votes on these matters, although we have on occasion asked > for a show of hands as a gauge of opinion in the room. John, Politics 101. You were elected by convincing the people who show up and vote that you'll give them what they want. The board, including yourself, was elected by the members based on the members' belief that you and the rest of the board would act in a "fair and appropriate" manner. In context, "fair and appropriate" means "not unfavorable to us." Such is the character of representative democracy and the board has done a generally good job of delivering what the voting members desire. Should some situation come about where the board implements a conservation-driven fee structure, it wouldn't be 5 days before a policy proposal showed up on this list directing ARIN to structure its fees in direct proportion to the relevant operating costs. Nor would that proposal have a hard time winning passage. Nor would the board member who pushed the original fee change win reelection. This is the political reality. The x-large members have the votes. Don't believe it? Try to adjust the fees to support conservation and see what happens. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jcurran at istaff.org Sat Oct 6 11:44:16 2007 From: jcurran at istaff.org (John Curran) Date: Sat, 6 Oct 2007 11:44:16 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710060815m9b8273cq3889f4e87c11cd7a@mail.gmail.com> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <3c3e3fca0710060815m9b8273cq3889f4e87c11cd7a@mail.gmail.com> Message-ID: At 11:15 AM -0400 10/6/07, William Herrin wrote: >Politics 101. You were elected by convincing the people who show up >and vote that you'll give them what they want. The board, including >yourself, was elected by the members based on the members' belief that >you and the rest of the board would act in a "fair and appropriate" >manner. In context, "fair and appropriate" means "not unfavorable to >us." Such is the character of representative democracy and the board >has done a generally good job of delivering what the voting members >desire. Thanks! >Should some situation come about where the board implements a >conservation-driven fee structure, it wouldn't be 5 days before a >policy proposal showed up on this list directing ARIN to structure its >fees in direct proportion to the relevant operating costs. Nor would >that proposal have a hard time winning passage. Nor would the board >member who pushed the original fee change win reelection. This is the >political reality. The x-large members have the votes. In some RIR's, I believe that there are voting structures which are not flat (i.e. not 1 member, 1 vote) but instead based on address space held or member size. In ARiN's region, we have more than 2800 members, and xsmall through medium far, far outnumber large + xlarge (I'll get the exact breakdown posted as soon as possible) Given our 1 member, 1 vote structure, the x-large members really can't control the votes. I'm not denying that there would be fallout from a restructuring of fees, but that is true of any major change to the fee schedule. This should not prevent members from suggesting fee structures that they feel is fair and appropriate to all. /John Chair, ARIN p.s. I'd recommend moving this from PPML to arin-discuss, since we've left the topic of policy and moved to ARIN's voting structure. From bicknell at ufp.org Sat Oct 6 12:00:15 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 6 Oct 2007 12:00:15 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> Message-ID: <20071006160015.GB41201@ussenterprise.ufp.org> In a message written on Sat, Oct 06, 2007 at 10:11:23AM -0400, William Herrin wrote: > The price structure is entirely inappropriate for a rapidly > diminishing asset like IPv4 free pool. Where conservation is desired, > large allocations per year should made to cost more per address than > small ones. Leaving aside the issue of is it good or not, I'm not sure ARIN as a non-profit is in a position to implement a "sin tax" on IP addresses to promote conservation. Several people already have stated they feel ARIN has too much of a surplus; if we implemented a fair sin tax of say $10 per IP per year, where would all that money go and what would it be used to do? > That having been said, this discussion is moot. The xlarge entities > have the votes to keep the favorable fee structure. I believe you're wrong on two levels. First, John has already answered that fees are set by the board, not by any member votes. If you wish to read about the board members, their bios are at http://www.arin.net/about_us/bot.html. Not a single one works for a "megacorp". If you were right about the megacorps they would have already stacked the board with puppets. Second, you retorted in a message that the megacorps would simply respond with policy proposals to fix the situation. As an AC member I can tell you that the AC passes policy on based on community consensus, and the board serves as a double check that we did just that. While there is no hard and fast rule for consensus, I can say that in most of the cases it requires the majority of the community to support the notation. Note, policy is NOT ARIN members, but the community, e.g. anyone who wants to show up and express an opinion. The 5, or 10, or 20 "megacorps" are quickly overruled by the hundreds if not thousands of people who represent small companies who take an opposite view. So for policy matters, everyone (including the general public) gets one "vote" if you want to think of that that way. We don't vote, the AC judges consensus; but close enough for the purposes of this message. For Board elections, all ARIN members get two votes each. You alone as a member can completely counteract Verizon's two votes. It's very hard for me to see how megacorps have any advantage. Consolidation is not helping, where AT&T, Pacbell, SBC, and Bell South used to have a total of 8 votes in elections they now have 2. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From owen at delong.com Sat Oct 6 12:06:29 2007 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Oct 2007 09:06:29 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <200710060645430.SM02832@mikesplace> References: <200710060645430.SM02832@mikesplace> Message-ID: <9F822965-E110-4653-A258-1CAB194FC293@delong.com> On Oct 6, 2007, at 3:45 AM, Michael Thomas - Mathbox wrote: > On the ARIN web site at: > http://www.arin.net/billing/fee_schedule.html#ipv4_alloc > > The price for an X-large allocation (blocks larger than /14, I.E. > a /13 > qualifies) is $18,000.00. That is the top fee for IP addresses. If > the same > ARIN subscriber needs more IP addresses, up to and including > another /13 or > more, there is no additional charge. No additonal charge! Free! I > have two > issues with this fee structure. > These fees are not for IP addresses. The fees are for ARIN Subscriber Membership. The total number of IP addresses you hold is used as an abstraction for classifying your membership. For someone who holds a /20, the next /20 is technically free, too. Regardless of the increments in which it comes. For someone who holds a /19+, it doesn't cost any more until they need more than a /16. This is standard tiered pricing and it's a way to simplify the pricing structure so that the cost of computing a bill does not increase the amount of money that needs to be collected. Owen From owen at delong.com Sat Oct 6 12:11:32 2007 From: owen at delong.com (Owen DeLong) Date: Sat, 6 Oct 2007 09:11:32 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> Message-ID: > > That having been said, this discussion is moot. The xlarge entities > have the votes to keep the favorable fee structure. This is patently false for at least the following reasons: 1. Fee structure is determined by the BoT with input from the ARIN membership. 2. x-large entities are NOT the majority of ARIN members and do not get any more votes than x-small entities per Org. If a sufficiently large portion of the membership supported a change to the fee structure, I am quite sure it could be accomplished. I am not sure that you could gain the support of enough of the x-small, small, medium and large organizations as well as the non-subscriber members to get such a fee structure through, but, it is quite possible to make such changes with zero support from the x-large entities if you can convince the rest of the membership that it is a good idea. Owen From BillD at cait.wustl.edu Sat Oct 6 13:06:13 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Sat, 6 Oct 2007 12:06:13 -0500 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <20071006160015.GB41201@ussenterprise.ufp.org> References: <200710060645430.SM02832@mikesplace><3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> Message-ID: Since I believe as you do that a 'sin tax' isn't likely to fly.... for a variety of reasons. I do think it is reasonable and in line with the mission of ARIN to execute fees that are in addition to the existing fees that would go to support a robust education program aimed at objectives like, legacy recovery, IPv6 understanding/adoption, etc. Should an organization be compelled to acquire or demonstrate use of a protocol that is NOT part of their business plan in order to acquire a protocol address that IS and for which ARIN has a duty to provide?.... I don't see anything in the mission statement of ARIN that makes it clear this is appropriate. Bill Darte CAIT - Washington University in St. Louis -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Leo Bicknell Sent: Saturday, October 06, 2007 11:00 AM To: William Herrin Cc: ppml at arin.net Subject: Re: [ppml] ARIN IP conservation and FREE IP Addresses In a message written on Sat, Oct 06, 2007 at 10:11:23AM -0400, William Herrin wrote: > The price structure is entirely inappropriate for a rapidly > diminishing asset like IPv4 free pool. Where conservation is desired, > large allocations per year should made to cost more per address than > small ones. Leaving aside the issue of is it good or not, I'm not sure ARIN as a non-profit is in a position to implement a "sin tax" on IP addresses to promote conservation. Several people already have stated they feel ARIN has too much of a surplus; if we implemented a fair sin tax of say $10 per IP per year, where would all that money go and what would it be used to do? > That having been said, this discussion is moot. The xlarge entities > have the votes to keep the favorable fee structure. I believe you're wrong on two levels. First, John has already answered that fees are set by the board, not by any member votes. If you wish to read about the board members, their bios are at http://www.arin.net/about_us/bot.html. Not a single one works for a "megacorp". If you were right about the megacorps they would have already stacked the board with puppets. Second, you retorted in a message that the megacorps would simply respond with policy proposals to fix the situation. As an AC member I can tell you that the AC passes policy on based on community consensus, and the board serves as a double check that we did just that. While there is no hard and fast rule for consensus, I can say that in most of the cases it requires the majority of the community to support the notation. Note, policy is NOT ARIN members, but the community, e.g. anyone who wants to show up and express an opinion. The 5, or 10, or 20 "megacorps" are quickly overruled by the hundreds if not thousands of people who represent small companies who take an opposite view. So for policy matters, everyone (including the general public) gets one "vote" if you want to think of that that way. We don't vote, the AC judges consensus; but close enough for the purposes of this message. For Board elections, all ARIN members get two votes each. You alone as a member can completely counteract Verizon's two votes. It's very hard for me to see how megacorps have any advantage. Consolidation is not helping, where AT&T, Pacbell, SBC, and Bell South used to have a total of 8 votes in elections they now have 2. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org From mike at mathbox.com Sat Oct 6 13:37:32 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Sat, 6 Oct 2007 13:37:32 -0400 Subject: [ppml] SPAM-WARN:Re: ARIN IP conservation and FREE IP Addresses In-Reply-To: <9F822965-E110-4653-A258-1CAB194FC293@delong.com> Message-ID: <200710061337244.SM01552@mikesplace> Owen, > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Saturday, October 06, 2007 12:06 PM > To: Michael Thomas - Mathbox > Cc: ppml at arin.net > Subject: SPAM-WARN:Re: [ppml] ARIN IP conservation and FREE > IP Addresses > > > On Oct 6, 2007, at 3:45 AM, Michael Thomas - Mathbox wrote: > > > On the ARIN web site at: > > http://www.arin.net/billing/fee_schedule.html#ipv4_alloc > > > > The price for an X-large allocation (blocks larger than /14, I.E. > > a /13 > > qualifies) is $18,000.00. That is the top fee for IP addresses. If > > the same > > ARIN subscriber needs more IP addresses, up to and including > > another /13 or > > more, there is no additional charge. No additonal charge! Free! I > > have two > > issues with this fee structure. > > > These fees are not for IP addresses. The fees are for ARIN > Subscriber Membership. > The total number of IP addresses you hold is used as an abstraction > for classifying > your membership. > > For someone who holds a /20, the next /20 is technically free, too. > Regardless of > the increments in which it comes. For someone who holds a /19+, it > doesn't cost > any more until they need more than a /16. True. But there is also a tier above them. So, until the subscriber reaches the /13 level, there is always increased costs. Once you reach the /13 level, there is no additional cost. > This is standard tiered pricing and it's a way to simplify the > pricing structure so that > the cost of computing a bill does not increase the amount of money > that needs > to be collected. I am certainly not suggesting that ARIN should not have tiered pricing. It does simplify billing. However, there is a large difference between: 1 IP $.10 10 IP $1.00 100 IP $10.00 And 1 IP $1.00 10 IP $4.00 100 IP $10.00 > > Owen You confuse tiered pricing with tiered discounts. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From arin-contact at dirtside.com Sat Oct 6 15:06:07 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 6 Oct 2007 15:06:07 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <3c3e3fca0710060815m9b8273cq3889f4e87c11cd7a@mail.gmail.com> Message-ID: <3c3e3fca0710061206y1bf404f2q9ac8ee1ed0fdb320@mail.gmail.com> Its officially the weekend, so I'm throwing some notions out there and letting things fall where they may. On 10/6/07, John Curran wrote: > In ARiN's region, we have more than 2800 members, and xsmall > through medium far, far outnumber large + xlarge (I'll get the > exact breakdown posted as soon as possible) Given our 1 member, > 1 vote structure, the x-large members really can't control the votes. John, That's something you should fix, by the way. You have 600 maybe 700 members who actually vote. Anyone can be a member: $500 buys voting membership at 2 semi-annual meetings. IPv6 deployment is not on track. There will be a gap, probably a large one, between free pool exhaustion and sufficiently ubiquitous IPv6 deployment. Given the amount of money in the industry today, fortunes will be made and lost on the post-exhaustion availability of IPv4 addresses. 100 votes is 15%. That's more than the swing on most proposals. It only costs $50k. On 10/6/07, Leo Bicknell wrote: > to promote conservation. Several people already have stated they > feel ARIN has too much of a surplus; if we implemented a fair sin > tax of say $10 per IP per year, where would all that money go and > what would it be used to do? Leo, Get ready to buy back the legacy addresses. That's what we all want after all: more addresses for as long as possible after the IANA free pool is gone. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Sat Oct 6 15:23:36 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 6 Oct 2007 15:23:36 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <20071006160015.GB41201@ussenterprise.ufp.org> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> Message-ID: <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> On 10/6/07, Leo Bicknell wrote: > In a message written on Sat, Oct 06, 2007 at 10:11:23AM -0400, William Herrin wrote: > > The price structure is entirely inappropriate for a rapidly > > diminishing asset like IPv4 free pool. Where conservation is desired, > > large allocations per year should made to cost more per address than > > small ones. > > Leaving aside the issue of is it good or not, I'm not sure ARIN as > a non-profit is in a position to implement a "sin tax" on IP addresses > to promote conservation. Leo, The "Local Internet Registries" do. If you're a SOHO or hobbyist customer its not unusual to pay anywhere from $10 to $60 per IP address per year for as much as 32+1 static IP addresses. Why should a Regional Internet Registry, one step up the food chain, not charge the LIR's $1 per IP address per year? Fair's fair, right? They charge the end users per-address so why shouldn't ARIN charge them the same way? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Sat Oct 6 16:24:53 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 6 Oct 2007 16:24:53 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> <3c3e3fca0710061206y1bf404f2q9ac8ee1ed0fdb320@mail.gmail.com> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <3c3e3fca0710060815m9b8273cq3889f4e87c11cd7a@mail.gmail.com> <3c3e3fca0710061206y1bf404f2q9ac8ee1ed0fdb320@mail.gmail.com> Message-ID: <20071006202453.GB63849@ussenterprise.ufp.org> In a message written on Sat, Oct 06, 2007 at 03:06:07PM -0400, William Herrin wrote: > 100 votes is 15%. That's more than the swing on most proposals. It > only costs $50k. Policy proposals are never voted on. The AC decides that there is community consensus. The cost of an attempt to sway the vote in such a way is virtually zero, it simply requires people to post their support on PPML. I believe, although someone may correct me if I'm wrong, the only thing we ever vote on is to elect AC members and BoT members. Those elections are the only thing you could attempt to buy in the manor you suggest. In a message written on Sat, Oct 06, 2007 at 03:23:36PM -0400, William Herrin wrote: > The "Local Internet Registries" do. If you're a SOHO or hobbyist > customer its not unusual to pay anywhere from $10 to $60 per IP > address per year for as much as 32+1 static IP addresses. > > Why should a Regional Internet Registry, one step up the food chain, > not charge the LIR's $1 per IP address per year? Fair's fair, right? > They charge the end users per-address so why shouldn't ARIN charge > them the same way? My point is those are for profit companies, and they charge what the market will bear. That's in stark contrast to ARIN, which is a non-profit who's charter is specifically to be a stweard of the address space. Plus, ARIN charges more for larger IP blocks due to the administrative overhead, why shouldn't for profit companies do the same for users? It does take more engineering effort to manage static IP's than to just throw another subnet into a DHCP server. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From stephen at sprunk.org Sat Oct 6 16:20:02 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 6 Oct 2007 15:20:02 -0500 Subject: [ppml] Counsel statement on Legacy assignments? References: <018f01c806c4$ad11ca00$363816ac@atlanta.polycom.com> <47057EBB.6010609@psg.com> Message-ID: <013f01c80857$8cc3ac70$6401a8c0@atlanta.polycom.com> Thus spake "Randy Bush" >> "MR. RYAN: I've thought a little bit about what a stick might look >> like here. So for example, it's very clear to me that denial of >> service by ARIN is legally permitted. In other words, I don't >> believe we, as the non-profit trying to carry out the community's >> wishes, have a duty to provide free services for legacy address >> holders. And the denial of those free services to legacy address >> holders pursuant to their lack of agreement is perfectly permitted, >> in my judgment, as a matter of law." > > if arin does not want to carry out its commitment to the community > and to the USG when it was chartered [0], i am sure the > community can find an organization more interested in public > service. probably such a change would be good for the > community; at least this puff and bluff would cease. In my message that Dean responded to, please note the relevant part: "it doesn't appear that ARIN has any legal obligation to maintain registry services for legacy assignments, though it does have a moral one since that was a condition of ARIN's creation." I believe we are _morally_ obligated, regardless of our (lack of) legal obligation, to continue to provide registry services for legacy assignments that are still in use. If a legacy assignment is not still in use (e.g. because the holder forgot about it, went bankrupt, etc.), I see no moral or legal obligation to continue providing services and we should reclaim it. I think this position is clear from 2007-14. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Sat Oct 6 16:07:53 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 6 Oct 2007 15:07:53 -0500 Subject: [ppml] ARIN IP conservation and FREE IP Addresses References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> Message-ID: <013e01c80857$8b7ab1b0$6401a8c0@atlanta.polycom.com> Thus spake "William Herrin" > The price structure is entirely inappropriate for a rapidly > diminishing asset like IPv4 free pool. Where conservation is > desired, large allocations per year should made to cost more > per address than small ones. I'd be satisfied with a constant per-address fee structure. If nothing else, that's a good first step vs. our current fee structure of giving additional addresses free to organizations who waste the most. > That having been said, this discussion is moot. The xlarge entities > have the votes to keep the favorable fee structure. There are 80 X-Large members, out of ~2800 members. Since it's one vote per member, they obviously do not "have the votes" to do anything. However, as John pointed out, members don't actually vote on fees; that's done by a supermajority of the Board. If members are unhappy with the current fee structure, they should consider that in the next round of Board elections. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From jhg at omsys.com Sat Oct 6 16:52:45 2007 From: jhg at omsys.com (Jeremy H. Griffith) Date: Sat, 06 Oct 2007 13:52:45 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> Message-ID: On Sat, 6 Oct 2007 15:23:36 -0400, "William Herrin" wrote: >The "Local Internet Registries" do. If you're a SOHO or hobbyist >customer its not unusual to pay anywhere from $10 to $60 per IP >address per year for as much as 32+1 static IP addresses. > >Why should a Regional Internet Registry, one step up the food chain, >not charge the LIR's $1 per IP address per year? Fair's fair, right? >They charge the end users per-address so why shouldn't ARIN charge >them the same way? +1 You're onto something. All the blather about deadbeat legacy holders is pure misdirection. The real issue is with the large holders, under RSA or not, who have *no* reason to use their assignments efficiently as long as the incremental cost of new IPs is zero. In fact, with v4 exhaustion on the horizon, it's better for them to remain inefficient to the end of the free pool, since that will give them breathing room at that point. This isn't a moral judgement, it's simple economics. As long as an organization is profit-making, it *must* act that way, or face shareholder suits if it acts to protect community interests instead of its own monetary interests. That's just how the system works. So, to change this, we have to work the system. And that means, as this thread has made blindingly clear, making every IP cost money, per year. No free rides for the big guys. The fees have nothing to do with ARIN's costs, and everything to do with the public policy needed to keep the Net functional. So the fees have to be enough, at the top end, to inspire more efficient use. Discounts can be used either way. Traditionally, larger purchases earn bigger discounts. But in California, for energy (and water) purchase, it's just the opposite. The more power we use, the more the rate goes *up*. This is policy aimed at conservation and efficiency in action. For example, this is what I pay for water (plus a basic meter fee of about $25/month): A unit of water is 100 cubic feet, which is 748 gallons. Prices per unit are as follows: Units per unit Consumption Charge 0 - 10 $ 1.95 11-40 $ 2.55 41 - 100 $ 3.05 101 - 200 $ 3.30 201 plus $ 3.60 Applying this idea to ARIN, what if we had a basic fee for any IP addresses of $25/year, which would include the first 256 addresses (such as a legacy Class C, /24). Then beyond that: /22 $ 0.20 /20 $ 0.35 /18 $ 0.50 /16 $ 0.75 /14 $ 1.00 /12 $ 1.50 /10 $ 2.00 /8 $ 3.00 more $ 5.00 which is *still* at the very top less than *half* what the LIRs charge at their *lowest* rate for a single static IP. A 100% markup would seem quite sufficient. This would be fairer *to the community* than the current scale, and would certainly promote fast action on IPv6... especially with the fee waivers already in effect for v6. Anybody want to draft a formal proposal? ;-) --JHG From stephen at sprunk.org Sat Oct 6 16:31:39 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 6 Oct 2007 15:31:39 -0500 Subject: [ppml] Counsel statement on Legacy assignments? References: Message-ID: <023701c8085b$d2c79340$6401a8c0@atlanta.polycom.com> Thus spake "Dean Anderson" > On Fri, 5 Oct 2007, John Curran wrote: >> >> Everyone who received address space received it under the >> direction of the IANA (and indirectly, the US government) >> prior to their respective RIR being formed. The absence of >> a formal contract for such assignments means that there >> are many possible interpretations as to the particular rights >> and obligations of the parties. > > Yes, a court determines implied contract terms, sometimes by > looking at previous performance of a long period of time. First, the court must assess whether a contract exists at all. > Of course, there is no dispute that a contract exists, just a > dispute about the terms of the contract. I dispute that a contract exists. AIUI, a contract takes the basic form of one party agreeing to do (or not do) something in return for consideration from the other party. The legacy assignments did not include any form of consideration back to IANA, SRI, NSI, etc. and therefore were not contracts. At most, one could claim they were gifts, but since no tangible property changed hands, that's also a difficult position to support. > ARIN is not giving out any free services to people without a > contract. Yes, actually, that's exactly what ARIN is doing. Counsel has said ARIN has no legal (i.e. contractual) obligation to provide free services to legacy holders as it's doing today. If there were a contract, he couldn't have made that statement. >> In any case, both legacy holders and ARIN appear to have >> obligations to the community. ARIN will certainly do as the >> community directs, but one wonders if the legacy community >> would like us all to forget their community obligations and >> simply pretend that their assignments were done in a total >> contractual and community obligation vacuum... > > And just what, exactly, is ARIN spending on maintaining Legacy > records? Very little, given about half of the records haven't even been updated in ten-plus years. That's not the point. > ARIN already has such a huge surplus that it strains non-profit > status to have such profit: ARIN can now operate for something > like 7 years with no further income. If the crowd that says IPv4 > will end in 3 years is right, we should be expecting __payments__ > from ARIN, instead of fees. It seems a bit disingenuous to > argue that ARIN needs to reduce costs by doing something to > Legacy holders. I don't see anyone claiming we need _money_ (i.e. something to offset costs) from legacy holders. What I do see are lots of claims that we need their resources back if they're not using them efficiently (or at all). > ARIN has no legal or moral authority to take Legacy space and > give it to someone else, merely because those new people are > better connected with ARIN staff. It has nothing to do with being "connected". Who gets new or reissued space is determined by the NRPM, the contents of which are determined by the community. > Basically, all that is going on is a fabricated pretension of anarchy > and a defamation of Legacy holders in order to justify a theft of > government assigned rights from legacy holders. I see no defamation being done by anyone other than you. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Sat Oct 6 16:35:49 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 6 Oct 2007 15:35:49 -0500 Subject: [ppml] ARIN IP conservation and FREE IP Addresses References: <200710060645430.SM02832@mikesplace> <9F822965-E110-4653-A258-1CAB194FC293@delong.com> Message-ID: <023a01c8085b$d3971840$6401a8c0@atlanta.polycom.com> Thus spake "Owen DeLong" > These fees are not for IP addresses. The fees are for ARIN > Subscriber Membership. The total number of IP addresses you > hold is used as an abstraction for classifying your membership. > > For someone who holds a /20, the next /20 is technically free, too. > Regardless of the increments in which it comes. For someone > who holds a /19+, it doesn't cost any more until they need more > than a /16. The point is there is an "until" in there, meaning those people are not encouraged to waste addresses indefinitely because they'll eventually have to pay more. Once you pass a /14, you _never_ pay _anything_ more no matter how much you waste. > This is standard tiered pricing and it's a way to simplify the > pricing structure so that the cost of computing a bill does not > increase the amount of money that needs to be collected. Either way, the amount of address space an org has needs to be calculated. Anyone with a modicum of programming experience can tell you that it's easier to multiply that number by a fixed per-IP rate than it is to try to determine which of five pricing tiers the org falls into and return a different fixed rate for each. I have yet to discover any argument _in favor_ of the current fee schedule, much less one that offsets its complexity, barriers to entry, and encouragement of massive waste. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From drc at virtualized.org Sat Oct 6 17:16:57 2007 From: drc at virtualized.org (David Conrad) Date: Sat, 6 Oct 2007 14:16:57 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <20071006160015.GB41201@ussenterprise.ufp.org> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> Message-ID: <2E0D9844-08F4-46F3-A569-D5E0B9E8CD67@virtualized.org> Leo, Not really commenting on this discussion (although I find it quite amusing), but: On Oct 6, 2007, at 9:00 AM, Leo Bicknell wrote: > The 5, or 10, or 20 "megacorps" are quickly overruled by the hundreds > if not thousands of people who represent small companies who take > an opposite view. Um. Where are these ARIN meetings in which these "hundreds if not thousands" of companies are participating? The ARIN meetings I go to (and the e-mail discussions I see) have the same few dozen of people, most of which are funded by their very large corporations to attend said meetings. I will also note that it is the very large corporations who have the lawyers who can pummel ARIN into the ground if policies change in a way they don't particularly like (regardless of the merit or legality of those changes). Welcome to business in the USA... Regards, -drc From jhg at omsys.com Sat Oct 6 17:40:48 2007 From: jhg at omsys.com (Jeremy H. Griffith) Date: Sat, 06 Oct 2007 14:40:48 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <2E0D9844-08F4-46F3-A569-D5E0B9E8CD67@virtualized.org> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> <2E0D9844-08F4-46F3-A569-D5E0B9E8CD67@virtualized.org> Message-ID: On Sat, 6 Oct 2007 14:16:57 -0700, David Conrad wrote: >I will also note that it is the very large corporations who have the >lawyers who can pummel ARIN into the ground if policies change in a >way they don't particularly like (regardless of the merit or legality >of those changes). Welcome to business in the USA... True. But oddly enough, when the energy discount structure in California reversed a few years back, in response to an energy shortage (albeit one deliberately created by Enron ;-), there were no such suits. The megacorps just absorbed the major rate increases they were given. Perhaps the same thing would happen if the IPv4 rate discounts were inverted too. --Jeremy From bicknell at ufp.org Sat Oct 6 18:01:53 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sat, 6 Oct 2007 18:01:53 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <2E0D9844-08F4-46F3-A569-D5E0B9E8CD67@virtualized.org> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> <2E0D9844-08F4-46F3-A569-D5E0B9E8CD67@virtualized.org> Message-ID: <20071006220153.GA70214@ussenterprise.ufp.org> In a message written on Sat, Oct 06, 2007 at 02:16:57PM -0700, David Conrad wrote: > Um. Where are these ARIN meetings in which these "hundreds if not > thousands" of companies are participating? The ARIN meetings I go to > (and the e-mail discussions I see) have the same few dozen of people, > most of which are funded by their very large corporations to attend > said meetings. The ARIN meeting in Puerto Rico had 149 attendees, per the list on the web site. Based on the organizations given they represent about 115 entities. Beyond that, the directives to the AC are quite clear: http://www.arin.net/policy/irpep.html ] Following discussion at the ARIN Public Policy Meeting, the Advisory ] Council will evaluate the proposal for community support based on ] comments from the Public Policy Mailing List as well as discussion and ] polling from the meetings. The Advisory Council review will normally ] take place within five days of the conclusion of the Public Policy ] Meeting. Comments on the Public Policy Mailing List are given as much ] weight as those made at the Public Policy Meeting, as it is recognized ] the mailing list provides access to the process that does not require ] physical presence at a meeting. So the AC considers every post on PPML, there's no requirement to go to the meeting. Looking at my own PPML archive, which goes back about a year and half I get 403 individual "From:" addresses in posts. There is some overlap with people who attend meetings, but it's not 100%. Perhaps my thousands was a bit off, but it seems like 450 is a likely number. Still, it's more than enough that 10, or 20, or even 30 megacorps would probably not be able to get a policy passed that everyone else opposed. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From paul at vix.com Sat Oct 6 18:07:58 2007 From: paul at vix.com (Paul Vixie) Date: Sat, 06 Oct 2007 22:07:58 +0000 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: Your message of "Sat, 06 Oct 2007 12:06:13 EST." References: <200710060645430.SM02832@mikesplace><3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> Message-ID: <7123.1191708478@sa.vix.com> note, this thread has nothing to do with any policy proposal and as such, probably ought to be on arin-discuss@ rather than ppml at . for the benefit of those who are subscribed here but not there, who may be following it, i am honouring the existing CC: header. but at some point we ought to pare down ppml@ to actual policy proposals rather than general discussion. > I do think it is reasonable and in line with the mission of ARIN to > execute fees that are in addition to the existing fees that would go to > support a robust education program aimed at objectives like, legacy > recovery, IPv6 understanding/adoption, etc. i've likewise heard randy bush's claim (most recently at the chicago IEPG meeting) that public funding has helped push IPv6 deployment in asia. am i to assume that the "public funding" mechanism being recommended here is a "sin tax" administered by ARIN? (that feels like mission creep, but before i say whether i think it's good or bad, i'd like to be sure i'm understanding what's been suggested.) From Lee.Howard at stanleyassociates.com Sat Oct 6 18:31:46 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sat, 6 Oct 2007 18:31:46 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710061206y1bf404f2q9ac8ee1ed0fdb320@mail.gmail.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4073855BE@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Saturday, October 06, 2007 3:06 PM > To: ppml at arin.net > Subject: Re: [ppml] ARIN IP conservation and FREE IP Addresses > > Its officially the weekend, so I'm throwing some notions out > there and letting things fall where they may. > > On 10/6/07, John Curran wrote: > > In ARiN's region, we have more than 2800 members, and > xsmall through > > medium far, far outnumber large + xlarge (I'll get the > exact breakdown > > posted as soon as possible) Given our 1 member, > > 1 vote structure, the x-large members really can't control > the votes. > > John, > > That's something you should fix, by the way. You have 600 > maybe 700 members who actually vote. Anyone can be a member: > $500 buys voting membership at 2 semi-annual meetings. Sorry, what needs to be fixed? Lee From Lee.Howard at stanleyassociates.com Sat Oct 6 18:58:30 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sat, 6 Oct 2007 18:58:30 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> > >The "Local Internet Registries" do. If you're a SOHO or hobbyist > >customer its not unusual to pay anywhere from $10 to $60 per > IP address > >per year for as much as 32+1 static IP addresses. > > > >Why should a Regional Internet Registry, one step up the food chain, > >not charge the LIR's $1 per IP address per year? Fair's fair, right? > >They charge the end users per-address so why shouldn't ARIN > > charge them the same way? Because two wrongs don't make a right. > You're onto something. All the blather about deadbeat legacy > holders is pure misdirection. The real issue is with the > large holders, under RSA or not, who have *no* reason to use > their assignments efficiently as long as the incremental cost > of new IPs is zero. In fact, with v4 exhaustion on the > horizon, it's better for them to remain inefficient to the > end of the free pool, since that will give them breathing > room at that point. The large holders who are active have to show efficient utilization, which means assignment to customers, in order to get more space. If they don't (and I speak from experience), they don't get more address space, which means they stop turning up new customers. > So, to change this, we have to work the system. And that > means, as this thread has made blindingly clear, making every > IP cost money, per year. > the fees have to be enough, at the top end, > to inspire more efficient use. Is it just me, or does it seems like everybody wants to raise fees on somebody else? I'm not convinced that this particular stick would have the intended effect. > The fees have nothing to do with ARIN's costs, and everything > to do with the public policy needed to keep the Net > functional. The fees were set by figuring out roughly what ARIN's budget needed to be, and setting up some simple tiers to meet those costs. > Applying this idea to ARIN, what if we had a basic fee for > any IP addresses of $25/year, which would include the first > 256 addresses (such as a legacy Class C, /24). > Then beyond that: > /22 $ 0.20 > /20 $ 0.35 > /18 $ 0.50 > /16 $ 0.75 > /14 $ 1.00 > /12 $ 1.50 > /10 $ 2.00 > /8 $ 3.00 > more $ 5.00 > which is *still* at the very top less than *half* what the > LIRs charge at their *lowest* rate for a single static IP. A > 100% markup would seem quite sufficient. Interesting idea. >From what I've seen, assignments to organizations (with dedicated service) are included with the service. Does that make any difference? > This would be fairer *to the community* than the current > scale, and would certainly promote fast action on IPv6... > especially with the fee waivers already in effect for v6. > > Anybody want to draft a formal proposal? ;-) This would go through the Suggestion Process, not the Public Policy Process. https://app.arin.net/suggestion/ Lee > --JHG From randy at psg.com Sat Oct 6 19:23:37 2007 From: randy at psg.com (Randy Bush) Date: Sun, 07 Oct 2007 08:23:37 +0900 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> Message-ID: <470818F9.8090408@psg.com> >>> Why should a Regional Internet Registry, one step up the food chain, >>> not charge the LIR's $1 per IP address per year? Fair's fair, right? >>> They charge the end users per-address so why shouldn't ARIN >>> charge them the same way? > Because two wrongs don't make a right. three lefts do > Is it just me, or does it seems like everybody wants to raise > fees on somebody else? and, as arin does not seem to be hurting for income, it would seem these efforts are motivated by some kind of anger/vengance or political goals. randy From michael at rancid.berkeley.edu Sat Oct 6 19:39:45 2007 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 06 Oct 2007 16:39:45 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> Message-ID: <47081CC1.8030506@rancid.berkeley.edu> Jeremy H. Griffith wrote: > This isn't a moral judgement, it's simple economics. As long > as an organization is profit-making, it *must* act that way, > or face shareholder suits if it acts to protect community > interests instead of its own monetary interests. That's just > how the system works. What about organizations that don't make a profit by design? What about EDUs, K-12s, regional and state networks, research networks, non-profit research organizations and national networks like Internet2, ESNet, NLR, etc.? Your economic model rests on the assumption that everyone makes a profit off of their IP addresses. How are those that don't make any profit supposed to suddenly pay for the allocations they need? Or, is PI space only to be assigned by ability to pay on an increasing-bracketed per-ip basis, rather than need? michael From michael at rancid.berkeley.edu Sat Oct 6 19:48:29 2007 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Sat, 06 Oct 2007 16:48:29 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <470818F9.8090408@psg.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> <470818F9.8090408@psg.com> Message-ID: <47081ECD.10207@rancid.berkeley.edu> W. Lee Howard wrote: >> Is it just me, or does it seems like everybody wants to raise >> fees on somebody else? Yes. Randy Bush wrote: > and, as arin does not seem to be hurting for income, it would seem these > efforts are motivated by some kind of anger/vengance or political goals. Interestingly, although there have been a lot of complaints about big government and excessive regulations in this thread, the call for increasing-graduated fees has a substantial redistributive tone to it. Much of the legacy discussion has been about carrots vs. sticks vs. something-in-between, and now, suddenly, we're proposing a sledgehammer. michael From stephen at sprunk.org Sat Oct 6 19:34:07 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 6 Oct 2007 18:34:07 -0500 Subject: [ppml] ARIN IP conservation and FREE IP Addresses References: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> <470818F9.8090408@psg.com> Message-ID: <035f01c80873$f6fbfdb0$6401a8c0@atlanta.polycom.com> Thus spake "Randy Bush" >> Is it just me, or does it seems like everybody wants to raise >> fees on somebody else? > > and, as arin does not seem to be hurting for income, it would > seem these efforts are motivated by some kind of anger / > vengance or political goals. Perhaps some commenters are motivated by such, but I'm only asking for a fee schedule that would provide a more fair (i.e. less anticompetitive) and more efficient result. I don't propose ARIN increase its revenues. If we charged per IP as opposed to the current tier structure, the vast majority of ARIN members would see their fees go down. (Perhaps a small flat fee, say $500/yr, plus a per-IP fee. That covers the fixed cost of dealing with an org in terms of billing and contracts, their "free" membership, etc.) S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Sat Oct 6 19:38:41 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 6 Oct 2007 18:38:41 -0500 Subject: [ppml] ARIN IP conservation and FREE IP Addresses References: <200710060645430.SM02832@mikesplace><3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com><20071006160015.GB41201@ussenterprise.ufp.org> <7123.1191708478@sa.vix.com> Message-ID: <036001c80873$f7a0a220$6401a8c0@atlanta.polycom.com> Thus spake "Paul Vixie" >> I do think it is reasonable and in line with the mission of ARIN to >> execute fees that are in addition to the existing fees that would >> go to support a robust education program aimed at objectives >> like, legacy recovery, IPv6 understanding/adoption, etc. > > i've likewise heard randy bush's claim (most recently at the > chicago IEPG meeting) that public funding has helped push IPv6 > deployment in asia. am i to assume that the "public funding" > mechanism being recommended here is a "sin tax" administered > by ARIN? (that feels like mission creep, but before i say whether > i think it's good or bad, i'd like to be sure i'm understanding > what's been suggested.) In case that is in fact true, I would like to state for the record that I am against ARIN collecting any form of "sin tax". ARIN is chartered to do specific things and collect the revenue necessary to pay for them. If we feel ARIN needs to do more things, then we should let the BoT worry about how to pay for them after we achieve consensus on those new activities. We should not "tax" people and then try to figure out how to spend the money; there are plenty of examples of why that's a complete failure of an idea. I do think the collection of current cost-recovery fees is broken, but that position has nothing to do with a "sin tax". S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From schiller at uu.net Sat Oct 6 20:14:59 2007 From: schiller at uu.net (Jason Schiller) Date: Sat, 06 Oct 2007 20:14:59 -0400 (EDT) Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> Message-ID: On Sat, 6 Oct 2007, William Herrin wrote: > On 10/6/07, Leo Bicknell wrote: > > > > Leaving aside the issue of is it good or not, I'm not sure ARIN as > > a non-profit is in a position to implement a "sin tax" on IP addresses > > to promote conservation. > > Leo, > > The "Local Internet Registries" do. If you're a SOHO or hobbyist > customer its not unusual to pay anywhere from $10 to $60 per IP > address per year for as much as 32+1 static IP addresses. > > Why should a Regional Internet Registry, one step up the food chain, > not charge the LIR's $1 per IP address per year? Fair's fair, right? > They charge the end users per-address so why shouldn't ARIN charge > them the same way? > > Regards, > Bill Herrin I would just like to point out that not all ISPs charge for IP addresses. If ARIN added a per IP address charge, then I suspect Verizon Business would be temped to charge their customers for IP addresses. Charging for IP addresses gives the impression that the addresses are property. As a result, it leads to the conclusion that the only justification required to get said addresses is if one pays enough money. The question I have is do we want to limit the use of IP addresses based on address utilization or based on the amount of money an org is willing to pay for each address? __Jason From jhg at omsys.com Sat Oct 6 20:23:06 2007 From: jhg at omsys.com (Jeremy H. Griffith) Date: Sat, 06 Oct 2007 17:23:06 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> Message-ID: On Sat, 6 Oct 2007 18:58:30 -0400, "Howard, W. Lee" wrote: >> >The "Local Internet Registries" do. If you're a SOHO or hobbyist >> >customer its not unusual to pay anywhere from $10 to $60 per >> IP address >> >per year for as much as 32+1 static IP addresses. >> > >> >Why should a Regional Internet Registry, one step up the food chain, >> >not charge the LIR's $1 per IP address per year? Fair's fair, right? >> >They charge the end users per-address so why shouldn't ARIN >> > charge them the same way? > >Because two wrongs don't make a right. Why is charging according to usage a "wrong"? It's the model used for virtually every transaction in the economy. >> You're onto something. All the blather about deadbeat legacy >> holders is pure misdirection. The real issue is with the >> large holders, under RSA or not, who have *no* reason to use >> their assignments efficiently as long as the incremental cost >> of new IPs is zero. In fact, with v4 exhaustion on the >> horizon, it's better for them to remain inefficient to the >> end of the free pool, since that will give them breathing >> room at that point. > >The large holders who are active have to show efficient >utilization, which means assignment to customers, in order to get >more space. If they don't (and I speak from experience), they >don't get more address space, which means they stop turning up >new customers. I'm not clear on your point here. There are many ways of looking at "efficient", and all involve a cost/benefit anaylsis. Efficient when marginal cost is zero is different from efficient when marginal cost is *something*. >> So, to change this, we have to work the system. And that >> means, as this thread has made blindingly clear, making every >> IP cost money, per year. >> the fees have to be enough, at the top end, >> to inspire more efficient use. > >Is it just me, or does it seems like everybody wants to raise >fees on somebody else? It's just you. ;-) I think everybody is trying to find some way of using fees, among other strategies, to deal with a real problem. I've seen as many posts advocating *lower* fees (for IPv6) as increases. That too is an appropriate approach. >I'm not convinced that this particular stick would have >the intended effect. Why is it a stick? It's simply a policy which has worked rather well where it has been used, specifically in California for energy and water, both in short supply. So from experience, not from political belief, it seems worth trying for the shortage ARIN is facing. >> The fees have nothing to do with ARIN's costs, and everything >> to do with the public policy needed to keep the Net >> functional. > >The fees were set by figuring out roughly what ARIN's budget >needed to be, and setting up some simple tiers to meet those >costs. Exactly. And that's the problem. The "simple tiers" have a discount structure meant to maximize use, which may have been fine in early days but isn't any more. And exhaustion is certainly going to have an impact on ARIN's budget. Could be a major decrease (no applications to process any more, so sorry), or an increase (paying for demo projects to get IPv6 out there more, or for investigators and attorneys to claw unused space back). The one thing it *won't* do is stay the same. >> Applying this idea to ARIN, what if we had a basic fee for >> any IP addresses of $25/year, which would include the first >> 256 addresses (such as a legacy Class C, /24). >> Then beyond that: >> /22 $ 0.20 >> /20 $ 0.35 >> /18 $ 0.50 >> /16 $ 0.75 >> /14 $ 1.00 >> /12 $ 1.50 >> /10 $ 2.00 >> /8 $ 3.00 >> more $ 5.00 >> which is *still* at the very top less than *half* what the >> LIRs charge at their *lowest* rate for a single static IP. A >> 100% markup would seem quite sufficient. > >Interesting idea. >From what I've seen, assignments to organizations (with >dedicated service) are included with the service. Does that >make any difference? Not really. I'm sure the cost of service far, far exceeds the max in the scale above. I pay about $200/month; it's hard to see where $5/year is going to impact that. >> This would be fairer *to the community* than the current >> scale, and would certainly promote fast action on IPv6... >> especially with the fee waivers already in effect for v6. >> >> Anybody want to draft a formal proposal? ;-) > >This would go through the Suggestion Process, not the Public >Policy Process. https://app.arin.net/suggestion/ Why is that? I've seen other proposals that affect the fee structure here, and this is specifically about public policy. Just wondering... --Jeremy From jhg at omsys.com Sat Oct 6 21:25:21 2007 From: jhg at omsys.com (Jeremy H. Griffith) Date: Sat, 06 Oct 2007 18:25:21 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> Message-ID: <2dbgg35d7fc23sqv9tqjur20mk4183oi8l@4ax.com> On Sat, 06 Oct 2007 20:14:59 -0400 (EDT), Jason Schiller wrote: >The question I have is do we want to limit the use of IP addresses based >on address utilization or based on the amount of money an org is willing >to pay for each address? Unless you think ARIN should charge nothing to anyone, which would be a hard position to support given that ARIN has expenses, this is rather moot. The question is then, do we want to have a fee scale: 1. that encourages maximum usage (the current one), 2. that is flat (about $0.02 per IP), or 3. that encourages conservation (the California-style graduated charge)? Personally, I favor number 3. Actually, that seems to address your concern better than the other two, IMHO. And note that this is orthogonal to utilization, not a replacement for it. --Jeremy From peter at boku.net Sat Oct 6 21:54:55 2007 From: peter at boku.net (Peter Eisch) Date: Sat, 06 Oct 2007 20:54:55 -0500 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <3c3e3fca0710060658m74538410jbbde6371090f19c8@mail.gmail.com> Message-ID: On 10/6/07 8:58 AM, "William Herrin" wrote: > On 10/6/07, Peter Eisch wrote: >> "As a steward of the Internet community ARIN would like to ask you for your >> stewardship back to the community. If you have unused address blocks that >> you're able and willing to return to the pool for others to potentially use, >> the Internet community would be appreciative. With the pending IPv4 >> exhaustion, your contribution back to the community can help extend the open >> availability for others to use." > > Hi Peter, > > The problem with a letter like this is that while this is the message > we want to convey, its intellectually dishonest and we will get called > on it. Let me explain what I mean. > > If you release address space back to ARIN's pool, there is somewhere > north of an 80% chance that next year it appears within an allocation > to one of a few hundred megacorps that has a voracious appetite for IP > addresses. ARIN's process is very top-heavy in that respect; at the > rate it makes single /20 and longer allocations it could continue for > decades. Its the big allocations to folks who already hold a lot of > addresses which are expected to exhaust the free pool in three years. > The odds favor your old addresses showing up at Verizon, AT&T or > another like them. Worse, under ARIN's price structure those guys > don't even have to pay more for it... Just the xxlarge annual fee. > Assuming your predictions here are correct, I don't see the problem. If the megacorps are going to consume the address space, they're going to consume the address space regardless of what the numbers are. It's in this area though that I wish the registrars would do the community a service by having them renumber so the number of slots they consume increase by zero when they are issued new ranges. With this I wander off to the issue of routing table size, but numbers are numbers. > Megacorps being what they are, you or someone you know has in the past > been screwed or treated like a peon by the one who ended up with your > old IP addresses. That's a pretty foul outcome for someone who has > generously returned addresses. I'd go so far as to call it a betrayal > of trust: It would be like volunteering to pick up trash on a highway > like you see the signs for, only to have the county come in and turn > it into a toll road. > I really don't follow the example or the analogy, sorry. Get the in-addrs updated and the issue is over. If you're talking about some emotional reaction then I'll say that I totally agree . > Then, when we go back for round two, we'll have zero credibility. > > Regards, > Bill Herrin > > From arin-contact at dirtside.com Sat Oct 6 22:00:04 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sat, 6 Oct 2007 22:00:04 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: <3c3e3fca0710061223i25382483h80481f2e81d791ca@mail.gmail.com> Message-ID: <3c3e3fca0710061900r6a50dd01jabcfc0666aa58779@mail.gmail.com> On 10/6/07, Jason Schiller wrote: > I would just like to point out that not all ISPs charge for IP > addresses. If ARIN added a per IP address charge, then I suspect Verizon > Business would be temped to charge their customers for IP addresses. Jason, For the record, Verizon does charge their SOHO and small business customers for IP addresses. I have 5 addresses on my business FiOS account and pay $5 per month for each. Once you're in a high enough business tier they do stop charging. The breakpoint comes around the time the revenues from your single account are sufficient to pay the entire ARIN bill. And by the way, why exactly can't I transfer the /26 Verizon Business assigned to me as a customer of its Ashburn VA data center to the Verizon Business 50-meg line I ordered from you in Vienna VA? You guys really got on my s*** list over that particular stunt. > Charging for IP addresses gives the impression that the addresses are > property. As a result, it leads to the conclusion that the only > justification required to get said addresses is if one pays enough money. Then the "Local Internet Registries" shouldn't be doing that, should they? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From stephen at sprunk.org Sat Oct 6 22:57:37 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sat, 6 Oct 2007 21:57:37 -0500 Subject: [ppml] ARIN IP conservation and FREE IP Addresses References: Message-ID: <03b401c8088e$39f588b0$6401a8c0@atlanta.polycom.com> Thus spake "Jason Schiller" > On Sat, 6 Oct 2007, William Herrin wrote: >> The "Local Internet Registries" do. If you're a SOHO or hobbyist >> customer its not unusual to pay anywhere from $10 to $60 per IP >> address per year for as much as 32+1 static IP addresses. >> >> Why should a Regional Internet Registry, one step up the food >> chain, not charge the LIR's $1 per IP address per year? Fair's >> fair, right? They charge the end users per-address so why >> shouldn't ARIN charge them the same way? > > I would just like to point out that not all ISPs charge for IP > addresses. If ARIN added a per IP address charge, then I > suspect Verizon Business would be temped to charge their > customers for IP addresses. The point is that right now, all your (VZB's) new addresses are _free_ from ARIN because you use/waste so much of them. That gives your sales people _no_ reason not to give customers as much as they want at no extra charge other than the general practice of squeezing them for as much as possible. This _is_ used as a competitive tactic -- mega-ISPs will give address space to customers at no extra charge as one way to win deals because their smaller competitors have to pay up to $5/yr/IP to ARIN (which they have to add to the customer's bill, one way or another, unlike you) just to get the same space. Instead of encouraging customers to conserve, a mega-ISP encourages customers to waste by giving them free IPs -- which they may never even use. If the mega-ISPs actually paid for their addresses, they'd be encouraging customers to conserve like their smaller competitors are forced to. > Charging for IP addresses gives the impression that the > addresses are property. There are lots of monthly or yearly services I pay for that do not convey me any sort of property rights. I don't own my phone number, despite paying for it for the last 10 years. It's debatable whether it's even _possible_ to own a number, though I'm sure the lawyers would have a lot of fun arguing both sides of the point. > As a result, it leads to the conclusion that the only justification > required to get said addresses is if one pays enough money. The NRPM does cover that, but I doubt it's enforced much in practice. In the real world, yes, customers can get as much address space as they're willing to pay for. The problem is that some LIRs the customers are paying to get that space from have to pay for it, while others do not (and take those fees as pure profit). Please explain to me how that's remotely fair... > The question I have is do we want to limit the use of IP addresses > based on address utilization or based on the amount of money > an org is willing to pay for each address? The utilization requirement still applies. Requiring payments in addition to (not instead of) encourages people to use less than they can justify, i.e. conserve. I'll also note that I have personal experience with at least one mega-ISP that insisted on SWIPing a /23 to my company, even though we had our own (smaller) PI space and didn't want to use theirs. They wouldn't have done that if they had to pay for that unused PA space. I won't name them since I don't know if they have the same practice today, but it's a perfect example of why RIRs giving addresses away for free to certain "special" LIRs is a bad idea. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From randy at psg.com Sat Oct 6 23:45:25 2007 From: randy at psg.com (Randy Bush) Date: Sun, 07 Oct 2007 12:45:25 +0900 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <035f01c80873$f6fbfdb0$6401a8c0@atlanta.polycom.com> References: <369EB04A0951824ABE7D8BAC67AF9BB4073855BF@CL-S-EX-1.stanleyassociates.com> <470818F9.8090408@psg.com> <035f01c80873$f6fbfdb0$6401a8c0@atlanta.polycom.com> Message-ID: <47085655.10501@psg.com> > I don't propose ARIN increase its revenues. If we charged per IP as > opposed to the current tier structure, the vast majority of ARIN members > would see their fees go down. > > (Perhaps a small flat fee, say $500/yr, plus a per-IP fee. That covers > the fixed cost of dealing with an org in terms of billing and contracts, > their "free" membership, etc.) this would make it even more blatantly obvious that arin is renting integers, not charging for services. randy From schiller at uu.net Sun Oct 7 02:00:04 2007 From: schiller at uu.net (Jason Schiller) Date: Sun, 07 Oct 2007 02:00:04 -0400 (EDT) Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710061900r6a50dd01jabcfc0666aa58779@mail.gmail.com> Message-ID: On Sat, 6 Oct 2007, William Herrin wrote: > Date: Sat, 06 Oct 2007 22:00:04 -0400 > From: William Herrin > To: Jason Schiller > Cc: ppml at arin.net > Subject: Re: [ppml] ARIN IP conservation and FREE IP Addresses > > On 10/6/07, Jason Schiller wrote: > > I would just like to point out that not all ISPs charge for IP > > addresses. If ARIN added a per IP address charge, then I suspect Verizon > > Business would be temped to charge their customers for IP addresses. > > Jason, > > For the record, Verizon does charge their SOHO and small business > customers for IP addresses. I have 5 addresses on my business FiOS > account and pay $5 per month for each. Just for the record I was referring to Verizon Business... AS701 (UUNET) which does not charge for IP addresses (not for business customer, not for SOHO, not for residential customers, not for DSL customers or DS-0 customers, not for any customers). When you refer to Verizon you are likely talking about AS19262 Verizon Internet Services (VIS). They are completely seperate networks run by completely seperate Business unit, with a completely seperate set of management, with a whole host of legacy policies. In other words Verizon Business does not equal Verizon. > > Once you're in a high enough business tier they do stop charging. The > breakpoint comes around the time the revenues from your single account > are sufficient to pay the entire ARIN bill. > > And by the way, why exactly can't I transfer the /26 Verizon Business > assigned to me as a customer of its Ashburn VA data center to the > Verizon Business 50-meg line I ordered from you in Vienna VA? You guys > really got on my s*** list over that particular stunt. This is not a stunt. The data centers are managed as a separate network with a separate AS, and due to route aggregation policies, your data center /26 would not route correctly. People sometimes have to renumber when they change networks... and yes that is painful. Just so you know the same would happen for longer than /24s from one continent being moved to another (Say UUNET North America and UUNET Asia-Pacific) > > > > Charging for IP addresses gives the impression that the addresses are > > property. As a result, it leads to the conclusion that the only > > justification required to get said addresses is if one pays enough money. > > Then the "Local Internet Registries" shouldn't be doing that, should they? Yes, I agree it would be great if the "Local Internet Registries" did not charge for IP addresses (with them not being property and all), and that is why Verizon Business (UUNET) doesn't. I can't speak for any other LIRs (including Verizon Internet Services (VIS). __Jason > > Regards, > Bill Herrin > > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > From schiller at uu.net Sun Oct 7 02:08:41 2007 From: schiller at uu.net (Jason Schiller) Date: Sun, 07 Oct 2007 02:08:41 -0400 (EDT) Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <03b401c8088e$39f588b0$6401a8c0@atlanta.polycom.com> Message-ID: On Sat, 6 Oct 2007, Stephen Sprunk wrote: > The point is that right now, all your (VZB's) new addresses are _free_ from > ARIN because you use/waste so much of them. That gives your sales people > _no_ reason not to give customers as much as they want at no extra charge > other than the general practice of squeezing them for as much as possible. > This _is_ used as a competitive tactic -- mega-ISPs will give address space > to customers at no extra charge as one way to win deals because their > smaller competitors have to pay up to $5/yr/IP to ARIN (which they have to > add to the customer's bill, one way or another, unlike you) just to get the > same space. Instead of encouraging customers to conserve, a mega-ISP > encourages customers to waste by giving them free IPs -- which they may > never even use. If the mega-ISPs actually paid for their addresses, they'd > be encouraging customers to conserve like their smaller competitors are > forced to. I don't know about other ISPs, but we require customers to justify all of thier IP space. This way it is possible to get IP space from ARIN when we need it. Our customers conserve IP space because we uphold ARIN policies. > > > Charging for IP addresses gives the impression that the > > addresses are property. > > As a result, it leads to the conclusion that the only justification > > required to get said addresses is if one pays enough money. > > The NRPM does cover that, but I doubt it's enforced much in practice. In > the real world, yes, customers can get as much address space as they're > willing to pay for. The problem is that some LIRs the customers are paying > to get that space from have to pay for it, while others do not (and take > those fees as pure profit). Please explain to me how that's remotely > fair... Verizon Business does not charge for space, so our customers do not get as much as they can pay for. Instead they get only as much as they can justify. I do understnd your point though. When customers pay for address space, they feel entilted to as much address space as they pay for. And since sales people want to sell as many services as possible, they are likely to they and pile on extra IP addresses to raise the cost. > > > The question I have is do we want to limit the use of IP addresses > > based on address utilization or based on the amount of money > > an org is willing to pay for each address? > > The utilization requirement still applies. Requiring payments in addition > to (not instead of) encourages people to use less than they can justify, > i.e. conserve. > As I said above using payment as a justification (even in part) for IP addresses muddies the waters. __Jason From arin-contact at dirtside.com Sun Oct 7 02:48:49 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 7 Oct 2007 02:48:49 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: <3c3e3fca0710061900r6a50dd01jabcfc0666aa58779@mail.gmail.com> Message-ID: <3c3e3fca0710062348o78e7665fw8cec8a4bce0520ce@mail.gmail.com> On 10/7/07, Jason Schiller wrote: > Just for the record I was referring to Verizon Business... AS701 > (UUNET) which does not charge for IP addresses (not for business customer, > When you refer to Verizon you are likely talking about AS19262 Verizon > Internet Services (VIS). They are completely seperate networks run by > > This is not a stunt. The data centers are managed as a separate network > with a separate AS, and due to route aggregation policies, your data > center /26 would not route correctly. People sometimes have to renumber > when they change networks... and yes that is painful. > > Just so you know the same would happen for longer than /24s from one > continent being moved to another (Say UUNET North America and UUNET > Asia-Pacific) Jason, Given this behavior, legacy registrants should, for your sake, give up their underutilized address blocks? Those route aggregation policies are strictly internal to the Verizon empire. Your company set them entirely on its own. No technical limitation prevents you from routing any Verizon address on down to a /32 anywhere within the empire that is Verizon. Certainly nothing stops Verizon from moving addresses 20 miles within the same US state. I'll bet you run the Ashburn data center as a separate AS. It provides you with the largest obstruction possible against anyone moving out. The next time folks on this list get to discussing provider independent address space, I'll pull this post back out. I think it beautifully illustrates real-world customer abuse which occurs as a consequence of too much emphasis on provider aggregatable space. > Yes, I agree it would be great if the "Local Internet Registries" did not > charge for IP addresses (with them not being property and all), and that > is why Verizon Business (UUNET) doesn't. I can't speak for any other LIRs > (including Verizon Internet Services (VIS). Would you then support a dual fee structure? One for LIRs which change their service prices based on the number of IP addresses assigned to a customer and a second for LIRs which don't? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From desterdick at verizon.com Sun Oct 7 06:57:20 2007 From: desterdick at verizon.com (desterdick at verizon.com) Date: Sun, 7 Oct 2007 06:57:20 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses Message-ID: Bill, Like many empires today, Verizon's has evolved from a multitude of separate enterprises with multiple autonomous networks, each with their associated network policies and support work groups. Throughout the multiple mergers that formed what is now Verizon, (first Bell Atlantic and NYNEX, each made up of multiple separate Bell Operating Companies, then GTE and then MCI and other miscellaneous companies that have been acquired or spun off along the way), there has been both organizational and network consolidation. However, there are still multiple separate corporate entities within the Verizon umbrella, along with multiple separate organizations managing multiple autonomous networks. Some of those networks support customer facing networks such as Verizon Business and Verizon Internet Service. There are also many other internal management networks, IT and lab networks, and other internal corporate infrastructure networks. The list goes on. My point is that while your claim that there is "No technical limitation [that] prevents you from routing any Verizon address on down to a /32 anywhere within the empire that is Verizon" may or may not be correct, there exist multiple legal, organizational, and operational limitations that prevent that and a whole lot of other things that ideally could be done better. My opinion regarding the suggestion that Verizon, as an "empire", is somehow gaming the IP addressing landscape to gain a competitive advantage is that nothing could be further from reality. I've spoken with some internal IT folks who have mentioned that they were still dealing with internal network integration issues from Bell Atlantic and NYNEX merger when the MCI merger was taking place. Many legacy registrants within Verizon operate independently. Although ideally network consolidation and renumbering will achieve better address utilization and potentially better operating and organizational efficiency, such an effort for an enterprise the size of Verizon could not only take a couple of lifetimes, but due to other legal, organizational and operational constraints may never be possible at all. Regards, Mark ----------------------------------------------------------------------------------------------------------------------------------------------------------------- Mark W. Desterdick Distinguished Member of Technical Staff - Technical Regulatory, Standards and Industry Forum Management Verizon Communications, Inc 221 East 37th Street, 4th floor New York, NY 10016 +1 212 681-5626 +1 212 681-5626 - FAX "William Herrin" tside.com> cc: ppml at arin.net, Jason Schiller Sent by: Subject: Re: [ppml] ARIN IP conservation and FREE IP Addresses ppml-bounces at arin .net 10/07/2007 02:48 AM On 10/7/07, Jason Schiller wrote: > Just for the record I was referring to Verizon Business... AS701 > (UUNET) which does not charge for IP addresses (not for business customer, > When you refer to Verizon you are likely talking about AS19262 Verizon > Internet Services (VIS). They are completely seperate networks run by > > This is not a stunt. The data centers are managed as a separate network > with a separate AS, and due to route aggregation policies, your data > center /26 would not route correctly. People sometimes have to renumber > when they change networks... and yes that is painful. > > Just so you know the same would happen for longer than /24s from one > continent being moved to another (Say UUNET North America and UUNET > Asia-Pacific) Jason, Given this behavior, legacy registrants should, for your sake, give up their underutilized address blocks? Those route aggregation policies are strictly internal to the Verizon empire. Your company set them entirely on its own. No technical limitation prevents you from routing any Verizon address on down to a /32 anywhere within the empire that is Verizon. Certainly nothing stops Verizon from moving addresses 20 miles within the same US state. I'll bet you run the Ashburn data center as a separate AS. It provides you with the largest obstruction possible against anyone moving out. The next time folks on this list get to discussing provider independent address space, I'll pull this post back out. I think it beautifully illustrates real-world customer abuse which occurs as a consequence of too much emphasis on provider aggregatable space. > Yes, I agree it would be great if the "Local Internet Registries" did not > charge for IP addresses (with them not being property and all), and that > is why Verizon Business (UUNET) doesn't. I can't speak for any other LIRs > (including Verizon Internet Services (VIS). Would you then support a dual fee structure? One for LIRs which change their service prices based on the number of IP addresses assigned to a customer and a second for LIRs which don't? 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 (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: image/gif Size: 45 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: pic17639.gif Type: image/gif Size: 1255 bytes Desc: not available URL: From arin-contact at dirtside.com Sun Oct 7 11:09:25 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 7 Oct 2007 11:09:25 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: Message-ID: <3c3e3fca0710070809n4f961f70ge6f16f9b7a81a1b3@mail.gmail.com> On 10/7/07, desterdick at verizon.com wrote: > the multiple mergers that formed what is now Verizon, >(first Bell Atlantic and NYNEX, each made up of multiple >separate Bell Operating Companies, then GTE and then >MCI and other miscellaneous companies that have been >acquired or spun off along the way), there has been both >organizational and network consolidation. However, there >are still multiple separate corporate entities within the >Verizon umbrella, along with multiple separate organizations >managing multiple autonomous networks. Mark, Yes, Verizon has had a great deal of difficulty and delay merging its operations in a sensible manner. Given the performance, one wonders if the regulators were asleep at the wheel when they approved the latter acquisitions. However, that is not at issue here. The 50 meg line I ordered is classic UUnet - AS701. The Ashburn data center was built by UUnet shortly before the Worldcom buyout. Architecting that part of the network so that customers could not easily move their IP addresses was no accident of consolidation. It was a deliberate choice to leverage provider aggregatable space in a way that harms the customers of what is now Verizon Business. That this behavior is not as foul as the choice by the business unit that does FiOS to monetize individual IP addresses does not make it any less offensive. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From schiller at uu.net Sun Oct 7 12:04:28 2007 From: schiller at uu.net (Jason Schiller) Date: Sun, 07 Oct 2007 12:04:28 -0400 (EDT) Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710070809n4f961f70ge6f16f9b7a81a1b3@mail.gmail.com> Message-ID: Bill, I think you are misunderstanding our intentions. The 50m line is classic UUNET AS701, but the data centers are not. The "classic UUNET Engineering" has no architectural authority over the data centers. I believe that the original UUNET data centers were not in AS701 due to the fact that some data center equipment could not be in the AS701 IGP. I believe those issues have been resolved. Unfortunately now all the data centers are engineered and operated by the legacy Digex folks. So they are following their own standards. I would certainly like to see the engineering and operations of the data centers merged with AS701 so that we could rationalize the routing, and have expressed this opinion in the past, but I lack the authority make this happen. You as a customer have more power to persuade this change happening. I would recomend contacting your sales person, and raising the issue to a sufficently high level. Can I count on your support? ___Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Sun, 7 Oct 2007, William Herrin wrote: > Date: Sun, 07 Oct 2007 11:09:25 -0400 > From: William Herrin > To: "desterdick at verizon.com" > Cc: ppml at arin.net > Subject: Re: [ppml] ARIN IP conservation and FREE IP Addresses > > On 10/7/07, desterdick at verizon.com wrote: > > the multiple mergers that formed what is now Verizon, > >(first Bell Atlantic and NYNEX, each made up of multiple > >separate Bell Operating Companies, then GTE and then > >MCI and other miscellaneous companies that have been > >acquired or spun off along the way), there has been both > >organizational and network consolidation. However, there > >are still multiple separate corporate entities within the > >Verizon umbrella, along with multiple separate organizations > >managing multiple autonomous networks. > > Mark, > > Yes, Verizon has had a great deal of difficulty and delay merging its > operations in a sensible manner. Given the performance, one wonders if > the regulators were asleep at the wheel when they approved the latter > acquisitions. > > However, that is not at issue here. The 50 meg line I ordered is > classic UUnet - AS701. The Ashburn data center was built by UUnet > shortly before the Worldcom buyout. Architecting that part of the > network so that customers could not easily move their IP addresses was > no accident of consolidation. It was a deliberate choice to leverage > provider aggregatable space in a way that harms the customers of what > is now Verizon Business. > > That this behavior is not as foul as the choice by the business unit > that does FiOS to monetize individual IP addresses does not make it > any less offensive. > > 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From ppml at rsuc.gweep.net Sun Oct 7 15:08:40 2007 From: ppml at rsuc.gweep.net (Joe Provo) Date: Sun, 7 Oct 2007 15:08:40 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <3c3e3fca0710070809n4f961f70ge6f16f9b7a81a1b3@mail.gmail.com> References: <3c3e3fca0710070809n4f961f70ge6f16f9b7a81a1b3@mail.gmail.com> Message-ID: <20071007190840.GA99522@gweep.net> On Sun, Oct 07, 2007 at 11:09:25AM -0400, William Herrin wrote: [snip] > Yes, Verizon has had a great deal of difficulty and delay merging its > operations in a sensible manner. Given the performance, one wonders if > the regulators were asleep at the wheel when they approved the latter > acquisitions. Some silos and imepediments to merging operations in all of the major LEC M&A stems directly *FROM* telco regulatory constraints. While large corporate entities tend to have too many feifdoms, several 'lines of business' cannot even talk during some time periods after these mergers. Specifically, look up the actual FCC merger conditions, noting section 272 and its sunset provisions. att just got theirs last month, and VZ has had it for about six months. Any steering of the corporate iceberg will take a while, however I'm dubious of the direct PPML relevance of further rehashing of FCC/PUC public documents. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From arin-contact at dirtside.com Mon Oct 8 01:10:06 2007 From: arin-contact at dirtside.com (William Herrin) Date: Mon, 8 Oct 2007 01:10:06 -0400 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: References: <3c3e3fca0710070809n4f961f70ge6f16f9b7a81a1b3@mail.gmail.com> Message-ID: <3c3e3fca0710072210udc6f2dj93e5f7101ae08b00@mail.gmail.com> On 10/7/07, Jason Schiller wrote: > I would certainly like to see the engineering and operations of > the data centers merged with AS701 so that we could rationalize the > routing, and have expressed this opinion in the past, but I lack the > authority make this happen. Jason, I'm well aware. Two Verizon vice presidents of Governmental Affairs were unable to make it happen. They couldn't make it happen for a 3 month transition window. They couldn't even arrange for GRE tunnel for 3 months. > You as a customer have more power to persuade this change happening. I > would recomend contacting your sales person, and raising the issue > to a sufficently high level. Can I count on your support? This all played out a year ago. If anyone had the clout, you'd think the Democratic Party would. VB screwed the DNC two months ahead of the '06 election, negatively impacting the fundraising efforts. The only part of that account which remains today are the yet uncorrected billing errors. That, and the lessons that can be learned from it. Experiences like this one offer insight into number resource policy questions like: What real-world price is paid for the emphasis on PA address space? Are the LIRs as a group capable of responsibly managing of number resources? Should the LIRs be expected to apply the same operating model to their customers that ARIN applies to them? Conversely, should ARIN apply the same operating model to the LIRs that the LIRs apply to their customers? So you see Jason, your company's public spanking is actually relevant to the discussion on this mailing list. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From raul at lacnic.net Mon Oct 8 09:42:37 2007 From: raul at lacnic.net (Raul Echeberria) Date: Mon, 08 Oct 2007 10:42:37 -0300 Subject: [ppml] IPv4 Soft Landing - Discussion and Support/Non-Support Requested In-Reply-To: References: Message-ID: <7.0.1.0.1.20071008100825.048fc7f8@lacnic.net> Ed: As you suggest, I think that there are implication of some policies in others. While I usually don't particpate very much in policy discussions, this issue is of a great importance for the future of the RIR's system, so, I will make an exception. My view is that we need some kind of "soft landing" proposal, but we face two probable problems. 1) The current IANA-RIRs IPv4 allocation policies works in a way in which as much IPv4 addresses an RIR allcocate to their custumers/members, as much IPv4 addresses they can receive from IANA. So, to apply this kind of policies in one region would probably put that region in disadvantage in relation to the other regions. So, the first problem is that a policy like this probably would not be adopted only in one region. The challenge is coordination. Coordination means from my perspective to have a cross-regional dialogue in order to analyze the pertinence of promotint some kind of "soft landing" proposals in every region. (not necessarily the same policy in every region, but based in the same concept/objective) 2) As you pointed out, there is a relation between soft landing proposal and the other proposals that are being discussed. (distribution of the last part of the free IPv4 pool) But, IMHO the relation is the opposite of what you mentioned. Since the distribution of the last part of the IPv4 pool will naturally take off pressure from the unallocated pool and will help to avoid a competition for that pool, it probably will create a better environment to implement "soft landing" policies. I will submit a proposal to all the RIRs' lists in order to address what I identify as the first problem, but it should not be considered as an opposition to the David's proposal. Ra?l At 11:32 a.m. 05/10/2007, Edward Lewis wrote: >At 16:10 -0500 10/2/07, Bill Darte wrote: > > >As shepherd of the ARIN Policy Proposal: IPv4 Soft Landing, I would like to > >ask the community to once again consider this proposal in advance of the > >Albuquerque Public Policy and Membership Meetings > >(http:/ > /www.arin.net/ARIN-XX/index.html) and voice support or non-support > >for this proposal with concise reasoning. > >It would certainly be bad to "abdicate responsibility"... > >On the one hand I like the way this proposal >thinks, but it thinks like an engineer. It >certainly has the mechanics in it to achieve the >goal of softening the transition pains. > >But I also waver over whether it is worth the >effort. At the APNIC meeting (yes, I know, not >"our" region, yet a public policy meeting none >the less) there was a discussion between two >proposals. The two were similar up to a >parameter. Each proposal mandated that IANA >operate as is until there were either 1x5 or 2x5 >/8's left (assuming the number of RIRs is >5). Once the last 5 or 10 /8's were left they >were handed out evenly to the RIRs regardless of burn rates. > >Of the two, I preferred the handing out of 1 /8 >(not the 2 /8). The reason is that this >approach is largely ceremonial. While it is >true that the burn rate of a /8 varies region to >region, for 1 /8, this isn't a significant >difference. (There could be a sharp rise in >membership at the lower burn rate organizations, >but really, there isn't much to get at that >point.) In the lower burn rate regions, the >symbolism of being given as much a the higher rate seems somewhat important. > >Those proposals are lightweight work-wise, least >command-econonmyish, have probably the right >dose of ceremonial benefit, and aren't trying to >delay the pain of the IPv4 run out. > >So, on the other hand, I think that the IPv4 >Soft Landing might be "trying to hard" to protect ourselves. > >Ultimately, in a vacuum, it's a good >proposal. But considering other ideas floating >around I have doubt that it's the right mechanism. > >As an aside - if we delay the run out of IPv4 by >12 months, is there an indication that the >obstacle to IPv6 will be removed in that 12 month period? >If it is the routing system, will 12 more months >improve/strengthen it? (I guess I have never >understood the rationale for "rationing" the >remaining IPv4 addresses. They aren't a >consumable {water, oil} and the last won't tide >us over until there's a rescue.) > >-- >-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- >Edward Lewis +1-571-434-5468 >NeuStar > >Think glocally. Act confused. >_______________________________________________ >PPML >You are receiving this message because you are >subscribed to the ARIN Public Policy >Mailing List (PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml >Please contact the ARIN Member Services >Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From apb at cequrux.com Mon Oct 8 12:33:53 2007 From: apb at cequrux.com (Alan Barrett) Date: Mon, 8 Oct 2007 18:33:53 +0200 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: <03b401c8088e$39f588b0$6401a8c0@atlanta.polycom.com> References: <03b401c8088e$39f588b0$6401a8c0@atlanta.polycom.com> Message-ID: <20071008163353.GE12017@apb-laptoy.apb.alt.za> On Sat, 06 Oct 2007, Stephen Sprunk wrote: > I'll also note that I have personal experience with at least one > mega-ISP that insisted on SWIPing a /23 to my company, even though we > had our own (smaller) PI space and didn't want to use theirs. This seems to point to an opportunity for ARIN to perform more thorough auditing of existing address space utilisation when that unnamed mega-ISP requests more address space in the future. --apb (Alan Barrett) From rgaglian at antel.net.uy Mon Oct 8 13:12:09 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Mon, 08 Oct 2007 15:12:09 -0200 Subject: [ppml] Global Policy Updata Message-ID: <1191863529.17471.122.camel@jessy.antel.net.uy> I wanted to give you all an update on the discussion of the "Global Policy for the Allocation of the remaining IPv4 Address Space" before heading to Alburqueque. As I mentioned on the policy proposal the text of the policy allowed to have two discussion: is such a policy needed? and what should be the size of the last allocation form IANA?. We have made a great progress in the first issue and some in the second. Here is an update: - LACNIC, the policy reached consensus. - APNIC, there was consensus that a global policy for the allocation of the remaining IPv4 space such as this one was needed. Not consensus on the size that allocation or the text. - AFRINIC, idem APNIC. So up to now, three of the five RIR have a positive opinion that a global policy is needed. Here are the main arguments showed on these three meetings: - It is a RIR issue: the allocation of the remaining IPv4 space is an issue that should be solved inside the RIR community and a global policy will be a clear signal to other actors (there are some governmental documents on the IGF preparation). - Central Pool: This policy releases the pressure on the central pool. - Certainty: this policy brings certainty to every RIR on what to expect as a last allocation. Without this policy there are different scenarios of what could happen, and which would be the first RIR to run out of addresses. - Conservation: after approving this policy the scenario will be such that each RIR could analyze more conservative policies such as the proposed "soft-landing" or the reservation of addresses to specific infrastructure. The current "on demand" policy encourage the consumption of addresses until the end of the IPv4 space. - easy to implement: This policy is strait-forward to implement. See you in Albuquerque, Roque -- ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tedm at ipinc.net Mon Oct 8 13:45:05 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 8 Oct 2007 10:45:05 -0700 Subject: [ppml] ARIN IP conservation and FREE IP Addresses In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >John Curran >Sent: Saturday, October 06, 2007 7:31 AM >To: William Herrin >Cc: ppml at arin.net >Subject: Re: [ppml] ARIN IP conservation and FREE IP Addresses > > >At 10:11 AM -0400 10/6/07, William Herrin wrote: >>That having been said, this discussion is moot. The xlarge entities >>have the votes to keep the favorable fee structure. > >I have no particular viewpoint on the matter of whether our >fee schedule needs to be changed, but want to be clear on >the ability to change the fees. The ARIN Board sets the fee >schedule, and it's been generally based on the feedback we >receive at the member meetings. Then, John, I would like to request, as a member, that at the next meeting you advance for discussion an agenda item titled along the lines of "Would fee adjustment affect IPv4 uptake rates, and if so would it be appropriate to modify fees to affect IPv4 uptake rates" Leave out the discussion of whether it would or would not be a good idea to affect IPv4 uptake rates entirely, it would be useful I think to know if the ARIN Board would think it would it be a good or bad idea, would there be unwanted side effects, etc. Ted From mje at pop.co.za Mon Oct 8 14:14:25 2007 From: mje at pop.co.za (Mark Elkins) Date: Mon, 08 Oct 2007 20:14:25 +0200 Subject: [ppml] Global Policy Updata In-Reply-To: <1191863529.17471.122.camel@jessy.antel.net.uy> References: <1191863529.17471.122.camel@jessy.antel.net.uy> Message-ID: <1191867266.10506.24.camel@localhost> On Mon, 2007-10-08 at 15:12 -0200, Roque Gagliano wrote: > I wanted to give you all an update on the discussion of the "Global > Policy for the Allocation of the remaining IPv4 Address Space" before > heading to Alburqueque. > > As I mentioned on the policy proposal the text of the policy allowed > to have two discussion: is such a policy needed? and what should be > the size of the last allocation form IANA?. > > We have made a great progress in the first issue and some in the > second. > > Here is an update: > - LACNIC, the policy reached consensus. > - APNIC, there was consensus that a global policy for the > allocation of the remaining IPv4 space such as this one was needed. > Not consensus on the size that allocation or the text. > - AFRINIC, idem APNIC. A bit more on this as far as AfriNIC is concerned. Regarding what the size of the last allocation should be.. a show of hands was asked for. For the size to be either one or two "/8's" - the votes were equal. For sizes larger than two - there were no votes. ie - we equally chose one and two. I might read this as being - AfriNIC does not feel we need more than two "/8's". I think we (AfriNIC members) understand that we do not want IPv4 addresses years after the rest of the world has run out, has moved over to IPv6 - and left Africa even further behind. I don't think many AfriNIC members would mind that much either if other areas chose and got a value greater than two (ie five) and we only had two. Disclaimer: This is my own interpretation of what happened. I speak for myself. -- . . ___. .__ Posix Systems - Sth Africa /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 From randy at psg.com Mon Oct 8 16:51:51 2007 From: randy at psg.com (Randy Bush) Date: Tue, 09 Oct 2007 05:51:51 +0900 Subject: [ppml] Global Policy Updata In-Reply-To: <1191863529.17471.122.camel@jessy.antel.net.uy> References: <1191863529.17471.122.camel@jessy.antel.net.uy> Message-ID: <470A9867.8010201@psg.com> > - APNIC, there was consensus that a global policy for the allocation > of the remaining IPv4 space such as this one was needed. Not > consensus on the size that allocation or the text. i suspect that a careful reading of the minutes or transcription would show that o consensus was *not* reached that such a proposal was needed o consensus *was* reached that, if such a proposal was needed that one /8 per rir was the appropriate number randy, co-chair apnic policy sig but speaking without consulting other chairs and without coffee and before 06:00 From tedm at ipinc.net Mon Oct 8 17:11:06 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 8 Oct 2007 14:11:06 -0700 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: <200710052114.l95LEMDK020056@cjbsys.bdb.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Cliff Bedore >Sent: Friday, October 05, 2007 9:25 AM >To: ppml at arin.net >Subject: Re: [ppml] Counsel statement on Legacy assignments? > > >I originally sent this to John Curran directly but after reading more >comments, I thought I'd post it to the group > > >As a legacy holder who has recently joined the PPML list, I can see certain >advantages to joining ARIN. I'm just not sure of the best way to keep my >network number safe if I join. I have a Class C (/24) and use it >actively but >don't use 50% of the numbers at the current time. If ARIN were to >have an RSA >that lets us join, pay our $100.00 per year and leave us alone with our >networks, I'd be happy to join. Do I want to pay $100.00 per >year? No but it >won't break my small consulting firm and it's probably a good >thing to do. I >tend to be suspicious of groups that say "We're from the governmet >and we're >here to help you" I have never seen a government/quasi-government >group shrink >or give up any power/control except at the point of a gun and I expect most >legacy users feel the same way. I expect most are willing to take >their chances >by maintaining their "legacy" status of being grandfathered into ARIN's >in-addr-ARPA service unless there is a very strong specific RSA >protecting their >status quo. This is not to say that if they need more resources, >they should >have free rein to get them. People keep working around this but >all proposals >seem to have more stick than carrot. > >It would seem to me that the ARIN leadership needs to look at the >way to get >people to join. There seems to be no concensus on the list about how to do >this but if ARIN's goal is to get people to join, they need to take a >pro-active stance to get it done. The choices seem to be to leave >the legacy >owners alone and codify their right to ARIN in-addr service or take strong >action to make them default members of ARIN by whatever means >necessary. This >could go to the point of offering free membership and guarantees >of safe harbor >for existing numbers with limited other benefits (maybe no voting etc) and >then allow full membership for a nominal fee. > >As others have stated, this is a v4 problem only and will disappear when v6 >takes over. I think it is to ARIN's advantage as the numbers get >tight toward >the end to have as many as possible legacy folks under the ARIN/other RIRs >umbrella. >The problems of hijacked legacy numbers will only cost ARIN more >time and money for lawyers and dispute resolution Why? As ARIN is not legally obligated to the legacy holders to do anything, any attempt to involve them in a dispute can merely be ignored. There is no gain to ARIN to be involved in someone else's lawsuit with some other person. >and I think any >action that >ARIN takes to get legacy users under ARIN should be taken. It's already been done. ARIN has setup the mechanism that a legacy holder can use to become a member - just contact them and sign an agreement and start paying the fees. This >would/should/could include free limited membership and any other incentives >needed. Is it fair to the newcomers? In some ways probably not >but if they >have to pay increased fees to cover the costs of dispute resolution because >the legacy users have not joined, they won't be happy about that either. > I would rather pay the legal fees because I am pretty confident that anything that comes out of such a dispute is going to result in the Judge telling the plantiff and defendant that they have to submit to ARIN's rules. And once a few cases like that have been filed and rulings like this, there won't be any more of these disputes involving ARIN because both parties know that they will give up their autonomy as legacy holders if they try to involve ARIN. >I look at this somewhat like Ford's pardon of Nixon. Was it >"fair" for Nixon >to walk? No but it was better for the country to get past the >embarrassment >and back to more important things. That is very arguable. The fact that Nixon was pardonded turned off an entire generation in disgust to US politics. Arguably, the disillusionment added to the lower voter turnouts of subsequent presidential elections, which then allowed minority factions like the Christian Right Wing to get a foothold and ultimately take over the Republican party and got Raygun elected. Imagine Nixon taking dictation from the likes of Jerry Falwell - it would never have happened in Nixon's time. The argument that "the country needs to get past..." has been used to justify a whole host of nasty things in US politics, everything from treatment of Vietnam Vets to the 2000 election, to the Japanese internment not being recognized as even happening for almost 50 years... It is rarely better for the embarrassment to be swept under the rug. Ted From dean at av8.com Mon Oct 8 20:08:22 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 8 Oct 2007 20:08:22 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: On Mon, 8 Oct 2007, Ted Mittelstaedt wrote: > >As a legacy holder who has recently joined the PPML list, I can see > >certain advantages to joining ARIN. I'm just not sure of the best > >way to keep my network number safe if I join. I have a Class C (/24) > >and use it actively but don't use 50% of the numbers at the current > >time. If ARIN were to have an RSA that lets us join, pay our $100.00 > >per year and leave us alone with our networks, I'd be happy to join. You lose more than this. > >As others have stated, this is a v4 problem only and will disappear > >when v6 takes over. I think it is to ARIN's advantage as the numbers > >get tight toward the end to have as many as possible legacy folks > >under the ARIN/other RIRs umbrella. IPv4 will never go away, even after IPv6 'takes over', which seems pretty doubtful, but I won't go there now. > >The problems of hijacked legacy numbers will only cost ARIN more time > >and money for lawyers and dispute resolution > > Why? As ARIN is not legally obligated to the legacy holders to do > anything, any attempt to involve them in a dispute can merely be > ignored. There is no gain to ARIN to be involved in someone else's > lawsuit with some other person. This is not true. Any true hijacking of records that ARIN maintains involves ARIN. Like Kremen v. ARIN, a case could involve jurisdiction of a court. There is no contest that ARIN isn't subject to court jurisdiction over such records. Kremen was dismissed on a statute of limitations technicality. Kremen essentially won all the court orders up to then. BTW, Curran has corrected himself: There is indeed no formal statement on the subject from ARIN counsel. I've asked for a formal statement to be produced, but haven't heard back whether they will do that. The statement from Sprunk to IETF relies on an informal statement of Counsel and Sprunk omitted significant qualifying context from the informal statement. > >and I think any action that ARIN takes to get legacy users under ARIN > >should be taken. > > It's already been done. ARIN has setup the mechanism that a legacy > holder can use to become a member - just contact them and sign an > agreement and start paying the fees. This is optional. ARIN doesn't (and can't) compel this action. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jcurran at istaff.org Mon Oct 8 20:17:00 2007 From: jcurran at istaff.org (John Curran) Date: Mon, 8 Oct 2007 20:17:00 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: At 8:08 PM -0400 10/8/07, Dean Anderson wrote: >BTW, Curran has corrected himself: There is indeed no formal statement >on the subject from ARIN counsel. I've asked for a formal statement to >be produced, but haven't heard back whether they will do that. Dean - The request was noted and will be brought before the Board. >The statement from Sprunk to IETF relies on an informal statement of >Counsel and Sprunk omitted significant qualifying context from the >informal statement. The full transcript (including Counsel's response to the question) is available online; you can keep repeating that Steven omitted context but a carefully reading doesn't support that conclusion. /John From dean at av8.com Tue Oct 9 00:51:21 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 9 Oct 2007 00:51:21 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: On Mon, 8 Oct 2007, John Curran wrote: > At 8:08 PM -0400 10/8/07, Dean Anderson wrote: > >BTW, Curran has corrected himself: There is indeed no formal statement > >on the subject from ARIN counsel. I've asked for a formal statement to > >be produced, but haven't heard back whether they will do that. > > Dean - The request was noted and will be brought before the Board. Good. When can we expect to have this statement? > >The statement from Sprunk to IETF relies on an informal statement of > >Counsel and Sprunk omitted significant qualifying context from the > >informal statement. > > The full transcript (including Counsel's response to the question) > is available online; you can keep repeating that Steven omitted > context but a carefully reading doesn't support that conclusion. I don't know how you can possibly say that with a straight face, given your correction already. Sprunk said to the IETF: "[ARIN] Counsel recently made a statement that it doesn't appear that ARIN has any legal obligation to maintain registry services for legacy assignments, though it does have a moral one since that was a condition of ARIN's creation. Counsel also stated, however, it is unclear that ARIN could assign those same numbers to someone else later." Sprunk's full message is at http://www1.ietf.org/mail-archive/web/ietf/current/msg48312.html In fact, Counsel did not assert "that ARIN [doesn't have] any legal obligation to maintain registry services for legacy assignments". Counsel said nothing of the sort, as the full text below reveals. Counsel acknowledges an agreement; a 'government give-away of rights without strings': "I have never seen the United States government give away anything without any strings attached before." Counsel then notes that government contract holders' space was probably 'government furnished', and therefore should be returned at the end of contract. Counsel goes on to acknowledge there are indeed legacy holders to whom "carrots" rather than sticks must be offered. Implicitly, this denies the notion that those legacy's have no legal rights, as Sprunk implies. Counsel then acknowledges the special unencumbered value of this Legacy space: "Because there's a window coming that intersects with the IPv4 exhaustion issue, where for a brief time, these resources will actually become financially more valuable if they were unencumbered, and where that value will only be for a limited period." In this section, Counsel says they can deny free services to people _without_an_agreement_. But virtually every Legacy in fact has an agreement in the form of a paper registration, a kind of license that doesn't terminate. My FAA-issued pilot's license also never expires. All that can be disputed is the terms of the agreement. Further, Mr Ryan notes that he hasn't thought much about it. He notes that an Act of Congress may be needed to take back this space. He notes that such an Act might not be constitutional. He notes he's only started to play with theories. "it's very clear to me that denial of service by ARIN is legally permitted. In other words, I don't believe we, as the non-profit trying to carry out the community's wishes, have a duty to provide free services for legacy address holders. And the denial of those free services to legacy address holders pursuant to their lack of agreement is perfectly permitted, in my judgment, as a matter of law. I've thought about it that far. I haven't thought carefully about what would be the stick beyond denial of those free services. And in my view, the two are quite different. The stick might be that we -- for example, I've thought about whether I could ask the United States Congress for authority to have the government obtain back that which the government gave. I don't know if that's constitutional, actually. I mean, I've started to play with different theories here." None of this is very definite. So from an implied formal statement that 'legacies have no rights', that Sprunk reported, we've shown that Atty Ryan actually stated: * an acknowledgement of a group of legacy's possessing a government right with no strings attached * notes requirement of an Act of Congress to take back legacy space * notes that such an Act might not be constitutional * notes that he is 'playing with theories' that haven't been thought through yet. That's a pretty big change in meaning from Sprunk and Curran. Sprunk has omitted the significant qualifications and context from the transcript, as I have cited, and which Curran also omits. Sprunk's report is indeed inaccurate and misleading, as I reported. Curran's support for Sprunk's report is similarly unfounded in fact. I've identified a number of issues that Sprunk omitted. A close reading of Sprunk's email doesn't find those issues mentioned. Rather, reading Sprunk's report to the IETF one gets the impression that 1. ARIN has in its possession a legal opinion that it in fact doesn't have, and 2. that ARIN has made a decision that it in fact hasn't made. Therefore, Sprunk's message to the IETF is misleading, and Curran stands corrected. IETF remains misled and deceived by incorrect reports of the actual events. John Curran has also been misreading the statement, asserting incorrectly for example, that there was a formal statement when there wasn't such a statement. Curran has agreed to correction, but still asserts mysteriously that Sprunk is correct. Someone should inform the IETF that Sprunk and Curran have misled them. The transcript is here http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 The complete relevant text is here: MR. RYAN: Well, from a legal perspective, this is why I love you guys. I have never seen the United States government give away anything without any strings attached before. And so there's a real question in my mind whether -- with regard to some of the legacy address holders who received early addresses who were in the Defense or academic community but held Defense contracts, whether the issuance of space at that time was pursuant to traditional government theories of government-furnished material or government-furnished equipment. The paper record is really pretty strange when one looks at it. And it does appear -- to the extent that I've had an opportunity to look at some of the paperwork -- that it's one of the few times in the history of governments that they gave away something seemingly without a clear set of strings attached to it. I believe that those who are government contractors and who received it as government contractors actually have the weakest case to argue that they have some enhanced right over other members of the community in this regard. And I'm still evaluating the legal theories that address that. But looking more generally, there are clearly legacy address holders who are not government contractors who did get early resources, and who are clearly not covered by GFM, GFE -- any kind of theories with regard to that. And with regard to those people, from my legal standpoint as a person who has adopted the notion of RFC 2008 and all of the sort of learning of the community, I think what we need to do is fashion a -- I do think we need to fashion a policy proposal or a series of proposals that creates a series of carrots, but not particularly sticks, that would be intended to entice legacy holders to bring their resources into the system, to give up those resources that they don't need, and to actually come out of that process benefited as opposed to being treated in a detrimental or in a pejorative or even a negative way in any regard. And I think the sooner we adopt such a set of policies that are well-thought-out by this community, the better off we'll be legally as we address this situation. Because there's a window coming that intersects with the IPv4 exhaustion issue, where for a brief time, these resources will actually become financially more valuable if they were unencumbered, and where that value will only be for a limited period. So in that sense as a lawyer, I look forward to working with you to try and describe mechanisms that are affirmative, positive, and that entice people to feel that it is a civic duty, but maybe even a beneficial civic duty, to perform in that way. MR. CURRAN: Can I ask one question, Steve? And this is asking as Counsel to ARIN. You said potentially, for those folks who have received legacy addresses who didn't necessarily get them through government contracts or GFE, that it might be useful to try to take an approach or a policy or a set of policies or actions that entice them to participate in the community -- the use of carrots, not sticks. My question is, is the shying away from sticks because it's not felt ARIN has any useful ones, or is it because of the liability that's entailed by doing that? MR. RYAN: I've thought a little bit about what a stick might look like here. So for example, it's very clear to me that denial of service by ARIN is legally permitted. In other words, I don't believe we, as the non-profit trying to carry out the community's wishes, have a duty to provide free services for legacy address holders. And the denial of those free services to legacy address holders pursuant to their lack of agreement is perfectly permitted, in my judgment, as a matter of law. I've thought about it that far. I haven't thought carefully about what would be the stick beyond denial of those free services. And in my view, the two are quite different. The stick might be that we -- for example, I've thought about whether I could ask the United States Congress for authority to have the government obtain back that which the government gave. I don't know if that's constitutional, actually. I mean, I've started to play with different theories here. -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From stephen at sprunk.org Tue Oct 9 01:05:57 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 9 Oct 2007 00:05:57 -0500 Subject: [ppml] ARIN IP conservation and FREE IP Addresses References: Message-ID: <028201c80a32$44aa4070$6401a8c0@atlanta.polycom.com> Thus spake "Jason Schiller" > On Sat, 6 Oct 2007, Stephen Sprunk wrote: >> The point is that right now, all your (VZB's) new addresses are >> _free_ from ARIN because you use/waste so much of them. >> That gives your sales people _no_ reason not to give customers >> as much as they want at no extra charge other than the general >> practice of squeezing them for as much as possible. This _is_ >> used as a competitive tactic -- mega-ISPs will give address >> space to customers at no extra charge as one way to win deals >> because their smaller competitors have to pay up to $5/yr/IP to >> ARIN (which they have to add to the customer's bill, one way or >> another, unlike you) just to get the same space. Instead of >> encouraging customers to conserve, a mega-ISP encourages >> customers to waste by giving them free IPs -- which they may >> never even use. If the mega-ISPs actually paid for their >> addresses, they'd be encouraging customers to conserve like >> their smaller competitors are forced to. > > I don't know about other ISPs, but we require customers to justify > all of thier IP space. This way it is possible to get IP space from > ARIN when we need it. Our customers conserve IP space > because we uphold ARIN policies. That's a very loose definition of conservation. It also completely fails to address the point that you get IPs free from ARIN while your smaller competitors pay up to $5/yr/IP, which gives you a significant competitive advantage. If you had to recover per-IP fees from your customers, they (and you) would be more interested in real conservation (i.e. above what ARIN policies require). > Verizon Business does not charge for space, so our customers > do not get as much as they can pay for. Instead they get only as > much as they can justify. In theory. > I do understnd your point though. When customers pay for > address space, they feel entilted to as much address space as > they pay for. And since sales people want to sell as many > services as possible, they are likely to they and pile on extra > IP addresses to raise the cost. And if the customer doesn't actually _need_ those addresses, whether or not they're "justified" under ARIN rules, they'd turn them down. Today, your salespeople throw addresses at them for free and the customer has no reason to conserve because it costs them nothing -- because waste costs _you_ nothing. >> > The question I have is do we want to limit the use of IP >> > addresses based on address utilization or based on the >> > amount of money an org is willing to pay for each address? >> >> The utilization requirement still applies. Requiring payments >> in addition to (not instead of) encourages people to use less >> than they can justify, i.e. conserve. >> > As I said above using payment as a justification (even in part) for IP > addresses muddies the waters. I never said money should be involved in the justification process. However, you seem to have no problem with your smaller competitors having to pay per IP _in addition to technical justification_, so why shouldn't you be required to as well? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From jcurran at istaff.org Tue Oct 9 01:33:27 2007 From: jcurran at istaff.org (John Curran) Date: Tue, 9 Oct 2007 01:33:27 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: At 12:51 AM -0400 10/9/07, Dean Anderson wrote: >On Mon, 8 Oct 2007, John Curran wrote: > >> At 8:08 PM -0400 10/8/07, Dean Anderson wrote: >> >BTW, Curran has corrected himself: There is indeed no formal statement >> >on the subject from ARIN counsel. I've asked for a formal statement to >> >be produced, but haven't heard back whether they will do that. >> >> Dean - The request was noted and will be brought before the Board. > >Good. When can we expect to have this statement? I will bring the matter to the Board. I do not know the outcome at this time. >None of this is very definite. I'm sorry that you're having trouble assessing the situation and have heard the request for formal statement as noted above. >Someone should inform the IETF that Sprunk and Curran have misled them. > >The transcript is here >http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 Alas, Dean, I've given you my assessment, as has Steven. As the full transcript is online, so each may judge the situation on their own, and decide accordingly. /John From dean at av8.com Tue Oct 9 02:24:30 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 9 Oct 2007 02:24:30 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: On Tue, 9 Oct 2007, John Curran wrote: > At 12:51 AM -0400 10/9/07, Dean Anderson wrote: > >On Mon, 8 Oct 2007, John Curran wrote: > > > >> At 8:08 PM -0400 10/8/07, Dean Anderson wrote: > >> >BTW, Curran has corrected himself: There is indeed no formal statement > >> >on the subject from ARIN counsel. I've asked for a formal statement to > >> >be produced, but haven't heard back whether they will do that. > >> > >> Dean - The request was noted and will be brought before the Board. > > > >Good. When can we expect to have this statement? > > I will bring the matter to the Board. I do not know the > outcome at this time. When will the board consider this? > >None of this is very definite. > > I'm sorry that you're having trouble assessing the situation > and have heard the request for formal statement as noted > above. I'm having no trouble 'assessing the situation'. > >Someone should inform the IETF that Sprunk and Curran have misled them. > > > >The transcript is here > >http://www.arin.net/meetings/minutes/ARIN_XIX/ppm1_transcript.html#anchor_13 > > Alas, Dean, I've given you my assessment, as has Steven. As the full > transcript is online, so each may judge the situation on their own, and > decide accordingly. The IETF doesn't have this information, and so can't judge the situation on their own. The assessment reported by Sprunk and approved by Curran wasn't based on facts from the transcript. It would be helpful if you stuck to actual facts found in the transcript rather than made baseless summary statements that suggest unfounded conclusions that most certainly weren't in the transcripts. The longer you wait with correction, the more IETF members will repost the incorrect assessments on other lists, and the harder it will be for you to correct these misapprehensions. I don't think that is too much to ask from ARIN Board members in general and the chairman in particular. Especially, since it has been established now that there is no formal statement, and no formal decision from ARIN. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jcurran at istaff.org Tue Oct 9 02:28:23 2007 From: jcurran at istaff.org (John Curran) Date: Tue, 9 Oct 2007 02:28:23 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: At 2:24 AM -0400 10/9/07, Dean Anderson wrote: > > I will bring the matter to the Board. I do not know the >> outcome at this time. > >When will the board consider this? At our meeting next week. >The IETF doesn't have this information, and so can't judge the situation >on their own. Feel free to forward them a link to the meeting transcript so they also can make their own judgement. /John From raul at lacnic.net Tue Oct 9 09:17:58 2007 From: raul at lacnic.net (Raul Echeberria) Date: Tue, 09 Oct 2007 10:17:58 -0300 Subject: [ppml] Proposal for the creation of a working group. Message-ID: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> Dear all: I would like to share with all of you this proposal. Since it is not a policy proposal, I don't know really how to proceed, but I guess that it is enough to send it to the list. This proposal doesn't intend to substitute the Policy Proposal "2007-16 IPv4 Soft Landing" and is not incompatible with the discussion of this proposal and/or its eventual adoption. I will send the same proposal to the others RIRs' poilicy lists. Ra?l ========================================== Proposal for the creation of a cross-regions working group Some proposals have been submitted through some RIR?s policy development process, which focus on the gradual modification of the requirements for receiving IPv4 addresses as the pool of unallocated IPv4 addresses diminishes. Most or all proposals which have been made appear to be incomplete and ineffective if approved in only one region. Therefore, it is proposed the creation of a working group made up by two appropriate respected individuals active in the policy process within each region?s community. These ten individuals would work on one or more joint proposals that could then be processed in every region according to their corresponding policy development processes. The objective of the working group would not be to produce proposals for global policies, but proposals to be sumbitted to every RIRs. The conclusion could be, of course, that the proposals should be different in each region. Since the proposal (if there are any) should go later through each Policy Development Process, there will not be any impact of this proposal in the independence of each region to adopt the poclicies that are considered more convenients. Naturally, the proposals that have already been presented in relation to this issue would be important input for this working group, one possible conclusion being that these proposals contain the best possible policies and should be presented. Without this level of coordination, it will be difficult to obtain proposals to be submitted for discussion in all regions with reasonable chances of success. One member of each RIRs staff would also participate in this working group, in the capacity of observers, so as to provide all the support, advice and information that the group deems necessary. IANA will also be invited to appoint up to two persons to the working group in the same condition of observers. The working schedule would be defined by the group itself, but it should be anticipated that the proposals, in case it is decided they are needed, be presented for their discussion as soon as possible. The following are some of the ideas that have already been presented either formally or informally and that will be available for the consideration of this working group (but not limited to) : ? Increasing the requirements for receiving additional allocations as IANA?s central pool of addresses diminishes. ? Adding to the current requirements the requirement to develop the availability of IPv6 infrastructure. ? Reducing the sizes of the blocks that are allocated as IANA?s central pool of addresses diminishes. ? Including within the gradual increase of restrictions the requirement that when one RIR runs out of addresses the others will automatically be moved to a more conservative phase in order to minimize RIR shopping. =============== From rgaglian at antel.net.uy Tue Oct 9 09:24:30 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Tue, 9 Oct 2007 11:24:30 -0200 Subject: [ppml] Global Policy Updata In-Reply-To: <470A9867.8010201@psg.com> References: <1191863529.17471.122.camel@jessy.antel.net.uy> <470A9867.8010201@psg.com> Message-ID: Randy, I should have said a majority was reached at APNIC and consensus at AFRINIC. Roque >> - APNIC, there was consensus that a global policy for the allocation >> of the remaining IPv4 space such as this one was needed. Not >> consensus on the size that allocation or the text. > > i suspect that a careful reading of the minutes or transcription would > show that > o consensus was *not* reached that such a proposal was needed > o consensus *was* reached that, if such a proposal was needed that > one /8 per rir was the appropriate number > > randy, co-chair apnic policy sig but speaking without consulting other > chairs and without coffee and before 06:00 ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean at av8.com Tue Oct 9 13:28:48 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 9 Oct 2007 13:28:48 -0400 (EDT) Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: Message-ID: On Tue, 9 Oct 2007, John Curran wrote: > >The IETF doesn't have this information, and so can't judge the situation > >on their own. > > Feel free to forward them a link to the meeting transcript > so they also can make their own judgement. Unfortunatly, due to improper and unlawful 'hardball tactics' by this very same group of people, (Sprunk et al), I have been banned from the IETF list. See pages at http://www.av8.net/IETF-watch/ for more information. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From jcurran at istaff.org Tue Oct 9 13:33:25 2007 From: jcurran at istaff.org (John Curran) Date: Tue, 9 Oct 2007 13:33:25 -0400 Subject: [ppml] Counsel statement on Legacy assignments? In-Reply-To: References: Message-ID: Dean - I'm happy to make sure that the discussion of this topic is well-informed on any mailing list. If you know of a discussion thread ongoing which doesn't include a solid set of references, please contact me directly and I'm happy to work with you on an appropriate message and post accordingly. Thanks, /John At 1:28 PM -0400 10/9/07, Dean Anderson wrote: >On Tue, 9 Oct 2007, John Curran wrote: > >> >The IETF doesn't have this information, and so can't judge the situation >> >on their own. >> >> Feel free to forward them a link to the meeting transcript >> so they also can make their own judgement. > >Unfortunatly, due to improper and unlawful 'hardball tactics' by this >very same group of people, (Sprunk et al), I have been banned from the >IETF list. > >See pages at http://www.av8.net/IETF-watch/ for more information. > > --Dean > >-- >Av8 Internet Prepared to pay a premium for better service? >www.av8.net faster, more reliable, better service >617 344 9000 From sleibrand at internap.com Tue Oct 9 15:20:09 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 09 Oct 2007 12:20:09 -0700 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> References: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> Message-ID: <470BD469.5040209@internap.com> Raul, Another option for coordinating policy between the RIRs would be to simply submit the proposal to multiple RIRs and have each RIR run the proposal through their own public policy process. I think that's happening now, and has happened in the past with other policy proposals. I'm very much in favor of coordination between RIRs on matters of policy (while maintaining each RIR's independence to decide on its own policy where appropriate). I think that we may already have enough existing mechanisms (such as: staff coordination, reports at ARIN meetings of activity in other RIRs, open mailing lists at each RIR so individuals can participate and contribute in the public policy process of multiple RIRs, etc.) to facilitate such coordination. There's always the possibility of expanding the use of such existing mechanisms, and I think that might be more successful than trying to establish a new mechanism. -Scott Raul Echeberria wrote: > Dear all: > > I would like to share with all of you this > proposal. Since it is not a policy proposal, I > don't know really how to proceed, but I guess > that it is enough to send it to the list. > > This proposal doesn't intend to substitute the > Policy Proposal "2007-16 IPv4 Soft Landing" and > is not incompatible with the discussion of this > proposal and/or its eventual adoption. > > I will send the same proposal to the others RIRs' poilicy lists. > > Ra?l > > > ========================================== > > Proposal for the creation of a cross-regions working group > > > > Some proposals have been submitted through some > RIR?s policy development process, which focus on > the gradual modification of the requirements for > receiving IPv4 addresses as the pool of unallocated IPv4 addresses diminishes. > > Most or all proposals which have been made appear > to be incomplete and ineffective if approved in > only one region. Therefore, it is proposed the > creation of a working group made up by two > appropriate respected individuals active in the > policy process within each region?s community. > These ten individuals would work on one or more > joint proposals that could then be processed in > every region according to their corresponding policy development processes. > > The objective of the working group would not be > to produce proposals for global policies, but > proposals to be sumbitted to every RIRs. The > conclusion could be, of course, that the > proposals should be different in each region. > > Since the proposal (if there are any) should go > later through each Policy Development Process, > there will not be any impact of this proposal in > the independence of each region to adopt the > poclicies that are considered more convenients. > > Naturally, the proposals that have already been > presented in relation to this issue would be > important input for this working group, one > possible conclusion being that these proposals > contain the best possible policies and should be > presented. Without this level of coordination, it > will be difficult to obtain proposals to be > submitted for discussion in all regions with > reasonable chances of success. One member of > each RIRs staff would also participate in this working > group, in the capacity of observers, so as to > provide all the support, advice and information > that the group deems necessary. IANA will also be > invited to appoint up to two persons to the working > group in the same condition of observers. > > The working schedule would be defined by the > group itself, but it should be anticipated that > the proposals, in case it is decided they are > needed, be presented for their discussion as soon as possible. > > The following are some of the ideas that have > already been presented either formally or > informally and that will be available for the > consideration of this working group (but not limited to) : > > > ? Increasing the requirements for > receiving additional allocations as IANA?s > central pool of addresses diminishes. > ? Adding to the current requirements the > requirement to develop the availability of IPv6 infrastructure. > ? Reducing the sizes of the blocks that > are allocated as IANA?s central pool of addresses diminishes. > ? Including within the gradual increase of > restrictions the requirement that when one RIR > runs out of addresses the others will > automatically be moved to a more conservative > phase in order to minimize RIR shopping. > > =============== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Oct 9 17:28:13 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 9 Oct 2007 14:28:13 -0700 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> Message-ID: Hi Raul, Just a quick comment. You recognize that we have separate RIR's because it was recognized that different regions cannot all operate the same way. You should also recognize that the diminishing pool of unallocated IPv4 is not the same level of concern in all regions and that some regions do not need or want to implement policy affecting it. I think it would be wise to wait for consensus on dealing with IPv4 runout in ARIN first, before trying to encourage the rest of the RIR's to go make policy regarding IPv4 runout. In all liklihood, for the ones that runout is a non-issue, they are merely waiting to see what ARIN does anyway and then just do that. Ted >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Raul Echeberria >Sent: Tuesday, October 09, 2007 6:18 AM >To: ppml at arin.net >Subject: [ppml] Proposal for the creation of a working group. > > > > >Dear all: > >I would like to share with all of you this >proposal. Since it is not a policy proposal, I >don't know really how to proceed, but I guess >that it is enough to send it to the list. > >This proposal doesn't intend to substitute the >Policy Proposal "2007-16 IPv4 Soft Landing" and >is not incompatible with the discussion of this >proposal and/or its eventual adoption. > >I will send the same proposal to the others RIRs' poilicy lists. > >Ra?l > > >========================================== > >Proposal for the creation of a cross-regions working group > > > >Some proposals have been submitted through some >RIR?s policy development process, which focus on >the gradual modification of the requirements for >receiving IPv4 addresses as the pool of unallocated IPv4 addresses >diminishes. > >Most or all proposals which have been made appear >to be incomplete and ineffective if approved in >only one region. Therefore, it is proposed the >creation of a working group made up by two >appropriate respected individuals active in the >policy process within each region?s community. >These ten individuals would work on one or more >joint proposals that could then be processed in >every region according to their corresponding policy development processes. > >The objective of the working group would not be >to produce proposals for global policies, but >proposals to be sumbitted to every RIRs. The >conclusion could be, of course, that the >proposals should be different in each region. > >Since the proposal (if there are any) should go >later through each Policy Development Process, >there will not be any impact of this proposal in >the independence of each region to adopt the >poclicies that are considered more convenients. > >Naturally, the proposals that have already been >presented in relation to this issue would be >important input for this working group, one >possible conclusion being that these proposals >contain the best possible policies and should be >presented. Without this level of coordination, it >will be difficult to obtain proposals to be >submitted for discussion in all regions with >reasonable chances of success. One member of >each RIRs staff would also participate in this working >group, in the capacity of observers, so as to >provide all the support, advice and information >that the group deems necessary. IANA will also be >invited to appoint up to two persons to the working >group in the same condition of observers. > >The working schedule would be defined by the >group itself, but it should be anticipated that >the proposals, in case it is decided they are >needed, be presented for their discussion as soon as possible. > >The following are some of the ideas that have >already been presented either formally or >informally and that will be available for the >consideration of this working group (but not limited to) : > > >? Increasing the requirements for >receiving additional allocations as IANA?s >central pool of addresses diminishes. >? Adding to the current requirements the >requirement to develop the availability of IPv6 infrastructure. >? Reducing the sizes of the blocks that >are allocated as IANA?s central pool of addresses diminishes. >? Including within the gradual increase of >restrictions the requirement that when one RIR >runs out of addresses the others will >automatically be moved to a more conservative >phase in order to minimize RIR shopping. > >=============== > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to the >ARIN Public Policy >Mailing List (PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml Please contact the >ARIN Member Services >Help Desk at info at arin.net if you experience any issues. > > From narten at us.ibm.com Wed Oct 10 10:00:07 2007 From: narten at us.ibm.com (Thomas Narten) Date: Wed, 10 Oct 2007 10:00:07 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <470BD469.5040209@internap.com> References: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> <470BD469.5040209@internap.com> Message-ID: <200710101400.l9AE07L6027929@localhost.localdomain> Scott Leibrand writes: > Raul, > Another option for coordinating policy between the RIRs would be to > simply submit the proposal to multiple RIRs and have each RIR run > the proposal through their own public policy process. I think that's > happening now, and has happened in the past with other policy > proposals. IMO, the process for getting globally-coordinated policies adopted locally within each region has signficant flaws. For starters, in an ideal world, it takes 2 cycles in each RIR to get something done. So we are talking something like 18 months to 2 years in practice. Can you say "miss the window of opportunity"? I also believe many of the policies that are being discussed really only make sense if done more globally. The fact is (as Raul said in his initial note) that many of the policies just don't make sense if done differently in different regions. The challenge is that address policies in practice often have global impact (e.g., on route table size, on long term consumption rates, etc.). Treating them as local policies significantly misses the point. Or, if there are significant differences in the details in practice, can lead to RIR shopping by entities looking for address space with the best terms. Speaking also as someone who has participated in globally-coordinated policy development, it is really, really, really hard to pull it off in practice. Consider the travel involved, for starters. (It is a fact that the face-to-face meetings are an important part of the process, and to be effective one needs to participate in those meetings.) In my experience, the only way to get any significant (or contentious) globally-coordinated policy adopted in practice requires the help of a team of people (from multiple regions) to work together to help coordinate the activities and to help folk understand the nuances of how each individual RIR works. And to come up with specific proposals that have a chance of being adopted by each region. I think the basic proposal Raul is making is a recognition of the challenges involved in getting significant policies adopted, and should be given serious consideration. Bottom line: how much time do the RIRs _really_ have to get any sort of IPv4 end game policy adopted before it is too late to matter? Thomas From bicknell at ufp.org Wed Oct 10 10:18:53 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 10 Oct 2007 10:18:53 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <200710101400.l9AE07L6027929@localhost.localdomain> References: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> <470BD469.5040209@internap.com> <200710101400.l9AE07L6027929@localhost.localdomain> Message-ID: <20071010141853.GA69818@ussenterprise.ufp.org> In a message written on Wed, Oct 10, 2007 at 10:00:07AM -0400, Thomas Narten wrote: > IMO, the process for getting globally-coordinated policies adopted > locally within each region has signficant flaws. For starters, in an > ideal world, it takes 2 cycles in each RIR to get something done. So > we are talking something like 18 months to 2 years in practice. Can > you say "miss the window of opportunity"? I'm afraid Thomas has hit the nail on the head. I actually think it's a bit worse; each RIR is developing its own "style" and thus it's harder and harder to make a global policy fit in a way that makes sense. ARIN has been tweaking the IPv6 section of the policy manual since it was adopted as a more-or-less global policy, for example. Policy proposal 2007-12 (IPv4 Countdown, from our friends in Japan) encountered as much difficult in the ARIN region due to it's formatting and style not matching ARIN's as it did for content reasons. I've also been vocal over the years that our process for ARIN to pass a global policy of putting it in the ARIN policy manual first is broken. For ARIN to forward it on as approved we have to adopt it and put it in our policy manual, even though all four other RIR's may reject it. That would leave us in a position of having to do another policy cycle to remove it. There's no mechanism (in any RIR that I know of) to say "We approve this policy, and will put it in our policy manual as soon as all 5 RIR's have approved it." I have actually mused recently to several people in private that we may never see another global policy passed. The barriers get larger as the RIR's policies drift further from a common base and as there are more RIR's. Travel costs have accelerated in recent years with airfair, and hotel rates seeing double digit inflation over the past 2-3 years. What's worse, is more and more of the large issues (e.g. "IPv4 end game") leave the RIR's with a prisoners dilemma of sorts, and human nature rarely overcomes those situations. Today the NRO's job is one of auditor, they certify that all 5 RIR's have passed a global policy. I have to wonder if the world would be better served if it were transformed to where the NRO could set binding policy for all 5 RIR's. Now that's a can of worms. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From jcurran at istaff.org Wed Oct 10 10:38:09 2007 From: jcurran at istaff.org (John Curran) Date: Wed, 10 Oct 2007 10:38:09 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <200710101400.l9AE07L6027929@localhost.localdomain> References: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> <470BD469.5040209@internap.com> <200710101400.l9AE07L6027929@localhost.localdomain> Message-ID: At 10:00 AM -0400 10/10/07, Thomas Narten wrote: >I also believe many of the policies that are being discussed really >only make sense if done more globally. The fact is (as Raul said in >his initial note) that many of the policies just don't make sense if >done differently in different regions. The challenge is that address >policies in practice often have global impact (e.g., on route table >size, on long term consumption rates, etc.). Treating them as local >policies significantly misses the point. Or, if there are significant >differences in the details in practice, can lead to RIR shopping by >entities looking for address space with the best terms. If the particular global policy is important enough, shouldn't the potential downside of the risk of significant differences (and "RIR shopping") be considered a relatively small price to pay? >In my experience, the only way to get any significant (or contentious) >globally-coordinated policy adopted in practice requires the help of a >team of people (from multiple regions) to work together to help >coordinate the activities and to help folk understand the nuances of >how each individual RIR works. And to come up with specific proposals >that have a chance of being adopted by each region. I also believe that this is the most successful path. In the past, it appears to have occurred on an ad-hoc basis. >Bottom line: how much time do the RIRs _really_ have to get any sort >of IPv4 end game policy adopted before it is too late to matter? Since the WG proposal has the output is to go through the individual region policy development processes, it does not appear intended to speed up the overall process, but instead the goal appears to be to increase the probability of approval of a common result. /John From stephen at sprunk.org Wed Oct 10 10:39:22 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 10 Oct 2007 09:39:22 -0500 Subject: [ppml] Proposal for the creation of a working group. References: <7.0.1.0.1.20071009101612.0456d698@lacnic.net><470BD469.5040209@internap.com><200710101400.l9AE07L6027929@localhost.localdomain> <20071010141853.GA69818@ussenterprise.ufp.org> Message-ID: <007c01c80b4e$519d5840$523816ac@atlanta.polycom.com> Thus spake "Leo Bicknell" > There's no mechanism (in any RIR that I know of) to say "We > approve this policy, and will put it in our policy manual as soon > as all 5 RIR's have approved it." What is stopping someone from putting "Upon adoption by all other RIRs" in the "Timetable for implementation" slot of the policy template? We could pass a proposal but it wouldn't go into the NRPM or be implemented by staff until that occurred. Given how nearly all proposals give a timetable of "immediately", such a trick seems like the only purpose for having that field... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From bicknell at ufp.org Wed Oct 10 11:20:26 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 10 Oct 2007 11:20:26 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <007c01c80b4e$519d5840$523816ac@atlanta.polycom.com> References: <20071010141853.GA69818@ussenterprise.ufp.org> <007c01c80b4e$519d5840$523816ac@atlanta.polycom.com> Message-ID: <20071010152026.GA76174@ussenterprise.ufp.org> In a message written on Wed, Oct 10, 2007 at 09:39:22AM -0500, Stephen Sprunk wrote: > What is stopping someone from putting "Upon adoption by all other RIRs" in > the "Timetable for implementation" slot of the policy template? We could > pass a proposal but it wouldn't go into the NRPM or be implemented by staff > until that occurred. Given how nearly all proposals give a timetable of > "immediately", such a trick seems like the only purpose for having that > field... Truthfully, I'm not entirely clear. If you look at http://www.nro.net/documents/nro4.html the problem seems to be in step 4: ] 4. This common text will be ratified by each RIR, by methods of its own ] choosing. I'm not sure if it's ARIN's interpretation, or the NRO's interpretation of ARIN's policies, but "ratified" seems to mean a passed policy proposal added to the NRPM. That's not to say it has to be implemented, e.g. ARIN actively doing what it is the policy states, but it needs to be in the ARIN NRPM somewhere. This gives rise to some fairly absurd (at least to me) situations. Consider this global policy: http://www.nro.net/policy/iana-rir-ipv6-allocation-proposal.html So the RIR's have to each put in their own policy process information on how IANA is going to hand them blocks as if it were so, so the NRO can approve it and then IANA can do it. It's just backwards. How IANA hands out space to RIR's should not appear in any RIR's policy manuals, that's not something an RIR can implement. RIR's should have input, and the method of making that policy should be bottom up; I don't want to change any of that. I do feel strongly there should be a way for RIR's to send off delegates or statements or something though to the central policy making group and have this end up as a central, global policy in a much more straight forward method though. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From Ed.Lewis at neustar.biz Wed Oct 10 11:36:49 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 10 Oct 2007 11:36:49 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <200710101400.l9AE07L6027929@localhost.localdomain> References: <7.0.1.0.1.20071009101612.0456d698@lacnic.net> <470BD469.5040209@internap.com> <200710101400.l9AE07L6027929@localhost.localdomain> Message-ID: Taking a quote potentially out of context... At 10:00 -0400 10/10/07, Thomas Narten wrote: >IMO, the process for getting globally-coordinated policies adopted >locally within each region has signficant flaws. For starters, in an >ideal world, it takes 2 cycles in each RIR to get something done. I agree that the process of getting a "global policy" approved has flaws. What can be done? For one I think policies should be labeled as global or local and have different process paths in each RIR. Not that the processed need to be similar to each other, but speaking from general ARIN experience and the IPv4 Countdown example, I don't think the one process ARIN has is the right fit for global policies. It's not the fault of the ARIN process, the ARIN process fits well for ARIN region policies. It's because the global policy has to cycle through each RIR - a result of the calendar of RIR meetings (they are clumped together without overlapping) and that each region has a different perspective. (Vividly I recall witnessing the progression of a policy from ARIN to RIPE to APNIC that took surprising turns as it was presented from one place to the next, each time tuned to the previous audience.) What I think is best is for the originator (instigator) of the policy to quickly assemble an ad hoc group representing all of the regions. The goal of the inter-RIR ad hoc group formation is to try to beat out the right words for the proposal that will fit into each region's Internet dialect. The reason for this is that the current road filled with cycles of present, get beaten up, fix, and present to the next region. There is cycling through the RIRs for the instigator, there are cycles inside the RIR for consideration by the audiences. It would be good to be able to make the process more parallel, to get the edits from one region fed into the proposal in other regions. Otherwise I don't think we will see any more global policies passed - assuming we need them. (And if we do see some, they might be approved way too late.) I think too that because of regional differences in policy proposals processes, messages from one meeting to the next (e.g., from APNIC's to ARIN's) gets confusing. The ARIN straw poll is often confused for a vote, having a proposal on the table is sometimes used as a statement of endorsement when presenting to the next RIR on the calendar. It's good that we have cross attendees to the meetings to help straighten out mistaken messages, but cross attendees (whether RIR staff or others) are bearing a cost to do this. I don't have a desire to make it easier for globally policy proposals to succeed. But I think the current process is too slow for the ones we do need and it is rather confusing. I think instigators should be able to do more ad hoc outreach (which is something they can do) but I also think that with in the ARIN region we have a separate (perhaps quite similar, but still) process for global policy proposals. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From dean at av8.com Wed Oct 10 14:01:20 2007 From: dean at av8.com (Dean Anderson) Date: Wed, 10 Oct 2007 14:01:20 -0400 (EDT) Subject: [ppml] Legacy Legal Defense Fund and Legacy Registry (fwd) Message-ID: Some legacy's have emailed me off-list with interest in setting up a legal defense fund, and to investigate the idea of forming a new registry to handle legacy assignments. I've started the work on forming the defense fund. Legacy's can mail me directly for details. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From owen at delong.com Wed Oct 10 14:21:03 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Oct 2007 11:21:03 -0700 Subject: [ppml] [arin-discuss] Legacy Legal Defense Fund and Legacy Registry In-Reply-To: References: Message-ID: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> Defense from what? While there are a few people on the PPML and arin-discuss who have suggested various forms of fee structures and such, but, there hasn't been anything even close to consensus in favor of such a thing. I believe that the majority of ARIN members support the idea of outreach and desire to build a positive relationship with legacy holders working towards a situation where legacy holders join the ARIN fold and there is no longer a need for such a distinction. Most legacy holders I talk to do not see the $100/year fee as a significant issue. Most do not have a significant issue with the idea of an RSA which preserves their status quo. I think both are feasible and I believe that is what the majority of the ARIN community supports. Further, I believe that support for that includes the idea that both of those things should be voluntary on the part of the legacy holder, although there are some who support a policy of terminating WHOIS and RDNS services for legacy holders who do not sign up within some time period. Frankly, I'd oppose the idea of terminating such services. As to an alternate registry, I think such an action is very premature and unnecessary. I also think that it would be unlikely to succeed or get buy-in from IANA or DOC, whichever one you choose to believe has theoretical control of said address space. Owen On Oct 10, 2007, at 11:00 AM, Dean Anderson wrote: > Some legacy's have emailed me off-list with interest in setting up a > legal defense fund, and to investigate the idea of forming a new > registry to handle legacy assignments. I've started the work on > forming > the defense fund. Legacy's can mail me directly for details. > > --Dean > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > _______________________________________________ > ARIN-Discuss > You are receiving this message because you are subscribed to the > ARIN Discussion > Mailing List (ARIN-discuss at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-discuss Please contact > the ARIN Member > Services Help Desk at info at arin.net if you experience any issues. From steveb at eagle.ca Wed Oct 10 14:54:13 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Wed, 10 Oct 2007 14:54:13 -0400 Subject: [ppml] [arin-discuss] Legacy Legal Defense Fund and Legacy Registry In-Reply-To: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> References: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> Message-ID: <470D1FD5.9050405@eagle.ca> > Further, I believe > that support for that includes the idea that both of those things should > be voluntary on the part of the legacy holder, although there are some > who support a policy of terminating WHOIS and RDNS services for > legacy holders who do not sign up within some time period. > > Frankly, I'd oppose the idea of terminating such services. The only way termination would be fair IMHO, would be in a case where a legacy holder applied for additional address space (be it v6 or v4) and was eventually caught having lied about holding any legacy space on the application. Perhaps the application templates should have an implicit 'List any legacy IP address space you currently control, whether in use or not' under the justification section, in addition to the current 'Indicate all IP addresses in use in your network today'? Steve From stephen at sprunk.org Wed Oct 10 15:03:12 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 10 Oct 2007 14:03:12 -0500 Subject: [ppml] Proposal for the creation of a working group. References: <20071010141853.GA69818@ussenterprise.ufp.org><007c01c80b4e$519d5840$523816ac@atlanta.polycom.com> <20071010152026.GA76174@ussenterprise.ufp.org> Message-ID: <00c801c80b70$7157eed0$523816ac@atlanta.polycom.com> Thus spake"Leo Bicknell" > In a message written on Wed, Oct 10, 2007 at 09:39:22AM -0500, Stephen > Sprunk wrote: >> What is stopping someone from putting "Upon adoption by all >> other RIRs" in the "Timetable for implementation" slot of the >> policy template? We could pass a proposal but it wouldn't go >> into the NRPM or be implemented by staff until that occurred. >> Given how nearly all proposals give a timetable of >> "immediately", such a trick seems like the only purpose for >> having that field... > > Truthfully, I'm not entirely clear. If you look at > http://www.nro.net/documents/nro4.html the problem seems to > be in step 4: > > ] 4. This common text will be ratified by each RIR, by methods of > ] its own choosing. > > I'm not sure if it's ARIN's interpretation, or the NRO's interpretation > of ARIN's policies, but "ratified" seems to mean a passed policy > proposal added to the NRPM. That's not to say it has to be > implemented, e.g. ARIN actively doing what it is the policy states, > but it needs to be in the ARIN NRPM somewhere. ARIN's world is a bit different due to having a single monolithic manual as opposed to publishing each individual policy that has been passed; this is IMHO superior as a reference work for applicants and staff, but it puts us at odds with how the other RIRs work when it comes to inter-RIR matters. Still, I don't think this should be an obstacle for the NRO's purposes. The text shouldn't need to be identical (heck, what are we supposed to do if LACNIC passes their policies in Spanish?) as long as the effect and intent is the same. My interpretation is that ARIN could pass a policy proposal, which would satisfy the NRO's needs, but not implement it or add it to the NRPM until the other RIRs passed it as well. We might end up deciding not to add it into the NRPM at all, though that's more a matter for the BoT to discuss. IIRC, there is nothing in the Charter that requires a NRPM in the first place -- just that the BoT vote on policy proposals. > RIR's should have input, and the method of making that policy > should be bottom up; I don't want to change any of that. I do feel > strongly there should be a way for RIR's to send off delegates > or statements or something though to the central policy making > group and have this end up as a central, global policy in a much > more straight forward method though. Sending delegates means some method of selecting delegates and hoping they'll do something the community would have formed consensus around anyways. I don't like that model. I'm growing to like the proposal for a inter-RIR WG. Such a group would work together to draft a single coherent proposal, present it to all the RIR communities simultaneously, collect feedback, and reconcile the changes needed to gain consensus (if possible) within one or two policy cycles. This would at least be superior to the current process of authors chasing whatever RIR has its meeting next, making changes, then getting shot down in the next one -- lather, rinse, repeat. The fundamental problem, of course, is what if it's simply not possible to get the various RIRs to agree on anything due to divergent views on a particular topic? It's entirely possible we'll still be bickering about v4 allocations to RIRs after the last one is handed out... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From mksmith at adhost.com Wed Oct 10 15:52:09 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Wed, 10 Oct 2007 12:52:09 -0700 Subject: [ppml] [arin-discuss] Legacy Legal Defense Fund and Legacy Registry In-Reply-To: References: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> Message-ID: <17838240D9A5544AAA5FF95F8D5203160297F0E6@ad-exh01.adhost.lan> Hello Dean: > -----Original Message----- > From: arin-discuss-bounces at arin.net [mailto:arin-discuss- > bounces at arin.net] On Behalf Of Dean Anderson > Sent: Wednesday, October 10, 2007 12:35 PM > To: Owen DeLong > Cc: arin-discuss at arin.net; Public Policy Mailing List > Subject: Re: [arin-discuss] Legacy Legal Defense Fund and Legacy > Registry > > On Wed, 10 Oct 2007, Owen DeLong wrote: > > > Defense from what? > > Defense from ARIN, if it decides there are no legal obligations to > Legacies. > I thought we had already established that there is no legal obligation today, let alone moving forward. The services provided by ARIN for legacy address holders are based upon a "moral" obligation agreed upon in principal when ARIN was first formed. > > As to an alternate registry, I think such an action is very premature > > and unnecessary. > > That's why we investigate the option. Its never premature to > investigate > the options. > > Having a separate registry certainly solves the problem of non-legacy's > continuing to want to impose new rules on Legacies. And it solves the > continuing problem of non-legacy's complaining about having to pay for > legacy services. > > Some of ARINs resources would be transferred to the Legacy Registry in > order to severe and terminate ARIN's obligations, probably a > significant > chunk of ARIN surplus, whois software, etc. An annuity on say, > $15million, would probably fund a Legacy registry forever, since the > Legacy's don't impose a significant burden on changes and there are no > new legacy's. Its a fixed cost operation. In-addr.arpa is already > merged from several registry's. And then provide electronic whois > services. > > It looks like a pretty good idea so far. > If a separate registry was formed, it seems to me that the funding for this registry would be accounted for from within the membership, i.e. the legacy address holders participating in the registry. I can't think of a reason why ARIN would be responsible for these costs. As a Member, it concerns me that the legacy holders only pay $100.00 into the coffers, although I understand the reasoning. Having my contributed dollars allocated to a registry that I will never use doesn't seem like an appropriate use of funds. Then again, you don't approve of the 50k going to NANOG and I do, so to each his own. > > I also think that it would be unlikely to succeed or get buy-in from > > IANA or DOC, whichever one you choose to believe has theoretical > > control of said address space. > > If the Legacy community decides it wants to have its own registry. I > don't know why IANA (a DoC function performed under contract by ICANN) > or DoC would object to their wishes. > Only one way to know. Regards, Mike From stephen at sprunk.org Wed Oct 10 16:59:38 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 10 Oct 2007 15:59:38 -0500 Subject: [ppml] [arin-discuss] Legacy Legal Defense Fund and LegacyRegistry References: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> <17838240D9A5544AAA5FF95F8D5203160297F0E6@ad-exh01.adhost.lan> Message-ID: <016901c80b84$cf40faf0$523816ac@atlanta.polycom.com> Thus spake "Michael K. Smith - Adhost" > If a separate registry was formed, it seems to me that the > funding for this registry would be accounted for from within the > membership, i.e. the legacy address holders participating in the > registry. I can't think of a reason why ARIN would be responsible > for these costs. I am assuming that Dean's theory is that ARIN promised to provide registry services for legacy holders, therefore it would fund a separate registry to do so. However, doing so would impose additional costs due to the separation of operations, and therefore it doesn't make fiscal sense. In reality, the creation of such a registry (if it were possible) would release ARIN from its moral obligation and need to be funded by its registrants. Note that these folks are the subset of ARIN registrants who have largely refused to pay ARIN money for the services they receive today, so I fail to see how an alternate registry, without fee-paying registrants, would be able to operate. > As a Member, it concerns me that the legacy holders only pay > $100.00 into the coffers, although I understand the reasoning. Actually, the vast majority of them pay nothing. Only a very few, AFAIK, have joined the ARIN process and pay the $100/yr maintenance fee. The remainder get their registration services for free, funded by the (mostly non-legacy) fee-paying members of the community. Those folks're getting a free ride. Frankly, it'd be a lot cheaper for them to join PPML and shout down any policy proposal that would adversely affect them (which costs exactly $0) than it would be to form any sort of "legal defense fund" -- which is a misleading name itself, since that term is commonly used for "defense" against lawsuits, and there is no indication that ARIN has any intent of suing anybody. What it really is is a "legal attack fund", i.e. a way for legacy holders to pool their money to sue ARIN. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From tedm at ipinc.net Wed Oct 10 18:48:13 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 10 Oct 2007 15:48:13 -0700 Subject: [ppml] [arin-discuss] Legacy Legal Defense Fund and LegacyRegistry In-Reply-To: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Owen DeLong >Sent: Wednesday, October 10, 2007 11:21 AM >To: Dean Anderson >Cc: arin-discuss at arin.net; Public Policy Mailing List >Subject: Re: [ppml] [arin-discuss] Legacy Legal Defense Fund and >LegacyRegistry > > >Defense from what? > >While there are a few people on the PPML and arin-discuss who have >suggested various forms of fee structures and such, but, there hasn't >been anything even close to consensus in favor of such a thing. > Such a group of legacy holders wouldn't even be able to gain consensus to create an RFP for 5,000 tinfoil hats. >I believe that the majority of ARIN members support the idea of outreach >and desire to build a positive relationship with legacy holders working >towards a situation where legacy holders join the ARIN fold and there >is no longer a need for such a distinction. > A lot of legacy holders have BOTH legacy assignments and non-legacy assignments. And ANY legacy holder that has ANY IPv6 also has a foot in both sides. >Most legacy holders I talk to do not see the $100/year fee as a >significant >issue. Most do not have a significant issue with the idea of an RSA >which >preserves their status quo. I think both are feasible and I believe >that >is what the majority of the ARIN community supports. I do not agree. I think that the majority of the community supports legacy holder status on IPv4 ONLY. I believe some of this smoke and mirrors is an attempt by certain people to get legacy status applied to "IP numbering" in general, rather than "IPv4 IP numbering" that is why they use such imprecise language all the time, constantly blurring the distinction between IPv4 and IPv6 numbering. If you look at ALL of Dean's responses to the subject you will find that he NEVER uses the precise terms "IPv4 IP numbering" and "IPv6 numbering" when referring to legacy holders. When people point this out he ignores it most of the time, the few times he responds it's along the line that the definition of a legacy holder is an IPv4 holder - conveniently ignoring that all the historical literature he's basing his arguments on is pre-IPv6 and thus DOES NOT draw a distinction either. > >As to an alternate registry, I think such an action is very premature >and >unnecessary. I also think that it would be unlikely to succeed or get >buy-in from IANA or DOC, whichever one you choose to believe >has theoretical control of said address space. > I really think the whole thing is preposterous. I can think of many reasons that infighting, lack of legal jurisdiction in different regions, the fact that many legacy holders would have to start paying twice - once for IPv6 resources to ARIN and once to this alternate registry, and the fact that an alternate would have no support from the existing governing structure, would doom such an effort. Keep in mind that an alternate registry couldn't force ARIN to update it's whois - and ARIN will not replace legacy WHOIS records to allow legacy numbers to be sold to a new entity, that's against current policy. The more you think about it the more silly it becomes. Just because it's possible to do something doesen't mean it's ever going to happen. I think Dean is confusing the possible with the practical. Ted From ez at zoovy.com Wed Oct 10 19:46:29 2007 From: ez at zoovy.com (Eric Ziegast) Date: Wed, 10 Oct 2007 16:46:29 -0700 Subject: [ppml] Elections (Re: ARIN IP conservation and FREE IP Addresses) In-Reply-To: <2E0D9844-08F4-46F3-A569-D5E0B9E8CD67@virtualized.org> References: <200710060645430.SM02832@mikesplace> <3c3e3fca0710060711m7f378037tda87b00cbafa0b96@mail.gmail.com> <20071006160015.GB41201@ussenterprise.ufp.org> <2E0D9844-08F4-46F3-A569-D5E0B9E8CD67@virtualized.org> Message-ID: <470D6455.2090500@zoovy.com> David Conrad wrote: > Where are these ARIN meetings in which these "hundreds if not > thousands" of companies are participating? The ARIN meetings I go to > (and the e-mail discussions I see) have the same few dozen of people, > most of which are funded by their very large corporations to attend > said meetings. > As a member of ARIN lurking from a small corner of the Internet, I'd like to remind other members that they should make sure they're registered to vote and encourage them to participate in any upcoming elections (mid-late October?). https://app.arin.net/election/ Also, members should look at simulcast info before the Albuquerque meeting if they can't attend. http://www.arin.net/ARIN-XX/webcast.html David continues: > I will also note that it is the very large corporations who have the > lawyers who can pummel ARIN into the ground if policies change in a > way they don't particularly like (regardless of the merit or legality > of those changes). Welcome to business in the USA... Team ARIN! Help us! Cili Rool is sending in the lawyers! Would a legal defense fund be a good place to stash that extra IPV4 renewal money? ;^) -- Eric Ziegast PS: Hi, y'all! From owen at delong.com Wed Oct 10 20:29:53 2007 From: owen at delong.com (Owen DeLong) Date: Wed, 10 Oct 2007 17:29:53 -0700 Subject: [ppml] [arin-discuss] Legacy Legal Defense Fund and Legacy Registry In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160297F0E6@ad-exh01.adhost.lan> References: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> <17838240D9A5544AAA5FF95F8D5203160297F0E6@ad-exh01.adhost.lan> Message-ID: > > If a separate registry was formed, it seems to me that the funding for > this registry would be accounted for from within the membership, i.e. > the legacy address holders participating in the registry. I can't > think > of a reason why ARIN would be responsible for these costs. As a > Member, > it concerns me that the legacy holders only pay $100.00 into the > coffers, although I understand the reasoning. Having my contributed > dollars allocated to a registry that I will never use doesn't seem > like > an appropriate use of funds. Then again, you don't approve of the 50k > going to NANOG and I do, so to each his own. > You are mistaken here... Legacy holders don't pay anything into the coffers. Those who have End-User assignments under RSA pay $100/year regardless of whether they were previously legacy holders, or, whether they are ARIN issued direct assignments. Owen From plzak at arin.net Thu Oct 11 06:25:06 2007 From: plzak at arin.net (Ray Plzak) Date: Thu, 11 Oct 2007 06:25:06 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <20071010152026.GA76174@ussenterprise.ufp.org> References: <20071010141853.GA69818@ussenterprise.ufp.org> <007c01c80b4e$519d5840$523816ac@atlanta.polycom.com> <20071010152026.GA76174@ussenterprise.ufp.org> Message-ID: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Leo Bicknell > Sent: Wednesday, October 10, 2007 11:20 AM > To: ARIN PPML > Subject: Re: [ppml] Proposal for the creation of a working group. > > How IANA hands out space to RIR's should not appear in any RIR's policy > manuals, that's not something an RIR can implement. Leo - If you look the Global v4 and v6 policy both contain criteria that the RIRs must follow, hence must implement. Ray From bicknell at ufp.org Thu Oct 11 08:30:10 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 11 Oct 2007 08:30:10 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: References: <20071010141853.GA69818@ussenterprise.ufp.org> <007c01c80b4e$519d5840$523816ac@atlanta.polycom.com> <20071010152026.GA76174@ussenterprise.ufp.org> Message-ID: <20071011123009.GA80329@ussenterprise.ufp.org> In a message written on Thu, Oct 11, 2007 at 06:25:06AM -0400, Ray Plzak wrote: > Leo - If you look the Global v4 and v6 policy both contain criteria > that the RIRs must follow, hence must implement. I have no problem with those elements being put into ARIN's NRPM. Rather than being one or two line items buried in section 10 of the manual, 90% of which ARIN staff cannot implement those items should be pulled out and integrated into the appropriate section of the manual. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From info at arin.net Thu Oct 11 17:21:17 2007 From: info at arin.net (Member Services) Date: Thu, 11 Oct 2007 17:21:17 -0400 Subject: [ppml] Legacy RSA Message-ID: <470E93CD.4080506@arin.net> On 17 October 2007 ARIN will release an additional version of the Registration Services Agreement ("RSA") that will be offered to those organizations and individuals in the ARIN service region who hold legacy Internet number resources that are not covered by any other registration services agreement with ARIN. Legacy holders who sign up are guaranteed the same services as ARIN members. The low annual fees charged may be waived if the organization returns unused address space. This legacy RSA also contractually promises ARIN Internet number resource policies adopted after the contract is signed will not lessen the legacy RSA address holder?s contract rights. This legacy RSA will be described during presentations at the upcoming NANOG meeting, ARIN Public Policy Meeting, and ARIN Members meeting. Regards, Raymond A. Plzak President & CEO American Registry for Internet Numbers (ARIN) From Keith at jcc.com Thu Oct 11 20:13:34 2007 From: Keith at jcc.com (Keith W. Hare) Date: Thu, 11 Oct 2007 20:13:34 -0400 Subject: [ppml] [arin-announce] Legacy RSA Message-ID: Ray, I look forward to reading this RSA. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ > -----Original Message----- > From: arin-announce-bounces at arin.net > [mailto:arin-announce-bounces at arin.net] On Behalf Of Member Services > Sent: Thursday, October 11, 2007 5:21 PM > To: arin-announce at arin.net; ppml at arin.net > Subject: [arin-announce] Legacy RSA > > On 17 October 2007 ARIN will release an additional version of > the Registration Services Agreement ("RSA") that will be > offered to those organizations and individuals in the ARIN > service region who hold legacy Internet number resources that > are not covered by any other registration services agreement > with ARIN. Legacy holders who sign up are guaranteed the same > services as ARIN members. The low annual fees charged may be > waived if the organization returns unused address space. This > legacy RSA also contractually promises ARIN Internet number > resource policies adopted after the contract is signed will > not lessen the legacy RSA address holder's contract rights. > > This legacy RSA will be described during presentations at the > upcoming NANOG meeting, ARIN Public Policy Meeting, and ARIN > Members meeting. > > Regards, > > Raymond A. Plzak > President & CEO > American Registry for Internet Numbers (ARIN) > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce Please > contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. > From cliffb at cjbsys.bdb.com Thu Oct 11 22:29:04 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Thu, 11 Oct 2007 22:29:04 -0400 (EDT) Subject: [ppml] Re Legacy RSA Message-ID: <200710120229.l9C2T4I7017512@cjbsys.bdb.com> I also am very interested in reading this proposal. Cliff -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From martin.hannigan at batelnet.bs Fri Oct 12 01:49:06 2007 From: martin.hannigan at batelnet.bs (Martin Hannigan) Date: Fri, 12 Oct 2007 01:49:06 -0400 Subject: [ppml] Proposal for the creation of a working group. Message-ID: <470f0ad2.179.35f.9062@batelnet.bs> ----- Original Message ----- From: Raul Echeberria To: ppml at arin.net Subject: [ppml] Proposal for the creation of a working group. Date: Tue, 09 Oct 2007 10:17:58 -0300 > Dear all: > > I would like to share with all of you this > proposal. Since it is not a policy proposal, I > don't know really how to proceed, but I guess > that it is enough to send it to the list. > > This proposal doesn't intend to substitute the > Policy Proposal "2007-16 IPv4 Soft Landing" and > is not incompatible with the discussion of this > proposal and/or its eventual adoption. > > I will send the same proposal to the others RIRs' poilicy > lists. > > Ra?l > > > ========================================= > Proposal for the creation of a cross-regions working group > > > > Some proposals have been submitted through some > RIR?s policy development process, which focus on > the gradual modification of the requirements for > receiving IPv4 addresses as the pool of unallocated IPv4 > addresses diminishes. > > Most or all proposals which have been made appear > to be incomplete and ineffective if approved in > only one region. Therefore, it is proposed the > creation of a working group made up by two > appropriate respected individuals active in the > policy process within each region?s community. > These ten individuals would work on one or more > joint proposals that could then be processed in > every region according to their corresponding policy > development processes. Could be perceived as an attempt to manipulate regional PDP's. Are you asking for the RIR's to officially sanction this? Or as you just asking for volunteers? If it's the latter, and you are suggesting that whatever came out of such a thing would have to still traverse the ARIN PDP and ICANN MoU/Attachment global policy process, this sounds just fine to me. -M< From raul at lacnic.net Fri Oct 12 09:45:41 2007 From: raul at lacnic.net (Raul Echeberria) Date: Fri, 12 Oct 2007 10:45:41 -0300 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <470f0ad2.179.35f.9062@batelnet.bs> References: <470f0ad2.179.35f.9062@batelnet.bs> Message-ID: <7.0.1.0.1.20071012102857.0411d808@lacnic.net> Dear all: Just to clarify. There have been many interesting comments about the Global Policy Development Process, and I think that those comments could be the basis for a revision of that process, but I am not proposing now to develop a global policy. IMO at some point, the RIRs have to start to apply different criteria for allocating IPv4 addresses. In fact, we have already seen some proposals like David's one. The problem that I see is that it will be difficult that some RIRs adopt that kind of policies if the others don't do that. So, the working group would analyze the issue from a multiregional perspective (I am avoinding to use the word "global") and conclude if a common proposal could be presented in every region or different policy proposal for each region , but based in the same concept and aiming the same objective, would be more appropriate. The proposal or proposals should go later trhough each regional PDP, so this WG would not be an intereference with the currently established PDPs. As John commmented in his mail, the goal is to increase the probability of approval of the WG suggestions and get all the RIRs moving in the same direction with exactly the same policies or not. Ra?l From raul at lacnic.net Fri Oct 12 09:55:29 2007 From: raul at lacnic.net (Raul Echeberria) Date: Fri, 12 Oct 2007 10:55:29 -0300 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <470f0ad2.179.35f.9062@batelnet.bs> References: <470f0ad2.179.35f.9062@batelnet.bs> Message-ID: <7.0.1.0.1.20071012105326.036b2fe8@lacnic.net> At 02:49 a.m. 12/10/2007, Martin Hannigan wrote: >Could be perceived as an attempt to manipulate regional >PDP's. I don't think so. > Are you asking for the RIR's to officially sanction >this? Or as you just asking for volunteers? I think that the WG could be composed by people with relevant roles in their region's PDP, like policy chairs or Advisory group members. I don't think it needs an official sanction. >If it's the latter, and you are suggesting that whatever >came out of such a thing would have to still traverse the >ARIN PDP and ICANN MoU/Attachment global policy process, That's exactly what i propose. >this sounds just fine to me. Thanks, Ra?l From kkargel at polartel.com Fri Oct 12 10:25:59 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 12 Oct 2007 09:25:59 -0500 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: <470E93CD.4080506@arin.net> References: <470E93CD.4080506@arin.net> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670763D@mail> That's a pretty good deal. I wish I could get it in my contract that my rights would never be lessened even if policy changed. Kevin > -----Original Message----- > From: arin-announce-bounces at arin.net > [mailto:arin-announce-bounces at arin.net] On Behalf Of Member Services > Sent: Thursday, October 11, 2007 4:21 PM > To: arin-announce at arin.net; ppml at arin.net > Subject: [arin-announce] Legacy RSA > > On 17 October 2007 ARIN will release an additional version of > the Registration Services Agreement ("RSA") that will be > offered to those organizations and individuals in the ARIN > service region who hold legacy Internet number resources that > are not covered by any other registration services agreement > with ARIN. Legacy holders who sign up are guaranteed the same > services as ARIN members. The low annual fees charged may be > waived if the organization returns unused address space. This > legacy RSA also contractually promises ARIN Internet number > resource policies adopted after the contract is signed will > not lessen the legacy RSA address holder's contract rights. > > This legacy RSA will be described during presentations at the > upcoming NANOG meeting, ARIN Public Policy Meeting, and ARIN > Members meeting. > > Regards, > > Raymond A. Plzak > President & CEO > American Registry for Internet Numbers (ARIN) > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce Please > contact the ARIN Member Services Help Desk at info at arin.net > if you experience any issues. > From Ed.Lewis at neustar.biz Fri Oct 12 11:46:46 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 12 Oct 2007 11:46:46 -0400 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <7.0.1.0.1.20071012105326.036b2fe8@lacnic.net> References: <470f0ad2.179.35f.9062@batelnet.bs> <7.0.1.0.1.20071012105326.036b2fe8@lacnic.net> Message-ID: At 10:55 -0300 10/12/07, Raul Echeberria wrote: >I think that the WG could be composed by people >with relevant roles in their region's PDP, like >policy chairs or Advisory group members. >I don't think it needs an official sanction. I think it is better if the WG is ad hoc and does not have an official sanction, even if the members have "designated" positions (like chairs, elected members, even staff). In theory the output would be a "considered opinion" yet not have any special (preferred) status while going through the individual policy development processes. If the group is set up, mail list, telecons, in person meetings over the next three weeks of RIR-type travel, I'd volunteer to participate. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From sleibrand at internap.com Fri Oct 12 13:19:06 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 12 Oct 2007 10:19:06 -0700 Subject: [ppml] Proposal for the creation of a working group. In-Reply-To: <7.0.1.0.1.20071012102857.0411d808@lacnic.net> References: <470f0ad2.179.35f.9062@batelnet.bs> <7.0.1.0.1.20071012102857.0411d808@lacnic.net> Message-ID: <470FAC8A.8080209@internap.com> Raul, Thanks for the clarification. Notwithstanding my earlier comments, I support such an effort, provided that (as you state below) the output still goes through the normal policy development process (albeit hopefully more smoothly, the proposal having been crafted to achieve consensus). Thanks for your efforts, Scott Raul Echeberria wrote: > Dear all: > > Just to clarify. > There have been many interesting comments about > the Global Policy Development Process, and I > think that those comments could be the basis for > a revision of that process, but I am not > proposing now to develop a global policy. > > IMO at some point, the RIRs have to start to > apply different criteria for allocating IPv4 > addresses. In fact, we have already seen some proposals like David's one. > The problem that I see is that it will be > difficult that some RIRs adopt that kind of > policies if the others don't do that. > So, the working group would analyze the issue > from a multiregional perspective (I am avoinding > to use the word "global") and conclude if a > common proposal could be presented in every > region or different policy proposal for each > region , but based in the same concept and aiming > the same objective, would be more appropriate. > > The proposal or proposals should go later trhough > each regional PDP, so this WG would not be an > intereference with the currently established PDPs. > > As John commmented in his mail, the goal is to > increase the probability of approval of the WG > suggestions and get all the RIRs moving in the > same direction with exactly the same policies or not. > > Ra?l > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From drc at virtualized.org Fri Oct 12 13:44:11 2007 From: drc at virtualized.org (David Conrad) Date: Fri, 12 Oct 2007 10:44:11 -0700 Subject: [ppml] [arin-discuss] Legacy Legal Defense Fund and Legacy Registry In-Reply-To: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> References: <86D16A98-BE5F-4215-95F7-E9B2795074BD@delong.com> Message-ID: Not commenting on Dean's suggestion, but to clarify one bit: On Oct 10, 2007, at 11:21 AM, Owen DeLong wrote: > As to an alternate registry, I think such an action is very premature > and unnecessary. I also think that it would be unlikely to succeed > or get buy-in from IANA or DOC, whichever one you choose to believe > has theoretical control of said address space. If I understand what is being suggested, IANA or US government buy-in is irrelevant. Anyone at any time can create their own IP registration database. What matters is whether or not anyone (particularly ISPs when they determining whether or not to accept a customer's assertion that the customer "owns" the address space being presented to the ISP) looks at it. Regards, -drc From tedm at ipinc.net Fri Oct 12 14:19:43 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 12 Oct 2007 11:19:43 -0700 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A06314106670763D@mail> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Kevin Kargel >Sent: Friday, October 12, 2007 7:26 AM >To: ppml at arin.net >Subject: Re: [ppml] [arin-announce] Legacy RSA > > > That's a pretty good deal. I wish I could get it in my contract that >my rights would never be lessened even if policy changed. > Kevin, don't forget ARIN defines legacy holders as IPv4 holders. IPve ONLY. In ARIN's definitions, there is no such thing as an "IPv6 Legacy Holder" I'll be happy to write you a contract that states unequiocably that you have permanent, perpetual rights in how to configure any one of a box of Latticenet cards I happened to see in a junk store a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) My only concern with the "Legacy RSA" is that somewhere within it, there is a statement that the term "Legacy holder" means "IPv4 only holder" That way there is no chance in the future that some court could misinterpret the contract and use it to extend over IPv6 assignments. This really comes down to your position on moving to IPv6. The official word is that IPv4 runout is a fact, and that IPv6 will replace it. There are, unfortunately, a lot of people out there (like Dean) who apparently think that they can manipulate the system into making the Internet some sort of permanent shared IPv4/IPv6 environment - if that were to happen, the assignments of the Legacy holders would become a permanent, unpaid, drag on the Internet. But in the last analysis, the so called "rights of the (IPv4) Legacy holders" are only of value as long as the rest of us continue to keep routing their legacy traffic - ie: their IPv4 traffic. Ask yourself, what is a reasonable expectation as to how long the rest of the Internet will be willing to continue to do this, before telling the Legacy holders (and, indeed, ALL IPv4 holders) that they must switch to IPv6. That is the true length of time that these so called "rights" will have any actual value. Ted From mike at mathbox.com Fri Oct 12 14:29:55 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 12 Oct 2007 14:29:55 -0400 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: Message-ID: <200710121430457.SM02952@mikesplace> First let me state that I am not a legacy holder. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Friday, October 12, 2007 2:20 PM > To: Kevin Kargel; ppml at arin.net > Subject: Re: [ppml] [arin-announce] Legacy RSA > > > > >-----Original Message----- > >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On > Behalf Of > >Kevin Kargel > >Sent: Friday, October 12, 2007 7:26 AM > >To: ppml at arin.net > >Subject: Re: [ppml] [arin-announce] Legacy RSA > > > > > > That's a pretty good deal. I wish I could get it in my > contract that > >my rights would never be lessened even if policy changed. > > > > Kevin, don't forget ARIN defines legacy holders as IPv4 holders. > IPve ONLY. In ARIN's definitions, there is no such thing as an > "IPv6 Legacy Holder" > > I'll be happy to write you a contract that states unequiocably that > you have permanent, perpetual rights in how to configure any one > of a box of Latticenet cards I happened to see in a junk store > a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) > > My only concern with the "Legacy RSA" is that somewhere > within it, there > is a statement that the term "Legacy holder" means "IPv4 only holder" > That way there is no chance in the future that some court could > misinterpret the contract and use it to extend over IPv6 assignments. > > This really comes down to your position on moving to IPv6. The > official word is that IPv4 runout is a fact, and that IPv6 will > replace it. There are, unfortunately, a lot of people out there > (like Dean) who apparently think that they can manipulate the system > into making the Internet some sort of permanent shared IPv4/IPv6 > environment - if that were to happen, the assignments of the Legacy > holders would become a permanent, unpaid, drag on the Internet. You do not consider the free 900,000+ /24 held by Xtra Large members unpaid, drag on the Internet? > > But in the last analysis, the so called "rights of the (IPv4) Legacy > holders" are only of value as long as the rest of us continue to keep > routing their legacy traffic - ie: their IPv4 traffic. Ask yourself, > what is a reasonable expectation as to how long the rest of > the Internet > will be willing to continue to do this, before telling the Legacy > holders (and, indeed, ALL IPv4 holders) that they must switch to IPv6. > That is the true length of time that these so called "rights" > will have > any actual value. > > Ted > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From tedm at ipinc.net Fri Oct 12 15:11:21 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 12 Oct 2007 12:11:21 -0700 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: <200710121430457.SM02952@mikesplace> Message-ID: >-----Original Message----- >From: Michael Thomas - Mathbox [mailto:mike at mathbox.com] >Sent: Friday, October 12, 2007 11:30 AM >To: 'Ted Mittelstaedt'; 'Kevin Kargel'; ppml at arin.net >Subject: RE: [ppml] [arin-announce] Legacy RSA > > >First let me state that I am not a legacy holder. > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Ted Mittelstaedt >> Sent: Friday, October 12, 2007 2:20 PM >> To: Kevin Kargel; ppml at arin.net >> Subject: Re: [ppml] [arin-announce] Legacy RSA >> >> >> >> >-----Original Message----- >> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >> Behalf Of >> >Kevin Kargel >> >Sent: Friday, October 12, 2007 7:26 AM >> >To: ppml at arin.net >> >Subject: Re: [ppml] [arin-announce] Legacy RSA >> > >> > >> > That's a pretty good deal. I wish I could get it in my >> contract that >> >my rights would never be lessened even if policy changed. >> > >> >> Kevin, don't forget ARIN defines legacy holders as IPv4 holders. >> IPve ONLY. In ARIN's definitions, there is no such thing as an >> "IPv6 Legacy Holder" >> >> I'll be happy to write you a contract that states unequiocably that >> you have permanent, perpetual rights in how to configure any one >> of a box of Latticenet cards I happened to see in a junk store >> a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) >> >> My only concern with the "Legacy RSA" is that somewhere >> within it, there >> is a statement that the term "Legacy holder" means "IPv4 only holder" >> That way there is no chance in the future that some court could >> misinterpret the contract and use it to extend over IPv6 assignments. >> >> This really comes down to your position on moving to IPv6. The >> official word is that IPv4 runout is a fact, and that IPv6 will >> replace it. There are, unfortunately, a lot of people out there >> (like Dean) who apparently think that they can manipulate the system >> into making the Internet some sort of permanent shared IPv4/IPv6 >> environment - if that were to happen, the assignments of the Legacy >> holders would become a permanent, unpaid, drag on the Internet. > >You do not consider the free 900,000+ /24 held by Xtra Large >members unpaid, >drag on the Internet? > NO, of course not. The reason why is that hardly anybody now is advertising IPv6. But when most people out there advertisng IPv6 then I would assume that people who are paying for IPv4 assignments will have an incentive to return them and stop advertising them and stop getting billed for them. Everyone, that is - except these legacy IPv4 holders who are STILL going to be faced with "I either got to IPv6 and start paying a lot of money or I keep using my free IPv4 and try to convince the rest of the world to continue supporting them." If the legacy holders don't do anything they will greatly increase the amount of advertisements and cause a lot of people to delay switchover, that is the drag I'm talking about. Same goes for these "free 900,000+ /24 held by Xtra Large members" your referring to - although we are having a fee discussion on them as I'm sure you may have seen the prior posts on. ALthough it is a little early to get into this because IPv4 runout hasn't happened, you do realize of course that once IPv4 runout does happen, we will have to put into policy, incentives to get people to stop using it and to switch to IPv6. Fee adjustments are the most obvious. Ted From stephen at sprunk.org Fri Oct 12 15:06:39 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 12 Oct 2007 14:06:39 -0500 Subject: [ppml] [arin-announce] Legacy RSA References: Message-ID: <022501c80d04$6ad2f6a0$573816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" > Kevin, don't forget ARIN defines legacy holders as IPv4 holders. > IPve ONLY. In ARIN's definitions, there is no such thing as an > "IPv6 Legacy Holder" ... > My only concern with the "Legacy RSA" is that somewhere within > it, there is a statement that the term "Legacy holder" means "IPv4 > only holder" That way there is no chance in the future that some > court could misinterpret the contract and use it to extend over > IPv6 assignments. That's not exactly correct. A legacy assignment is one made before ARIN's formation. A "Legacy RSA" would logically only apply to legacy assignments. It happens that only ASNs and IPv4 assignments can be legacy; there are no legacy IPv6 assignments or allocations. If a legacy holder also has non-legacy resources, those resources would be covered under a standard RSA. I'm sure ARIN's counsel covered these bases when drafting the Legacy RSA. > But in the last analysis, the so called "rights of the (IPv4) Legacy > holders" are only of value as long as the rest of us continue to > keep routing their legacy traffic - ie: their IPv4 traffic. Ask > yourself, what is a reasonable expectation as to how long the > rest of the Internet will be willing to continue to do this, before > telling the Legacy holders (and, indeed, ALL IPv4 holders) that > they must switch to IPv6. That is the true length of time that > these so called "rights" will have any actual value. They will have value as long as ISPs are willing to take money to route their traffic. There is no reason to think ISPs will turn down their money in the forseeable future. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From mike at mathbox.com Fri Oct 12 15:26:45 2007 From: mike at mathbox.com (Michael Thomas - Mathbox) Date: Fri, 12 Oct 2007 15:26:45 -0400 Subject: [ppml] SPAM-WARN:RE: [arin-announce] Legacy RSA In-Reply-To: Message-ID: <200710121526441.SM04668@mikesplace> > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Friday, October 12, 2007 3:11 PM > To: Michael Thomas - Mathbox; 'Kevin Kargel'; ppml at arin.net > Subject: SPAM-WARN:RE: [ppml] [arin-announce] Legacy RSA > > > > >-----Original Message----- > >From: Michael Thomas - Mathbox [mailto:mike at mathbox.com] > >Sent: Friday, October 12, 2007 11:30 AM > >To: 'Ted Mittelstaedt'; 'Kevin Kargel'; ppml at arin.net > >Subject: RE: [ppml] [arin-announce] Legacy RSA > > > > > >First let me state that I am not a legacy holder. > > > >> -----Original Message----- > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >> Behalf Of Ted Mittelstaedt > >> Sent: Friday, October 12, 2007 2:20 PM > >> To: Kevin Kargel; ppml at arin.net > >> Subject: Re: [ppml] [arin-announce] Legacy RSA > >> > >> > >> > >> >-----Original Message----- > >> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On > >> Behalf Of > >> >Kevin Kargel > >> >Sent: Friday, October 12, 2007 7:26 AM > >> >To: ppml at arin.net > >> >Subject: Re: [ppml] [arin-announce] Legacy RSA > >> > > >> > > >> > That's a pretty good deal. I wish I could get it in my > >> contract that > >> >my rights would never be lessened even if policy changed. > >> > > >> > >> Kevin, don't forget ARIN defines legacy holders as IPv4 holders. > >> IPve ONLY. In ARIN's definitions, there is no such thing as an > >> "IPv6 Legacy Holder" > >> > >> I'll be happy to write you a contract that states unequiocably that > >> you have permanent, perpetual rights in how to configure any one > >> of a box of Latticenet cards I happened to see in a junk store > >> a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) > >> > >> My only concern with the "Legacy RSA" is that somewhere > >> within it, there > >> is a statement that the term "Legacy holder" means "IPv4 > only holder" > >> That way there is no chance in the future that some court could > >> misinterpret the contract and use it to extend over IPv6 > assignments. > >> > >> This really comes down to your position on moving to IPv6. The > >> official word is that IPv4 runout is a fact, and that IPv6 will > >> replace it. There are, unfortunately, a lot of people out there > >> (like Dean) who apparently think that they can manipulate > the system > >> into making the Internet some sort of permanent shared IPv4/IPv6 > >> environment - if that were to happen, the assignments of the Legacy > >> holders would become a permanent, unpaid, drag on the Internet. > > > >You do not consider the free 900,000+ /24 held by Xtra Large > >members unpaid, > >drag on the Internet? > > > > NO, of course not. The reason why is that hardly anybody now > is advertising > IPv6. Sorry, I should have articulated that more clearly. As a group, the Xtra Large Members hold 900,000+ IPV4 /24 blocks that are registered with ARIN, where said registration of those 900,000+ IPV4 /24 blocks was free of charge. Do you not consider that to be an unpaid, drag on the Internet? > > But when most people out there advertisng IPv6 then I would assume > that people who are paying for IPv4 assignments will have an incentive > to return them and stop advertising them and stop getting > billed for them. > Everyone, that is - except these legacy IPv4 holders who are > STILL going > to be faced with "I either got to IPv6 and start paying a lot of money > or I keep using my free IPv4 and try to convince the rest of the world > to continue supporting them." If the legacy holders don't do anything > they will greatly increase the amount of advertisements and > cause a lot > of people to delay switchover, that is the drag I'm talking about. > > Same goes for these "free 900,000+ /24 held by Xtra Large members" > your referring to - although we are having a fee discussion on them > as I'm sure you may have seen the prior posts on. > > ALthough it is a little early to get into this because IPv4 runout > hasn't happened, you do realize of course that once IPv4 runout does > happen, we will have to put into policy, incentives to get people > to stop using it and to switch to IPv6. Fee adjustments are the most > obvious. > > Ted Michael Thomas Mathbox 978-683-6718 1-877-MATHBOX (Toll Free) From tedm at ipinc.net Fri Oct 12 15:33:24 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 12 Oct 2007 12:33:24 -0700 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: <022501c80d04$6ad2f6a0$573816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: Stephen Sprunk [mailto:stephen at sprunk.org] >Sent: Friday, October 12, 2007 12:07 PM >To: Ted Mittelstaedt >Cc: ARIN PPML >Subject: Re: [ppml] [arin-announce] Legacy RSA > > >They will have value as long as ISPs are willing to take money to route >their traffic. There is no reason to think ISPs will turn down >their money >in the forseeable future. > Of course - but what about their upstreams, and their other upstreams, and so on? My traceroute to this very mailing list server passes through a couple of networks that I don't pay money to directly. I'm sure as long as I'm paying my feeds I'll be able to route whatever I want through them. But, I doubt it is going to go more and a hop or so and I won't be able to compel those other neworks to carry my obsolete traffic if they don't want to. The Internet isn't a fuedal system and I think a few people are going to figure that out to their distress in the not too distant future. Ted From tedm at ipinc.net Fri Oct 12 17:23:43 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 12 Oct 2007 14:23:43 -0700 Subject: [ppml] SPAM-WARN:RE: [arin-announce] Legacy RSA In-Reply-To: <200710121526441.SM04668@mikesplace> Message-ID: >-----Original Message----- >From: Michael Thomas - Mathbox [mailto:mike at mathbox.com] >Sent: Friday, October 12, 2007 12:27 PM >To: 'Ted Mittelstaedt'; 'Kevin Kargel'; ppml at arin.net >Subject: RE: SPAM-WARN:RE: [ppml] [arin-announce] Legacy RSA > > >> -----Original Message----- >> From: Ted Mittelstaedt [mailto:tedm at ipinc.net] >> Sent: Friday, October 12, 2007 3:11 PM >> To: Michael Thomas - Mathbox; 'Kevin Kargel'; ppml at arin.net >> Subject: SPAM-WARN:RE: [ppml] [arin-announce] Legacy RSA >> >> >> >> >-----Original Message----- >> >From: Michael Thomas - Mathbox [mailto:mike at mathbox.com] >> >Sent: Friday, October 12, 2007 11:30 AM >> >To: 'Ted Mittelstaedt'; 'Kevin Kargel'; ppml at arin.net >> >Subject: RE: [ppml] [arin-announce] Legacy RSA >> > >> > >> >First let me state that I am not a legacy holder. >> > >> >> -----Original Message----- >> >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> >> Behalf Of Ted Mittelstaedt >> >> Sent: Friday, October 12, 2007 2:20 PM >> >> To: Kevin Kargel; ppml at arin.net >> >> Subject: Re: [ppml] [arin-announce] Legacy RSA >> >> >> >> >> >> >> >> >-----Original Message----- >> >> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On >> >> Behalf Of >> >> >Kevin Kargel >> >> >Sent: Friday, October 12, 2007 7:26 AM >> >> >To: ppml at arin.net >> >> >Subject: Re: [ppml] [arin-announce] Legacy RSA >> >> > >> >> > >> >> > That's a pretty good deal. I wish I could get it in my >> >> contract that >> >> >my rights would never be lessened even if policy changed. >> >> > >> >> >> >> Kevin, don't forget ARIN defines legacy holders as IPv4 holders. >> >> IPve ONLY. In ARIN's definitions, there is no such thing as an >> >> "IPv6 Legacy Holder" >> >> >> >> I'll be happy to write you a contract that states unequiocably that >> >> you have permanent, perpetual rights in how to configure any one >> >> of a box of Latticenet cards I happened to see in a junk store >> >> a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) >> >> >> >> My only concern with the "Legacy RSA" is that somewhere >> >> within it, there >> >> is a statement that the term "Legacy holder" means "IPv4 >> only holder" >> >> That way there is no chance in the future that some court could >> >> misinterpret the contract and use it to extend over IPv6 >> assignments. >> >> >> >> This really comes down to your position on moving to IPv6. The >> >> official word is that IPv4 runout is a fact, and that IPv6 will >> >> replace it. There are, unfortunately, a lot of people out there >> >> (like Dean) who apparently think that they can manipulate >> the system >> >> into making the Internet some sort of permanent shared IPv4/IPv6 >> >> environment - if that were to happen, the assignments of the Legacy >> >> holders would become a permanent, unpaid, drag on the Internet. >> > >> >You do not consider the free 900,000+ /24 held by Xtra Large >> >members unpaid, >> >drag on the Internet? >> > >> >> NO, of course not. The reason why is that hardly anybody now >> is advertising >> IPv6. > >Sorry, I should have articulated that more clearly. As a group, the Xtra >Large >Members hold 900,000+ IPV4 /24 blocks that are registered with ARIN, where >said registration of those 900,000+ IPV4 /24 blocks was free of charge. Do >you not consider that to be an unpaid, drag on the Internet? > I already explained why not. Maybe someday. Not today. And to clarify, the legacy holders IPv4's are not an unpaid drag on the Internet at the current time. Once more, maybe someday. Not today. Ted From tedm at ipinc.net Fri Oct 12 17:31:57 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 12 Oct 2007 14:31:57 -0700 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: <3c3e3fca0710121258k5a8030f7xa317987a9d838a42@mail.gmail.com> Message-ID: >-----Original Message----- >From: wherrin at gmail.com [mailto:wherrin at gmail.com]On Behalf Of William >Herrin >Sent: Friday, October 12, 2007 12:59 PM >To: Ted Mittelstaedt >Cc: ARIN PPML >Subject: Re: [ppml] [arin-announce] Legacy RSA > > >On 10/12/07, Ted Mittelstaedt wrote: >> Of course - but what about their upstreams, and their other upstreams, >> and so on? >> >> My traceroute to this very mailing list server passes through a couple of >> networks that I don't pay money to directly. I'm sure as long >as I'm paying >> my feeds I'll be able to route whatever I want through them. >But, I doubt >> it is going to go more and a hop or so and I won't be able to compel >> those other neworks to carry my obsolete traffic if they don't want to. > >Ted, > >For every single packet at every single router on the Internet today, >either the packet's source or its destination has paid for it to be >there. This may be indirect at times: I pay Joe who pays Bob who pays >Alice. But its not particularly hard to follow the money. > OK, I have a list of spamming IP addresses, maybe you can explain how to use this money trail to get the admins of the blocks that the spammers are operating from to actually answer their mail, or their phone, or actually do something about getting the spammers offline? Uh huh. Thought so. IPv4 routing will go exactly the same way, you just watch. When problems happen and you can't get your IPv4 traffic through anymore, you will call and bitch and everyone you talk to will assure you in all seriousness that they are still routing IPv4 and they aren't seeing the problem your having, and by the way have you tried accessing it with IPv6 and did that work? And in the meantime their admins will continue ignoring the complaints about unroutable IPv4. Exactly how spamming is handled on the Internet today. Most large networks are run by telcos - and here's a copy of the "telco response 101 handbook" that these companies use to respond to problems: #1 "We don't see a problem it must be your equipment" #2 See rule#1 Ted From JOHN at egh.com Fri Oct 12 17:37:48 2007 From: JOHN at egh.com (John Santos) Date: Fri, 12 Oct 2007 17:37:48 -0400 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: Message-ID: <1071012164409.7100C-100000@Ives.egh.com> On Fri, 12 Oct 2007, Ted Mittelstaedt wrote: > > > >-----Original Message----- > >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >Kevin Kargel > >Sent: Friday, October 12, 2007 7:26 AM > >To: ppml at arin.net > >Subject: Re: [ppml] [arin-announce] Legacy RSA > > > > > > That's a pretty good deal. I wish I could get it in my contract that > >my rights would never be lessened even if policy changed. > > > > Kevin, don't forget ARIN defines legacy holders as IPv4 holders. > IPve ONLY. In ARIN's definitions, there is no such thing as an > "IPv6 Legacy Holder" So far as I know, no legacy holder has obtained or asked to obtain IPv6 addresses (or additional IPv4 addresses) without signing an RSA and becoming a non-legacy holder. I believe that some legacy holders may also hold non-legacy addresses, but I don't know that for sure. In any case, this is straw man. > > I'll be happy to write you a contract that states unequiocably that > you have permanent, perpetual rights in how to configure any one > of a box of Latticenet cards I happened to see in a junk store > a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) Lots of contracts contain perpetual rights clauses. So what? > > My only concern with the "Legacy RSA" is that somewhere within it, there > is a statement that the term "Legacy holder" means "IPv4 only holder" > That way there is no chance in the future that some court could > misinterpret the contract and use it to extend over IPv6 assignments. > IANAL, but this seems extremely unlikely to me. The only way to obtain IPv6 assignments is to sign an RSA specifically applying to those resources, and no court is likely to ignore that. > This really comes down to your position on moving to IPv6. The > official word is that IPv4 runout is a fact, and that IPv6 will > replace it. There are, unfortunately, a lot of people out there > (like Dean) who apparently think that they can manipulate the system > into making the Internet some sort of permanent shared IPv4/IPv6 > environment - if that were to happen, the assignments of the Legacy > holders would become a permanent, unpaid, drag on the Internet. > There are a lot of incorrect assumptions here. 1) IPv6 will *not* replace IPv4, at least not for many years, if not decades. The "Internet" will be mixed IPv4/6 for a long time to come. 2) It is not a matter of "manipulation" to make the Internet a permanent shared IPv4/IPv6 environment, it is a natural consequence of a slow migration to a new technology. The only alternatives are either creating an entirely new, unconnected IPv6-only network (with virtually no users, providers, no Ebay nor Amazon nor YouTube nor CNN nor Kazaa nor emails of pictures from your brother-in-laws' cousin's bowling tournament), or a global flash-cut, where everyone has to toss out billions (trillions) of dollars worth of suddenly obsolete equipment. 3) I can't recall Dean (or anyone else) actually saying they want to acquire and think they have the right to acquire IPv6 resources without signing an RSA for them and without paying normal end-user fees (i.e. $100/year) just because they are a legacy v4 holder. Some people have proposed *offering* legacy v4 holders IPv6 and/or reductions in fees as an inducement to getting them to sign an RSA and return unneeded IPv4 assignments, but that is not the same thing at all. 4) Legacy IPv4 assignments can never increase, only decrease (as the holders go out of business, abandon their holdings, fail to find an ISP which will route for them, or move to IPv6.) It is fundamental mathematics that a monotoniclly decreasing function will tend toward zero, so the whole "permanent, unpaid drag on the Internet" argument is wrong. 5) At one time, the Internet consisted solely of legacy assignments. Are you saying, despite Moore's law operating over a decade and a half, it costs more now than it did 15 years ago to handle legacy traffic? > But in the last analysis, the so called "rights of the (IPv4) Legacy > holders" are only of value as long as the rest of us continue to keep > routing their legacy traffic - ie: their IPv4 traffic. Ask yourself, This is yet another false assumption. I have a legacy class C (/24) that is of great value to my company, despite the fact that it doesn't get routed. We have 3 private-line connections to various customers, and if we renumbered to RFC1918 addresses, we would have to co-ordinate the usage with all 3 customers, and an unknown, much larger group of potential future customers. (The issues are routing, firewalls, traffic segregation, etc. and grow geometricly with the number of participants.) I've mentioned this before and lots of people have said they have similar situations. > what is a reasonable expectation as to how long the rest of the Internet > will be willing to continue to do this, before telling the Legacy > holders (and, indeed, ALL IPv4 holders) that they must switch to IPv6. > That is the true length of time that these so called "rights" will have > any actual value. Eventually, the last v4 host will be shut down. Long before that, the last v4 router in the DFZ will be shut down or converted to v6 (or v-next or whatever) only. So what? > > Ted > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From stephen at sprunk.org Fri Oct 12 18:11:24 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 12 Oct 2007 17:11:24 -0500 Subject: [ppml] [arin-announce] Legacy RSA References: Message-ID: <02b301c80d1e$07b6a750$573816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" >>They will have value as long as ISPs are willing to take money to >>route their traffic. There is no reason to think ISPs will turn down >>their money in the forseeable future. > > Of course - but what about their upstreams, and their other > upstreams, and so on? Capitalism means that as long as you're willing to pay the price, someone will sell you what you want. If some networks stop routing v4, BGP will route around the "failure" and life will go on. Perhaps at some point, that will involve tunnels over v6 to a handful of v4 exchange points, i.e. a 4Bone, but not any time soon. Of course, over time, the cost of providing v4 services may rise to the point where legacy holders are no longer willing to pay, but that's (a) their decision, and (b) far enough away that none of us can predict when or how it'll happen. My crystal ball gets real fuzzy about five years from now, and I'm quite sure we'll still have a native v4 DFZ then. > My traceroute to this very mailing list server passes through a > couple of networks that I don't pay money to directly. Not directly, no. However, all of the networks you see in that path are getting money directly or indirectly from you and/or ARIN. That's how the money flows in the modern Internet. > I'm sure as long as I'm paying my feeds I'll be able to route > whatever I want through them. But, I doubt it is going to go more > and a hop or so and I won't be able to compel those other > neworks to carry my obsolete traffic if they don't want to. Obsolete or not, if you're willing to pay the cost of moving your v4 bits plus a fair profit, someone will be happy to take your money. You may find at some point, though, that you can get your bits moved for less if they're v6. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From tedm at ipinc.net Fri Oct 12 18:38:38 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 12 Oct 2007 15:38:38 -0700 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: <1071012164409.7100C-100000@Ives.egh.com> Message-ID: >-----Original Message----- >From: John Santos [mailto:JOHN at egh.com] >Sent: Friday, October 12, 2007 2:38 PM >To: Ted Mittelstaedt >Cc: Kevin Kargel; ppml at arin.net >Subject: Re: [ppml] [arin-announce] Legacy RSA > > >On Fri, 12 Oct 2007, Ted Mittelstaedt wrote: > >> >> >> >-----Original Message----- >> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> >Kevin Kargel >> >Sent: Friday, October 12, 2007 7:26 AM >> >To: ppml at arin.net >> >Subject: Re: [ppml] [arin-announce] Legacy RSA >> > >> > >> > That's a pretty good deal. I wish I could get it in my contract that >> >my rights would never be lessened even if policy changed. >> > >> >> Kevin, don't forget ARIN defines legacy holders as IPv4 holders. >> IPve ONLY. In ARIN's definitions, there is no such thing as an >> "IPv6 Legacy Holder" > >So far as I know, no legacy holder has obtained or asked to obtain >IPv6 addresses (or additional IPv4 addresses) without signing an >RSA and becoming a non-legacy holder. I believe that some legacy >holders may also hold non-legacy addresses, but I don't know that >for sure. In any case, this is straw man. > I don't understand your comment, here. I was pointing out to Kevin that it isn't possible for these rights to be in perpetuity because they are tied up in IPv4, and IPv4 is going to end. You seem to agree later - but your arguing against my assertion here? I think you need to reread the discussion, your making exactly the same point I am. >> >> I'll be happy to write you a contract that states unequiocably that >> you have permanent, perpetual rights in how to configure any one >> of a box of Latticenet cards I happened to see in a junk store >> a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) > >Lots of contracts contain perpetual rights clauses. So what? > That was exactly my response, so what? Which is why I illustrated it with the latticenet cards - perhaps you were unaware that latticenet is obsolete? >4) Legacy >IPv4 assignments can never increase, only decrease (as the holders >go out of business, abandon their holdings, fail to find an ISP >which will route for them, or move to IPv6.) Your other points I'm not going to discuss as they boil down to speculation - you and I can both make most logical arguments as to what is going to happen, and both make sense - but we won't know until it happens. However, I don't agree with the premise that Legacy IPv4 assignments are always going to decrease. If a legal precident is ever set that turns legacy numbers into "property" then they can be bought and sold and thus will not decrease - at least, not as a rate that is going to matter significantly. > >> But in the last analysis, the so called "rights of the (IPv4) Legacy >> holders" are only of value as long as the rest of us continue to keep >> routing their legacy traffic - ie: their IPv4 traffic. Ask yourself, > >This is yet another false assumption. I have a legacy class C (/24) >that is of great value to my company, despite the fact that it doesn't >get routed. I should have clarified that. I don't mean of value to you. I mean value on the open market. While my 1975 orange and yellow Chevy Vega with the rusted out fenders and the seats that look like a cat clawed them may have "great value" to me, it is of no value.* Although I might, like you are doing with your legacy IPv4 block, argue with ferver that my precious baby has value to anyone with good sense to try to straighten me out. Ted * Note that I do -not- own such a vehicle, I merely used the most fugly car I could imagine for the example - my apologies to owners of yellow-orange Vegas everywhere - and my sympathies. ;-) From JOHN at egh.com Fri Oct 12 19:14:27 2007 From: JOHN at egh.com (John Santos) Date: Fri, 12 Oct 2007 19:14:27 -0400 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: Message-ID: <1071012185332.7100A-100000@Ives.egh.com> On Fri, 12 Oct 2007, Ted Mittelstaedt wrote: > > > >-----Original Message----- > >From: John Santos [mailto:JOHN at egh.com] > >Sent: Friday, October 12, 2007 2:38 PM > >To: Ted Mittelstaedt > >Cc: Kevin Kargel; ppml at arin.net > >Subject: Re: [ppml] [arin-announce] Legacy RSA > > > > > >On Fri, 12 Oct 2007, Ted Mittelstaedt wrote: > > > >> > >> > >> >-----Original Message----- > >> >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of > >> >Kevin Kargel > >> >Sent: Friday, October 12, 2007 7:26 AM > >> >To: ppml at arin.net > >> >Subject: Re: [ppml] [arin-announce] Legacy RSA > >> > > >> > > >> > That's a pretty good deal. I wish I could get it in my contract that > >> >my rights would never be lessened even if policy changed. > >> > > >> > >> Kevin, don't forget ARIN defines legacy holders as IPv4 holders. > >> IPve ONLY. In ARIN's definitions, there is no such thing as an > >> "IPv6 Legacy Holder" > > > >So far as I know, no legacy holder has obtained or asked to obtain > >IPv6 addresses (or additional IPv4 addresses) without signing an > >RSA and becoming a non-legacy holder. I believe that some legacy > >holders may also hold non-legacy addresses, but I don't know that > >for sure. In any case, this is straw man. > > > > I don't understand your comment, here. I was pointing out to Kevin that > it isn't possible for these rights to be in perpetuity because they are > tied up in IPv4, and IPv4 is going to end. You seem to agree later - > but your arguing against my assertion here? I think you need to reread the > discussion, your making exactly the same point I am. You can have perpetual rights to something that has no (or minimal) economic value (like your Vega). I agree that *eventually* IPv4 will go away and cease to have value, but the rights will persist. Someone still owns whatever intellectual property value resides in those latticenet cards (copyright on software, patents, whatever) until they expire and someone owns the physical cards themselves, even if they wouldn't sell for the cost of postage on Ebay. "Perpetual rights" don't expire just because they have no value any more. My point is that I think all legacy holders know that eventually the holdings will have no value. But they do have value now, and they (quite reasonably) don't want to be deprived of that value. > > >> > >> I'll be happy to write you a contract that states unequiocably that > >> you have permanent, perpetual rights in how to configure any one > >> of a box of Latticenet cards I happened to see in a junk store > >> a couple years ago. ;-) Or maybe Arcnet cards? ;-) ;-) > > > >Lots of contracts contain perpetual rights clauses. So what? > > > > That was exactly my response, so what? Which is why I illustrated it > with the latticenet cards - perhaps you were unaware that latticenet is > obsolete? > > > >4) Legacy > >IPv4 assignments can never increase, only decrease (as the holders > >go out of business, abandon their holdings, fail to find an ISP > >which will route for them, or move to IPv6.) > > Your other points I'm not going to discuss as they boil down to > speculation - you and I can both make most logical arguments as > to what is going to happen, and both make sense - but we won't know > until it happens. > > However, I don't agree with the premise that Legacy IPv4 assignments > are always going to decrease. If a legal precident is ever set that > turns legacy numbers into "property" then they can be bought and > sold and thus will not decrease - at least, not as a rate that > is going to matter significantly. > The question of whether legacy assignments can be bought and sold is entirely different than whether they can be taken away from the holder without the holder's consent, which is my main issue as a legacy holder. When I signed up for a network assignment in 1993, I did not expect to be able to make money by reselling my addresses. I wanted, then and now, to have static, unique addresses, so I wouldn't have to renumber and I wouldn't have to play elaborate NATing games (I don't know if NAT even existed at the time) to communicate with other entities. > > > >> But in the last analysis, the so called "rights of the (IPv4) Legacy > >> holders" are only of value as long as the rest of us continue to keep > >> routing their legacy traffic - ie: their IPv4 traffic. Ask yourself, > > > >This is yet another false assumption. I have a legacy class C (/24) > >that is of great value to my company, despite the fact that it doesn't > >get routed. > > I should have clarified that. I don't mean of value to you. I mean > value on the open market. > > While my 1975 orange and yellow Chevy Vega with the rusted out fenders > and the seats that look like a cat clawed them may have "great value" to > me, it is of no value.* > > Although I might, like you are doing with your legacy IPv4 block, argue > with ferver that my precious baby has value to anyone with good sense > to try to straighten me out. > My legacy block has real value, replacement value, since it would take large amounts of my and other people's time (time *is* money) to replace it. > Ted > > * Note that I do -not- own such a vehicle, I merely used the > most fugly car I could imagine for the example - my apologies > to owners of yellow-orange Vegas everywhere - and my sympathies. ;-) > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From steveb at eagle.ca Fri Oct 12 19:52:02 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Fri, 12 Oct 2007 19:52:02 -0400 Subject: [ppml] [arin-announce] Legacy RSA In-Reply-To: <1071012185332.7100A-100000@Ives.egh.com> References: <1071012185332.7100A-100000@Ives.egh.com> Message-ID: <471008A2.4030701@eagle.ca> > My legacy block has real value, replacement value, since it would > take large amounts of my and other people's time (time *is* money) to > replace it. Out of curiosity, at what point do the savings equal or exceed the cost of renumbering to yourself, your clients and/or the community? Although I am a learning rookie here, I do have a desire to learn. When will this price point reach the stage that it costs more to hold the legacy space as opposed to switch over? I've renumbered several networks. It can be a *very* costly business (or profitable, depending on which side of the fence one is on). However, are you willing to hold on to the legacy space until it becomes a liability as opposed to a cost saving? When do you forsee the straw begin to bend the opposite way? Steve From info at arin.net Sat Oct 13 21:59:28 2007 From: info at arin.net (Member Services) Date: Sat, 13 Oct 2007 19:59:28 -0600 Subject: [ppml] Posting of Legacy RSA and FAQ Message-ID: <000001c80e05$dcf3a700$0a00090a@arin.net> The Legacy Registration Services Agreement (RSA), first referenced in the 11 October 2007 announcement, has been posted to the ARIN website at: http://www.arin.net/registration/agreements/legacy_rsa.pdf. A Frequently Asked Questions document is also available to assist the community at: http://www.arin.net/registration/agreements/legacy_rsa_faq.html An implementation date will be announced in the near future. Regards, Raymond A. Plzak President & CEO American Registry for Internet Numbers (ARIN) From randy at psg.com Sun Oct 14 00:57:17 2007 From: randy at psg.com (Randy Bush) Date: Sat, 13 Oct 2007 21:57:17 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <000001c80e05$dcf3a700$0a00090a@arin.net> References: <000001c80e05$dcf3a700$0a00090a@arin.net> Message-ID: <4711A1AD.5020002@psg.com> amusingly one-sided. o arin may terminate if holder does not... but nothing about if arin does not o arin may choose to ignore change request, which may be solely why the holder is interested in doing this at all o 4d si all about holder following laws, ... but nothing about arin doing so o 5b says holder responsible for accurate whois, but 4b makes clear that arin controls all data, and thereby may prevent compliance o and on and on and on if this was drawn two parties negotiating a fair win-win contract, it would be far more balanced. but this is a "my way or the highway" contract drawn by one party thinking it controls all the cards. maybe in a few iterations, when it is less one-sided and arrogant, i will think about spending a lawyer's time looking at it. randy From randy at psg.com Sun Oct 14 01:29:08 2007 From: randy at psg.com (Randy Bush) Date: Sat, 13 Oct 2007 22:29:08 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <000001c80e05$dcf3a700$0a00090a@arin.net> <4711A1AD.5020002@psg.com> <4711A5BA.2090209@psg.com> Message-ID: <4711A924.5010301@psg.com> > Almost of all the terms parallel the existing RSA agreement, only > with the addition of recognition that policies shall not diminish > existing right and privileges of a legacy holder oh? then what is section 9? yes, arin may not think the holder has such rights. but if that was really the case, why would arin make relinquishing them part of the contract? > nor shall ARIN take action or reduce services as a result of unused > legacy space. then why does it demand contractual right to audit? > Sorry... thanks for the reference (and I now realize your original > point that holder must xxx or else, but nowhere does it say ARIN must > YY or else) yep > It's not as clearly spelt out, but in 14(c) there's termination if > ARIN breaches the agreement and doesn't cure after 30 days. where is holder given 30 days to cure? see lack of parallel respect? randy From jcurran at istaff.org Sun Oct 14 01:56:38 2007 From: jcurran at istaff.org (John Curran) Date: Sun, 14 Oct 2007 01:56:38 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <4711A924.5010301@psg.com> References: <000001c80e05$dcf3a700$0a00090a@arin.net> <4711A1AD.5020002@psg.com> <4711A5BA.2090209@psg.com> <4711A924.5010301@psg.com> Message-ID: At 10:29 PM -0700 10/13/07, Randy Bush wrote: > > Almost of all the terms parallel the existing RSA agreement, only >> with the addition of recognition that policies shall not diminish >> existing right and privileges of a legacy holder > >oh? then what is section 9? yes, arin may not think the holder has >such rights. but if that was really the case, why would arin make >relinquishing them part of the contract? >... >then why does it demand contractual right to audit? The terms of the current RSA include both of these as well. We tried to stay as close to the current RSA as possible (for fairness to existing members), with the addition of the language which recognizes the legacy holders status with respect to policies which might otherwise reduce their rights. /John From dean at av8.com Sun Oct 14 02:31:39 2007 From: dean at av8.com (Dean Anderson) Date: Sun, 14 Oct 2007 02:31:39 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <000001c80e05$dcf3a700$0a00090a@arin.net> Message-ID: Having reviewed the Legacy RSA, I can say that it removes a number of significant rights from Legacies. With the exception of fees, it is about as onerous and encumbered as the regular RSA. Embedded in the document is again the threat of denial of services. The agreement states that by signing agreement, ARIN will Legacies get a fee of $100/yr through 2013. After 2013, the fees can go up. Section 3. A great deal of the agreement is at ARIN's sole discretion. It looks like a Legacy that signs this agreement can lose their block if ARIN "Determines in its sole discretion that it cannot provide services". Section 4. Under the new agreement, if one doesn't 'cooperate' with ARIN, again in its sole discretion, may take back the block. Wow. ARIN can take back a block if the applicant is ever found to violate 'any applicable laws, statutes or regulations by a ruling...'. Guess McDonalds won't be able to keep their block. They violate health regulations somewhere every day. ARIN can take back a block if the applicant _assists_ anyone doing something prohibited by this document. I guess that means ISC loses its blocks, because it assists SORBS and Alan Brown, who has been found in a court to violate the law for defamation. Oh wait, those aren't legacy blocks.... Applicant is responsible for timely management and accurate maintenance of whois data and SWIP data. So if your whois or SWIP gets out of date, you are in violation of the agreement; you lose your block. Wow. Section 8. ARIN may review your allocation once per year. If you don't comply with the allocation policy, ARIN can back your block. Section 12. Bankruptcy is another provision. If a legacy declares bankruptcy under any chapter (even debt reorganization!), then ARIN can take back the block. I can see taking back a block when a chapter 7 bankruptcy or other chapter leading to termination of business would justify taking back a block. However, there is no reason why chapter 11 (debt reorganization), which doesn't lead to business termination and in fact prevents creditors from halting operations, should be justification for ARIN taking back blocks. This is a flaw in the NPRM, too. What's worse, if SOMEONE ELSE files a bankruptcy petition against you, ARIN can take back the block. Wow. Guess there will be a lot of frivolous bankruptcy petitions against people they don't like. This is also in the RSA, but I hadn't noticed it before. Section 14. Term and Termination. ARIN can terminate immediately with cause (violations above), or at each year. Its a very lopsided agreement. Section 15. The only right the legacy keeps is the right to transfer. Well, not exactly. One now needs ARIN's written permission. There's also an anti-Kremen v ARIN, Kremen v. Cohen clause to say that blocks cannot be re-assigned involuntarilly by a Court. Wow. One of the serious flaws is that one must agree to resolve disputes through arbitration. Arbitration is a fine way to cheaply resolve small disputes, where all that is needed a reasonable third person to resolve trivial disputes. However, there is no appeal from arbitration. If one goes to Court, and the judge makes a mistake, that mistake can be corrected. But if an arbitrator makes a mistake, there is no way to correct that. An arbitrator also may not have any sophisticated understanding of the law. They are often lawyers, but need not be lawyers. Even where they are lawyers, they may not be experts in the legal issues relevant to your case. So, for any complicated case, where there is more possibility of mistake, there is no possibility that mistake can be corrected. This makes arbitration a very bad choice for anything of importance, where proper adherence to the law is important. So, I think it is a bad idea to agree to arbitration on any significant issue. Certainly, Legacies have not previously agreed to arbitration, nor anything else in this Legacy RSA. What a horribly unfair and lopsided agreement. The regular RSA is a real doozy, too, I just noticed. Time to write those letters to Congress. We definitely need a new, FAIR registrar. I think we can now say without doubt that this Legacy RSA removes rights from Legacies who sign it and transfers those rights to ARIN. And as a result, there is an even stronger argument that ARIN, by creating a fear of denial of services in the minds of Legacies, and then obtaining contract and property rights from Legacies, has engaged in extortion and racketeering as explained in my previous message (repeated below) It also remains unclear at what Board Meeting this was discussed. It remains unclear what NRPM change allows it to be accepted. It remains unclear why community input on the document wasn't solicited before it was released. It is however clear what benefits ARIN obtains from Legacies. >From my previous message (Friday): It occurs to me that the release of the Legacy RSA just announced violates the process of ARIN to solicit input from the membership before adopting a new license. The ARIN community should discuss the license and decide the terms just like any other significant change in ARIN. ARIN can't just drop a new licence without any discussion. It also occurs to me that Legacy RSA, if it removes _any_ privilege or value from Legacy's, is extortion. From Blacks Law dictionary: Extortion: The obtaining of property from another induced by wrongful use of actual or threatened force, violence, or fear, or under color of official right. 18 U.S.C.A section 871 et seq; section 1951 ARIN, in statements by it lawyer, and supported by Chairman Curran's statements, has threatened to deny service to Legacy's under the color of official right, creating fear and thereby inducing Legacy's to agree to an RSA that (presumably) removes valuable rights from Legacy's. There are references to the Hobbs Act (racketeering) if the extortion interferes with interstate commerce (it does, since whois and in-addr services are used in interstate commerce.) Anticipating that people might argue that IP Addresses aren't property, I looked up what property is. According to Black's Law Dictionary, in criminal law, the term 'property' includes contract rights, and that is exactly what the subject is here. --Dean On Sat, 13 Oct 2007, Member Services wrote: > The Legacy Registration Services Agreement (RSA), first referenced in the 11 October 2007 announcement, > has been posted to the ARIN website at: http://www.arin.net/registration/agreements/legacy_rsa.pdf. > > A Frequently Asked Questions document is also available to assist the community at: > http://www.arin.net/registration/agreements/legacy_rsa_faq.html > > An implementation date will be announced in the near future. > > Regards, > > Raymond A. Plzak > President & CEO > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From aaron.dewell at woods.net Sun Oct 14 03:07:20 2007 From: aaron.dewell at woods.net (Aaron Dewell) Date: Sun, 14 Oct 2007 11:07:20 +0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: Message-ID: <1192345640.6015.11.camel@gogo.woods.net> My interpretation of this is that you are not really looking for increased _fairness_ from ARIN, as by applying roughly the same (lack of) rights to all, they pretty much fufill the definition of fair. Your dispute is that you want more protection of your blocks, property, rights, whatever. That's a separate issue than "fairness". I believe the ARIN viewpoint is that these blocks are owned by them, retained by them, however, they allow you certain rights to use them. Those rights are fully revokeable at any time by ARIN, pretty much whenever they want to, as these resources are owned by them at all times. So by this view, it is in ARIN's sole discretion to allow you or not to allow you to use them. Now, you might dispute that viewpoint, and claim that these are assignable property/rights that should not be revoked except for more dramatic cause than what the current RSA allows. My point is that the issue is not "fairness", your issue is with what level of rights are associated with a registration (regardless of type). IMHO, the level of rights associated with registrations is pretty much set at this point, and while ARIN has the right to revoke any registration at pretty much any time, they have not done so arbitrarily to my knowledge. So trying to petition Congress to change the organization is rolling the dice as to whether the new organization would be as "fair" or would be more arbitrary. Aaron On Sun, 2007-10-14 at 02:31 -0400, Dean Anderson wrote: > Having reviewed the Legacy RSA, I can say that it removes a number of > significant rights from Legacies. With the exception of fees, it is > about as onerous and encumbered as the regular RSA. > > Embedded in the document is again the threat of denial of services. The > agreement states that by signing agreement, ARIN will > > Legacies get a fee of $100/yr through 2013. After 2013, the fees can > go up. > > Section 3. A great deal of the agreement is at ARIN's sole discretion. > It looks like a Legacy that signs this agreement can lose their block if > ARIN "Determines in its sole discretion that it cannot provide > services". > > > Section 4. Under the new agreement, if one doesn't 'cooperate' with > ARIN, again in its sole discretion, may take back the block. Wow. > > ARIN can take back a block if the applicant is ever found to violate > 'any applicable laws, statutes or regulations by a ruling...'. Guess > McDonalds won't be able to keep their block. They violate health > regulations somewhere every day. > > ARIN can take back a block if the applicant _assists_ anyone doing > something prohibited by this document. I guess that means ISC loses its > blocks, because it assists SORBS and Alan Brown, who has been found in a > court to violate the law for defamation. Oh wait, those aren't legacy > blocks.... > > Applicant is responsible for timely management and accurate maintenance > of whois data and SWIP data. So if your whois or SWIP gets out of date, > you are in violation of the agreement; you lose your block. Wow. > > Section 8. ARIN may review your allocation once per year. If you don't > comply with the allocation policy, ARIN can back your block. > > Section 12. Bankruptcy is another provision. If a legacy declares > bankruptcy under any chapter (even debt reorganization!), then ARIN can > take back the block. I can see taking back a block when a chapter 7 > bankruptcy or other chapter leading to termination of business would > justify taking back a block. However, there is no reason why chapter 11 > (debt reorganization), which doesn't lead to business termination and in > fact prevents creditors from halting operations, should be justification > for ARIN taking back blocks. This is a flaw in the NPRM, too. > > What's worse, if SOMEONE ELSE files a bankruptcy petition against you, > ARIN can take back the block. Wow. Guess there will be a lot of > frivolous bankruptcy petitions against people they don't like. This is > also in the RSA, but I hadn't noticed it before. > > Section 14. Term and Termination. ARIN can terminate immediately with > cause (violations above), or at each year. Its a very lopsided > agreement. > > Section 15. The only right the legacy keeps is the right to transfer. > Well, not exactly. One now needs ARIN's written permission. There's also > an anti-Kremen v ARIN, Kremen v. Cohen clause to say that blocks cannot > be re-assigned involuntarilly by a Court. Wow. > > One of the serious flaws is that one must agree to resolve disputes > through arbitration. Arbitration is a fine way to cheaply resolve small > disputes, where all that is needed a reasonable third person to resolve > trivial disputes. However, there is no appeal from arbitration. If one > goes to Court, and the judge makes a mistake, that mistake can be > corrected. But if an arbitrator makes a mistake, there is no way to > correct that. An arbitrator also may not have any sophisticated > understanding of the law. They are often lawyers, but need not be > lawyers. Even where they are lawyers, they may not be experts in the > legal issues relevant to your case. So, for any complicated case, where > there is more possibility of mistake, there is no possibility that > mistake can be corrected. This makes arbitration a very bad choice for > anything of importance, where proper adherence to the law is important. > So, I think it is a bad idea to agree to arbitration on any significant > issue. Certainly, Legacies have not previously agreed to arbitration, > nor anything else in this Legacy RSA. > > What a horribly unfair and lopsided agreement. The regular RSA is a real > doozy, too, I just noticed. Time to write those letters to Congress. We > definitely need a new, FAIR registrar. > > I think we can now say without doubt that this Legacy RSA removes rights > from Legacies who sign it and transfers those rights to ARIN. And as a > result, there is an even stronger argument that ARIN, by creating a fear > of denial of services in the minds of Legacies, and then obtaining > contract and property rights from Legacies, has engaged in extortion and > racketeering as explained in my previous message (repeated below) > > It also remains unclear at what Board Meeting this was discussed. It > remains unclear what NRPM change allows it to be accepted. It remains > unclear why community input on the document wasn't solicited before it > was released. > > It is however clear what benefits ARIN obtains from Legacies. > > >From my previous message (Friday): > > It occurs to me that the release of the Legacy RSA just announced > violates the process of ARIN to solicit input from the membership before > adopting a new license. The ARIN community should discuss the license > and decide the terms just like any other significant change in ARIN. > ARIN can't just drop a new licence without any discussion. > > It also occurs to me that Legacy RSA, if it removes _any_ privilege or > value from Legacy's, is extortion. From Blacks Law dictionary: > > Extortion: The obtaining of property from another induced by wrongful > use of actual or threatened force, violence, or fear, or under color of > official right. 18 U.S.C.A section 871 et seq; section 1951 > > ARIN, in statements by it lawyer, and supported by Chairman Curran's > statements, has threatened to deny service to Legacy's under the color > of official right, creating fear and thereby inducing Legacy's to agree > to an RSA that (presumably) removes valuable rights from Legacy's. > > There are references to the Hobbs Act (racketeering) if the extortion > interferes with interstate commerce (it does, since whois and in-addr > services are used in interstate commerce.) > > Anticipating that people might argue that IP Addresses aren't property, > I looked up what property is. According to Black's Law Dictionary, in > criminal law, the term 'property' includes contract rights, and that is > exactly what the subject is here. > > --Dean > > > > > On Sat, 13 Oct 2007, Member Services wrote: > > > The Legacy Registration Services Agreement (RSA), first referenced in the 11 October 2007 announcement, > > has been posted to the ARIN website at: http://www.arin.net/registration/agreements/legacy_rsa.pdf. > > > > A Frequently Asked Questions document is also available to assist the community at: > > http://www.arin.net/registration/agreements/legacy_rsa_faq.html > > > > An implementation date will be announced in the near future. > > > > Regards, > > > > Raymond A. Plzak > > President & CEO > > American Registry for Internet Numbers (ARIN) > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN Public Policy > > Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > > Help Desk at info at arin.net if you experience any issues. > > > > > From randy at psg.com Sun Oct 14 06:52:05 2007 From: randy at psg.com (Randy Bush) Date: Sun, 14 Oct 2007 03:52:05 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <000001c80e05$dcf3a700$0a00090a@arin.net> <4711A1AD.5020002@psg.com> <4711A5BA.2090209@psg.com> <4711A924.5010301@psg.com> Message-ID: <4711F4D5.6000508@psg.com> John Curran wrote: > At 10:29 PM -0700 10/13/07, Randy Bush wrote: >>> Almost of all the terms parallel the existing RSA agreement, only >>> with the addition of recognition that policies shall not diminish >>> existing right and privileges of a legacy holder >> oh? then what is section 9? yes, arin may not think the holder has >> such rights. but if that was really the case, why would arin make >> relinquishing them part of the contract? >> ... >> then why does it demand contractual right to audit? > The terms of the current RSA include both of these > as well. We tried to stay as close to the current RSA > as possible (for fairness to existing members), with > the addition of the language which recognizes the > legacy holders status with respect to policies which > might otherwise reduce their rights. section 9 is a wonderful example of rights reduction. randy From jcurran at istaff.org Sun Oct 14 07:27:22 2007 From: jcurran at istaff.org (John Curran) Date: Sun, 14 Oct 2007 07:27:22 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <4711F4D5.6000508@psg.com> References: <000001c80e05$dcf3a700$0a00090a@arin.net> <4711A1AD.5020002@psg.com> <4711A5BA.2090209@psg.com> <4711A924.5010301@psg.com> <4711F4D5.6000508@psg.com> Message-ID: At 3:52 AM -0700 10/14/07, Randy Bush wrote: >John Curran wrote: > >... > > The terms of the current RSA include both of these >> as well. We tried to stay as close to the current RSA >> as possible (for fairness to existing members), with >> the addition of the language which recognizes the >> legacy holders status with respect to policies which >> might otherwise reduce their rights. > >section 9 is a wonderful example of rights reduction. One can look at it that way, but it comes along with 10(b) which states: "ARIN will take no action to reduce the services provided for Included Number Resources that are not currently being utilized by the Legacy Applicant." This may be an example of rights enhancement; particular if one considers that it effectively undoes existing language of RFC2050 regarding underutilized resource reclamation. One trades the present undefined state for an agreement which provides clarity for the legacy holder's ability to use their address space, have access to ARIN services for data record maintenance, and not be subject to future policies that would reduce their rights. There is a policy proposal active (2007-15) which would require a Legacy RSA agreement, so the Board took the action to prepare the necessary agreement. /John From randy at psg.com Sun Oct 14 08:41:30 2007 From: randy at psg.com (Randy Bush) Date: Sun, 14 Oct 2007 05:41:30 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <000001c80e05$dcf3a700$0a00090a@arin.net> <4711A1AD.5020002@psg.com> <4711A5BA.2090209@psg.com> <4711A924.5010301@psg.com> <4711F4D5.6000508@psg.com> Message-ID: <47120E7A.4000601@psg.com> >>> The terms of the current RSA include both of these >>> as well. We tried to stay as close to the current RSA >>> as possible (for fairness to existing members), with >>> the addition of the language which recognizes the >>> legacy holders status with respect to policies which >>> might otherwise reduce their rights. >> section 9 is a wonderful example of rights reduction. > > One can look at it that way, but it comes along with 10(b) > which states: "ARIN will take no action to reduce the services > provided for Included Number Resources that are not currently > being utilized by the Legacy Applicant." and that ameliorates section 9 exactly how? to be clear, no one's lawyer, who has half a clue, will advise them to enter into this contract, section 9 being the poster child. randy From Lee.Howard at stanleyassociates.com Sun Oct 14 09:19:55 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sun, 14 Oct 2007 09:19:55 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <4711F4D5.6000508@psg.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40748D294@CL-S-EX-1.stanleyassociates.com> Everyone potentially affected by the Legacy RSA can make up their own minds, with their own legal counsel. Each person can also make their own determination of the value of amateur legal counsel on Internet mailing lists. Constructive suggestions to ARIN are wonderful and encouraged. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Randy Bush > > section 9 is a wonderful example of rights reduction. > > randy No, it says that number resources are not property. Lee From vixie at vix.com Sun Oct 14 11:07:18 2007 From: vixie at vix.com (Paul Vixie) Date: 14 Oct 2007 15:07:18 +0000 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <47120E7A.4000601@psg.com> References: <000001c80e05$dcf3a700$0a00090a@arin.net> <4711A1AD.5020002@psg.com> <4711A5BA.2090209@psg.com> <4711A924.5010301@psg.com> <4711F4D5.6000508@psg.com> <47120E7A.4000601@psg.com> Message-ID: randy at psg.com (Randy Bush) writes: > to be clear, no one's lawyer, who has half a clue, will advise them to > enter into this contract, section 9 being the poster child. that just ain't so, and i know the lawyer in question. while i did not keep ISC's interests in mind during the drafting of this RSA, i do plan to have ISC enter into this contract as soon as it's executable. i guess this means i consider the contract to be in the best interests of both ARIN and ISC, or that it memorializes the agreement i thought these two parties were already (informally) in, or perhaps both. -- Paul Vixie From arin-contact at dirtside.com Sun Oct 14 12:30:46 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 14 Oct 2007 12:30:46 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <000001c80e05$dcf3a700$0a00090a@arin.net> References: <000001c80e05$dcf3a700$0a00090a@arin.net> Message-ID: <3c3e3fca0710140930x750ea519mf39daed62e872a8c@mail.gmail.com> On 10/13/07, Member Services wrote: > http://www.arin.net/registration/agreements/legacy_rsa.pdf. First, thanks to Ray and the rest. This is a big step in the right direction. I'd like to offer some thoughts and suggestions: Major suggestions: As others have mentioned, this contract is a little lopsided against the registrant. This can be directly cured in 14d and 14e. Consider the following replacements: (d) Termination by Legacy Applicant Through Return of Number Resources. Legacy Applicant shall have the right to terminate this agreement by submitting thirty (30) days prior written notice to ARIN of its intent to end the agreement. (e) Effect of Termination. If this Legacy Agreement expires or is terminated: (i) ARIN may immediately cease providing services including but not limited to whois and reverse DNS delegation and will have no liability for doing so, (ii) Legacy Applicant must immediately pay ARIN any outstanding fees that Legacy Applicant owes, (iii) All involuntary revocation activity taken by ARIN against the registrant in the 90 days preceding termination shall be void, and (iv) All legal rights to use the number resources then remaining active under the Legacy Agreement shall return to the legacy registrant. Explanation: This would give the legacy registrant the final trump card, which is as it should be. If ARIN ever meaningfully oversteps its bounds, the Legacy Registrant reserves the right to walk away. ARIN would have no further legal or moral responsibilities due that registrant (no RDNS, no whois, nothing) but ARIN would also have no rights arising under this agreement to reclaim the number resources unless the agreement itself continues. Minor suggestions: Remove 15i. Its obviously false and might piss off the court in an action arising out of the contract. I understand the purpose; it attempts to get around a normal legal right associated with non-negotiated contracts. Don't do it; the courts have good reason to construe contracts against the drafter. Regards, Bill Herrin From randy at psg.com Sun Oct 14 13:07:15 2007 From: randy at psg.com (Randy Bush) Date: Sun, 14 Oct 2007 10:07:15 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <3c3e3fca0710140930x750ea519mf39daed62e872a8c@mail.gmail.com> References: <000001c80e05$dcf3a700$0a00090a@arin.net> <3c3e3fca0710140930x750ea519mf39daed62e872a8c@mail.gmail.com> Message-ID: <47124CC3.3070402@psg.com> > (e) Effect of Termination. If this Legacy Agreement expires or is terminated: > ... > (ii) Legacy Applicant must immediately pay ARIN any outstanding fees > that Legacy Applicant owes, what if termination was due to breach by arin? randy From arin-contact at dirtside.com Sun Oct 14 13:24:12 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 14 Oct 2007 13:24:12 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <47124CC3.3070402@psg.com> References: <000001c80e05$dcf3a700$0a00090a@arin.net> <3c3e3fca0710140930x750ea519mf39daed62e872a8c@mail.gmail.com> <47124CC3.3070402@psg.com> Message-ID: <3c3e3fca0710141024y55f5051cm8cec2c505fe5b1f0@mail.gmail.com> On 10/14/07, Randy Bush wrote: > > (e) Effect of Termination. If this Legacy Agreement expires or is terminated: > > ... > > (ii) Legacy Applicant must immediately pay ARIN any outstanding fees > > that Legacy Applicant owes, > > what if termination was due to breach by arin? Randy, Then pay the hundred bucks you owe and walk away. Seriously, isn't a hundred bucks in one direction or the other a petty matter in this discussion? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From drc at virtualized.org Sun Oct 14 14:48:15 2007 From: drc at virtualized.org (David Conrad) Date: Sun, 14 Oct 2007 11:48:15 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40748D294@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB40748D294@CL-S-EX-1.stanleyassociates.com> Message-ID: <164D3B28-9EBC-497D-ADA9-F00E622C1A16@virtualized.org> Hi, On Oct 14, 2007, at 6:19 AM, Howard, W. Lee wrote: > Everyone potentially affected by the Legacy RSA can make up their > own minds, with their own legal counsel. Indeed. I applaud ARIN for making a constructive effort towards some resolution to issues involving "legacy" address space (regardless of how it is defined). These issues will likely become more and more critical as the IPv4 is further depleted and it is good to bring discussions to the table. I have no comments about the legal terms of the Legacy RSA. In fact, most of my comments are actually in relation to the FAQ. My concerns: a) I have been told that given the Legacy RSA is a contractual document, the proper mechanism for asking questions about the document is the ARIN Consulting and Suggestions process. The fact that ARIN board members are discussing this document on PPML does alleviate this concern somewhat, but it would be helpful if an official statement regarding the status of the posted Legacy RSA and the appropriate venue/mechanism for discussing it were made. b) The definition of "legacy" address space in the FAQ may be confusing given how (at least) APNIC initially operated prior to the creation of ARIN. I might recommend defining legacy address space to be something like "address space allocated without a formal agreement on the part of the requester and the registry". c) Q&A 5 of the FAQ states: "Q5. What will happen to unused number resources I choose to relinquish? A5. Such resources will eventually be assigned to new applicants who can demonstrate the appropriate need for such resources per the need- based number resource policies in the ARIN region. If ARIN receives more unused resources than are needed in its service area, the number resources can be returned to IANA for its use or assignment to other RIRs." I personally believe this to be wholly inappropriate. IP addresses are global resources and returned legacy address space should be returned to IANA for disposition according to global policies, not returned to ARIN for reassignment by ARIN in the ARIN service area according to ARIN policies. d) in Q&A 6 of the FAQ (or in a new FQA item) it would probably be worthwhile to make explicit what ARIN believes its obligations are, if any, to legacy address holders who do NOT sign the RSA. Again, I believe the posting of the Legacy RSA is a good first step towards addressing the legacy address space situation. I look forward to further discussions on the policies, both implied and assumed, that create the environment in which a Legacy RSA can be implemented. Regards, -drc (speaking personally) From arin-contact at dirtside.com Sun Oct 14 15:31:00 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 14 Oct 2007 15:31:00 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <164D3B28-9EBC-497D-ADA9-F00E622C1A16@virtualized.org> References: <369EB04A0951824ABE7D8BAC67AF9BB40748D294@CL-S-EX-1.stanleyassociates.com> <164D3B28-9EBC-497D-ADA9-F00E622C1A16@virtualized.org> Message-ID: <3c3e3fca0710141231rd98fb0ew8842d49d6d035f80@mail.gmail.com> On 10/14/07, David Conrad wrote: > b) The definition of "legacy" address space in the FAQ may be > confusing given how (at least) APNIC initially operated prior to the > creation of ARIN. I might recommend defining legacy address space to > be something like "address space allocated without a formal agreement > on the part of the requester and the registry". David, Technically, its not even that, at least not as I understand it. Legacy address space is space which was assigned prior to ARIN's existance for which for which ARIN currently provides the registration services (RDNS, Whois). The old /8's, for example, are not ARIN Legacy Registrants. > A5. Such resources will eventually be assigned to new applicants who > can demonstrate the appropriate need for such resources per the need- > based number resource policies in the ARIN region. If ARIN receives > more unused resources than are needed in its service area, the number > resources can be returned to IANA for its use or assignment to other > RIRs." > > I personally believe this to be wholly inappropriate. IP addresses > are global resources and returned legacy address space should be > returned to IANA for disposition according to global policies, not > returned to ARIN for reassignment by ARIN in the ARIN service area > according to ARIN policies. Again, these registrations are already in ARIN-managed space. The point here as I take it is that if there were some outpouring of addresses that freed up /8s faster that ARIN registrants consumed them, ARIN would return those /8's to IANA. > d) in Q&A 6 of the FAQ (or in a new FQA item) it would probably be > worthwhile to make explicit what ARIN believes its obligations are, > if any, to legacy address holders who do NOT sign the RSA. I respectfully disagree. The whole point is that if you don't sign the Legacy RSA, your future is uncertain. But then, perhaps that should be said explicitly: Legacy Registrants who choose not to sign the RSA will be subject to whatever laws, ICANN policies and ARIN policies are eventually enacted to deal with such registrants. That should scare everybody into signing. :) Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jis at MIT.EDU Sun Oct 14 16:09:31 2007 From: jis at MIT.EDU (Jeffrey Schiller) Date: Sun, 14 Oct 2007 16:09:31 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <4711A1AD.5020002@psg.com> References: <000001c80e05$dcf3a700$0a00090a@arin.net> <4711A1AD.5020002@psg.com> Message-ID: <1192392571.5954.23.camel@jis-desktop> Disclaimer: I work for MIT, the holder of "Legacy" address space (including a /8). That said, I am speaking here as an individual and not a representative of MIT (though I can speak from the experience of operating MIT's network for > 20 years). Looking over the Legacy RSA I see if addresses two different goals: 1. Arrange for "Legacy" holders receiving services from ARIN (WHOIS, Reverse DNS) to enter into an agreement with ARIN and to pay their fair share for the services rendered. 2. Arrange for Legacy holders to "acknowledge" ARIN as their registration agent and to bring their assignments under ARIN's policies (albeit with a few extra privileges). The current legacy RSA mixes these two goals, and as others have pointed out, it has more then a few issues associated with it. I would propose that ARIN consider yet another legacy RSA which only deals with [1] above. It doesn't go into address assignment issues at all (though it may require that the applicant assert that they are a legacy holder and demonstrate it in some way). I suggest that such an agreement would be a much easier sell and would get more organizations into the ARIN "tent". This would have the benefit that it would not only bring in some more revenue for ARIN (and address some of people's fairness concerns about who is paying for providing WHOIS and Reverse DNS services) it would also improve the communities records of who all of the legacy holders are. Last time I checked (albeit a while ago) there wasn't a good way to update information in ARIN's database unless you signed an RSA. The upshot of this is that there may well be stale information that would be updated if organizations could sign an RSA that didn't deal with [2]. -Jeff -- ======================================================================== Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice jis at mit.edu ======================================================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 2164 bytes Desc: not available URL: From dean at av8.net Sun Oct 14 15:06:51 2007 From: dean at av8.net (Dean Anderson) Date: Sun, 14 Oct 2007 15:06:51 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB40748D294@CL-S-EX-1.stanleyassociates.com> Message-ID: On Sun, 14 Oct 2007, Howard, W. Lee wrote: > Everyone potentially affected by the Legacy RSA can make up > their own minds, with their own legal counsel. Each person > can also make their own determination of the value of > amateur legal counsel on Internet mailing lists. > Constructive suggestions to ARIN are wonderful and encouraged. > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > > Behalf Of Randy Bush > > > > section 9 is a wonderful example of rights reduction. > > > > randy > > No, it says that number resources are not property. It makes both parties agree. There was previously property rights in IP Addresses. I have long been under the impression that there were no _ownership_ rights in IP Blocks. However, as I look back at the documents, I can find no official statement to this effect, either. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.net Sun Oct 14 15:20:04 2007 From: dean at av8.net (Dean Anderson) Date: Sun, 14 Oct 2007 15:20:04 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <1192345640.6015.11.camel@gogo.woods.net> Message-ID: On Sun, 14 Oct 2007, Aaron Dewell wrote: > > My interpretation of this is that you are not really looking for > increased _fairness_ from ARIN, as by applying roughly the same (lack > of) rights to all, they pretty much fufill the definition of fair. Your > dispute is that you want more protection of your blocks, property, > rights, whatever. That's a separate issue than "fairness". 'Fairness' in a contract means that both sides have some rights. A contract must be a 'fair bargain' to be valid. Indeed, a contract that gives no rights to one party is invalid. The RSA (both I suspect) could be invalid for that reason. Fairness between legacy terms and non-legacy terms, fairness of pricing between a small non-legacy allocation and a large non-legacy allocation are about the differences between one contract an another contract. But such differences don't generally make the contracts invalid, no matter how unfair the differences in the terms between one contract and another contract are. I don't think the Legacies have an unfair deal, despite the differences in terms. Legacies are just reaping the benefits of the sweat and toil and risk that non-legacies didn't contribute to, but still benefited from. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.net Sun Oct 14 17:32:14 2007 From: dean at av8.net (Dean Anderson) Date: Sun, 14 Oct 2007 17:32:14 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: Message-ID: On 14 Oct 2007, Paul Vixie wrote: > randy at psg.com (Randy Bush) writes: > > to be clear, no one's lawyer, who has half a clue, will advise them to > > enter into this contract, section 9 being the poster child. > > that just ain't so, and i know the lawyer in question. > > while i did not keep ISC's interests in mind during the drafting of this > RSA, i do plan to have ISC enter into this contract as soon as it's > executable. i guess this means i consider the contract to be in the best > interests of both ARIN and ISC, or that it memorializes the agreement i > thought these two parties were already (informally) in, or perhaps both. As far as I can tell, by implication of the procedures and dates, ISC does not have (should not have) any legacy allocations that haven't already been converted to RSA, I found 6 allocations for ISC (ISC-NET[1-6]) comprising 12 different blocks totaling 76,544 IP addresses. That's a lot of IP addresses for a company that claims not to be in the internet service business. These blocks were all updated on October 5th, 2004, presumably to effect the ORG name change. On the premise that the blocks have a different name, I looked at our BGP view to see what blocks originate in AS1280, AS3557, AS27312, AS27322, AS30130, AS30131, AS30132 AS33072, AS33074, and AS33075. BTW, can you explain why there are no ARIN records for AS27322, AS30130, or AS30131? These are in ARIN AS Blocks. RADB has records that point to ISC, and ISC Address blocks originate from these AS numbers. [More unusual record-keeping problems for ARIN BoT Members related to RADB, too. tsk.tsk.] There are a number of corporations that might be known as "ISC": INTERNET SOFTWARE CONSORTIUM, California, 1997 950 Charter Street, Redwood City, CA 94043 INTERNET SYSTEMS CONSORTIUM, INC, Delaware non-profit, 2003 (no address available) INTERNET SYSTEMS CONSORTIUM, INC, California, 2004 950 Charter Street, Redwood City, CA 94043 INTERNET SYSTEMS CORPORATION, Delaware general (for profit) 2005 (no address available) INTERNET SYSTEMS CORPORATION, California, 2006 950 Charter Street, Redwood City, CA 94043 Quite a complicated web of incorporation activity. Only one is a 501(c)3 non-profit. Which one is that? How do you distinguish the for-profit ISC from the non-profit ISC? (this distinction seems very questionable to me. I thought one wasn't allowed to mix non-profit and for-profit money) It is my understanding that changing the ORG name of a block requires an RSA. So, since ISC changed the ORG name in 2004, that would require a new contract, and so ISC must be subject to the RSA for those 6 blocks. Maybe you mean the Palo Alto Unified School District's /17? That appears like it could be a legacy block. Or maybe you mean the PSI block 154.17/16 that is originated by ISC on AS3557. That doesn't seem to belong to ISC, but it looks like it might be a legacy block. There are some other probably legacies associate with ISC, originated by ISC. Carl Malamud's TRYSTERO block (Malamud was an ISC founder) Brian Reid's BKR-HOME-NET block. City of Palo Alto NETBLK-PA-CITY-NET block And now that I look into it, you also have several blocks that aren't advertised 199.6.2.0/24 nit 199.6.8.0/22, 1024 nit 199.6.12.0/23, 512 nit 199.6.14.0/24 256 nit I imagine those can go back to ARIN, right? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From info at arin.net Sun Oct 14 18:38:05 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:38:05 -0400 Subject: [ppml] Policy Proposal 2006-7 - Staff Assessment Message-ID: <47129A4D.4000600@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal 2006-7 is available as Annex A below and at: http://www.arin.net/policy/proposals/2006_7.html II. Understanding of the proposal ARIN staff understands this proposal would add to the list of criteria for an initial allocation of IPv6 address space (NRPM section 6.5.1.1.). Specifically, in addition to the common criteria, if an ISP is not known, nor can it provide a plan, it can instead attempt to justify intent to announce the address space within one year. III. Comments A. ARIN staff 1. Change I - the statement be a ?known ISP? is still contained in this policy. This term is ambiguous and open to interpretation and should be defined. It should be noted that there is no authoritative definition for either ISP or LIR. 2. ARIN staff is concerned about confusion that may occur if the text is inserted as the author indicated (letter "d" already has an "or"). ARIN staff has suggested alternative placement; see Annex B below. 3. What criteria would staff use to verify that an organization is new to providing "Internet services"? 4. What actions should staff take at the end of 1 year if the v6 block is not announced? 5. The requirement to announce the v6 block at the end of 1 year would seem to preclude the use of this address space on a private network. Is that the intent of this proposal? B. ARIN General Counsel This policy as proposed poses no significant legal risks for ARIN. IV. Resource Impact - Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Implementation would not require the acquisition of staff personnel or equipment. It will require the following: - Revisions to registration guidelines - Staff Training Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. - Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. - An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. - ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a. be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate ##*## Annex B ARIN staff suggested format for the insertion of the policy text 6.5.1.1. Initial allocation criteria To qualify for an initial allocation of IPv6 address space, an organization must: a. be an LIR; b. not be an end site; c. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; and d. meet at least one of the following: 1. be an existing, known ISP in the ARIN region. 2. have a plan for making at least 200 /48 assignments to other organizations within five years. 3. be an organization new to providing internet services that can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. From info at arin.net Sun Oct 14 18:39:53 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:39:53 -0400 Subject: [ppml] Policy Proposal 2007-13 - Staff Assessment Message-ID: <47129AB9.9090001@arin.net> Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_13.html II. Understanding of the proposal ARIN staff understands that this proposal would remove NRPM Section "4.3.4 Additional considerations" in order to remove text that conflicts with Section "4.2.1.6 Immediate need". III. Comments A. ARIN Staff If the immediate need clause is removed from this policy, then the immediate need policy (Number Resource Policy Manual section 4.2.1.6) needs to be amended to provide for end users. Otherwise, ARIN may not be able to meet the needs of end users who have no current address space in use. B. ARIN General Counsel No legal implications. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 120 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Sun Oct 14 18:40:34 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:40:34 -0400 Subject: [ppml] Policy Proposal 2007-14 - Staff Assessment Message-ID: <47129AE2.8080502@arin.net> Policy Proposal 2007-14 Resource Review Process ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_14.html II. Understanding of the proposal This policy proposal provides clear policy authority to audit or reclaim resources, guidelines for how it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to stop using any resources to be reclaimed. III. Comments A. ARIN Staff 1) 2c does not reconcile with the RSA, which grants ARIN authority to request any data necessary and does not specify any sort of limitation to frequency. 2) Point 4 refers to ?ARIN delegation?. Does this include legacy registrations or is it only ARIN issued resources? 3) Point 3 requires ARIN notify an organization each time a review is conducted. ARIN interprets a review to mean a full audit of an organization's resources conducted by ARIN staff. 4) Points 4 and 5 use the term ?compliance?. ARIN interprets this as bringing the organization into compliance with current policy. 5) Point 4 uses the terms ?single aggregate block?.and ?whole resources?. Are these terms used synonymously to refer to a single CIDR prefix, or to ?a contiguous range of addresses?? 6) Point 6 sets the minimum hold time at 6 months. Current staff procedure is a minimum of one year. 7) Point 6 compels ARIN to take action which doesn?t reconcile with the RSA, which (as articulated above) allows ARIN to take whatever action is necessary. 8) Author did not indicate placement in the NRPM. We would insert as "Section 12 Resource Review Process." B. ARIN General Counsel "Counsel strongly supports some version of this policy being enacted and believes adoption of this policy will save significant future legal fees. This policy proposal spells out a series of customary and contractual policies and rights that are important to make as clear as possible. Counsel does not agree with that portion of the description which states ARIN "feels that current policy does not give them the power...." And believes such powers are adequately vested in ARIN' but believes instead such powers can always be more carefully delineated for ease of understanding." IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimal. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Depending on the impact to RSD this may require additional staff. It will require the following: Guidelines Changes Registration System Changes Staff training May increase RSD workload May increase turnaround times Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as needed to bring them substantially into compliance. If possible, only whole resources shall be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:41:12 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:41:12 -0400 Subject: [ppml] Policy Proposal 2007-15 - Staff Assessment Message-ID: <47129B08.7020804@arin.net> Policy Proposal 2007-15 Authentication of Legacy Resources ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_15.html II. Understanding of the proposal ARIN staff understands that the proposal would add new sections to the NRPM, 4.9 regarding legacy resources. The purpose is to encourage "legacy resource holders" to sign the RSA. III. Comments A. ARIN Staff ARIN interprets "evaluate and verify chain of custody of any resource records" as the standard ARIN vetting and verification procedures currently in use. B. ARIN General Counsel "This policy may have legal implications. The ARIN board has authorized the creation of legacy RSA 1.0 which contains very favorable terms for legacy address holders designed to entice, or provide incentives to both sign the specifically designed rsa to obtain continued future services, and to return under utilized resources to ARIN. Policy 2007-15 takes this one step further and adds the incentive of the future fixed date reduction of in-addr services, or stick, not carrot, to the policy alternatives. If the policy is adopted, there is modest risk legacy holders who have received free services in the past, without any agreement with ARIN, could attempt to litigate about such policy. Currently I am unaware of any contractually binding or implied duty of ARIN to maintain such service in the absence of policy to this effect. Therefore I have no current legal objection to the proposed policy." Resource Impact ? Significant The resource impact of implementing this policy is viewed as significant. Barring any unforeseen resource requirements, this policy could be implemented from 6 months to 1 year from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Registration Services Guidelines will be required - Staff training will be required - Additional staff may be required - Database changes - New tracking tools Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-15 Authentication of Legacy Resources Author: Andrew Dul Proposal type: New Policy term: Permanent Policy statement: Add new NRPM section 4.9 - Legacy Records 4.9 - Legacy Records Legacy resource record holders shall be permitted to sign a registration services agreement which permits the legacy organization which is currently using the resources as of January 1, 2007 to continue to use those resources as long as a valid registration services agreement is in effect for the organization. ARIN will evaluate and verify the chain of custody of any resource records prior to executing a registration services agreement with an organization. ARIN shall use all reasonable methods to attempt to contact legacy record holders starting on January 1, 2008 to notify them of this change in policy. ARIN shall also post information on the public website regarding this outreach to legacy resource holders. No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2007. If a legacy resource holder requests additional IPv4 resources all IPv4 resources (legacy and non-legacy) shall be evaluated to determine utilization for additional allocations or assignments under NRPM sections 4.2 or 4.3. Rationale: An ARIN Legacy resource holder is an organization which was issued number resources prior to the formation of ARIN and whose registration information was not transferred to another RIR through the Early Registration Transfer Project (http://www.arin.net/registration/erx). Legacy resource holders were issued number resources through an informal process. This policy proposal attempts to bring these legacy resource holders into a formal agreement with ARIN, the manager of the IP numbering resources for many of the legacy record holders. This policy is similar to a policy which has been adopted in the APNIC region. (http://www.apnic.net/docs/policy/proposals/prop-018-v001.html) Some legacy resource holders have expressed concerns about committing to a registration service agreement (RSA) when the legacy resource holder cannot be assured that they will be permitted to retain their resources for the long-term. This policy proposal requests ARIN to develop a RSA which will allow legacy resource holders to continue to use IPv4 resources which were assigned or allocated prior to ARIN's formation. It is also suggested that the Board of Trustees formalize the annual maintenance fees for legacy resource holders at a level similar to the $100 USD per year for end-sites or provide fee-waivers as an incentive for legacy holders to sign a registration services agreement. The dates in this policy proposal were arbitrarily chosen based upon an expected ratification by the ARIN Board of Trustees by December 31, 2007. If this policy is implemented after December 31, 2007, the trigger dates in the policy should be adjusted appropriately. Given the informal relationship under which the resources were granted, ARIN currently maintains the records including WHOIS and in-addr.arpa delegations in a best-effort fashion. Some believe that ARIN may not be obligated to maintain these records. ARIN has also experienced some difficulty maintaining these records. Legacy records have been a popular target for hijackers, in part due to the out of date information contained in these records. Having up to date contact information and a formal relationship with legacy record holders would assist ARIN and ISP's in insuring these records are maintained accurately. Legacy resource holders who sign a RSA would continue to receive all the services that are currently provided by ARIN plus they would be eligible for any future services that ARIN may offer, such as cryptographic signing of resource records. Timetable for implementation: As stated in policy From info at arin.net Sun Oct 14 18:41:46 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:41:46 -0400 Subject: [ppml] Policy Proposal 2007-16 - Staff Assessment Message-ID: <47129B2A.2050507@arin.net> Policy Proposal 2007-16 IPv4 Soft Landing ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_16.html II. Understanding of the proposal The proposal "aims to provide for a defined transition away from IPv4 address space towards IPv6 address space by imposing increasingly stricter requirements for new address allocations." III. Comments A. ARIN Staff General Comments ? 1. The policy seems to apply only to the general IPv4 ISP policy. Does this policy also apply to the other ISP additional policies like multiple discreet networks (NRPM 4.5) and cable (NRPM 4.2.6)? 2. Does this policy supersede the ISP additional request policy and any other ISP additional request policies? If so, this should be clearly stated. 3. In the policy statement, the author discusses utilization rates and refers to swip and rwhois. These terms should be removed because they are not necessarily relevant to all customers (those that assign smaller than /28s or orgs that manage dynamic address pools, Voip, etc?). 4. In the policy statement, the author refers to specific fields in the template. This should be removed since template fields will change over time. 5. A general question of fairness comes up when you consider that ISP?s will now be faced with much more difficulty in obtaining IP address space from ARIN while end users will feel no effect or change at all. Phase 0: No comments. Phase 1: No comments Phase 2: No comments Phase 3: No comments 6. Author indicated placement in the NRPM. All the text from "begin modification" to "end modification" would be placed in Section 4.2.4.1. Subsections would be created. The title of the section would be changed to "Utilization Requirements". We would strike the "80%" reference in 4.2.3.4.1. B. ARIN General Counsel Counsel does not see any legal implications with this policy. Resource Impact ? Moderate The resource impact of implementing this policy is moderate. Barring any unforeseen resource requirements, this policy could be implemented within 3-6 months from the date of the ratification of the policy by the ARIN Board of Trustees It will require the following: - Significant staff training - Template changes - New Registration Services tools - Guidelines changes - Significant increase in processing time Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy statement Policy Proposal 2007-16 IPv4 Soft Landing Author: David Conrad Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Sun Oct 14 18:42:19 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:42:19 -0400 Subject: [ppml] Policy Proposal 2007-17 - Staff Assessment Message-ID: <47129B4B.8090504@arin.net> Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_17.html II. Understanding of the proposal ARIN staff understands that the proposal would modify NRPM Section 4.6. Ignoring the parts that concern fees and waivers, the proposal would change the current policy by removing the defined timeframe for returning address space to ARIN. III. Comments A. ARIN Staff 1. There is currently an aggregation policy in NRPM 4.7. This proposal seems to be confusing and perhaps contradicting that existing policy. Does this proposal replace the existing aggregation policy 4.7 in NRPM? 2. The policy seems to suggest some type of fee waiver which does not belong within policy. See ARIN General Counsel comments below. 3. ARIN?s current practice requires a signed Registration Services Agreement (RSA) from organizations receiving number resources. The proposed policy should clarify this requirement in section 3. B. ARIN General Counsel ?I have reviewed this policy and believe it poses no significant risk of litigation by outside parties. However, in my non-legal opinion, acting as counselor to the Board and AC, the policy does something I have never previously seen and encroaches on how ARIN has operated by custom. To date, the ARIN Board of Trustees has unilaterally debated and set the rates of payment for any ARIN services. Overall, this policy proposal substitutes a policy with specific numerical promises. This would impinge on the Board's ability to holistically adjust such economic numbers, for example, to create a new incentive by going even further than the policy, or less than the policy to achieve its aims. The author and AC might consider substitution of an alternative draft policy that gives strong directional adjectival guidance to the Board, but does not contain specific amounts. For example, and I believe consistent with the proposed policy, the policy adopted can make clear the community is sending clear guidance that the economic inducements for legacy address holders to sign a new and publicly available alternative RSA for legacy holders can be accomplished more deftly by providing an RSA, not a policy. The discussion approved to accompany the policy can contain non-binding but specific recommendations for this purpose, which the Board would probably welcome. An RSA is a contract. ARIN can unilaterally bind itself in such contracts, promising consistent future terms, including any promise ARIN chooses to make to not charge for certain services. But the RSA can also be phased out, not impacting contracted parties, but not be available for future parties who do not sign up. Such flexibility in the RSA, with the Board following aspirational policy is a correct direction for the continued development of this proposal.? Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Registration Services Guidelines will be required - Staff training will be required - Tracking tools for the return of the space Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests: ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. The organization returning the addresses shall have 12 months from the date they receive their new addresses to return the addresses under this policy. Organizations may request no more than 2 six month extensions to this time, which, may be granted at ARIN the discretion of ARIN staff. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. The BoT shall develop an incentive program to encourage such returns. Such incentives may include fee reductions and/or other such mechanisms as the BoT deems appropriate. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 and ASN resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. It is suggested that the BoT adopt fee incentives such as the elimination of 2 years of ARIN fees for each /20 returned. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:42:48 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:42:48 -0400 Subject: [ppml] Policy Proposal 2007-18 - Staff Assessment Message-ID: <47129B68.3070009@arin.net> Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_18.html II. Understanding of the proposal ARIN staff understands that this proposal is a global proposal. It would reserve a certain number of /8s in the IANA pool to be allocated to the RIRs when the remaining IANA /8s run out. The suggested reserve is 25 /8s, 5 per each RIR. When the IANA can not fulfill the last RIR request, they will give what they can to that RIR. The IANA will then allocate the 5 /8s to each RIR. III. Comments A. ARIN Staff 1. The policy conflicts with the spirit of RFC 2050 in which fairness and efficiency of allocation by IANA to the RIRs is cited. 2. If additional addresses are made available to IANA at some point after the exhaustion phase is triggered, this policy would need to be revised before IANA could do anything with the addresses. 3. Author did not indicate placement in the NRPM. Staff would add it to Section 10. B. ARIN General Counsel "These two policies address the same issue, the global policy of what allocation should be made and when regarding the last unissued IPv4 slash 8's from the IANA. Based on legal considerations counsel has serious concerns about the implications of adopting 2007-18. Counsel does not have similar concerns about 2007-23. 2007-23 describes a policy to allocate equally the last 5 blocs of unissued slash 8's, providing one each to each of the 5 RIR's. This is a rationing mechanism to allocate the last slash 8's. 2007-18 describes much more aggressive policy which would allocate the last 25 such blocs equally, providing 5 each to each RIR. The first policy proposal, 2007-23, is more consistent with the current legal underpinnings of the RIR system, while 2007-23 substitutes a new basis of allocation, equality between RIRs, who have very different rates of utilization and need. The substitution of utilizing RIR equality instead of a utilization based allocation may have significant legal implications for ARIN. Currently, if ARIN is legally challenged about its allocation policies, and the underlying global policy, all current policies are based in need and utilization. Since the takeup rate in each RIR is very different the allocation policy proposed in 2007-23 undermines the current rationale of need and utilization based allocation, and it is inconsistent with all prior ARIN and global allocation policies. Adoption of 2007-23 discriminates against the ARIN service region and could reduce the amount of IPv4 resources available and instead shift these resources to other continents, with less actual need than the ARIN region. This will, in my opinion, raise fiduciary responsibility issues for ARIN's Board, and may lead to counsel cautioning the Board members regarding adoption of global policy that has an intentionally discriminatory impact against or adverse to ARIN's service region." Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space Author: Roque Gagliano Co-authors: Francisco Obispo, Hytham EL Nakhal, Didier Allain Kla Proposal type: new Policy term: permanent Policy statement: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, an identical number of IPv4 allocation units (N units) will be reserved by IANA for each RIR. The number N is defined as: 5. The reserved allocation units will no longer be part of the available space at the IANA pool. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA cannot be fulfilled with the remaining IPv4 space available at the IANA pool. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate N allocation units to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly. A new policy is proposed to replace the current "on demand" policy in order to bring certainty on how the remaining space will be allocated. This policy eliminates the pressure on the remaining central pool of addresses by allocating equal amount of allocation units (N) to each RIR. RIR may be studying slow-landing policies or the possibility to reserve specific address spaces for "critical infrastructure" or new companies in order to comply with anti-trust regulations in its region. This policy allows each RIR to adopt those policies through its PDP, which is simpler than a global policy discussion process. Each RIR will have the exact information on the amount of address spaces that they will be receiving as a last allocation from the IANA. The policy is written in such a way that the discussion could be split in two sections: first do we agree on the concept of the policy and second what is the appropriate value for the last allocation units N. Timetable for implementation: This is a Global policy that needs to be approved by all RIRs and then ratified by ASO/ICANN. It has already reached consensus at LACNIC meeting. From info at arin.net Sun Oct 14 18:43:29 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:43:29 -0400 Subject: [ppml] Policy Proposal 2007-19 - Staff Assessment Message-ID: <47129B91.4050608@arin.net> Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_19.html II. Understanding of the proposal ARIN staff understands that this proposal is a global proposal. It would create policy for IANA to RIR regarding allocations of ASNs. Block size is 1024. Allocations for 12 months need. Until 31 Dec 2009, allocations of 2-byte and 4-byte blocks are separate. RIRs request additional ASNs when either at 80% or at less than two months need. III. Comments A. ARIN Staff 1. The ?Additional Allocations? section indicates an RIR can receive an additional ASN allocation when the RIR ?has assigned/allocated 80% of the previously received ASN block?. After 12/31/2009, there will be no distinction made between 2 byte AS numbers and 4 byte AS numbers per policy. Does ?previously received ASN block? literally mean the most recent ASN block (even if it was a 2 byte only block), or does it mean 80% of both the most recent 4 byte block and the most recent 2 byte block? If it?s the latter, one ASN block would never be audited, since it would never be ?the most recent ASN block allocated?. 2. The policy will be inserted in Section 10 of the NRPM. B. ARIN General Counsel "Counsel has no legal concerns regarding this policy. Counsel believes policies allocating resources based on usage and need are consistent with the operating philosophy of the RIR Community. Other policy proposals, inconsistent with this philosophy should be subject to greater scrutiny." Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs Author: Axel Pawlik Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Policy Rationale Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:43:55 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:43:55 -0400 Subject: [ppml] Policy Proposal 2007-21 - Staff Assessment Message-ID: <47129BAB.8090902@arin.net> Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_21.html II. Understanding of the proposal ARIN staff understands that this proposal would make direct assignments of IPv6 space available to any organization with an efficiently utilized v4 assignment or allocation covered under an RSA. III. Comments A. ARIN Staff The title uses the words ?legacy holder? which is never mentioned within the policy text. B. ARIN General Counsel This policy does not create any legal concerns. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - New process to manually add RSA coverage will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal type: new Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of a direct IPv4 assignment or allocation covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Sun Oct 14 18:44:27 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:44:27 -0400 Subject: [ppml] Policy Proposal 2007-22 - Staff Assessment Message-ID: <47129BCB.3040107@arin.net> Policy Proposal 2007-22 Expand timeframe of Additional Requests ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_22.html II. Understanding of the proposal ARIN staff understands that the proposal would change the allocation timeframe in 4.2.4.4 from six months to 12. III. Comments A. ARIN Staff 1. In addition to changing the time period from 6 months to one year, this policy removes the qualification criteria that a member be a subscriber with a direct ARIN allocation. If an organization has no allocation history with ARIN, it makes it difficult to reliably verify and evaluate a 12 month projection. 2. ARIN staff suggests changing the section name of NRPM 4.2.4.4 from "Six months" to "Twelve months". B. ARIN General Counsel Counsel does not believe this policy raises legal concerns. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimal. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - Template changes will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-22 Expand timeframe of Additional Requests Author: Dan Alexander Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From info at arin.net Sun Oct 14 18:45:00 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:45:00 -0400 Subject: [ppml] Policy Proposal 2007-23 - Staff Assessment Message-ID: <47129BEC.2080605@arin.net> Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_23.html II. Understanding of the proposal ARIN staff understands that this policy would have IANA allocate a single /8 to each of the 5 RIRs at the point when the IANA free pool hits 5 /8s. III. Comments A. ARIN Staff 1. Item 3 indicates that the RIRs will project an IANA exhaustion date. The RIRs do not generally make projections about address space, and in particular, about the IANA pool since they have no control over these resource. 2. The policy conflicts with the spirit of RFC 2050 in which fairness and efficiency of allocation by IANA to the RIRs is cited. 3. Author did not indicate placement in the NRPM. It would go in to Section 10. B. ARIN General Counsel "These two policies address the same issue, the global policy of what allocation should be made and when regarding the last un-issued IPv4 slash 8's from the IANA. Based on legal considerations counsel has serious concerns about the implications of adopting 2007-18. Counsel does not have similar concerns about 2007-23. 2007-23 describes a policy to allocate equally the last 5 blocs of un-issued slash 8's, providing one each to each of the 5 RIR's. This is a rationing mechanism to allocate the last slash 8's. 2007-18 describes much more aggressive policy which would allocate the last 25 such blocs equally, providing 5 each to each RIR. The first policy proposal, 2007-23, is more consistent with the current legal underpinnings of the RIR system, while 2007-23 substitutes a new basis of allocation, equality between RIRs, who have very different rates of utilization and need. The substitution of utilizing RIR equality instead of a utilization based allocation may have significant legal implications for ARIN. Currently, if ARIN is legally challenged about its allocation policies, and the underlying global policy, all current policies are based in need and utilization. Since the takeup rate in each RIR is very different the allocation policy proposed in 2007-23 undermines the current rationale of need and utilization based allocation, and it is inconsistent with all prior ARIN and global allocation policies. Adoption of 2007-23 discriminates against the ARIN service region and could reduce the amount of IPv4 resources available and instead shift these resources to other continents, with less actual need than the ARIN region. This will, in my opinion, raise fiduciary responsibility issues for ARIN's Board, and may lead to counsel cautioning the Board members regarding adoption of global policy that has an intentionally discriminatory impact against or adverse to ARIN's service region." Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 -90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA, Akira NAKAGAWA, Izumi OKUTANI, Kosuke ITO, Kuniaki KONDO, Shuji NAKAMURA, Susumu SATO, Takashi ARANO, Tomohiro FUJISAKI, Tomoya YOSHIDA, Toshiyuki HOSAKA Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From info at arin.net Sun Oct 14 18:45:38 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:45:38 -0400 Subject: [ppml] Policy Proposal 2007-24 - Staff Assessment Message-ID: <47129C12.4040503@arin.net> Policy Proposal 2007-24 IPv6 Assignment Guidelines ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_24.html II. Understanding of the proposal ARIN staff understands that this proposal would replace 6.5.4.1. Instead of the assignment size being a decision of the LIR or ISP, the actual prefix to be assigned would be based on a subnet count. III. Comments A. ARIN Staff 1. Currently, there have been 54 IPv6 reassignments/reallocations larger than /48 made by ISPs to their customers. If staff is expected to review each and every one larger than /48, this could significantly increase workload and turnaround times. 2. If staff is expected to review all reassignments larger than /48, should this be done at the time the reassignment is made or at the time the organization is requesting additional IPv6 space from ARIN? B. ARIN General Counsel Counsel does not believe this policy creates any legal issues. Resource Impact ? Moderate The resource impact of implementing this policy is viewed as moderate. Barring any unforeseen resource requirements, this policy could be implemented within 3 ? 6 months from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - Template changes will be required (text fields only, no software impact) - Sustaining this activity could require the need for additional staff and associated costs. Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-24 IPv6 Assignment Guidelines Author: Leo Bicknell and Ed Lewis Proposal type: new Policy term: permanent Policy statement: Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with the following text: Assignments by LIRs /48 or smaller will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how ARIN should treat prefixes allocated to a site should an ISP come back for additional space in the future. This makes it difficult for LIR's to know if they are allocating in accordance with the rules under which they will be judged in the future. The existing section also provides no guidence on what the LIR or ARIN should do in the case a larger prefix is necessary. Timetable for implementation: immediate From info at arin.net Sun Oct 14 18:46:08 2007 From: info at arin.net (Member Services) Date: Sun, 14 Oct 2007 18:46:08 -0400 Subject: [ppml] Policy Proposal 2007-25 - Staff Assessment Message-ID: <47129C30.2020303@arin.net> Policy Proposal 2007-25 IPv6 Policy Housekeeping ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_25.html II. Understanding of the proposal ARIN staff understands that this proposal would make changes to the IPv6 section of the NRPM. It would remove the prefix size from the initial IPv6 allocation criteria, move a modified version of 6.5.3 to a new location (6.5.4.4), establish criteria for assignments larger than a /48 (.94 HD-Ratio), and make reserved space (from the /44s) available for other use. III. Comments A. ARIN Staff 1. Change I - the statement be a ?known ISP? is still contained in this policy. This term is ambiguous and open to interpretation and should be defined. It should be noted that there is no authoritative definition for either ISP or LIR. 2. Change J - The section number, 6.5.3, would be retired instead of renumbering all the subsequent sections. B. ARIN General Counsel Counsel does not believe this policy creates any legal issues that need further consideration. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Guidelines will be required - Staff training will be required - May be minor text changes to the template Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-25 IPv6 Policy Housekeeping Author: Leo Bicknell Proposal type: modify Policy term: permanent Policy statement: Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. Timetable for implementation: Immediate From bcasne at millerwelds.com Sun Oct 14 20:05:29 2007 From: bcasne at millerwelds.com (BRUCE CASNER) Date: Sun, 14 Oct 2007 19:05:29 -0500 Subject: [ppml] PPML Digest, Vol 28, Issue 28 In-Reply-To: References: Message-ID: <47126879.93F5.00AD.0@millerwelds.com> I look forward to this document. -- Date: Thu, 11 Oct 2007 17:21:17 -0400 From: Member Services Subject: [ppml] Legacy RSA To: arin-announce at arin.net, ppml at arin.net Message-ID: <470E93CD.4080506 at arin.net> Content-Type: text/plain; charset=windows-1252; format=flowed On 17 October 2007 ARIN will release an additional version of the Registration Services Agreement ("RSA") that will be offered to those organizations and individuals in the ARIN service region who hold legacy Internet number resources that are not covered by any other registration services agreement with ARIN. Legacy holders who sign up are guaranteed the same services as ARIN members. The low annual fees charged may be waived if the organization returns unused address space. This legacy RSA also contractually promises ARIN Internet number resource policies adopted after the contract is signed will not lessen the legacy RSA address holder?s contract rights. This legacy RSA will be described during presentations at the upcoming NANOG meeting, ARIN Public Policy Meeting, and ARIN Members meeting. Regards, Raymond A. Plzak President & CEO American Registry for Internet Numbers (ARIN) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bicknell at ufp.org Mon Oct 15 10:09:51 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 15 Oct 2007 10:09:51 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: Message-ID: <20071015140951.GA68372@ussenterprise.ufp.org> In a message written on Sun, Oct 14, 2007 at 05:32:14PM -0400, Dean Anderson wrote: > BTW, can you explain why there are no ARIN records for AS27322, AS30130, > or AS30131? These are in ARIN AS Blocks. RADB has records that point to > ISC, and ISC Address blocks originate from these AS numbers. [More > unusual record-keeping problems for ARIN BoT Members related to RADB, > too. tsk.tsk.] $ whois -h whois.arin.net 27322 OrgName: Internet Systems Consortium, Inc. OrgID: ISC-94 Address: 950 Charter Street City: Redwood City StateProv: CA PostalCode: 94063 Country: US ASNumber: 27318 - 27322 ASName: ISC-F-AS ASHandle: AS27318 Comment: RegDate: 2003-02-12 Updated: 2004-10-05 OrgAbuseHandle: ISCAT-ARIN OrgAbuseName: Internet Systems Consortium Abuse Team OrgAbusePhone: +1-650-423-1300 OrgAbuseEmail: abuse at isc.org OrgNOCHandle: ISCN-ARIN OrgNOCName: Internet Systems Consortium NOC OrgNOCPhone: +1-650-423-1310 OrgNOCEmail: noc at isc.org OrgTechHandle: JDA87-ARIN OrgTechName: Damas, Joao OrgTechPhone: +1-650-423-1312 OrgTechEmail: Joao_Damas at isc.org # ARIN WHOIS database, last updated 2007-10-14 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. $ whois -h whois.arin.net 30130 OrgName: Internet Systems Consortium, Inc. OrgID: ISC-94 Address: 950 Charter Street City: Redwood City StateProv: CA PostalCode: 94063 Country: US ASNumber: 30122 - 30134 ASName: ISC-F-AS ASHandle: AS30122 Comment: For details of F root nameserver operations, see Comment: http://f.root-servers.org/ RegDate: 2003-07-28 Updated: 2004-10-05 OrgAbuseHandle: ISCAT-ARIN OrgAbuseName: Internet Systems Consortium Abuse Team OrgAbusePhone: +1-650-423-1300 OrgAbuseEmail: abuse at isc.org OrgNOCHandle: ISCN-ARIN OrgNOCName: Internet Systems Consortium NOC OrgNOCPhone: +1-650-423-1310 OrgNOCEmail: noc at isc.org OrgTechHandle: JDA87-ARIN OrgTechName: Damas, Joao OrgTechPhone: +1-650-423-1312 OrgTechEmail: Joao_Damas at isc.org # ARIN WHOIS database, last updated 2007-10-14 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. $ whois -h whois.arin.net 30131 OrgName: Internet Systems Consortium, Inc. OrgID: ISC-94 Address: 950 Charter Street City: Redwood City StateProv: CA PostalCode: 94063 Country: US ASNumber: 30122 - 30134 ASName: ISC-F-AS ASHandle: AS30122 Comment: For details of F root nameserver operations, see Comment: http://f.root-servers.org/ RegDate: 2003-07-28 Updated: 2004-10-05 OrgAbuseHandle: ISCAT-ARIN OrgAbuseName: Internet Systems Consortium Abuse Team OrgAbusePhone: +1-650-423-1300 OrgAbuseEmail: abuse at isc.org OrgNOCHandle: ISCN-ARIN OrgNOCName: Internet Systems Consortium NOC OrgNOCPhone: +1-650-423-1310 OrgNOCEmail: noc at isc.org OrgTechHandle: JDA87-ARIN OrgTechName: Damas, Joao OrgTechPhone: +1-650-423-1312 OrgTechEmail: Joao_Damas at isc.org -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From arin-contact at dirtside.com Mon Oct 15 11:17:57 2007 From: arin-contact at dirtside.com (William Herrin) Date: Mon, 15 Oct 2007 11:17:57 -0400 Subject: [ppml] Statements of support for the proposals Message-ID: <3c3e3fca0710150817y3424332dw630c653f19622c4a@mail.gmail.com> Hi folks, I thought it might be helpful to compile statements of support or opposition for each of the pending policy proposals in a single message along with a brief reason why/why not. I encourage others to do the same. 2006-7 Changes to IPv6 initial allocation criteria I have no strong feelings one way or another on this proposal. It seems reasonable to me to starting thinking about what initial allocations look like in a post-IPv4 world. Having accepted a policy which enables that process, we'd be in a position to start gaining operational experience. Maybe we'd learn how we need to adjust the policy before major demand hits. 2007-13: Removal of ISP Immediate Need from End-User I SUPPORT proposal 2007-13. I'd support a proposal to remove 4.2.1.6 too, but maybe I like planning too much. 2007-14: Resource Review Process I SUPPORT proposal 2007-14. Counsel has the right of it. 2007-15: Authentication of Legacy Resources I OPPOSE proposal 2007-15. I support efforts like the recently offered "Legacy RSA" and outreach in general but the time for penalizing Legacy folks who don't join up has not yet arrived, may never arrive and certainly won't arrive in the next 80 days. 2007-16: IPv4 Soft Landing I SUPPORT proposal 2007-16. Staff has suggested some reasonable adjustments, but the proposal is otherwise a darn good idea. Folks still gobbling IPv4 address space at this late date SHOULD demonstrate that they're getting themselves and their customers ready for the day when there are no more IPv4 addresses. Even if this does mean more work for ARIN staff. 2007-17: Legacy Outreach and Partial Reclamation I neither support nor oppose this proposal. Your heart's in the right place Owen, but I'm not convinced this is the best way to go about it. 2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space I OPPOSE proposal 2007-18. Grabbing the last 25 /8's like this is too much and the division between the RIRs is unfair. The general idea is good but I'd prefer to see 2007-23 enacted. 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs I neither support nor oppose this proposal. I frankly don't understand what problem its attempting to solve. Is there something about the way we currently assign ASNs that's troublesome? 2007-21: PIv6 for legacy holders with RSA and efficient use I STRONGLY SUPPORT proposal 2007-21. The IPv6 deployment process is in enough trouble as it is without disenfranchising (and thus pissing off) small orgs who are already multihomed with IPv4. Because of the significant cost of running dual stack everywhere we may only get one chance to deploy a protocol like IPv6. If we shoot ourselves in the foot the price could be IPv4 forever, or at least until something replaces BGP at a couple orders of magnitude lower cost. 2007-22: Expand timeframe of Additional Requests I OPPOSE proposal 2007-22. With 3 years before the free pool runs dry, now is not the time to extend the forward window for allocations. 2007-23: End Policy for IANA IPv4 allocations to RIRs I SUPPORT proposal 2007-23. Although it potentially denies us one last /8 in favor of Afrinic, it buys us a longer window of time at the end to enact whatever final conservation policies we choose to. We have time left to bicker about what ARIN's policy should then be, but there is a limited amount of time left in which we'll be able to get global consensus on policy which enables that activity. 2007-24: IPv6 Assignment Guidelines I neither support nor oppose this proposal. In general, I have difficulty seeing the need. RIPE with their /19's will burn us out of IPv6 addresses long before ARIN's review process causes any meaningful difficulty. 2007-25: IPv6 Policy Housekeeping I SUPPORT proposal 2007-25. Its intended to be an inoffensive cleanup of the NRPM and it achieves its goal. 2007-26 came in after the deadline for this meeting, did it not? In general I support it. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From dean at av8.net Mon Oct 15 14:44:02 2007 From: dean at av8.net (Dean Anderson) Date: Mon, 15 Oct 2007 14:44:02 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <20071015140951.GA68372@ussenterprise.ufp.org> Message-ID: Must be a problem with whois. For these 3 records, whois as27322 @whois.arin.net doesn't work. whois 27322 @whois.arin.net works. --Dean [Querying whois.arin.net] [whois.arin.net] No match found for AS27322. # ARIN WHOIS database, last updated 2007-10-13 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. [dean at citation2 PaulVixie]$ whois as27322 @whois.arin.net [Querying whois.arin.net] [whois.arin.net] No match found for as27322. # ARIN WHOIS database, last updated 2007-10-14 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. On Mon, 15 Oct 2007, Leo Bicknell wrote: > In a message written on Sun, Oct 14, 2007 at 05:32:14PM -0400, Dean Anderson wrote: > > BTW, can you explain why there are no ARIN records for AS27322, AS30130, > > or AS30131? These are in ARIN AS Blocks. RADB has records that point to > > ISC, and ISC Address blocks originate from these AS numbers. [More > > unusual record-keeping problems for ARIN BoT Members related to RADB, > > too. tsk.tsk.] > > $ whois -h whois.arin.net 27322 > > OrgName: Internet Systems Consortium, Inc. > OrgID: ISC-94 > Address: 950 Charter Street > City: Redwood City > StateProv: CA > PostalCode: 94063 > Country: US > > ASNumber: 27318 - 27322 > ASName: ISC-F-AS > ASHandle: AS27318 > Comment: > RegDate: 2003-02-12 > Updated: 2004-10-05 > > OrgAbuseHandle: ISCAT-ARIN > OrgAbuseName: Internet Systems Consortium Abuse Team > OrgAbusePhone: +1-650-423-1300 > OrgAbuseEmail: abuse at isc.org > > OrgNOCHandle: ISCN-ARIN > OrgNOCName: Internet Systems Consortium NOC > OrgNOCPhone: +1-650-423-1310 > OrgNOCEmail: noc at isc.org > > OrgTechHandle: JDA87-ARIN > OrgTechName: Damas, Joao > OrgTechPhone: +1-650-423-1312 > OrgTechEmail: Joao_Damas at isc.org > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > $ whois -h whois.arin.net 30130 > > OrgName: Internet Systems Consortium, Inc. > OrgID: ISC-94 > Address: 950 Charter Street > City: Redwood City > StateProv: CA > PostalCode: 94063 > Country: US > > ASNumber: 30122 - 30134 > ASName: ISC-F-AS > ASHandle: AS30122 > Comment: For details of F root nameserver operations, see > Comment: http://f.root-servers.org/ > RegDate: 2003-07-28 > Updated: 2004-10-05 > > OrgAbuseHandle: ISCAT-ARIN > OrgAbuseName: Internet Systems Consortium Abuse Team > OrgAbusePhone: +1-650-423-1300 > OrgAbuseEmail: abuse at isc.org > > OrgNOCHandle: ISCN-ARIN > OrgNOCName: Internet Systems Consortium NOC > OrgNOCPhone: +1-650-423-1310 > OrgNOCEmail: noc at isc.org > > OrgTechHandle: JDA87-ARIN > OrgTechName: Damas, Joao > OrgTechPhone: +1-650-423-1312 > OrgTechEmail: Joao_Damas at isc.org > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > $ whois -h whois.arin.net 30131 > > OrgName: Internet Systems Consortium, Inc. > OrgID: ISC-94 > Address: 950 Charter Street > City: Redwood City > StateProv: CA > PostalCode: 94063 > Country: US > > ASNumber: 30122 - 30134 > ASName: ISC-F-AS > ASHandle: AS30122 > Comment: For details of F root nameserver operations, see > Comment: http://f.root-servers.org/ > RegDate: 2003-07-28 > Updated: 2004-10-05 > > OrgAbuseHandle: ISCAT-ARIN > OrgAbuseName: Internet Systems Consortium Abuse Team > OrgAbusePhone: +1-650-423-1300 > OrgAbuseEmail: abuse at isc.org > > OrgNOCHandle: ISCN-ARIN > OrgNOCName: Internet Systems Consortium NOC > OrgNOCPhone: +1-650-423-1310 > OrgNOCEmail: noc at isc.org > > OrgTechHandle: JDA87-ARIN > OrgTechName: Damas, Joao > OrgTechPhone: +1-650-423-1312 > OrgTechEmail: Joao_Damas at isc.org > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From bmanning at vacation.karoshi.com Mon Oct 15 15:19:38 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 15 Oct 2007 19:19:38 +0000 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <20071015140951.GA68372@ussenterprise.ufp.org> Message-ID: <20071015191938.GA7319@vacation.karoshi.com.> which client are you using? mine has no support for using the @ in queries and the options/query order is important. the one you used might have similar constraints. e.g. $ whois 4555 @whois.arin.net Whois Server Version 2.0 Domain names in the .com and .net domains can now be registered with many different competing registrars. Go to http://www.internic.net for detailed information. 4555.NET 4555.COM No match for "@WHOIS.ARIN.NET". >>> Last update of whois database: Mon, 15 Oct 2007 19:13:33 UTC <<< vs... $ whois -h whois.arin.net 4555 OrgName: Exchange Point Blocks OrgID: EPB Address: PO 12317 City: Marina del Rey StateProv: CA PostalCode: Country: US ASNumber: 4555 ASName: EP0-BLK-ASNBLOCK-5 ASHandle: AS4555 Comment: RegDate: Updated: 1998-02-02 RTechHandle: WM110-ARIN RTechName: Manning, Bill RTechPhone: +1-310-322-8102 RTechEmail: bmanning at karoshi.com # ARIN WHOIS database, last updated 2007-10-14 19:10 ======================================================================== On Mon, Oct 15, 2007 at 02:44:02PM -0400, Dean Anderson wrote: > Must be a problem with whois. For these 3 records, > > whois as27322 @whois.arin.net > > doesn't work. > > whois 27322 @whois.arin.net works. > > --Dean > > [Querying whois.arin.net] > [whois.arin.net] > > No match found for AS27322. > > # ARIN WHOIS database, last updated 2007-10-13 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > [dean at citation2 PaulVixie]$ whois as27322 @whois.arin.net > [Querying whois.arin.net] > [whois.arin.net] > > No match found for as27322. > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > # Enter ? for additional hints on searching ARIN's WHOIS database. > > > On Mon, 15 Oct 2007, Leo Bicknell wrote: > > > In a message written on Sun, Oct 14, 2007 at 05:32:14PM -0400, Dean Anderson wrote: > > > BTW, can you explain why there are no ARIN records for AS27322, AS30130, > > > or AS30131? These are in ARIN AS Blocks. RADB has records that point to > > > ISC, and ISC Address blocks originate from these AS numbers. [More > > > unusual record-keeping problems for ARIN BoT Members related to RADB, > > > too. tsk.tsk.] > > > > $ whois -h whois.arin.net 27322 > > > > OrgName: Internet Systems Consortium, Inc. > > OrgID: ISC-94 > > Address: 950 Charter Street > > City: Redwood City > > StateProv: CA > > PostalCode: 94063 > > Country: US > > > > ASNumber: 27318 - 27322 > > ASName: ISC-F-AS > > ASHandle: AS27318 > > Comment: > > RegDate: 2003-02-12 > > Updated: 2004-10-05 > > > > OrgAbuseHandle: ISCAT-ARIN > > OrgAbuseName: Internet Systems Consortium Abuse Team > > OrgAbusePhone: +1-650-423-1300 > > OrgAbuseEmail: abuse at isc.org > > > > OrgNOCHandle: ISCN-ARIN > > OrgNOCName: Internet Systems Consortium NOC > > OrgNOCPhone: +1-650-423-1310 > > OrgNOCEmail: noc at isc.org > > > > OrgTechHandle: JDA87-ARIN > > OrgTechName: Damas, Joao > > OrgTechPhone: +1-650-423-1312 > > OrgTechEmail: Joao_Damas at isc.org > > > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > > # Enter ? for additional hints on searching ARIN's WHOIS database. > > $ whois -h whois.arin.net 30130 > > > > OrgName: Internet Systems Consortium, Inc. > > OrgID: ISC-94 > > Address: 950 Charter Street > > City: Redwood City > > StateProv: CA > > PostalCode: 94063 > > Country: US > > > > ASNumber: 30122 - 30134 > > ASName: ISC-F-AS > > ASHandle: AS30122 > > Comment: For details of F root nameserver operations, see > > Comment: http://f.root-servers.org/ > > RegDate: 2003-07-28 > > Updated: 2004-10-05 > > > > OrgAbuseHandle: ISCAT-ARIN > > OrgAbuseName: Internet Systems Consortium Abuse Team > > OrgAbusePhone: +1-650-423-1300 > > OrgAbuseEmail: abuse at isc.org > > > > OrgNOCHandle: ISCN-ARIN > > OrgNOCName: Internet Systems Consortium NOC > > OrgNOCPhone: +1-650-423-1310 > > OrgNOCEmail: noc at isc.org > > > > OrgTechHandle: JDA87-ARIN > > OrgTechName: Damas, Joao > > OrgTechPhone: +1-650-423-1312 > > OrgTechEmail: Joao_Damas at isc.org > > > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > > # Enter ? for additional hints on searching ARIN's WHOIS database. > > $ whois -h whois.arin.net 30131 > > > > OrgName: Internet Systems Consortium, Inc. > > OrgID: ISC-94 > > Address: 950 Charter Street > > City: Redwood City > > StateProv: CA > > PostalCode: 94063 > > Country: US > > > > ASNumber: 30122 - 30134 > > ASName: ISC-F-AS > > ASHandle: AS30122 > > Comment: For details of F root nameserver operations, see > > Comment: http://f.root-servers.org/ > > RegDate: 2003-07-28 > > Updated: 2004-10-05 > > > > OrgAbuseHandle: ISCAT-ARIN > > OrgAbuseName: Internet Systems Consortium Abuse Team > > OrgAbusePhone: +1-650-423-1300 > > OrgAbuseEmail: abuse at isc.org > > > > OrgNOCHandle: ISCN-ARIN > > OrgNOCName: Internet Systems Consortium NOC > > OrgNOCPhone: +1-650-423-1310 > > OrgNOCEmail: noc at isc.org > > > > OrgTechHandle: JDA87-ARIN > > OrgTechName: Damas, Joao > > OrgTechPhone: +1-650-423-1312 > > OrgTechEmail: Joao_Damas at isc.org > > > > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. From tedm at ipinc.net Mon Oct 15 15:43:01 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Oct 2007 12:43:01 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <47120E7A.4000601@psg.com> Message-ID: Well, Randy and Dean, I'm going to address both of you since you seem to be on the same side here. See here. The non-legacy community doesen't have infinite patience in dealing with you. The legacy RSA that is coming up for discussion is the paying communities attempt to accomodate your desires. You don't like it, well frankly not all of us like it either. You can choose to participate in the discussion to try to make the legacy RSA proposal more to your liking or not. But I will warn you, and the rest of the folks that seem to think like you - meaning, your not going to participate no matter what. This legacy RSA proposal is going to be the last offer your going to get. Once it's complete - in whatever form it ends up in - your going to see a number of legacy holders sign it. If you don't, fine - but the community isn't going to have the patience to come out with yet one more, different version of a legacy RSA that is more to your liking - not only is there no patience for it, but the existing legacy holders that end up signing this, who do decide to participate, are going to feel cheated if the community continues catering to you. We - the paying community - aren't going to screw over the legacy holders that DO decide to come in and play with the rest of us and sign this RSA. So, there won't be another legacy RSA offered to you again. Frankly, you should have shut your mouths about this in the beginning, because IMHO it has been the continual insistance that legacy IP numbers are property which has spurred this initative. Your choice, if you decide to not sign, will be to live under uncertainty as to what happens to your IPv4 blocks. Your central argument of your claim boils down to IP (IPv4) numbers are property, and you got property from someone a while ago. This is a position that is utterly unsupportable by the rest of the community. We are not going to give a damn if you get some US court to rule in your favor - ARIN will move every last nexus out of the US if that were to happen and remain in permanent voilation of whatever US court ruling exists - because the idea that IP numbers are property would destroy the entire IP number assignment mechanism for ALL rir's on a global scale. And the rest of the administrators on the Internet are not going to listen to a US court telling them what to do - and administrators in the US that might be legally compelled to recognise your IPv4 claim, well they may do so - but what good is that if the rest of the Internet doesen't. You are living under the delusion that the US dictates terms on the Internet to the rest of the world. And in any case, the liklihood of getting a US court to rule in your favor is extremely slim. Good luck getting the UN and the world court to see your way - because that is what your going to have to do if you insist on this rediculous course of claiming that IP numbers are property. If you don't sign a legacy RSA then eventually, somewhere, in a post-IPv4 runout world, your IP blocks will be poached by someone. And your going to have a hell of a time getting any support from anyone in the community to help you. It's your choice. Ted >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Randy Bush >Sent: Sunday, October 14, 2007 5:42 AM >To: John Curran >Cc: Public Policy Mailing List >Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > >>>> The terms of the current RSA include both of these >>>> as well. We tried to stay as close to the current RSA >>>> as possible (for fairness to existing members), with >>>> the addition of the language which recognizes the >>>> legacy holders status with respect to policies which >>>> might otherwise reduce their rights. >>> section 9 is a wonderful example of rights reduction. >> >> One can look at it that way, but it comes along with 10(b) >> which states: "ARIN will take no action to reduce the services >> provided for Included Number Resources that are not currently >> being utilized by the Legacy Applicant." > >and that ameliorates section 9 exactly how? > >to be clear, no one's lawyer, who has half a clue, will advise them to >enter into this contract, section 9 being the poster child. > >randy >_______________________________________________ >PPML >You are receiving this message because you are subscribed to the >ARIN Public Policy >Mailing List (PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml Please contact the >ARIN Member Services >Help Desk at info at arin.net if you experience any issues. > From owen at delong.com Mon Oct 15 16:35:38 2007 From: owen at delong.com (Owen DeLong) Date: Mon, 15 Oct 2007 13:35:38 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: Message-ID: <1386FE31-4B95-4D1F-9FD4-8404541B5CE3@delong.com> Did I miss an election where Ted was appointed spokesperson for the entire non-legacy community? Ted, I really don't think you have any right to speak for all of us, and, I, for one complete disagree with much of what you have said. I think your tone is unnecessarily antagonistic, much as I think this is true of Dean and Randy as well. How about the three of you go find a room or a ring somewhere and duke it out while the rest of us actually continue trying to find a workable solution in an amicable and respectful manner? On Oct 15, 2007, at 12:43 PM, Ted Mittelstaedt wrote: > > Well, Randy and Dean, I'm going to address both of you since you seem > to be on the same side here. > > See here. The non-legacy community doesen't have infinite patience > in dealing with you. The legacy RSA that is coming up for > discussion is > the paying communities attempt to accomodate your desires. You don't > like it, well frankly not all of us like it either. You can choose to > participate in the discussion to try to make the legacy RSA proposal > more to your liking or not. [snip...] Owen From kkargel at polartel.com Mon Oct 15 16:52:10 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 15 Oct 2007 15:52:10 -0500 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <1386FE31-4B95-4D1F-9FD4-8404541B5CE3@delong.com> References: <1386FE31-4B95-4D1F-9FD4-8404541B5CE3@delong.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A06314106670765B@mail> For a more non-violent solution maybe they could just line up at the railing and see just who really can pee farthest.. :) I hope though that everyone isn't going into a put-up-your-dukes mine-is-bigger-than-yours mode here. Cooperative anarchy is what has kept the "Internet" working so far, and it will be what keeps it working for some time in the future. If we lose the cooperative part of that then the whole thing goes to you-know-where in a handbasket. Put this in the hands of courts and governments and when taxation is implemented to pay for administration none of us will be able to afford connectivity. The active community paying to support ARIN is certainly doing their part to keep things going and working smoothly. I think everyone is doing a pretty good job of it. We cannot forget that the Legacy holders were the pioneers that got this whole ball rolling, and bad things come of dismissing your ancestors. I am sure there is a solution that protects both the legacy holders and the active ARIN community, without serving one at the others expense. If we keep working to that end we will work something out. I suppose one of the things the Legacy holders could do if they were unwilling to compromise or join the fold would be to institute their own registry (Legacy Registration Authority - LSA?), and see if they offered enough value to the "community" that it would accept routing advertisements from that registry. This is assuming theLegacy Holders could come to a consensus amongst themselves. If they did that ARIN could just stop advertising legacy blocks, let the legacy organizations shepherd their own space and sidestep the whole political tar baby. Speaking for myself, I would continue to support the ARIN community and accept advertisements from ARIN, and accept only those unique advertisements from the Legacy registry where my customers demanded it. I would not accept any advertisements from the legacy registry where they also existed at ARIN. I can't see this working, and I don't advocate it by any means, but it may be a less evil alternative to surrendering to government control. If the Legacy holders think ARIN is inflexible and dictatorial, I would hate to hear what they thought of a myriad of governmental regulatory agencies. Just my two cents worth.. I don't claim it is worth more than that. Kevin > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Owen DeLong > Sent: Monday, October 15, 2007 3:36 PM > To: Ted Mittelstaedt > Cc: Randy Bush; Public Policy Mailing List > Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > Did I miss an election where Ted was appointed spokesperson > for the entire non-legacy community? > > Ted, I really don't think you have any right to speak for all > of us, and, I, for one complete disagree with much of what > you have said. I think your tone is unnecessarily > antagonistic, much as I think this is true of Dean and Randy as well. > > How about the three of you go find a room or a ring somewhere > and duke it out while the rest of us actually continue trying > to find a workable solution in an amicable and respectful manner? > > > On Oct 15, 2007, at 12:43 PM, Ted Mittelstaedt wrote: > > > > > Well, Randy and Dean, I'm going to address both of you > since you seem > > to be on the same side here. > > > > See here. The non-legacy community doesen't have infinite > patience in > > dealing with you. The legacy RSA that is coming up for > discussion is > > the paying communities attempt to accomodate your desires. > You don't > > like it, well frankly not all of us like it either. You > can choose to > > participate in the discussion to try to make the legacy RSA > proposal > > more to your liking or not. > [snip...] > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > From cliffb at cjbsys.bdb.com Mon Oct 15 17:00:30 2007 From: cliffb at cjbsys.bdb.com (Cliff Bedore) Date: Mon, 15 Oct 2007 17:00:30 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <1386FE31-4B95-4D1F-9FD4-8404541B5CE3@delong.com> from "Owen DeLong" at Oct 15, 2007 01:35:38 PM Message-ID: <200710152100.l9FL0UC0001661@cjbsys.bdb.com> Owen Thanks for a rational response. I just walked away from the computer after reading Ted's rant. Suffice it to say that I was going to go off big time but decided to count to a lot higher than 10 before responding. I was not going to be nearly as polite but since you managed a very gracious tone, I'll refrain from offering a somewhat blunter opinion. (at least for now) Cliff > > Did I miss an election where Ted was appointed spokesperson for the > entire > non-legacy community? > > Ted, I really don't think you have any right to speak for all of us, > and, I, for > one complete disagree with much of what you have said. I think your > tone > is unnecessarily antagonistic, much as I think this is true of Dean and > Randy as well. > > How about the three of you go find a room or a ring somewhere and duke > it out while the rest of us actually continue trying to find a > workable solution > in an amicable and respectful manner? > > > On Oct 15, 2007, at 12:43 PM, Ted Mittelstaedt wrote: > > > > > Well, Randy and Dean, I'm going to address both of you since you seem > > to be on the same side here. > > > > See here. The non-legacy community doesen't have infinite patience > > in dealing with you. The legacy RSA that is coming up for > > discussion is > > the paying communities attempt to accomodate your desires. You don't > > like it, well frankly not all of us like it either. You can choose to > > participate in the discussion to try to make the legacy RSA proposal > > more to your liking or not. > [snip...] > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > -- Cliff Bedore 7403 Radcliffe Dr. College Park MD 20740 cliffb at cjbsys.bdb.com http://www.bdb.com Amateur Radio Call Sign W3CB For info on ham radio, http://www.arrl.org/ From david at omd3.com Mon Oct 15 17:17:53 2007 From: david at omd3.com (David S. Madole) Date: Mon, 15 Oct 2007 17:17:53 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <47120E7A.4000601@psg.com> Message-ID: <2640.66.212.193.19.1192483073.squirrel@ssl.omd3.com> > From "Ted Mittelstaedt" : > > See here. The non-legacy community doesen't have infinite patience > in dealing with you. The legacy RSA that is coming up for discussion is > the paying communities attempt to accomodate your desires. You don't > like it, well frankly not all of us like it either. You can choose to > participate in the discussion to try to make the legacy RSA proposal > more to your liking or not. > > This legacy RSA proposal is going to be the last offer your going to > get. Once it's complete - in whatever form it ends up in - your going > to see a number of legacy holders > sign it. If you don't, fine - but the community isn't going to have > the patience to come out with yet one more, different version of a legacy > RSA that is more to your liking - not only is there no patience for > it, but the existing legacy holders that end up signing this, who > do decide to participate, are going to feel cheated if the community > continues catering to you. We - the paying community - aren't going to > screw over the legacy holders that DO decide to come in and play with > the rest of us and sign this RSA. So, there won't be another legacy > RSA offered to you again. Thanks, Ted, for this enlighting and authoritative information as to the workings of ARIN. But I am left with some confusion about your role in this decision making process or as spokesperson. I've looked at the: Board of Trustees: http://www.arin.net/about_us/bot.html Advisory Council: http://www.arin.net/about_us/ac.html NRO Number Council: http://www.arin.net/about_us/nronc.html and I can't find your name. Can you explain your role in the process and the decision that a different RSA will never be offered to legacy holders? In fact, in the whole of the arin.net website I can't find your name except in the archives of the PPML mailing list. I am sure I am just overlooking an important committee listing somewhere though. I am also trying to figure out how the "paying community" has a more significant a role in this than anyone else. In my readings of ARIN policies and information I only really find reference to a "community" in general, which appears to mean basically anyone who has an interest in the work of ARIN, whether they pay them anything or not. Perhaps by "paying community" you mean "members", in which case it appears that your input is through electing the Board of Trustees and Advisory Council: http://www.arin.net/membership/index.html I have been under the impression through statements of some of the current members of the Board of Trustees that input from all of the community is considered in making decisions, not just that from members or the "paying community". Again, the error is probably on my side and I am just misinterpreting things. David Madole From bmanning at vacation.karoshi.com Mon Oct 15 17:22:10 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 15 Oct 2007 21:22:10 +0000 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <20071015191938.GA7319@vacation.karoshi.com.> Message-ID: <20071015212210.GA8517@vacation.karoshi.com.> I understand. Note also that the prepending of as##### is a specific "enhancement" done in the Ripe Region and is not universally adopted. if you try "whois -h whois.arin.net 27322" you will get an answer. --bill On Mon, Oct 15, 2007 at 05:15:52PM -0400, Dean Anderson wrote: > The client was jwhois 3.2.1. Just tried v3.2.3, which also had the same > problem. > > The bsd whois clients that come with *bsd and solaris require the -h > instead of @. The jwhois client that comes on, eg fedora, > uses the @host syntax. But I tried just now on an opensolaris (nv56) > box, and it got results for 'whois -h whois.arin.net as1280', but not > for 'whois -h whois.arin.net as27322'. And 'whois -h whois.arin.net > 27322' does work. I'm thinking it might be a server problem for a > record that represents a block of AS numbers. Both clients seem to work > correctly when the record represents a single AS number. > > Thanks! > > --Dean > > > > On Mon, 15 Oct 2007 bmanning at vacation.karoshi.com wrote: > > > which client are you using? > > mine has no support for using the @ in queries and the options/query order > > is important. the one you used might have similar constraints. > > > > e.g. > > > > $ whois 4555 @whois.arin.net > > > > Whois Server Version 2.0 > > > > Domain names in the .com and .net domains can now be registered > > with many different competing registrars. Go to http://www.internic.net > > for detailed information. > > > > 4555.NET > > 4555.COM > > > > No match for "@WHOIS.ARIN.NET". > > >>> Last update of whois database: Mon, 15 Oct 2007 19:13:33 UTC <<< > > > > vs... > > > > $ whois -h whois.arin.net 4555 > > > > OrgName: Exchange Point Blocks > > OrgID: EPB > > Address: PO 12317 > > City: Marina del Rey > > StateProv: CA > > PostalCode: > > Country: US > > > > ASNumber: 4555 > > ASName: EP0-BLK-ASNBLOCK-5 > > ASHandle: AS4555 > > Comment: > > RegDate: > > Updated: 1998-02-02 > > > > RTechHandle: WM110-ARIN > > RTechName: Manning, Bill > > RTechPhone: +1-310-322-8102 > > RTechEmail: bmanning at karoshi.com > > > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > > > > ======================================================================== > > > > On Mon, Oct 15, 2007 at 02:44:02PM -0400, Dean Anderson wrote: > > > Must be a problem with whois. For these 3 records, > > > > > > whois as27322 @whois.arin.net > > > > > > doesn't work. > > > > > > whois 27322 @whois.arin.net works. > > > > > > --Dean > > > > > > [Querying whois.arin.net] > > > [whois.arin.net] > > > > > > No match found for AS27322. > > > > > > # ARIN WHOIS database, last updated 2007-10-13 19:10 > > > # Enter ? for additional hints on searching ARIN's WHOIS database. > > > [dean at citation2 PaulVixie]$ whois as27322 @whois.arin.net > > > [Querying whois.arin.net] > > > [whois.arin.net] > > > > > > No match found for as27322. > > > > > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > > > # Enter ? for additional hints on searching ARIN's WHOIS database. > > > > > > > > > On Mon, 15 Oct 2007, Leo Bicknell wrote: > > > > > > > In a message written on Sun, Oct 14, 2007 at 05:32:14PM -0400, Dean Anderson wrote: > > > > > BTW, can you explain why there are no ARIN records for AS27322, AS30130, > > > > > or AS30131? These are in ARIN AS Blocks. RADB has records that point to > > > > > ISC, and ISC Address blocks originate from these AS numbers. [More > > > > > unusual record-keeping problems for ARIN BoT Members related to RADB, > > > > > too. tsk.tsk.] > > > > > > > > $ whois -h whois.arin.net 27322 > > > > > > > > OrgName: Internet Systems Consortium, Inc. > > > > OrgID: ISC-94 > > > > Address: 950 Charter Street > > > > City: Redwood City > > > > StateProv: CA > > > > PostalCode: 94063 > > > > Country: US > > > > > > > > ASNumber: 27318 - 27322 > > > > ASName: ISC-F-AS > > > > ASHandle: AS27318 > > > > Comment: > > > > RegDate: 2003-02-12 > > > > Updated: 2004-10-05 > > > > > > > > OrgAbuseHandle: ISCAT-ARIN > > > > OrgAbuseName: Internet Systems Consortium Abuse Team > > > > OrgAbusePhone: +1-650-423-1300 > > > > OrgAbuseEmail: abuse at isc.org > > > > > > > > OrgNOCHandle: ISCN-ARIN > > > > OrgNOCName: Internet Systems Consortium NOC > > > > OrgNOCPhone: +1-650-423-1310 > > > > OrgNOCEmail: noc at isc.org > > > > > > > > OrgTechHandle: JDA87-ARIN > > > > OrgTechName: Damas, Joao > > > > OrgTechPhone: +1-650-423-1312 > > > > OrgTechEmail: Joao_Damas at isc.org > > > > > > > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > > > > # Enter ? for additional hints on searching ARIN's WHOIS database. > > > > $ whois -h whois.arin.net 30130 > > > > > > > > OrgName: Internet Systems Consortium, Inc. > > > > OrgID: ISC-94 > > > > Address: 950 Charter Street > > > > City: Redwood City > > > > StateProv: CA > > > > PostalCode: 94063 > > > > Country: US > > > > > > > > ASNumber: 30122 - 30134 > > > > ASName: ISC-F-AS > > > > ASHandle: AS30122 > > > > Comment: For details of F root nameserver operations, see > > > > Comment: http://f.root-servers.org/ > > > > RegDate: 2003-07-28 > > > > Updated: 2004-10-05 > > > > > > > > OrgAbuseHandle: ISCAT-ARIN > > > > OrgAbuseName: Internet Systems Consortium Abuse Team > > > > OrgAbusePhone: +1-650-423-1300 > > > > OrgAbuseEmail: abuse at isc.org > > > > > > > > OrgNOCHandle: ISCN-ARIN > > > > OrgNOCName: Internet Systems Consortium NOC > > > > OrgNOCPhone: +1-650-423-1310 > > > > OrgNOCEmail: noc at isc.org > > > > > > > > OrgTechHandle: JDA87-ARIN > > > > OrgTechName: Damas, Joao > > > > OrgTechPhone: +1-650-423-1312 > > > > OrgTechEmail: Joao_Damas at isc.org > > > > > > > > # ARIN WHOIS database, last updated 2007-10-14 19:10 > > > > # Enter ? for additional hints on searching ARIN's WHOIS database. > > > > $ whois -h whois.arin.net 30131 > > > > > > > > OrgName: Internet Systems Consortium, Inc. > > > > OrgID: ISC-94 > > > > Address: 950 Charter Street > > > > City: Redwood City > > > > StateProv: CA > > > > PostalCode: 94063 > > > > Country: US > > > > > > > > ASNumber: 30122 - 30134 > > > > ASName: ISC-F-AS > > > > ASHandle: AS30122 > > > > Comment: For details of F root nameserver operations, see > > > > Comment: http://f.root-servers.org/ > > > > RegDate: 2003-07-28 > > > > Updated: 2004-10-05 > > > > > > > > OrgAbuseHandle: ISCAT-ARIN > > > > OrgAbuseName: Internet Systems Consortium Abuse Team > > > > OrgAbusePhone: +1-650-423-1300 > > > > OrgAbuseEmail: abuse at isc.org > > > > > > > > OrgNOCHandle: ISCN-ARIN > > > > OrgNOCName: Internet Systems Consortium NOC > > > > OrgNOCPhone: +1-650-423-1310 > > > > OrgNOCEmail: noc at isc.org > > > > > > > > OrgTechHandle: JDA87-ARIN > > > > OrgTechName: Damas, Joao > > > > OrgTechPhone: +1-650-423-1312 > > > > OrgTechEmail: Joao_Damas at isc.org > > > > > > > > > > > > > > -- > > > Av8 Internet Prepared to pay a premium for better service? > > > www.av8.net faster, more reliable, better service > > > 617 344 9000 > > > > > > > > > > > > _______________________________________________ > > > PPML > > > You are receiving this message because you are subscribed to the ARIN Public Policy > > > Mailing List (PPML at arin.net). > > > Unsubscribe or manage your mailing list subscription at: > > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > > > Help Desk at info at arin.net if you experience any issues. > > > > > > -- > Av8 Internet Prepared to pay a premium for better service? > www.av8.net faster, more reliable, better service > 617 344 9000 > From arin-contact at dirtside.com Mon Oct 15 17:24:14 2007 From: arin-contact at dirtside.com (William Herrin) Date: Mon, 15 Oct 2007 17:24:14 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <47120E7A.4000601@psg.com> Message-ID: <3c3e3fca0710151424h70023cd5kc5833469cc7fca4@mail.gmail.com> On 10/15/07, Ted Mittelstaedt wrote: > See here. The non-legacy community doesen't have infinite patience > in dealing with you. Ted, Like many if not most of the registrants, I have the privilege or representing both legacy and non-legacy interests. I can confidently say that if we have anything to say about the matter, ARIN will exercise as much patience as is needed to get the job done. I can say with similar confidence that as we are also non-legacy registrants, we have quite a bit to say about the matter. On 10/15/07, Davey, George wrote: > I agree, I find it a bit dishonest that the CEO of ARIN sent it out and says > to check it out it does not reduce rights when in fact it does just that. > Are they trying to pull something fishy or did he just not read it? George, No fishiness; just a lot of competing interests. Its a good step in the right direction, but its not the last step. There are several ways of adjusting this draft to get it to serve all of us. Now that we have the draft as a base for discussion, we can start to think about which wa we want to jump. 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 Mon Oct 15 17:27:58 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Oct 2007 14:27:58 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <1386FE31-4B95-4D1F-9FD4-8404541B5CE3@delong.com> Message-ID: >-----Original Message----- >From: Owen DeLong [mailto:owen at delong.com] >Sent: Monday, October 15, 2007 1:36 PM >To: Ted Mittelstaedt >Cc: Randy Bush; John Curran; dean at av8.com; Public Policy Mailing List >Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > >Did I miss an election where Ted was appointed spokesperson for the >entire >non-legacy community? > >Ted, I really don't think you have any right to speak for all of us, I'm not taking it upon myself to act as spokesperson. Sorry you cannot argue against what I'm saying using that cheap excuse. I am telling those folks what is going to happen. They know I'm right and I think you know I'm right as well. To put it another way that may be more understandable as to where I'm coming from: certain things are happening right now with regards to the legacy holders. Certain things are going to happen in the future. The results of that are going to make some choices disappear. These are political issues, not technical issues. Sure, from a technical standpoint, anything is possible. Technically, legacy holders could indeed be offered a succession of RSA's, one after another, until all of them sign. But, politically it won't happen. Trust me on this. It won't. Any more than the Republicans in the current US election are going to field a credible candidate. It isn't possible from a political standpoint. The fundamental point I made was that the legacy holders are being asked by the rest of the community to participate, sign an RSA, come in from out of the cold. The community is, right now, bending over backwards to accomodate them, and asking them to work and participate with the community to make the coming-in-from-the-cold transition as easy as possible. For a legacy holder to turn it's back on the current effort is politically unwise. It is, in fact, political suicide. Because what will happen is that as I mentioned, once the current outreach effort is concluded and a large number of legacy holders have in fact, come in out of the cold, have signed a "legacy RSA" why then what will happen is that the remaining ones who have refused to come in now, will be out in the cold, and will have no sympathy from anyone. They won't have sympathy from the non-legacy community because we have already extended the olive branch and had it refused. And they will have even less sympathy from the Legacy holders who have taken that olive branch, signed a Legacy RSA, and will be telling the rest of us "The legacy RSA was good enough for me to sign, it's good enough for those bozos to sign" I'm sorry you didn't like how I phrased this the first time around. Maybe you will like it more this time around. I'm honestly not telling anyone anything they don't already know in the back of their mind. And I'm not telling anyone who studies politics anything that they haven't already seen before. >and, I, for >one complete disagree with much of what you have said. I personally don't agree 100% with it either. For example I think it would be very bad for ARIN to have to vacate the US to remove itself from US court jurisdiction. But, if the remaining Legacy holders who want to litigate and refuse to work out an acceptable RSA now, follow through with litigation, and by some miracle manage to find some backwards court in the US to rule in their favor, why then you and I know that ARIN isn't going to have any choice but to leave the US. The rest of the world won't stand for the US trying to litigate IP address assignments, you know that. >I think your >tone >is unnecessarily antagonistic, much as I think this is true of Dean and >Randy as well. > Well, that's your opinion. I thought my tone wasn't antagonistic enough. Dean and Randy and others like them aren't going to understand that they cannot go against the rest of the world and win, until they try it and suffer contusions. But, some of the folks that they are leading around by the nose may come to their senses after reading my statement and decide it is in their best interest to work with the system rather than fighting it. For any Legacy holder that has sense, they will understand that right now they have the greatest amount of influence with ARIN and with setting policy. In my opinion the non-Legacy community is so desperate to get the Legacy holders under an RSA that they will give away the farm, the Legacy holders can practically write their own RSA right now. If they have sense, they will get with ARIN and do so. But if they don't, they will foolishly wait and then end up losing whatever influence they could have gotten freely given, and will have to fight tooth and nail later on. This is a fact. It is not a technical fact, but it is politically, a fact. And, I apologize to any and everyone that is uncomfortable with it, but I am merely relating what has happened thousands of times before in these kinds of scenarios. Ted From tedm at ipinc.net Mon Oct 15 17:44:34 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Oct 2007 14:44:34 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <2640.66.212.193.19.1192483073.squirrel@ssl.omd3.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David S. Madole >Sent: Monday, October 15, 2007 2:18 PM >To: ppml at arin.net >Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > >Can you explain >the decision that a different RSA will never be offered to legacy holders? I explained this already and I don't understand why people have such a difficult time with this concept but here goes. There's currently one RSA covering new or additonal requests. The Legacy holders (probably rightly) felt that it was not to their advantage to sign that. They made that known. The non-Legacy holders had sympathy and a lot (probably most, we shall see) are somewhat supportive of a grandfathering approach. ARIN embodied this with an outreach for a "special" RSA for legacy holders. ARIN will not label this RSA as complete until they have it in a form that a number of legacy holders like, and are willing to sign. (otherwise, there would be no point to releasing it) Once the "special" RSA is done, and signed by many legacy holders, the legacy holders that didn't sign it will now be facing 2 groups. The first group will be the non-Legacy holders who had sympathy to putting out a special RSA. This group will be having a hard time understanding why the Legacy holders who didn't sign the legacy RSA are still arguing over it - after having given them a chance to help edit it. The second group will be the Legacy holders who have signed the special RSA. This group will be having a hard time understanding why the Legacy holders who are still arguing are considering themselves better than they are. Face with this, I highly doubt that the Legacy holders still arguing will be able to engender any sympathy from either group. I think you would be extremely hard pressed to find a scenario in human history where a group that didn't even try participating in a peacemaking session that many of their peers did participate in, had any credibility left when the session was over and accomodations were worked out. Ted From tedm at ipinc.net Mon Oct 15 17:50:26 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Oct 2007 14:50:26 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <3c3e3fca0710151424h70023cd5kc5833469cc7fca4@mail.gmail.com> Message-ID: >-----Original Message----- >From: wherrin at gmail.com [mailto:wherrin at gmail.com]On Behalf Of William >Herrin >Sent: Monday, October 15, 2007 2:24 PM >To: Ted Mittelstaedt >Cc: Public Policy Mailing List >Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > >On 10/15/07, Ted Mittelstaedt wrote: >> See here. The non-legacy community doesen't have infinite patience >> in dealing with you. > >Ted, > >Like many if not most of the registrants, I have the privilege or >representing both legacy and non-legacy interests. I can confidently >say that if we have anything to say about the matter, ARIN will >exercise as much patience as is needed to get the job done. > Define "getting the job done" will the job be done when 80% of the legacy holders have signed a Legacy RSA? 90%? 100%? What if it's 100% and 5% of them absolutely refuse to sign no matter what ARIN does? How long are we going to have ARIN waste resources on outreach to a group that simply does not want to participate? There's some folks out there who do not want to participate, they want to litigate. You cannot keep them from doing that, no matter how kind you want ARIN to be when approaching them. Ted From david at omd3.com Mon Oct 15 17:51:24 2007 From: david at omd3.com (David S. Madole) Date: Mon, 15 Oct 2007 17:51:24 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <2640.66.212.193.19.1192483073.squirrel@ssl.omd3.com> Message-ID: <2889.66.212.193.19.1192485084.squirrel@ssl.omd3.com> > From Ted Mittelstaedt [tedm at ipinc.net] > >>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>David S. Madole >>Sent: Monday, October 15, 2007 2:18 PM >>To: ppml at arin.net >>Subject: Re: [ppml] Posting of Legacy RSA and FAQ >> >> >>Can you explain >>the decision that a different RSA will never be offered to legacy >> holders? Umm, real nice job with the creative quoting of my message but that wasn't at all the question I asked. I asked: > Can you explain your role in the process and > the decision that a different RSA will never be offered to legacy > holders? Those six words you edited out change the meaning quite a bit. It's a usual goal in (honest) editing and quoting not to change the meaning of things. I am hoping that the answer to my original question is not that your role in the ARIN process is editing the policies. David Madole From tedm at ipinc.net Mon Oct 15 18:07:34 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Oct 2007 15:07:34 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <2889.66.212.193.19.1192485084.squirrel@ssl.omd3.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David S. Madole >Sent: Monday, October 15, 2007 2:51 PM >To: ppml at arin.net >Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > >> From Ted Mittelstaedt [tedm at ipinc.net] >> >>>From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>>David S. Madole >>>Sent: Monday, October 15, 2007 2:18 PM >>>To: ppml at arin.net >>>Subject: Re: [ppml] Posting of Legacy RSA and FAQ >>> >>> >>>Can you explain >>>the decision that a different RSA will never be offered to legacy >>> holders? > >Umm, real nice job with the creative quoting of my message but that wasn't >at all the question I asked. I asked: > >> Can you explain your role in the process and >> the decision that a different RSA will never be offered to legacy >> holders? > >Those six words you edited out change the meaning quite a bit. It's a >usual goal in (honest) editing and quoting not to change the meaning of >things. > No, sorry they don't change the meaning. Your talking like ARIN is an entity separate from the community. It isn't. ARIN will do what the community wants. Right now the community has decided it wants to pursue outreach to the Legacy holders. Some Legacy holders (understandably) don't want ARIN to outreach to them. Once outreach is concluded, the community -and by extension, ARIN - will be through with this issue and as I said, simply will not be interested in further chasing after people who don't want to have anything to do with them. That is why a second Legacy RSA won't be offered. OK, I have answered your questions several times, now answer one of mine. Why do YOU want multiple RSA's offered to Legacy holders? What do YOU get out of it, why do YOU want this to happen? Do you think it would be a good thing to have 4, 5, 6, 10, 15, 150, 500 different RSA's out there, each tailored to some complainer? Ted From dean at av8.com Mon Oct 15 18:26:25 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 15 Oct 2007 18:26:25 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: Message-ID: On Mon, 15 Oct 2007, Ted Mittelstaedt wrote: > Well, Randy and Dean, I'm going to address both of you since you seem > to be on the same side here. > > See here. The non-legacy community doesen't have infinite patience > in dealing with you. The legacy RSA that is coming up for discussion is > the paying communities attempt to accomodate your desires. You don't > like it, well frankly not all of us like it either. You can choose to > participate in the discussion to try to make the legacy RSA proposal > more to your liking or not. The legacy community doesn't have infinite patience in dealing with the ungrateful non-legacy community that doesn't have respect for the obligations it undertook to obtain the privilege of operating a registry service. This is why we legacies need to work together to fight ARIN in Court if necessary, and form a separate Legacy Registry. This is in both our interests, it turns out. A number of legacies have already contacted me offlist. But we need to get the word out to other legacies. Unfairly, ARIN has this list of legacies, but hasn't shared it. ARIN hasn't even acknowledged that there are other points of view in its FAQ. ARIN hasn't given any notice to legacies that they may have any other options at all. ARIN continues to create fear and has failed to repudiate reports from individuals that serve to induce fear. ARIN has accomplished inducement through action and inaction with the sole purpose of obtaining, unlawfully, the property and contract rights of legacy IP Address Registration holders. Letter to Demand Documents ARIN has also not yet provided the documents and correspondence relevant to its formation that establish the agreements and the terms it understood and undertook. I am preparing a written letter to demand this information. If you want to sign the letter, please contact me offlist. Both legacies and non-legacies have an interest in these documents and both may want to sign the letter. Mutual Interest in Legacy Registry Through some offlist discussion, it was pointed out that IPv4 registration services will eventually transition to a 'low volume of changes' mode, suitable for nearly automated operation. Legacies already have a 'low volume of changes' mode, and so the ultimate goals of ARIN and the Legacies in further automating registry operations is consistent and beneficial. By the time non-legacies get to a low volume of change mode, a Legacy Registry will have a great deal of operational experience on the subject. So, assuming your intention is not merely to steal Legacy space from Legacies, and that you just want to rid yourself of the burden (small though it is) of maintaining legacy registrations, you should have no objection to establishing a Legacy Registry. You should look forward to our results and, once again, benefiting from our experience. There is one thing that has been nagging me just a little. Ted said the other day that BSD code was imported into the GPL. There are a few points about that claim: 1). With few, if any exceptions, the GPL unix-replacement programs are complete rewrites and are not copies of BSD code. The rewrites are often better than the originals. It was necessary to undertake rewrites because at the time these efforts began, BSD unix was not freely available. It was encumbered by the ATT copyright. You needed to purchase a Unix source license from ATT before you could get the BSD code. This was one of the reasons for the formation of the OSF by major computer vendors. 2). The problem with the free BSD copyright is that it doesn't prevent anyone from taking it private, or subjecting it to new terms. All that one has to do is acknowlege Berkeley as the author. Without getting into a this/that copyright discussion, this is basically the reason that FSF created the GPL. The point here is this: It would have been perfectly legal for FSF to take the BSD code with the appropriate notice, had the code been free. But this didn't happen because BSD wasn't free at the time. 3). The reason that you have free BSD copyright programs for *bsd unix-like operating system is because the OSF funded the completion of the free BSD 4.4 release. If OSF hadn't funded that, the Berkeley CSRG would have shut down several years before 4.4 could be completed, leaving only the tiny BSD net2 release. BSD 4.3 _still_ requires a source license, from SCO or Novell or both. [I forget who owns Unix Source code these days. The Open Group (formerly OSF) owns the Unix trademark and does the certification.] 4). It so happens, ironically, that I am the contact for the OSF legacy space. So, we see now that Ted and others are quite happy to reap the benefit of millions spent by OSF so they can run *BSD for free, but they begrudge the legacy registration services. I can tell you that OSF supported CSRG because it was realized that it was the right thing to do, and someone had to step up and complete this valuable research project. Perhaps if Ted can change the agreements that led to free legacy IP Address registrations, we can change the agreements that led to free BSD software. Maybe we can charge Ted and others $100,000 for source licenses. Wouldn't that be great? I don't think so. I think we should stick by the past agreements. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From dean at av8.com Mon Oct 15 18:26:25 2007 From: dean at av8.com (Dean Anderson) Date: Mon, 15 Oct 2007 18:26:25 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: Message-ID: On Mon, 15 Oct 2007, Ted Mittelstaedt wrote: > Well, Randy and Dean, I'm going to address both of you since you seem > to be on the same side here. > > See here. The non-legacy community doesen't have infinite patience > in dealing with you. The legacy RSA that is coming up for discussion is > the paying communities attempt to accomodate your desires. You don't > like it, well frankly not all of us like it either. You can choose to > participate in the discussion to try to make the legacy RSA proposal > more to your liking or not. The legacy community doesn't have infinite patience in dealing with the ungrateful non-legacy community that doesn't have respect for the obligations it undertook to obtain the privilege of operating a registry service. This is why we legacies need to work together to fight ARIN in Court if necessary, and form a separate Legacy Registry. This is in both our interests, it turns out. A number of legacies have already contacted me offlist. But we need to get the word out to other legacies. Unfairly, ARIN has this list of legacies, but hasn't shared it. ARIN hasn't even acknowledged that there are other points of view in its FAQ. ARIN hasn't given any notice to legacies that they may have any other options at all. ARIN continues to create fear and has failed to repudiate reports from individuals that serve to induce fear. ARIN has accomplished inducement through action and inaction with the sole purpose of obtaining, unlawfully, the property and contract rights of legacy IP Address Registration holders. Letter to Demand Documents ARIN has also not yet provided the documents and correspondence relevant to its formation that establish the agreements and the terms it understood and undertook. I am preparing a written letter to demand this information. If you want to sign the letter, please contact me offlist. Both legacies and non-legacies have an interest in these documents and both may want to sign the letter. Mutual Interest in Legacy Registry Through some offlist discussion, it was pointed out that IPv4 registration services will eventually transition to a 'low volume of changes' mode, suitable for nearly automated operation. Legacies already have a 'low volume of changes' mode, and so the ultimate goals of ARIN and the Legacies in further automating registry operations is consistent and beneficial. By the time non-legacies get to a low volume of change mode, a Legacy Registry will have a great deal of operational experience on the subject. So, assuming your intention is not merely to steal Legacy space from Legacies, and that you just want to rid yourself of the burden (small though it is) of maintaining legacy registrations, you should have no objection to establishing a Legacy Registry. You should look forward to our results and, once again, benefiting from our experience. There is one thing that has been nagging me just a little. Ted said the other day that BSD code was imported into the GPL. There are a few points about that claim: 1). With few, if any exceptions, the GPL unix-replacement programs are complete rewrites and are not copies of BSD code. The rewrites are often better than the originals. It was necessary to undertake rewrites because at the time these efforts began, BSD unix was not freely available. It was encumbered by the ATT copyright. You needed to purchase a Unix source license from ATT before you could get the BSD code. This was one of the reasons for the formation of the OSF by major computer vendors. 2). The problem with the free BSD copyright is that it doesn't prevent anyone from taking it private, or subjecting it to new terms. All that one has to do is acknowlege Berkeley as the author. Without getting into a this/that copyright discussion, this is basically the reason that FSF created the GPL. The point here is this: It would have been perfectly legal for FSF to take the BSD code with the appropriate notice, had the code been free. But this didn't happen because BSD wasn't free at the time. 3). The reason that you have free BSD copyright programs for *bsd unix-like operating system is because the OSF funded the completion of the free BSD 4.4 release. If OSF hadn't funded that, the Berkeley CSRG would have shut down several years before 4.4 could be completed, leaving only the tiny BSD net2 release. BSD 4.3 _still_ requires a source license, from SCO or Novell or both. [I forget who owns Unix Source code these days. The Open Group (formerly OSF) owns the Unix trademark and does the certification.] 4). It so happens, ironically, that I am the contact for the OSF legacy space. So, we see now that Ted and others are quite happy to reap the benefit of millions spent by OSF so they can run *BSD for free, but they begrudge the legacy registration services. I can tell you that OSF supported CSRG because it was realized that it was the right thing to do, and someone had to step up and complete this valuable research project. Perhaps if Ted can change the agreements that led to free legacy IP Address registrations, we can change the agreements that led to free BSD software. Maybe we can charge Ted and others $100,000 for source licenses. Wouldn't that be great? I don't think so. I think we should stick by the past agreements. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From david at omd3.com Mon Oct 15 18:28:51 2007 From: david at omd3.com (David S. Madole) Date: Mon, 15 Oct 2007 18:28:51 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <2889.66.212.193.19.1192485084.squirrel@ssl.omd3.com> Message-ID: <3071.66.212.193.19.1192487331.squirrel@ssl.omd3.com> > From Ted Mittelstaedt [tedm at ipinc.net] > >>Those six words you edited out change the meaning quite a bit. It's a >>usual goal in (honest) editing and quoting not to change the meaning of >>things. >> > > No, sorry they don't change the meaning. Then why did you feel the need to remove them? > Your talking like ARIN is an entity separate from the community. It > isn't. > ARIN will do what the community wants. ARIN is in fact a separate entity from the community. ARIN is a corporation that was formed through a defined legal process and has contractual rights and obligations. It is a legal entity. It has a mechanism to define a single organizational position on any issue. The community is just a group of people interested in IP address policy. There is no organization except perhaps between members of ARIN and non-members (both of which are still the community). The community has no way to draw a consensus among itself and agree to a single position on any issue. Therefore, it is silly to say that ARIN will do what the community wants, since it's impossible to define exactly what the community wants. That's like saying the Congress of the United States will do what the citizens want. Go around and ask a bunch of citizens whether they think Congress is "doing what they want". ARIN may solicit input from the community and they may base their actions on that input, but I would not generalize that to say that "ARIN will do what the community wants". It's not that simple. Among other reasons, ARIN has obligations that the community does not have. > Why do YOU want multiple RSA's offered to Legacy holders? What do YOU > get out of it, why do YOU want this to happen? Do you think it would be a > good thing to have 4, 5, 6, 10, 15, 150, 500 different RSA's out there, > each tailored to some complainer? I never suggested I wanted multiple RSA's. Just because I may not like the one that has been put forth doesn't mean that I want multiple ones, it may just mean I want one different one. Maybe I missed something, I have not been on this list that long, but I never saw a draft of this RSA before it was released, so all I can do is comment on it now. I admit that may be my own fault. By the way, did you ever notice what the very first words of the RSA document say? "Legacy RSA Version 1.0" What's the point of that if it's a foregone conclusion that there will never be another one? Someone needs to clue in the person that composed this that the version number is an unnecessary consideration. David From Daniel_Alexander at Cable.Comcast.com Mon Oct 15 18:40:09 2007 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Mon, 15 Oct 2007 18:40:09 -0400 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <2640.66.212.193.19.1192483073.squirrel@ssl.omd3.com> Message-ID: <997BC128AE961E4A8B880CD7442D948001FAD9C8@NJCHLEXCMB01.cable.comcast.com> Ted, I understand the scenario you are pointing out. What I'm curious about is your assertion that all the Legacy holders will have the opportunity to provide input to this modified RSA. Also about the assertion that if a number of them do sign, the remaining ones are all of the opinion they are turning their back on the RIR system. My concern is that many of the conversations on the list have tried to simplify the topics down to an "us and them". It is not that simple, and we need to avoid this tendency. There have been a number of Legacy holders post to this list that are more than willing to try, and find a middle ground that is a win-win for everyone, and this is just the first step. It may not have been the intent, but I read your note as "you better get on board, before the opportunity passes you by", which is not the best approach. Who are the admins for all legacy allocations? Are they authorized to sign an RSA for said company? Has ARIN made the appropriate effort to track down or verify the legacy allocation, before they are labelled as advesarial? What is "the appropriate effort"? There is much work that needs to be done before anyone is given a label, or a final option. Dan Alexander ARIN AC -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Monday, October 15, 2007 5:45 PM To: David S. Madole; ppml at arin.net Subject: Re: [ppml] Posting of Legacy RSA and FAQ >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >David S. Madole >Sent: Monday, October 15, 2007 2:18 PM >To: ppml at arin.net >Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > >Can you explain >the decision that a different RSA will never be offered to legacy holders? I explained this already and I don't understand why people have such a difficult time with this concept but here goes. There's currently one RSA covering new or additonal requests. The Legacy holders (probably rightly) felt that it was not to their advantage to sign that. They made that known. The non-Legacy holders had sympathy and a lot (probably most, we shall see) are somewhat supportive of a grandfathering approach. ARIN embodied this with an outreach for a "special" RSA for legacy holders. ARIN will not label this RSA as complete until they have it in a form that a number of legacy holders like, and are willing to sign. (otherwise, there would be no point to releasing it) Once the "special" RSA is done, and signed by many legacy holders, the legacy holders that didn't sign it will now be facing 2 groups. The first group will be the non-Legacy holders who had sympathy to putting out a special RSA. This group will be having a hard time understanding why the Legacy holders who didn't sign the legacy RSA are still arguing over it - after having given them a chance to help edit it. The second group will be the Legacy holders who have signed the special RSA. This group will be having a hard time understanding why the Legacy holders who are still arguing are considering themselves better than they are. Face with this, I highly doubt that the Legacy holders still arguing will be able to engender any sympathy from either group. I think you would be extremely hard pressed to find a scenario in human history where a group that didn't even try participating in a peacemaking session that many of their peers did participate in, had any credibility left when the session was over and accomodations were worked out. Ted _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From mksmith at adhost.com Mon Oct 15 18:43:12 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Mon, 15 Oct 2007 15:43:12 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: Message-ID: <17838240D9A5544AAA5FF95F8D5203160297F528@ad-exh01.adhost.lan> Hello Dean: > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Dean Anderson > Sent: Monday, October 15, 2007 4:26 PM > To: Ted Mittelstaedt > Cc: Randy Bush; Public Policy Mailing List > Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > On Mon, 15 Oct 2007, Ted Mittelstaedt wrote: > > Well, Randy and Dean, I'm going to address both of you since you seem > > to be on the same side here. > > > > See here. The non-legacy community doesen't have infinite patience > > in dealing with you. The legacy RSA that is coming up for discussion > is > > the paying communities attempt to accomodate your desires. You don't > > like it, well frankly not all of us like it either. You can choose > to > > participate in the discussion to try to make the legacy RSA proposal > > more to your liking or not. > > The legacy community doesn't have infinite patience in dealing with the > ungrateful non-legacy community that doesn't have respect for the > obligations it undertook to obtain the privilege of operating a > registry > service. > > This is why we legacies need to work together to fight ARIN in Court if > necessary, and form a separate Legacy Registry. This is in both our > interests, it turns out. A number of legacies have already contacted > me > offlist. But we need to get the word out to other legacies. Unfairly, > ARIN has this list of legacies, but hasn't shared it. ARIN hasn't even > acknowledged that there are other points of view in its FAQ. ARIN > hasn't > given any notice to legacies that they may have any other options at > all. ARIN continues to create fear and has failed to repudiate reports > from individuals that serve to induce fear. ARIN has accomplished > inducement through action and inaction with the sole purpose of > obtaining, unlawfully, the property and contract rights of legacy IP > Address Registration holders. > > > Letter to Demand Documents > > ARIN has also not yet provided the documents and correspondence > relevant > to its formation that establish the agreements and the terms it > understood and undertook. I am preparing a written letter to demand > this information. If you want to sign the letter, please contact me > offlist. Both legacies and non-legacies have an interest in these > documents and both may want to sign the letter. > > > Mutual Interest in Legacy Registry > > Through some offlist discussion, it was pointed out that IPv4 > registration services will eventually transition to a 'low volume of > changes' mode, suitable for nearly automated operation. Legacies > already have a 'low volume of changes' mode, and so the ultimate goals > of ARIN and the Legacies in further automating registry operations is > consistent and beneficial. By the time non-legacies get to a low > volume > of change mode, a Legacy Registry will have a great deal of operational > experience on the subject. > > So, assuming your intention is not merely to steal Legacy space from > Legacies, and that you just want to rid yourself of the burden (small > though it is) of maintaining legacy registrations, you should have no > objection to establishing a Legacy Registry. You should look forward to > our results and, once again, benefiting from our experience. > > > > > There is one thing that has been nagging me just a little. Ted said the > other day that BSD code was imported into the GPL. There are a few > points about that claim: > > 1). With few, if any exceptions, the GPL unix-replacement programs are > complete rewrites and are not copies of BSD code. The rewrites are > often > better than the originals. It was necessary to undertake rewrites > because at the time these efforts began, BSD unix was not freely > available. It was encumbered by the ATT copyright. You needed to > purchase a Unix source license from ATT before you could get the BSD > code. This was one of the reasons for the formation of the OSF by > major > computer vendors. > > 2). The problem with the free BSD copyright is that it doesn't prevent > anyone from taking it private, or subjecting it to new terms. All that > one has to do is acknowlege Berkeley as the author. Without getting > into > a this/that copyright discussion, this is basically the reason that FSF > created the GPL. The point here is this: It would have been perfectly > legal for FSF to take the BSD code with the appropriate notice, had the > code been free. But this didn't happen because BSD wasn't free at the > time. > > 3). The reason that you have free BSD copyright programs for *bsd > unix-like operating system is because the OSF funded the completion of > the free BSD 4.4 release. If OSF hadn't funded that, the Berkeley CSRG > would have shut down several years before 4.4 could be completed, > leaving only the tiny BSD net2 release. BSD 4.3 _still_ requires a > source license, from SCO or Novell or both. [I forget who owns Unix > Source code these days. The Open Group (formerly OSF) owns the Unix > trademark and does the certification.] > > 4). It so happens, ironically, that I am the contact for the OSF legacy > space. So, we see now that Ted and others are quite happy to reap the > benefit of millions spent by OSF so they can run *BSD for free, but > they > begrudge the legacy registration services. I can tell you that OSF > supported CSRG because it was realized that it was the right thing to > do, and someone had to step up and complete this valuable research > project. > > Perhaps if Ted can change the agreements that led to free legacy IP > Address registrations, we can change the agreements that led to free > BSD > software. Maybe we can charge Ted and others $100,000 for source > licenses. Wouldn't that be great? I don't think so. I think we should > stick by the past agreements. > > > --Dean > The establishment of a Legacy Registry and the BSD copyright are not discussions related to ARIN policy. Please take the discussion of the Legacy Registry to arin-discuss and take the discussion of the BSD copyright "someplace else". Regards, Mike From tedm at ipinc.net Mon Oct 15 20:56:50 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 15 Oct 2007 17:56:50 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <997BC128AE961E4A8B880CD7442D948001FAD9C8@NJCHLEXCMB01.cable.comcast.com> Message-ID: >-----Original Message----- >From: Alexander, Daniel [mailto:Daniel_Alexander at cable.comcast.com] >Sent: Monday, October 15, 2007 3:40 PM >To: Ted Mittelstaedt; David S. Madole; ppml at arin.net >Subject: RE: [ppml] Posting of Legacy RSA and FAQ > > >Ted, > >I understand the scenario you are pointing out. What I'm curious about >is your assertion that all the Legacy holders will have the opportunity >to provide input to this modified RSA. On October 11th when ARIN put out it's Legacy RSA notification, I thought that it sounded arbitrary, that they were making a decision without Legacy or non-Legacy input. But then I read the ENTIRE notice and at the bottom it says: "...This legacy RSA will be described during presentations at the upcoming NANOG meeting, ARIN Public Policy Meeting, and ARIN Members meeting..." and the obvious point is that IF there would be NO input, then there would have been no point in "describing it during presentations" at the ARIN members meeting. This is a meeting that ARIN has already posted instructions on how to remotely access - ie: it's a public meeting. Clearly what is going on is a dog-and-pony show. ARIN is trotting out this legacy RSA document, version 1.0 if you will. The community will have an opportunity for review and comment during the meetings. ARIN very likely thinks it has anticipated all of the concerns that would be raised by Legacy and non-Legacy holders, and that is why they are not releasing a copy early - they want to make sure that they release the copy in a forum where they can answer a dozen or so RTFM-style questions, and everyone will get the benefit of the answers. If this question and answer period turns up concerns that need to be addressed - or the subsequent discussion that will undoubtedly occur here (and on NANOG's list) turns up concerns, then obviously no Legacy holder will sign until those are fixed - and ARIN certainly knows this, and will make changes. So we will see a revision 1.01, 1.02, 1.1 and so on. Then ARIN will trot around - non-publically of course - and try getting Legacy signatures, and that may prompt even more revisions. Eventually ARIN will get a document that enough Legacy holders are willing to sign that they will feel comfortable publishing it as a permanent "Legacy RSA" document on the ARIN website. It is THAT final document that I am saying is the "last chance" the Legacy holders have. I do NOT believe there will be any will to produce another that is significantly different from the first. If there was such a will then no Legacy would sign the first one - since they would be waiting for the next, and the next and so on, forever and ever. But, I DO think that during this time period after introduction that the Legacy holders - espically the ones with very large holdings which are the primary purpose we are wasting time on this in the first place - will have PLENTY of input. If, they haven't already, secretly, HAD input. Now I may be wrong and Dean may be right and ARIN may be composed of a bunch of intractable fools who are willing to cut off their nose to spite their face and be unwilling to listen to any Legacy holder concerns or make any changes - in which case this whole initative will go nowhere and 6 months from now we will all still be arguing over this. But fortunately, as I'm not employed by ARIN I am free to speculate and guess that ARIN has already been in talks with some Legacy holders already - something that no employee of ARIN could possibly confirm or deny - and that ARIN will be in further talks with Legacy holders under NDA in the future. And fortunately since I'm not a /8 Legacy holder, ARIN will not be making me sign an NDA so I am free to sit back and observe and comment on the political workings of large organizations. ;-) > Also about the assertion that if >a number of them do sign, the remaining ones are all of the opinion they >are turning their back on the RIR system. > Well, that kind of follows I think. I don't necessairly think this has the negative connotations though that some folks are attributing. Look at it another way. I own a car. I carry liability insurance only on it. I have "turned my back" on the Insurance company's system - which is everyone carries comprehensive, if they get in an accident they claim against their own policy, and the insurance companies just argue with each other. Thus, when I am rear-ended (which by the way has happened) then I am the one filing the claim against the other carrier, and fighting with the other carrier when they almost automatically attempt to deny or reduce the claim (which by the way has happened, and yes I won and got the money I wanted, yadda yadda yadda) In short, I am taking the responsibility for what happens when I "turn my back" on the Insurance companies nice little system for handling claims between themselves. I am going into this with my eyes open. If Dean as a legacy holder wants to turn his back on ARIN that's fine with me. I presume he is fully aware of the consequences and lack of protection of NOT signing an RSA. The problem is that I'm not running around telling people to save money on their car insurance by carrying liability only and it is always going to be to their advantage. I'm not the Legacy holder running around telling other Legacy holders to turn their back on ARIN and not sign an RSA because it's always going to be to their advantage. Not like Dean and Randy. Do you get my drift, here? I read a lot from Dean and a few others about these so-called "rights" of the Legacy holders that are so all-fired important. But not once have I seen a word from him, particularly, about responsibility. >My concern is that many of the conversations on the list have tried to >simplify the topics down to an "us and them". It is not that simple, and >we need to avoid this tendency. There have been a number of Legacy >holders post to this list that are more than willing to try, and find a >middle ground that is a win-win for everyone, and this is just the first >step. It may not have been the intent, but I read your note as "you >better get on board, before the opportunity passes you by", which is not >the best approach. > Maybe not - but look here, what does it do to ARIN and the non-Legacy holders credibility to tell the Legacy holders lies? If this Legacy RSA is merely the first in a long series of version 1.X, 2.X 3.X and so on "Legacy RSA" that are going to come down the pike, then to be honest we should tell the Legacy holders this now, up front. "Wait for the best one" we should be saying. "You don't have to sign now if you don't like it, there will be a different one tomorrow" we should be saying. What does it do to our credibility to IMPLY that this is the final solution, then turn around and screw any Legacy holders that sign it next year with another Legacy RSA that has better terms? Do you see where this is going? The sentence from ARIN was: "...This legacy RSA also contractually promises ARIN Internet number resource policies adopted after the contract is signed will not lessen the legacy RSA address holder's contract rights... But, it DOES NOT say that it promises to NOT INCREASE the legacy RSA holders rights. In other words, it promises them that ARIN won't offer another policy change later that will roll back whatever rights they get from the Legacy RSA - but it leaves it open to release another RSA that -increases- rights for yet more Legacy holders? And the first Legacy holders that sign are going to be happy about that happening? You see, already ARIN's credibility is being risked by such sloppy language. Either the non-Legacy community makes a decision to create a fair "Legacy RSA" and offer it now, in good faith, or we don't do it AT ALL. To offer one now, ASSUMING that we are going to change it in the future - that will shoot ARIN's credibility into the toilet. ARIN will get a first batch of Legacy holders signed up - then the second ARIN tries offering another Legacy RSA that has substantively different terms, then ALL the Legacy holders that have not yet signed will just say screw ARIN, let's litigate. >Who are the admins for all legacy allocations? Are they authorized to >sign an RSA for said company? Has ARIN made the appropriate effort to >track down or verify the legacy allocation, before they are labelled as >advesarial? What is "the appropriate effort"? There is much work that >needs to be done before anyone is given a label, or a final option. > You are right - there are a lot of details to work out. That is even more the reason that for this to work ARIN is going to have to revise it after Legacy and non-Legacy input - and even more reason that once the revisions are completed and people have all had their say, that is MUST be etched in stone. The Legacy holders right NOW all feel that their assignments are etched in stone. ARIN CANNOT offer them something that is etched in quicksand and reasonably expect any of them to buy off on it. Ted From michael.dillon at bt.com Mon Oct 15 23:48:12 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 16 Oct 2007 04:48:12 +0100 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: <1386FE31-4B95-4D1F-9FD4-8404541B5CE3@delong.com> Message-ID: > These are political issues, not technical issues. Sure, from > a technical standpoint, anything is possible. Technically, > legacy holders could indeed be offered a succession of RSA's, > one after another, until all of them sign. > But, politically it won't happen. Trust me on this. It > won't. I am with Ted on this one. In politics, timing is everything, and if this legacy RSA fails, then the exhaustion of IPv4 addresses is so close that it doesn't really matter anymore. Just about everyone is now working on their IPv6 transition strategies, and the energy will all go into getting that right, because those companies who do get it right, will have smooth sailing a couple of years from now. > For a legacy holder to turn it's back on the current effort > is politically unwise. It is, in fact, political suicide. Yes. I can't see why anyone would put any more effort into bringing legacy IPv4 holders on board if they get slapped in the face over the current proposal. > Well, that's your opinion. I thought my tone wasn't > antagonistic enough. > Dean and Randy and others like them aren't going to > understand that they cannot go against the rest of the world > and win, until they try it and suffer contusions. But, some > of the folks that they are leading around by the nose may > come to their senses after reading my statement and decide it > is in their best interest to work with the system rather than > fighting it. >From a political point of view it might be advantageous to have Randy and Dean opposing your position. What many engineers fail to understand is that politics does not demand perfection. If anything, politics prefers imperfect solutions because they tend to be optimal. Engineers often think that an optimal solution means that it is best according to some engineering criteria. In fact, the engineering approach should be to understand the problem as one of bringing a system into a state of equilibrium which can be maintained with low energy. If there are several local minima that are close to optimal, then a random choice is usually made. The "energy" being measured here in the system is the "heat" of opposition. An optimal political solution is the one which most people hate the least. There may be a few people which hate it a lot, but that gets averaged out by the other members of the policymaking community. Therefore an excellent political solution that is BEST FOR THE OVERALL COMMUNITY is still likely to have one or two vehement opponents. > And, I apologize to any and everyone > that is uncomfortable with it, but I am merely relating what > has happened thousands of times before in these kinds of scenarios. Unfortunately, a lot of the players in the ARIN community come from a technical background and are used to finding the kinds of consensus solutions that are usually possible in the technical arena. They often forget that the second P in PPML stands for "policy" and that means that ARIN policymaking is a political forum, not a technical engineering forum. And in any case, it will all be moot about three years from now when growth shifts to the IPv6 Internet. Let us not forget that. --Michael Dillon From michael.dillon at bt.com Tue Oct 16 00:02:05 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 16 Oct 2007 05:02:05 +0100 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: References: Message-ID: > ARIN has also not yet provided the documents and > correspondence relevant to its formation that establish the > agreements and the terms it understood and undertook. ARIN has always published its charter and by-laws. As I understand it, this is the sum total of the obligations and undertakings that a new corporation has under U.S. law. Remember that ARIN was not created by legislation and was not created by any sort of regulatory agency. I know that a lot of people had a lot of discussions around the time of ARIN's formation. Some of those discussions happened at NANOG, some at the DOC, some even at the Whitehouse, believe it or not. I personally solicited some U.S.-based ISPs to send letters of support for ARIN's formation to the part of the Whitehouse that Ira Magaziner was associated with. But in the end, unless ARIN's officers signed some sort of contract, any agreements that anybody thought were made, are now just dust. A lot of possible scenarios were discussed and some people may have misunderstood what was a commitment and what was merely analysis or blue-sky thinking. What is the point of rehashing this now? ARIN has squarely made its mark as a bottom-up decision-making organization in which stakeholders in IP address allocation meet to make their own rules and regulations. No government help is needed, nor is any government interference desired. > Through some offlist discussion, it was pointed out that IPv4 > registration services will eventually transition to a 'low > volume of changes' mode, suitable for nearly automated > operation. I don't recall anyone mentioning suitability for automated operation. Getting one complex application per month would be low-volume but would be entirely unsuitable for automation. In any case, the key thing here is that this change would be caused by a nearly 100% transition to IPv6. Legacy ISPs will never, ever have any experience useful to ARIN since "legacy" by definition, is purely IPv4-based. By the time ARIN is mostly dealing with IPv6 activity, IPv4 ISPs will be relegated to a market share similar to that now enjoyed by the BBS business. --Michael Dillon From Keith at jcc.com Tue Oct 16 07:43:22 2007 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 16 Oct 2007 07:43:22 -0400 Subject: [ppml] Comments on Legacy Registration Service Agreement Message-ID: Here are my comments on the Legacy RSA Version 1.0 Section 3 "EVALUATION AND ACCEPTANCE" "ARIN will promptly evaluate..." RSA: Version 9.1 does not contain the word "promptly". Does this suggest that the standard applications are not evaluated promptly? Section 4 "CONDITIONS OF SERVICE", paragraph (d) "Prohibited Conduct." This section seems pretty wide reaching, but the paragraph in the Legacy RSA is identical to the paragraph in the standard RSA. Since it is not clear to me (at least) what "applicable laws, statutes or regulations" are, I will be careful not to violate any zoning ordinances. Section 6 "FEES; PAYMENTS", paragraph (b) "Annual Maintenance Fees..." Compare the following sentence: ARIN has the right to: (i) revoke the included number resources if unpaid after 12 months of the due date, and/or ARIN is unable to contact the Applicant after 12 months, or (ii) terminate this Legacy Agreement and stop providing the services. to the last sentences in Section 4 "CONDITIONS OF SERVICE", paragraph (c) "Cooperation": If Legacy Applicant does not provide ARIN with required information, assistance, or cooperation that ARIN requests, ARIN may: (i) take such failure into account in determining Legacy Applicant's future allocation/assignment of additional number resources, and/or (ii) terminate this Legacy Agreement. I prefer the wording in the "Cooperation" paragraph. However, the legacy resource holders that sign this agreement are most likely to be the ones who want additional resources and services, I don't see a lot of risk to a legacy resource holder (to me at least) in "Annual Maintenance Fees" wording. Section 8 "REVIEW OF LEGACY APPLICANT'S NUMBER RESOURCES" First sentence "ARIN may, no more other than annually..." seems to have an extra "other". This sentence would read better if it said: ARIN may, no more than annually... Section 9 "NO PROPERTY RIGHTS" says: Legacy Applicant acknowledges and agrees that the number resources are not property... This section has generated some amount of heated discussion. Since I have a legacy /24, I'm unlikely to be able to subdivide it and sell off parts (at least not routable parts), so I can live with this. INDEMNIFICATION -- I noticed that the Legacy RSA does not include the INDEMNIFICATION section that is in the standard RSA. Since the INDEMNIFICATION section in the regular RSA looks pretty one-sided, not having it is a good thing. Section 14 TERM AND TERMINATION, paragraph (e) "Effect of Termination" says: (e) Effect of Termination. If this Legacy Agreement expires or is terminated: (i) ARIN will immediately revoke the number resources and otherwise cease providing the Services and will have no liability for doing so, and (ii) Legacy Applicant must immediately pay ARIN any outstanding fees that Legacy Applicant owes. Since the Legacy RSA is an agreement for services for number resources, not an agreement to allocate those number resources, termination of the agreement should only result in termination of the services. With a couple of tweaks, I'd be willing to sign this Legacy RSA. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From Keith at jcc.com Tue Oct 16 07:53:53 2007 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 16 Oct 2007 07:53:53 -0400 Subject: [ppml] One additional comment on Legacy RSA V1.0 Message-ID: In the Legacy RSA Version 1.0: Section 15, "GENERAL PROVISIONS", following paragraph (l) "Governing Law..." there is a paragraph: (b) If the Legacy Applicant is part of a national, state, or local... It is not clear where this paragraph really should be. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From kkargel at polartel.com Tue Oct 16 09:35:52 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 16 Oct 2007 08:35:52 -0500 Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <73394C3E0701EB4F8AAD37FCFF1BDF4C01235A95@email> References: <1386FE31-4B95-4D1F-9FD4-8404541B5CE3@delong.com> <70DE64CEFD6E9A4EB7FAF3A06314106670765B@mail> <73394C3E0701EB4F8AAD37FCFF1BDF4C01235A95@email> Message-ID: <70DE64CEFD6E9A4EB7FAF3A063141066707666@mail> I don't believe I ever said they couldn't be a member of more than one registrar. What I did say is that any netblock should not be advertised from more than one registrar. That would create synchronization and authority problems in any database. I think everyone welcomes any IP address holder to ARIN. Kevin > -----Original Message----- > From: Davey, George [mailto:George.Davey at dmu.edu] > Sent: Monday, October 15, 2007 4:07 PM > To: Kevin Kargel > Subject: RE: [ppml] Posting of Legacy RSA and FAQ > > I agree with the first half of your argument and well put by the way. > The end of your argument fades into darconinism. > One thing is why would you say you respect the pioneer but if > he is a member of another new registry he cannot be a member of ARIN. > Why not? The legacy allocation is the only thing that > requires or compels that person to put those IP space under > the new organization because they fit better there than at ARIN. > New allocations, however, would best fit at ARIN including IPV6. > > Many large companies hold IP space from ARIN and RIPE (global > companies) so how do you feel about them? > Should they be forced to pick only 1 registrar? > > > > > > > > > > < Des Moines University - Osteopathic Medical Center > > > George Davey, B.S., M.C.S.E. > Network Administrator > 3200 Grand Avenue > Des Moines, IA 50312 > 515.271.1544 > FAX 515.271.7063 > george.davey at dmu.edu > www.dmu.edu > > > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Kevin Kargel > Sent: Monday, October 15, 2007 3:52 PM > To: Owen DeLong > Cc: ppml at arin.net > Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > For a more non-violent solution maybe they could just line up > at the railing and see just who really can pee farthest.. :) > > I hope though that everyone isn't going into a > put-up-your-dukes mine-is-bigger-than-yours mode here. > Cooperative anarchy is what has kept the "Internet" working > so far, and it will be what keeps it working for some time in > the future. If we lose the cooperative part of that then the > whole thing goes to you-know-where in a handbasket. Put this > in the hands of courts and governments and when taxation is > implemented to pay for administration none of us will be able > to afford connectivity. > > The active community paying to support ARIN is certainly > doing their part to keep things going and working smoothly. > I think everyone is doing a pretty good job of it. We cannot > forget that the Legacy holders were the pioneers that got > this whole ball rolling, and bad things come of dismissing > your ancestors. I am sure there is a solution that protects > both the legacy holders and the active ARIN community, > without serving one at the others expense. If we keep > working to that end we will work something out. > > I suppose one of the things the Legacy holders could do if > they were unwilling to compromise or join the fold would be > to institute their own registry (Legacy Registration > Authority - LSA?), and see if they offered enough value to > the "community" that it would accept routing advertisements > from that registry. This is assuming theLegacy Holders could > come to a consensus amongst themselves. If they did that > ARIN could just stop advertising legacy blocks, let the > legacy organizations shepherd their own space and sidestep > the whole political tar baby. > > Speaking for myself, I would continue to support the ARIN > community and accept advertisements from ARIN, and accept > only those unique advertisements from the Legacy registry > where my customers demanded it. > I would not accept any advertisements from the legacy > registry where they also existed at ARIN. > > I can't see this working, and I don't advocate it by any > means, but it may be a less evil alternative to surrendering > to government control. > If the Legacy holders think ARIN is inflexible and > dictatorial, I would hate to hear what they thought of a > myriad of governmental regulatory agencies. > > Just my two cents worth.. I don't claim it is worth more than that. > > Kevin > > > -----Original Message----- > > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] > On Behalf > > Of Owen DeLong > > Sent: Monday, October 15, 2007 3:36 PM > > To: Ted Mittelstaedt > > Cc: Randy Bush; Public Policy Mailing List > > Subject: Re: [ppml] Posting of Legacy RSA and FAQ > > > > Did I miss an election where Ted was appointed spokesperson for the > > entire non-legacy community? > > > > Ted, I really don't think you have any right to speak for > all of us, > > and, I, for one complete disagree with much of what you > have said. I > > think your tone is unnecessarily antagonistic, much as I > think this is > > true of Dean and Randy as well. > > > > How about the three of you go find a room or a ring > somewhere and duke > > it out while the rest of us actually continue trying to find a > > workable solution in an amicable and respectful manner? > > > > > > On Oct 15, 2007, at 12:43 PM, Ted Mittelstaedt wrote: > > > > > > > > Well, Randy and Dean, I'm going to address both of you > > since you seem > > > to be on the same side here. > > > > > > See here. The non-legacy community doesen't have infinite > > patience in > > > dealing with you. The legacy RSA that is coming up for > > discussion is > > > the paying communities attempt to accomodate your desires. > > You don't > > > like it, well frankly not all of us like it either. You > > can choose to > > > participate in the discussion to try to make the legacy RSA > > proposal > > > more to your liking or not. > > [snip...] > > > > Owen > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed > to the ARIN > > Public Policy Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > > Member Services Help Desk at 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3107 bytes Desc: not available URL: From andrew.dul at quark.net Tue Oct 16 10:47:15 2007 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Tue, 16 Oct 2007 06:47:15 -0800 Subject: [ppml] Posting of Legacy RSA and FAQ Message-ID: <20071016144716.16504.qmail@hoster908.com> I have attached a diff of the current RSA 9.1 and the proposed Legacy RSA. I took the current RSA (as the base document) and proposed Legacy RSA extracted the text from the PDFs and then I used a document delta viewer that I have access to create the attached PDF. Your results may vary, but I thought this might help people see the differences between the two documents. Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: ARIN RSA 9.1 diff ARIN Legacy RSA 1.0.pdf Type: application/octet-stream Size: 197373 bytes Desc: not available URL: From dean at av8.com Tue Oct 16 14:03:07 2007 From: dean at av8.com (Dean Anderson) Date: Tue, 16 Oct 2007 14:03:07 -0400 (EDT) Subject: [ppml] Posting of Legacy RSA and FAQ In-Reply-To: <17838240D9A5544AAA5FF95F8D5203160297F528@ad-exh01.adhost.lan> Message-ID: On Mon, 15 Oct 2007, Michael K. Smith - Adhost wrote: > The establishment of a Legacy Registry and the BSD copyright are not > discussions related to ARIN policy. Please take the discussion of the > Legacy Registry to arin-discuss and take the discussion of the BSD > copyright "someplace else". Really, so you and Ted have taken over, now? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From rgaglian at antel.net.uy Tue Oct 16 14:05:22 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Tue, 16 Oct 2007 16:05:22 -0200 Subject: [ppml] Global Policy Update v2. In-Reply-To: <1191867266.10506.24.camel@localhost> References: <1191863529.17471.122.camel@jessy.antel.net.uy> <1191867266.10506.24.camel@localhost> Message-ID: <082A533D-1B8B-4D3F-9822-6A2A6ADEB131@antel.net.uy> I wanted to let you people know a change on the proposal that I will be presenting at tomorrow's meeting. After we held discussions on all the five RIRs we decided that we needed to re-visit the size of the last allocation from IANA to the RIRs. We are now proposing setting the last allocation size on two (2) /8s. That means change N to N=2 in our policy text. The rationale behind this text is: - N=2 is the current "gentlemen" agreement for allocations between RIRs, so setting N=2 can be considered as a "allocation". - no important address piling in any RIR so, discourage for RIR shopping. - no significant push forward for the last allocation date (probably 4 to 6 months) from IANA to RIRs. - enough address space to adopt conservative policies at RIR that decides to do so. - We believe it addresses the legal concerns from the ARIN counsel. Regards, Roque ------------------------------------------------------------- Roque Gagliano ANTEL - URUGUAY rgaglian at antel.net.uy -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Oct 16 11:46:58 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 16 Oct 2007 08:46:58 -0700 Subject: [ppml] Policy Proposal 2007-13 - Staff Assessment In-Reply-To: <47129AB9.9090001@arin.net> References: <47129AB9.9090001@arin.net> Message-ID: > A. ARIN Staff > > If the immediate need clause is removed from this policy, then the > immediate need policy (Number Resource Policy Manual section 4.2.1.6) > needs to be amended to provide for end users. Otherwise, ARIN may not > be able to meet the needs of end users who have no current address > space > in use. > Removal of this section should not prevent ARIN from handling such requests under the multihoming policy or other existing end-user policies. As such, I do not believe the immediate need clause conflict is necessary or particularly useful in an end-user context. Owen From owen at delong.com Tue Oct 16 14:30:30 2007 From: owen at delong.com (Owen DeLong) Date: Tue, 16 Oct 2007 11:30:30 -0700 Subject: [ppml] Policy Proposal 2007-17 - Staff Assessment In-Reply-To: <47129B4B.8090504@arin.net> References: <47129B4B.8090504@arin.net> Message-ID: <8CD735F9-45F2-4358-A870-C9CF8053F68D@delong.com> This appears to be an evaluation of the original 2007-17 proposal without regard to the updated version which was submitted. The revised proposal addresses most of the concerns expressed by staff and counsel. Below is the message I sent on September 15 which contains the revised policy: > Specific ideas incorporated into this proposal: > 1. Specific fee statements removed. Fees are not the realm > of IRPEP, so, it is replaced with a requirement for the BoT > to develop appropriate incentives. > > 2. An oversight in the original version did not provide a > timeframe in which addresses were to be returned. > This version adopts a 12 month timeframe with staff > discretion for up to 2 extensions of 6 months each. > > 3. This proposal differs from the existing section 4.6 in > that it places discretion over whether a subnet of > a returned block may be retained or not in the hands > of the address holder. There was some suggestion > from some AC members that this discretion should > only be given to legacy holders while ARIN staff should > retain discretion over non-legacy resources. I do not > have a strong opposition to such a change, but, I do > feel that the policy is actually better as is, so, I have > chosen not to add this revision. I would like to see > discussion on this area, and, if it is possible, I would > like this version to allow the AC discretion to gauge > consensus on whether this edit should be added > prior to last call. > > > Revised proposal is as follows: > > > Policy Proposal 2007-17 > Legacy Outreach and Partial Reclamation > > Author: Owen DeLong > > Proposal Version: 1.0 > Submission Date: 2007 September 15 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Modify section 4.6 as follows: > > 4.6 Amnesty Requests: > > ARIN will accept the return or relinquishment of > any address space from any existing address holder. If the address > holder wishes to aggregate into a single block, ARIN may work with the > address holder to arrive at an allocation or assignment which is equal > to or smaller than the sum of their existing blocks and which best > meets > the needs of the existing holder and the community. The organization > returning the addresses shall have 12 months from the date they > receive > their new addresses to return the addresses under this policy. > Organizations > may request no more than 2 six month extensions to this time, which, > may be granted at ARIN the discretion of ARIN staff. There shall be no > fee for returning addresses under this policy. Further, organizations > returning addresses under this policy shall receive the following > benefits: > > 1. If the organization does not currently pay ARIN fees, they shall > remain fee exempt. > > 2. The BoT shall develop an incentive program to encourage such > returns. Such incentives may include fee reductions and/or other > such mechanisms as the BoT deems appropriate. > > 3. Any organization returning address space under this policy shall > continue under their existing RSA or they may choose to sign the > current > RSA. For organizations which currently do not have an RSA, they may > sign > the current RSA, or, they may choose to remain without an RSA. > > 4. All organizations returning space under this policy shall, if they > meet other eligibility requirements and so request, obtain an > appropriate IPv6 end-user assignment or ISP allocation as applicable, > with no fees for the first 5 years. Organizations electing to receive > IPv6 allocation/assignment under this provision must sign a current > RSA > and must agree that all of their IPv4 and ASN resources are > henceforth subject > to the RSA. Organizations taking this election shall be subject to > end-user fees for their IPv4 resources not previously under an ARIN > RSA. > If they are already an ARIN subscriber, then IPv4 resources > affected by > this process may, instead, be added to their existing subscriber > agreement at the address holder's discretion. > > Rationale: > > The current amnesty policy does a nice job of facilitating > aggregation, > which was the intent when it was drafted. However, as we approach IPv4 > free-space exhaustion, the community now has an additional need to > facilitate address reclamation. > > A very high percentage of underutilized space is in the hands of > legacy > holders who currently have no benefit to joining the ARIN process. > Further, there is an unfortunate perception that doing so will require > force the legacy holder into certain future disadvantages. This > proposal > attempts to resolve both of those issues while also providing some > incentive to legacy organizations to start using IPv6 resources and > bring their IPv4 resources into the ARIN process. > > This policy attempts to provide some benefit and remove most of the > costs of making partial IPv4 returns. It also attempts to provide an > incentive for these IPv4 holders to join the ARIN process. > > It is suggested that the BoT adopt fee incentives such as the > elimination of 2 years of ARIN fees for each /20 returned. > > > Timetable for implementation: Immediate > > Sorry for any confusion. Owen From leo.vegoda at icann.org Tue Oct 16 17:34:40 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 16 Oct 2007 23:34:40 +0200 Subject: [ppml] Policy Proposal 2007-19 - Staff Assessment In-Reply-To: <47129B91.4050608@arin.net> References: <47129B91.4050608@arin.net> Message-ID: On 15 Oct 2007, at 00:43, Member Services wrote: [...] > III. Comments > > A. ARIN Staff > > 1. The ?Additional Allocations? section indicates an RIR can > receive an additional ASN allocation when the RIR ?has > assigned/allocated 80% of the previously received ASN block?. > > After 12/31/2009, there will be no distinction made between 2 > byte > AS numbers and 4 byte AS numbers per policy. Does ?previously > received > ASN block? literally mean the most recent ASN block (even if it was > a 2 > byte only block), or does it mean 80% of both the most recent 4 byte > block and the most recent 2 byte block? If it?s the latter, one ASN > block would never be audited, since it would never be ?the most recent > ASN block allocated?. I think that people would reasonably expect IANA to review both the most recent 16-bit and 32-bit ASN allocations when evaluating a request for an additional block after 2009. Regards, Leo Vegoda From joe at via.net Tue Oct 16 18:05:17 2007 From: joe at via.net (joe mcguckin) Date: Tue, 16 Oct 2007 15:05:17 -0700 Subject: [ppml] Posting of Legacy RSA and FAQ Message-ID: <37C72389-E246-41F6-BDB2-A0FFA30B957B@via.net> Ted's message reminds me of the old joke: Democracy is two wolves and a sheep deciding what's for dinner. Joe Joe McGuckin ViaNet Communications joe at via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Tue Oct 16 19:36:56 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 16 Oct 2007 17:36:56 -0600 Subject: [ppml] Lame delegation consultation Message-ID: I'd like to mention that there is a consultation related to the lame delegation thread(s) that were on PPML a while back. The thread begins here: http://lists.arin.net/pipermail/consult/2007-October/000052.html The closing date for comments is October 23 - early next week. I don't mean to being the discussion here, I just wanted to "promote it." Info on the consultation mailing list is here: http://lists.arin.net/mailman/listinfo/consult -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From drc at virtualized.org Tue Oct 16 22:36:07 2007 From: drc at virtualized.org (David Conrad) Date: Tue, 16 Oct 2007 20:36:07 -0600 Subject: [ppml] Policy Proposal 2007-16 - Staff Assessment In-Reply-To: <47129B2A.2050507@arin.net> References: <47129B2A.2050507@arin.net> Message-ID: <612D0D76-BD75-490C-9E13-A9523575E020@virtualized.org> Hi, Responding to staff assessment comments: On Oct 14, 2007, at 4:41 PM, Member Services wrote: > 1. The policy seems to apply only to the general IPv4 ISP policy. > Does > this policy also apply to the other ISP additional policies like > multiple discreet networks (NRPM 4.5) and cable (NRPM 4.2.6)? The goal of the policy is to promote increased efficiency and encourage transition any time any ISP requests additional address space. For simplicity, fairness, and consistency's sake, I believe it inappropriate to create loopholes based on a particular access technology or how an organization decides to partition their network. As such, the utilization requirements in section 4.2.6 (second bullet) and section 4.5.5 should be modified to correspond with the utilization based on thresholds as defined in the proposal. > 2. Does this policy supersede the ISP additional request policy > and any > other ISP additional request policies? If so, this should be > clearly stated. Yes. > 3. In the policy statement, the author discusses utilization rates > and > refers to swip and rwhois. These terms should be removed because they > are not necessarily relevant to all customers (those that assign > smaller > than /28s or orgs that manage dynamic address pools, Voip, etc?). I referenced SWIP and rwhois because the NPRM as it exists references SWIP and rwhois. I'm happy to remove those references. > 4. In the policy statement, the author refers to specific fields > in the > template. This should be removed since template fields will change > over > time. OK. > 5. A general question of fairness comes up when you consider that > ISP?s > will now be faced with much more difficulty in obtaining IP address > space from ARIN while end users will feel no effect or change at all. As mentioned in previous discussions on this proposal, due to limited time I focused on the consumers of the vast majority of address space. If the community feels it appropriate, I am happy to create a separate proposal that focuses on end users. > 6. Author indicated placement in the NRPM. All the text from "begin > modification" to "end modification" would be placed in Section > 4.2.4.1. > Subsections would be created. The title of the section would be > changed > to "Utilization Requirements". We would strike the "80%" reference in > 4.2.3.4.1. OK. Regards, -drc From Keith at jcc.com Tue Oct 16 23:31:43 2007 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 16 Oct 2007 23:31:43 -0400 Subject: [ppml] Support for Policy Proposal 2007-21 Message-ID: I support Policy Proposal 2007-21. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From rgaglian at antel.net.uy Wed Oct 17 02:09:01 2007 From: rgaglian at antel.net.uy (Roque Gagliano) Date: Wed, 17 Oct 2007 04:09:01 -0200 Subject: [ppml] Policy Proposal 2007-18 - Staff Assessment In-Reply-To: <47129B68.3070009@arin.net> References: <47129B68.3070009@arin.net> Message-ID: <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> > > 1. The policy conflicts with the spirit of RFC 2050 in which > fairness and efficiency of allocation by IANA to the RIRs is cited. > RFC 2050 is a BCP for the allocations of IPv4 addresses from the RIRs to the LIR/NIR (please check the abstract, second paragraph), I do not believe it applies to this policy. Even if you disagree with me, the principle that RFC 2050 mentions is CONSERVATION ( section 1.1 ), but the address space is depleting, that is the problem that we are addressing... Roque From info at arin.net Wed Oct 17 09:35:58 2007 From: info at arin.net (Member Services) Date: Wed, 17 Oct 2007 09:35:58 -0400 Subject: [ppml] Policy Proposal 2007-17 - Staff Assessment In-Reply-To: <47129B4B.8090504@arin.net> References: <47129B4B.8090504@arin.net> Message-ID: <47160FBE.4090904@arin.net> ARIN staff spoke with the author of this proposal here at the ARIN XX meeting. As a result of that conversation, we will be posting a revised staff assessment. We will update the staff understanding and remove staff comments 2 and 3 in the revised assessment. Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > Policy Proposal 2007-17 > Legacy Outreach and Partial Reclamation > > ARIN Staff Assessment > > The assessment of this proposal includes comments from ARIN staff and > the ARIN General Counsel. It contains analysis of procedural, legal, and > resource concerns regarding the implementation of this policy proposal > as it is currently stated. Any changes to the language of the proposal > may necessitate further analysis by staff and Counsel. > > I. Proposal > > Policy Proposal is available as Annex A below and at: > http://www.arin.net/policy/proposals/2007_17.html > > II. Understanding of the proposal > > ARIN staff understands that the proposal would modify NRPM Section 4.6. > Ignoring the parts that concern fees and waivers, the proposal would > change the current policy by removing the defined timeframe for > returning address space to ARIN. > > III. Comments > > A. ARIN Staff > > 1. There is currently an aggregation policy in NRPM 4.7. This > proposal seems to be confusing and perhaps contradicting that existing > policy. Does this proposal replace the existing aggregation policy 4.7 > in NRPM? > > 2. The policy seems to suggest some type of fee waiver which does > not belong within policy. See ARIN General Counsel comments below. > > 3. ARIN?s current practice requires a signed Registration Services > Agreement (RSA) from organizations receiving number resources. The > proposed policy should clarify this requirement in section 3. > > B. ARIN General Counsel > > ?I have reviewed this policy and believe it poses no significant risk of > litigation by outside parties. > > However, in my non-legal opinion, acting as counselor to the Board and > AC, the policy does something I have never previously seen and > encroaches on how ARIN has operated by custom. > > To date, the ARIN Board of Trustees has unilaterally debated and set the > rates of payment for any ARIN services. Overall, this policy proposal > substitutes a policy with specific numerical promises. This would > impinge on the Board's ability to holistically adjust such economic > numbers, for example, to create a new incentive by going even further > than the policy, or less than the policy to achieve its aims. The author > and AC might consider substitution of an alternative draft policy that > gives strong directional adjectival guidance to the Board, but does not > contain specific amounts. For example, and I believe consistent with the > proposed policy, the policy adopted can make clear the community is > sending clear guidance that the economic inducements for legacy address > holders to sign a new and publicly available alternative RSA for legacy > holders can be accomplished more deftly by providing an RSA, not a > policy. The discussion approved to accompany the policy can contain > non-binding but specific recommendations for this purpose, which the > Board would probably welcome. An RSA is a contract. ARIN can > unilaterally bind itself in such contracts, promising consistent future > terms, including any promise ARIN chooses to make to not charge for > certain services. But the RSA can also be phased out, not impacting > contracted parties, but not be available for future parties who do not > sign up. Such flexibility in the RSA, with the Board following > aspirational policy is a correct direction for the continued development > of this proposal.? > > Resource Impact ? Minimal > > The resource impact of implementing this policy is viewed as minimum. > Barring any unforeseen resource requirements, this policy could be > implemented within 30 - 90 days from the date of the ratification of the > policy by the ARIN Board of Trustees. It will require the following: > > - Updates to Registration Services Guidelines will be required > - Staff training will be required > - Tracking tools for the return of the space > > Respectfully submitted, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ##*## > > > Annex A > > Policy Proposal 2007-17 > Legacy Outreach and Partial Reclamation > > Author: Owen DeLong > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Modify section 4.6 as follows: > > 4.6 Amnesty Requests: > > ARIN will accept the return or relinquishment of any address space from > any existing address holder. If the address holder wishes to aggregate > into a single block, ARIN may work with the address holder to arrive at > an allocation or assignment which is equal to or smaller than the sum of > their existing blocks and which best meets the needs of the existing > holder and the community. The organization returning the addresses shall > have 12 months from the date they receive their new addresses to return > the addresses under this policy. Organizations may request no more than > 2 six month extensions to this time, which, may be granted at ARIN the > discretion of ARIN staff. There shall be no fee for returning addresses > under this policy. Further, organizations returning addresses under this > policy shall receive the following benefits: > > 1. If the organization does not currently pay ARIN fees, they shall > remain fee exempt. > > 2. The BoT shall develop an incentive program to encourage such returns. > Such incentives may include fee reductions and/or other such > mechanisms as the BoT deems appropriate. > > 3. Any organization returning address space under this policy shall > continue under their existing RSA or they may choose to sign the current > RSA. For organizations which currently do not have an RSA, they may sign > the current RSA, or, they may choose to remain without an RSA. > > 4. All organizations returning space under this policy shall, if they > meet other eligibility requirements and so request, obtain an > appropriate IPv6 end-user assignment or ISP allocation as applicable, > with no fees for the first 5 years. Organizations electing to receive > IPv6 allocation/assignment under this provision must sign a current RSA > and must agree that all of their IPv4 and ASN resources are henceforth > subject to the RSA. Organizations taking this election shall be subject > to end-user fees for their IPv4 resources not previously under an ARIN > RSA. If they are already an ARIN subscriber, then IPv4 resources > affected by this process may, instead, be added to their existing > subscriber agreement at the address holder's discretion. > > Rationale: > > The current amnesty policy does a nice job of facilitating aggregation, > which was the intent when it was drafted. However, as we approach IPv4 > free-space exhaustion, the community now has an additional need to > facilitate address reclamation. > > A very high percentage of underutilized space is in the hands of legacy > holders who currently have no benefit to joining the ARIN process. > Further, there is an unfortunate perception that doing so will require > force the legacy holder into certain future disadvantages. This proposal > attempts to resolve both of those issues while also providing some > incentive to legacy organizations to start using IPv6 resources and > bring their IPv4 resources into the ARIN process. > > This policy attempts to provide some benefit and remove most of the > costs of making partial IPv4 returns. It also attempts to provide an > incentive for these IPv4 holders to join the ARIN process. > > It is suggested that the BoT adopt fee incentives such as the > elimination of 2 years of ARIN fees for each /20 returned. > > Timetable for implementation: Immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Wed Oct 17 09:39:17 2007 From: info at arin.net (Member Services) Date: Wed, 17 Oct 2007 09:39:17 -0400 Subject: [ppml] Policy Proposal 2007-14 - Staff Assessment In-Reply-To: <47129AE2.8080502@arin.net> References: <47129AE2.8080502@arin.net> Message-ID: <47161085.3040301@arin.net> ARIN staff spoke with the author of this proposal here at the ARIN XX meeting. As a result of that conversation, we will be posting a revised staff assessment. We will remove staff comments 2, 4 and 6 in the revised assessment. Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > Policy Proposal 2007-14 > Resource Review Process > > ARIN Staff Assessment > > The assessment of this proposal includes comments from ARIN staff and > the ARIN General Counsel. It contains analysis of procedural, legal, and > resource concerns regarding the implementation of this policy proposal > as it is currently stated. Any changes to the language of the proposal > may necessitate further analysis by staff and Counsel. > > I. Proposal > > Policy Proposal is available as Annex A below and at: > http://www.arin.net/policy/proposals/2007_14.html > > II. Understanding of the proposal > > This policy proposal provides clear policy authority to audit or reclaim > resources, guidelines for how it shall be done, and a guarantee of a > (minimum) six-month grace period so that the current user shall have > time to stop using any resources to be reclaimed. > > > III. Comments > > A. ARIN Staff > > 1) 2c does not reconcile with the RSA, which grants ARIN authority to > request any data necessary and does not specify any sort of limitation > to frequency. > > 2) Point 4 refers to ?ARIN delegation?. Does this include legacy > registrations or is it only ARIN issued resources? > > 3) Point 3 requires ARIN notify an organization each time a review is > conducted. ARIN interprets a review to mean a full audit of an > organization's resources conducted by ARIN staff. > > 4) Points 4 and 5 use the term ?compliance?. ARIN interprets this as > bringing the organization into compliance with current policy. > > 5) Point 4 uses the terms ?single aggregate block?.and ?whole > resources?. Are these terms used synonymously to refer to a single CIDR > prefix, or to ?a contiguous range of addresses?? > > 6) Point 6 sets the minimum hold time at 6 months. Current staff > procedure is a minimum of one year. > > 7) Point 6 compels ARIN to take action which doesn?t reconcile with the > RSA, which (as articulated above) allows ARIN to take whatever action is > necessary. > > 8) Author did not indicate placement in the NRPM. We would insert as > "Section 12 Resource Review Process." > > B. ARIN General Counsel > "Counsel strongly supports some version of this policy being enacted and > believes adoption of this policy will save significant future legal > fees. This policy proposal spells out a series of customary and > contractual policies and rights that are important to make as clear as > possible. > > Counsel does not agree with that portion of the description which states > ARIN "feels that current policy does not give them the power...." And > believes such powers are adequately vested in ARIN' but believes instead > such powers can always be more carefully delineated for ease of > understanding." > > IV. Resource Impact ? Minimal > > The resource impact of implementing this policy is viewed as minimal. > Barring any unforeseen resource requirements, this policy could be > implemented within 30 ? 90 days from the date of the ratification of the > policy by the ARIN Board of Trustees. Depending on the impact to RSD > this may require additional staff. It will require the following: > > Guidelines Changes > Registration System Changes > Staff training > May increase RSD workload > May increase turnaround times > > > Respectfully submitted, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ##*## > > > Annex A > > Policy Proposal 2007-14 > Resource Review Process > > Author: Owen DeLong, Stephen Sprunk > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Add the following to the NRPM: > > Resource Review > > 1. ARIN may review the current usage of any resources issued by ARIN to > an organization. The organization shall furnish whatever records are > necessary to perform this review. > > 2. ARIN may conduct such reviews: > > a. when any new resource is requested, > b. whenever ARIN has cause to believe that the resources had > originally been obtained fraudulently, or > c. at any other time without cause unless a prior review has been > completed in the preceding 12 months. > > 3. ARIN shall communicate the results of the review to the organization. > > 4. If the review shows that existing usage is substantially not in > compliance with current allocation and/or assignment policies, the > organization shall return resources as needed to bring them > substantially into compliance. If possible, only whole resources shall > be returned. Partial address blocks shall be returned in such a way that > the portion retained will comprise a single aggregate block. > > 5. If the organization does not voluntarily return resources as > required, ARIN may revoke any resources issued by ARIN as required to > bring the organization into overall compliance. ARIN shall follow the > same guidelines for revocation that are required for voluntary return in > the previous paragraph. > > 6. Except in cases of fraud, an organization shall be given a minimum of > six months to effect a return. ARIN shall negotiate a longer term with > the organization if ARIN believes the organization is working in good > faith to substantially restore compliance and has a valid need for > additional time to renumber out of the affected blocks. > > 7. Legacy resources in active use, regardless of utilization, are not > subject to revocation by ARIN. However, the utilization of legacy > resources shall be considered during a review to assess overall compliance. > > Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 > > Remove the sentence "In extreme cases, existing allocations may be > affected." from NRPM section 4.2.3.1. > > Rationale: > > ARIN feels that current policy does not give them the power to review or > reclaim resources except in cases of fraud, despite this being mentioned > in the Registration Services Agreement. This policy proposal provides > clear policy authority to do so, guidelines for how and under what > conditions it shall be done, and a guarantee of a (minimum) six-month > grace period so that the current user shall have time to renumber out of > any resources to be reclaimed. > > The nature of the "review" is to be of the same form as is currently > done when an organization requests new resources, i.e. the documentation > required and standards should be the same. > > The renumbering period does not affect any "hold" period that ARIN may > apply after return or revocation of resources is complete. > > The deleted sections/text would be redundant with the adoption of this > proposal. > > Timetable for implementation: Immediate > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From info at arin.net Wed Oct 17 09:44:02 2007 From: info at arin.net (Member Services) Date: Wed, 17 Oct 2007 09:44:02 -0400 Subject: [ppml] Policy Proposal 2007-17 - Staff Assessment Message-ID: <471611A2.8070506@arin.net> Revised Staff Assessment - 17 October 2007 Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_17.html II. Understanding of the proposal ARIN staff understands that the proposal would modify NRPM Section 4.6. Ignoring the parts that concern fees and waivers, the proposal would change the current policy by changing the timeframe for returning address space to ARIN. III. Comments A. ARIN Staff There is currently an aggregation policy in NRPM 4.7. This proposal seems to be confusing and perhaps contradicting that existing policy. Does this proposal replace the existing aggregation policy 4.7 in NRPM? B. ARIN General Counsel ?I have reviewed this policy and believe it poses no significant risk of litigation by outside parties. However, in my non-legal opinion, acting as counselor to the Board and AC, the policy does something I have never previously seen and encroaches on how ARIN has operated by custom. To date, the ARIN Board of Trustees has unilaterally debated and set the rates of payment for any ARIN services. Overall, this policy proposal substitutes a policy with specific numerical promises. This would impinge on the Board's ability to holistically adjust such economic numbers, for example, to create a new incentive by going even further than the policy, or less than the policy to achieve its aims. The author and AC might consider substitution of an alternative draft policy that gives strong directional adjectival guidance to the Board, but does not contain specific amounts. For example, and I believe consistent with the proposed policy, the policy adopted can make clear the community is sending clear guidance that the economic inducements for legacy address holders to sign a new and publicly available alternative RSA for legacy holders can be accomplished more deftly by providing an RSA, not a policy. The discussion approved to accompany the policy can contain non-binding but specific recommendations for this purpose, which the Board would probably welcome. An RSA is a contract. ARIN can unilaterally bind itself in such contracts, promising consistent future terms, including any promise ARIN chooses to make to not charge for certain services. But the RSA can also be phased out, not impacting contracted parties, but not be available for future parties who do not sign up. Such flexibility in the RSA, with the Board following aspirational policy is a correct direction for the continued development of this proposal.? Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimum. Barring any unforeseen resource requirements, this policy could be implemented within 30 - 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. It will require the following: - Updates to Registration Services Guidelines will be required - Staff training will be required - Tracking tools for the return of the space Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests: ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. The organization returning the addresses shall have 12 months from the date they receive their new addresses to return the addresses under this policy. Organizations may request no more than 2 six month extensions to this time, which, may be granted at ARIN the discretion of ARIN staff. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. The BoT shall develop an incentive program to encourage such returns. Such incentives may include fee reductions and/or other such mechanisms as the BoT deems appropriate. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 and ASN resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. It is suggested that the BoT adopt fee incentives such as the elimination of 2 years of ARIN fees for each /20 returned. Timetable for implementation: Immediate From info at arin.net Wed Oct 17 09:46:02 2007 From: info at arin.net (Member Services) Date: Wed, 17 Oct 2007 09:46:02 -0400 Subject: [ppml] Policy Proposal 2007-14 - Staff Assessment Message-ID: <4716121A.30008@arin.net> Revised Staff Assessment - 17 October 2007 Policy Proposal 2007-14 Resource Review Process ARIN Staff Assessment The assessment of this proposal includes comments from ARIN staff and the ARIN General Counsel. It contains analysis of procedural, legal, and resource concerns regarding the implementation of this policy proposal as it is currently stated. Any changes to the language of the proposal may necessitate further analysis by staff and Counsel. I. Proposal Policy Proposal is available as Annex A below and at: http://www.arin.net/policy/proposals/2007_14.html II. Understanding of the proposal This policy proposal provides clear policy authority to audit or reclaim resources, guidelines for how it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to stop using any resources to be reclaimed. III. Comments A. ARIN Staff 1) 2c does not reconcile with the RSA, which grants ARIN authority to request any data necessary and does not specify any sort of limitation to frequency. 2) Point 3 requires ARIN notify an organization each time a review is conducted. ARIN interprets a review to mean a full audit of an organization's resources conducted by ARIN staff. 3) Point 4 uses the terms ?single aggregate block?.and ?whole resources?. Are these terms used synonymously to refer to a single CIDR prefix, or to ?a contiguous range of addresses?? 4) Point 6 compels ARIN to take action which doesn?t reconcile with the RSA, which (as articulated above) allows ARIN to take whatever action is necessary. 5) Author did not indicate placement in the NRPM. We would insert as "Section 12 Resource Review Process." B. ARIN General Counsel "Counsel strongly supports some version of this policy being enacted and believes adoption of this policy will save significant future legal fees. This policy proposal spells out a series of customary and contractual policies and rights that are important to make as clear as possible. Counsel does not agree with that portion of the description which states ARIN "feels that current policy does not give them the power...." And believes such powers are adequately vested in ARIN' but believes instead such powers can always be more carefully delineated for ease of understanding." IV. Resource Impact ? Minimal The resource impact of implementing this policy is viewed as minimal. Barring any unforeseen resource requirements, this policy could be implemented within 30 ? 90 days from the date of the ratification of the policy by the ARIN Board of Trustees. Depending on the impact to RSD this may require additional staff. It will require the following: Guidelines Changes Registration System Changes Staff training May increase RSD workload May increase turnaround times Respectfully submitted, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as needed to bring them substantially into compliance. If possible, only whole resources shall be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From captain at netidea.com Wed Oct 17 14:43:42 2007 From: captain at netidea.com (Kirk Ismay) Date: Wed, 17 Oct 2007 11:43:42 -0700 Subject: [ppml] Statements of support for the proposals In-Reply-To: <3c3e3fca0710150817y3424332dw630c653f19622c4a@mail.gmail.com> References: <3c3e3fca0710150817y3424332dw630c653f19622c4a@mail.gmail.com> Message-ID: <471657DE.8050807@netidea.com> William Herrin wrote: > Hi folks, > > I thought it might be helpful to compile statements of support or > opposition for each of the pending policy proposals in a single > message along with a brief reason why/why not. I encourage others to > do the same. > Here's my $0.02: > 2006-7 Changes to IPv6 initial allocation criteria I support 2006-7. I prefer the wording proposed in Annex B in the staff assessment. > 2007-13: Removal of ISP Immediate Need from End-User I support 2007-13. > 2007-14: Resource Review Process I support 2007-14. > 2007-15: Authentication of Legacy Resources I OPPOSE 2007-15 as written. I do like the proposed Legacy RSA. I would be supportive if the 3rd paragraph were revised as follows: "No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2008" This change gives a minimum of 1 year of outreach efforts. > 2007-16: IPv4 Soft Landing I support 2007-16. > 2007-17: Legacy Outreach and Partial Reclamation I OPPOSE 2007-17. The Legacy RSA proposes additional benefits for the return of IP resources, which address this issue. > 2007-18: Global Policy for the Allocation of the Remaining IPv4 > Address Space I OPPOSE 2007-18, in favor of 2007-23. > 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs I support 2007-19 - as it codifies the existing practice (as described in the Rationale) > 2007-21: PIv6 for legacy holders with RSA and efficient use I support 2007-21. > 2007-22: Expand timeframe of Additional Requests I OPPOSE 2007-22, though I have mixed feelings about it. On the one hand, I like the idea of harmonizing policy with other RIRs. On the other, the policy may have negative effects on IPv4 conservation efforts, which far outweigh any benefits of harmonization. > 2007-23: End Policy for IANA IPv4 allocations to RIRs I support 2007-23. > 2007-24: IPv6 Assignment Guidelines I support 2007-24. Simple is better. > 2007-25: IPv6 Policy Housekeeping I support 2007-25, clarification is a good thing. > 2007-26 Lame Delegation Policy I support 2007-26. -- Sincerely, Kirk Ismay System Administrator -- Net Idea 201-625 Front Street Nelson, BC V1L 4B6 P:250-352-3512 | F:250-352-9780 | TF:1-888-352-3512 Check out our brand new website! www.netidea.com From weiler at tislabs.com Wed Oct 17 17:30:43 2007 From: weiler at tislabs.com (Sam Weiler) Date: Wed, 17 Oct 2007 17:30:43 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation Message-ID: I support 2007-17. I believe the community is best served by accepting returned address space (and swapping address space for smaller and/or aggregatable blocks) with as few restrictions as possible. I specifically like the "no RSA" part of this proposal. I think signing of any agreement with ARIN, even the proposed Legacy RSA, is an impediment to returning resources -- if I personally held legacy space, I'd be very reluctant to do it. The particular proposal text may need further work, particularly to address the NRPM section 4.7 confusion identified by staff. I'd also prefer to see the policy not mention the RSA specifically but instead say "any agreement". (I used broad language like that on 15 May 2006 as part of the "Requirement for Reasonable Contract Terms" policy proposal.) -- Sam From weiler at tislabs.com Wed Oct 17 17:40:30 2007 From: weiler at tislabs.com (Sam Weiler) Date: Wed, 17 Oct 2007 17:40:30 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources Message-ID: I oppose 2007-15. I think the community is better served by having up-to-date WHOIS information than by trying to force legacy address holders to sign RSAs. Remembering that part of the value of the WHOIS is to the net at large, not just the address holder -- putting more conditions on updating the WHOIS, which will lead to more stale data, penalizes users of the net beyond just the address holder. -- Sam From briand at ca.afilias.info Wed Oct 17 19:40:44 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Wed, 17 Oct 2007 19:40:44 -0400 (EDT) Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> Message-ID: <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> Here is the jist of the modification to the proposal, which is basically clock-based (run-rate based): Immediately prior to the assignments for N=1, have a policy which will be triggered by a current consensus estimate among the RIRs that the *slowest* RIR run rate will use up one /8 before IANA Address Depletion, the remaining space is divided based on the projected usage between that time and IAD. (For absolute fairness, allow any RIR to hit the "panic button", with the caveat that if the slowest-growing RIR hits the panic button, that RIR would only get their one last /8.) One /8 is subtracted from this value, to be given out per -23. The remainder is allocated in as aggregatable a fashion, but with a granularity of /12, and given to the RIRs based on projected use. This distribution will leave one /8 per RIR, which will trigger 2007-23. And, combined with 2007-23, this policy will result in near simultaneous RIR exhaustion dates for all RIRs. For example (and example only): Imagine 5 RIRs, A, B, C, D, E. Imagine in this scenario, that IAD is 1.5 years away. Run rates are: A = 5 /8's per year B = 3 /8's per year C = 2 /8's per year D = 1 /8's per year E = 1 /8 per 1.5 years. Assume some non-linear aspect to run rates. Assume that based on current projections, the last 1.5 years will result in usage for RIRs of, respectively: A = 9.5 /8's B = 5.25 /8's C = 2.75 /8's D = 1.5 /8's E = 1.0 /8's And (in order to have this use up all the space), there are 18 /8's left. This policy would, at the moment in time that the slowest RIR needs exactly one /8, assign X-1 /8's or parts thereof, to each RIR. In this example, that would be: A = 8 /8's and 1 /9 B = 4 /8's and 1 /10 C = 1 /8's, 1 /9, and 1 /10 D = 1 /9 E = (nothing, because current estimate is 1 /8 *) (* - if at the time the decision is taken to implement the final assignments, the smallest RIR has more than one /8 estimated use, they would get that portion above the one /8, rather than nothing.) And then immediately, each of A, B, C, D, and E, get the last /8 each, exactly the way 2007-23 proposes. This would result in achieving the balance of 2007-23, and also being fair based on run rate. Everyone would have the same amount of time, and more than one /8 left with which to enact respective "final /8" policies. Apologies if this isn't totally clear; please ask for details on any aspect of this if you don't understand what is being proposed. It is basically, split the last of the pie fairly, when the smallest piece is big enough to "eat". Brian Dickson From michael.dillon at bt.com Wed Oct 17 22:36:55 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 18 Oct 2007 03:36:55 +0100 Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> Message-ID: > It is basically, split the last of the pie fairly, when the > smallest piece is big enough to "eat". No, this is basically split the pie UNFAIRLY using some complex formula which nobody can understand. Instead of the current level playing field that everyone understands, you have a new, poorly understood calculation, which will likely be to the benefit of some organizations and to the detriment of others. This is completely unfair. Currently we give out addresses based on demonstrated technical need for them. Why should we ever change this? --Michael Dillon From Ed.Lewis at neustar.biz Thu Oct 18 11:05:12 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Thu, 18 Oct 2007 09:05:12 -0600 Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net .uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> Message-ID: At 3:36 +0100 10/18/07, wrote: >Currently we give out addresses based on demonstrated technical need for >them. Why should we ever change this? The principle of "least surprise." It's good to know that the game is about to end. It's true that we currently have a disparity in run-rates at the RIRs. Do we know that the run-rate at each RIR is a constant, has the newest RIR been operating long enough to predict it's workload in a year or two? All of "this" (whether to *do* -18, -23, nothing, etc.) is based on conjecture and opinion. There are many scenarios that may play out. The best that we can hope for is to pick the approach that has the best "expected value" according to some metric of happiness. For every reason that can be given to agree with "leaving well enough alone" there is a reason to say that we should treat the last /8's specially. Playing a hunch from my experience, trying to find a happy medium amongst the extremes is the best strategy. I like reserving just the last 1 slash-8 per RIR for an even distribution. It's more signal than significant to me. Perhaps the slowest burning RIR will "catch up" and we will wind up with this being the same as the current approach. Maybe that "surplus" to the slowest RIR is more needed there for dual-stack transition. It's all conjecture. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From briand at ca.afilias.info Thu Oct 18 12:38:38 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 12:38:38 -0400 (EDT) Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> Message-ID: <49835.192.35.166.161.1192725518.squirrel@look.libertyrms.com> > Here is the jist of the modification to the proposal, which is basically > clock-based (run-rate based): Commenting on my own proposal, and clarifying the intent and details... I neglected the existence of remaining unused portions of /8's within the RIRs. As such, there would need to be details modified about triggering events and calculations... > Immediately prior to the assignments for N=1, have a policy which will be > triggered by a current consensus estimate among the RIRs that the > *slowest* RIR run rate will use up one /8 before IANA Address Depletion, > the remaining space is divided based on the projected usage between that > time and IAD. In order to avoid having two slow-use RIRs being in a race condition, where one gets a /8 that will bring it *close* to IAD but not past it, and the other then causing the triggering of the policy, it would need to be changed slightly: The trigger event would be an RIR requesting a /8, where *that* RIR would, based on projected use, not be able to use up two /8's before IAD. In other words, that IAD would occur before the RIR used up that /8 and one other /8. (The second /8 would be one of the five /8's given to the RIRs as a result of 2007-23.) Since the *first* instance of an RIR meeting this condition would trigger the rest of this proposal, we can be sure that no race condition will result (other than very slight variations in usage during the very final period, which are expected to fit within the rounding error of /12.) > (For absolute fairness, allow any RIR to hit the "panic button", with the > caveat that if the slowest-growing RIR hits the panic button, that RIR > would > only get their one last /8.) > > One /8 is subtracted from this value, to be given out per -23. > The remainder is allocated in as aggregatable a fashion, but with a > granularity of /12, and given to the RIRs based on projected use. The above would be modified according to the following: ... after subtracting the current remaining unallocated space from each RIR's current /8. > This distribution will leave one /8 per RIR, which will trigger 2007-23. > > And, combined with 2007-23, this policy will result in near simultaneous > RIR exhaustion dates for all RIRs. > > For example (and example only): > Imagine 5 RIRs, A, B, C, D, E. > Imagine in this scenario, that IAD is 1.5 years away. > Run rates are: > A = 5 /8's per year > B = 3 /8's per year > C = 2 /8's per year > D = 1 /8's per year > E = 1 /8 per 1.5 years. This example, for simplification, also assumes all 5 RIRs are requesting /8's at the same time. > Assume some non-linear aspect to run rates. > Assume that based on current projections, the last 1.5 years will result > in > usage for RIRs of, respectively: > A = 9.5 /8's > B = 5.25 /8's > C = 2.75 /8's > D = 1.5 /8's > E = 1.0 /8's > > And (in order to have this use up all the space), there are 18 /8's left. > > This policy would, at the moment in time that the slowest RIR needs > exactly > one /8, assign X-1 /8's or parts thereof, to each RIR. > > In this example, that would be: > A = 8 /8's and 1 /9 > B = 4 /8's and 1 /10 > C = 1 /8's, 1 /9, and 1 /10 > D = 1 /9 > E = (nothing, because current estimate is 1 /8 *) > > (* - if at the time the decision is taken to implement the final > assignments, the smallest RIR has more than one /8 estimated use, they > would get that portion above the one /8, rather than nothing.) > > And then immediately, each of A, B, C, D, and E, get the last /8 each, > exactly the way 2007-23 proposes. > > This would result in achieving the balance of 2007-23, and also being > fair based on run rate. Everyone would have the same amount of time, > and more than one /8 left with which to enact respective "final /8" > policies. > > Apologies if this isn't totally clear; please ask for details on any > aspect of this if you don't understand what is being proposed. > > It is basically, split the last of the pie fairly, when the smallest piece > is big enough to "eat". And to be ultra-clear on this, the pie is not completely divided out under this proposal; it leaves one piece each, with the expectation that the combined amounts (this proposal *plus* 2007-23) will result in each RIR exhausting their respective pools of IANA-supplied addresses at the same time, or within a very short window (i.e. the error range of the projections of usage.) Brian From briand at ca.afilias.info Thu Oct 18 12:47:30 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 12:47:30 -0400 (EDT) Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> Message-ID: <49845.192.35.166.161.1192726050.squirrel@look.libertyrms.com> >> It is basically, split the last of the pie fairly, when the >> smallest piece is big enough to "eat". > > No, this is basically split the pie UNFAIRLY using some complex formula > which nobody can understand. Are you claiming you don't understand the formula? Or are you putting words in the mouths of every other ARIN member, none of which have yet commented on the understandability of the formula? I asked that anyone who had trouble understanding the proposal, to ask for clarification on any and all parts of the proposal. You haven't asked for any clarifications, so either you are blindly rejecting it because it is different from current policy, or for no reason at all acting as a nay-sayer. If you are interested in understanding the proposal, please ask questions that will get you to the point of understanding it. > Instead of the current level playing field > that everyone understands, you have a new, poorly understood > calculation, which will likely be to the benefit of some organizations > and to the detriment of others. This is completely unfair. The calculation, per my proposal, only needs to be understood by and agreed upon by the RIRs. If the RIRs agree it is fair, then they will use the calculation. The policy, independent of the specific calculation, it that each RIR gets enough space through the run-out date, so that all RIRs run out at the same time. I do not understand how that is not "fair", or how you interpret this to not be fair. Perhaps you could explain how you perceive this as unfair? The current policies are fair only under the assumption that more address space is available for all RIRs - a situation which exists today but will not exist at some point in the future. The exact point in time where that happens, *is* the trigger point for my policy as proposed (ammended today). > Currently we give out addresses based on demonstrated technical need for > them. Why should we ever change this? IANA does not give out addresses. It gives out blocks of addresses to RIRs. The proposed policy is independent of how RIRs give out addresses, which will continue to be based on demonstrated technical need for them. We should not ever change this. Brian From briand at ca.afilias.info Thu Oct 18 12:58:29 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 12:58:29 -0400 (EDT) Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> Message-ID: <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> I propose adding one additional condition under which an organization would be eligible for receiving an IPv6 PI allocation from ARIN: The organization currently has been assigned an ASN and is actively using it. The rationale is, if an organization has an ASN, they are actively involved in multihoming, which is the one situation under which current PA assignment would not meet the needs of the organization. Regardless of whether they meet the other current requirements, in order to encourage IPv6 adoption, these organizations are most likely to be able to immediately use their allocations, since they are fundamentally independent of their upstream providers (by way of originating their prefixes from their own AS). Such an organization would, in fact, be able to use different/new IPv6 transit providers, if their current IPv4 transit providers were not IPv6 dual-stacked already. Conversely, if such an organization's upstreams were not IPv6 already, they would not be able to start using IPv6 (native) until their upstream(s) went IPv6. If ARIN is interested in encouraging IPv6 adoption, extending IPv6 PI allocations to all organizations that have an actively used ASN, is the most logical way to pursue that interest. Brian Dickson From arin-contact at dirtside.com Thu Oct 18 13:11:56 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 13:11:56 -0400 Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> Message-ID: <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> Brian, Its possible (and in some cases preferred) for small orgs to use a private ASN and let the the service provider strip it before propagating the announcement. I forget the exact numbers but its in the 64000/65000 range. This is one of the sources of "inconsistent ASes" in the routing table. Requiring the assignment of an ASN would burn ASNs unnecessarily in this case. Regards, Biill Herrin On 10/18/07, briand at ca.afilias.info wrote: > I propose adding one additional condition under which an organization > would be eligible for receiving an IPv6 PI allocation from ARIN: > > The organization currently has been assigned an ASN and is actively using it. -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Thu Oct 18 13:16:20 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 13:16:20 -0400 Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> Message-ID: <3c3e3fca0710181016n6e436ff3jcb818c0bd1888b26@mail.gmail.com> To clarify: 64512 - 65534 Designated for private use and in Cisco IOS the private AS is stripped before propagation to the Internet with: neighbor x.x.x.x remove-private-AS Regards, Bill Herrin On 10/18/07, William Herrin wrote: > Brian, > > Its possible (and in some cases preferred) for small orgs to use a > private ASN and let the the service provider strip it before > propagating the announcement. I forget the exact numbers but its in > the 64000/65000 range. This is one of the sources of "inconsistent > ASes" in the routing table. > > Requiring the assignment of an ASN would burn ASNs unnecessarily in this case. > > Regards, > Biill Herrin > > > > On 10/18/07, briand at ca.afilias.info wrote: > > I propose adding one additional condition under which an organization > > would be eligible for receiving an IPv6 PI allocation from ARIN: > > > > The organization currently has been assigned an ASN and is actively using it. > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From briand at ca.afilias.info Thu Oct 18 13:18:46 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 13:18:46 -0400 (EDT) Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> Message-ID: <49884.192.35.166.161.1192727926.squirrel@look.libertyrms.com> > Brian, > > Its possible (and in some cases preferred) for small orgs to use a > private ASN and let the the service provider strip it before > propagating the announcement. I forget the exact numbers but its in > the 64000/65000 range. This is one of the sources of "inconsistent > ASes" in the routing table. > > Requiring the assignment of an ASN would burn ASNs unnecessarily in this > case. I think you are concerned about *requiring* ASNs; my proposal addresses on the additional *ability* to get PI IPv6 for orgs that don't qualify under other criteria. Under the conditions you describe, do those orgs not qualify either under existing policy, or based on the proposed "legacy + efficient utilization" policy? If they do, then I don't think it's an issue. Besides, ASNs don't, by themselves, use router slots, so I don't think ASN burn rate is as big an issue. We know we will need to go to 4-byte ASNs soon, regardless of new ways of encouraging ASN requests, and once 4-byte ASNs are being used, the ASN burn rate is also not an issue... Brian > Regards, > Biill Herrin > > > > On 10/18/07, briand at ca.afilias.info wrote: >> I propose adding one additional condition under which an organization >> would be eligible for receiving an IPv6 PI allocation from ARIN: >> >> The organization currently has been assigned an ASN and is actively >> using it. > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > From arin-contact at dirtside.com Thu Oct 18 13:31:01 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 13:31:01 -0400 Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <49884.192.35.166.161.1192727926.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> <49884.192.35.166.161.1192727926.squirrel@look.libertyrms.com> Message-ID: <3c3e3fca0710181031t45d227acr3871ab58678124ad@mail.gmail.com> On 10/18/07, briand at ca.afilias.info wrote: > I think you are concerned about *requiring* ASNs; my proposal addresses > on the additional *ability* to get PI IPv6 for orgs that don't qualify under > other criteria. > > Under the conditions you describe, do those orgs not qualify either under > existing policy, or based on the proposed "legacy + efficient utilization" > policy? Brian, Orgs efficiently using private AS numbers would qualify for IPv6 PI under 2007-21. As I understand your suggested modification, they would not qualify since they don't hold an ARIN assigned AS number. They would qualify for an AS number so they could get that first and then get IPv6 PI space, but why make an extra hurdle and spend an extra AS number with extra record-keeping? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From briand at ca.afilias.info Thu Oct 18 13:37:23 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 13:37:23 -0400 (EDT) Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <3c3e3fca0710181031t45d227acr3871ab58678124ad@mail.gmail.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> <49884.192.35.166.161.1192727926.squirrel@look.libertyrms.com> <3c3e3fca0710181031t45d227acr3871ab58678124ad@mail.gmail.com> Message-ID: <49912.192.35.166.161.1192729043.squirrel@look.libertyrms.com> > On 10/18/07, briand at ca.afilias.info wrote: >> I think you are concerned about *requiring* ASNs; my proposal addresses >> on the additional *ability* to get PI IPv6 for orgs that don't qualify >> under >> other criteria. >> >> Under the conditions you describe, do those orgs not qualify either >> under >> existing policy, or based on the proposed "legacy + efficient >> utilization" >> policy? > > Brian, > > Orgs efficiently using private AS numbers would qualify for IPv6 PI > under 2007-21. As I understand your suggested modification, they would > not qualify since they don't hold an ARIN assigned AS number. My intention is to add an "else-if" condition, not an "and" condition. If they qualify, I don't propose any change to them qualifying. It is only if they didn't *otherwise* qualify, that this would be another way to qualify. Brian > They > would qualify for an AS number so they could get that first and then > get IPv6 PI space, but why make an extra hurdle and spend an extra AS > number with extra record-keeping? > > Regards, > Bill Herrin > > > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > From scott.beuker at sjrb.ca Thu Oct 18 13:37:17 2007 From: scott.beuker at sjrb.ca (Scott Beuker) Date: Thu, 18 Oct 2007 11:37:17 -0600 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <200709010103.l81138Vk008834@cjbsys.bdb.com> Message-ID: I oppose the policy proposal because all it really serves to do is grandfather the special treatment of legacy IPv4 space holders into the IPv6 world. I was very much looking forward to the fresh start IPv6 offered, where everyone would qualify for their address space on the same merits as everyone else. No more special treatment. Leave behind the legal mess and inequality that legacy space created with IPv4. Don't grandfather IPv4's flaws. There is not adequate reason here to: (a) add to the bloat of the IPv6 routing table (b) create inequity in conditions of qualification in IPv6 (c) create a precedence of special treatment for IPv4 legacy space holders in the IPv6 world If you voted in support of this proposal, why not take it all the way and simply seek to loosen the requirements for IPv6 space such that EVERYONE of that size network can get space (not just legacy IPv4 holders)? Sure, it will probably lead to major problems in the DFZ down the road, but it would appear to me that those who support this proposal don't consider or care about such things anyway. Thank you, Scott Beuker From arin-contact at dirtside.com Thu Oct 18 13:41:56 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 13:41:56 -0400 Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: <49845.192.35.166.161.1192726050.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49845.192.35.166.161.1192726050.squirrel@look.libertyrms.com> Message-ID: <3c3e3fca0710181041g37b75491y61d372ccc81e78df@mail.gmail.com> On 10/18/07, briand at ca.afilias.info wrote: > >> It is basically, split the last of the pie fairly, when the > >> smallest piece is big enough to "eat". > > > > No, this is basically split the pie UNFAIRLY using some complex formula > > which nobody can understand. > > Are you claiming you don't understand the formula? Brian, I would suggest that the more complex the formula, the less likely it will be perceived as fair. Thus we seek the fairest SIMPLE formula. For example, does ANY US taxpayer consider the income tax fair? Yet the whole point of the vastly complex deductions was to make it fair. 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 xdsinc.net Thu Oct 18 13:44:32 2007 From: mcr at xdsinc.net (mcr at xdsinc.net) Date: Thu, 18 Oct 2007 13:44:32 -0400 Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> Message-ID: <20071018174353.C717514456E@smtp2.arin.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "William" == William Herrin writes: William> Brian, William> Its possible (and in some cases preferred) for small orgs William> to use a private ASN and let the the service provider strip William> it before propagating the announcement. I forget the exact William> numbers but its in the 64000/65000 range. This is one of William> the sources of "inconsistent ASes" in the routing table. I understood Brian's "condition" to be a disjunction. I.e. if you have an ASN then you get IPv6, irregardless of whether you would otherwise quality. Not... "In addition to ... you must have an ASN" - -- Michael Richardson XDS Inc, Ottawa, ON Personal: http://www.sandelman.ca/mcr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBRxebfu0sRu40D6vCAQLWqQX/SpjoKTBwqgivYN4Ef11G7o4YmERIz/2Z zbQ7nGxsxPNQr5AxOkuA8n9jGm4iWS+iVIIvBX6Cs5kV8ZVE8u6JBItVfX1pYQhP Oab62HObFEL32WgepxIvnmrTwt/dzZE6zasBvlCEO/DzqudRgilPgPngFzqpGsFU 1/KOsAuMIYTl0pwohRSYVHhzbhryjuS8Hqks44nFFbunyW7vwqyPu35XkOtEAuBk 36s9jkEKgiwbE3Eg9+8kdRCXrlVnMn6/ =DfGb -----END PGP SIGNATURE----- From andrew.dul at quark.net Thu Oct 18 13:44:01 2007 From: andrew.dul at quark.net (=?iso-8859-1?Q?Andrew=20Dul?=) Date: Thu, 18 Oct 2007 09:44:01 -0800 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with Message-ID: <20071018174401.13283.qmail@hoster908.com> > -------Original Message------- > From: Scott Beuker > Subject: Re: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with > Sent: 18 Oct '07 09:37 > > > I oppose the policy proposal because all it really serves to do > is grandfather the special treatment of legacy IPv4 space holders > into the IPv6 world. This is the exact reason I also opposed the policy. Andrew From arin-contact at dirtside.com Thu Oct 18 13:45:53 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 13:45:53 -0400 Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <49912.192.35.166.161.1192729043.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> <49884.192.35.166.161.1192727926.squirrel@look.libertyrms.com> <3c3e3fca0710181031t45d227acr3871ab58678124ad@mail.gmail.com> <49912.192.35.166.161.1192729043.squirrel@look.libertyrms.com> Message-ID: <3c3e3fca0710181045xfcb15c4ib78573bdff7b29ca@mail.gmail.com> On 10/18/07, briand at ca.afilias.info wrote: > My intention is to add an "else-if" condition, not an "and" condition. > If they qualify, I don't propose any change to them qualifying. > > It is only if they didn't *otherwise* qualify, that this would be another > way to qualify. Brian, So if someone announces a /24 hole carved from someone's PA space with an ARIN-assigned AS number then they should qualify for an IPv6 PI assignment. Do I correctly understand you now? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From arin-contact at dirtside.com Thu Oct 18 13:55:42 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 13:55:42 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <20071018174401.13283.qmail@hoster908.com> References: <20071018174401.13283.qmail@hoster908.com> Message-ID: <3c3e3fca0710181055r1b80d5dcm4d558d09fed2b552@mail.gmail.com> On 10/18/07, Andrew Dul wrote: > > I oppose the policy proposal because all it really serves to do > > is grandfather the special treatment of legacy IPv4 space holders > > into the IPv6 world. > > This is the exact reason I also opposed the policy. Andrew, To me, the most important thing is that the fresh start actually happen. I don't think that's inevitible. Double-NAT can be made to work and when it does, 4B addresses is enough. To my way of thinking, refusing to in some way grandfather the IPv4 legacy users, especially the multihomed ones, qualifies as "cutting off your nose to spite your face." Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From briand at ca.afilias.info Thu Oct 18 13:58:01 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 13:58:01 -0400 (EDT) Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <3c3e3fca0710181045xfcb15c4ib78573bdff7b29ca@mail.gmail.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> <49884.192.35.166.161.1192727926.squirrel@look.libertyrms.com> <3c3e3fca0710181031t45d227acr3871ab58678124ad@mail.gmail.com> <49912.192.35.166.161.1192729043.squirrel@look.libertyrms.com> <3c3e3fca0710181045xfcb15c4ib78573bdff7b29ca@mail.gmail.com> Message-ID: <49935.192.35.166.161.1192730281.squirrel@look.libertyrms.com> > On 10/18/07, briand at ca.afilias.info wrote: >> My intention is to add an "else-if" condition, not an "and" condition. >> If they qualify, I don't propose any change to them qualifying. >> >> It is only if they didn't *otherwise* qualify, that this would be >> another >> way to qualify. > > Brian, > > So if someone announces a /24 hole carved from someone's PA space with > an ARIN-assigned AS number then they should qualify for an IPv6 PI > assignment. Do I correctly understand you now? Yes, just as they would if they had an inefficiently used /24 of legacy space announced from an ARIN-assigned (or legacy) ASN. The further rationale is that no one will efficiently use a PI or PA IPv6 allocation, be it a /32 or a /48. :-) Brian From arin-contact at dirtside.com Thu Oct 18 14:13:28 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 14:13:28 -0400 Subject: [ppml] IPv6 PI to legacy IPv4 holders In-Reply-To: <49935.192.35.166.161.1192730281.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <3c3e3fca0710181011o78db740fj49ca890e69fb39ef@mail.gmail.com> <49884.192.35.166.161.1192727926.squirrel@look.libertyrms.com> <3c3e3fca0710181031t45d227acr3871ab58678124ad@mail.gmail.com> <49912.192.35.166.161.1192729043.squirrel@look.libertyrms.com> <3c3e3fca0710181045xfcb15c4ib78573bdff7b29ca@mail.gmail.com> <49935.192.35.166.161.1192730281.squirrel@look.libertyrms.com> Message-ID: <3c3e3fca0710181113r1e8ec420va2f67b94a883fa4b@mail.gmail.com> On 10/18/07, briand at ca.afilias.info wrote: > > So if someone announces a /24 hole carved from someone's PA space with > > an ARIN-assigned AS number then they should qualify for an IPv6 PI > > assignment. Do I correctly understand you now? > > Yes, just as they would if they had an inefficiently used /24 of legacy > space announced from an ARIN-assigned (or legacy) ASN. Brian, Okay, that seems reasonable to me. If folks who need to multihome in v6 never bust holes in the ISP /32's then filters can be applied at /32 in the space assigned to service providers so that TE doesn't contribute to a DFZ size problem. Can this be forwarded as a suggestion to the AC as they deliberate on 2007-21 or would we need to make a new proposal? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From david at omd3.com Thu Oct 18 14:16:04 2007 From: david at omd3.com (David S. Madole) Date: Thu, 18 Oct 2007 14:16:04 -0400 (EDT) Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: References: <200709010103.l81138Vk008834@cjbsys.bdb.com> Message-ID: <4538.66.212.195.12.1192731364.squirrel@ssl.omd3.com> > From: "Scott Beuker" > > I oppose the policy proposal because all it really serves to do > is grandfather the special treatment of legacy IPv4 space holders > into the IPv6 world. I was very much looking forward to the fresh > start IPv6 offered, where everyone would qualify for their > address space on the same merits as everyone else. As Ted pointed out recently, there is currently a disincentive for legacy holders to implement IPv6 at all versus dragging out IPv4 as long as they can. One simple way to remove this disincentive would be to offer IPv6 addresses to legacy holders on the same terms as their IPv4 addresses, or maybe not the same but something that removes or lessens the disincentive. I am sure that concept will be thoroughly rebuffed for purely political reasons. That's ok with me, as I am not advocating for it here, just pointing it out as an effective solution to that problem, if anyone even considers it to be a problem as Ted does. Taking this point a little further, it's largely the legacies that got IPv4 to take off and got the Internet built, they could be the ones to do the same for IPv6 too perhaps if given an incentive rather than a disincentive. After all, even ARIN, who should be leading the way I would think, isn't even offering whois on IPv6 yet as far as I can tell, even though RIPE has been doing so for almost five years. David From scott.beuker at sjrb.ca Thu Oct 18 14:58:23 2007 From: scott.beuker at sjrb.ca (Scott Beuker) Date: Thu, 18 Oct 2007 12:58:23 -0600 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <4538.66.212.195.12.1192731364.squirrel@ssl.omd3.com> Message-ID: Comments below... > > I oppose the policy proposal because all it really serves to do is > > grandfather the special treatment of legacy IPv4 space holders into > > the IPv6 world. I was very much looking forward to the fresh start > > IPv6 offered, where everyone would qualify for their > address space on > > the same merits as everyone else. > > As Ted pointed out recently, there is currently a > disincentive for legacy holders to implement IPv6 at all > versus dragging out IPv4 as long as they can. There's also currently many disincentives for me to move to IPv6, one of which is that table bloat is going to make it costly to support two tables for both IPv4 and IPv6, requiring upgrades. We all have "disincentives" for going to IPv6, and we all have to deal with them. In this case, it's not fair to ask the community at large to shoulder the burden for the sake of this small group. > One simple way to remove this disincentive would be to offer > IPv6 addresses to legacy holders on the same terms as their > IPv4 addresses, or maybe not the same but something that > removes or lessens the disincentive. While it would be nice to give a block to everyone who wants it, there are very real technical reasons this simply can't happen. A line has been drawn by the community as a whole. This proposal side steps the line, without a truly compelling reason, in my opinion. > Taking this point a little further, it's largely the legacies > that got IPv4 to take off and got the Internet built, they > could be the ones to do the same for IPv6 too perhaps if > given an incentive rather than a disincentive. I'm sick of this argument, I've been hearing it since I got involved in ARIN. Every time the legacy holders want something, someone has to play the "we built the Internet" card. Quite frankly, I think this argument is bunk, but that whole discussion is totally irrelevant so I'm going to stop there. People who buy this argument are beyond being swayed by rational discussion anyway. Scott Beuker From kkargel at polartel.com Thu Oct 18 15:09:54 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 18 Oct 2007 14:09:54 -0500 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <4538.66.212.195.12.1192731364.squirrel@ssl.omd3.com> References: <200709010103.l81138Vk008834@cjbsys.bdb.com> <4538.66.212.195.12.1192731364.squirrel@ssl.omd3.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667076A0@mail> I am all for giving the legacy holders a fair break, and being nice to them. I would go so far as to say that "initial" fees for them could be waived. Past that I am opposed to giving them more ongoing rights, priviledges or recurring concessions than anyone else (meaning me) gets. IPv6 needs to be a level playing field. Everyone should have the same requirements, rights and responsibilities. Simply said. Kevin > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of David S. Madole > Sent: Thursday, October 18, 2007 1:16 PM > To: arin ppml > Subject: Re: [ppml] Policy Proposal 2007-21: PIv6 for legacy > holders with > > > From: "Scott Beuker" > > > > I oppose the policy proposal because all it really serves to do is > > grandfather the special treatment of legacy IPv4 space holders into > > the IPv6 world. I was very much looking forward to the fresh start > > IPv6 offered, where everyone would qualify for their > address space on > > the same merits as everyone else. > > As Ted pointed out recently, there is currently a > disincentive for legacy holders to implement IPv6 at all > versus dragging out IPv4 as long as they can. > > One simple way to remove this disincentive would be to offer > IPv6 addresses to legacy holders on the same terms as their > IPv4 addresses, or maybe not the same but something that > removes or lessens the disincentive. > > I am sure that concept will be thoroughly rebuffed for purely > political reasons. That's ok with me, as I am not advocating > for it here, just pointing it out as an effective solution to > that problem, if anyone even considers it to be a problem as Ted does. > > Taking this point a little further, it's largely the legacies that got > IPv4 to take off and got the Internet built, they could be > the ones to do the same for IPv6 too perhaps if given an > incentive rather than a disincentive. > > After all, even ARIN, who should be leading the way I would > think, isn't even offering whois on IPv6 yet as far as I can > tell, even though RIPE has been doing so for almost five years. > > David > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > From RMHeisey at pdpgroupinc.com Thu Oct 18 16:59:55 2007 From: RMHeisey at pdpgroupinc.com (RMHeisey at pdpgroupinc.com) Date: Thu, 18 Oct 2007 16:59:55 -0400 Subject: [ppml] Email Address Message-ID: Below find my email address. Rick Heisey Computer Operations/Network Manager PDP Technologies +Email:RMHEISEY at PDPGROUPINC.COM (Office:(410) 584-0337 ?Mobile:(443) 271-1899 The information contained in this communication may be confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please re-send this communication to the sender and delete the original message and any copy of it from your computer system. Thank you. For more information please visit: http://www.pdpgroupinc.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.dillon at bt.com Thu Oct 18 17:25:22 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 18 Oct 2007 22:25:22 +0100 Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: <49845.192.35.166.161.1192726050.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49845.192.35.166.161.1192726050.squirrel@look.libertyrms.com> Message-ID: > > No, this is basically split the pie UNFAIRLY using some complex > > formula which nobody can understand. > You haven't asked for any clarifications, so either you are > blindly rejecting it because it is different from current > policy, or for no reason at all acting as a nay-sayer. Or else I, like you, find the formula complex and difficult to understand in its entirety. Judging by the message that you just posted which makes a small adjustment in the formula, you also have trouble fully understanding it. And now you have added more complexity by modifying the triggering events and calculations. Even if ARIN passes this, that version has to remain substantially unchanged and be passed in the other 5 RIRs. If, by chance you have rigged the formula so that it is worse for North America and better for other regions, they have several months to study it and understand it and pass it unchanged so as to lock us into our stupidity. Or, if it is worse for other regions, they will not pass it, so why should we even bother starting this ball rolling. In any case, the bottom line is that you just changed the formula so that gives ARIN members, what, a day or so to figure this out before passing it? > I do not understand how that is not "fair", or how you > interpret this to not be fair. Perhaps you could explain how > you perceive this as unfair? It is unfair because it is an arbitrary formula which you are fiddling with up to the last minute. It replaces the proven method of allocating IP resources based on proven technical need. Fair would be for all the RIRs to pool any substantial free chunks of IPv4 space from their regional allocations and jointly manage it so that it goes to whoever in the world needs it, when they can demonstrate technical need. This would avoid the games with shell companies in Africa that your proposal will lead to. This whole policy process is deeply flawed because it encourages shallow thinking like your variation on a variation of a bad idea, to take center stage and does not dig out the creative thinking that could lead to a really workable solution. What we really need is an all-party working group (all RIR working group) that brainstorms various approaches and produces a report describing how they could be implemented and what the implications are of each proposal, both pro and con. That way everybody could go into the decision making process with all the cards on the table. --Michael Dillon From stephen at sprunk.org Thu Oct 18 18:10:31 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 18 Oct 2007 17:10:31 -0500 Subject: [ppml] IPv6 PI to legacy IPv4 holders References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> Message-ID: <005501c811d4$ac0ab160$82a723c0@atlanta.polycom.com> Thus spake > I propose adding one additional condition under which an organization > would be eligible for receiving an IPv6 PI allocation from ARIN: > > The organization currently has been assigned an ASN and is actively > using it. The problem with that is that it's trivial to get an ASN; effectively setting the bar for PI space to "anyone who wants it". While one can debate how low the bar should be (and such debate comes up every few months), I cannot support removing the bar entirely. > The rationale is, if an organization has an ASN, they are actively > involved in multihoming, which is the one situation under which > current PA assignment would not meet the needs of the organization. In v4, we require a multihomed end user to justify at least a /22 to get a direct assignment. That bar is inherited for v6 today. There was a proposal in prior cycles to reduce that bar to a /24; it was defeated for a variety of reasons, most recently due to the perceived potential for abuse by spammers. While I find that unfortunate, I believe that is the fair and correct way to open things up so that those legacy holders with a /24 (who could justify such again today) could get PIv6 space. I am strongly opposed to giving PIv6 space to Legacy Class C holders who couldn't justify a /24 today simply because they happened to get a block back in the days when nobody was paying attention. I'm definitely opposed to giving PIv6 space to those folks and _not_ giving PIv6 space to folks who potentially have equal or better utilization today. I do thank many Legacy folks for their contribution 15+ years ago, but I've seen too many folks who swiped (not SWIP'd) a Class C from a past employer and are using it for their two-PC home network today to believe that simply being a legacy holder means that one made a meaningful contribution to the birth of the Internet that deserves any sort of special treatment, e.g. that it alone justifies PIv6 space and thus a slot in the v6 DFZ. Extending that proposal to non-Legacy ASN holders (including folks who get an ASN tomorrow solely to dodge the current requirements) is unconscionable, IMHO. > If ARIN is interested in encouraging IPv6 adoption, extending IPv6 PI > allocations to all organizations that have an actively used ASN, is the > most logical way to pursue that interest. According to the BoT, ARIN is not in the business of "encouraging" particular technologies. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Thu Oct 18 17:19:12 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 18 Oct 2007 16:19:12 -0500 Subject: [ppml] Policy Proposals 2007-18 and -23 References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com><49845.192.35.166.161.1192726050.squirrel@look.libertyrms.com> <3c3e3fca0710181041g37b75491y61d372ccc81e78df@mail.gmail.com> Message-ID: <005401c811d4$ab473a50$82a723c0@atlanta.polycom.com> Thus spake "William Herrin" > I would suggest that the more complex the formula, the less likely it > will be perceived as fair. Thus we seek the fairest SIMPLE formula. > > For example, does ANY US taxpayer consider the income tax fair? Yet > the whole point of the vastly complex deductions was to make it fair. Is the goal to _be_ fair or to _appear_ fair? It _appears_ fair that the sheep and two wolves each get an equal vote on dinner, but the reality is that it's not fair at all. There are hundreds of similar examples where trying to make things _appear_ to be fair ensures that they are not in practice. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From arin-contact at dirtside.com Thu Oct 18 18:28:40 2007 From: arin-contact at dirtside.com (William Herrin) Date: Thu, 18 Oct 2007 18:28:40 -0400 Subject: [ppml] Policy Proposals 2007-18 and -23 In-Reply-To: <005401c811d4$ab473a50$82a723c0@atlanta.polycom.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49845.192.35.166.161.1192726050.squirrel@look.libertyrms.com> <3c3e3fca0710181041g37b75491y61d372ccc81e78df@mail.gmail.com> <005401c811d4$ab473a50$82a723c0@atlanta.polycom.com> Message-ID: <3c3e3fca0710181528q564005d2o1f654e450c0575bd@mail.gmail.com> On 10/18/07, Stephen Sprunk wrote: > Thus spake "William Herrin" > > I would suggest that the more complex the formula, the less likely it > > will be perceived as fair. Thus we seek the fairest SIMPLE formula. > > > > For example, does ANY US taxpayer consider the income tax fair? Yet > > the whole point of the vastly complex deductions was to make it fair. > > Is the goal to _be_ fair or to _appear_ fair? Stephen, Neither. The goal is to be _wise_. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From stephen at sprunk.org Thu Oct 18 18:47:47 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 18 Oct 2007 17:47:47 -0500 Subject: [ppml] IPv6 PI to legacy IPv4 holders References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> Message-ID: <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> Thus spake > I propose adding one additional condition under which an organization > would be eligible for receiving an IPv6 PI allocation from ARIN: > > The organization currently has been assigned an ASN and is actively > using it. The problem with that is that it's trivial to get an ASN; effectively setting the bar for PIv6 space to "anyone who wants it". While one can debate how low the bar should be (and such debate comes up regularly), I cannot support removing the bar entirely. > The rationale is, if an organization has an ASN, they are actively > involved in multihoming, which is the one situation under which > current PA assignment would not meet the needs of the organization. In v4, we require a multihomed end user to justify at least a /22 to get a direct assignment. Today, that bar is inherited for v6. There was a proposal in prior cycles to reduce that bar to a /24; it was defeated for a variety of reasons, most recently due to the perceived potential for abuse by spammers. While I find that unfortunate, I believe that is the fair and correct way to open things up so that those legacy holders with a /24 (who could justify such again today) could get PIv6 space. I am strongly opposed to giving PIv6 space to Legacy Class C holders who couldn't justify a /24 today simply because they happened to get a block back in the days when nobody was paying attention. I'm definitely opposed to giving PIv6 space to those folks and _not_ giving PIv6 space to folks who potentially have equal or better utilization today. I do thank many Legacy folks for their contribution 15+ years ago, but I've seen too many folks who swiped (not SWIP'd) a Class C from a past employer and are using it for their two-PC home network today to believe that simply being a legacy holder means that one made a meaningful contribution to the birth of the Internet or deserves any sort of special treatment, e.g. that legacy status alone justifies PIv6 space and thus a slot in the v6 DFZ. Extending that proposal to non-Legacy ASN holders (including folks who get an ASN tomorrow solely to dodge the host count requirements) is unconscionable, IMHO. > If ARIN is interested in encouraging IPv6 adoption, extending IPv6 PI > allocations to all organizations that have an actively used ASN, is the > most logical way to pursue that interest. According to the BoT, ARIN is not in the business of "encouraging" particular technologies. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From briand at ca.afilias.info Thu Oct 18 19:17:39 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 19:17:39 -0400 (EDT) Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> Message-ID: <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> I propose changes to the current text of 6.5.4.1: Currently, it reads: 6.5.4.1. Assignment address space size End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /64 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /64 when it is known that one and only one subnet is needed * /56 for small sites, those expected to need only a few subnets over the next 5 years. * /48 for larger sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. [...] ----- I propose the following as a replacement for the text: 6.5.4.1. Assignment address space size End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /120 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /120 for a very small customer with one subnet, using static assignments or DHCPv6 * /116 for a small customer with a few subnets, using static assignments or DHCPv6 * /112 for a medium size customer with a significant total number of hosts and/or subnets, using static assignments and/or DHCPv6 * /96 for large customers * /80 for very large customers, or for customers using a proposed modified version of V6-autoconf * /64 when it is known that one and only one subnet is needed, for a customer that absolutely requires either traditional IPv6 autoconfiguration, or IPv6 host Interface Identifier cryptographic generation * /60 for sites where a mix of IPv6-autoconfiguration and other address assignment techiques are required * /56 for very large sites * /52 for very, very large sites * /48 for extremely large sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. ----- The timeframe for the proposed change: immediate. The intent is to provide more current guidance, to both ARIN members, and to ARIN staff, based on available IPv6 technology, and for the encouragement of efficient assignment of IPv6 address space. Brian Dickson Afilias From sleibrand at internap.com Thu Oct 18 20:35:26 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 18 Oct 2007 18:35:26 -0600 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> Message-ID: <4717FBCE.9080608@internap.com> Brian, This change is not wise. For better or worse, IPv6 was designed with the last 64 bits as the "host" portion of the address, and there are a number of IPv6 features (such as address autoconfiguration and cryptographically generated addresses) that need those bits to function. We should not be issuing guidelines that encourage ISPs to assign addresses in such a way as to eliminate the ability to use such features. While I don't oppose allowing ISPs to issue /120's to their subscribers' cell phones if they control the technology and know what they are doing, we should *not* be encouraging such behavior as a general practice for consumer ISPs, who do not and should not know or care what kinds of devices the consumer attaches to the network. -Scott briand at ca.afilias.info wrote: > I propose changes to the current text of 6.5.4.1: > > Currently, it reads: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /64 (when only one subnet is anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /64 when it is known that one and only one subnet is needed > * /56 for small sites, those expected to need only a few subnets over > the next 5 years. > * /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > [...] > > ----- > > I propose the following as a replacement for the text: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /120 (when only one subnet is anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant total number of > hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf > * /64 when it is known that one and only one subnet is needed, for a > customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > ----- > The timeframe for the proposed change: immediate. > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > Brian Dickson > Afilias > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From briand at ca.afilias.info Thu Oct 18 21:09:44 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 21:09:44 -0400 (EDT) Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <4717FBCE.9080608@internap.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> Message-ID: <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> > Brian, > > This change is not wise. For better or worse, IPv6 was designed with > the last 64 bits as the "host" portion of the address, and there are a > number of IPv6 features (such as address autoconfiguration and > cryptographically generated addresses) that need those bits to > function. We should not be issuing guidelines that encourage ISPs to > assign addresses in such a way as to eliminate the ability to use such > features. I have given this a lot of consideration... (As far as I have been able to find out, those two are in fact the only two which depend specifically on /64.) And, in fact, this is a two-pronged approach at present. I have a proposal with the IETF to modify the relevant RFCs, so as to allow use of /80 prefixes for autoconfiguration, and to tolerate the use of /N (instead of fixed value of N=64) for the crypto stuff. BTW - the /64 comes from EUI-64, which was chosen in anticipation of the use of 64-bit MAC instead of 48-bit MAC. Only IEEE-1394 currently uses this, whereas 802.* uses 48-bit EUI-48 (aka MAC-48). So, making a change to the IPv6 specifications for autoconfiguration is something that will support all 802.* devices with hard-coded MACs - although it will still require vendor implementation and end-user upgrades. That proposal, in case anyone is interested in following or participating in the IETF discussions around it, is: draft-dickson-v6man-new-autoconf-00 and can be found at: https://datatracker.ietf.org/drafts/draft-dickson-v6man-new-autoconf/ I see what you're saying, but feel that the ability to scale IPv6 usage, beyond the short-medium term (1-3 to 3-5 years respectively), is something important to the general health of a diverse membership at ARIN (and other RIRs as well). Which is why, rather than let the IPv6 autoconfiguration spec adversely affect the global allocation policies, I have chosen to address this head-on, by pushing for the IPv6 specs to be *very slightly* changed. And, even without changing the IETF specs, I think allowing AC to drive address space wastage, is poor policy. Yes, we have lots of space, but only if we use it wisely. Encouraging end sites to use DHCPv6 instead of autoconfiguration, IMHO is a wise recommendation, and will result in more conservative levels of allocation - even while being excessively generous to end-sites. Those who allow historical elements to sway technical decisions, are as foolish as those who are ignorant of history and thus doomed to repeat it. :-) Respectfully, Brian Dickson > While I don't oppose allowing ISPs to issue /120's to their subscribers' > cell phones if they control the technology and know what they are doing, > we should *not* be encouraging such behavior as a general practice for > consumer ISPs, who do not and should not know or care what kinds of > devices the consumer attaches to the network. > > -Scott > > briand at ca.afilias.info wrote: >> I propose changes to the current text of 6.5.4.1: >> >> Currently, it reads: >> >> 6.5.4.1. Assignment address space size >> >> End-users are assigned an end site assignment from their LIR or ISP. The >> exact size of the assignment is a local decision for the LIR or ISP to >> make, using a minimum value of a /64 (when only one subnet is >> anticipated >> for the end site) up to the normal maximum of /48, except in cases of >> extra large end sites where a larger assignment can be justified. >> >> The following guidelines may be useful (but they are only guidelines): >> >> * /64 when it is known that one and only one subnet is needed >> * /56 for small sites, those expected to need only a few subnets >> over >> the next 5 years. >> * /48 for larger sites >> >> For end sites to whom reverse DNS will be delegated, the LIR/ISP should >> consider making an assignment on a nibble (4-bit) boundary to simplify >> reverse lookup delegation. >> [...] >> >> ----- >> >> I propose the following as a replacement for the text: >> >> 6.5.4.1. Assignment address space size >> >> End-users are assigned an end site assignment from their LIR or ISP. The >> exact size of the assignment is a local decision for the LIR or ISP to >> make, using a minimum value of a /120 (when only one subnet is >> anticipated >> for the end site) up to the normal maximum of /48, except in cases of >> extra large end sites where a larger assignment can be justified. >> >> The following guidelines may be useful (but they are only guidelines): >> >> * /120 for a very small customer with one subnet, using static >> assignments or DHCPv6 >> * /116 for a small customer with a few subnets, using static >> assignments or DHCPv6 >> * /112 for a medium size customer with a significant total number of >> hosts and/or subnets, using static assignments and/or DHCPv6 >> * /96 for large customers >> * /80 for very large customers, or for customers using a proposed >> modified version of V6-autoconf >> * /64 when it is known that one and only one subnet is needed, for a >> customer that absolutely requires either traditional IPv6 >> autoconfiguration, or IPv6 host Interface Identifier cryptographic >> generation >> * /60 for sites where a mix of IPv6-autoconfiguration and other >> address assignment techiques are required >> * /56 for very large sites >> * /52 for very, very large sites >> * /48 for extremely large sites >> >> For end sites to whom reverse DNS will be delegated, the LIR/ISP should >> consider making an assignment on a nibble (4-bit) boundary to simplify >> reverse lookup delegation. >> >> ----- >> The timeframe for the proposed change: immediate. >> >> The intent is to provide more current guidance, to both ARIN members, >> and to ARIN staff, based on available IPv6 technology, and for the >> encouragement of efficient assignment of IPv6 address space. >> >> Brian Dickson >> Afilias >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN >> Member Services >> Help Desk at info at arin.net if you experience any issues. >> > From sleibrand at internap.com Thu Oct 18 21:22:35 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Thu, 18 Oct 2007 19:22:35 -0600 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> Message-ID: <471806DB.2020907@internap.com> Brian, If you can get the protocol experts at the IETF to agree to your autoconf change, then I'd consider revising the guidelines to suggest reassigning prefixes longer than /64 to end sites. Until then, I for one don't feel like I'm enough of a protocol expert to override their guidance on the subject. -Scott P.S. As a general rule, please try to keep things simple, unless there's a really good reason to add complexity. That's a good principle to follow in engineering, but it's also necessary when making policy. briand at ca.afilias.info wrote: >> Brian, >> >> This change is not wise. For better or worse, IPv6 was designed with >> the last 64 bits as the "host" portion of the address, and there are a >> number of IPv6 features (such as address autoconfiguration and >> cryptographically generated addresses) that need those bits to >> function. We should not be issuing guidelines that encourage ISPs to >> assign addresses in such a way as to eliminate the ability to use such >> features. >> > > I have given this a lot of consideration... > (As far as I have been able to find out, those two are in fact the only > two which depend specifically on /64.) > > And, in fact, this is a two-pronged approach at present. > > I have a proposal with the IETF to modify the relevant RFCs, so as to > allow use of /80 prefixes for autoconfiguration, and to tolerate the use > of /N (instead of fixed value of N=64) for the crypto stuff. > > BTW - the /64 comes from EUI-64, which was chosen in anticipation of the > use of 64-bit MAC instead of 48-bit MAC. Only IEEE-1394 currently uses > this, whereas 802.* uses 48-bit EUI-48 (aka MAC-48). So, making a change > to the IPv6 specifications for autoconfiguration is something that will > support all 802.* devices with hard-coded MACs - although it will still > require vendor implementation and end-user upgrades. > > That proposal, in case anyone is interested in following or participating > in the IETF discussions around it, is: > > draft-dickson-v6man-new-autoconf-00 > > and can be found at: > > https://datatracker.ietf.org/drafts/draft-dickson-v6man-new-autoconf/ > > I see what you're saying, but feel that the ability to scale IPv6 usage, > beyond the short-medium term (1-3 to 3-5 years respectively), is something > important to the general health of a diverse membership at ARIN (and other > RIRs as well). > > Which is why, rather than let the IPv6 autoconfiguration spec adversely > affect the global allocation policies, I have chosen to address this > head-on, by pushing for the IPv6 specs to be *very slightly* changed. > > And, even without changing the IETF specs, I think allowing AC to drive > address space wastage, is poor policy. Yes, we have lots of space, but > only if we use it wisely. Encouraging end sites to use DHCPv6 instead > of autoconfiguration, IMHO is a wise recommendation, and will result > in more conservative levels of allocation - even while being excessively > generous to end-sites. > > Those who allow historical elements to sway technical decisions, are > as foolish as those who are ignorant of history and thus doomed to > repeat it. :-) > > Respectfully, > > Brian Dickson > >> While I don't oppose allowing ISPs to issue /120's to their subscribers' >> cell phones if they control the technology and know what they are doing, >> we should *not* be encouraging such behavior as a general practice for >> consumer ISPs, who do not and should not know or care what kinds of >> devices the consumer attaches to the network. >> >> -Scott >> >> briand at ca.afilias.info wrote: >> >>> I propose changes to the current text of 6.5.4.1: >>> >>> Currently, it reads: >>> >>> 6.5.4.1. Assignment address space size >>> >>> End-users are assigned an end site assignment from their LIR or ISP. The >>> exact size of the assignment is a local decision for the LIR or ISP to >>> make, using a minimum value of a /64 (when only one subnet is >>> anticipated >>> for the end site) up to the normal maximum of /48, except in cases of >>> extra large end sites where a larger assignment can be justified. >>> >>> The following guidelines may be useful (but they are only guidelines): >>> >>> * /64 when it is known that one and only one subnet is needed >>> * /56 for small sites, those expected to need only a few subnets >>> over >>> the next 5 years. >>> * /48 for larger sites >>> >>> For end sites to whom reverse DNS will be delegated, the LIR/ISP should >>> consider making an assignment on a nibble (4-bit) boundary to simplify >>> reverse lookup delegation. >>> [...] >>> >>> ----- >>> >>> I propose the following as a replacement for the text: >>> >>> 6.5.4.1. Assignment address space size >>> >>> End-users are assigned an end site assignment from their LIR or ISP. The >>> exact size of the assignment is a local decision for the LIR or ISP to >>> make, using a minimum value of a /120 (when only one subnet is >>> anticipated >>> for the end site) up to the normal maximum of /48, except in cases of >>> extra large end sites where a larger assignment can be justified. >>> >>> The following guidelines may be useful (but they are only guidelines): >>> >>> * /120 for a very small customer with one subnet, using static >>> assignments or DHCPv6 >>> * /116 for a small customer with a few subnets, using static >>> assignments or DHCPv6 >>> * /112 for a medium size customer with a significant total number of >>> hosts and/or subnets, using static assignments and/or DHCPv6 >>> * /96 for large customers >>> * /80 for very large customers, or for customers using a proposed >>> modified version of V6-autoconf >>> * /64 when it is known that one and only one subnet is needed, for a >>> customer that absolutely requires either traditional IPv6 >>> autoconfiguration, or IPv6 host Interface Identifier cryptographic >>> generation >>> * /60 for sites where a mix of IPv6-autoconfiguration and other >>> address assignment techiques are required >>> * /56 for very large sites >>> * /52 for very, very large sites >>> * /48 for extremely large sites >>> >>> For end sites to whom reverse DNS will be delegated, the LIR/ISP should >>> consider making an assignment on a nibble (4-bit) boundary to simplify >>> reverse lookup delegation. >>> >>> ----- >>> The timeframe for the proposed change: immediate. >>> >>> The intent is to provide more current guidance, to both ARIN members, >>> and to ARIN staff, based on available IPv6 technology, and for the >>> encouragement of efficient assignment of IPv6 address space. >>> >>> Brian Dickson >>> Afilias >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN >>> Public Policy >>> Mailing List (PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN >>> Member Services >>> Help Desk at info at arin.net if you experience any issues. >>> >>> > > > From briand at ca.afilias.info Thu Oct 18 22:25:59 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Thu, 18 Oct 2007 22:25:59 -0400 (EDT) Subject: [ppml] Use of HD ratios (esp. 0.94) In-Reply-To: <471806DB.2020907@internap.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> <471806DB.2020907@internap.com> Message-ID: <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> Having read more about HD ratios (RFC 3194), and re-reading the current NPRM, and proposed changes, I think there needs to be further discussion on the matter. Let me first present some math stuff, since it was confusing to me, and I have three math degrees from the University of Waterloo (;-)): HD = log(things)/log(max-things) Which, after much complicated stuff, gets rearranged into: things = (max-things)^HD But, we are used to max-things of 2^N, so we get: things = (2^N)^HD = 2^(N*HD) Here's where I think we stared getting messed up: The current and proposed texts, all are using, not true "HD", but rather, HD-56, where the base unit of measure is /56, or 2^56. In terms of allocation efficiency, and utilization requirements, using HD-56 instead of some other kind of HD, unfairly penalizes those who act as good "Internet citizens", and allocate longer prefixes to customers. Consider two comparative situations. ISP A, gives out /48's, and ISP B, who gives out /56's. Each does so from an initial allocation of /32. ISP A can give out at most 65536 prefixes. ISP B can give out ~16M. The respective thresholds would be ~24K vs ~6M. However, at review time, both have a threshold of 36.9% utilization. The presumption is that ISP A's assignments are 100% utilized. If instead, the HD ratio was based on a value related to the prefix sizes used in allocations, then ISP A would have to have a utilization level of 51.4%. I don't know for sure how we should handle VLSM assignment space rather than fixed-size assignments. But I do believe we should be rewarding efficient use, by basing the HD ratio on the base assignment size. What do folks think? Or am I mis-interpreting how HD-56 is to be used? Are we supposed to count each object, regardless of size, as 1, and the utilization percentage would then be based on object count vs threshold values? If the latter is the case, then a /32 would only be able to give out at most ~47K /48's, and the rest would have to be /56 or longer, for a total of ~6M, before justifying another /32. Can I ask anyone from ARIN to comment on the *intent* of HD and HD-56, for evaluating IPv6 assignments? Brian Dickson From randy at psg.com Thu Oct 18 22:57:58 2007 From: randy at psg.com (Randy Bush) Date: Thu, 18 Oct 2007 20:57:58 -0600 Subject: [ppml] Use of HD ratios (esp. 0.94) In-Reply-To: <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> <471806DB.2020907@internap.com> <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> Message-ID: <47181D36.8080101@psg.com> > The current and proposed texts, all are using, not true "HD", but > rather, HD-56, where the base unit of measure is /56, or 2^56. this is the opposite of an accident. the point is to normalize to a common measure. > In terms of allocation efficiency, and utilization requirements, using > HD-56 instead of some other kind of HD, unfairly penalizes those who > act as good "Internet citizens", and allocate longer prefixes to customers. s/good "Internet citizens"/lir which has a different business model or different customer base/ arin hostmasters can look at both and see if one is merely allocating inefficiently or actually has a different customer need distribution. that's why we have humans as hostmasters not equations. randy From mack at exchange.alphared.com Thu Oct 18 23:29:56 2007 From: mack at exchange.alphared.com (mack) Date: Thu, 18 Oct 2007 22:29:56 -0500 Subject: [ppml] PPML Digest, Vol 28, Issue 51 In-Reply-To: References: Message-ID: <859D2283FD04CA44986CC058E06598F84B1DAC198F@exchange4.exchange.alphared.local> This is not workable for a number of reasons. 1) It is in direct conflict with current RFCs. 2) It is in direct conflict with current auto-configuration implementations. 3) It breaks under at least one major vendors implementation of IPv6 when certain functionality is used. Quote from vendor documentation: If the compress mode is on, the IPv6 address is compressed similarly to the EUI-64 compression method (removal of bits [39:24]) to allow for the Layer 4 port information to be used as part of the key used to look up the QoS TCAM, but Layer 3 information is lost. In practice the loss of data in these bits is inconsequential as they are a specific value (0xFFFE) or manually configured. Manual configuration can set these to a known constant. I personally use (0x0000 or 0xFFFE). Any change that significantly breaks current hardware under a common configuration is a very bad idea. -- LR Mack McBride Network Administrator Alpha Red, Inc. > -----Original Message----- > Message: 1 > Date: Thu, 18 Oct 2007 19:17:39 -0400 (EDT) > From: briand at ca.afilias.info > Subject: [ppml] IPv6 assignment - proposal for change to nrpm > To: "ARIN PPML" > Message-ID: > <50228.192.35.166.161.1192749459.squirrel at look.libertyrms.com> > Content-Type: text/plain;charset=iso-8859-1 > > I propose changes to the current text of 6.5.4.1: > > Currently, it reads: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. > The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /64 (when only one subnet is > anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /64 when it is known that one and only one subnet is needed > * /56 for small sites, those expected to need only a few subnets > over > the next 5 years. > * /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > [...] > > ----- > > I propose the following as a replacement for the text: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. > The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /120 (when only one subnet is > anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant total number > of > hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf > * /64 when it is known that one and only one subnet is needed, for > a > customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > ----- > The timeframe for the proposed change: immediate. > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > Brian Dickson > Afilias From michael.dillon at bt.com Fri Oct 19 10:11:02 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 19 Oct 2007 15:11:02 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com><49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com><008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com><50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com><4717FBCE.9080608@internap.com> <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> Message-ID: > I have given this a lot of consideration... > (As far as I have been able to find out, those two are in > fact the only two which depend specifically on /64.) There are also a couple of special bits in the last 64 bits which cannot be set arbitrarily. And it breaks the basic model which gives end users enough spare bits to grow their networks without changing their allocation. > I have a proposal with the IETF to modify the relevant RFCs, > so as to allow use of /80 prefixes for autoconfiguration, and > to tolerate the use of /N (instead of fixed value of N=64) > for the crypto stuff. But it is only a proposal and it has met with a flurry of rejections similar to what you have seen here. In addition, the IETF has pointed out that it really is not prepared to make such a fundamental change to IPv6 at this time, and in fact the IETF has closed down the IPv6 working group and chartered a new IPv6 Maintenance working group which will only deal with maintenance issues. >From an ARIN perspective, we should not do anything until and if the IETF has completed its work. And, since there is no shortage of IPv6 addresses, we should not be stingy with them right now. --Michael Dillon From michael.dillon at bt.com Fri Oct 19 10:16:40 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 19 Oct 2007 15:16:40 +0100 Subject: [ppml] Use of HD ratios (esp. 0.94) In-Reply-To: <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com><49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com><008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com><50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com><4717FBCE.9080608@internap.com><50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com><471806DB.2020907@internap.com> <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> Message-ID: > In terms of allocation efficiency, and utilization requirements, using > HD-56 instead of some other kind of HD, unfairly penalizes > those who act as good "Internet citizens", and allocate > longer prefixes to customers. Those are BAD Internet citizens who are not following the basic architecture of IPv6 which attempts to give each level of allocation, more addresses than they could ever need. /48 does that for end user networks, and it can be argued that /56 maintains that for residential end users. --Michael Dillon From arin-contact at dirtside.com Fri Oct 19 11:42:42 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 19 Oct 2007 11:42:42 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <4717FBCE.9080608@internap.com> References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> Message-ID: <3c3e3fca0710190842w4b1e2a3eldc37d736ca631856@mail.gmail.com> On 10/18/07, Scott Leibrand wrote: > This change is not wise. For better or worse, IPv6 was designed with > the last 64 bits as the "host" portion of the address, and there are a > number of IPv6 features (such as address autoconfiguration and > cryptographically generated addresses) that need those bits to > function. We should not be issuing guidelines that encourage ISPs to > assign addresses in such a way as to eliminate the ability to use such > features. Scott, I concur. ARIN should not offer guidelines which conflict with the IETF's adoption of /64 as the standard subnet mask. On the other hand, we shouldn't discourage such use either. I've heard more than a few excellent arguments that the adoption of /64 as the netmask was ill advised and should not be followed. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From jlewis at lewis.org Fri Oct 19 12:53:01 2007 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 19 Oct 2007 12:53:01 -0400 (EDT) Subject: [ppml] Use of HD ratios (esp. 0.94) In-Reply-To: References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com><49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com><008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com><50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com><4717FBCE.9080608@internap.com><50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com><471806DB.2020907@internap.com> <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> Message-ID: On Fri, 19 Oct 2007 michael.dillon at bt.com wrote: >> In terms of allocation efficiency, and utilization requirements, using >> HD-56 instead of some other kind of HD, unfairly penalizes >> those who act as good "Internet citizens", and allocate >> longer prefixes to customers. > > Those are BAD Internet citizens who are not following the basic > architecture of IPv6 which attempts to give each level of allocation, > more addresses than they could ever need. /48 does that for end user > networks, and it can be argued that /56 maintains that for residential > end users. After years of having to be conservative with IPv4 space, I think its just hard for some of us to wrap our heads around the idea of giving customers such astronomical numbers of IPv6 IPs. 2^64, if you don't do the silly autoconf that wastes half the IPv6 space, is just an insane number of IPs. 18.4 trillion million if I did the math right. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From stephen at sprunk.org Fri Oct 19 12:54:49 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Fri, 19 Oct 2007 11:54:49 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com><49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com><008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com><50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com><4717FBCE.9080608@internap.com> <3c3e3fca0710190842w4b1e2a3eldc37d736ca631856@mail.gmail.com> Message-ID: <008f01c81272$b0b0af00$dae9020a@atlanta.polycom.com> Thus spake "William Herrin" > On 10/18/07, Scott Leibrand wrote: >> This change is not wise. For better or worse, IPv6 was designed with >> the last 64 bits as the "host" portion of the address, and there are a >> number of IPv6 features (such as address autoconfiguration and >> cryptographically generated addresses) that need those bits to >> function. We should not be issuing guidelines that encourage ISPs to >> assign addresses in such a way as to eliminate the ability to use such >> features. > > I concur. ARIN should not offer guidelines which conflict with the > IETF's adoption of /64 as the standard subnet mask. On the other > hand, we shouldn't discourage such use either. I've heard more than > a few excellent arguments that the adoption of /64 as the netmask > was ill advised and should not be followed. It was, perhaps, ill-advised, but it _is_ the standard and there doesn't appear to be any consensus within the IETF for changing it. There is no technical or political justification for us overriding the IETF in this case. unlike in the case of PIv6, so we should continue to follow that recommendation until the IETF changes it. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From gih at apnic.net Fri Oct 19 20:51:09 2007 From: gih at apnic.net (Geoff Huston) Date: Sat, 20 Oct 2007 10:51:09 +1000 Subject: [ppml] Use of HD ratios (esp. 0.94) In-Reply-To: <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> <471806DB.2020907@internap.com> <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> Message-ID: <471950FD.1030208@apnic.net> Brian, [...] > However, at review time, both have a threshold of 36.9% utilization. > The presumption is that ISP A's assignments are 100% utilized. The intent of the use of /56 in the efficiency metric was to provide a common mechanism to measure the efficiency of end-site prefix assignments irrespective of the size of individual end site assignments, and explicitly not to measure the efficiency of address assignments to hosts. i.e the presumption in terms of this end site prefix efficiency measure is that the assignments with end-sites are not the subject of the review. regards, Geoff Huston From gih at apnic.net Fri Oct 19 20:56:00 2007 From: gih at apnic.net (Geoff Huston) Date: Sat, 20 Oct 2007 10:56:00 +1000 Subject: [ppml] Use of HD ratios (esp. 0.94) In-Reply-To: <471950FD.1030208@apnic.net> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> <471806DB.2020907@internap.com> <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> <471950FD.1030208@apnic.net> Message-ID: <47195220.5090704@apnic.net> Geoff Huston wrote: > Brian, > > > [...] > >> However, at review time, both have a threshold of 36.9% utilization. >> The presumption is that ISP A's assignments are 100% utilized. > > > The intent of the use of /56 in the efficiency metric was to provide a > common mechanism to measure the efficiency of end-site prefix > assignments irrespective of the size of individual end site assignments, > and explicitly not to measure the efficiency of address assignments to > hosts. > > i.e the presumption in terms of this end site prefix efficiency measure > is that the assignments with end-sites are not the subject of the review. s/with/within/ apologies for my poor brain / hand coordination! Geoff From rw at firstpr.com.au Fri Oct 19 22:51:05 2007 From: rw at firstpr.com.au (Robin Whittle) Date: Sat, 20 Oct 2007 12:51:05 +1000 Subject: [ppml] Maps of IPv4 ping responses and BGP advertisements Message-ID: <47196D19.105@firstpr.com.au> The Information Sciences Institute of the University of Southern California recently pinged every advertised IPv4 address - and printed a map with one 600DPI pixel per IP address. http://www.isi.edu/ant/address/ They found about 103 million ping-responsive hosts, which is similar to the 108 million figure I estimated by extrapolating my random ping survey results from earlier this year. My survey concentrated on the widely different ping-response rates, and statistical distribution of these, in prefixes of different lengths. http://www.firstpr.com.au/ip/host-density-per-prefix/ There are detailed maps, month-by-month, of the IPv4 address space down to /24 resolution showing how much has been advertised and in what prefix length: http://maps.measurement-factory.com/ http://maps.measurement-factory.com/gallery/Routeviews/ I read about these two mapping projects via the Mapping-Cyberspace discussion list www.cybergeography.org/discussion.html . - Robin From kmedcalf at dessus.com Sat Oct 20 13:31:12 2007 From: kmedcalf at dessus.com (Keith Medcalf) Date: Sat, 20 Oct 2007 13:31:12 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> Message-ID: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> This is a very bad idea. The requirement that a "minumum" end-user site assignment of a /64 is the only thing that will permit many Legacy /24 holders (such as myself) who are single-homed use IPv6 at all. Either you have to require a minimum /64 PA end-user delegation by ISPs *or* you have to make it so that anyone who wants a /64 can qualify for a PIv6 /64 (or larger) direct assignment. The purpose of ARIN is *not* to ensure the profitability of carriers and ISPs by imposing unreasonable limits on the availability and usability of the network. Therefore I would very actively and vocally oppose any such attempted change to policy. > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of briand at ca.afilias.info > Sent: Thursday, 18 October, 2007 19:18 > To: ARIN PPML > Subject: [ppml] IPv6 assignment - proposal for change to nrpm > > I propose changes to the current text of 6.5.4.1: > > Currently, it reads: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR > or ISP. The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /64 (when only one subnet is > anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /64 when it is known that one and only one subnet is needed > * /56 for small sites, those expected to need only a few > subnets over > the next 5 years. > * /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the > LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > [...] > > ----- > > I propose the following as a replacement for the text: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR > or ISP. The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /120 (when only one subnet > is anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant > total number of > hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf > * /64 when it is known that one and only one subnet is > needed, for a > customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the > LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > ----- > The timeframe for the proposed change: immediate. > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > Brian Dickson > Afilias > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From briand at ca.afilias.info Sat Oct 20 14:36:31 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Sat, 20 Oct 2007 14:36:31 -0400 (EDT) Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> Message-ID: <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> > > This is a very bad idea. The requirement that a "minumum" end-user site > assignment of a /64 is the only thing that will permit many Legacy /24 > holders (such as myself) who are single-homed use IPv6 at all. I'm interested in understanding this proposition. Can you explain why you believe /24 Legacy holders would not be able to use, for example, a /120? Or any other prefix length in between /64 and /120? I suggest /120, because as a /24 holder, the only viable addressing options are static, and DHCP. And for a /24, there are only 8 bits of host available for assignment. Static and DHCP are both supported in IPv6, and 8 bits of host are obviously supported with a /120. This is not to say, that if you present an addressing plan that shows you need 24 bits of address space (for whatever reason), that they would not be able to, or would not be willing to, assign a /104. > Either you have to require a minimum /64 PA end-user delegation by ISPs > *or* you have to make it so that anyone who wants a /64 can qualify for a > PIv6 /64 (or larger) direct assignment. What is it, specifically, about /64 that you feel is the minimum requirement, not just for you, but for *everyone*? And besides, what makes you think that the existence of a smaller minimum, will in any way affect the *maximum* size that an ISP will willingly delegate to and end-site or end-user? I think, given the vast amount of space any ISP will have, will encourage the adoption of customer-responsive allocation policies, e.g. if you have a given block /N from one ISP, that every other ISP you connect to will be happy to give you a block of size /N, unless N << 64 - in which case you would probably want to provide some kind of justification. The purpose of recommendations is to give ISPs who don't have a handle on IPv6, a rough idea on how many ways their customers *can* use it, and what kinds of request they should expect to see. If neither the ISP nor the ISP's customer has much IPv6 experience, the recommendations are intended to give both an idea of what others in the industry generally do. And the intent of *that*, is so that an end-user, in requesting space from a second ISP (who is more IPv6-experienced) won't get any unpleasant surprises. It is, in effect, an early "best common practices" for a period in time before there are *any* common practices, good or bad - with the intent of ensuring that things don't go collectively to the dogs from day one. > The purpose of ARIN is *not* to ensure the profitability of carriers and > ISPs by imposing unreasonable limits on the availability and usability of > the network. That is true. However, I think you would agree that anything which is bad for *all* ISPs and carriers, is bad for the Internet. And, for good or bad, ARIN does what its members tell it to. Those members generally need to work towards consensus, and all benefit from policies which benefit most (if not all) and harm none. > Therefore I would very actively and vocally oppose any such attempted > change to policy. I see it as a clarification of policy, rather than a change. The policy is quite old, and predates completed specification and available implementations of the likes of DHCPv6. But I, like most participating on PPML, am interested in hearing the voices of those with whom we disagree - since without dialog, there can not be consensus. Brian >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of briand at ca.afilias.info >> Sent: Thursday, 18 October, 2007 19:18 >> To: ARIN PPML >> Subject: [ppml] IPv6 assignment - proposal for change to nrpm >> >> I propose changes to the current text of 6.5.4.1: >> >> Currently, it reads: >> >> 6.5.4.1. Assignment address space size >> >> End-users are assigned an end site assignment from their LIR >> or ISP. The >> exact size of the assignment is a local decision for the LIR or ISP to >> make, using a minimum value of a /64 (when only one subnet is >> anticipated >> for the end site) up to the normal maximum of /48, except in cases of >> extra large end sites where a larger assignment can be justified. >> >> The following guidelines may be useful (but they are only guidelines): >> >> * /64 when it is known that one and only one subnet is needed >> * /56 for small sites, those expected to need only a few >> subnets over >> the next 5 years. >> * /48 for larger sites >> >> For end sites to whom reverse DNS will be delegated, the >> LIR/ISP should >> consider making an assignment on a nibble (4-bit) boundary to simplify >> reverse lookup delegation. >> [...] >> >> ----- >> >> I propose the following as a replacement for the text: >> >> 6.5.4.1. Assignment address space size >> >> End-users are assigned an end site assignment from their LIR >> or ISP. The >> exact size of the assignment is a local decision for the LIR or ISP to >> make, using a minimum value of a /120 (when only one subnet >> is anticipated >> for the end site) up to the normal maximum of /48, except in cases of >> extra large end sites where a larger assignment can be justified. >> >> The following guidelines may be useful (but they are only guidelines): >> >> * /120 for a very small customer with one subnet, using static >> assignments or DHCPv6 >> * /116 for a small customer with a few subnets, using static >> assignments or DHCPv6 >> * /112 for a medium size customer with a significant >> total number of >> hosts and/or subnets, using static assignments and/or DHCPv6 >> * /96 for large customers >> * /80 for very large customers, or for customers using a proposed >> modified version of V6-autoconf >> * /64 when it is known that one and only one subnet is >> needed, for a >> customer that absolutely requires either traditional IPv6 >> autoconfiguration, or IPv6 host Interface Identifier cryptographic >> generation >> * /60 for sites where a mix of IPv6-autoconfiguration and other >> address assignment techiques are required >> * /56 for very large sites >> * /52 for very, very large sites >> * /48 for extremely large sites >> >> For end sites to whom reverse DNS will be delegated, the >> LIR/ISP should >> consider making an assignment on a nibble (4-bit) boundary to simplify >> reverse lookup delegation. >> >> ----- >> The timeframe for the proposed change: immediate. >> >> The intent is to provide more current guidance, to both ARIN members, >> and to ARIN staff, based on available IPv6 technology, and for the >> encouragement of efficient assignment of IPv6 address space. >> >> Brian Dickson >> Afilias >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml Please contact >> the ARIN Member Services >> Help Desk at info at arin.net if you experience any issues. >> > > > > From Lee.Howard at stanleyassociates.com Sat Oct 20 20:25:27 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Sat, 20 Oct 2007 20:25:27 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB40758584F@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Keith Medcalf > Sent: Saturday, October 20, 2007 1:31 PM > To: briand at ca.afilias.info > Cc: ppml at arin.net > Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > > This is a very bad idea. The requirement that a "minumum" > end-user site assignment of a /64 is the only thing that will > permit many Legacy /24 holders (such as myself) who are > single-homed use IPv6 at all. Please clarify. I don't understand the correlation between /64, Legacy /24, and single-homed. > Either you have to require a minimum /64 PA end-user > delegation by ISPs *or* you have to make it so that anyone > who wants a /64 can qualify for a PIv6 /64 (or larger) direct > assignment. Why? > The purpose of ARIN is *not* to ensure the profitability of > carriers and ISPs by imposing unreasonable limits on the > availability and usability of the network. True. Are you suggesting that this proposal does that? In what way? > Therefore I would very actively and vocally oppose any such > attempted change to policy. *Thank you* for clearly stating your position on a proposal! Lee From mksmith at adhost.com Sun Oct 21 01:49:01 2007 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Sat, 20 Oct 2007 22:49:01 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> References: <47129B68.3070009@arin.net><05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy><49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com><49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com><008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> Message-ID: <17838240D9A5544AAA5FF95F8D5203160297F98B@ad-exh01.adhost.lan> Hello Brian: I oppose this modification. I concur with others that the /64 is presently inviolate because of present standards. In addition, I don't think there is a need for such granularity when the initial allocation by ARIN is a /32. Regards, Mike > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > briand at ca.afilias.info > Sent: Thursday, October 18, 2007 5:18 PM > To: ARIN PPML > Subject: [ppml] IPv6 assignment - proposal for change to nrpm > > I propose changes to the current text of 6.5.4.1: > > Currently, it reads: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. > The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /64 (when only one subnet is > anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /64 when it is known that one and only one subnet is needed > * /56 for small sites, those expected to need only a few subnets > over > the next 5 years. > * /48 for larger sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > [...] > > ----- > > I propose the following as a replacement for the text: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. > The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /120 (when only one subnet is > anticipated > for the end site) up to the normal maximum of /48, except in cases of > extra large end sites where a larger assignment can be justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant total number > of > hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf > * /64 when it is known that one and only one subnet is needed, for > a > customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > ----- > The timeframe for the proposed change: immediate. > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > Brian Dickson > Afilias > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From arin-contact at dirtside.com Sun Oct 21 01:59:58 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 21 Oct 2007 01:59:58 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> Message-ID: <3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> On 10/20/07, briand at ca.afilias.info wrote: > > This is a very bad idea. The requirement that a "minumum" end-user site > > assignment of a /64 is the only thing that will permit many Legacy /24 > > holders (such as myself) who are single-homed use IPv6 at all. > > I'm interested in understanding this proposition. > Can you explain why you believe /24 Legacy holders would not be able to > use, for example, a /120? Brian, Given that we could assign a /48 to every individual who has ever lived without filling a /14, and given that the IETF has defined standards that only work properly when the subnet mask is /64, I'm curious why you'd want to buck the IETF on the recommendation against assigning prefixes longer than /64? Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From briand at ca.afilias.info Sun Oct 21 22:08:25 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Sun, 21 Oct 2007 22:08:25 -0400 (EDT) Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> <3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> Message-ID: <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> > On 10/20/07, briand at ca.afilias.info wrote: >> > This is a very bad idea. The requirement that a "minumum" end-user >> site >> > assignment of a /64 is the only thing that will permit many Legacy /24 >> > holders (such as myself) who are single-homed use IPv6 at all. >> >> I'm interested in understanding this proposition. >> Can you explain why you believe /24 Legacy holders would not be able to >> use, for example, a /120? > > Brian, > > Given that we could assign a /48 to every individual who has ever > lived without filling a /14, and given that the IETF has defined > standards that only work properly when the subnet mask is /64, I'm > curious why you'd want to buck the IETF on the recommendation against > assigning prefixes longer than /64? I'll answer your question in good faith, but ask you *again*, to answer my basic question: What, if anything, do you believe forms a *requirement* that a Legacy /24 cannot use IPv6, unless they receive a /64? To answer your question(s): (1) The IETF does not recommend use of specific prefix lengths; (2) The IETF lists a set of RFCs that must be *supported* by an end node, for it to be considered a complete IPv6 implementation (2.1) However, those RFCs encompass a number of technologies which, while supported by an end node, are incompatible, e.g. you need to pick one, or do either/or. (2.2) The IETF does not make recommendations of which node configurations are preferable, or which prefix lengths are mandatory (3) The IETF lists a few methods for constructing Interface Identifiers. Currently, those are 64 bits in size. (3.1) However, the other RFCs only *implicitly* make reference to the size of the Interface Identifer, e.g. as N bits and 128-N bits. (3.2) Specifically, Link Local addresses are constructed as right-aligned Interface Identifier, zero-padded, bitwise "OR"-ed with 0xFE80::. And, the Link Local address does *not* have a prefix length (!!) The reason I encourage use of a smaller prefix size than /64, is that the overall scalability of *all* of the ISPs who have full routing tables, is dramatically affected by the likelyhood of *any* ISPs getting more than one PA block for giving out to customers. And the PA block usage is driven by both the ability to aggregate internally, and the size of blocks assigned to customers. With a /32, giving out /48's and doing internal aggregation, a new block may be needed in as little as 20k assignments - and under current policies, would be a perfectly acceptable basis for requesting an additional block. The error is in taking the number of /N blocks that fit in a /M blocks, and presuming that they can be assigned in a completely efficient manner, effectively serialized assignments. This is not the case in real world allocation environments, and particularly not when internal aggregation is a very important consideration. (See the IETF draft on the IETF web site, search for "dickson" in the draft tracker, and read the whole thing, to understand what I'm talking about, and to see examples of aggregation and allocation techniques.) So, to summarize: (1) I'm concurrently asking ARIN to be more forward thinking in their own allocation policies, and the policies the recommend to their members, and also working on the IETF to change the standards for IPv6, to better accommodate the real-world needs as opposed to the "1997 future world need" that the IETF originally built IPng around (later renamed IPv6); (2) The IETF does not have allocation policies or recommendation, so there are none such to buck; (3) I am not an ISP, nor do I work for one, and have no vested interest in this other than to educate those who are ISPs or work for them, that they are headed into a potential IPv6 crib-death scenario, and that given the perceived need for IPv6 to co-exist with IPv4, to keep the Internet as a going concern, that such a crib-death would be very, very bad. Static assignments and DHCPv6 assignments, for prefixes > /64, are not only possible, but fully compatible with the IETF specifications. The real question is, if an end-site can implement a long-term plan, using those two technologies, and based on their long-term needs (10 or 20 year is entirely reasonable), request a huge IPv6 block, such as a /80, why would they not give consideration to making a request for a /80? (Hint: at the current time, the OUI portion of MAC-48 is about 0.1% used. This means that all the Ethernet devices ever made, number much less than 10^22, or a /90. Even if the number of Ethernet devices increases by 1000, the will still be able to be numbered at layer 2, with MAC-48, and would all be able to be assigned IPv6 addresses from within a single /80.) BTW - I'm trying to avoid getting into one-on-one discussions on technical aspect of this thread. If anyone sees issues discussed by anyone else, please read my response to that, rather than re-raise it. I may privately point you to the other thread, but won't beat this to death more than once per technical item. :-) Brian > Regards, > Bill Herrin > > -- > William D. Herrin herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. Web: > Falls Church, VA 22042-3004 > From arin-contact at dirtside.com Sun Oct 21 22:52:06 2007 From: arin-contact at dirtside.com (William Herrin) Date: Sun, 21 Oct 2007 22:52:06 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> <3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> Message-ID: <3c3e3fca0710211952q49e2a8ffx9773b84bd94cf2cf@mail.gmail.com> On 10/21/07, briand at ca.afilias.info wrote: > What, if anything, do you believe forms a *requirement* that a Legacy > /24 cannot use IPv6, unless they receive a /64? Brian, I think you have mistaken me for Keith Medcalf whose assertion that legacy /24 holders should receive a /64 confuses me as well. They should receive a /48 IMHO, just like every other PI assignment. That's not an engineering requirement but it is a best practice. > (1) The IETF does not recommend use of specific prefix lengths; That may come as a surprise to your compatriots in the IETF. The recommend netmask of exactly /64 on any broadcast-capable LAN has come through loud and clear. So clearly, in fact, that a number of folks are surprised to learn its a recommendation and not a requirement. > (3.2) Specifically, Link Local addresses are constructed as right-aligned > Interface Identifier, zero-padded, bitwise "OR"-ed with 0xFE80::. > And, the Link Local address does *not* have a prefix length (!!) $ ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:04:23:AC:CA:32 inet6 addr: fe80::204:23ff:feac:ca32/64 Scope:Link Note the "/64" on the autoconfigured link local address. > The reason I encourage use of a smaller prefix size than /64, is that the > overall scalability of *all* of the ISPs who have full routing tables, > is dramatically affected by the likelyhood of *any* ISPs getting more than > one PA block for giving out to customers. This is the purpose of holding the nearby space in reserve so that the ISP can simply shorten the netmask upon returning for additional addresses. With "sparse allocation" the RIR can further maximize the probability of meeting the ISP's second and subsequent requests for address space from within a block that doesn't require an additional prefix in the BGP table. None of which has anything to do with assigning user prefixes longer than /64. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Sun Oct 21 22:59:57 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 21 Oct 2007 22:59:57 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> <3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> Message-ID: <20071022025956.GB37937@ussenterprise.ufp.org> In a message written on Sun, Oct 21, 2007 at 10:08:25PM -0400, briand at ca.afilias.info wrote: > With a /32, giving out /48's and doing internal aggregation, a new block > may be needed in as little as 20k assignments - and under current policies, > would be a perfectly acceptable basis for requesting an additional block. I'm wondering how many ISP's in the ARIN region have more than 20k assignments. I'd be surprised for sure if the number was more than 500, and suspect it's under 100. Now, some of those will come back and fit in their reservation. IIRC ARIN is assigning each /32 out of a reserved /28 for that network to grow into and still take a single routing slot. That reduces the number. Also, some large networks have justified right out of the gate something larger than a /32 based on current customer counts. If that has been done properly, they will not need to come back. Thus it would seem to me the risk is small, probably well less than 500 ISP's, and likely under 100 who would need a second prefix in any reasonable amount of time. That's hardly table bloat. > Static assignments and DHCPv6 assignments, for prefixes > /64, are not only > possible, but fully compatible with the IETF specifications. However, they do preclude the use of IPv6 autoconfiguration. Now, I am not going to debate the merits of that particular protocol; but I will say as long as it is an IETF standard and in use in the community I don't support ARIN policies that would make it useless. It is for that reason I can't support any ARIN policies requiring an ISP to allocate longer than /64 prefixes. I fully support things like encouraging people to use /126's on P2P links and other economies and think it would be nice if we could find a policy mechanism to encourage that without creating unfair advantage. The bottom line is there are 26,000 ASN's in the routing system today (http://www.cidr-report.org/as2.0/), even if 10% of the prefixes handed out were too small for their networks and got a second one, that would be 28,600 prefixes in the routing table. Compared to the 239,000 today that's a huge win. Heck, even adjusted for the 4x size it would be 114,400 IPv4 Route equivilants, cutting the memory needed for a table in half. To provide a different perspective. I think we are giving away blocks that are too large. We have reinvented classful networks with the /48 and the /64. One day we will wake up and implement exactly what you suggest, using smaller networks like /120's for small LAN's. This is just like we woke up from CIDR and starting using VLSM. There's good news though, from an RIR perspective we're only giving away the equivalent of IPv4 /8's. Due to CIDR improvements most companies who got a /8 of IPv4 have never been back for more, they are still eating from that original allocation. The same will be true in IPv6, I suspect almost everyone who has a /32 will fit in it forever, as long as we wake up and do the right thing with prefix lists. But how did we get routing table bloat? The Class C swamp. Small prefixes, not aggregatable. This is exactly why we don't want ARIN giving out /64's today, or /80's, or /120's. That is how we will get routing table bloat in the future. But back to your current goal. Get the IETF to deprecate IPv6 auto-configuration; which will remove the /64 boundary as sacred. At that point I'd be willing to talk about prefixes longer than a /64 being required, until then it's premature. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From briand at ca.afilias.info Sun Oct 21 23:37:54 2007 From: briand at ca.afilias.info (briand at ca.afilias.info) Date: Sun, 21 Oct 2007 23:37:54 -0400 (EDT) Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071022025956.GB37937@ussenterprise.ufp.org> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> <3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> <20071022025956.GB37937@ussenterprise.ufp.org> Message-ID: <64505.70.53.64.10.1193024274.squirrel@look.libertyrms.com> Leo Bicknell wrote: > In a message written on Sun, Oct 21, 2007 at 10:08:25PM -0400, > briand at ca.afilias.info wrote: > Thus it would seem to me the risk is small, probably well less than > 500 ISP's, and likely under 100 who would need a second prefix in > any reasonable amount of time. That's hardly table bloat. The issue I'm trying to point out is: The consensus in the community is that dual-stack will be around for a long time, with 10 to 20 years being the predominate view. And, IPv4 prefix counts will not decrease by any significant amount during that period. Dual-stack means the combined prefix counts of IPv4 and IPv6 are the issue. Bloat of even a small amount in IPv6 may be enough to cause problems for significant numbers of ISPs who might be adversely affected at a financial level. So, if we can adopt policies which avoid causing problems for members of ARIN, when those policies do not themselves introduce problems, it would seem like a wise course of action. >> Static assignments and DHCPv6 assignments, for prefixes > /64, are not >> only >> possible, but fully compatible with the IETF specifications. > > However, they do preclude the use of IPv6 autoconfiguration. > It is for that reason I can't support any ARIN policies requiring > an ISP to allocate longer than /64 prefixes. I'm pretty sure the way I worded my proposal was the encouragement of, not the requirement of, ISPs allocating longer prefixes. I will go further in the details of what I will propose as a recommendation: that ISPs give out /64's or shorter, only when a customer *specifically* requests such with justification showing a network plan using auto-v6. It isn't a question of saying "never"; it's just a question of saying, let's not always assume auto-v6, and instead ask customers about their needs/plans. (Ideally, this would be a nice intro/wiki kind of thing.) > But back to your current goal. Get the IETF to deprecate IPv6 > auto-configuration; which will remove the /64 boundary as sacred. > At that point I'd be willing to talk about prefixes longer than a > /64 being required, until then it's premature. I'm working on them. Having support from the operator community, which says in principal, "We endorse the removal of /64 as a sacred boundary, and would like to see whatever revisions are needed to accomplish that implemented, ASAP", would go a long way to achieving that result. Like ARIN, the IETF is receptive to overwhelming support for proposals. :-) Brian From stephen at sprunk.org Sun Oct 21 23:50:17 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Sun, 21 Oct 2007 22:50:17 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com><64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com><3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> Message-ID: <049f01c81462$e8b78170$6501a8c0@atlanta.polycom.com> Thus spake >> Given that we could assign a /48 to every individual who has ever >> lived without filling a /14, and given that the IETF has defined >> standards that only work properly when the subnet mask is /64, I'm >> curious why you'd want to buck the IETF on the recommendation >> against assigning prefixes longer than /64? > > I'll answer your question in good faith, but ask you *again*, to answer > my basic question: > > What, if anything, do you believe forms a *requirement* that a Legacy > /24 cannot use IPv6, unless they receive a /64? Because, according to the IETF, a single subnet should be a /64. Even folks who are using DHCPv6 are assigning /64s, from what I've seen. > To answer your question(s): > (1) The IETF does not recommend use of specific prefix lengths; Actually, it did. Please see RFC 3177. > (3) The IETF lists a few methods for constructing Interface Identifiers. > Currently, those are 64 bits in size. > (3.1) However, the other RFCs only *implicitly* make reference to > the size of the Interface Identifer, e.g. as N bits and 128-N bits. > (3.2) Specifically, Link Local addresses are constructed as right- > aligned Interface Identifier, zero-padded, bitwise "OR"-ed with > 0xFE80::. > And, the Link Local address does *not* have a prefix length (!!) RFC 4291 definitely implies a /64 for LLAs; the only example given has a 64-bit IID. > The reason I encourage use of a smaller prefix size than /64, is that > the overall scalability of *all* of the ISPs who have full routing tables, > is dramatically affected by the likelyhood of *any* ISPs getting more > than one PA block for giving out to customers. > > And the PA block usage is driven by both the ability to aggregate > internally, and the size of blocks assigned to customers. > > With a /32, giving out /48's and doing internal aggregation, a new > block may be needed in as little as 20k assignments - and under > current policies, would be a perfectly acceptable basis for > requesting an additional block. First of all, the vast majority (numerically) of LIRs will never need to make more assignments than that. Those that do will likely be using /56 assignments for most customers, which were specifically adopted for such LIRs that wanted them. Second, /32 is only the _minimum_ size allocation. LIRs can request more space, and at least two* have according to ARIN's WHOIS. In other regions, where IPv6 has been rolled out more aggressively, one can see allocations as short as /19. That's a heck of a lot of /48 assignments, even with several levels of internal aggregation. (* Sprint with a /29 and VZB with a /27, both out of what appear to be /21s reserved for future growth. /32s appear to get /29 reservations.) > The error is in taking the number of /N blocks that fit in a /M blocks, > and presuming that they can be assigned in a completely efficient > manner, effectively serialized assignments. This is not the case in > real world allocation environments, and particularly not when > internal aggregation is a very important consideration. Hardly; the whole point of using the HD Ratio is that it allows for aggregation causing inefficient utilization. The more bits you need for actual subnets, the more bits you get to burn on internal hierarchy. > The real question is, if an end-site can implement a long-term plan, > using those two technologies, and based on their long-term needs > (10 or 20 year is entirely reasonable), request a huge IPv6 block, > such as a /80, why would they not give consideration to making a > request for a /80? That's a miniscule block by current standards, not "huge". You're focusing almost exclusively on the lower-order bits and trying to justify minimizing their use, but you haven't given any decent reason why we're short on higher-order bits. 128 bits is a _lot_. That number was chosen (vs. 64) so that we'd have so many we wouldn't need to worry about wasting them, even when using EUI-64s for the host part. 64 bits for the network prefix is far more than we can figure out how to assign, much less route... If we did, for example, stuff every end site into a /80, we still couldn't route more than a /60 of space today in the DFZ. IMHO, that says you're worrying about the wrong problem. We can barely manage routing 20 bits of prefixes today, perhaps 24 bits within a few years. Today's /32s for LIRs and /48s for end sites are already ridiculously long because we can't possibly route the number of prefixes possible with those sizes; there is no point, IMHO, in making allocations/assignments longer than that. And, if those are the top-level sizes, there is no rational need for anything longer than /64s for individual subnets, except perhaps for PTP links (where /127s do sort of make sense). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From michael.dillon at bt.com Mon Oct 22 04:28:55 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Oct 2007 09:28:55 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com><64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com><3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> Message-ID: > (1) The IETF does not recommend use of specific prefix lengths; This is flat-out UNTRUE! RFC 3177, which references RFCs 2374 and 2450 says this: In [RFC2374] and [RFC2450], the IETF's IPNG working group has recommended that the address block given to a single edge network which may be recursively subnetted be a 48-bit prefix. This gives each such network 2^16 subnet numbers to use in routing, and a very large number of unique host numbers within each network. This is deemed to be large enough for most enterprises, and to leave plenty of room for delegation of address blocks to aggregating entities. That is not only a recommendation on the use of specific prefix lengths but it also includes and explanation of why, especially if you read it in context of the whole RFC. The author admits that he has no relevant experience whatsoever in this field so, although we probably can't stop him from chattering away on the PPML list, we can and should ignore him. --Michael Dillon From michael.dillon at bt.com Mon Oct 22 04:34:26 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Oct 2007 09:34:26 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <3c3e3fca0710211952q49e2a8ffx9773b84bd94cf2cf@mail.gmail.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com><64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com><3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com><65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> <3c3e3fca0710211952q49e2a8ffx9773b84bd94cf2cf@mail.gmail.com> Message-ID: > I think you have mistaken me for Keith Medcalf whose > assertion that legacy /24 holders should receive a /64 > confuses me as well. They should receive a /48 IMHO, just > like every other PI assignment. That's not an engineering > requirement but it is a best practice. When this comment first came up, it sounded like the original writer was just explaining that he would need a MINIMUM of an IPv6 /64 in order to implement the same kind of network architecture that he had with an IPv4 /24. Some people view /24 as a class C block which is what you use on a local area network connected to a router. This may be a simplistic view, but it is widespread and the people who hold this view tend to think of /24 as the smallest IPv4 subnet size. In that context, comparing a /24 in IPv4 to a /64 in IPv6 makes a lot more sense. Personally, I think that when someone is faced with a beliigerent poster who repeatedly demands answers to a specific narrow question, it is best to ignore the questions. --Michael Dillon From marla.azinger at frontiercorp.com Mon Oct 22 09:31:36 2007 From: marla.azinger at frontiercorp.com (Azinger, Marla) Date: Mon, 22 Oct 2007 09:31:36 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm Message-ID: <454810F09B5AA04E9D78D13A5C39028A0272FA72@nyrofcs2ke2k01.corp.pvt> Just a note on the RFC debate. 3177 is a recommendation from 2001 and not a standar of any kind. It says so in the first paragraph. Related to this,I am finding that there are people who are actually working with creating their IPv6 networks and they are finding this recommendation to be far more wasteful then originally thought. So to some this recommendation is outdated and not a good one if you choose to learn from history. *I know everyone will not agree with my last statement but I just want to point out that it is an opinion that is growing larger. Cheers~ Marla -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Stephen Sprunk Sent: Sunday, October 21, 2007 8:50 PM To: briand at ca.afilias.info Cc: ARIN PPML Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm Thus spake >> Given that we could assign a /48 to every individual who has ever >> lived without filling a /14, and given that the IETF has defined >> standards that only work properly when the subnet mask is /64, I'm >> curious why you'd want to buck the IETF on the recommendation >> against assigning prefixes longer than /64? > > I'll answer your question in good faith, but ask you *again*, to answer > my basic question: > > What, if anything, do you believe forms a *requirement* that a Legacy > /24 cannot use IPv6, unless they receive a /64? Because, according to the IETF, a single subnet should be a /64. Even folks who are using DHCPv6 are assigning /64s, from what I've seen. > To answer your question(s): > (1) The IETF does not recommend use of specific prefix lengths; Actually, it did. Please see RFC 3177. > (3) The IETF lists a few methods for constructing Interface Identifiers. > Currently, those are 64 bits in size. > (3.1) However, the other RFCs only *implicitly* make reference to > the size of the Interface Identifer, e.g. as N bits and 128-N bits. > (3.2) Specifically, Link Local addresses are constructed as right- > aligned Interface Identifier, zero-padded, bitwise "OR"-ed with > 0xFE80::. > And, the Link Local address does *not* have a prefix length (!!) RFC 4291 definitely implies a /64 for LLAs; the only example given has a 64-bit IID. > The reason I encourage use of a smaller prefix size than /64, is that > the overall scalability of *all* of the ISPs who have full routing tables, > is dramatically affected by the likelyhood of *any* ISPs getting more > than one PA block for giving out to customers. > > And the PA block usage is driven by both the ability to aggregate > internally, and the size of blocks assigned to customers. > > With a /32, giving out /48's and doing internal aggregation, a new > block may be needed in as little as 20k assignments - and under > current policies, would be a perfectly acceptable basis for > requesting an additional block. First of all, the vast majority (numerically) of LIRs will never need to make more assignments than that. Those that do will likely be using /56 assignments for most customers, which were specifically adopted for such LIRs that wanted them. Second, /32 is only the _minimum_ size allocation. LIRs can request more space, and at least two* have according to ARIN's WHOIS. In other regions, where IPv6 has been rolled out more aggressively, one can see allocations as short as /19. That's a heck of a lot of /48 assignments, even with several levels of internal aggregation. (* Sprint with a /29 and VZB with a /27, both out of what appear to be /21s reserved for future growth. /32s appear to get /29 reservations.) > The error is in taking the number of /N blocks that fit in a /M blocks, > and presuming that they can be assigned in a completely efficient > manner, effectively serialized assignments. This is not the case in > real world allocation environments, and particularly not when > internal aggregation is a very important consideration. Hardly; the whole point of using the HD Ratio is that it allows for aggregation causing inefficient utilization. The more bits you need for actual subnets, the more bits you get to burn on internal hierarchy. > The real question is, if an end-site can implement a long-term plan, > using those two technologies, and based on their long-term needs > (10 or 20 year is entirely reasonable), request a huge IPv6 block, > such as a /80, why would they not give consideration to making a > request for a /80? That's a miniscule block by current standards, not "huge". You're focusing almost exclusively on the lower-order bits and trying to justify minimizing their use, but you haven't given any decent reason why we're short on higher-order bits. 128 bits is a _lot_. That number was chosen (vs. 64) so that we'd have so many we wouldn't need to worry about wasting them, even when using EUI-64s for the host part. 64 bits for the network prefix is far more than we can figure out how to assign, much less route... If we did, for example, stuff every end site into a /80, we still couldn't route more than a /60 of space today in the DFZ. IMHO, that says you're worrying about the wrong problem. We can barely manage routing 20 bits of prefixes today, perhaps 24 bits within a few years. Today's /32s for LIRs and /48s for end sites are already ridiculously long because we can't possibly route the number of prefixes possible with those sizes; there is no point, IMHO, in making allocations/assignments longer than that. And, if those are the top-level sizes, there is no rational need for anything longer than /64s for individual subnets, except perhaps for PTP links (where /127s do sort of make sense). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From kkargel at polartel.com Mon Oct 22 11:09:11 2007 From: kkargel at polartel.com (Kevin Kargel) Date: Mon, 22 Oct 2007 10:09:11 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> Message-ID: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> Speaking as an ISP.. albeit a small one, my plan (when customers start asking for IPv6) is to grant all customers who request more than a host subnet a minimum of a /120, and to be very liberal in allowing shorter lengths. I will have no problem giving a customer a shorter prefix if they tell me they have a couple thousand toasters in need of IP addresses. Kevin > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of briand at ca.afilias.info > Sent: Saturday, October 20, 2007 1:37 PM > To: Keith Medcalf > Cc: ppml at arin.net > Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > > > > This is a very bad idea. The requirement that a "minumum" end-user > > site assignment of a /64 is the only thing that will permit many > > Legacy /24 holders (such as myself) who are single-homed > use IPv6 at all. > > I'm interested in understanding this proposition. > Can you explain why you believe /24 Legacy holders would not > be able to use, for example, a /120? > > Or any other prefix length in between /64 and /120? > > I suggest /120, because as a /24 holder, the only viable > addressing options are static, and DHCP. > > And for a /24, there are only 8 bits of host available for assignment. > > Static and DHCP are both supported in IPv6, and 8 bits of > host are obviously supported with a /120. > > This is not to say, that if you present an addressing plan > that shows you need 24 bits of address space (for whatever > reason), that they would not be able to, or would not be > willing to, assign a /104. > > > Either you have to require a minimum /64 PA end-user delegation by > > ISPs > > *or* you have to make it so that anyone who wants a /64 can qualify > > for a > > PIv6 /64 (or larger) direct assignment. > > What is it, specifically, about /64 that you feel is the > minimum requirement, not just for you, but for *everyone*? > > And besides, what makes you think that the existence of a > smaller minimum, will in any way affect the *maximum* size > that an ISP will willingly delegate to and end-site or end-user? > > I think, given the vast amount of space any ISP will have, > will encourage the adoption of customer-responsive allocation > policies, e.g. if you have a given block /N from one ISP, > that every other ISP you connect to will be happy to give you > a block of size /N, unless N << 64 - in which case you would > probably want to provide some kind of justification. > > The purpose of recommendations is to give ISPs who don't have > a handle on IPv6, a rough idea on how many ways their > customers *can* use it, and what kinds of request they should > expect to see. If neither the ISP nor the ISP's customer has > much IPv6 experience, the recommendations are intended to > give both an idea of what others in the industry generally do. > > And the intent of *that*, is so that an end-user, in > requesting space from a second ISP (who is more > IPv6-experienced) won't get any unpleasant surprises. > > It is, in effect, an early "best common practices" for a > period in time before there are *any* common practices, good > or bad - with the intent of ensuring that things don't go > collectively to the dogs from day one. > > > The purpose of ARIN is *not* to ensure the profitability of > carriers > > and ISPs by imposing unreasonable limits on the availability and > > usability of the network. > > That is true. > > However, I think you would agree that anything which is bad > for *all* ISPs and carriers, is bad for the Internet. > > And, for good or bad, ARIN does what its members tell it to. > Those members generally need to work towards consensus, and > all benefit from policies which benefit most (if not all) and > harm none. > > > Therefore I would very actively and vocally oppose any such > attempted > > change to policy. > > I see it as a clarification of policy, rather than a change. > > The policy is quite old, and predates completed specification > and available implementations of the likes of DHCPv6. > > But I, like most participating on PPML, am interested in > hearing the voices of those with whom we disagree - since > without dialog, there can not be consensus. > > Brian > > >> -----Original Message----- > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] > On Behalf > >> Of briand at ca.afilias.info > >> Sent: Thursday, 18 October, 2007 19:18 > >> To: ARIN PPML > >> Subject: [ppml] IPv6 assignment - proposal for change to nrpm > >> > >> I propose changes to the current text of 6.5.4.1: > >> > >> Currently, it reads: > >> > >> 6.5.4.1. Assignment address space size > >> > >> End-users are assigned an end site assignment from their > LIR or ISP. > >> The exact size of the assignment is a local decision for > the LIR or > >> ISP to make, using a minimum value of a /64 (when only one > subnet is > >> anticipated for the end site) up to the normal maximum of > /48, except > >> in cases of extra large end sites where a larger assignment can be > >> justified. > >> > >> The following guidelines may be useful (but they are only > guidelines): > >> > >> * /64 when it is known that one and only one subnet is needed > >> * /56 for small sites, those expected to need only a > few subnets > >> over the next 5 years. > >> * /48 for larger sites > >> > >> For end sites to whom reverse DNS will be delegated, the LIR/ISP > >> should consider making an assignment on a nibble (4-bit) > boundary to > >> simplify reverse lookup delegation. > >> [...] > >> > >> ----- > >> > >> I propose the following as a replacement for the text: > >> > >> 6.5.4.1. Assignment address space size > >> > >> End-users are assigned an end site assignment from their > LIR or ISP. > >> The exact size of the assignment is a local decision for > the LIR or > >> ISP to make, using a minimum value of a /120 (when only > one subnet is > >> anticipated for the end site) up to the normal maximum of > /48, except > >> in cases of extra large end sites where a larger assignment can be > >> justified. > >> > >> The following guidelines may be useful (but they are only > guidelines): > >> > >> * /120 for a very small customer with one subnet, using static > >> assignments or DHCPv6 > >> * /116 for a small customer with a few subnets, using static > >> assignments or DHCPv6 > >> * /112 for a medium size customer with a significant > total number > >> of hosts and/or subnets, using static assignments and/or DHCPv6 > >> * /96 for large customers > >> * /80 for very large customers, or for customers using > a proposed > >> modified version of V6-autoconf > >> * /64 when it is known that one and only one subnet is needed, > >> for a customer that absolutely requires either traditional IPv6 > >> autoconfiguration, or IPv6 host Interface Identifier cryptographic > >> generation > >> * /60 for sites where a mix of IPv6-autoconfiguration > and other > >> address assignment techiques are required > >> * /56 for very large sites > >> * /52 for very, very large sites > >> * /48 for extremely large sites > >> > >> For end sites to whom reverse DNS will be delegated, the LIR/ISP > >> should consider making an assignment on a nibble (4-bit) > boundary to > >> simplify reverse lookup delegation. > >> > >> ----- > >> The timeframe for the proposed change: immediate. > >> > >> The intent is to provide more current guidance, to both > ARIN members, > >> and to ARIN staff, based on available IPv6 technology, and for the > >> encouragement of efficient assignment of IPv6 address space. > >> > >> Brian Dickson > >> Afilias > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed > to the ARIN > >> Public Policy Mailing List (PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN > >> Member Services Help Desk at 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact > the ARIN Member Services Help Desk at info at arin.net if you > experience any issues. > From info at arin.net Mon Oct 22 11:23:21 2007 From: info at arin.net (Member Services) Date: Mon, 22 Oct 2007 11:23:21 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: References: Message-ID: <471CC069.6040005@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Size Reduction Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: 6.5.4.1. Assignment address space size End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /120 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /120 for a very small customer with one subnet, using static assignments or DHCPv6 * /116 for a small customer with a few subnets, using static assignments or DHCPv6 * /112 for a medium size customer with a significant total number of hosts and/or subnets, using static assignments and/or DHCPv6 * /96 for large customers * /80 for very large customers, or for customers using a proposed modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) * /72 for customers with several subnets using modified V6-autoconf (which uses EUI-48 instead of EUI-64) * /64 when it is known that one and only one subnet is needed, for a customer that absolutely requires either traditional IPv6 autoconfiguration, or IPv6 host Interface Identifier cryptographic generation * /60 for sites where a mix of IPv6-autoconfiguration and other address assignment techiques are required * /56 for very large sites * /52 for very, very large sites * /48 for extremely large sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. Rationale: The intent is to provide more current guidance, to both ARIN members, and to ARIN staff, based on available IPv6 technology, and for the encouragement of efficient assignment of IPv6 address space. IPv6 supports numerous methods for address assignments to end nodes. Those include autoconfiguration, static assignment, and DHCPv6. Of those, only autoconfiguration requires use of /64 as the prefix size. Efficient use of IPv6 space should discourage widespread use of /64's, or for use of autoconfiguration as the sole justification for allocations of large address space. In particular, the effective lifetime of PA assignments to ISPs/LIRs, is largely a factor of internal aggregation, and the size of end assignments. Rather than meeting ISP needs by assigning very large IPv6 PA blocks, it would be wiser to encourage assignments that to not significantly use up available PA space for the ISP, even for very large customers. The overall intent is to minimize the need for any PA recipient, to return to ARIN for subsequent assignments, thus reducing the need for additional globally routable prefixes using up slots in routers in the DFZ - something that affects the long-term ability for all ISPs to continue to scale in a cost-effective manner. Timetable for implementation: Immediate From info at arin.net Mon Oct 22 11:23:36 2007 From: info at arin.net (Member Services) Date: Mon, 22 Oct 2007 11:23:36 -0400 Subject: [ppml] Policy Proposal: 200-reduction-6.5.1.1.d In-Reply-To: References: Message-ID: <471CC078.2060401@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: 200-reduction-6.5.1.1.d Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: In 6.5.1.1 d), where 2007-25 proposes: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." replace with" "be an existing, known ISP in the ARIN region or have a plan for making at least 20 end-site assignments to other organizations, or for providing IPv6 transit to one or more IPv6 PI blocks belonging to other organizations, within 5 years." Rationale: The purpose of the text is to establish reasonable ways for an ISP to demonstrate that it is in fact an ISP. Any of the above listed conditions satisfy that need, and the intent is to avoid having the text of the policy prevent any legitimate ISP from receiving an initial IPv6 allocation. It does lower the bar, but in a justifiable fashion. It is not necessary for an ISP to have lots of PA assignments. It is necessary for an ISP to be announcing PA *or* PI blocks to the internet, and relaxing the criteria to recognize both possibilities jointly, makes the policy reflect the actual realities for any number of large regional ISPs, who may have sold off portions of their business but who still operate significant infrastructure. Timetable for implementation: Immediate From mack at exchange.alphared.com Mon Oct 22 11:48:20 2007 From: mack at exchange.alphared.com (mack) Date: Mon, 22 Oct 2007 10:48:20 -0500 Subject: [ppml] PPML Digest, Vol 28, Issue 56 In-Reply-To: References: Message-ID: <859D2283FD04CA44986CC058E06598F84B1DAC1B0D@exchange4.exchange.alphared.local> As previously stated this breaks existing implementations as well as contradicting a large number of RFCs. It is in direct conflict with current IETF direction. The current guidelines of: /56 for small sites /48 for large sites And /32 or larger for LIRs is reasonable. The only further comment I have on this is NO! LR Mack McBride Network Administrator Alpha Red, Inc. > > Message: 5 > Date: Mon, 22 Oct 2007 11:23:21 -0400 > From: Member Services > Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction > To: ppml at arin.net > Message-ID: <471CC069.6040005 at arin.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > ARIN received the following policy proposal. In accordance with the > ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed > on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If > the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. > At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Assignment Size Reduction > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: Oct 18, 2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. > The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /120 (when only one subnet is > anticipated for the end site) up to the normal maximum of /48, except > in > cases of extra large end sites where a larger assignment can be > justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant total number > of hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) > * /72 for customers with several subnets using modified V6- > autoconf > (which uses EUI-48 instead of EUI-64) > * /64 when it is known that one and only one subnet is needed, for > a customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > Rationale: > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > IPv6 supports numerous methods for address assignments to end nodes. > Those include autoconfiguration, static assignment, and DHCPv6. > Of those, only autoconfiguration requires use of /64 as the prefix > size. > > Efficient use of IPv6 space should discourage widespread use of /64's, > or for use of autoconfiguration as the sole justification for > allocations of large address space. > > In particular, the effective lifetime of PA assignments to ISPs/LIRs, > is > largely a factor of internal aggregation, and the size of end > assignments. > > Rather than meeting ISP needs by assigning very large IPv6 PA blocks, > it > would be wiser to encourage assignments that to not significantly use > up > available PA space for the ISP, even for very large customers. > > The overall intent is to minimize the need for any PA recipient, to > return to ARIN for subsequent assignments, thus reducing the need for > additional globally routable prefixes using up slots in routers in the > DFZ - something that affects the long-term ability for all ISPs to > continue to scale in a cost-effective manner. > > Timetable for implementation: Immediate > > > > > > ------------------------------ > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > > > End of PPML Digest, Vol 28, Issue 56 > ************************************ From dlw+arin at tellme.com Mon Oct 22 12:06:54 2007 From: dlw+arin at tellme.com (David Williamson) Date: Mon, 22 Oct 2007 09:06:54 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <471CC069.6040005@arin.net> References: <471CC069.6040005@arin.net> Message-ID: <20071022160654.GS23649@shell01.cell.sv2.tellme.com> On Mon, Oct 22, 2007 at 11:23:21AM -0400, Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > Policy Proposal Name: IPv6 Assignment Size Reduction I am entirely against this proposal. As others have noted, this flies in the face of existing IETF standards and recommendations. The vast majority of existing LLA implementations expect the /64 boundary to be enforced, and EUI-48 isn't generally implemented, while EUI-64 is. (I'll also note that DHCP6 is still primitive, to my mild annoyance.) In addition, the current v6 environment is focused on subnets, not hosts, which seems to be something that many people are missing. As Geoff Huston noted: >The intent of the use of /56 in the efficiency metric was to provide a >common mechanism to measure the efficiency of end-site prefix >assignments irrespective of the size of individual end site assignments, >and explicitly not to measure the efficiency of address assignments to >hosts. > >i.e the presumption in terms of this end site prefix efficiency measure >is that the assignments with end-sites are not the subject of the review. Let me expand on that. End-sites and their efficiency are essentially irrelevant to the overall numbering and routing scheme in v6. Again, hosts just don't matter, and all that counts for anything is the number of subnets. Personally, I think the /64 everywhere decision was pretty dumb, but it has some advantages. We need to stop thinking about how many hosts we can squeeze into a network, and we can stop worrying about picking the right subnet mask when a new network is turned up. (what if I have to remask it later? is no longer an interesting question.) If we collectively get out of v4 mindset, we can do some seriously creative things in v6. Let's not reimpose v4 restrictions on the world, which is exactly what this proposal does. Yes, we're not being super efficient with number policy, but that's not what we need at this point in time. If, 50 years from now, we're running low on address space, things will certainly change. It's presumptuous of us to think that we know how this is really going to work out over that kind of time period, though. Again, for clarity, I really really oppose this policy proposal. -David From bicknell at ufp.org Mon Oct 22 12:29:20 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 22 Oct 2007 12:29:20 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <64505.70.53.64.10.1193024274.squirrel@look.libertyrms.com> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com> <64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> <3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com> <65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com> <20071022025956.GB37937@ussenterprise.ufp.org> <64505.70.53.64.10.1193024274.squirrel@look.libertyrms.com> Message-ID: <20071022162920.GA89375@ussenterprise.ufp.org> In a message written on Sun, Oct 21, 2007 at 11:37:54PM -0400, briand at ca.afilias.info wrote: > I'm pretty sure the way I worded my proposal was the encouragement of, > not the requirement of, ISPs allocating longer prefixes. Here's the problem with "encouragement". At the end of the day the rubber meets the road by an ISP coming back to ARIN and asking for more space. At that time staff takes some look at their previous use of space and decides if it meets the requirements to get more space. The carrot is, do things right and your request goes through quicker, the stick is, do things wrong and you won't get more space until you fix your current problem. In that context, guidelines don't work well. Indeed, prior to IPv6 the last 10 years have been all about removing guidelines from ARIN policy, and leaving hard and fast rules. It's nice to say something like: "If you can, use a /120 for a small customer." However, when ARIN staff conducts there review the current /requirement/ is that ISP's justify larger than a /48. So the ISP says "well, I think this guy may grow in 5 years, so I gave him a /48", ARIN staff accepts it and moves on. I ended up a bit at odds with Leslie while on the Podium, and we talked after the meeting. Being tired from two days of policy I minced her words wrong and created some confusion. I said "ARIN staff does not use the guidelines,", which she jumped up and said was wrong. It was, they use them to inform people how they should be doing things. The correct statement was "ARIN staff does not /enforce/ the guidelines." They see no way to enforce a recommendation. [Hopefully I got it right this time, sorry Leslie.] It's useful to explain things like "you can use a /126 for a P2P link between your routers where you want to statically address things" to people so we're not wasting /64's for that job. I guess where I keep coming back to is that such items are not policy, they are community education. They should be in the NPOG (which I think needs to be accelerated), or the glossy flyers ARIN produces; not the policy manual which is our hard and fast rules that staff must implement. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From mack at exchange.alphared.com Mon Oct 22 12:32:08 2007 From: mack at exchange.alphared.com (mack) Date: Mon, 22 Oct 2007 11:32:08 -0500 Subject: [ppml] ARIN Meeting Minutes In-Reply-To: References: Message-ID: <859D2283FD04CA44986CC058E06598F84B1DAC1B1E@exchange4.exchange.alphared.local> Does anyone have a summary of which policy proposals passed at the meeting or the schedule for meeting minutes being placed on the website? LR Mack McBride Network Administrator Alpha Red, Inc. From Crumb_Anthony_A at cat.com Mon Oct 22 13:01:28 2007 From: Crumb_Anthony_A at cat.com (Anthony A. Crumb) Date: Mon, 22 Oct 2007 12:01:28 -0500 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <471CC069.6040005@arin.net> Message-ID: Given the number of possible interfaces available in a /64 I think it makes good sense to talk about the use of subnets smaller than 64 bits long. However I think an ARIN policy change would have to be preceded by the appropriate RFC changes. Specifically RFC 4291 sec. 2.5.1 where it is stated that "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." If there is an RFC that obsoletes 4291, or if I am just misinterpreting it please provide the number or help me understand the flaw in my interpretation. Anthony A. Crumb Member Services Sent by: ppml-bounces at arin.net 10/22/2007 10:23 AM To ppml at arin.net cc Subject [ppml] Policy Proposal: IPv6 Assignment Size Reduction Caterpillar: Confidential Green Retain Until: 11/21/2007 ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: IPv6 Assignment Size Reduction Author: Brian Dickson Proposal Version: 1 Submission Date: Oct 18, 2007 Proposal type: modify Policy term: permanent Policy statement: 6.5.4.1. Assignment address space size End-users are assigned an end site assignment from their LIR or ISP. The exact size of the assignment is a local decision for the LIR or ISP to make, using a minimum value of a /120 (when only one subnet is anticipated for the end site) up to the normal maximum of /48, except in cases of extra large end sites where a larger assignment can be justified. The following guidelines may be useful (but they are only guidelines): * /120 for a very small customer with one subnet, using static assignments or DHCPv6 * /116 for a small customer with a few subnets, using static assignments or DHCPv6 * /112 for a medium size customer with a significant total number of hosts and/or subnets, using static assignments and/or DHCPv6 * /96 for large customers * /80 for very large customers, or for customers using a proposed modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) * /72 for customers with several subnets using modified V6-autoconf (which uses EUI-48 instead of EUI-64) * /64 when it is known that one and only one subnet is needed, for a customer that absolutely requires either traditional IPv6 autoconfiguration, or IPv6 host Interface Identifier cryptographic generation * /60 for sites where a mix of IPv6-autoconfiguration and other address assignment techiques are required * /56 for very large sites * /52 for very, very large sites * /48 for extremely large sites For end sites to whom reverse DNS will be delegated, the LIR/ISP should consider making an assignment on a nibble (4-bit) boundary to simplify reverse lookup delegation. Rationale: The intent is to provide more current guidance, to both ARIN members, and to ARIN staff, based on available IPv6 technology, and for the encouragement of efficient assignment of IPv6 address space. IPv6 supports numerous methods for address assignments to end nodes. Those include autoconfiguration, static assignment, and DHCPv6. Of those, only autoconfiguration requires use of /64 as the prefix size. Efficient use of IPv6 space should discourage widespread use of /64's, or for use of autoconfiguration as the sole justification for allocations of large address space. In particular, the effective lifetime of PA assignments to ISPs/LIRs, is largely a factor of internal aggregation, and the size of end assignments. Rather than meeting ISP needs by assigning very large IPv6 PA blocks, it would be wiser to encourage assignments that to not significantly use up available PA space for the ISP, even for very large customers. The overall intent is to minimize the need for any PA recipient, to return to ARIN for subsequent assignments, thus reducing the need for additional globally routable prefixes using up slots in routers in the DFZ - something that affects the long-term ability for all ISPs to continue to scale in a cost-effective manner. Timetable for implementation: Immediate _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ed.Lewis at neustar.biz Mon Oct 22 13:13:13 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 22 Oct 2007 13:13:13 -0400 Subject: [ppml] ARIN Meeting Minutes In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1DAC1B1E@exchange4.exchange.alphared.lo cal> References: <859D2283FD04CA44986CC058E06598F84B1DAC1B1E@exchange4.exchange.alphared.lo cal> Message-ID: At 11:32 -0500 10/22/07, mack wrote: >Does anyone have a summary of which policy proposals passed at the >meeting or the schedule for meeting minutes being placed on the >website? http://www.arin.net/meetings/minutes/ARIN_XX/PDF/friday/ACReport_Azinger.pdf Is that what you want? In the past it has taken a reasonable time (week-weeks?) to get the meeting record up on the web site. I don't officially know myself...just speaking from experience. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From alh-ietf at tndh.net Mon Oct 22 13:17:03 2007 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 22 Oct 2007 10:17:03 -0700 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <471CC069.6040005@arin.net> References: <471CC069.6040005@arin.net> Message-ID: <014001c814cf$5f87a4d0$1e96ee70$@net> This proposal is completely misguided, in that its fundamental premise is based on the IPv4 mindset of managing subnet size based on connected device count. This short-sighted approach precludes technology advancements like securing neighbor discovery through use of cryptographic addressing mechanisms. While any organization is free to choose whatever prefix length it wants (with the associated self-inflicted consequences), it is inappropriate for assignment policy to placate this closed-minded and unjustified conservatism. People are complaining about routers falling over due to too many routing entries, yet proposals like this one keep appearing that do nothing more than increase the number of potential routing entries at the expense of real innovation. IPv6 has many of the characteristics of IPv4, to make deployment straight forward for the existing staff. That similarity does not mean IPv6 should be limited to the capabilities of IPv4, yet proposals like this one (and statements like 'IPv6 is just IPv4 with more bits') are so focused on the past that they attempt to ensure that IPv6 can never have new and different capabilities. I oppose this proposal. Tony > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Member Services > Sent: Monday, October 22, 2007 8:23 AM > To: ppml at arin.net > Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction > > ARIN received the following policy proposal. In accordance with the > ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed > on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If > the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. > At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: IPv6 Assignment Size Reduction > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: Oct 18, 2007 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > 6.5.4.1. Assignment address space size > > End-users are assigned an end site assignment from their LIR or ISP. > The > exact size of the assignment is a local decision for the LIR or ISP to > make, using a minimum value of a /120 (when only one subnet is > anticipated for the end site) up to the normal maximum of /48, except > in > cases of extra large end sites where a larger assignment can be > justified. > > The following guidelines may be useful (but they are only guidelines): > > * /120 for a very small customer with one subnet, using static > assignments or DHCPv6 > * /116 for a small customer with a few subnets, using static > assignments or DHCPv6 > * /112 for a medium size customer with a significant total number > of hosts and/or subnets, using static assignments and/or DHCPv6 > * /96 for large customers > * /80 for very large customers, or for customers using a proposed > modified version of V6-autoconf (which uses EUI-48 instead of EUI-64) > * /72 for customers with several subnets using modified V6- > autoconf > (which uses EUI-48 instead of EUI-64) > * /64 when it is known that one and only one subnet is needed, for > a customer that absolutely requires either traditional IPv6 > autoconfiguration, or IPv6 host Interface Identifier cryptographic > generation > * /60 for sites where a mix of IPv6-autoconfiguration and other > address assignment techiques are required > * /56 for very large sites > * /52 for very, very large sites > * /48 for extremely large sites > > For end sites to whom reverse DNS will be delegated, the LIR/ISP should > consider making an assignment on a nibble (4-bit) boundary to simplify > reverse lookup delegation. > > Rationale: > > The intent is to provide more current guidance, to both ARIN members, > and to ARIN staff, based on available IPv6 technology, and for the > encouragement of efficient assignment of IPv6 address space. > > IPv6 supports numerous methods for address assignments to end nodes. > Those include autoconfiguration, static assignment, and DHCPv6. > Of those, only autoconfiguration requires use of /64 as the prefix > size. > > Efficient use of IPv6 space should discourage widespread use of /64's, > or for use of autoconfiguration as the sole justification for > allocations of large address space. > > In particular, the effective lifetime of PA assignments to ISPs/LIRs, > is > largely a factor of internal aggregation, and the size of end > assignments. > > Rather than meeting ISP needs by assigning very large IPv6 PA blocks, > it > would be wiser to encourage assignments that to not significantly use > up > available PA space for the ISP, even for very large customers. > > The overall intent is to minimize the need for any PA recipient, to > return to ARIN for subsequent assignments, thus reducing the need for > additional globally routable prefixes using up slots in routers in the > DFZ - something that affects the long-term ability for all ISPs to > continue to scale in a cost-effective manner. > > Timetable for implementation: Immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From info at arin.net Mon Oct 22 13:42:01 2007 From: info at arin.net (Member Services) Date: Mon, 22 Oct 2007 13:42:01 -0400 Subject: [ppml] ARIN Meeting Minutes In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1DAC1B1E@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1DAC1B1E@exchange4.exchange.alphared.local> Message-ID: <471CE0E9.50808@arin.net> The ARIN XX Meeting Report will be available on the ARIN website on 30 October. The Advisory Council Report given at the Members Meeting on Friday 19 October includes decisions made by the Advisory Council regarding each of the proposals. This presentation can be found at: PDF: http://www.arin.net/meetings/minutes/ARIN_XX/PDF/friday/ACReport_Azinger.pdf PPT: http://www.arin.net/meetings/minutes/ARIN_XX/PPT/friday/ACReport_Azinger.ppt Regards, Member Services American Registry for Internet Numbers (ARIN) ------------------ mack wrote: > Does anyone have a summary of which policy proposals passed at the meeting or the schedule for meeting minutes being placed on the website? > > LR Mack McBride > Network Administrator > Alpha Red, Inc. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From bicknell at ufp.org Mon Oct 22 12:59:08 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 22 Oct 2007 12:59:08 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <454810F09B5AA04E9D78D13A5C39028A0272FA72@nyrofcs2ke2k01.corp.pvt> References: <454810F09B5AA04E9D78D13A5C39028A0272FA72@nyrofcs2ke2k01.corp.pvt> Message-ID: <20071022165908.GB89375@ussenterprise.ufp.org> In a message written on Mon, Oct 22, 2007 at 09:31:36AM -0400, Azinger, Marla wrote: > 3177 is a recommendation from 2001 and not a standar of any kind. I'm afraid many people are not looking at the right RFC's and/or considering what all needs to be changed if the /64 boundary is to be updated. I'm fairly sure this is not an exhaustive list, /64 is referenced in many locations in different IPv6 RFC's, many of which are standards track. * http://www.faqs.org/rfcs/rfc2373.html "IP Version 6 Addressing Architecture" Status: Standards Track Section 2.5.1: "Interface IDs are required to be 64 bits long..." Section 2.5.7: Aggregatable Global Unicast Addresses Section 2.5.8: Local-Use IPv6 Unicast Addresses * http://www.faqs.org/rfcs/rfc2374.html "An IPv6 Aggregatable Global Unicast Address Format" Status: Standards Track Section 3.1 makes it clear the lower 64 bits are an interface identifier for I also point out section 3.4 makes a recomendation we continue to use a slow start method: It is recommended that organizations assigning NLA address space use "slow start" allocation procedures similar to [RFC2050]. * http://www.faqs.org/rfcs/rfc2450.html "Proposed TLA and NLA Assignment Rule" Status: Informational Section 3: IPv6 Aggregatable Global Unicast Address Format * http://www.faqs.org/rfcs/rfc2460.html "Internet Protocol, Version 6 (IPv6) Specification" Status: Standards Track Section 3: Specifically referrs to 2373 (ADDRARCH) * http://www.rfc-editor.org/rfc/rfc3177.txt "IAB/IESG Recommendations on IPv6 Address Allocations to Sites" Status: Informational Section 3: Recomendations -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From michael.dillon at bt.com Mon Oct 22 15:30:31 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Oct 2007 20:30:31 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com><64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com> <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> Message-ID: > Speaking as an ISP.. albeit a small one, Right, so ARIN will give you a /32 when you ask for IPv6 addresses. > my plan (when > customers start asking for IPv6) is to grant all customers > who request more than a host subnet a minimum of a /120, and > to be very liberal in allowing shorter lengths. I will have > no problem giving a customer a shorter prefix if they tell me > they have a couple thousand toasters in need of IP addresses. So what are you going to do with all those extra /48s that you are hoarding? There is no shortage of IPv6 addresses and since you are a small ISP, it is hard to imagine you running out of /48s anytime soon. So please tell us why you plan to hoard most of your allocation unused? And don't forget to explain how a SMALL ISP can justify allocating 200 /48 assignments to other organizations within 5 years when that small ISP actually plans to allocate a /120 to most customers. Or will you lie to ARIN's hostmasters. --Michael Dillon From michael.dillon at bt.com Mon Oct 22 15:36:53 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Oct 2007 20:36:53 +0100 Subject: [ppml] PPML Digest, Vol 28, Issue 56 In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1DAC1B0D@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1DAC1B0D@exchange4.exchange.alphared.local> Message-ID: > As previously stated this breaks existing implementations as > well as contradicting a large number of RFCs. > It is in direct conflict with current IETF direction. > > The current guidelines of: > /56 for small sites > /48 for large sites > And > /32 or larger for LIRs is reasonable. > > The only further comment I have on this is NO! I couldn't have said this better. I also say NO! --Michael Dillon P.S. The AC will reject this proposal anyway since cooperation with the IETF is fundamental to ARIN's relationships with ICANN. From bmanning at vacation.karoshi.com Mon Oct 22 15:37:30 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 22 Oct 2007 19:37:30 +0000 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> Message-ID: <20071022193730.GA15529@vacation.karoshi.com.> On Mon, Oct 22, 2007 at 08:30:31PM +0100, michael.dillon at bt.com wrote: > > Speaking as an ISP.. albeit a small one, > > Right, so ARIN will give you a /32 when you ask for IPv6 addresses. > > > my plan (when > > customers start asking for IPv6) is to grant all customers > > who request more than a host subnet a minimum of a /120, and > > to be very liberal in allowing shorter lengths. I will have > > no problem giving a customer a shorter prefix if they tell me > > they have a couple thousand toasters in need of IP addresses. > > So what are you going to do with all those extra /48s that you are > hoarding? There is no shortage of IPv6 addresses and since you are a > small ISP, it is hard to imagine you running out of /48s anytime soon. > So please tell us why you plan to hoard most of your allocation unused? i suspect the hoarding will be an unfortunate sideeffect of the /32 v6 allocation size. sort of like the hoarding done by those unfortunate souls who only needed 6 v4 addresses but were "forced" to take more (a /24 if they were lucky, a /20 if they were not) by their address registry. its not exactly fair to force people to take more addresses than they need and then berate them for hoarding... is it? --bill > --Michael Dillon From michael.dillon at bt.com Mon Oct 22 15:44:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Oct 2007 20:44:50 +0100 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <20071022160654.GS23649@shell01.cell.sv2.tellme.com> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> Message-ID: > If we collectively get out of v4 mindset, we can do some > seriously creative things in v6. Let's not reimpose v4 > restrictions on the world, which is exactly what this > proposal does. Let's not forget that the world of computers and networks does not stand still. With virtualization environments it is possible to build real networks of dozens of virtual machines and routers on a single physical computer. If I am sitting at home with a /48 allocation, I can have all kinds of virtual machines, each of which requires a real, globally unique routable IP address, on my network. With IPv4, the widespread use of this type of virtualization is not possible without hiding behind NAT. Using the IETF's IPv6 architecture with a /48 per end-site, it can be done by everyone. --Michael Dillon From michael.dillon at bt.com Mon Oct 22 15:51:32 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Oct 2007 20:51:32 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071022162920.GA89375@ussenterprise.ufp.org> References: <1196bcfddc62a74e996a15b3123a538d@mail.dessus.com><64471.70.53.64.10.1192905391.squirrel@look.libertyrms.com><3c3e3fca0710202259u5c04dacal3dd27098801b9095@mail.gmail.com><65401.70.53.64.10.1193018905.squirrel@look.libertyrms.com><20071022025956.GB37937@ussenterprise.ufp.org><64505.70.53.64.10.1193024274.squirrel@look.libertyrms.com> <20071022162920.GA89375@ussenterprise.ufp.org> Message-ID: > I guess where I keep coming back to is that such items > are not policy, they are community education. They should be > in the NPOG Education? What is NPOG. I went to www.arin.net and used the site search but came up with nothing. From bicknell at ufp.org Mon Oct 22 15:56:07 2007 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 22 Oct 2007 15:56:07 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: References: <20071022162920.GA89375@ussenterprise.ufp.org> Message-ID: <20071022195606.GA6490@ussenterprise.ufp.org> In a message written on Mon, Oct 22, 2007 at 08:51:32PM +0100, michael.dillon at bt.com wrote: > What is NPOG. I went to www.arin.net and used the site search but came > up with nothing. Sorry. It's a semi-offical name that comes from "Number Policy Operational Guidelines". Collectively all the stuff that's not policy, but we think needs to be written down. The BoT, Staff, and the AC are all providing some input into such a document. I don't know that the final form or contents have been decided yet. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: From michael.dillon at bt.com Mon Oct 22 16:06:13 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Oct 2007 21:06:13 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071022193730.GA15529@vacation.karoshi.com.> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> Message-ID: > its not exactly fair to force people to take more > addresses than they > need and then berate them for hoarding... is it? Taking more than you need is part of the IPv6 architecture, as well as giving your customers more than they need. The end result of giving everyone more addresses than they need is that you drive down the size of the global routing table and THAT is the resource that really is in short supply and really does need to be conserved. As for hoarding, whenever an ISP tries to apply IPv4 thinking to IPv6, they shoot themselves in the foot and become an address hoarder. Not in reality, of course, but only in their own deluded frame of reference. If you live in a desert, then it is appropriate to conserve water and hoard some in case of drought. But if you live in a rain forest, the same behavior is insane. --Michael Dillon From Ed.Lewis at neustar.biz Mon Oct 22 17:40:03 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 22 Oct 2007 17:40:03 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071022195606.GA6490@ussenterprise.ufp.org> References: <20071022162920.GA89375@ussenterprise.ufp.org> <20071022195606.GA6490@ussenterprise.ufp.org> <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> Message-ID: At 15:56 -0400 10/22/07, Leo Bicknell wrote: >>In a message ... michael.dillon at bt.com wrote: >> What is NPOG. I went to www.arin.net and used the site search but came >> up with nothing. ... >The BoT, Staff, and the AC are all providing some input into such >a document. I don't know that the final form or contents have >been decided yet. FWIW, I hadn't heard the term either until the member meeting. But I faintly recall hearing the idea bandied about. In the vein of open and transparent work of the AC, here are two links I found when searching the ARIN site: http://www.arin.net/meetings/minutes/ac/ac2007_0719.html http://www.arin.net/meetings/minutes/ac/ac2007_0215.html And this I couldn't resist replying to: At 21:06 +0100 10/22/07, wrote: >If you live in a desert, Like Albuquerque? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From briand at ca.afilias.info Mon Oct 22 17:42:23 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Mon, 22 Oct 2007 17:42:23 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071022165908.GB89375@ussenterprise.ufp.org> References: <454810F09B5AA04E9D78D13A5C39028A0272FA72@nyrofcs2ke2k01.corp.pvt> <20071022165908.GB89375@ussenterprise.ufp.org> Message-ID: <471D193F.8050302@ca.afilias.info> Leo Bicknell wrote: > In a message written on Mon, Oct 22, 2007 at 09:31:36AM -0400, Azinger, Marla wrote: > >> 3177 is a recommendation from 2001 and not a standar of any kind. >> > > I'm afraid many people are not looking at the right RFC's and/or > considering what all needs to be changed if the /64 boundary is to > be updated. I'm fairly sure this is not an exhaustive list, /64 > is referenced in many locations in different IPv6 RFC's, many of > which are standards track. > > * http://www.faqs.org/rfcs/rfc2373.html > "IP Version 6 Addressing Architecture" > Status: Standards Track > > Section 2.5.1: "Interface IDs are required to be 64 bits long..." > > Section 2.5.7: Aggregatable Global Unicast Addresses > > Section 2.5.8: Local-Use IPv6 Unicast Addresses > > RFC 2373 was obsoleted by 3531 which was obsoleted by 4291. 2.5.8 is gone, but AGUA is still roughly the same (all but 000 require use of EUI-64 modified), and ditto 2.5.1 > * http://www.faqs.org/rfcs/rfc2374.html > "An IPv6 Aggregatable Global Unicast Address Format" > Status: Standards Track > > Section 3.1 makes it clear the lower 64 bits are an interface > identifier for > > I also point out section 3.4 makes a recomendation we continue to use > a slow start method: > > It is recommended that > organizations assigning NLA address space use "slow start" allocation > procedures similar to [RFC2050]. > > 2374 was obsoleted by 3587. > * http://www.faqs.org/rfcs/rfc2450.html > "Proposed TLA and NLA Assignment Rule" > Status: Informational > > Section 3: IPv6 Aggregatable Global Unicast Address Format > > This bit was itself in RFC 2374, which was obsoleted by RFC 3587. > * http://www.faqs.org/rfcs/rfc2460.html > "Internet Protocol, Version 6 (IPv6) Specification" > Status: Standards Track > > Section 3: Specifically referrs to 2373 (ADDRARCH) > 4291 obsoletes 3531 which obsoleted 2373. (I don't know why 2460 hasn't been updated with the new references...) > * http://www.rfc-editor.org/rfc/rfc3177.txt > "IAB/IESG Recommendations on IPv6 Address Allocations to Sites" > Status: Informational > > Section 3: Recomendations > This was informational only, from 2001, and IMHO no longer as relevant as it once was. So, by my count, that is 4291 and 3587. My IETF draft also lists 2464 (Ethernet), 4941 (privacy), and 4862 (autoconfiguration). Most other IPv6 RFCs inherit from those few, and mostly the choice is rather axiomatic. Two small changes, basically, in a backward-compatible manner, is meant to be as minimally-disruptive as is possible. (Think surgery to remove a burst appendix or inflamed tonsils.) Anyone interested can see the draft at: http://www.ietf.org/internet-drafts/draft-dickson-v6man-new-autoconf-00.txt My draft even includes the necessary patch for Linux, about 17 lines in total, mostly the result of the necesssary line length provisions for an RFC. (It was 10 lines originally.) Brian From briand at ca.afilias.info Mon Oct 22 17:57:38 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Mon, 22 Oct 2007 17:57:38 -0400 Subject: [ppml] PPML Digest, Vol 28, Issue 51 In-Reply-To: <859D2283FD04CA44986CC058E06598F84B1DAC198F@exchange4.exchange.alphared.local> References: <859D2283FD04CA44986CC058E06598F84B1DAC198F@exchange4.exchange.alphared.local> Message-ID: <471D1CD2.4030604@ca.afilias.info> mack wrote: > This is not workable for a number of reasons. > 1) It is in direct conflict with current RFCs. > Hogwash. The current implementations fully support non /64 prefix usage. They simply dictate behavior that is not very useful. They say, if you get a non-64-bit prefix via RA, ignore it. *Implementations* must support auto-configuration. Nowhere does it say everyone must *use* auto-configuration. And I know lots of folks who plan never to touch the darned thing. > 2) It is in direct conflict with current auto-configuration implementations. > No - if you read the proposal, it is a set of *recommendations*, not *requirements*. Any end-site should still be able to justify a /64 if they intend to use auto-configuration. The corresponding proposal to the IETF, is to *allow* auto-configuration to respond to non-64-bit RA announcments, by constructing appropriate hardware-based II's, e.g. EUI-48 (MAC-48) for Ethernet. This would be backward-compatible for /64 prefixes, and would allow for use of other prefix lengths, e.g. /80, for auto-configuration. > 3) It breaks under at least one major vendors implementation of IPv6 when certain functionality is used. > > Quote from vendor documentation: > If the compress mode is on, the IPv6 address is compressed similarly to the EUI-64 compression method (removal of bits [39:24]) to allow for the Layer 4 port information to be used as part of the key used to look up the QoS TCAM, but Layer 3 information is lost. > > In practice the loss of data in these bits is inconsequential as they are a specific value (0xFFFE) or manually configured. Manual configuration can set these to a known constant. I personally use (0x0000 or 0xFFFE). > > Any change that significantly breaks current hardware under a common configuration is a very bad idea. > Does said hardware do this *only* when auto-configuration is used? What about when static configuration is done? What about when DHCPv6 is used? What about when crypto-v6 II's are used? (random II's based on cryptography). All of these do *not* use EUI-64 for their IPv6 address. They *do* use it for their Link-Local address. And my proposal does not in any way alter the use of EUI-64 for Link Local addressing - only for auto-configuration. So, what if a vendor's implementation is already broken, in that it violates the end-to-end principal for IPv6 addresses which are not auto-configuration generated? Brian Dickson From mack at exchange.alphared.com Mon Oct 22 18:20:25 2007 From: mack at exchange.alphared.com (mack) Date: Mon, 22 Oct 2007 17:20:25 -0500 Subject: [ppml] PPML Digest, Vol 28, Issue 51 In-Reply-To: <471D1CD2.4030604@ca.afilias.info> References: <859D2283FD04CA44986CC058E06598F84B1DAC198F@exchange4.exchange.alphared.local> <471D1CD2.4030604@ca.afilias.info> Message-ID: <859D2283FD04CA44986CC058E06598F84B1DAC1B86@exchange4.exchange.alphared.local> > -----Original Message----- > From: Brian Dickson [mailto:briand at ca.afilias.info] > Sent: Monday, October 22, 2007 4:58 PM > To: mack > Cc: ppml at arin.net > Subject: Re: [ppml] PPML Digest, Vol 28, Issue 51 > > mack wrote: > > This is not workable for a number of reasons. > > 1) It is in direct conflict with current RFCs. > > > Hogwash. The current implementations fully support non /64 prefix > usage. > They simply dictate behavior that is not very useful. > They say, if you get a non-64-bit prefix via RA, ignore it. > > *Implementations* must support auto-configuration. > Nowhere does it say everyone must *use* auto-configuration. > And I know lots of folks who plan never to touch the darned thing. Auto-configuration is only one set of RFCs. There was a list posted to the mailing list. Not sure what the conflict has to do with implementation but that is discussed later. > > 2) It is in direct conflict with current auto-configuration > implementations. > > > No - if you read the proposal, it is a set of *recommendations*, not > *requirements*. > Any end-site should still be able to justify a /64 if they intend to > use > auto-configuration. > > The corresponding proposal to the IETF, is to *allow* auto- > configuration > to respond to non-64-bit RA announcments, by constructing appropriate > hardware-based II's, e.g. EUI-48 (MAC-48) for Ethernet. > > This would be backward-compatible for /64 prefixes, and would allow for > use of other prefix lengths, e.g. /80, for auto-configuration. Some current implementations will support auto-configuration with lengths other than /64. A sufficient number will not. Your proposal does not make allowances for that. > > 3) It breaks under at least one major vendors implementation of IPv6 > when certain functionality is used. > > > > Quote from vendor documentation: > > If the compress mode is on, the IPv6 address is compressed similarly > to the EUI-64 compression method (removal of bits [39:24]) to allow for > the Layer 4 port information to be used as part of the key used to look > up the QoS TCAM, but Layer 3 information is lost. > > > > In practice the loss of data in these bits is inconsequential as they > are a specific value (0xFFFE) or manually configured. Manual > configuration can set these to a known constant. I personally use > (0x0000 or 0xFFFE). > > > > Any change that significantly breaks current hardware under a common > configuration is a very bad idea. > > > Does said hardware do this *only* when auto-configuration is used? > What about when static configuration is done? > What about when DHCPv6 is used? > What about when crypto-v6 II's are used? (random II's based on > cryptography). Yes, all of those are effected as well. Any address that contains data in the effected bits is effected. EUI-64 and link local constructed from MAC addresses do not contain useful information in those bits. > > All of these do *not* use EUI-64 for their IPv6 address. They *do* use > it for their Link-Local address. > > And my proposal does not in any way alter the use of EUI-64 for Link > Local addressing - only for auto-configuration. > > So, what if a vendor's implementation is already broken, in that it > violates the end-to-end principal for IPv6 addresses which are not > auto-configuration generated? It is an unfortunate side effect of the ACL TCAM implementation used. You can either have ACLs with full IP information and not port information Or port information and lose 16 bits of the address. As a major portion of the internet runs on this hardware it is a major issue. Your proposal does not address the issue. > > Brian Dickson From steveb at eagle.ca Mon Oct 22 18:35:19 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Mon, 22 Oct 2007 18:35:19 -0400 (EDT) Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071022193730.GA15529@vacation.karoshi.com.> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> Message-ID: <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> > i suspect the hoarding will be an unfortunate sideeffect of the /32 v6 > allocation size. sort of like the hoarding done by those unfortunate > souls who only needed 6 v4 addresses but were "forced" to take more (a > /24 if they were lucky, a /20 > if they were not) by their address registry. > > its not exactly fair to force people to take more addresses than they > need and then berate them for hoarding... is it? Interesting insight. I, operating a small ISP as others here, directly requested a smaller than /32 IPv6 block, because I knew that we would almost certainly never need it, but it was forced upon us anyway. Receiving such a large address space makes it very difficult in the justification side of things (some would have no choice but to lie on the application, just to get ANY IPv6 addresses). I only received the allocation because of the designation that I have (ISP). Yes, we provide Internet services, but in terms of size, I'm no where near even that of 'enterprise'. I'll never use the IP's, so apparently, I'll be hoarding them. In regard to Bill's second statement above, it sounds like a lot of people are doing exactly this (damning them as hoarders) for legacy IPv4 holders...doesn't it? When push comes to shove, why would one give up what was given to them, especially when they vehemently tried to state it wasn't warranted/needed. (I know this is going OT, but an opinion would be nice) Although we (the small SP's) have signed a v6 RSA, are we going to get the same ridicule and harassment in the future that the Legacy IPv4 folk are seeing today? If this is the case, then I feel for the legacy folk. I explicitly tried to get a smaller chunk of the IPv6 pie, but alas, the request was futile. I understand that the routing table growth is the failing point of v6, so I know *why* I have such a large space, but it is really upsetting when people are already using the word 'hoarding' when some of us can not get a space suitable for our size, but receive something that is exponentially beyond the scope of comprehension, let alone above suitable. Steve From briand at ca.afilias.info Mon Oct 22 19:20:01 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Mon, 22 Oct 2007 19:20:01 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <20071022160654.GS23649@shell01.cell.sv2.tellme.com> References: <471CC069.6040005@arin.net> <20071022160654.GS23649@shell01.cell.sv2.tellme.com> Message-ID: <471D3021.5080606@ca.afilias.info> David Williamson wrote: > On Mon, Oct 22, 2007 at 11:23:21AM -0400, Member Services wrote: > >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> Policy Proposal Name: IPv6 Assignment Size Reduction >> > > I am entirely against this proposal. > > As others have noted, this flies in the face of existing IETF standards > and recommendations. The vast majority of existing LLA implementations > expect the /64 boundary to be enforced, and EUI-48 isn't generally > implemented, while EUI-64 is. (I'll also note that DHCP6 is still > primitive, to my mild annoyance.) > Neither this proposal, nor the proposed IETF change, in any way impacts use of EUI-64 for Link Local addressing. And, the IETF RFCs are *very* specific about not tying any other addressing implementations to LLA. In particular, short-cuts on Interface Identifiers are officially scorned, and DAD specifically identifies that Link Local is not a good enough check. You always have to do DAD - because topologies may have changed. > Let me expand on that. End-sites and their efficiency are essentially > irrelevant to the overall numbering and routing scheme in v6. Again, > hosts just don't matter, and all that counts for anything is the number > of subnets. > No, there are three things that matter, if you are the ISP giving out the subnets: - the number of subnets - the size of the subnets - the ability to allocate subnets in a manner that permits internal aggregation It's all relative. If you have a big PA block, then only the *relative* size of the end-site assignments matters. But, it *does* matter, at least, that the relationship between PA and end-site size, is a difference of enough bits to aggregate. If you have a /12, you would be happy giving out /32's. But, if you had a /28, you would not be so happy giving out /32's. If you had a /28, you would be happy giving out /48's. But if you had a /44, you would not be happy giving out /48's. (I think you can spot the trend here.) > We need to stop thinking about how many hosts we > can squeeze into a network, Hosts/network is irrelevant. If that was the issue, I would not have proposed use of EUI-48 for auto-configuration. I would have recommended getting rid of auto-configuration. I think auto-configuration has definite uses. I do not thing presuming everyone will use it is a good way to set policy. And I do not think universally using EUI-64 for auto-configuration is helpful - which is why I am working on the IETF end of things as well. > If we collectively get out of v4 mindset, we can do some seriously > creative things in v6. This is not an IPv4 mindset. It is a *CIDR* mindset, something which on the routing side has been very helpful. Not just on the address assignment side of things, but on routing aggregation and routing policy, scalability inside networks as well as outside. Prior to CIDR, IPv4 routers could not have scaled to handle all the prefixes currently announced. Class C space was 32 /16 equivalents, or ~2M routes. > Let's not reimpose v4 restrictions on the > world, which is exactly what this proposal does. Yes, we're not being > super efficient with number policy, but that's not what we need at this > point in time. If, 50 years from now, we're running low on address > space, things will certainly change. It's presumptuous of us to think > that we know how this is really going to work out over that kind of > time period, though. > If you read the proposal, you'd realize it has nothing to do with the end-site or end-user usage, prefix count, or anything - it has to do with aggregation on the ISP's network, and on DFZ routing table slots. Aggregation is important to ISP routing table slots. Both internal and external routes eat up slots, which are a precious and largely non-renewable resource. > Again, for clarity, I really really oppose this policy proposal. > I'm all for change, and welcome all comers to change their view, once clarification on what has been proposed is made. You don't need to tell me, but if you change your mind, the PPML list would likely want to hear about it. Brian From arin-contact at dirtside.com Mon Oct 22 20:11:06 2007 From: arin-contact at dirtside.com (William Herrin) Date: Mon, 22 Oct 2007 20:11:06 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <471CC069.6040005@arin.net> References: <471CC069.6040005@arin.net> Message-ID: <3c3e3fca0710221711n44236505p546a41c80a3b37cc@mail.gmail.com> On 10/22/07, Member Services wrote: > Policy Proposal Name: IPv6 Assignment Size Reduction Brian, I would suggest that the appropriate venue for this would be updates to the various RFCs that Leo listed. If and only if such updates are published should ARIN consider recommending the use of prefixes longer than /64 for end-user networks. Even then, this belongs in a best practices or guidelines document, not in the NRPM. On the flip side, ARIN should avoid instructions which imply that /64 is the required minimum size for end users. Burning a /64 for every basement was an incredibly bone-headed idea. Worse, exposing your MAC address to the world in every single packet (as autoconf does) is a privacy and security nightmare. Who needs cookies any more? I'll just track the lower 64 bits of your IP address. Stateless autoconf and /64 for the lan will eventually go down in flames. Its not appropriate for ARIN to usurp the IETF's role and drive that process but there's no reason for us to be among the folks who look foolish for it. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From michael.dillon at bt.com Tue Oct 23 01:53:41 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 23 Oct 2007 06:53:41 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> Message-ID: > I'll never use the IP's, so apparently, I'll > be hoarding them. People who understand IPv6 architecture would not consider this "hoarding". If you announce that /32 then you are "using" the addresses that you were allocated, as they were meant to be used. > Although we (the small SP's) have signed a v6 RSA, are we > going to get the same ridicule and harassment in the future > that the Legacy IPv4 folk are seeing today? Unlikely because in the future, people will better understand the IPv6 architecture. It was the intent of the architects to allocate/assign every organization (and private residence) more IPv6 addresses than they could ever use. This solves part of the renumbering problem; the part caused by changing the prefix length due to growth of your network. IPv6 addresses are assigned to interfaces, not to hosts. The number of interfaces per host is growing and can be expected to continue to grow for some time as virtualization becomes a core part of operating systems. You may use more IPv6 addresses than you think. > If this is the case, then I feel for the legacy folk. I > explicitly tried to get a smaller chunk of the IPv6 pie, but > alas, the request was futile. Indeed it was futile because there is no shortage of IPv6 addresses, therefore no need to conserve them. And conserving IPv6 addresses leads to WASTAGE of slots in the global routing table. By accepting more IPv6 addresses than you will ever need you are helping to conserve space in the global routing table which is a more valuable resource, and has constraints which can't be wiped away by adding bits to the address. > but it is really upsetting when > people are already using the word 'hoarding' I agree. On the other hand, these people are demonstrating their ignorance. Whenever you get a sea change like this, some people are so steeped in the old ways that they will never change. They are like the buggy whip manufacturers who don't understand what all the fuss is about noisy, smelly and unreliable horseless carriages. They are convinced that the new thing is a fad and the fuss will all blow over, so they stick to the knitting and keep making top-notch buggy whips. This is one of the facts of life. You have to choose whether you go along with the flow, or try to resist and stick with tradition. In the case of IPv4, it is likely to be in widespread use for another 20 years, at first on the Internet, and later in private networks. You could spend the rest of your career with IPv4 and ignore IPv6 entirely. But most of us, have to go along with the flow because that is where the network growth will be, starting in 2 or 3 years from now. --Michael Dillon P.S. The virtualization trend that I mentioned, may cause IPv4 address exhaustion to happen sooner than we think. From ipng at 69706e6720323030352d30312d31340a.nosense.org Tue Oct 23 06:02:48 2007 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Tue, 23 Oct 2007 19:32:48 +0930 Subject: [ppml] Use of HD ratios (esp. 0.94) In-Reply-To: References: <47129B68.3070009@arin.net> <05E517B2-1DD8-4D0A-A011-99979A7DA69E@antel.net.uy> <49759.192.35.166.161.1192664444.squirrel@look.libertyrms.com> <49853.192.35.166.161.1192726709.squirrel@look.libertyrms.com> <008f01c811d8$f6df5a20$82a723c0@atlanta.polycom.com> <50228.192.35.166.161.1192749459.squirrel@look.libertyrms.com> <4717FBCE.9080608@internap.com> <50356.192.35.166.161.1192756184.squirrel@look.libertyrms.com> <471806DB.2020907@internap.com> <50471.192.35.166.161.1192760759.squirrel@look.libertyrms.com> Message-ID: <20071023193248.7dab46d3.ipng@69706e6720323030352d30312d31340a.nosense.org> On Fri, 19 Oct 2007 12:53:01 -0400 (EDT) Jon Lewis wrote: > On Fri, 19 Oct 2007 michael.dillon at bt.com wrote: > > >> In terms of allocation efficiency, and utilization requirements, using > >> HD-56 instead of some other kind of HD, unfairly penalizes > >> those who act as good "Internet citizens", and allocate > >> longer prefixes to customers. > > > > Those are BAD Internet citizens who are not following the basic > > architecture of IPv6 which attempts to give each level of allocation, > > more addresses than they could ever need. /48 does that for end user > > networks, and it can be argued that /56 maintains that for residential > > end users. > > After years of having to be conservative with IPv4 space, I think its just > hard for some of us to wrap our heads around the idea of giving customers > such astronomical numbers of IPv6 IPs. 2^64, if you don't do the > silly autoconf that wastes half the IPv6 space, is just an insane number > of IPs. 18.4 trillion million if I did the math right. > How do you cope with 48 bit MAC addresses! 2^46 unicast MAC addresses on a on a link! That's absurd! Who'd ever plug in even half that many devices? Would even plug in 2^16 devices? And they decided that in 1981! What were they thinking!? (Plug and play convenience - and that's what's being aimed for with IPv6) ;-) ("48-bit Absolute Internet and Ethernet Host Numbers" is the paper you want if you're interested in the details) Regards, Mark. From michael.dillon at bt.com Tue Oct 23 09:08:43 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 23 Oct 2007 14:08:43 +0100 Subject: [ppml] Economist at the ARIN meeting Message-ID: I have been told that an economist made a presentation at the meeting in Albuquerque. If this is true, who was the economist and where can I find a copy of the presentation? ------------------------------------------------------- Michael Dillon RadianzNet Capacity Management -- BT Design 66 Prescot St., London, E1 8HG, UK Mobile: +44 7900 823 672 Internet: michael.dillon at bt.com Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 http://www.btradianz.com One Community One Connection One Focus From bmanning at vacation.karoshi.com Tue Oct 23 10:03:29 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 23 Oct 2007 14:03:29 +0000 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> Message-ID: <20071023140329.GA23317@vacation.karoshi.com.> On Tue, Oct 23, 2007 at 06:53:41AM +0100, michael.dillon at bt.com wrote: > > I'll never use the IP's, so apparently, I'll > > be hoarding them. > > People who understand IPv6 architecture would not consider this > "hoarding". If you announce that /32 then you are "using" the addresses > that you were allocated, as they were meant to be used. aha! clearly then you are enabling folks to forge packets w/ source addresses you are announcing but for which there is no PCB to accept/emit IP datagrams. announcement does not, IMHO, equate to use - at least in my network. --bill From tvest at pch.net Tue Oct 23 10:59:01 2007 From: tvest at pch.net (Tom Vest) Date: Tue, 23 Oct 2007 16:59:01 +0200 Subject: [ppml] Economist at the ARIN meeting In-Reply-To: References: Message-ID: <1EE00034-1194-453F-98BD-E67AD7405C6E@pch.net> It was Ben Edelman, who has been engaged as a consultant by ARIN. He spoke on the "IP Markets?" panel, without slides. TV On Oct 23, 2007, at 3:08 PM, wrote: > > I have been told that an economist made a presentation at the > meeting in > Albuquerque. If this is true, who was the economist and where can I > find > a copy of the presentation? > > ------------------------------------------------------- > Michael Dillon > RadianzNet Capacity Management -- BT Design > 66 Prescot St., London, E1 8HG, UK > Mobile: +44 7900 823 672 > Internet: michael.dillon at bt.com > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > http://www.btradianz.com > > One Community One Connection One Focus > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the > ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From info at arin.net Tue Oct 23 13:36:37 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:36:37 -0400 Subject: [ppml] Policy Proposal 2007-19: IANA Policy for Allocation of ASN Blocks to RIRs - Last Call Message-ID: <471E3125.7090601@arin.net> Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_19.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs Author: Axel Pawlik Proposal type: New Policy term: renewable Policy statement: Abstract This document describes the policy governing the allocation of Autonomous System Numbers (ASNs) from the IANA to the Regional Internet Registries (RIRs). This policy document does not stipulate performance requirements in the provision of services by the IANA to an RIR. Such requirements will be specified by appropriate agreements between ICANN and the Number Resource Organization (NRO). 1. Allocation Principles IANA allocates ASNs to RIRs in blocks of 1024 ASNs. In this document the term "ASN block" refers to a set of 1024 ASNs. Until 31 December 2009, allocations of 2-byte only and 4-byte only ASN blocks will be made separately and independent of each other [1]. This means until 31 December 2009, RIRs can receive two separate ASN blocks, one for 2-byte only ASNs and one for 4-byte only ASNs from the IANA under this policy. After this date, IANA and the RIRs will cease to make any distinction between 2-byte only and 4-byte only ASNs, and will operate ASN allocations from an undifferentiated 4-byte ASN allocation pool. 2. Initial Allocations Each new RIR will be allocated a new ASN block. 3. Additional Allocations An RIR is eligible to receive (an) additional ASN block(s) from the IANA if one of the following conditions is met: 1. The RIR has assigned/allocated 80% of the previously received ASN block, or 2. The number of free ASNs currently held by the RIR is less than two months need. This projection is based on the monthly average number of ASNs assigned/allocated by the RIR over the previous six months. An RIR will be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months, based on their average assignment/allocation rate over the previous six months, unless the RIR specifically requests fewer blocks than it qualifies for. 4. Announcement of IANA Allocations The IANA, the NRO and the RIRs will make announcements and update their respective websites/databases when an allocation is made by the IANA to an RIR. ICANN and the NRO will establish administrative procedures to manage this process. [1. http://www.ripe.net/ripe/policies/proposals/2005-12.html] Rationale: There are global policies governing the allocation of IPv4 and IPv6 blocks from the IANA to RIRs. At this point there is no specific policy regarding the allocation of Autonomous System Numbers from the IANA to the RIRs. This proposal will create a policy to fill this gap. The criteria being proposed has already been the practice between IANA and RIRs so far and it has been proven to work. It is designed to allow RIRs to request ASN blocks from the IANA in a timely fashion and maintain enough ASNs in holding to ensure that their registration services can be sustained. It is also proposed that the RIRs be allocated as many ASN blocks as are needed to support their registration needs for the next 12 months. This will generally mean that each RIR will only need to make one ASN request from the IANA each year, thus lowering operational overhead for the RIRs. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:36:50 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:36:50 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call Message-ID: <471E3132.7000808@arin.net> Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the amended proposal and moved it to last call. The policy text was amended from "a direct IPv4 assignment or allocation" to "all direct IPv4 assignments or allocations." The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_21.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-21 PIv6 for legacy holders with RSA and efficient use Author: Scott Leibrand Proposal type: new Policy term: permanent Policy statement: Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user organizations: Criteria), to read: To qualify for a direct assignment, an organization must: 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments or allocations covered by a current ARIN RSA. Rationale: Current policy allows direct IPv6 allocations and assignments to nearly all organizations with IPv4 allocations or assignments from ARIN. As a result, such organizations can get IPv6 space just as easily as they can get IPv4 space, making it easy for them to transition to IPv6 as soon as they're ready to do so. However, there are some organizations who received IPv4 /23's and /24's prior to the formation of ARIN, and use that space in a multihomed, provider-independent fashion. Under current policy, such organizations cannot get IPv6 PI space without artificially inflating host counts, and are therefore discouraged from adopting IPv6. This policy proposal aims to remove this disincentive, and allow such organizations to easily adopt IPv6. In addition, pre-ARIN assignments were issued through an informal process, and many legacy resource holders have not yet entered into a formal agreement with ARIN, the manager of many such IP numbering resources. This policy proposal would require that such assignments be brought under a current ARIN Registration Services Agreement, thereby formalizing the relationship. Some pre-ARIN assignments may not be used efficiently. As unallocated IPv4 numbering resources are approaching exhaustion, it is important to ensure efficient utilization of IPv4 assignments, and to arrange for reclamation of unused space. Therefore, this policy would require that the organization wishing to receive IPv6 PI space demonstrate efficient utilization of their IPv4 assignment. (Efficient utilization is already defined elsewhere in policy, and the exact mechanism for achieving and determining efficient use is a matter of procedure, not of policy, so detailed procedures are not included in the policy statement above. The intent is that any organization with an assignment of /23 or larger which is less than 50% utilized would renumber and return whole unused CIDR blocks as necessary to bring the remaining CIDR block to 50% utilization or higher. A /24 should be considered efficiently utilized as long as it is in use for multihoming, as /25's and smaller are not routable for that purpose.) It has been suggested that this policy would be useful only until the growth of IPv6 exceeds the growth of IPv4. I would agree with this, and would further posit that the existing "qualify ... under the IPv4 policy currently in effect" language should also be modified at that time. I have therefore proposed this policy with a policy term of "permanent", with the expectation that this section of policy (6.5.8.1) will be rewritten at the appropriate time to entirely remove all IPv4 dependencies. Timetable for implementation: immediate From info at arin.net Tue Oct 23 13:37:02 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:02 -0400 Subject: [ppml] Policy Proposal 2007-22: Expand timeframe of Additional Requests - Last Call Message-ID: <471E313E.3070408@arin.net> Policy Proposal 2007-22 Expand timeframe of Additional Requests The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_22.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-22 Expand timeframe of Additional Requests Author: Dan Alexander Proposal type: modify Policy term: permanent Policy statement: The proposal is to modify section 4.2.4.4 of the NRPM Current wording: "After a subscriber has been a member of ARIN for one year they may choose to request a six-month supply of IP addresses." Change to: "After an organization has been an ARIN member in good standing for one year, they may choose to request up to a 12 month supply of IP addresses." Rationale: Currently, all RIR's provide organizations with at least a 12 month supply of IPv4 address space when making subsequent requests, with the exception of the ARIN region. The primary reason for this change is for continuity among all RIR. In doing so, all established organizations have a more consistent access to IP resources. The adjustment does not change demand on IPv4 address space. It only changes the frequency in which established organizations need to request address space. This would allow for fewer potential aggregates allocated to an organization providing more consolidated routing announcements. This does not change the requirement on new organizations where established growth trends have yet to be established. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:37:14 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:14 -0400 Subject: [ppml] Policy Proposal 2007-25: IPv6 Policy Housekeeping - Last Call Message-ID: <471E314A.2010201@arin.net> Policy Proposal 2007-25 IPv6 Policy Housekeeping The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is community consensus in favor of the proposal and moved it to last call. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_25.html Comments are encouraged. All comments should be provided to ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 November 2007. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-25 IPv6 Policy Housekeeping Author: Leo Bicknell Proposal type: modify Policy term: permanent Policy statement: Change I: In section 6.5.1.1.d, replace the existing statement with the new statement: "be an existing, known ISP in the ARIN region or have a plan for making at least 200 end-site assignments to other organizations within 5 years." Change J: Remove section 6.5.3 entirely. Update all subsequent sections to have new section numbers (6.5.[n-1]). Replace part of the text as (new) section 6.5.4.4: "All /56 and larger assignments to end sites are required to be registered either by the LIR or its subordinate ISPs in such a way that the RIR/NIR can properly evaluate the HD-Ratio when a subsequent allocation becomes necessary." Change K: Section 6.5.8.2, add the following sentence to the end of the first paragraph: "An HD-Ratio of .94 must be met for all assignments larger than a /48." Add to the end of the second paragraph: "This reservation may be assigned to other organizations later, at ARIN's discretion." Change L: Section 6.5.8.3, add a sentence between the two existing sentences: "Justification will be determined based on the .94 HD-Ratio metric." Rationale: When the IPv6 policy was passed, it was considered to be an "interim" policy, and it was intended to be similar in all 5 RIR's. Since that time it has become clear the policy is no longer interim (and proposal 2007-4 was passed to change just that) and it has also been modified separately in the different RIR's. It was brought to the ARIN AC's attention that there were a number of problems with "Section 6" of the NRPM as a result of this legacy: * The policy contained a large number of items that were not policy. * The policy contained a few items that were self contradictory. * The added text was redundant in some cases with existing text. * The policy was overly vague in a few areas, leaving ARIN staff to have to make interpretations of what the policy intended. * Policy changes made since the initial IPv6 policy was adopted have not always updated all of the relevant sections due to the complexity of section 6. The intent of these changes is not to change any existing policy, but rather to remove all non-policy items, and update any ambiguous items with the way that ARIN staff is currently interprets the policy. Change I: Proposal 2005-8 amended section 6.5.4.1 to allow /56 and /64 allocations, but section 6.5.1.1.d was never updated to match the change. It is believed the intent of the policy, and ARIN staff's current interpretation of the policy match the updated text. Change J: The first part is not policy, and incorrectly states there is no policy as section 6.5.4 has the policy in it. Take the one useful part and make it part of the 6.5.4 criteria. Change K: No metric is currently listed to justify a larger initial assignment. It is believed ARIN staff is currently applying the HD-Ratio similar to the ISP policy, this puts that in writing. Make it clear that the reservation may not exist in perpetuity. Change L: No metric is given to justify additional assignments. It is believed that ARIN staff is currently applying the HD_Ratio similar to the ISP policy, this puts that in writing. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:37:27 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:27 -0400 Subject: [ppml] Policy Proposal 2007-16: IPv4 Soft Landing - Revise Message-ID: <471E3157.2090806@arin.net> Policy Proposal 2007-16 IPv4 Soft Landing The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_16.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-16 IPv4 Soft Landing Author: David Conrad Proposal type: New Policy term: Permanent Policy statement: This policy is intended to replace section 4.2.4.1 of the ARIN Number Resource Policy Manual with wording substantially along the lines of: --- begin modification --- 4.2.4.1 In order to encourage a smooth transition to IPv6, ARIN has instituted a set of IPv4 Address Allocation "phases" that vary the requirements for address allocation using the amount of address space remaining unallocated by IANA as a metric. As the amount of address space in the IANA free pool is reduced, the requirements for IPv4 address allocation are made more stringent. When requesting additional IPv4 address space, ISPs must meet the requirements of the IPv4 Address Allocation phase ARIN was in when the request was submitted. These phases will require the requester to demonstrate increasingly efficient utilization of previously allocated IPv4 address space, including all space reassigned to their customers. In addition, depending on the IPv4 Address Allocation phase ARIN was in when the request was submitted, there may be additional requirements that will need to be met by the requester such as completing a survey on IPv6 deployment plans, documentation of non-private address space used for internal infrastructure, documentation of IPv6 plans for offering connectivity and services, etc. The reassignment information section of the ARIN ISP Network Request Template should be completed for all address blocks that have been allocated to your organization. In the template, line 1b. Assigned: information will be verified via SWIP/RWHOIS and 1c. Reserved: should be used to indicate internal network information. Please note that until all requirements are met and your prior utilization is verified to meet the requirements specified in the IPv4 Address Allocation phase in which the request was received, ARIN can neither process nor approve a request for additional addresses. IPv4 Allocation Phases The thresholds and the requirements to justify an allocation of new IPv4 address space from ARIN are defined in this section. Phase: 0 Threshold: Greater than 40 /8s Requirements: Requesters must: * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization Phase: 1 Threshold: 40 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 80% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 25% utilization - Demonstrate a one year requirement of 50% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. Phase: 2 Threshold: 25 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 85% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 50% utilization - Demonstrate a one year requirement of 75% utilization * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure and how it is used. * Provide plans for migrating all non-RFC 1918 address space used for internal infrastructure either to IPv6 (preferred) or to private addressing where possible. Where such migration is not possible, provide documentation listing the use of addresses that are not migratable and the reasons for the inability to migrate. * Demonstrate documented plans for availability of production IPv6 infrastructure and connectivity services within 6 months of submitting the request. Phase: 3 Threshold: 10 /8s Requirements: Requesters must: * Provide a response to a survey (individual responses to be held in confidence by ARIN staff) exploring requester IPv6 transition plans and impediments, anonymized summary data of which may be published by ARIN. * Demonstrate efficient utilization of 100% of all previous IPv4 allocations and at least 90% utilization of the most recent allocation. * For downstream customers: - Demonstrate an immediate requirement of 75% utilization - Demonstrate a one year requirement of 90% utilization * Provide documentation demonstrating migration (where possible) of non-RFC 1918 address space used for internal infrastructure to either IPv6 (preferred) or private addressing. * Provide a detailed listing of all non-RFC 1918 address space used for internal infrastructure, how it is used, and why it is not possible to migrate those addresses to either IPv6 (preferred) or private addressing. * Demonstrate availability of production IPv6 infrastructure and connectivity services. Notes: * Phase 0 reflects current allocation requirements. * Phases 1 through 3 are to be implemented 30 days after IANA allocates address space from the IPv4 free pool that reduces that free pool to a number of /8s that are at or below the threshold specified. * If multiple thresholds should be crossed within a 30 day period, the requirements from the last threshold crossed will be applied to requesters for additional address space at the time of the request. --- end modification --- Rationale: The rationale for this proposal is threefold: * to prolong the availability of IPv4 addresses for requesters who can provide sufficient justification; * to encourage the deployment of IPv6 as an alternative to IPv4 by making the requirements to justify IPv4 allocations increasingly stringent over time; * to promote the more efficient use of increasingly scarce IPv4 resources. As the lack of significant deployment of IPv6 can attest, the cost of deploying IPv6 currently outweighs the benefits that protocol would appear to provide. This proposal aims to encourage the deployment of IPv6 by over time, making the allocation of IPv4 both more difficult and contingent on the requester demonstrating both support for IPv6 as well as requiring a demonstration that the IPv4 address space they administer is being used efficiently. The goal of these measures is to rebalance the IPv6 deployment cost/benefit ratio thereby encouraging greater uptake of IPv6 before the IPv4 free pool is exhausted. The "IPv4 Soft Landing" policy aims to provide for a smoother transition away from IPv4 towards IPv6 by imposing increasingly strict requirements for new address allocations as the amount of address space available in the IANA unallocated IPv4 address pool decreases. These increased requirements include both more stringent reassignment and utilization percentages as well as requiring documented IPv6 infrastructure services and connectivity provision and the documentation or reuse of public IPv4 address space used for internal infrastructure. The increased stringency in the allocation requirements is intended both to increase the efficiency of utilization of the IPv4 address space and to reduce the likelihood of a "run" on the remaining free pool of IPv4 address space. ARIN staff would be expected to use the same mechanisms in use today to verify conformance to the specified requirements. The requirements for demonstration of IPv6 infrastructure services and connectivity are intended to motivate ISPs to provide those services before the only address space they can offer their customers is IPv6, thereby offering an opportunity to break the "chicken-and-egg" problem limiting significant IPv6 deployment. Verification of these requirements can be done by ARIN staff by using IPv6 transport to connect to published services of the ISP (e.g., DNS servers, WWW URLs, etc.) as well as using IPv6 ping to identified addresses internal to the ISP. Obviously, false positive responses for most any objective mechanism for verifying the availability can be engineered, so ARIN staff may also consider subjective reports of an inability to obtain IPv6 services by customers as an indicator of (lack of) conformance to this requirement. The requirements to migrate internal infrastructure to either IPv6 or private (e.g., RFC 1918) addressing are intended to improve the efficiency of utilization of IPv4 address space, reserving the scarce IPv4 resources for purposes for which IPv6 or private addresses are not suitable. These requirements acknowledge that pragmatically, the use of IPv4 is absolutely essential only for servers in client-server architectures, machines engaged in peer-to-peer applications, and entry points for NAT/ALG devices. As such, use of IPv4 for purposes such as router interface numbering, client-only devices, and devices which should not be available from external networks should be discouraged. Since there can be circumstances in which migration of internal infrastructure addresses to private addressing would not be feasible, this policy allows for requesters to document those situations in which it is not possible to do the migration. The time for transition between phases of this policy are not fixed, rather they depend on the rate of consumption of IPv4 address space from the IANA free pool. Current RIR operational procedure is to request 2 /8s from the IANA when the RIR's current pool of free IPv4 address space is depleted. This procedure should ensure transitions between phases will have some lead-time, so organizations can prepare for the next phase of IPv4 address allocation. Given the highly volatile nature of IPv4 consumption and the inability to define a predictive model rooted in an underlying theory rather than extrapolating over existing data, the thresholds chosen are acknowledged to be somewhat arbitrary. The intent of the chosen values is to provide a "reasonable" amount of time, approximately 18 months, between transitions at current consumption rates (approximately 10 /8s per year). However, it should be explicitly noted that one of the intents of this policy is to extend the IPv4 free pool lifetime, thus as the policy becomes effective, the amount of time between phase transitions would presumably increase. Timetable for implementation: Immediately upon approval of this policy by the ARIN Board of Trustees. From info at arin.net Tue Oct 23 13:37:39 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:39 -0400 Subject: [ppml] Policy Proposal 2007-23: End Policy for IANA IPv4 allocations to RIRs - Revise Message-ID: <471E3163.3060502@arin.net> Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_23.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-23 End Policy for IANA IPv4 allocations to RIRs Author: JPNIC IPv4 countdown policy team; Akinori MAEMURA, Akira NAKAGAWA, Izumi OKUTANI, Kosuke ITO, Kuniaki KONDO, Shuji NAKAMURA, Susumu SATO, Takashi ARANO, Tomohiro FUJISAKI, Tomoya YOSHIDA, Toshiyuki HOSAKA Proposal type: new Policy term:renewable Policy statement: 1) Distribute a single /8 to each RIR at the point when new IANA free pool hits 5 */8. This date is defined as "IANA Exhaustion Date". 2) It should be completely left up to each RIR communities to define a regional policy on how to distribute the remaining RIR free pool to LIRs within their respective regions after "IANA Exhaustion Date". Note 1: It is fine for an RIR to continue operations with the existing policy if that is the consensus decision of the respective RIR community. Note 2: Address recovery and re-distribution of recovered address space is another important measure for considerations, but should be treated as a separate policy proposal from distribution of new IANA pool. 3) RIRs should provide an official projection on IANA Exhaustion Date to the community through their website, at their Policy Meetings and through any other effective means. Rationale: [current problem] There are two major issues in terms of address management if no measures are taken for IPv4 address exhaustion. 1) Continue applying a global coordinated policy for distribution of the last piece(s) of RIR's unallocated address block does not match the reality of the situation in each RIR region. Issues each RIR region will face during the exhaustion period vary by region as the level of development of IPv4 and IPv6 are widely different. As a result, applying a global co-ordinated policy may not adequately address issues in a certain region while it could be work for the others. For example, in a region where late comers desperately need even small blocks of IPv4 addresses to access to the IPv4 Internet, a policy that defines the target of allocations/assignments of IPv4 address space to be late comers would be appropriate in such region. This would allow availablilty of IPv4 address space for such requirements for more years. Another example comes from difference in IPv6 deployment rate. For a region where IPv6 deployment rate is low, measures may be necessary to prolong IPv4 address life for the existing business as well as for new businesses until networks are IPv6 ready. Some regions may have strong needs to secure IPv4 address space for translators. A globally coordinated policy which addresses all the issues listed above to meet the needs for all RIR regions may result in not solving issues in any of the regions. 2) LIRs and stakeholders remain unprepared for the situation if they are not informed If LIRs and the community are uninformed of the exhaustion, their services and networks remain unprepared to face the situation at the time of exhaustion. [Objective of the proposal] This proposal seeks to provide the following solutions to the problems listed above. 1) RIR community should be able to define their own regional policies on how to assign the last piece(s) of allocation block in order to address their own regional issues during the exhaustion period. 2) RIRs should provide official projection of the date when LIRs will be able to receive the allocations under the current criteria. The criteria should remain consistent until this date in order to avoid confusion. [Pros and Cons] Pros: + It allows each RIR community to define a policy on how to distribute the last piece(s) of allocations which best matches their situation. + It helps LIR better informed of the date when they are able to receive allocations from RIRs under the current criteria and prepare for the event. Cons: + Concerns could be raised about allocating a fixed size to all RIRs, that it artificially fastens the consumption rate of some RIR regions. However, its impact is kept to minimum by keeping the allocation size to a single /8 which makes merely 3-4 months difference. + Concerns could be raised that explicitly allowing regional policies will encourage RIR shopping. However, this should not happen if the requirements within each region is adequately reflected in each RIR's policy through PDP. RIR may also chose to add criteria to prevent LIRs from other regions submitting such requests. Timetable for implementation: Immediate after all 5 RIRs (and possibly ICANN) ratifies the policy. From info at arin.net Tue Oct 23 13:37:51 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:37:51 -0400 Subject: [ppml] Policy Proposal 2007-17: Legacy Outreach and Partial Reclamation - Revise Message-ID: <471E316F.7050206@arin.net> Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_17.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-17 Legacy Outreach and Partial Reclamation Author: Owen DeLong Proposal type: modify Policy term: permanent Policy statement: Modify section 4.6 as follows: 4.6 Amnesty Requests ARIN will accept the return or relinquishment of any address space from any existing address holder. If the address holder wishes to aggregate into a single block, ARIN may work with the address holder to arrive at an allocation or assignment which is equal to or smaller than the sum of their existing blocks and which best meets the needs of the existing holder and the community. There shall be no fee for returning addresses under this policy. Further, organizations returning addresses under this policy shall receive the following benefits: 1. If the organization does not currently pay ARIN fees, they shall remain fee exempt. 2. If the organization currently pays ARIN fees, their fees shall be waived for two years for each /20 equivalent returned, with any fractional /20 equivalent resulting in a one-time single year waiver. 3. Any organization returning address space under this policy shall continue under their existing RSA or they may choose to sign the current RSA. For organizations which currently do not have an RSA, they may sign the current RSA, or, they may choose to remain without an RSA. 4. All organizations returning space under this policy shall, if they meet other eligibility requirements and so request, obtain an appropriate IPv6 end-user assignment or ISP allocation as applicable, with no fees for the first 5 years. Organizations electing to receive IPv6 allocation/assignment under this provision must sign a current RSA and must agree that all of their IPv4 resources are henceforth subject to the RSA. Organizations taking this election shall be subject to end-user fees for their IPv4 resources not previously under an ARIN RSA. If they are already an ARIN subscriber, then IPv4 resources affected by this process may, instead, be added to their existing subscriber agreement at the address holder's discretion. Rationale: The current amnesty policy does a nice job of facilitating aggregation, which was the intent when it was drafted. However, as we approach IPv4 free-space exhaustion, the community now has an additional need to facilitate address reclamation. A very high percentage of underutilized space is in the hands of legacy holders who currently have no benefit to joining the ARIN process. Further, there is an unfortunate perception that doing so will require force the legacy holder into certain future disadvantages. This proposal attempts to resolve both of those issues while also providing some incentive to legacy organizations to start using IPv6 resources and bring their IPv4 resources into the ARIN process. This policy attempts to provide some benefit and remove most of the costs of making partial IPv4 returns. It also attempts to provide an incentive for these IPv4 holders to join the ARIN process. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:38:04 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:04 -0400 Subject: [ppml] Policy Proposal 2007-14: Resource Review Process - Revise Message-ID: <471E317C.7090305@arin.net> Policy Proposal 2007-14 Resource Review Process The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_14.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-14 Resource Review Process Author: Owen DeLong, Stephen Sprunk Proposal type: modify Policy term: permanent Policy statement: Add the following to the NRPM: Resource Review 1. ARIN may review the current usage of any resources issued by ARIN to an organization. The organization shall furnish whatever records are necessary to perform this review. 2. ARIN may conduct such reviews: a. when any new resource is requested, b. whenever ARIN has cause to believe that the resources had originally been obtained fraudulently, or c. at any other time without cause unless a prior review has been completed in the preceding 12 months. 3. ARIN shall communicate the results of the review to the organization. 4. If the review shows that existing usage is substantially not in compliance with current allocation and/or assignment policies, the organization shall return resources as needed to bring them substantially into compliance. If possible, only whole resources shall be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. 5. If the organization does not voluntarily return resources as required, ARIN may revoke any resources issued by ARIN as required to bring the organization into overall compliance. ARIN shall follow the same guidelines for revocation that are required for voluntary return in the previous paragraph. 6. Except in cases of fraud, an organization shall be given a minimum of six months to effect a return. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. 7. ARIN shall continue to maintain the resource(s) while their return or revocation is pending, except no new maintenance fees shall be assessed for the resource(s). 8. Legacy resources in active use, regardless of utilization, are not subject to revocation by ARIN. However, the utilization of legacy resources shall be considered during a review to assess overall compliance. Delete NRPM sections 4.1.2, 4.1.3, 4.1.4 Remove the sentence "In extreme cases, existing allocations may be affected." from NRPM section 4.2.3.1. Policy Rationale Rationale: ARIN feels that current policy does not give them the power to review or reclaim resources except in cases of fraud, despite this being mentioned in the Registration Services Agreement. This policy proposal provides clear policy authority to do so, guidelines for how and under what conditions it shall be done, and a guarantee of a (minimum) six-month grace period so that the current user shall have time to renumber out of any resources to be reclaimed. The nature of the "review" is to be of the same form as is currently done when an organization requests new resources, i.e. the documentation required and standards should be the same. The renumbering period does not affect any "hold" period that ARIN may apply after return or revocation of resources is complete. The deleted sections/text would be redundant with the adoption of this proposal. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:38:15 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:15 -0400 Subject: [ppml] Policy Proposal 2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space - Abandoned Message-ID: <471E3187.6070409@arin.net> Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), has decided to abandon 2007-18 in favour of working with all the authors of both 2007-18 and 2007-23 to craft a cohesive policy proposal around 2007-23. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html In order for this proposal to be further considered, the author may use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 30 October 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_18.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal 2007-18 Global Policy for the Allocation of the Remaining IPv4 Address Space Author: Roque Gagliano Co-authors: Francisco Obispo, Hytham EL Nakhal, Didier Allain Kla Proposal type: new Policy term: permanent Policy statement: This policy describes the process for the allocation of the remaining IPv4 space from IANA to the RIRs. When a minimum amount of available space is reached, an identical number of IPv4 allocation units (/8s) will be allocated from IANA to each RIR, replacing the current IPv4 allocation policy. In order to fulfill the requirements of this policy, at the time it is adopted, an identical number of IPv4 allocation units (N units) will be reserved by IANA for each RIR. The number N is defined as: 5. The reserved allocation units will no longer be part of the available space at the IANA pool. The process for the allocation of the remaining IPv4 space is divided in two consecutive phases: 1. Existing Policy Phase: During this phase IANA will continue allocating IPv4 addresses to the RIRs using the existing allocation policy. This phase will continue until a request for IPv4 address space from any RIR to IANA cannot be fulfilled with the remaining IPv4 space available at the IANA pool. This will be the last IPv4 address space request that IANA will accept from any RIR. At this point the next phase of the process will be initiated. 2. Exhaustion Phase: IANA will automatically allocate the reserved IPv4 allocation units to each RIR (N units to each one) and respond to the last request with the remaining available allocation units at the IANA pool (M units). 2.1. Size of the final IPv4 allocations: During this phase IANA will automatically allocate N allocation units to each RIR from the reserved space defined in this policy. IANA will also allocate M allocation units to the RIR that submitted the last request for IPv4 addresses. 2.2. Allocation of the remaining IPv4 Address space: After the completion of the evaluation of the final request for IPv4 addresses, IANA MUST: A) Immediately notify the NRO about the activation of the second phase of this policy. B) Proceed to allocate M allocation units to the RIR that submitted the last request for IPv4 address space. C) Proceed to allocate N allocation units to each RIR from the reserved space. Rationale: The IANA pool of allocation units of IPv4 addresses (/8s) is decreasing rapidly. A new policy is proposed to replace the current "on demand" policy in order to bring certainty on how the remaining space will be allocated. This policy eliminates the pressure on the remaining central pool of addresses by allocating equal amount of allocation units (N) to each RIR. RIR may be studying slow-landing policies or the possibility to reserve specific address spaces for "critical infrastructure" or new companies in order to comply with anti-trust regulations in its region. This policy allows each RIR to adopt those policies through its PDP, which is simpler than a global policy discussion process. Each RIR will have the exact information on the amount of address spaces that they will be receiving as a last allocation from the IANA. The policy is written in such a way that the discussion could be split in two sections: first do we agree on the concept of the policy and second what is the appropriate value for the last allocation units N. Timetable for implementation: This is a Global policy that needs to be approved by all RIRs and then ratified by ASO/ICANN. It has already reached consensus at LACNIC meeting. From info at arin.net Tue Oct 23 13:38:27 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:27 -0400 Subject: [ppml] Policy Proposal 2006-7: Changes to IPv6 initial allocation criteria - Abandoned Message-ID: <471E3193.2060700@arin.net> Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that there is not community consensus in favor of the proposal and abandoned it. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html In order for this proposal to be further considered, the author may use the last call petition process as defined in the ARIN Internet Resource Policy Evaluation Process. This policy will be considered to be abandoned if the author of the proposal does not initiate a last call petition by 23:59, Eastern Time, 30 October 2007. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2006-7.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2006-7 Changes to IPv6 initial allocation criteria Proposal type: Insert a new additional line item e. to 6.5.1.1 of NRPM Policy term: permanent Policy statement: New organizations need a policy that allows them to apply for IPv6 address space. To provide this we need to insert a new additional line item to 6.5.1.1. The new line item would be line 'e' as follows: e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPv6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Rationale: - New organizations who do not want to use IPv4 at all and start off using IPv6 addresses only, need a policy that gives them permission to do so. This is also valid for existing companies that may or may not have assigned IPv4 addresses and now want to start offering IPv6 services. These organizations may also wish to request IPv4 at the same time. - One year is given as the sufficient time frame to actually implement usage of the IPv6 address space and reveal if the 'said organization' is truly using the IPv6 space granted. - Every means of documentation that can reveal 'true intent of use' is not listed as this can be a very long list and should be left to the discretion of the RIR staff. - An ISP or LIR may decide to assign a different prefix size than /48. For example, a cellular operator may use /64. - ASN is not required because as long as they are statically routed to an upstream and don't want to run bgp/announce directly to the Internet, they don't need an ASN, therefore we shouldn't create policy that would contribute to ASN bloat. - Organization in this is defined as a Corporation, ISP, LLC et al. In SUMMARY if this policy is implemented the change to the NRPM would read as follows: 6.5.1.1 Initial allocation criteria To qualify for an initial allocation of IPV6 address space, an organization must: a. be a LIR; b. not be an end site; c. plan to provide IPV6 connectivity to which it will assign IPV6 address space, by advertising that connectivity through its single aggregated address allocation; d. be an existing, known ISP in the ARIN region or have a plan for making at least 200/48 assignments to other organizations within five years. e. OR be an organization new to providing internet services, and can justify intent to announce the requested IPV6 address space within one year, through records such as contracts, inventory and/or other applicable documentation. Timetable for implementation: Immediate From info at arin.net Tue Oct 23 13:38:59 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:38:59 -0400 Subject: [ppml] Policy Proposal 2007-15: Authentication of Legacy Resources - Withdrawn Message-ID: <471E31B3.1080309@arin.net> Policy Proposal 2007-15 Authentication of Legacy Resources 2007-15 was withdrawn by the author. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_15.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-15 Authentication of Legacy Resources Author: Andrew Dul Proposal type: New Policy term: Permanent Policy statement: Add new NRPM section 4.9 - Legacy Records 4.9 - Legacy Records Legacy resource record holders shall be permitted to sign a registration services agreement which permits the legacy organization which is currently using the resources as of January 1, 2007 to continue to use those resources as long as a valid registration services agreement is in effect for the organization. ARIN will evaluate and verify the chain of custody of any resource records prior to executing a registration services agreement with an organization. ARIN shall use all reasonable methods to attempt to contact legacy record holders starting on January 1, 2008 to notify them of this change in policy. ARIN shall also post information on the public website regarding this outreach to legacy resource holders. No changes shall be made to legacy resource records which are not covered by a registration services agreement after December 31, 2007. If a legacy resource holder requests additional IPv4 resources all IPv4 resources (legacy and non-legacy) shall be evaluated to determine utilization for additional allocations or assignments under NRPM sections 4.2 or 4.3. Rationale: An ARIN Legacy resource holder is an organization which was issued number resources prior to the formation of ARIN and whose registration information was not transferred to another RIR through the Early Registration Transfer Project (http://www.arin.net/registration/erx). Legacy resource holders were issued number resources through an informal process. This policy proposal attempts to bring these legacy resource holders into a formal agreement with ARIN, the manager of the IP numbering resources for many of the legacy record holders. This policy is similar to a policy which has been adopted in the APNIC region. (http://www.apnic.net/docs/policy/proposals/prop-018-v001.html) Some legacy resource holders have expressed concerns about committing to a registration service agreement (RSA) when the legacy resource holder cannot be assured that they will be permitted to retain their resources for the long-term. This policy proposal requests ARIN to develop a RSA which will allow legacy resource holders to continue to use IPv4 resources which were assigned or allocated prior to ARIN's formation. It is also suggested that the Board of Trustees formalize the annual maintenance fees for legacy resource holders at a level similar to the $100 USD per year for end-sites or provide fee-waivers as an incentive for legacy holders to sign a registration services agreement. The dates in this policy proposal were arbitrarily chosen based upon an expected ratification by the ARIN Board of Trustees by December 31, 2007. If this policy is implemented after December 31, 2007, the trigger dates in the policy should be adjusted appropriately. Given the informal relationship under which the resources were granted, ARIN currently maintains the records including WHOIS and in-addr.arpa delegations in a best-effort fashion. Some believe that ARIN may not be obligated to maintain these records. ARIN has also experienced some difficulty maintaining these records. Legacy records have been a popular target for hijackers, in part due to the out of date information contained in these records. Having up to date contact information and a formal relationship with legacy record holders would assist ARIN and ISP's in insuring these records are maintained accurately. Legacy resource holders who sign a RSA would continue to receive all the services that are currently provided by ARIN plus they would be eligible for any future services that ARIN may offer, such as cryptographic signing of resource records. Timetable for implementation: As stated in policy From info at arin.net Tue Oct 23 13:39:11 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:39:11 -0400 Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User - Withdrawn Message-ID: <471E31BF.8030001@arin.net> Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User 2007-13 was withdrawn by the author. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_13.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ##*## Annex A Policy Proposal 2007-13 Removal of ISP Immediate Need from End-User Author: Rob Seastrom, David Williamson, Owen DeLong Proposal type: delete Policy term: permanent Policy statement: Delete section 4.3.4, which reads: 4.3.4. Additional considerations End-users may qualify for address space under other policies such as Immediate need [4.2.1.6] or Micro-allocation [4.4]. from the NRPM. Rationale: As discussed at ARIN XIX, section 4.3.4 creates a conflict with section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users while section 4.3.4 is specifically for end users. Prior to the development of the multihoming policy for end users, the immediate need policy was required in order to support end users being able to get address space under some circumstances. The "immediate need" title is a misnomer as it is more an issue of "initial need without prior address utilization" than "immediate need". Such initial needs for end users are now addressed best through the multihoming policy. Timetable for implementation: immediate From info at arin.net Tue Oct 23 13:39:24 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 13:39:24 -0400 Subject: [ppml] Policy Proposal 2007-24: IPv6 Assignment Guidelines - Revise Message-ID: <471E31CC.1090501@arin.net> Proposal 2007-24 IPv6 Assignment Guidelines The ARIN Advisory Council (AC), acting under the provisions of the ARIN Internet Resource Policy Evaluation Process (IRPEP), determined that while there is not community consensus in favor of the proposal there is consensus that the proposal should be revised and discussed further. The AC made this determination at their meeting at the conclusion of the ARIN Public Policy meeting on 18 October 2007. The Chair of the AC reported the results of the AC meeting during the Members Meeting. The AC Chair's report can be found at: http://www.arin.net/meetings/minutes/ARIN_XX/mem.html The AC will work with the author of the proposal to revise the text and return the proposal to the PPML for further discussion. The policy proposal text is provided below and is also available at: http://www.arin.net/policy/proposals/2007_24.html The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Proposal 2007-24 IPv6 Assignment Guidelines Author: Leo Bicknell and Ed Lewis Proposal type: new Policy term: permanent Policy statement: Delete the text in 6.5.4.2 and Replace the text in section 6.5.4.1 with the following text: Assignments by LIRs /48 or smaller will not be reviewed by ARIN. Assignments greater than /48 will be reviewed to see if the additional space is warranted according to the 0.94 HD ratio policy. If the space is not warranted, ARIN will consider the excess space to be available for a different assignment, lowering the overall utilization score of the LIR. Rationale: The existing section 6.5.4.1 does not provide clear guidance on how ARIN should treat prefixes allocated to a site should an ISP come back for additional space in the future. This makes it difficult for LIR's to know if they are allocating in accordance with the rules under which they will be judged in the future. The existing section also provides no guidence on what the LIR or ARIN should do in the case a larger prefix is necessary. Timetable for implementation: immediate From sleibrand at internap.com Tue Oct 23 14:06:42 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 23 Oct 2007 11:06:42 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3132.7000808@arin.net> References: <471E3132.7000808@arin.net> Message-ID: <471E3832.1030908@internap.com> All, As the policy author, I'd like to get opinions on the wordsmithing we did at the meeting. The text to be added now reads: or demonstrate efficient utilization of all direct IPv4 assignments or allocations covered by a current ARIN RSA. If an organization had multiple legacy assignments or allocations, and chose to cover just one of them under an RSA, would you read that that mean they'd only have to demonstrate efficient utilization of that one block? Or does that verbiage accurately reflect the intent of the proposal, that all direct IPv4 assignments or allocations must be covered under an ARIN RSA and efficiently utilized? If you have any suggestions for simple wording changes to reduce ambiguity, I'm all ears. If no one has any better suggestions, and we think the current proposal text is ambiguous, I'm leaning towards something like: or demonstrate efficient utilization and coverage under a current ARIN RSA of all direct IPv4 assignments or allocations. I'm perfectly willing to stick with the current text, though, if people think it's clear and doesn't have any loopholes. Thanks, Scott P.S. I'm also interested in how ARIN staff would interpret the current proposed text. Member Services wrote: > Policy Proposal 2007-21 > PIv6 for legacy holders with RSA and efficient use > > The ARIN Advisory Council (AC), acting under the provisions of the ARIN > Internet Resource Policy Evaluation Process (IRPEP), determined that > there is community consensus in favor of the amended proposal and moved > it to last call. The policy text was amended from "a direct IPv4 > assignment or allocation" to "all direct IPv4 assignments or > allocations." The AC made this determination at their meeting at the > conclusion of the ARIN Public Policy meeting on 18 October 2007. The > Chair of the AC reported the results of the AC meeting during the > Members Meeting. The AC Chair's report can be found at: > http://www.arin.net/meetings/minutes/ARIN_XX/mem.html > > The policy proposal text is provided below and is also available at: > http://www.arin.net/policy/proposals/2007_21.html > > Comments are encouraged. All comments should be provided to > ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 > November 2007. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 2007-21 > PIv6 for legacy holders with RSA and efficient use > > Author: Scott Leibrand > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user > organizations: Criteria), to read: > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or > allocation from ARIN under the IPv4 policy currently in effect, or > demonstrate efficient utilization of all direct IPv4 assignments or > allocations covered by a current ARIN RSA. > > > Rationale: > > Current policy allows direct IPv6 allocations and assignments to nearly > all organizations with IPv4 allocations or assignments from ARIN. As a > result, such organizations can get IPv6 space just as easily as they can > get IPv4 space, making it easy for them to transition to IPv6 as soon as > they're ready to do so. However, there are some organizations who > received IPv4 /23's and /24's prior to the formation of ARIN, and use > that space in a multihomed, provider-independent fashion. Under current > policy, such organizations cannot get IPv6 PI space without artificially > inflating host counts, and are therefore discouraged from adopting IPv6. > This policy proposal aims to remove this disincentive, and allow such > organizations to easily adopt IPv6. > > In addition, pre-ARIN assignments were issued through an informal > process, and many legacy resource holders have not yet entered into a > formal agreement with ARIN, the manager of many such IP numbering > resources. This policy proposal would require that such assignments be > brought under a current ARIN Registration Services Agreement, thereby > formalizing the relationship. > > Some pre-ARIN assignments may not be used efficiently. As unallocated > IPv4 numbering resources are approaching exhaustion, it is important to > ensure efficient utilization of IPv4 assignments, and to arrange for > reclamation of unused space. Therefore, this policy would require that > the organization wishing to receive IPv6 PI space demonstrate efficient > utilization of their IPv4 assignment. (Efficient utilization is already > defined elsewhere in policy, and the exact mechanism for achieving and > determining efficient use is a matter of procedure, not of policy, so > detailed procedures are not included in the policy statement above. The > intent is that any organization with an assignment of /23 or larger > which is less than 50% utilized would renumber and return whole unused > CIDR blocks as necessary to bring the remaining CIDR block to 50% > utilization or higher. A /24 should be considered efficiently utilized > as long as it is in use for multihoming, as /25's and smaller are not > routable for that purpose.) > > It has been suggested that this policy would be useful only until the > growth of IPv6 exceeds the growth of IPv4. I would agree with this, and > would further posit that the existing "qualify ... under the IPv4 policy > currently in effect" language should also be modified at that time. I > have therefore proposed this policy with a policy term of "permanent", > with the expectation that this section of policy (6.5.8.1) will be > rewritten at the appropriate time to entirely remove all IPv4 dependencies. > > Timetable for implementation: immediate > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From sleibrand at internap.com Tue Oct 23 14:10:08 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 23 Oct 2007 11:10:08 -0700 Subject: [ppml] Policy Proposal 2007-13: Removal of ISP Immediate Need from End-User - Withdrawn In-Reply-To: <471E31BF.8030001@arin.net> References: <471E31BF.8030001@arin.net> Message-ID: <471E3900.3080606@internap.com> Owen, If you're not burnt out on the topic yet, it might make sense to put forth a proposal to reconcile 4.2.1.6 with current staff interpretation (as discovered at the meeting), and explicitly state within 4.2.1.6 that it applies to end users as well as ISPs. -Scott Member Services wrote: > Policy Proposal 2007-13 > Removal of ISP Immediate Need from End-User > > 2007-13 was withdrawn by the author. The AC made this determination at > their meeting at the conclusion of the ARIN Public Policy meeting on > 18 October 2007. The Chair of the AC reported the results of the AC > meeting during the Members Meeting. The AC Chair's report can be found at: > http://www.arin.net/meetings/minutes/ARIN_XX/mem.html > > The policy proposal text is provided below and is also available at: > http://www.arin.net/policy/proposals/2007_13.html > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ##*## > > > Annex A > > Policy Proposal 2007-13 > Removal of ISP Immediate Need from End-User > > Author: Rob Seastrom, David Williamson, Owen DeLong > > Proposal type: delete > > Policy term: permanent > > Policy statement: > > Delete section 4.3.4, which reads: > > 4.3.4. Additional considerations > > End-users may qualify for address space under other policies such as > Immediate need [4.2.1.6] or Micro-allocation [4.4]. > > from the NRPM. > > Rationale: > > As discussed at ARIN XIX, section 4.3.4 creates a conflict with > section 4.2.1.6 in that section 4.2.1.6 specifically excludes end users > while section 4.3.4 is specifically for end users. > > Prior to the development of the multihoming policy for end users, > the immediate need policy was required in order to support end users > being able to get address space under some circumstances. The "immediate > need" title is a misnomer as it is more an issue of "initial need > without prior address utilization" than "immediate need". Such initial > needs for end users are now addressed best through the multihoming policy. > > Timetable for implementation: immediate > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Oct 23 14:12:29 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 23 Oct 2007 11:12:29 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3832.1030908@internap.com> Message-ID: I like the revision, I wouldn't support it if it could be used by a legacy holder to cherry-pick a single IPv4 legacy assignment and use that as a straw man to cover all of their legacy IPv4 assignments. The worst that could happen is no legacy holders would take advantage of the new policy, thus leaving us exactly where we are now. In that case we revise it again. Ted >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Scott Leibrand >Sent: Tuesday, October 23, 2007 11:07 AM >To: Member Services >Cc: ppml at arin.net >Subject: Re: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders >with RSA and efficient use - Last Call > > >All, > >As the policy author, I'd like to get opinions on the wordsmithing we >did at the meeting. The text to be added now reads: > >or demonstrate efficient utilization of all direct IPv4 >assignments or allocations covered by a current ARIN RSA. > > >If an organization had multiple legacy assignments or allocations, and >chose to cover just one of them under an RSA, would you read that that >mean they'd only have to demonstrate efficient utilization of that one >block? Or does that verbiage accurately reflect the intent of the >proposal, that all direct IPv4 assignments or allocations must be >covered under an ARIN RSA and efficiently utilized? > >If you have any suggestions for simple wording changes to reduce >ambiguity, I'm all ears. If no one has any better suggestions, and we >think the current proposal text is ambiguous, I'm leaning towards >something like: > >or demonstrate efficient utilization and coverage under a current >ARIN RSA of all direct IPv4 assignments or allocations. > > >I'm perfectly willing to stick with the current text, though, if people >think it's clear and doesn't have any loopholes. > >Thanks, >Scott > >P.S. I'm also interested in how ARIN staff would interpret the current >proposed text. > >Member Services wrote: >> Policy Proposal 2007-21 >> PIv6 for legacy holders with RSA and efficient use >> >> The ARIN Advisory Council (AC), acting under the provisions of the ARIN >> Internet Resource Policy Evaluation Process (IRPEP), determined that >> there is community consensus in favor of the amended proposal and moved >> it to last call. The policy text was amended from "a direct IPv4 >> assignment or allocation" to "all direct IPv4 assignments or >> allocations." The AC made this determination at their meeting at the >> conclusion of the ARIN Public Policy meeting on 18 October 2007. The >> Chair of the AC reported the results of the AC meeting during the >> Members Meeting. The AC Chair's report can be found at: >> http://www.arin.net/meetings/minutes/ARIN_XX/mem.html >> >> The policy proposal text is provided below and is also available at: >> http://www.arin.net/policy/proposals/2007_21.html >> >> Comments are encouraged. All comments should be provided to >> ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 >> November 2007. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal 2007-21 >> PIv6 for legacy holders with RSA and efficient use >> >> Author: Scott Leibrand >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user >> organizations: Criteria), to read: >> >> To qualify for a direct assignment, an organization must: >> >> 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or >> allocation from ARIN under the IPv4 policy currently in effect, or >> demonstrate efficient utilization of all direct IPv4 assignments or >> allocations covered by a current ARIN RSA. >> >> >> Rationale: >> >> Current policy allows direct IPv6 allocations and assignments to nearly >> all organizations with IPv4 allocations or assignments from ARIN. As a >> result, such organizations can get IPv6 space just as easily as they can >> get IPv4 space, making it easy for them to transition to IPv6 as soon as >> they're ready to do so. However, there are some organizations who >> received IPv4 /23's and /24's prior to the formation of ARIN, and use >> that space in a multihomed, provider-independent fashion. Under current >> policy, such organizations cannot get IPv6 PI space without artificially >> inflating host counts, and are therefore discouraged from adopting IPv6. >> This policy proposal aims to remove this disincentive, and allow such >> organizations to easily adopt IPv6. >> >> In addition, pre-ARIN assignments were issued through an informal >> process, and many legacy resource holders have not yet entered into a >> formal agreement with ARIN, the manager of many such IP numbering >> resources. This policy proposal would require that such assignments be >> brought under a current ARIN Registration Services Agreement, thereby >> formalizing the relationship. >> >> Some pre-ARIN assignments may not be used efficiently. As unallocated >> IPv4 numbering resources are approaching exhaustion, it is important to >> ensure efficient utilization of IPv4 assignments, and to arrange for >> reclamation of unused space. Therefore, this policy would require that >> the organization wishing to receive IPv6 PI space demonstrate efficient >> utilization of their IPv4 assignment. (Efficient utilization is already >> defined elsewhere in policy, and the exact mechanism for achieving and >> determining efficient use is a matter of procedure, not of policy, so >> detailed procedures are not included in the policy statement above. The >> intent is that any organization with an assignment of /23 or larger >> which is less than 50% utilized would renumber and return whole unused >> CIDR blocks as necessary to bring the remaining CIDR block to 50% >> utilization or higher. A /24 should be considered efficiently utilized >> as long as it is in use for multihoming, as /25's and smaller are not >> routable for that purpose.) >> >> It has been suggested that this policy would be useful only until the >> growth of IPv6 exceeds the growth of IPv4. I would agree with this, and >> would further posit that the existing "qualify ... under the IPv4 policy >> currently in effect" language should also be modified at that time. I >> have therefore proposed this policy with a policy term of "permanent", >> with the expectation that this section of policy (6.5.8.1) will be >> rewritten at the appropriate time to entirely remove all IPv4 >dependencies. >> >> Timetable for implementation: immediate >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the >ARIN Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml Please contact the >ARIN Member Services >> Help Desk at 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 (PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/ppml Please contact the >ARIN Member Services >Help Desk at info at arin.net if you experience any issues. > From info at arin.net Tue Oct 23 14:21:42 2007 From: info at arin.net (Member Services) Date: Tue, 23 Oct 2007 14:21:42 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3132.7000808@arin.net> References: <471E3132.7000808@arin.net> Message-ID: <471E3BB6.5020805@arin.net> > The policy text was amended from "a direct IPv4 > assignment or allocation" > to "all direct IPv4 assignments or allocations." Correction. Amended to "all direct IPv4 assignments and allocations." Regards, Member Services American Registry for Internet Numbers (ARIN) Member Services wrote: > Policy Proposal 2007-21 > PIv6 for legacy holders with RSA and efficient use > > The ARIN Advisory Council (AC), acting under the provisions of the ARIN > Internet Resource Policy Evaluation Process (IRPEP), determined that > there is community consensus in favor of the amended proposal and moved > it to last call. The policy text was amended from "a direct IPv4 > assignment or allocation" to "all direct IPv4 assignments or > allocations." The AC made this determination at their meeting at the > conclusion of the ARIN Public Policy meeting on 18 October 2007. The > Chair of the AC reported the results of the AC meeting during the > Members Meeting. The AC Chair's report can be found at: > http://www.arin.net/meetings/minutes/ARIN_XX/mem.html > > The policy proposal text is provided below and is also available at: > http://www.arin.net/policy/proposals/2007_21.html > > Comments are encouraged. All comments should be provided to > ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 > November 2007. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal 2007-21 > PIv6 for legacy holders with RSA and efficient use > > Author: Scott Leibrand > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user > organizations: Criteria), to read: > > To qualify for a direct assignment, an organization must: > > 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or > allocation from ARIN under the IPv4 policy currently in effect, or > demonstrate efficient utilization of all direct IPv4 assignments and > allocations covered by a current ARIN RSA. > > > Rationale: > > Current policy allows direct IPv6 allocations and assignments to nearly > all organizations with IPv4 allocations or assignments from ARIN. As a > result, such organizations can get IPv6 space just as easily as they can > get IPv4 space, making it easy for them to transition to IPv6 as soon as > they're ready to do so. However, there are some organizations who > received IPv4 /23's and /24's prior to the formation of ARIN, and use > that space in a multihomed, provider-independent fashion. Under current > policy, such organizations cannot get IPv6 PI space without artificially > inflating host counts, and are therefore discouraged from adopting IPv6. > This policy proposal aims to remove this disincentive, and allow such > organizations to easily adopt IPv6. > > In addition, pre-ARIN assignments were issued through an informal > process, and many legacy resource holders have not yet entered into a > formal agreement with ARIN, the manager of many such IP numbering > resources. This policy proposal would require that such assignments be > brought under a current ARIN Registration Services Agreement, thereby > formalizing the relationship. > > Some pre-ARIN assignments may not be used efficiently. As unallocated > IPv4 numbering resources are approaching exhaustion, it is important to > ensure efficient utilization of IPv4 assignments, and to arrange for > reclamation of unused space. Therefore, this policy would require that > the organization wishing to receive IPv6 PI space demonstrate efficient > utilization of their IPv4 assignment. (Efficient utilization is already > defined elsewhere in policy, and the exact mechanism for achieving and > determining efficient use is a matter of procedure, not of policy, so > detailed procedures are not included in the policy statement above. The > intent is that any organization with an assignment of /23 or larger > which is less than 50% utilized would renumber and return whole unused > CIDR blocks as necessary to bring the remaining CIDR block to 50% > utilization or higher. A /24 should be considered efficiently utilized > as long as it is in use for multihoming, as /25's and smaller are not > routable for that purpose.) > > It has been suggested that this policy would be useful only until the > growth of IPv6 exceeds the growth of IPv4. I would agree with this, and > would further posit that the existing "qualify ... under the IPv4 policy > currently in effect" language should also be modified at that time. I > have therefore proposed this policy with a policy term of "permanent", > with the expectation that this section of policy (6.5.8.1) will be > rewritten at the appropriate time to entirely remove all IPv4 dependencies. > > Timetable for implementation: immediate > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From sleibrand at internap.com Tue Oct 23 14:36:23 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 23 Oct 2007 11:36:23 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: References: Message-ID: <471E3F27.9070301@internap.com> Ted: I'm not 100% sure which text you're expressing support for. Can you clarify? Thanks, Scott Ted Mittelstaedt wrote: > I like the revision, I wouldn't support it if it could be used > by a legacy holder to cherry-pick a single IPv4 legacy assignment > and use that as a straw man to cover all of their legacy IPv4 assignments. > > The worst that could happen is no legacy holders would take advantage > of the new policy, thus leaving us exactly where we are now. In that > case we revise it again. > > Ted > > >> -----Original Message----- >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >> Scott Leibrand >> Sent: Tuesday, October 23, 2007 11:07 AM >> To: Member Services >> Cc: ppml at arin.net >> Subject: Re: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders >> with RSA and efficient use - Last Call >> >> >> All, >> >> As the policy author, I'd like to get opinions on the wordsmithing we >> did at the meeting. The text to be added now reads: >> >> or demonstrate efficient utilization of all direct IPv4 >> assignments or allocations covered by a current ARIN RSA. >> >> >> If an organization had multiple legacy assignments or allocations, and >> chose to cover just one of them under an RSA, would you read that that >> mean they'd only have to demonstrate efficient utilization of that one >> block? Or does that verbiage accurately reflect the intent of the >> proposal, that all direct IPv4 assignments or allocations must be >> covered under an ARIN RSA and efficiently utilized? >> >> If you have any suggestions for simple wording changes to reduce >> ambiguity, I'm all ears. If no one has any better suggestions, and we >> think the current proposal text is ambiguous, I'm leaning towards >> something like: >> >> or demonstrate efficient utilization and coverage under a current >> ARIN RSA of all direct IPv4 assignments or allocations. >> >> >> I'm perfectly willing to stick with the current text, though, if people >> think it's clear and doesn't have any loopholes. >> >> Thanks, >> Scott >> >> P.S. I'm also interested in how ARIN staff would interpret the current >> proposed text. >> >> Member Services wrote: >> >>> Policy Proposal 2007-21 >>> PIv6 for legacy holders with RSA and efficient use >>> >>> The ARIN Advisory Council (AC), acting under the provisions of the ARIN >>> Internet Resource Policy Evaluation Process (IRPEP), determined that >>> there is community consensus in favor of the amended proposal and moved >>> it to last call. The policy text was amended from "a direct IPv4 >>> assignment or allocation" to "all direct IPv4 assignments or >>> allocations." The AC made this determination at their meeting at the >>> conclusion of the ARIN Public Policy meeting on 18 October 2007. The >>> Chair of the AC reported the results of the AC meeting during the >>> Members Meeting. The AC Chair's report can be found at: >>> http://www.arin.net/meetings/minutes/ARIN_XX/mem.html >>> >>> The policy proposal text is provided below and is also available at: >>> http://www.arin.net/policy/proposals/2007_21.html >>> >>> Comments are encouraged. All comments should be provided to >>> ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 >>> November 2007. >>> >>> The ARIN Internet Resource Policy Evaluation Process can be found at: >>> http://www.arin.net/policy/irpep.html >>> >>> Regards, >>> >>> Member Services >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> ## * ## >>> >>> >>> Policy Proposal 2007-21 >>> PIv6 for legacy holders with RSA and efficient use >>> >>> Author: Scott Leibrand >>> >>> Proposal type: new >>> >>> Policy term: permanent >>> >>> Policy statement: >>> >>> Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user >>> organizations: Criteria), to read: >>> >>> To qualify for a direct assignment, an organization must: >>> >>> 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or >>> allocation from ARIN under the IPv4 policy currently in effect, or >>> demonstrate efficient utilization of all direct IPv4 assignments or >>> allocations covered by a current ARIN RSA. >>> >>> >>> Rationale: >>> >>> Current policy allows direct IPv6 allocations and assignments to nearly >>> all organizations with IPv4 allocations or assignments from ARIN. As a >>> result, such organizations can get IPv6 space just as easily as they can >>> get IPv4 space, making it easy for them to transition to IPv6 as soon as >>> they're ready to do so. However, there are some organizations who >>> received IPv4 /23's and /24's prior to the formation of ARIN, and use >>> that space in a multihomed, provider-independent fashion. Under current >>> policy, such organizations cannot get IPv6 PI space without artificially >>> inflating host counts, and are therefore discouraged from adopting IPv6. >>> This policy proposal aims to remove this disincentive, and allow such >>> organizations to easily adopt IPv6. >>> >>> In addition, pre-ARIN assignments were issued through an informal >>> process, and many legacy resource holders have not yet entered into a >>> formal agreement with ARIN, the manager of many such IP numbering >>> resources. This policy proposal would require that such assignments be >>> brought under a current ARIN Registration Services Agreement, thereby >>> formalizing the relationship. >>> >>> Some pre-ARIN assignments may not be used efficiently. As unallocated >>> IPv4 numbering resources are approaching exhaustion, it is important to >>> ensure efficient utilization of IPv4 assignments, and to arrange for >>> reclamation of unused space. Therefore, this policy would require that >>> the organization wishing to receive IPv6 PI space demonstrate efficient >>> utilization of their IPv4 assignment. (Efficient utilization is already >>> defined elsewhere in policy, and the exact mechanism for achieving and >>> determining efficient use is a matter of procedure, not of policy, so >>> detailed procedures are not included in the policy statement above. The >>> intent is that any organization with an assignment of /23 or larger >>> which is less than 50% utilized would renumber and return whole unused >>> CIDR blocks as necessary to bring the remaining CIDR block to 50% >>> utilization or higher. A /24 should be considered efficiently utilized >>> as long as it is in use for multihoming, as /25's and smaller are not >>> routable for that purpose.) >>> >>> It has been suggested that this policy would be useful only until the >>> growth of IPv6 exceeds the growth of IPv4. I would agree with this, and >>> would further posit that the existing "qualify ... under the IPv4 policy >>> currently in effect" language should also be modified at that time. I >>> have therefore proposed this policy with a policy term of "permanent", >>> with the expectation that this section of policy (6.5.8.1) will be >>> rewritten at the appropriate time to entirely remove all IPv4 >>> >> dependencies. >> >>> Timetable for implementation: immediate >>> >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the >>> >> ARIN Public Policy >> >>> Mailing List (PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml Please contact the >>> >> ARIN Member Services >> >>> Help Desk at 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 (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml Please contact the >> ARIN Member Services >> Help Desk at info at arin.net if you experience any issues. >> >> From captain at netidea.com Tue Oct 23 14:36:34 2007 From: captain at netidea.com (Kirk Ismay) Date: Tue, 23 Oct 2007 11:36:34 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3832.1030908@internap.com> References: <471E3132.7000808@arin.net> <471E3832.1030908@internap.com> Message-ID: <471E3F32.6040802@netidea.com> Scott Leibrand wrote: > If you have any suggestions for simple wording changes to reduce > ambiguity, I'm all ears. If no one has any better suggestions, and we > think the current proposal text is ambiguous, I'm leaning towards > something like: > > or demonstrate efficient utilization and coverage under a current ARIN RSA of all direct IPv4 assignments or allocations. I prefer this less ambiguous version. -- Sincerely, Kirk Ismay System Administrator -- Net Idea 201-625 Front Street Nelson, BC V1L 4B6 P:250-352-3512 | F:250-352-9780 | TF:1-888-352-3512 Check out our brand new website! www.netidea.com From sleibrand at internap.com Tue Oct 23 14:38:22 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 23 Oct 2007 11:38:22 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3F32.6040802@netidea.com> References: <471E3132.7000808@arin.net> <471E3832.1030908@internap.com> <471E3F32.6040802@netidea.com> Message-ID: <471E3F9E.2090503@internap.com> And incorporating ARIN's correction, that would be: or demonstrate efficient utilization and coverage under a current ARIN RSA of all direct IPv4 assignments and allocations. (Replacing the last "or" with "and".) -Scott Kirk Ismay wrote: > Scott Leibrand wrote: >> If you have any suggestions for simple wording changes to reduce >> ambiguity, I'm all ears. If no one has any better suggestions, and >> we think the current proposal text is ambiguous, I'm leaning towards >> something like: >> >> or demonstrate efficient utilization and coverage under a current >> ARIN RSA of all direct IPv4 assignments or allocations. > I prefer this less ambiguous version. > From plzak at arin.net Tue Oct 23 14:39:57 2007 From: plzak at arin.net (Ray Plzak) Date: Tue, 23 Oct 2007 14:39:57 -0400 Subject: [ppml] Economist at the ARIN meeting In-Reply-To: <1EE00034-1194-453F-98BD-E67AD7405C6E@pch.net> References: <1EE00034-1194-453F-98BD-E67AD7405C6E@pch.net> Message-ID: Once the meeting notes are posted the streaming audio and video of Ben's talk should be available. This should occur next week. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Tom Vest > Sent: Tuesday, October 23, 2007 10:59 AM > To: michael.dillon at bt.com > Cc: ppml at arin.net > Subject: Re: [ppml] Economist at the ARIN meeting > > It was Ben Edelman, who has been engaged as a consultant by ARIN. > He spoke on the "IP Markets?" panel, without slides. > > TV > > On Oct 23, 2007, at 3:08 PM, > wrote: > > > > > I have been told that an economist made a presentation at the > > meeting in > > Albuquerque. If this is true, who was the economist and where can I > > find > > a copy of the presentation? > > > > ------------------------------------------------------- > > Michael Dillon > > RadianzNet Capacity Management -- BT Design > > 66 Prescot St., London, E1 8HG, UK > > Mobile: +44 7900 823 672 > > Internet: michael.dillon at bt.com > > Phone: +44 20 7650 9493 Fax: +44 20 7650 9030 > > http://www.btradianz.com > > > > One Community One Connection One Focus > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the > > ARIN Public Policy > > Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > > Member Services > > Help Desk at 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From sleibrand at internap.com Tue Oct 23 16:48:49 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 23 Oct 2007 13:48:49 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3F9E.2090503@internap.com> References: <471E3132.7000808@arin.net> <471E3832.1030908@internap.com> <471E3F32.6040802@netidea.com> <471E3F9E.2090503@internap.com> Message-ID: <471E5E31.1060706@internap.com> After receiving some excellent private feedback on the language, I'd like to submit the following text for comments: or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by a current ARIN RSA. I believe that text resolves any potential ambiguity in the conditions, while staying as close as possible to the text discussed at the meeting and keeping things as simple as possible. Thanks, Scott Scott Leibrand wrote: > And incorporating ARIN's correction, that would be: > > or demonstrate efficient utilization and coverage under a current ARIN > RSA of all direct IPv4 assignments and allocations. > > (Replacing the last "or" with "and".) > > -Scott > > Kirk Ismay wrote: > >> Scott Leibrand wrote: >> >>> If you have any suggestions for simple wording changes to reduce >>> ambiguity, I'm all ears. If no one has any better suggestions, and >>> we think the current proposal text is ambiguous, I'm leaning towards >>> something like: >>> >>> or demonstrate efficient utilization and coverage under a current >>> ARIN RSA of all direct IPv4 assignments or allocations. >>> >> I prefer this less ambiguous version. >> >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From mcr at xdsinc.net Tue Oct 23 18:47:00 2007 From: mcr at xdsinc.net (mcr at xdsinc.net) Date: Tue, 23 Oct 2007 18:47:00 -0400 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with In-Reply-To: <4538.66.212.195.12.1192731364.squirrel@ssl.omd3.com> References: <200709010103.l81138Vk008834@cjbsys.bdb.com> <4538.66.212.195.12.1192731364.squirrel@ssl.omd3.com> Message-ID: <20071023224557.B9AD3144533@smtp2.arin.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "David" == David S Madole writes: David> As Ted pointed out recently, there is currently a David> disincentive for legacy holders to implement IPv6 at all David> versus dragging out IPv4 as long as they can. There are no obvious carrots for IPv6, only sticks against IPv4. David> One simple way to remove this disincentive would be to offer David> IPv6 addresses to legacy holders on the same terms as their David> IPv4 addresses, or maybe not the same but something that David> removes or lessens the disincentive. From what I understand, IPv4 RSA holders already have access to IPv6 PI space. I am curious to know what the distribution of legacy IPv4 holder are: how many /24s, how many /16s, etc? I think that the many multitude of /24s, probably don't need more than a /48, and there are many ways to get that. Of the /16s and /8 legacy holders, I would think that getting IPv6 PI space directly would be easy. Likely the biggest hurdles they have for getting IPv6 deployed is internal. David> Taking this point a little further, it's largely the legacies David> that got IPv4 to take off and got the Internet built, they David> could be the ones to do the same for IPv6 too perhaps if David> given an incentive rather than a disincentive. Doubtful. Just make IPv6 space as easy to get as IPv4 was back in 1988. David> After all, even ARIN, who should be leading the way I would David> think, isn't even offering whois on IPv6 yet as far as I can David> tell, even though RIPE has been doing so for almost five David> years. I didn't know there was no whois yet. - -- Michael Richardson XDS Inc, Ottawa, ON Personal: http://www.sandelman.ca/mcr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBRx554+0sRu40D6vCAQKeyQYAmNigI6z2eQ08bc4bzcycYrRlWd1hX5qr T8Zckvy8caZ09AsqN13QAb+f35Or/JyL3c3rUT7TBt3yfPKXQaBWcSWC43BncRCX /UmytzzK6laMfnjkJ6lKCJyMEjdusr+HFb+wKrqQ0FLj2HPlQJAUWd24eFr/+F0f eYZdhoAlUQtzuG3C6VkBt2/Xsw6VTii6/UVXKS0WL7CnCppssKWO8VGl7ODKGaqZ op3P3VGc19ku4wBGkvTBm8gYRIOI6WSp =j2bg -----END PGP SIGNATURE----- From josmon at rigozsaurus.com Mon Oct 22 22:58:21 2007 From: josmon at rigozsaurus.com (John Osmon) Date: Mon, 22 Oct 2007 20:58:21 -0600 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> Message-ID: <20071023025821.GB7902@jeeves.rigozsaurus.com> On Mon, Oct 22, 2007 at 06:35:19PM -0400, Steve Bertrand wrote: > [...] I understand that the routing table growth is the failing > point of v6, so I know *why* I have such a large space, but it is > really upsetting when people are already using the word 'hoarding' > when some of us can not get a space suitable for our size, but receive > something that is exponentially beyond the scope of comprehension, let > alone above suitable. Two questions hit me while I was reading this thread: -- hoarding -- is it hoarding to keep the address block you were assigned, even it if is bigger than you wanted? How many legacy holders would have been happy with a /26 - /29 if such blocks had been available? -- address run-out -- How much longer could the existing address space last if we could allocate a block of space that is appropriately sized for an end-user's needs? Yes -- I realize that I'm playing fast and loose with other people's routing slots. Which is worse? Running out of address space? Or running into limitations of current router implementations? If we play towards the router implementations, aren't we setting routing policy de facto? From sleibrand at internap.com Wed Oct 24 02:12:06 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 23 Oct 2007 23:12:06 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071023025821.GB7902@jeeves.rigozsaurus.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <20071023025821.GB7902@jeeves.rigozsaurus.com> Message-ID: <471EE236.60903@internap.com> John Osmon wrote: > Two questions hit me while I was reading this thread: > -- hoarding -- is it hoarding to keep the address block you > were assigned, even it if is bigger than you wanted? I wouldn't think so, at least in the case of someone who got a /24. If you got a /8 or /16 and are only using part of it, I think the proper thing to do is to renumber (if necessary) into a subnet of your original allocation, and return the unused portion. > How many legacy holders would have been happy with a /26 - /29 if > such blocks had been available? > Given the way routing filters played out (at /24), I would say not many. > -- address run-out -- How much longer could the existing address > space last if we could allocate a block of space that is > appropriately sized for an end-user's needs? > I think this can, will, and is happening. All new allocations for the last 10 years have been appropriately sized. Some who received /8's have already renumbered and returned un-needed space. I'm hopeful that this will continue happening with other legacy /8 and /16 allocations and assignments. I also suspect that as we approach IANA free pool exhaustion we'll be able to implement an address transfer system, whereby networks needing new space can incent networks with existing space to renumber into smaller netblocks. > Yes -- I realize that I'm playing fast and loose with other people's > routing slots. Which is worse? Running out of address space? Or > running into limitations of current router implementations? > > If we play towards the router implementations, aren't we setting > routing policy de facto? Clearly both can be bad, and any policy we implement needs to appropriately balance the two. That is why I favor some sort of address transfer system, but also think we need to maintain restrictions on the top-level deaggregation of assignments and allocations. I believe that deaggregation at lower levels of the hierarchy is less of a problem, as that preserves the possibility of filtering deaggregates while preserving reachability via the larger covering aggregate. -Scott From michael.dillon at bt.com Wed Oct 24 02:55:50 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 24 Oct 2007 07:55:50 +0100 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071023025821.GB7902@jeeves.rigozsaurus.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail><20071022193730.GA15529@vacation.karoshi.com.><3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <20071023025821.GB7902@jeeves.rigozsaurus.com> Message-ID: > -- address run-out -- How much longer could the existing address > space last if we could allocate a block of space that is > appropriately sized for an end-user's needs? There is no danger of IPv6 addresses running out anytime soon. > If we play towards the router implementations, aren't we > setting routing policy de facto? ARIN cannot set routing policy because it doesn't run the routers. But ARIN can and should understand how our policies impact routing. --Michael Dillon P.S. the reason that some of us write IPv4 and IPv6 all the time is to make it clear what type of IP addresses are under discussion. If you check the subject line of your message, it says IPv6 but in your text you don't mention either IPv4 or IPv6. From Ed.Lewis at neustar.biz Wed Oct 24 11:17:51 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 24 Oct 2007 11:17:51 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <20071023025821.GB7902@jeeves.rigozsaurus.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <20071023025821.GB7902@jeeves.rigozsaurus.com> Message-ID: At 20:58 -0600 10/22/07, John Osmon wrote: BTW - thanks for sponsoring the last meeting. >Two questions hit me while I was reading this thread: > -- hoarding -- is it hoarding to keep the address block you IMO - Hoarding is not a situation but intent. I use hoarding to describe building up a storehouse of addresses for the purposes of disbursing them according to some (usually "not in the public interest") criteria. If you have "too many" because that's what it takes to route, that's not hoarding. If you are waiting for the market to emerge, that's hoarding. If an RIR has a huge chunk and is trying to squeeze it for whatever reason, the RIR is hoarding. (Alluding to my comments why I didn't like the "last *25* /8s's go evenly to the 5 RIRs.") > -- address run-out -- How much longer could the existing address > space last if we could allocate a block of space that is > appropriately sized for an end-user's needs? I'm not sure of your wording. Address run-out to me simply means being out of addresses (for the situation). >If we play towards the router implementations, aren't we setting >routing policy de facto? It should be vice versa. Policy ought to maximize the public good, which means reflecting the realities of operations, balanced against developing an unfair playing field. As can be imagined, there are local and global "maxima" at play in a complex game, policy should try to get to the global maxima. If that means that the policies are seen as impacting the routing policy, there's some influence. But I hope the reverse influence is greater - that the policies drawn up are based on operational reality. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From tedm at ipinc.net Wed Oct 24 12:01:24 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 24 Oct 2007 09:01:24 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <471E3F27.9070301@internap.com> Message-ID: I support "...or demonstrate efficient utilization and coverage under a current ARIN RSA of all direct IPv4 assignments AND allocations...." Ted >-----Original Message----- >From: Scott Leibrand [mailto:sleibrand at internap.com] >Sent: Tuesday, October 23, 2007 11:36 AM >To: Ted Mittelstaedt >Cc: Member Services; ppml at arin.net >Subject: Re: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders >with RSA and efficient use - Last Call > > >Ted: I'm not 100% sure which text you're expressing support for. Can >you clarify? > >Thanks, >Scott > >Ted Mittelstaedt wrote: >> I like the revision, I wouldn't support it if it could be used >> by a legacy holder to cherry-pick a single IPv4 legacy assignment >> and use that as a straw man to cover all of their legacy IPv4 >assignments. >> >> The worst that could happen is no legacy holders would take advantage >> of the new policy, thus leaving us exactly where we are now. In that >> case we revise it again. >> >> Ted >> >> >>> -----Original Message----- >>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >>> Scott Leibrand >>> Sent: Tuesday, October 23, 2007 11:07 AM >>> To: Member Services >>> Cc: ppml at arin.net >>> Subject: Re: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders >>> with RSA and efficient use - Last Call >>> >>> >>> All, >>> >>> As the policy author, I'd like to get opinions on the wordsmithing we >>> did at the meeting. The text to be added now reads: >>> >>> or demonstrate efficient utilization of all direct IPv4 >>> assignments or allocations covered by a current ARIN RSA. >>> >>> >>> If an organization had multiple legacy assignments or allocations, and >>> chose to cover just one of them under an RSA, would you read that that >>> mean they'd only have to demonstrate efficient utilization of that one >>> block? Or does that verbiage accurately reflect the intent of the >>> proposal, that all direct IPv4 assignments or allocations must be >>> covered under an ARIN RSA and efficiently utilized? >>> >>> If you have any suggestions for simple wording changes to reduce >>> ambiguity, I'm all ears. If no one has any better suggestions, and we >>> think the current proposal text is ambiguous, I'm leaning towards >>> something like: >>> >>> or demonstrate efficient utilization and coverage under a current >>> ARIN RSA of all direct IPv4 assignments or allocations. >>> >>> >>> I'm perfectly willing to stick with the current text, though, if people >>> think it's clear and doesn't have any loopholes. >>> >>> Thanks, >>> Scott >>> >>> P.S. I'm also interested in how ARIN staff would interpret the current >>> proposed text. >>> >>> Member Services wrote: >>> >>>> Policy Proposal 2007-21 >>>> PIv6 for legacy holders with RSA and efficient use >>>> >>>> The ARIN Advisory Council (AC), acting under the provisions of the ARIN >>>> Internet Resource Policy Evaluation Process (IRPEP), determined that >>>> there is community consensus in favor of the amended proposal and moved >>>> it to last call. The policy text was amended from "a direct IPv4 >>>> assignment or allocation" to "all direct IPv4 assignments or >>>> allocations." The AC made this determination at their meeting at the >>>> conclusion of the ARIN Public Policy meeting on 18 October 2007. The >>>> Chair of the AC reported the results of the AC meeting during the >>>> Members Meeting. The AC Chair's report can be found at: >>>> http://www.arin.net/meetings/minutes/ARIN_XX/mem.html >>>> >>>> The policy proposal text is provided below and is also available at: >>>> http://www.arin.net/policy/proposals/2007_21.html >>>> >>>> Comments are encouraged. All comments should be provided to >>>> ppml at arin.net. This last call will expire at 23:59, Eastern Time, 6 >>>> November 2007. >>>> >>>> The ARIN Internet Resource Policy Evaluation Process can be found at: >>>> http://www.arin.net/policy/irpep.html >>>> >>>> Regards, >>>> >>>> Member Services >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> ## * ## >>>> >>>> >>>> Policy Proposal 2007-21 >>>> PIv6 for legacy holders with RSA and efficient use >>>> >>>> Author: Scott Leibrand >>>> >>>> Proposal type: new >>>> >>>> Policy term: permanent >>>> >>>> Policy statement: >>>> >>>> Modify NRPM section 6.5.8.1 (Direct assignments from ARIN to end-user >>>> organizations: Criteria), to read: >>>> >>>> To qualify for a direct assignment, an organization must: >>>> >>>> 1. not be an IPv6 LIR; and 2. qualify for an IPv4 assignment or >>>> allocation from ARIN under the IPv4 policy currently in effect, or >>>> demonstrate efficient utilization of all direct IPv4 assignments or >>>> allocations covered by a current ARIN RSA. >>>> >>>> >>>> Rationale: >>>> >>>> Current policy allows direct IPv6 allocations and assignments to nearly >>>> all organizations with IPv4 allocations or assignments from ARIN. As a >>>> result, such organizations can get IPv6 space just as easily >as they can >>>> get IPv4 space, making it easy for them to transition to IPv6 >as soon as >>>> they're ready to do so. However, there are some organizations who >>>> received IPv4 /23's and /24's prior to the formation of ARIN, and use >>>> that space in a multihomed, provider-independent fashion. Under current >>>> policy, such organizations cannot get IPv6 PI space without >artificially >>>> inflating host counts, and are therefore discouraged from >adopting IPv6. >>>> This policy proposal aims to remove this disincentive, and allow such >>>> organizations to easily adopt IPv6. >>>> >>>> In addition, pre-ARIN assignments were issued through an informal >>>> process, and many legacy resource holders have not yet entered into a >>>> formal agreement with ARIN, the manager of many such IP numbering >>>> resources. This policy proposal would require that such assignments be >>>> brought under a current ARIN Registration Services Agreement, thereby >>>> formalizing the relationship. >>>> >>>> Some pre-ARIN assignments may not be used efficiently. As unallocated >>>> IPv4 numbering resources are approaching exhaustion, it is important to >>>> ensure efficient utilization of IPv4 assignments, and to arrange for >>>> reclamation of unused space. Therefore, this policy would require that >>>> the organization wishing to receive IPv6 PI space demonstrate efficient >>>> utilization of their IPv4 assignment. (Efficient utilization is already >>>> defined elsewhere in policy, and the exact mechanism for achieving and >>>> determining efficient use is a matter of procedure, not of policy, so >>>> detailed procedures are not included in the policy statement above. The >>>> intent is that any organization with an assignment of /23 or larger >>>> which is less than 50% utilized would renumber and return whole unused >>>> CIDR blocks as necessary to bring the remaining CIDR block to 50% >>>> utilization or higher. A /24 should be considered efficiently utilized >>>> as long as it is in use for multihoming, as /25's and smaller are not >>>> routable for that purpose.) >>>> >>>> It has been suggested that this policy would be useful only until the >>>> growth of IPv6 exceeds the growth of IPv4. I would agree with this, and >>>> would further posit that the existing "qualify ... under the >IPv4 policy >>>> currently in effect" language should also be modified at that time. I >>>> have therefore proposed this policy with a policy term of "permanent", >>>> with the expectation that this section of policy (6.5.8.1) will be >>>> rewritten at the appropriate time to entirely remove all IPv4 >>>> >>> dependencies. >>> >>>> Timetable for implementation: immediate >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the >>>> >>> ARIN Public Policy >>> >>>> Mailing List (PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/ppml Please contact the >>>> >>> ARIN Member Services >>> >>>> Help Desk at 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 (PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/ppml Please contact the >>> ARIN Member Services >>> Help Desk at info at arin.net if you experience any issues. >>> >>> > From bmanning at vacation.karoshi.com Wed Oct 24 12:33:29 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 24 Oct 2007 16:33:29 +0000 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <20071023025821.GB7902@jeeves.rigozsaurus.com> Message-ID: <20071024163329.GA6796@vacation.karoshi.com.> On Wed, Oct 24, 2007 at 11:17:51AM -0400, Edward Lewis wrote: > At 20:58 -0600 10/22/07, John Osmon wrote: > > I'm not sure of your wording. Address run-out to me simply means > being out of addresses (for the situation). > > >If we play towards the router implementations, aren't we setting > >routing policy de facto? > > It should be vice versa. Policy ought to maximize the public good, > which means reflecting the realities of operations, balanced against > developing an unfair playing field. As can be imagined, there are > local and global "maxima" at play in a complex game, policy should > try to get to the global maxima. > > If that means that the policies are seen as impacting the routing > policy, there's some influence. But I hope the reverse influence is > greater - that the policies drawn up are based on operational reality. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis +1-571-434-5468 but there is no hegonomy in operational scope... is there? --bill From Ed.Lewis at neustar.biz Wed Oct 24 13:06:16 2007 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 24 Oct 2007 13:06:16 -0400 Subject: [ppml] hegemony, was Re: IPv6 assignment - proposal ... In-Reply-To: <20071024163329.GA6796@vacation.karoshi.com.> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <20071023025821.GB7902@jeeves.rigozsaurus.com> <20071024163329.GA6796@vacation.karoshi.com.> Message-ID: At 16:33 +0000 10/24/07, bmanning at vacation.karoshi.com wrote: > but there is no hegonomy in operational scope... is there? You make it sound like "hegemony" is a bad thing. According to m-w.com: 1) preponderant influence or authority over others : domination 2) the social, cultural, ideological, or economic influence exerted by a dominant group If hegemony in the nature of operations, policy won't remove it. (Operations rules!) My intent was to say that policy shouldn't (unduly) contribute to hegemony. If we are lucky, policy may reduce it's negative impact. Sometimes the 800 $unit_of_weight gorilla does know better through experience. And sometimes the gorilla just wants more bananas for itself. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused. From arin-contact at dirtside.com Wed Oct 24 13:41:35 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 24 Oct 2007 13:41:35 -0400 Subject: [ppml] hegemony, was Re: IPv6 assignment - proposal ... In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <20071023025821.GB7902@jeeves.rigozsaurus.com> <20071024163329.GA6796@vacation.karoshi.com.> Message-ID: <3c3e3fca0710241041u6e4f195eo56a5a947a67396de@mail.gmail.com> On 10/24/07, Edward Lewis wrote: > At 16:33 +0000 10/24/07, bmanning at vacation.karoshi.com wrote: > > but there is no hegonomy in operational scope... is there? > > You make it sound like "hegemony" is a bad thing. According to m-w.com: Edward, Hegemony leads to stability but it also leads to stagnation. Competition yeilds innovation. Policy which obstructs competition also obstructs innovation. This means that policy which prevents small operators from competing is bad (or at least unfortunate) policy. > Sometimes the 800 $unit_of_weight gorilla does know better through experience. > And sometimes the gorilla just wants more bananas for itself. Folks in our industry should never forget that the early deployments of 300 baud modems had to be shoved down the 800 lb gorilla's throat. Ma Bell didn't much like the idea of devices she didn't make being connected to her network nor did she like the idea of selling those devices instead of leasing them. She predicted dire consequences, maybe even the collapse of the telephone network, if any random vendor's device could be plugged in. And when told by the courts that she was damn well going to do it anyway, she figured out how to make it work after all. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From stephen at sprunk.org Wed Oct 24 13:38:17 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 24 Oct 2007 12:38:17 -0500 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call References: <471E3132.7000808@arin.net><471E3832.1030908@internap.com> <471E3F32.6040802@netidea.com><471E3F9E.2090503@internap.com> <471E5E31.1060706@internap.com> Message-ID: <033601c81668$980a4980$9902fea9@atlanta.polycom.com> Thus spake "Scott Leibrand" > After receiving some excellent private feedback on the language, > I'd like to submit the following text for comments: > > or demonstrate efficient utilization of all direct IPv4 assignments > and allocations, each of which must be covered by a current ARIN > RSA. This text better reflects what I had thought your proposal meant. I'm still not thrilled with the idea, though; if we think a /24 is good enough for legacy holders to get PIv6 space, then I would prefer we go down the path of making /24 the minimum v4 assignment size. However, that would remove this proposal's carrot for legacy holders to sign RSAs, so I'm torn. Now that the LRSA is out, did you mean to include that in your above reference to "ARIN RSA", or did you mean only a standard RSA? That probably needs a little more clarity. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From sleibrand at internap.com Wed Oct 24 14:20:20 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 24 Oct 2007 11:20:20 -0700 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with RSA and efficient use - Last Call In-Reply-To: <033601c81668$980a4980$9902fea9@atlanta.polycom.com> References: <471E3132.7000808@arin.net><471E3832.1030908@internap.com> <471E3F32.6040802@netidea.com><471E3F9E.2090503@internap.com> <471E5E31.1060706@internap.com> <033601c81668$980a4980$9902fea9@atlanta.polycom.com> Message-ID: <471F8CE4.7030306@internap.com> Stephen Sprunk wrote: > Now that the LRSA is out, did you mean to include that in your above > reference to "ARIN RSA", or did you mean only a standard RSA? That > probably needs a little more clarity. I intended to make the policy vague enough to cover any and all RSAs considered valid and current by ARIN. The Legacy RSA would definitely qualify. -Scott From tedm at ipinc.net Wed Oct 24 15:01:45 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 24 Oct 2007 12:01:45 -0700 Subject: [ppml] hegemony, was Re: IPv6 assignment - proposal ... In-Reply-To: <3c3e3fca0710241041u6e4f195eo56a5a947a67396de@mail.gmail.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >William Herrin >Sent: Wednesday, October 24, 2007 10:42 AM >To: Edward Lewis >Cc: ppml at arin.net >Subject: Re: [ppml] hegemony, was Re: IPv6 assignment - proposal ... > > >On 10/24/07, Edward Lewis wrote: >> At 16:33 +0000 10/24/07, bmanning at vacation.karoshi.com wrote: >> > but there is no hegonomy in operational scope... is there? >> >> You make it sound like "hegemony" is a bad thing. According to m-w.com: > >Edward, > >Hegemony leads to stability but it also leads to stagnation. stagnation is a loaded, emotional term that has no place in this discussion. >Competition yeilds innovation. Which is not always good. >Policy which obstructs competition also >obstructs innovation. Which may be good. Why don't you ask the citizens of the State of California if competition has been a Good Thing for their electric rates? >This means that policy which prevents small >operators from competing is bad (or at least unfortunate) policy. > Your trying to very crudely imply that small operators suffer from stagnation. This is absolute rubbish. It's rubbish in industries like farming and the food industry where small farmers who aren't using all the "innovation" of genetically modified crops are producing better tasting and healthier food. And it's rubbish here as well where a steady-state market can do good things like not requiring small operators to mortage their futures by continually throwing away and replacing perfectly good hardware and software. > >Folks in our industry should never forget that the early deployments >of 300 baud modems had to be shoved down the 800 lb gorilla's throat. I don't. Did you even ever OWN a 300 baud modem, Bill? I'll bet you didn't. I did - a $150 direct connect modem, a fine, advanced piece of equipment, undoubtedly scrap in a landfill today. >Ma Bell didn't much like the idea of devices she didn't make being >connected to her network nor did she like the idea of selling those >devices instead of leasing them. She predicted dire consequences, >maybe even the collapse of the telephone network, if any random >vendor's device could be plugged in. > >And when told by the courts that she was damn well going to do it >anyway, she figured out how to make it work after all. > You obviously have never worked a tech support line at an ISP. I hardly call the state of modems today to be "working" Go search on Google for "conexant chipset negotiation problem" then come back here and repeat that with a straight face. Ted From stephen at sprunk.org Wed Oct 24 16:23:41 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 24 Oct 2007 15:23:41 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail><20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> Message-ID: <041101c8167e$160d2630$9902fea9@atlanta.polycom.com> Thus spake "Steve Bertrand" >> i suspect the hoarding will be an unfortunate sideeffect of the /32 >> v6 allocation size. sort of like the hoarding done by those >> unfortunate souls who only needed 6 v4 addresses but were >> "forced" to take more (a /24 if they were lucky, a /20 if they were >> not) by their address registry. >> >> its not exactly fair to force people to take more addresses than >> they need and then berate them for hoarding... is it? > > Interesting insight. IMHO, a misapplication of the term "hoarding", which I interpreted as being a sarcastic comment, not an actual accusation. (Michael: If I read that wrong, please let me know so I can flame you.) > I, operating a small ISP as others here, directly requested a smaller > than /32 IPv6 block, because I knew that we would almost certainly > never need it, but it was forced upon us anyway. Right. One of the goals in IPv6 policy is minimizing routes in the DFZ, and it's easiest to do that if everyone (or nearly everyone) has the same size blocks because it's easy to filter deaggregates that way. While a /32 is way, way too large for most LIRs, it's large enough that nearly all LIRs will fit in it, it's a convenient number, and everyone can filter anything longer than /32 (except in the PIv6 block, where it's /48) with impunity unless they specifically want deaggregates. Since we have absolutely no clue how to route the half a billion /32s in 2000::/3, there is no reason to give out longer prefixes -- and plenty of reasons not to. > Receiving such a large address space makes it very difficult in the > justification side of things (some would have no choice but to lie on > the application, just to get ANY IPv6 addresses). I only received the > allocation because of the designation that I have (ISP). Yes, we > provide Internet services, but in terms of size, I'm no where near > even that of 'enterprise'. I'll never use the IP's, so apparently, > I'll be hoarding them. I wouldn't use that term. If you have the smallest allocation/assignment that you need or that can be issued, you can't be "hoarding", IMHO. > In regard to Bill's second statement above, it sounds like a lot of > people are doing exactly this (damning them as hoarders) for legacy > IPv4 holders...doesn't it? When push comes to shove, why would one > give up what was given to them, especially when they vehemently tried > to state it wasn't warranted/needed. (I know this is going OT, but an > opinion would be nice) I don't think anyone's faulting legacy folks for the inefficiencies of classful assignments. What I see them being faulted for is that now, when VLSM and CIDR make giving back possible, many of them are choosing not to. (I'd say "most", but I don't think "most" have been asked yet and are likely unaware of the problem facing the RIRs soon.) Some are knowingly hoarding address space in anticipation of financial gain, aka speculation, and opting out of the need-based system the community has endorsed and which gave them those oversize (due to inefficiency) assignments in the first place. > Although we (the small SP's) have signed a v6 RSA, are we going > to get the same ridicule and harassment in the future that the > Legacy IPv4 folk are seeing today? The "ridicule and harassment" is coming from a very small group of unfortunately vocal people. The rest of us are trying to be polite and merely ask that legacy folks give back what they don't need (even using very liberal definitions of "need"). If we did a straw poll of folks favoring carrots vs. sticks, I'm quite sure the former would outnumber the latter by an overwhelming margin. And, to be pragmatic, the fact that all v6 allocations are under RSA (as you mentioned) means that ARIN could "fix" the situation with blanket /32s in IPv6 if it ever became necessary, unlike the inability to "fix" legacy IPv4 assignments. I hope that never comes to pass, and I don't see at present how it could, but ARIN is covered just in case. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From arin-contact at dirtside.com Wed Oct 24 19:02:00 2007 From: arin-contact at dirtside.com (William Herrin) Date: Wed, 24 Oct 2007 19:02:00 -0400 Subject: [ppml] hegemony, was Re: IPv6 assignment - proposal ... In-Reply-To: References: <3c3e3fca0710241041u6e4f195eo56a5a947a67396de@mail.gmail.com> Message-ID: <3c3e3fca0710241602y1a6ca2ecped0440fee7a69892@mail.gmail.com> On 10/24/07, Ted Mittelstaedt wrote: > >Folks in our industry should never forget that the early deployments > >of 300 baud modems had to be shoved down the 800 lb gorilla's throat. > > I don't. Did you even ever OWN a 300 baud modem, Bill? I'll bet > you didn't. What's your forfeit Ted? You just lost that bet. I know, how about you send me a USR Courier Dual Standard. I always wanted a modem that could do both HST and v.32 but even with the sysop discount the dang things were expensive. My first modem was a cheap 300 baud pulse dial job that came "free" with my subscription to "Quantum Link," the precursor to AOL. They were a tiny company back then, Quantum Computer Services based out of Vienna VA. Built themselves quite an empire over the following decade. AOL and the formerly little guys like them enabled the largest economic boom this country has seen in a century. All because some judge somewhere had the good policy sense to tell Ma Bell to stuff it and let the little guys compete. And when did the bubble burst? Was it before or after PI addresses became difficult to get? As I recall it was roughly one business cycle after. Coincidence? Eh, probably. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Wed Oct 24 21:33:10 2007 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 25 Oct 2007 01:33:10 +0000 Subject: [ppml] hegemony, was Re: IPv6 assignment - proposal ... In-Reply-To: References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail> <20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <20071023025821.GB7902@jeeves.rigozsaurus.com> <20071024163329.GA6796@vacation.karoshi.com.> Message-ID: <20071025013310.GA10797@vacation.karoshi.com.> On Wed, Oct 24, 2007 at 01:06:16PM -0400, Edward Lewis wrote: > At 16:33 +0000 10/24/07, bmanning at vacation.karoshi.com wrote: > > > but there is no hegonomy in operational scope... is there? > > You make it sound like "hegemony" is a bad thing. According to m-w.com: > 1) preponderant influence or authority over others : domination > 2) the social, cultural, ideological, or economic influence > exerted by a dominant group > > If hegemony in the nature of operations, policy won't remove it. > (Operations rules!) My intent was to say that policy shouldn't > (unduly) contribute to hegemony. If we are lucky, policy may reduce > it's negative impact. > > Sometimes the 800 $unit_of_weight gorilla does know better through > experience. > And sometimes the gorilla just wants more bananas for itself. ah... but then there are these pesky Articles of Incorporation: (noting that manage/conserve come first... operational routing issues are, from ARINs perspective, are things "to encourage" ISPs to do things, not nessc'ly make ARIN policy ... number 7 calls for changes to ISP policies ... or am I reading this incorrectly?) - I'm not seeing anything here that speaks to hegemony as a prefered or even desired goal. Please educate me. 4 # to manage and help conserve scarce Internet protocol resources, and to educate Internet protocol users on how to efficiently utilize these scarce resources as a service to the entire Internet community; 5 # to do all and everything necessary to enhance the growth of the Internet and the prospects for competition among Internet Service Providers by encouraging the exploration and implementation of solutions to Internet Protocol number scarcity issues; 6 # to encourage the exploration of new addressing and routing technologies that reduce or eliminate the costs or in some cases the need for renumbering when an Internet Service Provider or end user changes to a new Internet Service Provider; and, when such alternatives are developed, to work with its members to facilitate the assignment of portable addresses and/or the elimination of the cost of Internet Protocol renumbering; 7 # to encourage allocation policy changes for Internet Service Providers in order to enhance competition by providing mobility of Internet Service Providers among upstream Internet Service Providers when it is generally agreed that the technology is available for portable addressing; 8 # to manage the allocation and registration of Internet resources; From steveb at eagle.ca Thu Oct 25 08:55:07 2007 From: steveb at eagle.ca (Steve Bertrand) Date: Thu, 25 Oct 2007 08:55:07 -0400 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <041101c8167e$160d2630$9902fea9@atlanta.polycom.com> References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail><20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <041101c8167e$160d2630$9902fea9@atlanta.polycom.com> Message-ID: <4720922B.3030106@eagle.ca> > Right. One of the goals in IPv6 policy is minimizing routes in the DFZ, > and it's easiest to do that if everyone (or nearly everyone) has the > same size blocks because it's easy to filter deaggregates that way. > While a /32 is way, way too large for most LIRs, it's large enough that > nearly all LIRs > will fit in it, it's a convenient number, and everyone can filter anything > longer than /32 (except in the PIv6 block, where it's /48) with impunity > unless they specifically want deaggregates. Since we have absolutely no > clue how to route the half a billion /32s in 2000::/3, there is no > reason to > give out longer prefixes -- and plenty of reasons not to. I completely understand the importance of the allocation of blocks with as short a prefix and as consistent as possible, but thanks for the clarification. Out of curiosity, who was the original classification of size (/32 and /48) distribution designed by? Was it the community as all other ARIN policies are created by? Also, I don't pay attention to what other RIR's are doing, is this allocation scheme the same across all RIR's? > Some are > knowingly hoarding address space in anticipation of financial gain, aka > speculation, and opting out of the need-based system the community has > endorsed and which gave them those oversize (due to inefficiency) > assignments in the first place. Sounds like extortion to me. The only way anyone can profit from holding v4 addresses in speculation is if there is demand. Someone will always try to make a quick buck. Although * won't see any of such financial gain, any company that we do work for won't have to dig into their pockets because of it either. Unfortunately, IPv6 does not have enough traction to make itself or it's importance understood across the board. Perhaps most business are thinking the cost is too high for the R&D at this time, but that is too short term thinking for me. The costs of doing something later may be far higher. What ever happened to due diligence anyway? Another possible issue perhaps, will there be any network operators who will filter routes that are held or were knowingly acquired 'illegally' from a legacy holder nearer or after the runout? > If we did a straw poll of folks > favoring > carrots vs. sticks, I'm quite sure the former would outnumber the latter by > an overwhelming margin. My consensus from following this and other lists is that I concur with this statement. Steve From tedm at ipinc.net Thu Oct 25 16:34:08 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 25 Oct 2007 13:34:08 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <041101c8167e$160d2630$9902fea9@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Stephen Sprunk >Sent: Wednesday, October 24, 2007 1:24 PM >To: Steve Bertrand; bmanning at vacation.karoshi.com >Cc: ARIN PPML >Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > >Thus spake "Steve Bertrand" >>> i suspect the hoarding will be an unfortunate sideeffect of the /32 >>> v6 allocation size. sort of like the hoarding done by those >>> unfortunate souls who only needed 6 v4 addresses but were >>> "forced" to take more (a /24 if they were lucky, a /20 if they were >>> not) by their address registry. >>> >>> its not exactly fair to force people to take more addresses than >>> they need and then berate them for hoarding... is it? >> >> Interesting insight. > >IMHO, a misapplication of the term "hoarding", which I interpreted >as being >a sarcastic comment, not an actual accusation. (Michael: If I read that >wrong, please let me know so I can flame you.) > >> I, operating a small ISP as others here, directly requested a smaller >> than /32 IPv6 block, because I knew that we would almost certainly >> never need it, but it was forced upon us anyway. > >Right. One of the goals in IPv6 policy is minimizing routes in >the DFZ, and >it's easiest to do that if everyone (or nearly everyone) has the same size >blocks because it's easy to filter deaggregates that way. While a /32 is >way, way too large for most LIRs, it's large enough that nearly all LIRs >will fit in it, it's a convenient number, and everyone can filter anything >longer than /32 (except in the PIv6 block, where it's /48) with impunity >unless they specifically want deaggregates. Since we have absolutely no >clue how to route the half a billion /32s in 2000::/3, there is no >reason to >give out longer prefixes -- and plenty of reasons not to. > >> Receiving such a large address space makes it very difficult in the >> justification side of things (some would have no choice but to lie on >> the application, just to get ANY IPv6 addresses). I only received the >> allocation because of the designation that I have (ISP). Yes, we >> provide Internet services, but in terms of size, I'm no where near >> even that of 'enterprise'. I'll never use the IP's, so apparently, >> I'll be hoarding them. > >I wouldn't use that term. If you have the smallest allocation/assignment >that you need or that can be issued, you can't be "hoarding", IMHO. > >> In regard to Bill's second statement above, it sounds like a lot of >> people are doing exactly this (damning them as hoarders) for legacy >> IPv4 holders...doesn't it? When push comes to shove, why would one >> give up what was given to them, especially when they vehemently tried >> to state it wasn't warranted/needed. (I know this is going OT, but an >> opinion would be nice) > >I don't think anyone's faulting legacy folks for the inefficiencies of >classful assignments. What I see them being faulted for is that now, when >VLSM and CIDR make giving back possible, many of them are choosing not to. >(I'd say "most", but I don't think "most" have been asked yet and >are likely >unaware of the problem facing the RIRs soon.) Some are knowingly hoarding >address space in anticipation of financial gain, aka speculation, >and opting >out of the need-based system the community has endorsed and which >gave them >those oversize (due to inefficiency) assignments in the first place. > >> Although we (the small SP's) have signed a v6 RSA, are we going >> to get the same ridicule and harassment in the future that the >> Legacy IPv4 folk are seeing today? > >The "ridicule and harassment" is coming from a very small group of >unfortunately vocal people. The rest of us are trying to be polite and >merely ask that legacy folks give back what they don't need (even >using very >liberal definitions of "need"). The devil is in the definition of need. I have 10 point to point T1s. I need 10 IPv4 /24s since I assign a /24 to each circuit. That is the problem, you see. "Need" is elastic. If someone is fighting for every /24 they can get, they might even be using unnumbered, grudging even 4 IP addresses for their point to point links. I just did a support call this morning with a customer who has a site down in SBCGlobal territory. They needed a static IP on a DSL line. They were assigned a /29. SBC uses Westell DSL model 2701 DSL modems that are configured in these instances to act as routers, burning up 4 IP numbers at minimum (assuming the customer used a /30 mask, which they aren't doing) So, while all the customer needed was a single public IP on their firewall, and their firewall could speak pppoe, the setup is the sbcglobal Westell speaks PPP to SBC and wastes a /29 on it's ethernet interface. It's incredibly wasteful. Why are they doing this? Beats me - but do ya think it might have something to do with the possibility that those numbers are out of 76.192.0.0/10 and SBC is doing some hedging internally? How much would anyone want to bet me that in 5 years if the customer still has that line, that SBC will be knocking on their door telling them they can renumber into a /32 and "save a bunch of money" What, no one willing to take any sucker bets? >If we did a straw poll of folks favoring >carrots vs. sticks, I'm quite sure the former would outnumber the latter by >an overwhelming margin. > In a perfect world, yes. But when you actually start LOOKING at what the hell is HAPPENING out in the real world you will turn up PLENTY of stories like the one I just cited, and I think you will be getting the sticks out and tossing the carrots a lot faster than you think. Ted From tedm at ipinc.net Thu Oct 25 17:24:35 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 25 Oct 2007 14:24:35 -0700 Subject: [ppml] hegemony, was Re: IPv6 assignment - proposal ... In-Reply-To: <3c3e3fca0710241602y1a6ca2ecped0440fee7a69892@mail.gmail.com> Message-ID: >-----Original Message----- >From: wherrin at gmail.com [mailto:wherrin at gmail.com]On Behalf Of William >Herrin >Sent: Wednesday, October 24, 2007 4:02 PM >To: Ted Mittelstaedt >Cc: ppml at arin.net >Subject: Re: [ppml] hegemony, was Re: IPv6 assignment - proposal ... > > >On 10/24/07, Ted Mittelstaedt wrote: >> >Folks in our industry should never forget that the early deployments >> >of 300 baud modems had to be shoved down the 800 lb gorilla's throat. >> >> I don't. Did you even ever OWN a 300 baud modem, Bill? I'll bet >> you didn't. > >What's your forfeit Ted? You just lost that bet. I know, how about you >send me a USR Courier Dual Standard. I always wanted a modem that >could do both HST and v.32 but even with the sysop discount the dang >things were expensive. > :-) I have 2 of the things here - you will have to replace the power regulator caps inside them otherwise they work. Actually, laugh, but I just had a guy tell me yesterday that he got 2 of them off craigslist for $5. >My first modem was a cheap 300 baud pulse dial job that came "free" >with my subscription to "Quantum Link," the precursor to AOL. They >were a tiny company back then, Quantum Computer Services based out of >Vienna VA. > >Built themselves quite an empire over the following decade. AOL and >the formerly little guys like them enabled the largest economic boom >this country has seen in a century. No, they didn't. We had a sitting President that actually knew how to balance the budget and not go into debt to the tune of $200 billion a year. Notice how the economy booms during times the government is curtailing deficits, at least it has been for the last nearly 2 decades. When you have a national debt that overshadows the federal budget that kind of thing tends to happen. Of course, it was too good to be true. How can you have a good government based on a party and candidate that gets in office by stealing the election? >All because some judge somewhere >had the good policy sense to tell Ma Bell to stuff it and let the >little guys compete. > >And when did the bubble burst? Was it before or after PI addresses >became difficult to get? I think it was after the FCC told the cable companies that they wern't actually delivering television and voice over real wires, and thus wern't considered wire providers or telephone companies and subject to the open network access laws that the real telephone companies are subject to. >As I recall it was roughly one business cycle >after. Coincidence? Eh, probably. > It has nothing to do with that, really. Up until year 2000 the FCC was a big help to the small ISP. But after the 2000 election they knew which side of their bread was buttered and started toeing the line when Bush decided to pay back all his cronies, and commenced instituting policies that helped the large ISPs to cheat against the small ISPs. Hell the entire decade has been one long economic train wreck. We went from a booming economy with very low unemployment, government surpluses, rising wages, to a contracting economy with giant government deficits, high real unemployment, stagnant wages, dying home starts, falling home prices most places, and finally now the Dow is in freefall and even the rich who spent the first part of the decade plundering the economy are running scared. It isn't the existence or non-existence of monopolies and hegemony. It is the abrogation of any real governance or leadership by the current political party in power and the current administration. That's why they got their butts whupped during the midterms and thats why they won't be around after next year. You can have monopolies and hegemony as long as the government regulates effectively. In fact in many cases, they are needed. The small ISPs like your Quantum Link would never have existed without the existence of Ma Bell. But they also wouldn't have existed without the interference of the government - as you pointed out. I think though that your missing the fact that it took BOTH of those factors for them to exist. Far from being bad, the Bell monopoly was a necessary component - its not the monopoly itsef that is bad, it's the government that is out of wack. Ted From randy at psg.com Fri Oct 26 02:48:48 2007 From: randy at psg.com (Randy Bush) Date: Fri, 26 Oct 2007 15:48:48 +0900 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: Message-ID: <47218DD0.4000802@psg.com> [ someone asked me privately ] > Other than 1) Facilitating X.509 certification for resource holders, > and 2) Not creating a IPv6 ULA swamp, any other advice for the > RIR's? (conspicuously absent on pg 53's Summary) in that presentation (very similar to the one at nanog/abq), i did not want to get into the trading and legacy debates. the goal of the preso was a bit lower in the stack. but i personally feel that open market is the best course to flush out and get registered the under-utilized space, whether legacy or not. and, given a choice of o un/itu/... regulation o national government regulation o regulation by the rirs o an open market i strongly suspect that the latter will produce as 'fair' a distribution of resources as any of the former. (remember, current arin distribution has over three quarters of the resources going to just ten members.) what is important is as open and transparent a marketplace as possible. the x.509-based rpki will make it a safe market, no one can sell you something which they do not have the right to sell. but something open like an ebay will do a lot for keeping folk from getting ripped off on price. i doubt the rirs should be that marketplace, but perhaps rirs encouraging or aiding its formation would be reasonable. randy From vixie at isc.org Fri Oct 26 09:45:44 2007 From: vixie at isc.org (Paul Vixie) Date: 26 Oct 2007 13:45:44 +0000 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <47218DD0.4000802@psg.com> References: <47218DD0.4000802@psg.com> Message-ID: randy at psg.com (Randy Bush) writes: > but i personally feel that open market is the best course to flush out > and get registered the under-utilized space, whether legacy or not. > ... > what is important is as open and transparent a marketplace as possible. does any of this technology support tli's proposed routing table slot market? -- Paul Vixie From Lee.Howard at stanleyassociates.com Fri Oct 26 10:58:53 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 26 Oct 2007 10:58:53 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <47218DD0.4000802@psg.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> > and, given a choice of > o un/itu/... regulation > o national government regulation > o regulation by the rirs > o an open market > i strongly suspect that the latter will produce as 'fair' a > distribution of resources as any of the former. (remember, > current arin distribution has over three quarters of the > resources going to just ten members.) It may sound kind of bad, but why is it bad for ten large ISPs to aggregate routes for assignments to their customers? Lee From jcurran at istaff.org Fri Oct 26 11:16:55 2007 From: jcurran at istaff.org (John Curran) Date: Fri, 26 Oct 2007 11:16:55 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> Message-ID: At 10:58 AM -0400 10/26/07, Howard, W. Lee wrote: > > and, given a choice of >> o un/itu/... regulation >> o national government regulation >> o regulation by the rirs >> o an open market >> i strongly suspect that the latter will produce as 'fair' a >> distribution of resources as any of the former. (remember, >> current arin distribution has over three quarters of the >> resources going to just ten members.) > >It may sound kind of bad, but why is it bad for ten large ISPs >to aggregate routes for assignments to their customers? I believe that Randy's point is that an open market will likely result in availability of address blocks to all ISP's, both large and small, and this might not happen in some of the possible choices before us. /John p.s. Of course, depending on the particular rules of the "open" market, there can be a higher probability of block fragmentation since there's more value in providing (n) sites with unique blocks than one site with a block (n) times larger. Smaller ISP's may be better able to obtain blocks of addresses in such a situation, but still be the first routes dropped when the fragment routing begins. From randy at psg.com Fri Oct 26 11:17:08 2007 From: randy at psg.com (Randy Bush) Date: Sat, 27 Oct 2007 00:17:08 +0900 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: <47218DD0.4000802@psg.com> Message-ID: <472204F4.3050603@psg.com> > does any of this technology support tli's proposed routing table slot market? first, it was sean doran second, nothing is going to handle A charging B for a routing slot when B is 4 hops away (read papers on mean AS hop length) except a worse- than-itu settlement model. randy From randy at psg.com Fri Oct 26 11:20:41 2007 From: randy at psg.com (Randy Bush) Date: Sat, 27 Oct 2007 00:20:41 +0900 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> References: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> Message-ID: <472205C9.9060500@psg.com> > It may sound kind of bad, but why is it bad for ten large ISPs > to aggregate routes for assignments to their customers? can you say "barrier to market entry?" how about "cartel?" randy From arin-contact at dirtside.com Fri Oct 26 11:29:46 2007 From: arin-contact at dirtside.com (William Herrin) Date: Fri, 26 Oct 2007 11:29:46 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> References: <47218DD0.4000802@psg.com> <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> Message-ID: <3c3e3fca0710260829x2416011auec1b70eabcfc2585@mail.gmail.com> On 10/26/07, Howard, W. Lee wrote: > > (remember, > > current arin distribution has over three quarters of the > > resources going to just ten members.) > > It may sound kind of bad, but why is it bad for ten large ISPs > to aggregate routes for assignments to their customers? Lee, Start at http://lists.arin.net/pipermail/ppml/2007-October/009369.html and read the thread through http://lists.arin.net/pipermail/ppml/2007-October/009383.html. It documents harm to the US political process in 2006 as a direct result of this heirarchical aggregation approach. Why is it bad? Its bad because those customers get hurt. Regards, Bill Herrin -- William D. Herrin herrin at dirtside.com bill at herrin.us 3005 Crane Dr. Web: Falls Church, VA 22042-3004 From paul at vix.com Fri Oct 26 11:42:33 2007 From: paul at vix.com (Paul Vixie) Date: Fri, 26 Oct 2007 15:42:33 +0000 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: Your message of "Sat, 27 Oct 2007 00:17:08 +0900." <472204F4.3050603@psg.com> References: <47218DD0.4000802@psg.com> <472204F4.3050603@psg.com> Message-ID: <81715.1193413353@sa.vix.com> > > does any of this technology support tli's proposed routing table slot > > market? > > first, it was sean doran i know that's where you first heard it. but tli came to abq and talked about this, and i'm referring to tli's abq presentation here. > second, nothing is going to handle A charging B for a routing slot when > B is 4 hops away (read papers on mean AS hop length) except a worse- > than-itu settlement model. i'll take that as a "no", noting also that i disagree with your prediction. From michael.dillon at bt.com Fri Oct 26 12:42:01 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Oct 2007 17:42:01 +0100 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> Message-ID: > I believe that Randy's point is that an open market will > likely result in availability of address blocks to all ISP's, > both large and small, and this might not happen in some of > the possible choices before us. This debate is ten years too late. Maybe more. As for IPv6, all ISPs can get a /32 or more if that is not enough. And there is no impending shortage of /32s either. And I still maintain that there is insufficient liquidity for an IPv4 market to form. Most IPv4 addresses that have been allocated are locked up in networks, and cannot easily be released for resale. Releasing IPv4 addresses is not cost-free and buyers would have to pay a hefty premium to get those addresses. This would drive prices too high and that, coupled with shrinking supply of IPv4 addresses, would result in liquidity collapse if a market did attempt to form. --Michael Dillon From michael.dillon at bt.com Fri Oct 26 12:47:16 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Oct 2007 17:47:16 +0100 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <3c3e3fca0710260829x2416011auec1b70eabcfc2585@mail.gmail.com> References: <47218DD0.4000802@psg.com><369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> <3c3e3fca0710260829x2416011auec1b70eabcfc2585@mail.gmail.com> Message-ID: > Start at http://lists.arin.net/pipermail/ppml/2007-October/009369.html > and read the thread through > http://lists.arin.net/pipermail/ppml/2007-October/009383.html. > It documents harm to the US political process in 2006 as a > direct result of this heirarchical aggregation approach. I don't see it documenting any harm. It sounds to me like network engineer who doesn't understand networking 101 didn't realize that you cannot take IP addresses with you when you move and therefore made some serious mistakes in infrastructure that did not allow the customer (Democrats?) to renumber easily. > Why is it bad? Its bad because those customers get hurt. Then they should transition to IPv6, get a /48, and build their network so that it can easily renumber if that /48 prefix changes. No more pain. --Michael Dillon From Lee.Howard at stanleyassociates.com Fri Oct 26 13:32:32 2007 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 26 Oct 2007 13:32:32 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <472205C9.9060500@psg.com> Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB407675F91@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Friday, October 26, 2007 11:21 AM > To: Howard, W. Lee > Cc: Public Policy Mailing List > Subject: Re: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf > > > It may sound kind of bad, but why is it bad for ten large ISPs to > > aggregate routes for assignments to their customers? > > can you say "barrier to market entry?" how about "cartel?" I'm capable of pronouncing the words, but I don't see how they apply. If everyone is able to get what they need, even if some people need more, there's no barrier. Maybe you mean that it's unfair that ARIN has a minimum allocation size. There's a policy proposal process for changing that size. Proposals for changing it have occasionally found consensus. Maybe you mean (as John Curran suggests) that in some future scenarios, more ISPs would be able to get portable address space. While that might be true, I'm failing to see the relevance. Bill Herrin pointed out a thread (which I did read at the time) where several arguments were advanced: * assertion that it's unfair that organizations pay by ARIN- workload, not per-address * assertion that it stinks that a customer moving a longer-than- /24 between different upstream ASNs has to renumber * assertion that representation from extra-large ISPs is disproptortionately low on list, and representation at meetings is 100 organizations wide Maybe I missed the relevant point. I appreciate everyone's efforts, but I still don't understand your point. I'm sure the communication failure is on my end, but I could really use short, declarative sentences, in the active voice, which don't rely on inference to understand relevance. Lee From Keith at jcc.com Fri Oct 26 13:36:51 2007 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 26 Oct 2007 13:36:51 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf Message-ID: >Then they should transition to IPv6, get a /48, and build their network >so that it can easily renumber if that /48 prefix changes. No more pain. This assumes that the technology actually exists to easily renumber if the /48 prefix changes. The pieces I have not yet seen are: -- Firewalls -- With IPv4, the firewall rules are built in terms of IP addresses. Will IPv6 firewalls do something similar or will there be a single place to specify a prefix? -- Intrusion Detection & Network monitoring appliances -- is it (or will it be possible) to specify an IPv6 prefix someplace rather than embedding the entire IP address in rules? -- VPNs -- How do I change an IP on a VPN link if I don't control the other end? What if I do control the other end, but it is remote? -- If /48 prefix changes, will my customers/vendors/etc. require another security audit? I'm sceptical that the technology exists today to easily renumber a business network if a /48 prefix changes. Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From billf at powerset.com Fri Oct 26 14:03:59 2007 From: billf at powerset.com (Bill Fumerola) Date: Fri, 26 Oct 2007 11:03:59 -0700 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: Message-ID: "Keith W. Hare" on 10/26/07 10:36 AM scribed thusly: >> Then they should transition to IPv6, get a /48, and build their network >> so that it can easily renumber if that /48 prefix changes. No more > pain. > > This assumes that the technology actually exists to easily renumber if > the /48 prefix changes. > > The pieces I have not yet seen are: > > -- Firewalls -- With IPv4, the firewall rules are built in terms of IP > addresses. Will IPv6 firewalls do something similar or will there be a > single place to specify a prefix? with IPv4, firewall rules are built in terms of numbers and masks. with IPv6, firewall rules are built in terms of numbers and masks. adding transition rules for either is not hard. IPv6 tends to make this easier with a larger probability there is a 1:1 mapping from old to new. IPv4 renumbering often comes prefix & subnet size changes which make 1:1 mapping not always possible. regardless, the technology has existed since 1977. it's called m4 (or cpp). > -- Intrusion Detection & Network monitoring appliances -- is it (or will > it be possible) to specify an IPv6 prefix someplace rather than > embedding the entire IP address in rules? see above, the technology has existed since 1977. it's called m4 (or cpp). more advanced systems (like puppet[1]) can use ruby to generate/distribute configuration files. you can even use languages like php to generate config files if m4 or cpp is too low level. > -- VPNs -- How do I change an IP on a VPN link if I don't control the > other end? What if I do control the other end, but it is remote? no control of the remote: contact the person who does. control of the remote: add new addressing, (re-)connect using new addressing, remove old addressing. if appropriate in your environment, using ULA-{C,L,U} for inside tunnel addressing can also decrease the probability of having to renumber those addresses down to limit(1/x, x->Inf). > -- If /48 prefix changes, will my customers/vendors/etc. require another > security audit? there are lots of things that may or may not triggering an audit. if you have to renumber from one PA space to another PA space, you're presumably changing providers. that may bring about many things that trigger an audit (e.g. new circuits, other changes configuration on gear, etc). > I'm sceptical that the technology exists today to easily renumber a > business network if a /48 prefix changes. while you remain sceptical [sic], people who can template their configurations and effectively manage their equipment will be passing by those that can't (or don't). there are plenty of things that make renumbering annoying, but it's not rocket science nor is it impossible. anyone who has had to renumber V4 a few times should have the scars and the vision to take advantage of the improvements/features in IPv6-land that make renumbering easier there. -- billf 1. http://reductivelabs.com/projects/puppet/ From briand at ca.afilias.info Fri Oct 26 14:34:39 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 26 Oct 2007 14:34:39 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> Message-ID: <4722333F.3030200@ca.afilias.info> John Curran wrote: >>> Randy wrote: >>> and, given a choice of >>> o un/itu/... regulation >>> o national government regulation >>> o regulation by the rirs >>> o an open market >>> i strongly suspect that the latter will produce as 'fair' a >>> distribution of resources as any of the former.[...] >>> > I believe that Randy's point is that an open market will likely > result in availability of address blocks to all ISP's, both large > and small, and this might not happen in some of the possible > choices before us. > > > /John > > p.s. Of course, depending on the particular rules of the "open" > market, there can be a higher probability of block fragmentation > since there's more value in providing (n) sites with unique blocks > than one site with a block (n) times larger. Everything depends on the meaning and contect of "open". Per Ben Edelman (who has been engaged as a consultant by ARIN and who spoke on IP markets), getting into the details of how a market might operate, before deciding that a white market should exist and/or be operated/facilitated by {ARIN|RIRs|IANA|whoever}, is putting the cart before the horse (to paraphrase). My $0.02 is: I think the "open" in open market should be primarily limited to pricing. Anyone with address space should be able to ask for whatever $$$ they think they can get. However, I think that, since there is more than a mere commodity aspect to IP address blocks, that some additional regulation would be needed to prevent disasterous outcomes. Things to avoid: - market manipulation by collusion, cartels, or any other kind of deliberate action - direct sales between parties (this is something better characterized as "grey" or "black" market) - speculation, cornering of the market, or other blanket market abuse by those with deep pockets - purchases directly by recipients, without approval or intermediation by RIRs or similar agents (to prevent inappropriate allocation of resources) - deaggregation Things to encourage: - transparency of operation of the market - blind, double-blind, or N-tuple blind market - separation of the two sides of the market, i.e. those selling blocks and those buying, by RIR-type entity (who is also "blind") - aggregation between return of blocks to RIR-type entity, and allocation/sale to RIR customers - decoupling buying/selling aspects by way of combined purchasing pool - decoupling funding of purchases from allocation (effectively turning "purchasing" into "donating to the fund for getting space back into the RIR pool") - creating contingency-blocking "trees" similar to real-estate "chains"-of-conditional-purchases, e.g. in real-estate, there can be multiple transactions which are effectively blocked, until a transaction which has no conditions on it, is able to trigger the completion of all of the transactions in the chain. This can be extended with a non-trivial dependency topology, where N:1 and 1:N branching/merging of transaction sets, trigger "go/no-go" events on the whole tree. - coupling contingency-based bidding/donating with purchase&allocate events - someone's donation gets accepted iff their allocation request is satisfied It's a highly non-trivial kind of thing to delve into, but IMHO something which can work very well, *and* actually has some chance to improve the aggregation situation in IPv4. Imagine getting some return on the effort involved in renumbering, when previously the only benefit was knowing you were doing "the right thing". Brian From michael.dillon at bt.com Fri Oct 26 15:02:10 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Oct 2007 20:02:10 +0100 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: Message-ID: > The pieces I have not yet seen are: > > -- Firewalls -- With IPv4, the firewall rules are built in > terms of IP addresses. Will IPv6 firewalls do something > similar or will there be a single place to specify a prefix? Linux iptables has had IPv6 support since 2001 so I can't believe it is so hard to find a v6 firewall. Since it can be configured by shell script it is trivial to specify the prefix in one place. If your issues are with the management interface on commercial firewalls, then you can either implement a Linux firewall, or hammer your favourite vendor to fix their broken system. > -- Intrusion Detection & Network monitoring appliances -- is > it (or will it be possible) to specify an IPv6 prefix > someplace rather than embedding the entire IP address in rules? Same thing as above. This is trivial to implement and since the IETF guidelines state that all end sites will receive a /48 in order to simplify renumbering, then vendors of IPv6 products really should make it easy to *ADD* additional prefixes to the same ruleset, and *REMOVE* a prefix from a ruleset. Remember that IPv6 renumbering is done by adding a prefix so that all interfaces have two IPv6 addresses during a transition timeperiod, then removing the old prefix. > -- VPNs -- How do I change an IP on a VPN link if I don't > control the other end? What if I do control the other end, > but it is remote? This is a management system problem. Again solvable by demanding your vendors make it so. > -- If /48 prefix changes, will my customers/vendors/etc. > require another security audit? Seems overkill to do a security audit if all you are doing is a managed renumbering. I would suggest that you test your IPv6 renumbering process from the beginning, document the process, and then include a test of this process as part of the first IPv6 security audit. > I'm sceptical that the technology exists today to easily > renumber a business network if a /48 prefix changes. It does exist if you use Linux or *BSD boxes for firewall functions etc. If commercial vendors have not yet implemented, it is not because of a lack of technology. --Michael Dillon From michael.dillon at bt.com Fri Oct 26 15:12:41 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Oct 2007 20:12:41 +0100 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: Message-ID: > regardless, the technology has existed since 1977. it's > called m4 (or cpp). Macro and scripting languages were invented a lot earlier than 1977. These days Python seems to be the favourite to add a scripting language to an application. > if appropriate in your environment, using ULA-{C,L,U} for > inside tunnel addressing can also decrease the probability of > having to renumber those addresses down to limit(1/x, x->Inf). The only kind of ULA that exists currently is the kind defined in RFC 4193. There may be no other kinds since RFC 4193 ULA addresses do the job that is needed, and there is enough space allocated to give everyone 118 different /48s if anyone had such a need. There is a handy tool here to generate your own ULA and if you feel the need, you can also add it to the registry but that is not necessary if you don't want to. > there are plenty of things that make renumbering annoying, > but it's not rocket science nor is it impossible. anyone who > has had to renumber V4 a few times should have the scars and > the vision to take advantage of the improvements/features in > IPv6-land that make renumbering easier there. And most importantly, IPv6 is greenfield so you can plan for, and test, renumbering from day 1. --Michael Dillon From tedm at ipinc.net Fri Oct 26 15:21:41 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 26 Oct 2007 12:21:41 -0700 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >michael.dillon at bt.com >Sent: Friday, October 26, 2007 9:42 AM >To: ppml at arin.net >Subject: Re: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf > > >> I believe that Randy's point is that an open market will >> likely result in availability of address blocks to all ISP's, >> both large and small, and this might not happen in some of >> the possible choices before us. > >This debate is ten years too late. Maybe more. > >As for IPv6, all ISPs can get a /32 or more if that is not enough. >And there is no impending shortage of /32s either. > >And I still maintain that there is insufficient liquidity for >an IPv4 market to form. I agree - and furthermore, there IS NO SUCH THING AS AN OPEN MARKET A truly open market is one in which there was NO recourse to the government or courts if someone fails to uphold their end of a contract - or anything else - because, after all, in an open market, if someone fails to uphold their end, their reputation will cause the rest of the players in the market to avoid them, in which case they will go out of business. The concept of "open market" is a fiction they use to teach economic theory to 1st year economics students. It does not exist anywhere in the world. It might have existed 600 years ago in some feudal manor somewhere but that's it. ALL governments regulate markets. Some call it 'interference' of course. This is true whether they are dictatorships or communistic or democracies - they all regulate. Thus the market isn't really open. Thus the question IS NOT a choice between the fiction of a so-called "open market" and a regulated market. It is really a question of "if we are going to have a market, how much are we going to regulate" >Most IPv4 addresses that have been allocated >are locked up in networks, and cannot easily be released for resale. >Releasing IPv4 addresses is not cost-free and buyers would have to >pay a hefty premium to get those addresses. This would drive prices >too high and that, coupled with shrinking supply of IPv4 addresses, >would result in liquidity collapse if a market did attempt to form. > Which is another way of saying that only the largest cash-rich players could afford to waste the money on chasing scraps of IPv4 here and there. In other words - your creating a market as a perk for rich people, using the flag of "open market" The US has had a LOT of experience with this happening in the last 6 years, you would think most people would have learned to recognize being snookered by now. Ted From tedm at ipinc.net Fri Oct 26 15:29:01 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 26 Oct 2007 12:29:01 -0700 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <4722333F.3030200@ca.afilias.info> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Brian Dickson >Sent: Friday, October 26, 2007 11:35 AM >To: John Curran >Cc: Public Policy Mailing List >Subject: Re: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf > > >My $0.02 is: >I think the "open" in open market should be primarily limited to >pricing. I think your attempting to redefine "open market" instead of using the term "regulated market" which already means exactly what your trying to redefine "open market" to mean. I think your trying to do this because you understand there's emotional positive connotations with the phrase "open market" and emotional negative terms with the phrase "regulated market" and your trying to use these to generate support for a proposal that would otherwise fail. If you can't use correct terminology and call a spade a spade, then your pulling a fast one. Please knock it off. What your talking about is a regulated market, not an open market. Ted From tedm at ipinc.net Fri Oct 26 15:40:13 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 26 Oct 2007 12:40:13 -0700 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >michael.dillon at bt.com >Sent: Friday, October 26, 2007 12:02 PM >To: ppml at arin.net >Subject: Re: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf > > >> The pieces I have not yet seen are: >> >> -- Firewalls -- With IPv4, the firewall rules are built in >> terms of IP addresses. Will IPv6 firewalls do something >> similar or will there be a single place to specify a prefix? > >Linux iptables has had IPv6 support since 2001 so I can't believe it is >so hard to find a v6 firewall. You can download an IPv6 firewall for Windows XP from here: http://technet.microsoft.com/en-us/network/bb530961.aspx if your a Windows user and not a Linux user. IPv6 will be integrated into Server 2008 and is already in Vista. Earthlink produced IPv6 firmware for the Linksys WRT54G you can fetch from here: http://www.research.earthlink.net/ipv6/ if your definition of a firewall is that of a toy for the home, not a real commercial-quality box. Ted From briand at ca.afilias.info Fri Oct 26 15:45:16 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Fri, 26 Oct 2007 15:45:16 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: Message-ID: <472243CC.3040107@ca.afilias.info> Ted Mittelstaedt wrote: > What your talking > about is a regulated market, not an open market. > s/open/regulated/g (and while we're at it, s/your/you're/g). Now, since I don't care what it's called, can we get on with discussion on what it should/would/could look like and how it might work? (Please send all label discussions to /dev/null from now on. I'd rather not procmail unnecessarily, since I think you have interesting things to say on technical stuff.) Brian From michael.dillon at bt.com Fri Oct 26 16:03:17 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 26 Oct 2007 21:03:17 +0100 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: Message-ID: > >Linux iptables has had IPv6 support since 2001 so I can't > believe it is > >so hard to find a v6 firewall. > > You can download an IPv6 firewall for Windows XP from here: > Earthlink produced IPv6 firmware for the Linksys WRT54G you > can fetch from here: Right, so not only has IPv6 firewall technology been around since at least 2001 (if not longer) it is now already making its way into consumer products as well. According to this talk commercial firewalls supporting IPv6 are available. IPCop is based on Linux m0n0wall is based on FreeBSD pfSense is also based on FreeBSD FWBuilder is a management tool that builds filter setups for several different firewalls. Checkpoint FW1 NGX R65 on SecurePlatform supports IPv6 FortiGate supports IPv6 in FortiOS 3.0 and up. Juniper SSG (formerly Netscreen) supports IPv6 in ScreenOS 6.0 and up. Cisco ASA (formerly PIX) supports IPv6 in version 7.0 and up. I suspect that the people complaining about IPv6 support are partially complaining because they have older hardware that the vendor does not plan to upgrade to IPv6 support until they have all features implemented in their newer products, and partially complaining because their vendor has not implemented some feature which they happen to use. Commercial firewall support may be lagging behind OS and router support, but not by much. And if commercial vendors are not responsive, maybe you should try pricing out an open source solution with a consultant. I believe there is a gap here that startup firewall companies could fill if they understand the enterprise market. --Michael Dillon From tedm at ipinc.net Fri Oct 26 16:24:31 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 26 Oct 2007 13:24:31 -0700 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >michael.dillon at bt.com >Sent: Friday, October 26, 2007 1:03 PM >To: ppml at arin.net >Subject: Re: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf > > > >Cisco ASA (formerly PIX) supports IPv6 in version 7.0 and up. > Great list! Don't forget Cisco IOS - IPv6 support in mainline since 12.4 and in earlier versions in feature sets. Current Cisco small router series - the 1800/2800/3800 comes with a Firewall Feature Set as it's included IOS load and has IPv6 support. And also don't forget the open source routing daemon Quagga: http://www.quagga.net BGP4+ including support for IPv6. Note strictly a firewall but you can run it on a system that has an IPv6 firewall. >I suspect that the people complaining about IPv6 support are partially >complaining because they have older hardware that the vendor does not >plan to upgrade to IPv6 support until they have all features implemented >in their newer products, and partially complaining because their vendor >has not implemented some feature which they happen to use. > I agree but I think it's unlikely the vendors will ever update many of these older products - not unless the vendor maintains service contracts. And some may have firmware updates but will require purchase of more ram or flash or both. Note that BOTH Microsoft and Cisco publish very detailed product lifecycles so you know the day you purchase the product how long the vendor will support it - you have NO right to go complaining if one of your devices from one of these vendors is older than the support end date. One BIG problem is that a large number of smaller businesses are using DSL or Cable, where the DSL modem is also a router, or the cable modem is also a router. Aside from the DSL provider support of IPv6 most likely being nonexistent, none of these modem/router products I'm aware of contain IPv6, at least not English localized in the US products. These companies are going to have to get used to the idea that to run IPv6 when their provider gets around to offering it, that they will need to put these devices into bridged mode and go BUY firewalls that can speak PPPoEese or whatever their provider runs. >Commercial firewall support may be lagging behind OS and router support, >but not by much. And if commercial vendors are not responsive, maybe you >should try pricing out an open source solution with a consultant. I >believe there is a gap here that startup firewall companies could fill >if they understand the enterprise market. > I think that there will be a gap in the DSL and Cable provider market a lot sooner. Ted From sleibrand at internap.com Fri Oct 26 19:04:01 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Fri, 26 Oct 2007 16:04:01 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <47218DD0.4000802@psg.com> Message-ID: <47227261.6000206@internap.com> Paul Vixie wrote: > randy at psg.com (Randy Bush) writes: > >> but i personally feel that open market is the best course to flush out >> and get registered the under-utilized space, whether legacy or not. >> ... >> what is important is as open and transparent a marketplace as possible. >> > > does any of this technology support tli's proposed routing table slot market? > In my opinion a full-settlement routing table slot market is impractical and undesirable. However, as Tony outlined at the markets panel at ABQ, there needs to exist some sort of backpressure against the deaggregation and global announcement of too many small blocks. If we set the conditions properly, I believe we can create the framework for such backpressure to exist, and place the economic cost of announcing deaggregates largely on the originator rather than as an externality on the entire DFZ. For your weekend reading pleasure, below is one way it might work. Keep in mind that what I'm outlining is not practical or desirable today, because the current underlying cost of a routing slot is so small compared to the cost of passing traffic. The scenario outlined here will only come to exist if the post-free-pool-exhaustion demand for IPv4 space and routing slots outpaces the ability of ISPs to provide additional routing slots relatively cheaply. Firstly, we need to keep something close to the existing IPv4 minimum block sizes. Today multihomed orgs can get /22s and larger from ARIN, and non-multihomed orgs can get /20s and larger. Let's assume that we continue such a policy into the post-exhaustion era, allowing transfers only of blocks of that size or larger. The other part of the framework is that major DFZ participants (particularly tier 1 NSPs) would need to agree on a BCP to require everyone (or their ISP) to announce RIR-minimum-size covering aggregates for all their announced space. For any cases where that is impractical, they could instead agree to tag (i.e. with communities) and accept more-specifics that don't have a covering aggregate. If significant numbers of such routes exist, they would likely be the subject of peering negotiations, much as with traffic ratios today. With those two pieces in place, it becomes possible to differentiate between aggregates, which are required for reachability and should be accepted across the DFZ, and more-specifics, which only need to be accepted by networks maintaining a business relationship of some kind. If routing slots are still cheap, no one would have any real incentive to filter such more-specifics, but if the number of routes grows at more than 2X the current rate, I could see filtering and routing slot backpressure developing along lines something like this: Say you have a multihomed network who wants finer-grained control over their inbound traffic than can be obtained with AS path prepends and localpref communities. They contact their ISPs and ask them to open their prefix-lists for their more-specifics. The ISPs do so (possibly charging the customer based on the number of routes announced), and also update their prefix-lists to accept the more-specifics from their peers. (If either of the ISPs buys transit, they request that their upstreams accept the route as well, and the upstreams also accept the route from their peers.) This ensures that all of the network's upstreams accept the route, both directly from their downstreams as well as from any other upstreams, and gives the multihomed network full control over which of their links inbound traffic arrives on. However, any tier 1s that are not upstreams (and not being paid) need not accept the more-specifics, and can simply route based on the covering aggregate. Once traffic hits one of the network's upstreams, the more-specific will take over. All of this may seem rather complicated compared to today's system, but remember that this would only make sense if the cost of routing table slots goes up dramatically. If the cost remains low, then we don't have a problem and can continue business as usual. But if it does, we have decent mechanisms, using existing deployed technologies and business relationships, to relieve the pressure. The most important factor here, however, is maintaining a reasonable minimum top-level prefix size. As long as that level of aggregation exists, we can allow more-specifics to be announced to upstreams for TE, while preserving the ability of parties not being paid to filter them without losing reachability. However, if we go ahead and allow full deaggregation down to /24, as Geoff's proposal in APNIC would do, then we lose the ability to filter such routes without losing reachability. -Scott From michael.dillon at bt.com Sat Oct 27 04:27:57 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 27 Oct 2007 09:27:57 +0100 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <4722333F.3030200@ca.afilias.info> References: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> <4722333F.3030200@ca.afilias.info> Message-ID: > Things to encourage: > - transparency of operation of the market > - blind, double-blind, or N-tuple blind market > - separation of the two sides of the market, i.e. those > selling blocks and those buying, by RIR-type entity (who is > also "blind") How does this blindness fit with "transparency of operation". In any case, it will always be known who was the registered owner of an address block, and who is the new registered owner so unless you keep the identity of the address secret, there will be no blindness. And if the addresses are secret, then it becomes risky to buy them because not all addresses are equal. > It's a highly non-trivial kind of thing to delve into, but > IMHO something which can work very well, *and* actually has > some chance to improve the aggregation situation in IPv4. It sounds like the time is long past when we could have set up such a market because it is a non-trivial exercise and we have only two or three years of supply left. In addition, the cost of setting up such a complex and highly regulated market has to be weighed against the cost of IPv6 transition, given the abundant supply of free IPv6 addresses. --Michael Dillon From michael.dillon at bt.com Sat Oct 27 05:04:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sat, 27 Oct 2007 10:04:09 +0100 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <47227261.6000206@internap.com> References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com> Message-ID: > However, if we go ahead and allow full > deaggregation down to /24, as Geoff's proposal in APNIC would > do, then we lose the ability to filter such routes without > losing reachability. Allow? What business does ARIN or APNIC or RIPE have in allowing or disallowing any kind of route announcements? It is not in the charter of ARIN or in the terms of reference of RIPE. Is there a significant number of ISPs who are about to sign some kind of routing treaty? --Michael Dillon From gih at apnic.net Sat Oct 27 05:50:41 2007 From: gih at apnic.net (Geoff Huston) Date: Sat, 27 Oct 2007 19:50:41 +1000 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: Message-ID: <472309F1.8010107@apnic.net> Ted Mittelstaedt wrote: > I agree - and furthermore, there IS NO SUCH THING AS AN OPEN MARKET > > A truly open market is one in which there was NO recourse to the > government or courts if someone fails to uphold their end of a > contract - or anything else - because, after all, in an open market, > if someone fails to uphold their end, their reputation will cause the > rest of the players in the market to avoid them, in which case they > will go out of business. > This assertion confuses the terms "free market" and "open market" You may find that wikipedia could help you here with a quick primer on basic terms related to characteristics of markets. I'm sure there are many related entries, but you may find http://en.wikipedia.org/wiki/Free_market helpful here. From briand at ca.afilias.info Sat Oct 27 09:17:44 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Sat, 27 Oct 2007 09:17:44 -0400 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> <4722333F.3030200@ca.afilias.info> Message-ID: <47233A78.2070405@ca.afilias.info> michael.dillon at bt.com wrote: >> Things to encourage: >> - transparency of operation of the market >> - blind, double-blind, or N-tuple blind market >> - separation of the two sides of the market, i.e. those >> selling blocks and those buying, by RIR-type entity (who is >> also "blind") >> > > How does this blindness fit with "transparency of operation". Any number of ways. But that's an implementation question... > In any case, it will always be known who was the registered owner of an address > block, and who is the new registered owner so unless you keep the > identity of the address secret, there will be no blindness. Correct. > And if the > addresses are secret, then it becomes risky to buy them because not all > addresses are equal. > > Which would be why I suggest (in the bit you kept quoted!!!) separating the two sides of the market. Basically, something like an RIR (or actual RIRs, or IANA) would still be allocating blocks, just like today, but with the addition of bids or donations, to fund the re-acquisition of blocks *by* the allocating entity. The allocation side is blind today - you don't get to choose what block you are given. So, that doesn't change under this split market. And, I envision the market augmenting existing RIR function, not replacing/displacing it. The split in the market would exist so that addresses would become available for both "bidding" and "requesting (unpaid except for RIR fees)" requesters. It would still be possible for someone to request a block from an RIR and get one which was purchased by the RIR, without the recipient having to directly purchase it. The "market" would exist primarily on the seller side, between the allocation entity, and the holders of space that is unused or underused. Having *that* operate transparently to the community at large, but blind to the buyer/sellers, ensures that no hanky-panky occurs. SOX would probably help there too, in making sure at worst, there is the ability to audit activity. It may even be necessary to have the buyer's staff (who are directly involved) be bonded. >> It's a highly non-trivial kind of thing to delve into, but >> IMHO something which can work very well, *and* actually has >> some chance to improve the aggregation situation in IPv4. >> > > It sounds like the time is long past when we could have set up such a > market because it is a non-trivial exercise and we have only two or > three years of supply left. > The benefit of the market, is in bringing additional supply to the IPv4 pool. That will continue to have benefit after the IANA "original" allocations to RIRs has finished. > In addition, the cost of setting up such a complex and highly regulated > market has to be weighed against the cost of IPv6 transition, given the > abundant supply of free IPv6 addresses. > If IPv4 and IPv6 were natively interoperable, that would be true. However, they are not. The value of an IPv4 market is *independent* of the availability and value of IPv6 space. Brian From vixie at isc.org Sat Oct 27 10:58:34 2007 From: vixie at isc.org (Paul Vixie) Date: 27 Oct 2007 14:58:34 +0000 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com> Message-ID: michael.dillon at bt.com writes: > What business does ARIN or APNIC or RIPE have in allowing or disallowing > any kind of route announcements? It is not in the charter of ARIN or in > the terms of reference of RIPE. Is there a significant number of ISPs > who are about to sign some kind of routing treaty? that's what tli advised us to do during his ARIN XX preso in ABQ. as far as i could tell, the ISPs in the room didn't immediately run out into the hall to discuss details. but that doesn't mean we oughtn't discuss it, since the predicted backpressure-free market mechanics don't seem wonderful. -- Paul Vixie From kloch at kl.net Sat Oct 27 13:16:04 2007 From: kloch at kl.net (Kevin Loch) Date: Sat, 27 Oct 2007 13:16:04 -0400 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com> Message-ID: <47237254.7050306@kl.net> michael.dillon at bt.com wrote: >> However, if we go ahead and allow full >> deaggregation down to /24, as Geoff's proposal in APNIC would >> do, then we lose the ability to filter such routes without >> losing reachability. > > Allow? > > What business does ARIN or APNIC or RIPE have in allowing or disallowing > any kind of route announcements? It is not in the charter of ARIN or in > the terms of reference of RIPE. Is there a significant number of ISPs > who are about to sign some kind of routing treaty? What the RIR's could do is limit subdivision of assignments to only a certain level when transferring them. If you had a /16 you could only sell it off in chunks of /20 for example. The current RIR's have the best chance of implementing those kinds of restrictions by supporting markets early, but time is running out. - Kevin From sleibrand at internap.com Sat Oct 27 13:27:13 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 27 Oct 2007 10:27:13 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com> Message-ID: <472374F1.3010904@internap.com> michael.dillon at bt.com wrote: >> However, if we go ahead and allow full >> deaggregation down to /24, as Geoff's proposal in APNIC would >> do, then we lose the ability to filter such routes without >> losing reachability. >> > > Allow? > > What business does ARIN or APNIC or RIPE have in allowing or disallowing > any kind of route announcements? It is not in the charter of ARIN or in > the terms of reference of RIPE. Is there a significant number of ISPs > who are about to sign some kind of routing treaty? > I'm not referring to "allowing" announcement of more-specifics out of a larger aggregate. Geoff's proposal would allow you to break up and transfer (in APNIC's database) individual /24's, basically turning all of APNIC's space into a larger class C swamp. That is a problem because you can't filter such routes without losing reachability, whereas if someone advertises a more-specific /24 out of a /22 or larger aggregate for TE purposes (as we see today), that more-specific need not be accepted by every network on the Internet. -Scott From sleibrand at internap.com Sat Oct 27 13:41:46 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Sat, 27 Oct 2007 10:41:46 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <47237254.7050306@kl.net> References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com> <47237254.7050306@kl.net> Message-ID: <4723785A.9040002@internap.com> Kevin Loch wrote: > michael.dillon at bt.com wrote: > >> What business does ARIN or APNIC or RIPE have in allowing or disallowing >> any kind of route announcements? It is not in the charter of ARIN or in >> the terms of reference of RIPE. Is there a significant number of ISPs >> who are about to sign some kind of routing treaty? >> > > What the RIR's could do is limit subdivision of assignments to > only a certain level when transferring them. If you had a /16 you > could only sell it off in chunks of /20 for example. > That's exactly the kind of thing I'm talking about. The exact mechanics could work in a number of ways: an across-the-board minimum allocation size, a maximum deaggregation factor (such as 4 bits longer than the current allocation size, as in your /16 to /20 example), or more likely some combination of things like that. But IMO the most important factor is that we preserve as much top-level aggregation as possible, to preserve the ability to filter deaggregates if necessary without losing reachability. > The current RIR's have the best chance of implementing those kinds > of restrictions by supporting markets early, but time is running out. > Based on the discussions at ABQ, I think that discussion has now started in earnest, and that we should continue it here and see if we can get consensus around a possible policy proposal. -Scott From iljitsch at muada.com Sun Oct 28 10:51:16 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 28 Oct 2007 15:51:16 +0100 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB407675E0C@CL-S-EX-1.stanleyassociates.com> Message-ID: On 26 okt 2007, at 17:16, John Curran wrote: > I believe that Randy's point is that an open market will likely > result in availability of address blocks to all ISP's, both large > and small, and this might not happen in some of the possible > choices before us. Anyone who needs a stream of fresh IP addresses to stay in business and is still betting on IPv4 when their RIR of choice has to say to a LIR "you qualify but we don't have the space" for the first time is completely delusional. An IPv4 address space market will be very helpful--in promoting IPv6. From iljitsch at muada.com Sun Oct 28 11:25:52 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sun, 28 Oct 2007 16:25:52 +0100 Subject: [ppml] Reducing unnecessary BGP announcements, was: Re: IPv4 address and routing slot markets In-Reply-To: References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com> Message-ID: On 27 okt 2007, at 16:58, Paul Vixie wrote: >> What business does ARIN or APNIC or RIPE have in allowing or >> disallowing >> any kind of route announcements? It is not in the charter of ARIN >> or in >> the terms of reference of RIPE. Is there a significant number of ISPs >> who are about to sign some kind of routing treaty? > that's what tli advised us to do during his ARIN XX preso in ABQ. > as far > as i could tell, the ISPs in the room didn't immediately run out > into the > hall to discuss details. but that doesn't mean we oughtn't discuss > it, > since the predicted backpressure-free market mechanics don't seem > wonderful. Sometimes all it takes is someone with a vision and a route filter. How about this: out of the weekly routing table report and the RIR allocation record, a filter is created that removes unnecessarily unaggregated prefixes. The filter is sorted in order of decreasing number of prefixes filtered out. People then install the first X lines for whatever value of X best suits them. This will generate a lot of pressure on the worst offenders to do better. From Fred.Wettling at Bechtel.com Mon Oct 29 11:35:09 2007 From: Fred.Wettling at Bechtel.com (Wettling, Fred) Date: Mon, 29 Oct 2007 11:35:09 -0400 Subject: [ppml] Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <471CC069.6040005@arin.net> References: <471CC069.6040005@arin.net> Message-ID: <3400197AD5EC0540BC920AB9A1FD243311BC2483@fres0094.amers.ibechtel.com> I oppose this proposal. ARIN Policy 6.5.4. Assignments from LIRs/ISPs is fine as-is. In addition to Tony Hain's comments, there are some additional practical issues based on the experience of deploying IPv6 on a large number of sites. 1. Stateless auto-configuration works and is deployed in many commercial products today. It's based on RFC 2374 - "An IPv6 Aggregatable Global Unicast Address Format" with the last 64 bits designated as the interface ID. A policy that opposes the fundamental addressing structure of an established protocol should be avoided. 2. We should assume that EUI-64 will be the standard as explicitly defined by IEEE. http://standards.ieee.org/regauth/oui/tutorials/EUI64.html A policy that opposes the fundamental addressing structure of an established standard should be avoided. 3. Address allocation should not be dependent on the address assignment method used by an organization. These will change over time. 4. IPv6 addressing plans for enterprises with multiple sites will often contain patterns that are applied across multiple sites... regardless of size. For example, MIPv6, HMIPv6 Multicast, DMZ, voice, video, etc. Operational efficiencies are possible if the same patterns can be applied to each site of an enterprise. 5. LIR allocations, aggregations, and management will be easier with fewer blocks per customer, not more. BTW, I also disagree with Bill Herrin's comments that stateless auto-configuration will "go down in flames". See RFC 3041 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" Regards, Fred Wettling Bechtel Corporation From BillD at cait.wustl.edu Mon Oct 29 11:40:58 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 29 Oct 2007 10:40:58 -0500 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <47237254.7050306@kl.net> References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com> <47237254.7050306@kl.net> Message-ID: Please tell me simply what keeps those who wish to de-aggregate their available blocks beyond that which ARIN will sanction...from using the gray or black market to do so. Bill Darte ARIN Advisory Council -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Kevin Loch Sent: Saturday, October 27, 2007 12:16 PM To: ppml at arin.net Subject: Re: [ppml] IPv4 address and routing slot markets michael.dillon at bt.com wrote: >> However, if we go ahead and allow full >> deaggregation down to /24, as Geoff's proposal in APNIC would >> do, then we lose the ability to filter such routes without >> losing reachability. > > Allow? > > What business does ARIN or APNIC or RIPE have in allowing or disallowing > any kind of route announcements? It is not in the charter of ARIN or in > the terms of reference of RIPE. Is there a significant number of ISPs > who are about to sign some kind of routing treaty? What the RIR's could do is limit subdivision of assignments to only a certain level when transferring them. If you had a /16 you could only sell it off in chunks of /20 for example. The current RIR's have the best chance of implementing those kinds of restrictions by supporting markets early, but time is running out. - Kevin _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From stephen at sprunk.org Mon Oct 29 12:06:09 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 29 Oct 2007 11:06:09 -0500 Subject: [ppml] IPv4 address and routing slot markets References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> Message-ID: <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> Thus spake "Bill Darte" > Please tell me simply what keeps those who wish to de-aggregate > their available blocks beyond that which ARIN will sanction...from > using the gray or black market to do so. There is a theory that a non-trivial number of ISPs will filter at ARIN's defined prefix lengths, and therefore deaggregation beyond those lengths will be pointless unless one only wants the block(s) for private use -- which none of us should care about. Of course, if ISPs are willing to accept black/gray market /24s in /20 space, they'll get what they've asked for (i.e. routers falling over). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From BillD at cait.wustl.edu Mon Oct 29 12:36:15 2007 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 29 Oct 2007 11:36:15 -0500 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> Message-ID: Thanks Stephen, and yes, I've heard that theory. What makes people 'really' think the theory will win out over $$$ I'd rather be confident that the 'rules' that ARIN establishes will indeed be 'enforced' within the community that really has the power. What other mechanisms to empower ARIN to 'make the policies stick' exist? Bill Darte ARIN Advisory Council -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of Stephen Sprunk Sent: Monday, October 29, 2007 11:06 AM To: Bill Darte Cc: ARIN PPML Subject: Re: [ppml] IPv4 address and routing slot markets Thus spake "Bill Darte" > Please tell me simply what keeps those who wish to de-aggregate > their available blocks beyond that which ARIN will sanction...from > using the gray or black market to do so. There is a theory that a non-trivial number of ISPs will filter at ARIN's defined prefix lengths, and therefore deaggregation beyond those lengths will be pointless unless one only wants the block(s) for private use -- which none of us should care about. Of course, if ISPs are willing to accept black/gray market /24s in /20 space, they'll get what they've asked for (i.e. routers falling over). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues. From sleibrand at internap.com Mon Oct 29 13:08:36 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 29 Oct 2007 10:08:36 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> Message-ID: <47261394.3050106@internap.com> Bill, The only thing that will make that theory true is $$$. Today, the $$$ favors accepting all prefixes. If routing table growth accelerates to the point where the cost of upgrading hardware gets much higher than it is today, then some ISPs will consider filtering, perhaps in the manner I outlined at the start of this thread, because the benefits of doing so would outweigh the costs. If that happens, then organizations wishing to announce deaggregates smaller than the minimum prefix size will need to also announce their covering aggregate to maintain full reachability. I disagree with Stephen's characterization that this would make deaggregates pointless for anything but private use. I still see a role for deaggregates, but would expect (in a world of widespread filtering) that they would only be announced as far as the business relationship extends: to one's upstreams and possibly a few peers. That would preserve the ability to use deaggregates to do inbound TE, while ensuring that only networks wishing to receive the deaggregates need do so. With regards to your grey/black market question, I see no reason that a large IPv4 address holder couldn't split off /24's to third parties. However, unless everyone in the DFZ remains willing to listen to /24 deaggregate announcements, the holder of the larger block will need to continue announcing covering aggregates, and provide some sort of connectivity (perhaps just a tunnel or a shared transit provider) to deliver any packets destined for that aggregate. In that case, the problem reduces down to that of an ISP providing their customer a /24 for multihoming, which is a good way to provide such functionality while preserving the ability of the rest of the world to filter deaggregates if necessary without destroying reachability. -Scott Bill Darte wrote: > Thanks Stephen, and yes, I've heard that theory. What makes people > 'really' think the theory will win out over $$$ > > I'd rather be confident that the 'rules' that ARIN establishes will > indeed be 'enforced' within the community that really has the power. > > What other mechanisms to empower ARIN to 'make the policies stick' > exist? > > Bill Darte > ARIN Advisory Council > > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Stephen Sprunk > Sent: Monday, October 29, 2007 11:06 AM > To: Bill Darte > Cc: ARIN PPML > Subject: Re: [ppml] IPv4 address and routing slot markets > > Thus spake "Bill Darte" > >> Please tell me simply what keeps those who wish to de-aggregate >> their available blocks beyond that which ARIN will sanction...from >> using the gray or black market to do so. >> > > There is a theory that a non-trivial number of ISPs will filter at > ARIN's > defined prefix lengths, and therefore deaggregation beyond those lengths > > will be pointless unless one only wants the block(s) for private use -- > > which none of us should care about. > > Of course, if ISPs are willing to accept black/gray market /24s in /20 > space, they'll get what they've asked for (i.e. routers falling over). > > S > > Stephen Sprunk "God does not play dice." --Albert Einstein > CCIE #3723 "God is an inveterate gambler, and He throws the > K5SSS dice at every possible opportunity." --Stephen Hawking > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From mcr at xdsinc.net Mon Oct 29 13:32:19 2007 From: mcr at xdsinc.net (mcr at xdsinc.net) Date: Mon, 29 Oct 2007 13:32:19 -0400 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> Message-ID: <20071029173051.281921446D0@smtp2.arin.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Stephen" == Stephen Sprunk writes: Stephen> Thus spake "Bill Darte" >> Please tell me simply what keeps those who wish to de-aggregate >> their available blocks beyond that which ARIN will >> sanction...from using the gray or black market to do so. Stephen> There is a theory that a non-trivial number of ISPs will Stephen> filter at ARIN's defined prefix lengths, and therefore Stephen> deaggregation beyond those lengths will be pointless unless Stephen> one only wants the block(s) for private use -- which none Stephen> of us should care about. I've tried that. There are ISPs too stupid to also announce the broader prefix, and there is no ARIN policy or RFC that I can find that tells that they should. How do I discover this? When my customers are told that some people can't reach their site. - -- Michael Richardson XDS Inc, Ottawa, ON Personal: http://www.sandelman.ca/mcr/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iQDVAwUBRyYZIe0sRu40D6vCAQJG1gX/cBgAxAnIOYarRQSTcVsSd10km6+2dFZZ h3niXjeu+23NBfb8Sj72xiASEXh1F4F6si4pt6uesJWFEfK1M5L2OP1cQGCmNF/s fEwHFx1odjXuIRqXga6Xm4Gz82MkI0PQ4yHouYA0qn+lFnz7133x9LLQ4Ojoh5yD BcL1HQv/PfKgvO7mk9o4FuO1WA6aJJgOe0HxeN9NBxbmL227bKw/bRXrpuaxu/dv /n5mBO9ASQSTaiCFCCrR+HiT88x78qPe =iYPg -----END PGP SIGNATURE----- From drc at virtualized.org Mon Oct 29 13:43:28 2007 From: drc at virtualized.org (David Conrad) Date: Mon, 29 Oct 2007 10:43:28 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> Message-ID: <1BD397CA-A63B-4E1C-B124-2E504E6FFE80@virtualized.org> Bill, On Oct 29, 2007, at 9:36 AM, Bill Darte wrote: > Thanks Stephen, and yes, I've heard that theory. What makes people > 'really' think the theory will win out over $$$ Because the $$$ aren't being paid to the folks who are receiving the long prefixes from peers. Why should the peers of the ISP who is receiving the $$$ slit their own throats? Regards, -drc From tedm at ipinc.net Mon Oct 29 14:23:18 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 29 Oct 2007 11:23:18 -0700 Subject: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf In-Reply-To: <472309F1.8010107@apnic.net> Message-ID: >-----Original Message----- >From: Geoff Huston [mailto:gih at apnic.net] >Sent: Saturday, October 27, 2007 2:51 AM >To: Ted Mittelstaedt >Cc: ppml at arin.net >Subject: Re: [ppml] ripe-55/presentations/bush-ipv6-transition.pdf > > >Ted Mittelstaedt wrote: > >> I agree - and furthermore, there IS NO SUCH THING AS AN OPEN MARKET >> >> A truly open market is one in which there was NO recourse to the >> government or courts if someone fails to uphold their end of a >> contract - or anything else - because, after all, in an open market, >> if someone fails to uphold their end, their reputation will cause the >> rest of the players in the market to avoid them, in which case they >> will go out of business. >> > >This assertion confuses the terms "free market" and "open market" > If your beef is with how the original post misused the term "open market" then please take it up with someone else. I know what the original poster was trying to mean by use of that term, as do most people I think. I was responding to his meaning, not making technical nitpicking. >You may find that wikipedia could help you here with a quick primer on >basic terms related to characteristics of markets. > >I'm sure there are many related entries, but you may find >http://en.wikipedia.org/wiki/Free_market helpful here. > Quote from that entry: "...While the free-market is an idealized abstraction, it is useful..." I fail to see what in the entry contradicts my summary - which you snipped of course, since it was the most important part - that the question isn't between an unregulated and a regulated market, but as all markets are regulated, the real question is how much regulation you want. As I said previously, use of terms like "governmental regulated market" opposing "open market", are mere emotional appeals designed to confuse the issue. It's the old battle cry "The commies are coming" simply reframed in year 2007 terms and it is as invalid today as it was then. Ted From tedm at ipinc.net Mon Oct 29 14:34:15 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 29 Oct 2007 11:34:15 -0700 Subject: [ppml] Reducing unnecessary BGP announcements, was: Re: IPv4 address and routing slot markets In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Iljitsch van Beijnum >Sent: Sunday, October 28, 2007 8:26 AM >To: Public Policy Mailing List >Subject: [ppml] Reducing unnecessary BGP announcements,was: Re: IPv4 >address and routing slot markets > > >On 27 okt 2007, at 16:58, Paul Vixie wrote: > >>> What business does ARIN or APNIC or RIPE have in allowing or >>> disallowing >>> any kind of route announcements? It is not in the charter of ARIN >>> or in >>> the terms of reference of RIPE. Is there a significant number of ISPs >>> who are about to sign some kind of routing treaty? > >> that's what tli advised us to do during his ARIN XX preso in ABQ. >> as far >> as i could tell, the ISPs in the room didn't immediately run out >> into the >> hall to discuss details. but that doesn't mean we oughtn't discuss >> it, >> since the predicted backpressure-free market mechanics don't seem >> wonderful. > >Sometimes all it takes is someone with a vision and a route filter. > >How about this: out of the weekly routing table report and the RIR >allocation record, a filter is created that removes unnecessarily >unaggregated prefixes. The filter is sorted in order of decreasing >number of prefixes filtered out. People then install the first X lines >for whatever value of X best suits them. > >This will generate a lot of pressure on the worst offenders to do >better. I don't think so. De facto standards on the Internet tend to be driven by the biggest networks with the deepest pockets. For example, take e-mail SPF records. Until AOL started blocking multiple pieces of mail from mailservers that didn't have an SPF, nobody really paid attention to SPF. Once AOL started doing that, a whole bunch of ISPs out there suddenly put SPF records into their DNS. I don't know but I strongly suspect the worst offenders in any such filter you might construct are going to be precisely the groups that set de facto policy, ie: the biggest networks with the deepest pockets. Ted From tedm at ipinc.net Mon Oct 29 14:55:13 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 29 Oct 2007 11:55:13 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <20071029173051.281921446D0@smtp2.arin.net> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >mcr at xdsinc.net >Sent: Monday, October 29, 2007 10:32 AM >To: Stephen Sprunk >Cc: ARIN PPML; Bill Darte >Subject: Re: [ppml] IPv4 address and routing slot markets > > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >>>>>> "Stephen" == Stephen Sprunk writes: > Stephen> Thus spake "Bill Darte" > >> Please tell me simply what keeps those who wish to de-aggregate > >> their available blocks beyond that which ARIN will > >> sanction...from using the gray or black market to do so. > > Stephen> There is a theory that a non-trivial number of ISPs will > Stephen> filter at ARIN's defined prefix lengths, and therefore > Stephen> deaggregation beyond those lengths will be pointless unless > Stephen> one only wants the block(s) for private use -- which none > Stephen> of us should care about. > > I've tried that. > There are ISPs too stupid to also announce the broader prefix, and >there is no ARIN policy or RFC that I can find that tells that they >should. > How do I discover this? When my customers are told that some people >can't reach their site. > Don't worry about it. Sooner or later one of the Very Large ISP's is going to be in the position of they either pony up the hundreds of millions needed to upgrade all their routers, or filter and cut off a bunch of idiots. They will filter and when their customers say "why can't some people reach my site" they will tell their customers that they can't find anything wrong and maybe those "some people" need to talk to their own administrators. It's been my experience that ignorant customers ALWAYS assume that if there is a problem, that the smaller ISP must be the cause of it based on the assumption that a Very Large ISP like an AOL or MSN or someone like that must obviously know what they are doing simply by virtue that they are Very Large. It's the same logic that "God must be right, because, after all, he is God" (ignorning the story of the rainbow, etc.) In other words, it's a faith issue with these customers, not a logic issue. Ted From stephen at sprunk.org Mon Oct 29 14:40:50 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 29 Oct 2007 13:40:50 -0500 Subject: [ppml] IPv4 address and routing slot markets References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> <47261394.3050106@internap.com> Message-ID: <01b801c81a5d$fa3c84d0$3a3816ac@atlanta.polycom.com> Thus spake "Scott Leibrand" > The only thing that will make that theory true is $$$. Today, the $$$ > favors accepting all prefixes. If routing table growth accelerates to the > point where the cost of upgrading hardware gets much higher > than it is today, then some ISPs will consider filtering, perhaps in > the manner I outlined at the start of this thread, because the benefits > of doing so would outweigh the costs. If that happens, then > organizations wishing to announce deaggregates smaller than the > minimum prefix size will need to also announce their covering > aggregate to maintain full reachability. What if the /24 I bought is in space ARIN has marked as having a minimum allocation of /20? > I disagree with Stephen's characterization that this would make > deaggregates pointless for anything but private use. I still see a > role for deaggregates, but would expect (in a world of widespread > filtering) that they would only be announced as far as the business > relationship extends: to one's upstreams and possibly a few > peers. That would preserve the ability to use deaggregates to > do inbound TE, while ensuring that only networks wishing to > receive the deaggregates need do so. If buyers had to purchase transit from the seller to get useful reachability, it's no longer a sale/transfer of PI address space but rather a SWIP of PA space to a (possibly multihomed) transit customer. That isn't what I thought we were discussing when we talk about a black/gray/white market for addresses, since a mechanism for _renting_ address space already exists. If I'm going to go to the hassle of _buying_ address space, I want it to be completely PI and have full reachability without any requirement for the seller to continue providing me transit service. That is, AIUI, what people are afraid of because it necessitates the buyer getting a slot in the DFZ for each purchased block. Even if we don't allow chopping up /8s into anything longer than a /20, that's still a heck of a lot of routes added to the DFZ vs. today. OTOH, there's only ~900k /20s, and router vendors swear they'll be able to handle that (for a price). Given that's a hard limit if people filter at that boundary, and a lot of big folks (you know, the ones with 80% of the address space) have big blocks they won't deaggregate that far, is the apparent lack of backpressure really a problem? S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Mon Oct 29 15:00:09 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 29 Oct 2007 14:00:09 -0500 Subject: [ppml] Policy Proposal 2007-21: PIv6 for legacy holders with References: <200709010103.l81138Vk008834@cjbsys.bdb.com><4538.66.212.195.12.1192731364.squirrel@ssl.omd3.com> <20071023224557.B9AD3144533@smtp2.arin.net> Message-ID: <01b901c81a5d$fa62aa70$3a3816ac@atlanta.polycom.com> Thus spake >>>>>> "David" == David S Madole writes: > David> As Ted pointed out recently, there is currently a > David> disincentive for legacy holders to implement IPv6 at all > David> versus dragging out IPv4 as long as they can. > > There are no obvious carrots for IPv6, only sticks against IPv4. > > David> One simple way to remove this disincentive would be to offer > David> IPv6 addresses to legacy holders on the same terms as their > David> IPv4 addresses, or maybe not the same but something that > David> removes or lessens the disincentive. > > From what I understand, IPv4 RSA holders already have access to > IPv6 PI space. There is no "IPv4 RSA". Some IPv4 registrations are under an RSA, while others (most legacy ones) are not. Anyone who signs a standard RSA (i.e. not the LRSA) "has access" to IPv6, provided they meet the bar given in the NRPM. According to Leslie's preso at ARIN XX, out of 209 IPv6 requests in the last 12 months, only six were denied (not counting the five that were of the wrong type and corrected), so the bar doesn't appear to be particularly high. > I am curious to know what the distribution of legacy IPv4 > holder are: how many /24s, how many /16s, etc? You can send a request to hostmaster if staff doesn't respond here directly. > I think that the many multitude of /24s, probably don't need more than > a /48, and there are many ways to get that. If you want a PI /48, there's only one way to get it: qualify for a v4 assignment under current policy (which requires 25% utilization of a /22 if multihomed, /20 if not). > Of the /16s and /8 legacy holders, I would think that getting IPv6 > PI space directly would be easy. It's hard to imagine that the bar for PIv6 wouldn't be met by those folks. The only "problem" is the folks that have a legacy /24, which they most likely wouldn't qualify for under current policy. > David> Taking this point a little further, it's largely the legacies > David> that got IPv4 to take off and got the Internet built, they > David> could be the ones to do the same for IPv6 too perhaps if > David> given an incentive rather than a disincentive. > > Doubtful. > Just make IPv6 space as easy to get as IPv4 was back in 1988. We're a bit short on routing slots these days; we can't afford to give a block to everyone who asks, though we're not far off that with a rejection rate <3%. > David> After all, even ARIN, who should be leading the way I would > David> think, isn't even offering whois on IPv6 yet as far as I can > David> tell, even though RIPE has been doing so for almost five > David> years. > > I didn't know there was no whois yet. # host -t any whois.arin.net whois.arin.net has address 192.149.252.44 whois.arin.net has address 199.43.0.144 WHOIS does, of course, contain v6 records; it's just not accessible via v6. That should be fixed. (The same problem doesn't apply to www.arin.net) S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From sleibrand at internap.com Mon Oct 29 15:27:30 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 29 Oct 2007 12:27:30 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <01b801c81a5d$fa3c84d0$3a3816ac@atlanta.polycom.com> References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> <47261394.3050106@internap.com> <01b801c81a5d$fa3c84d0$3a3816ac@atlanta.polycom.com> Message-ID: <47263422.2040109@internap.com> Stephen Sprunk wrote: > Thus spake "Scott Leibrand" >> The only thing that will make that theory true is $$$. Today, the >> $$$ favors accepting all prefixes. If routing table growth >> accelerates to the point where the cost of upgrading hardware gets >> much higher >> than it is today, then some ISPs will consider filtering, perhaps in >> the manner I outlined at the start of this thread, because the benefits >> of doing so would outweigh the costs. If that happens, then >> organizations wishing to announce deaggregates smaller than the >> minimum prefix size will need to also announce their covering >> aggregate to maintain full reachability. > > What if the /24 I bought is in space ARIN has marked as having a > minimum allocation of /20? Then ARIN wouldn't recognize your "purchase". The "seller" could SWIP it to you, of course, but it would still be part of a larger allocation. Any large ISPs who decide to filter more-specifics instead of buy more big iron could potentially filter your more-specific, relying instead on an aggregate announced by the "seller". > >> I disagree with Stephen's characterization that this would make >> deaggregates pointless for anything but private use. I still see a >> role for deaggregates, but would expect (in a world of widespread >> filtering) that they would only be announced as far as the business >> relationship extends: to one's upstreams and possibly a few >> peers. That would preserve the ability to use deaggregates to >> do inbound TE, while ensuring that only networks wishing to >> receive the deaggregates need do so. > > If buyers had to purchase transit from the seller to get useful > reachability, it's no longer a sale/transfer of PI address space but > rather a SWIP of PA space to a (possibly multihomed) transit > customer. That isn't what I thought we were discussing when we talk > about a black/gray/white market for addresses, since a mechanism for > _renting_ address space already exists. In order for a black/gray market to function, it either needs to be possible to con ARIN into transferring the space (i.e. with the sale-of-shell-company game), or some other mechanism of tracking the "sale" needs to be found. In the case of a sale of sub-minimum-size blocks, the easiest such mechanism would be a SWIP. As you pointed out, it then becomes a legitimate rent/lease arrangement (although it could be a long-term lease more like an IRU), with strings attached with regards to reachability. > > If I'm going to go to the hassle of _buying_ address space, I want it > to be completely PI and have full reachability without any requirement > for the seller to continue providing me transit service. That is, > AIUI, what people are afraid of because it necessitates the buyer > getting a slot in the DFZ for each purchased block. Agreed. It would therefore make a lot of sense for small multihomers to buy legacy class C blocks, where the minimum allocation size is already /24. For larger multihomed networks, who would qualify for a /22, they would presumably be able to buy a /22 out of a netblock used for /22 assignments. And, of course, there's always the expedient of simply getting a /24 from your ISP and using that to multihome, if you're not overly concerned with IPv4 provider independence. > > Even if we don't allow chopping up /8s into anything longer than a > /20, that's still a heck of a lot of routes added to the DFZ vs. > today. OTOH, there's only ~900k /20s, and router vendors swear > they'll be able to handle that (for a price). Given that's a hard > limit if people filter at that boundary, and a lot of big folks (you > know, the ones with 80% of the address space) have big blocks they > won't deaggregate that far, is the apparent lack of backpressure > really a problem? That's exactly what I'm trying to elucidate: backpressure of various forms (charing your transit customers for announcement of lots of prefixes, filtering deaggregates, etc.) will emerge if (and only if) there start to be lots of routes added to the DFZ, and it becomes expensive to upgrade routers. What we as a community need to guard against is the sort of irreversible deaggregation that occurs at the top of the hierarchy. Deaggregation lower down (SWIPping PA space) is less of a concern, as it's easily dealt with by these various backpressure mechanisms. -Scott From michael.dillon at bt.com Mon Oct 29 16:04:19 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 29 Oct 2007 20:04:19 -0000 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <20071029173051.281921446D0@smtp2.arin.net> Message-ID: > Don't worry about it. Sooner or later one of the Very Large > ISP's is going to be in the position of they either pony up > the hundreds of millions needed to upgrade all their routers, > or filter and cut off a bunch of idiots. The very largest ISPs do a lot of forward planning and already have IPv6 support in most of their network. They are also all doing various types of testing of IPv6 because they are all getting RFIs and RFPs that ask for IPv6 support. Probably none of the very largest ISPs will be stuck spending millions in capital expenses at the last minute to support an expanded IPv4 routing table because they will all be pushing new customers towards IPv6 network access. --Michael Dillon From sleibrand at internap.com Mon Oct 29 16:15:49 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 29 Oct 2007 13:15:49 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: References: <20071029173051.281921446D0@smtp2.arin.net> Message-ID: <47263F75.30307@internap.com> michael.dillon at bt.com wrote: >> Don't worry about it. Sooner or later one of the Very Large >> ISP's is going to be in the position of they either pony up >> the hundreds of millions needed to upgrade all their routers, >> or filter and cut off a bunch of idiots. >> > > The very largest ISPs do a lot of forward planning and already have IPv6 > support in most of their network. They are also all doing various types > of testing of IPv6 because they are all getting RFIs and RFPs that ask > for IPv6 support. Probably none of the very largest ISPs will be stuck > spending millions in capital expenses at the last minute to support an > expanded IPv4 routing table because they will all be pushing new > customers towards IPv6 network access. > Do you anticipate that the very large ISPs will drop out of the IPv4 DFZ any time soon? That seems unlikely to me. While large ISPs do appear to be getting positioned to provide IPv6 connectivity to customers, I think they'll still need to support the IPv4 routing table as well for quite awhile yet. If they're putting all their new customers on v6, but others are expanding their v4 route announcements, that seems like a really good set of incentives to "filter and cut off a bunch of idiots" to me... -Scott From info at arin.net Mon Oct 29 16:47:05 2007 From: info at arin.net (Member Services) Date: Mon, 29 Oct 2007 16:47:05 -0400 Subject: [ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 Message-ID: <472646C9.3000207@arin.net> ARIN received the following policy proposal. In accordance with the ARIN Internet Resource Policy Evaluation Process, the proposal is being posted to the ARIN Public Policy Mailing List (PPML) and being placed on ARIN's website. The ARIN Advisory Council (AC) will review this proposal at their next regularly scheduled meeting. The AC may decide to: 1. Accept the proposal as a formal policy proposal as written. If the AC accepts the proposal, it will be posted as a formal policy proposal to PPML and it will be presented at a Public Policy Meeting. 2. Postpone their decision regarding the proposal until the next regularly scheduled AC meeting in order to work with the author. The AC will work with the author to clarify, combine or divide the proposal. At their following meeting the AC will accept or not accept the proposal. 3. Not accept the proposal. If the AC does not accept the proposal, the AC will explain their decision. If a proposal is not accepted, then the author may elect to use the petition process to advance their proposal. If the author elects not to petition or the petition fails, then the proposal will be closed. The AC will assign shepherds in the near future. ARIN will provide the names of the shepherds to the community via the PPML. In the meantime, the AC invites everyone to comment on this proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. The ARIN Internet Resource Policy Evaluation Process can be found at: http://www.arin.net/policy/irpep.html Mailing list subscription information can be found at: http://www.arin.net/mailing_lists/ Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: globally-coordinated-RIR-pie-IPv4 Author: Brian Dickson Proposal Version: 1 Submission Date: 26 October 2007 Proposal type: new Policy term: renewable Policy statement: This policy concerns the globally-coordinated allocations of IPv4 address space from IANA to the RIRs. The policy is intended to be compatible with 2007-23 (in its expected final form). The overview of the policy is: At the last reasonable time to do so, divide up the remaining IPv4 space based on currently projected use between that time and the date at which no more IPv4 space is available at any RIR for new allocations. Here is how the policy is to be implemented: 1) RIRs should provide up-to-date assignment projections for their respective regions, and provide up-to-date utilization on their current IANA-assigned block(s) from which assignments are made. 2) RIRs should provide an official projection on IANA Exhaustion Date (IED) to the community through their website, at their Policy Meetings and through any other effective means. 3) When any RIR requests a /8 from IANA, the current assignment projections for that RIR should be combined with the RIR's currently available IANA blocks (i.e. from which RIR assignments are made). This should be compared with the global available IANA unused space (for allocating to RIRs), the current projected usage rate of the RIR, and the current projected IED. If the RIR projection shows that the RIR would not expect to use up two /8 blocks before IED, the "Pie-splitting" event will be triggered. 4) Splitting the Pie - the following method will be used to determine the final IPv4 global IANA allocations to the RIRs: For each RIR, the following calculation will be done: (i) Determine from the current projection, the total allocations the RIR will make from present to IED (ii) Subtract from this, unallocated RIR space already received from ARIN (if any) (iii) Round the result to the nearest /12 (iv) Subtract from this amount, one /8 (to be set aside to satisfy the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to RIRs") (v) Allocate this amount to the RIR immediately. Every effort should be made to divide these allocations among RIRs in as aggregatable a fashion as possible. 5) The allocations made will result in just 5 * /8 being left in the IANA pool, which will trigger 2007-23. 6) This in turn, will result in the last 5 * /8's being allocate to the RIR's, one for each. Rationale: The objective of this policy is to ensure that the remaining IPv4 pool is distributed so as to provide each RIR with a quantity of IPv4 addresses that will last for an expected duration. The intent is for this duration to be as close to the same for each RIR as possible. By following the rules above, the "pie split" is done: - as late as possible - as fairly as possible - in a consistent manner for all RIRs - early enough that each RIR is guaranteed at least one /8 The final /8 allocations are done *after* this allocation, so that there can be no issue of fairness, with each RIR being guaranteed to get one of the final /8's at the same time. The "pie split" is timed so that no RIR will have so much (relative) IPv4 address space, as to expect to have IPv4 space after any other RIR has exhausted its own IPv4 space. By providing a "pie split" which is based on the same data as the IED projection, the following results occur: - there is no contention over the process by which the division of resources occur - all RIRs have the ability to project, well in advance of the "pie split", exactly when their own IPv4 space will be exhausted. It will happen at the IED date -- no sooner, no later. - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land grab" is likely to occur, and thus the projections for IED itself are likely to remain consistent, as will the per-RIR projections. - LIRs are likely to view the policy as neutral, and thus fair. - Because it removes the incentive for RIR shopping, the rules preventing RIR shopping will become largely moot (but still recommended). The perception then of anti-shopping provisions might then be that it maintains stability, rather than penalizing any RIR/LIR/region. Additional Observations about Fast vs Slow RIRs Fast-consuming RIRs will contribute more heavily towards the consumption rate. In turn, these RIRs will be the largest component of the projections of IED. Low-consuming RIRs will have less impact on IED. However, the low rate means that these RIRs will have *greater* proportional accuracy when it comes to knowing how much space they need between present time and IED. (This is because, the uncertainty on allocation needs, will be the result of multiplying the uncertainty on IED date, by the rate of consumption. Low-consuming LIRs, will have less uncertainty on their penultimate allocation.) The uncertainty on exact date of IED, is expected to be largely invariant across RIRs. Any changes to individual RIR allocation trends, after the "pie split" date, are not expected to exceed the individual RIR's own uncertainty at "pie split" date. In other words, the accuracy of each RIR's IED is expected to increase over time, and to continue to fall within the range of the original upper and lower limits (based on rounding to /12) of the RIR's allocation from IANA. Timetable for implementation: immediate From tedm at ipinc.net Mon Oct 29 17:49:06 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 29 Oct 2007 14:49:06 -0700 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <47263F75.30307@internap.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Scott Leibrand >Sent: Monday, October 29, 2007 1:16 PM >To: michael.dillon at bt.com >Cc: ppml at arin.net >Subject: Re: [ppml] IPv4 address and routing slot markets > > >michael.dillon at bt.com wrote: >>> Don't worry about it. Sooner or later one of the Very Large >>> ISP's is going to be in the position of they either pony up >>> the hundreds of millions needed to upgrade all their routers, >>> or filter and cut off a bunch of idiots. >>> >> >> The very largest ISPs do a lot of forward planning and already have IPv6 >> support in most of their network. They are also all doing various types >> of testing of IPv6 because they are all getting RFIs and RFPs that ask >> for IPv6 support. Probably none of the very largest ISPs will be stuck >> spending millions in capital expenses at the last minute to support an >> expanded IPv4 routing table because they will all be pushing new >> customers towards IPv6 network access. >> > >Do you anticipate that the very large ISPs will drop out of the IPv4 DFZ >any time soon? That seems unlikely to me. While large ISPs do appear >to be getting positioned to provide IPv6 connectivity to customers, I >think they'll still need to support the IPv4 routing table as well for >quite awhile yet. If they're putting all their new customers on v6, but >others are expanding their v4 route announcements, that seems like a >really good set of incentives to "filter and cut off a bunch of idiots" >to me... It's either that or launch: www.free-porn.com and www.free-piratedmovies.com as IPv6 only websites. Ted From sleibrand at internap.com Mon Oct 29 18:07:37 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 29 Oct 2007 15:07:37 -0700 Subject: [ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 In-Reply-To: <472646C9.3000207@arin.net> References: <472646C9.3000207@arin.net> Message-ID: <472659A9.7020807@internap.com> Brian, A few comments: * I think this has to be a true global policy (passed in identical forms in all 5 RIRs), because it directs IANA action. If I understand the policy process correctly, that's different from a "globally coordinated" policy. * I'm not sure of the necessity for this level of optimization in the final IANA allocations. * Your mechanism for triggering the pie-splitting event seems to assume that every request will be for two /8s. Your proposal states that "If the RIR projection shows that the RIR would not expect to use up _two /8 blocks_ before IED, the "Pie-splitting" event will be triggered." You might want to rephrase "two /8 blocks" to something like "the requested allocation". That way, if a slow-consuming RIR only requests one /8 (because they can't use up two before IED), then we don't prematurely trigger pie-splitting. Please let me know if I'm misunderstanding your intent or the imlications of the "two /8 blocks" clause. -Scott Member Services wrote: > ARIN received the following policy proposal. In accordance with the ARIN > Internet Resource Policy Evaluation Process, the proposal is being > posted to the ARIN Public Policy Mailing List (PPML) and being placed on > ARIN's website. > > The ARIN Advisory Council (AC) will review this proposal at their next > regularly scheduled meeting. The AC may decide to: > > 1. Accept the proposal as a formal policy proposal as written. If the > AC accepts the proposal, it will be posted as a formal policy proposal > to PPML and it will be presented at a Public Policy Meeting. > > 2. Postpone their decision regarding the proposal until the next > regularly scheduled AC meeting in order to work with the author. The AC > will work with the author to clarify, combine or divide the proposal. At > their following meeting the AC will accept or not accept the proposal. > > 3. Not accept the proposal. If the AC does not accept the proposal, > the AC will explain their decision. If a proposal is not accepted, then > the author may elect to use the petition process to advance their > proposal. If the author elects not to petition or the petition fails, > then the proposal will be closed. > > The AC will assign shepherds in the near future. ARIN will provide the > names of the shepherds to the community via the PPML. > > In the meantime, the AC invites everyone to comment on this proposal on > the PPML, particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > The ARIN Internet Resource Policy Evaluation Process can be found at: > http://www.arin.net/policy/irpep.html > > Mailing list subscription information can be found at: > http://www.arin.net/mailing_lists/ > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Policy Proposal Name: globally-coordinated-RIR-pie-IPv4 > > Author: Brian Dickson > > Proposal Version: 1 > > Submission Date: 26 October 2007 > > Proposal type: new > > Policy term: renewable > > Policy statement: > > This policy concerns the globally-coordinated allocations of IPv4 > address space from IANA to the RIRs. > > The policy is intended to be compatible with 2007-23 (in its expected > final form). > > The overview of the policy is: > At the last reasonable time to do so, divide up the remaining IPv4 space > based on currently projected use between that time and the date at which > no more IPv4 space is available at any RIR for new allocations. > > Here is how the policy is to be implemented: > > 1) RIRs should provide up-to-date assignment projections for their > respective regions, and provide up-to-date utilization on their current > IANA-assigned block(s) from which assignments are made. > > 2) RIRs should provide an official projection on IANA Exhaustion Date > (IED) to the community through their website, at their Policy Meetings > and through any other effective means. > > 3) When any RIR requests a /8 from IANA, the current assignment > projections for that RIR should be combined with the RIR's currently > available IANA blocks (i.e. from which RIR assignments are made). This > should be compared with the global available IANA unused space (for > allocating to RIRs), the current projected usage rate of the RIR, and > the current projected IED. > > If the RIR projection shows that the RIR would not expect to use up two > /8 blocks before IED, the "Pie-splitting" event will be triggered. > > 4) Splitting the Pie - the following method will be used to determine > the final IPv4 global IANA allocations to the RIRs: > For each RIR, the following calculation will be done: > (i) Determine from the current projection, the total allocations > the RIR will make from present to IED > (ii) Subtract from this, unallocated RIR space already received > from ARIN (if any) > (iii) Round the result to the nearest /12 > (iv) Subtract from this amount, one /8 (to be set aside to satisfy > the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to > RIRs") > (v) Allocate this amount to the RIR immediately. Every effort > should be made to divide these allocations among RIRs in as aggregatable > a fashion as possible. > > 5) The allocations made will result in just 5 * /8 being left in the > IANA pool, which will trigger 2007-23. > > 6) This in turn, will result in the last 5 * /8's being allocate to the > RIR's, one for each. > > > Rationale: > > The objective of this policy is to ensure that the remaining IPv4 pool > is distributed so as to provide each RIR with a quantity of IPv4 > addresses that will last for an expected duration. > > The intent is for this duration to be as close to the same for each RIR > as possible. > > By following the rules above, the "pie split" is done: > - as late as possible > - as fairly as possible > - in a consistent manner for all RIRs > - early enough that each RIR is guaranteed at least one /8 > > The final /8 allocations are done *after* this allocation, so that there > can be no issue of fairness, with each RIR being guaranteed to get one > of the final /8's at the same time. > > The "pie split" is timed so that no RIR will have so much (relative) > IPv4 address space, as to expect to have IPv4 space after any other RIR > has exhausted its own IPv4 space. > > By providing a "pie split" which is based on the same data as the IED > projection, the following results occur: > - there is no contention over the process by which the division of > resources occur > - all RIRs have the ability to project, well in advance of the "pie > split", exactly when their own IPv4 space will be exhausted. It will > happen at the IED date -- no sooner, no later. > - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land > grab" is likely to occur, and thus the projections for IED itself are > likely to remain consistent, as will the per-RIR projections. > - LIRs are likely to view the policy as neutral, and thus fair. > - Because it removes the incentive for RIR shopping, the rules > preventing RIR shopping will become largely moot (but still > recommended). The perception then of anti-shopping provisions might then > be that it maintains stability, rather than penalizing any > RIR/LIR/region. > > Additional Observations about Fast vs Slow RIRs > > Fast-consuming RIRs will contribute more heavily towards the consumption > rate. In turn, these RIRs will be the largest component of the > projections of IED. > > Low-consuming RIRs will have less impact on IED. However, the low rate > means that these RIRs will have *greater* proportional accuracy when it > comes to knowing how much space they need between present time and IED. > (This is because, the uncertainty on allocation needs, will be the > result of multiplying the uncertainty on IED date, by the rate of > consumption. Low-consuming LIRs, will have less uncertainty on their > penultimate allocation.) > > The uncertainty on exact date of IED, is expected to be largely > invariant across RIRs. > > Any changes to individual RIR allocation trends, after the "pie split" > date, are not expected to exceed the individual RIR's own uncertainty at > "pie split" date. In other words, the accuracy of each RIR's IED is > expected to increase over time, and to continue to fall within the range > of the original upper and lower limits (based on rounding to /12) of the > RIR's allocation from IANA. > > Timetable for implementation: immediate > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From briand at ca.afilias.info Mon Oct 29 18:26:17 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Mon, 29 Oct 2007 18:26:17 -0400 Subject: [ppml] Policy Proposal: globally-coordinated-RIR-pie-IPv4 In-Reply-To: <472659A9.7020807@internap.com> References: <472646C9.3000207@arin.net> <472659A9.7020807@internap.com> Message-ID: <47265E09.9080400@ca.afilias.info> Scott Leibrand wrote: > Brian, > > A few comments: > > * I think this has to be a true global policy (passed in identical > forms in all 5 RIRs), because it directs IANA action. If I > understand the policy process correctly, that's different from a > "globally coordinated" policy. You may be right there. I am a bit unsure of which it needs to be, and/or how an IANA policy would get proposed/approved. I think if the 5 RIRs agree to the policy, they can just ask IANA to implement it. > * I'm not sure of the necessity for this level of optimization in > the final IANA allocations. It removes "blind chance" from the final allocations. There may be a presumption that the last allocations will give the slowest-using RIRs the most time, but there could be disparity among the two or three slowest that was neither intended nor forseen. If the two slowest get one block each, but one of them had *just* received its previous block, and the other was *just* about to exhaust its previous block, this would both appear to be unfair, and actually *be* unfair. The proposed policy also balances the needs of the fast-using RIRs, mostly preventing fast-RIR customers from RIR-shopping. RIR shopping would cause, IMHO, lots of problems, including an even greater problem of proliferation of difficult-to-trace ownership of IP blocks used for nefarious purposes (e.g. spam). The good that comes out of the policy is an expected side-effect, but mostly it's about predictability and fairness. If everyone expects their personal IED day to be the same as global IED day, there should be no surprises. It reduces the IED to a Y2K-like event. > * Your mechanism for triggering the pie-splitting event seems to > assume that every request will be for two /8s. Your proposal > states that "If the RIR projection shows that the RIR would not > expect to use up _two /8 blocks_ before IED, the "Pie-splitting" > event will be triggered." You might want to rephrase "two /8 > blocks" to something like "the requested allocation". That way, > if a slow-consuming RIR only requests one /8 (because they can't > use up two before IED), then we don't prematurely trigger > pie-splitting. Please let me know if I'm misunderstanding your > intent or the imlications of the "two /8 blocks" clause. > Ah, the magic "two". It's only "two" because of the need to hold back one from the final allocation. If you subtract the withheld one from the two, it becomes "one". It's basically an attempt to word things without double-negatives and without double-entry accounting. What it really means is: - IANA holds back one /8 per RIR - If the next /8 IANA gives to an RIR, *plus* the held-back /8, would last beyond IED, it's time to divide up the pie. BTW - the most likely scenario is that one of the two *slowest* RIRs will trigger the pie event, specifically because each of their /8's lasts longer. (And no, there is no presumption on multiple /8's per allocation. If anything, it's the reverse.) Thanks for your comments. Brian > -Scott > > Member Services wrote: >> ARIN received the following policy proposal. In accordance with the ARIN >> Internet Resource Policy Evaluation Process, the proposal is being >> posted to the ARIN Public Policy Mailing List (PPML) and being placed on >> ARIN's website. >> >> The ARIN Advisory Council (AC) will review this proposal at their next >> regularly scheduled meeting. The AC may decide to: >> >> 1. Accept the proposal as a formal policy proposal as written. If >> the >> AC accepts the proposal, it will be posted as a formal policy proposal >> to PPML and it will be presented at a Public Policy Meeting. >> >> 2. Postpone their decision regarding the proposal until the next >> regularly scheduled AC meeting in order to work with the author. The AC >> will work with the author to clarify, combine or divide the proposal. At >> their following meeting the AC will accept or not accept the proposal. >> >> 3. Not accept the proposal. If the AC does not accept the proposal, >> the AC will explain their decision. If a proposal is not accepted, then >> the author may elect to use the petition process to advance their >> proposal. If the author elects not to petition or the petition fails, >> then the proposal will be closed. >> >> The AC will assign shepherds in the near future. ARIN will provide the >> names of the shepherds to the community via the PPML. >> >> In the meantime, the AC invites everyone to comment on this proposal on >> the PPML, particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their >> deliberations. >> >> The ARIN Internet Resource Policy Evaluation Process can be found at: >> http://www.arin.net/policy/irpep.html >> >> Mailing list subscription information can be found at: >> http://www.arin.net/mailing_lists/ >> >> Regards, >> >> Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Policy Proposal Name: globally-coordinated-RIR-pie-IPv4 >> >> Author: Brian Dickson >> >> Proposal Version: 1 >> >> Submission Date: 26 October 2007 >> >> Proposal type: new >> >> Policy term: renewable >> >> Policy statement: >> >> This policy concerns the globally-coordinated allocations of IPv4 >> address space from IANA to the RIRs. >> >> The policy is intended to be compatible with 2007-23 (in its expected >> final form). >> >> The overview of the policy is: >> At the last reasonable time to do so, divide up the remaining IPv4 space >> based on currently projected use between that time and the date at which >> no more IPv4 space is available at any RIR for new allocations. >> >> Here is how the policy is to be implemented: >> >> 1) RIRs should provide up-to-date assignment projections for their >> respective regions, and provide up-to-date utilization on their current >> IANA-assigned block(s) from which assignments are made. >> >> 2) RIRs should provide an official projection on IANA Exhaustion Date >> (IED) to the community through their website, at their Policy Meetings >> and through any other effective means. >> >> 3) When any RIR requests a /8 from IANA, the current assignment >> projections for that RIR should be combined with the RIR's currently >> available IANA blocks (i.e. from which RIR assignments are made). This >> should be compared with the global available IANA unused space (for >> allocating to RIRs), the current projected usage rate of the RIR, and >> the current projected IED. >> >> If the RIR projection shows that the RIR would not expect to use up two >> /8 blocks before IED, the "Pie-splitting" event will be triggered. >> >> 4) Splitting the Pie - the following method will be used to determine >> the final IPv4 global IANA allocations to the RIRs: >> For each RIR, the following calculation will be done: >> (i) Determine from the current projection, the total allocations >> the RIR will make from present to IED >> (ii) Subtract from this, unallocated RIR space already received >> from ARIN (if any) >> (iii) Round the result to the nearest /12 >> (iv) Subtract from this amount, one /8 (to be set aside to satisfy >> the 2005-23 policy proposal for "End Policy for IANA IPv4 allocations to >> RIRs") >> (v) Allocate this amount to the RIR immediately. Every effort >> should be made to divide these allocations among RIRs in as aggregatable >> a fashion as possible. >> >> 5) The allocations made will result in just 5 * /8 being left in the >> IANA pool, which will trigger 2007-23. >> >> 6) This in turn, will result in the last 5 * /8's being allocate to the >> RIR's, one for each. >> >> >> Rationale: >> >> The objective of this policy is to ensure that the remaining IPv4 pool >> is distributed so as to provide each RIR with a quantity of IPv4 >> addresses that will last for an expected duration. >> >> The intent is for this duration to be as close to the same for each RIR >> as possible. >> >> By following the rules above, the "pie split" is done: >> - as late as possible >> - as fairly as possible >> - in a consistent manner for all RIRs >> - early enough that each RIR is guaranteed at least one /8 >> >> The final /8 allocations are done *after* this allocation, so that there >> can be no issue of fairness, with each RIR being guaranteed to get one >> of the final /8's at the same time. >> >> The "pie split" is timed so that no RIR will have so much (relative) >> IPv4 address space, as to expect to have IPv4 space after any other RIR >> has exhausted its own IPv4 space. >> >> By providing a "pie split" which is based on the same data as the IED >> projection, the following results occur: >> - there is no contention over the process by which the division of >> resources occur >> - all RIRs have the ability to project, well in advance of the "pie >> split", exactly when their own IPv4 space will be exhausted. It will >> happen at the IED date -- no sooner, no later. >> - No RIR "shopping" is likely to occur. Consequently, no inter-RIR "land >> grab" is likely to occur, and thus the projections for IED itself are >> likely to remain consistent, as will the per-RIR projections. >> - LIRs are likely to view the policy as neutral, and thus fair. >> - Because it removes the incentive for RIR shopping, the rules >> preventing RIR shopping will become largely moot (but still >> recommended). The perception then of anti-shopping provisions might then >> be that it maintains stability, rather than penalizing any >> RIR/LIR/region. >> >> Additional Observations about Fast vs Slow RIRs >> >> Fast-consuming RIRs will contribute more heavily towards the consumption >> rate. In turn, these RIRs will be the largest component of the >> projections of IED. >> >> Low-consuming RIRs will have less impact on IED. However, the low rate >> means that these RIRs will have *greater* proportional accuracy when it >> comes to knowing how much space they need between present time and IED. >> (This is because, the uncertainty on allocation needs, will be the >> result of multiplying the uncertainty on IED date, by the rate of >> consumption. Low-consuming LIRs, will have less uncertainty on their >> penultimate allocation.) >> >> The uncertainty on exact date of IED, is expected to be largely >> invariant across RIRs. >> >> Any changes to individual RIR allocation trends, after the "pie split" >> date, are not expected to exceed the individual RIR's own uncertainty at >> "pie split" date. In other words, the accuracy of each RIR's IED is >> expected to increase over time, and to continue to fall within the range >> of the original upper and lower limits (based on rounding to /12) of the >> RIR's allocation from IANA. >> >> Timetable for implementation: immediate >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy >> Mailing List (PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN >> Member Services >> Help Desk at info at arin.net if you experience any issues. >> From stephen at sprunk.org Mon Oct 29 19:12:32 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 29 Oct 2007 18:12:32 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm References: <70DE64CEFD6E9A4EB7FAF3A0631410667076CE@mail><20071022193730.GA15529@vacation.karoshi.com.> <3062.64.39.177.10.1193092519.squirrel@webmail.ibctech.ca> <041101c8167e$160d2630$9902fea9@atlanta.polycom.com> <4720922B.3030106@eagle.ca> Message-ID: <024901c81a84$887e6850$3a3816ac@atlanta.polycom.com> Thus spake "Steve Bertrand" >> Right. One of the goals in IPv6 policy is minimizing routes in the >> DFZ, and it's easiest to do that if everyone (or nearly everyone) >> has the same size blocks because it's easy to filter deaggregates >> that way. While a /32 is way, way too large for most LIRs, it's >> large enough that nearly all LIRs will fit in it, it's a convenient >> number, and everyone can filter anything longer than /32 (except >> in the PIv6 block, where it's /48) with impunity unless they >> specifically want deaggregates. Since we have absolutely no >> clue how to route the half a billion /32s in 2000::/3, there is no >> reason to give out longer prefixes -- and plenty of reasons not to. > > I completely understand the importance of the allocation of blocks > with as short a prefix and as consistent as possible, but thanks for > the clarification. "As short as possible" wasn't a consideration, AFAIK. We certainly don't want any risk of running out of them, which is what happens when you get stingy with the size of a protocol field. > Out of curiosity, who was the original classification of size (/32 > and /48) distribution designed by? That came from the IETF, though it's fairly obvious where they got it from: multiples of 16 bits are much preferred by humans given how v6 addresses are written, and powers of two (and small multiples thereof) are preferred by computers given register sizes -- the same sorts of reasons that led to 8-bit boundaries in v4. Once EUI-64 was decided upon, I can't see how we'd have divided 128 total bits any other way than was done. If they'd gone with EUI-48, it'd probably look slightly different, but not too much. > Was it the community as all other ARIN policies are created by? One can debate how much the IETF resembles "the community", but the RIRs have a long history of following the IETF's recommendations, with a few notable exceptions. Also, a number of folks from the RIR world are involved in the IETF world as well, which keeps the two reasonably in sync most of the time. > Also, I don't pay attention to what other RIR's are doing, is this > allocation scheme the same across all RIR's? Initially, all the RIRs started out with a uniform policy set. Subsequently, each has monkeyed with policies in different ways so they're no longer identical -- just as happened with IPv4. ARIN's major v6 policy changes to date are the addition of PI /48s and PA /56s and the removal of non-policy text (the latter mainly due to our different policy format). S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From stephen at sprunk.org Mon Oct 29 19:44:07 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Mon, 29 Oct 2007 18:44:07 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm References: Message-ID: <025001c81a88$d722b6b0$3a3816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" >>> Although we (the small SP's) have signed a v6 RSA, are we >>> going to get the same ridicule and harassment in the future that >>> the Legacy IPv4 folk are seeing today? >> >>The "ridicule and harassment" is coming from a very small group >>of unfortunately vocal people. The rest of us are trying to be polite >>and merely ask that legacy folks give back what they don't need >>(even using very liberal definitions of "need"). > > The devil is in the definition of need. > > I have 10 point to point T1s. I need 10 IPv4 /24s since I assign a > /24 to each circuit. That is the problem, you see. I have no pity for people doing that; RIPv2 has been out for a long, long time, and RIPv1 was the last reasonable excuse for doing things that way. There are few reasons, other than the intentional waste (or hoarding) of addresses, to assign more than a /30 to a PTP link. Unfortunately, many vendors are still clueless about /31s, or I'd revise that statement even further. > "Need" is elastic. If someone is fighting for every /24 they can > get, they might even be using unnumbered, grudging even 4 IP > addresses for their point to point links. There are legitimate technical reasons for not using unnumbered. > I just did a support call this morning with a customer who has a > site down in SBCGlobal territory. They needed a static IP on a > DSL line. They were assigned a /29. ... It's incredibly wasteful. Perhaps there are technical reasons you're not privvy to; perhaps it's waste or hoarding. Either way, it's close enough for us to not quibble over here -- though presumably ARIN staff would require a justification for such when their next request comes in. If you want to talk about waste, look at the folks with a /8 (or two) who could likely fit into a handful of /16s, or the folks with dozens of /16s who only use a single /24 outside of 10/8. >>If we did a straw poll of folks favoring carrots vs. sticks, I'm quite >>sure the former would outnumber the latter by an overwhelming >>margin. > > In a perfect world, yes. But when you actually start LOOKING at > what the hell is HAPPENING out in the real world you will turn up > PLENTY of stories like the one I just cited, and I think you will be > getting the sticks out and tossing the carrots a lot faster than > you think. I've seen plenty of horrifying examples, though NDAs prevent me from naming names. However, I know better than to think that all, or even the majority of, legacy holders deserved to be tarred with that brush; many have been quite willing to voluntarily return space they don't need. So far, just asking politely has netted ARIN quite a number of returned blocks -- and threats have, so far, netted the community nothing but a bunch of animosity and/or fear. I'm in favor of what gets us the most productive results for the least effort. Making enemies of people we want something from is not helpful on either front. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From sethm at rollernet.us Mon Oct 29 21:29:41 2007 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 29 Oct 2007 18:29:41 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <025001c81a88$d722b6b0$3a3816ac@atlanta.polycom.com> References: <025001c81a88$d722b6b0$3a3816ac@atlanta.polycom.com> Message-ID: <47268905.1000102@rollernet.us> Stephen Sprunk wrote: > Thus spake "Ted Mittelstaedt" >> >> I just did a support call this morning with a customer who has a >> site down in SBCGlobal territory. They needed a static IP on a >> DSL line. They were assigned a /29. ... It's incredibly wasteful. > > Perhaps there are technical reasons you're not privvy to; perhaps it's waste > or hoarding. Either way, it's close enough for us to not quibble over > here -- though presumably ARIN staff would require a justification for such > when their next request comes in. > I'm betting on "we're AT&T, they wouldn't dare deny us anything we want." Does anyone know how solid ARIN's authority is if they tried to deny AT&T a request for more space, or would their lawyers run ARIN into the ground? ~Seth From bonomi at mail.r-bonomi.com Mon Oct 29 22:00:50 2007 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 29 Oct 2007 20:00:50 -0600 (CST) Subject: [ppml] IPv4 address and routing slot markets Message-ID: <200710300200.l9U20oU2006279@mail.r-bonomi.com> > From: "Stephen Sprunk" > Date: Mon, 29 Oct 2007 13:40:50 -0500 > Subject: Re: [ppml] IPv4 address and routing slot markets > > If buyers had to purchase transit from the seller to get useful > reachability, it's no longer a sale/transfer of PI address space but rather > a SWIP of PA space to a (possibly multihomed) transit customer. That isn't > what I thought we were discussing when we talk about a black/gray/white > market for addresses, since a mechanism for _renting_ address space already > exists. > > If I'm going to go to the hassle of _buying_ address space, I want it to be > completely PI and have full reachability without any requirement for the > seller to continue providing me transit service. That is, AIUI, what people > are afraid of because it necessitates the buyer getting a slot in the DFZ > for each purchased block. If that is what you _think_ you're buying you better have in the contract with the seller that that *is* what they're selling. _Somebody_ has to pay for those resources, and unless you have a _contratual_ commitment for someone to provide them to you, you are *NOT* assured of having them. Even in today's world, -with- an adress-block acquuired directly from an RIR, you're _still_ not 'guarantee' a DFZ routing 'slot'. What is the liklihood that contracts for connectivity/transit/peering will start to place limits on the number of prefixes that can be announced/serviced? That will *really* drive aggregation. Including attempts to 'trade' multiple non-contguous blocks for a single contiguous one of 'equivalent' size. This could involve some, large-scale, 'painful' renumbering, but does have potential to significantly reduce DFZ table size. From sleibrand at internap.com Mon Oct 29 23:17:20 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Mon, 29 Oct 2007 20:17:20 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <47268905.1000102@rollernet.us> References: <025001c81a88$d722b6b0$3a3816ac@atlanta.polycom.com> <47268905.1000102@rollernet.us> Message-ID: <4726A240.3040205@internap.com> Seth Mattinen wrote: > I'm betting on "we're AT&T, they wouldn't dare deny us anything we > want." Does anyone know how solid ARIN's authority is if they tried to > deny AT&T a request for more space, or would their lawyers run ARIN into > the ground? I think ARIN would have the upper hand there. The IP administrator for another mega-telco was telling me at ABQ how her director was wanting to escalate an IP request and simply "call up ARIN's CEO". The IP admin had to explain to the director that their relationship with ARIN didn't work that way like it does with normal commercial vendors, and if he tried it it would only make their life harder by ensuring that ARIN followed their policy and procedure to the letter. I suspect the same is the experience of most people working with ARIN: if you are reasonable and cooperate with their justification requests, they'll be reasonable in return, and not ask for details on every last netblock. But if you start to get belligerent or litigious, there's *a lot* more justification they could reasonably request, without even coming close to what a judge might consider excessive. -Scott From iljitsch at muada.com Mon Oct 29 17:37:14 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Mon, 29 Oct 2007 22:37:14 +0100 Subject: [ppml] Reducing unnecessary BGP announcements, was: Re: IPv4 address and routing slot markets In-Reply-To: References: Message-ID: <67868F4D-9E0D-406A-A220-F23B65B6F224@muada.com> On 29 okt 2007, at 19:34, Ted Mittelstaedt wrote: >> This will generate a lot of pressure on the worst offenders to do >> better. > I don't think so. De facto standards on the Internet tend to be > driven by > the biggest networks with the deepest pockets. Well, if this is going to be the small guys against the big ones I wouldn't want to be in the shoes of the small guys. But it hurts the big ones too, so I don't see any reason except inertia that at least a few of them wouldn't want to get on board with something like this, unless they like the idea of an upgrade cycle and think they can afford more expensive routers that their competitors. > For example, take e-mail > SPF records. Until AOL started blocking multiple pieces of mail from > mailservers that didn't have an SPF, nobody really paid attention to > SPF. > Once AOL started doing that, a whole bunch of ISPs out there suddenly > put SPF records into their DNS. There are many differences. With SPF records you can't easily see how many people use them. Also, SPF was something new, not the failure to do something that everyone thinks is reasonable in the first place. And apparently it worked once AOL got on board. :-) From michael.dillon at bt.com Tue Oct 30 04:30:29 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 30 Oct 2007 08:30:29 -0000 Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <47263F75.30307@internap.com> References: <20071029173051.281921446D0@smtp2.arin.net> <47263F75.30307@internap.com> Message-ID: > Do you anticipate that the very large ISPs will drop out of > the IPv4 DFZ any time soon? The very large ISPs will be the last to drop out of the IPv4 DFZ sometime in about 20 years. What does this have to do with IPv6? Nobody is shutting off existing IPv4 infrastructure until long after IPv6 has become widespread. > If they're putting all their new customers on > v6, but others are expanding their v4 route announcements, > that seems like a really good set of incentives to "filter > and cut off a bunch of idiots" > to me... Yes, I agree. Since the largest ISPs are all preparing their own IPv6 Internet access services they are not likely to support people who try to stretch out IPv4-only networks by adding lots of long prefixes to the DFZ. --Michael Dillon From jlewis at lewis.org Tue Oct 30 09:44:32 2007 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 30 Oct 2007 09:44:32 -0400 (EDT) Subject: [ppml] IPv4 address and routing slot markets In-Reply-To: <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> References: <47218DD0.4000802@psg.com> <47227261.6000206@internap.com><47237254.7050306@kl.net> <017001c81a48$90b3f760$3a3816ac@atlanta.polycom.com> Message-ID: On Mon, 29 Oct 2007, Stephen Sprunk wrote: > Thus spake "Bill Darte" >> Please tell me simply what keeps those who wish to de-aggregate >> their available blocks beyond that which ARIN will sanction...from >> using the gray or black market to do so. > > There is a theory that a non-trivial number of ISPs will filter at ARIN's > defined prefix lengths, and therefore deaggregation beyond those lengths > will be pointless unless one only wants the block(s) for private use -- > which none of us should care about. The trouble is, there's a non-trivial number of networks who deaggregate their CIDRs and only announce the subnets (many of which end up smaller than RIR-minimum allocations). Who wants to be the first to filter these networks and ignore their routes? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From briand at ca.afilias.info Tue Oct 30 10:58:28 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Tue, 30 Oct 2007 10:58:28 -0400 Subject: [ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <47272926.8010901@spaghetti.zurich.ibm.com> References: <471CC069.6040005@arin.net> <546B3558-09D5-4D9D-B56C-EBD7978DB392@muada.com> <20071030230521.0e01415c.ipng@69706e6720323030352d30312d31340a.nosense.org> <47272926.8010901@spaghetti.zurich.ibm.com> Message-ID: <47274694.5010300@ca.afilias.info> Jeroen Massar wrote: > Now the fun part of this, these 5 de-aggregated blocks which where just > allocated by ARIN to a certain company called Affilias, the same company > (Presumably you meant to spell it "Afilias"...) > that he is working for, is using his email address from and which name > is also on the draft: > > 2001:500:16::/47 > 2001:500:18::/45 > 2001:500:20::/45 > 2001:500:28::/46 > 2001:500:2c::/48 > > Uh, Jeroen, the affiliation with companies, as you well know, is informative only. Pointing to what employers do when regarding proposals, is *way* off base, in the realm of ad-hominem attacks - something specifically against the mailing list charter. *However*, since you bring up the question: These are used specifically, and explicitly, for DNS anycast services for Afilias, as operator of numerous TLDs (Top Level Domains), such as ".org", ".info", ".mobi", ".aero", ".asia", etc... If you had bothered to look at the registrations, or IRR, or anywhere, that would be obvious. Even the web site www.afilias.info, makes it very clear we do DNS registries. E.g. Take a look at the *previous* ARIN assignment: mail:bind-9.4.1 (bash)$ whois -h whois.arin.net 2001:500:e:: OrgName: Afilias Canada, Corp. OrgID: ACC-308 Address: 4141 Yonge Street Address: Suite 204 City: Toronto StateProv: ON PostalCode: M2P-2A8 Country: CA NetRange: 2001:0500:0006:0000:0000:0000:0000:0000 - 2001:0500:000F:FFFF:FFFF:FFFF:FFFF:FFFF CIDR: 2001:0500:0006:0000:0000:0000:0000:0000/47, 2001:0500:0008:0000:0000:0000:0000:0000/45 NetName: AFILIAS-NET2 NetHandle: NET6-2001-500-6-1 Parent: NET6-2001-400-0 NetType: Direct Assignment NameServer: NS1.AMS1.AFILIAS-NST.INFO NameServer: NS1.MIA1.AFILIAS-NST.INFO NameServer: NS1.SEA1.AFILIAS-NST.INFO NameServer: NS1.YYZ1.AFILIAS-NST.INFO Comment: RegDate: 2006-10-19 Updated: 2007-09-26 RAbuseHandle: JAB328-ARIN RAbuseName: Abley, Joe RAbusePhone: +1-519-670-9327 RAbuseEmail: jabley at ca.afilias.info RNOCHandle: JAB328-ARIN RNOCName: Abley, Joe RNOCPhone: +1-519-670-9327 RNOCEmail: jabley at ca.afilias.info RTechHandle: JAB328-ARIN RTechName: Abley, Joe RTechPhone: +1-519-670-9327 RTechEmail: jabley at ca.afilias.info OrgTechHandle: JAB328-ARIN OrgTechName: Abley, Joe OrgTechPhone: +1-519-670-9327 OrgTechEmail: jabley at ca.afilias.info # ARIN WHOIS database, last updated 2007-10-29 19:10 # Enter ? for additional hints on searching ARIN's WHOIS database. mail:bind-9.4.1 (bash)$ whois -h whois.ra.net 2001:500:e:: route6: 2001:500:E::/48 descr: Afilias Canada, Corp. origin: AS12041 mnt-by: MAINT-AFILIAS changed: jabley at ca.afilias.info 20061109 source: RIPE mail:bind-9.4.1 (bash)$ whois -h whois.ra.net AS12041 aut-num: AS12041 as-name: AFILIAS-NST descr: Afilias Limited descr: ------------------------------------------ descr: Prefixes announced from this origin AS are descr: anycast from several places. See RFC 4787. descr: ------------------------------------------ admin-c: JA856-RIPE tech-c: JA856-RIPE export: to AS12041:AS-TRANSIT announce AS12041:AS-AFILIAS export: to AS12041:AS-PEERS announce AS12041:AS-AFILIAS export: to AS112 announce ANY import: from AS12041:AS-TRANSIT accept ANY import: from AS12041:AS-PEERS accept AS12041:AS-SET:PeerAS import: from AS112 accept AS112 mnt-by: MAINT-AFILIAS changed: jabley at ca.afilias.info 20070921 changed: jabley at ca.afilias.info 20070922 source: RIPE These are all Direct Assignments, and are anycast for DNS services. It even says so right there. > So one has to wonder, if they already got their own de-aggregated > prefixes, why do they want to block others from doing so. > > Why do you interpret "let's all avoid polluting the DFZ" to mean "If you see someone else polluting, it is okay to pollute"? We (Afilias) have /48's as direct assignments, specifically because each DNS TLD needs to operate independently. And even though we only use a single IP address from the anycast blocks, the smallest direct assignment possible under ARIN policy is a /48. Clearly, root servers and TLD servers need to be globally reachable. (*Those* router slots are an example of very good return on the usage, IMHO. The Internet is not usable without them.) > If it would happen in the first place that is, remember that a /32 > actually comes out of a reserved block of afaik a /29, as such those > blocks can grow without any problems and de-aggregation. Any ISP who > needs more than that definitely has grown a lot or have really > misplanned how much space they will need. Most ISPs will do fine with a > /64 though. > > The whole point of my proposal at ARIN, is actually orthogonal to the IETF proposal, although anchored from the same rationale: Let's adopt policies and IPv6 implementations, which ensure as long a life for IPv6, at as low an operational cost as is practical, for as long as possible. The initial "growth" curve for IPv6 won't be a true growth curve, it will be an adoption curve. It will have the same shape as that of a disease affecting a population: the rate of adoption will be N(x)(1-x) where N is a scaling factor, and x is the percentage of the networks who are IPv6. Once the vast majority of networks have IPv6 deployed, the curve *should* flatten out to a rate very close to zero. The question is, after *that* point, the real growth curve will show up. Wouldn't it be better to ensure that the rate of router slot consumption, is low enough to match up with natural router amortization and replacement periods (3-5 years) instead of causing another round of ISP bankruptcies? > As for the draft/proposal itself: why try to move the bits on the right > side (the /64 portion) when ISPs can already shove the bits on the left > side by simply justifying more address space? > > More address space (by getting new PA blocks) means more router slots being eaten. Better allocation policies means no need for router slots being eaten. And, if you look in the details of the IETF proposal, there are examples of benefits of scaling when internal aggregation is not only possible (at all), but done well - internal router slots get used in a very conservative fashion, even for the very biggest of ISPs. Brian From briand at ca.afilias.info Tue Oct 30 12:10:27 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Tue, 30 Oct 2007 12:10:27 -0400 Subject: [ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <47274D67.4000502@spaghetti.zurich.ibm.com> References: <471CC069.6040005@arin.net> <546B3558-09D5-4D9D-B56C-EBD7978DB392@muada.com> <20071030230521.0e01415c.ipng@69706e6720323030352d30312d31340a.nosense.org> <47272926.8010901@spaghetti.zurich.ibm.com> <47274694.5010300@ca.afilias.info> <47274D67.4000502@spaghetti.zurich.ibm.com> Message-ID: <47275773.7080706@ca.afilias.info> Jeroen Massar wrote: > I am not coming forward as any > company, I am coming forward as an individual user of the internet and I > have huge concerns with what you are trying to propose and what you are > actually doing yourself/company. > > I do not care what you think of what I am doing, or what my employer is doing. Period. However, you are saying you have "huge concerns with what I am trying to propose". Would you care to instantiate those concerns, and elaborate on why you think they are a problem? >> *However*, since you bring up the question: >> >> These are used specifically, and explicitly, for DNS anycast services >> for Afilias, as operator >> of numerous TLDs (Top Level Domains), such as ".org", ".info", ".mobi", >> ".aero", ".asia", etc... >> > > Thus you are advocating on one side (according to your private opinion > while pushing the name of your company) that companies should only get a > small amount of address space (eg a /48) and only provide a /120 to end > user while your company burns through a /47, 2x /45, a /46 and a /48? > > I am advocating policies applicable only to PA space. PA space is blocks given to ISPs to assign to their customers. PI space (direct assignments by RIRs) are not affected by my proposals. We use /48's because they are announced directly to the DFZ, and the following are (IMHO) applicable: - The smallest PI block assigned by RIRs is /48 - PA blocks are intended to be announced only as the PA block - deaggregating PA blocks is at best naive and at worst anti-social - multihomed networks who are sufficiently justified in getting PI blocks (by whatever rationale is generally accepted), *should* use PA or PI blocks > And that because you host some nameservers and are going to anycast > those? If you are going to anycast them, why do you need more than a > single /48? > > Because each TLD needs to be anycast from a topologically unique *set* of servers. If you have two TLDs whose topology of anycast is different, they must, by definition of anycast, have unique prefixes. We use unique prefixes for each TLD or country-code TLD (such as .ag, .mn, .in, etc.) as well as the afore-mentioned three- and four-letter TLDs. > You do expect that a huge ISP will only announce one single /20 and thus > receives all their traffic in that one spot, but for your own purposes > suddenly you are special and you are going to announce separate prefixes? > > Yes. Just the way root servers are special. All 13 of them. Anycast in a few hundred locations. There is one "root". Each of those 13 instances of "root" are anycast, and use one /48. There is more than one TLD, many more than one. Each of *those* need at *least* two /48's, since the minimum number of nameservers for any zone is two. And yes, root servers and TLD servers are *very* special. They are very much *not* DNS hosting. (I humbly suggest you review the archives of dnsop). > But just in case you do not want to read what I write, I'll state it > again: Why are you proposing that ISP's should have only one single > block and instead of them asking for one huge prefix have the end-user > receive a lot less space, this while you are requesting several large > blocks, are going to announce those blocks separately and are most > likely only going to use a few number of IP addresses in those blocks? > > See the big problem with what you are proposing and what you are > actually doing? > I see that you can't make the distinction between PA and PI blocks. The reason for suggesting policies where smaller allocations to end sites is done in PA space, is specifically because nobody knows who will be a lot bigger in 5 or 10 years. We know who is big now. We don't know who (of all the ISPs that exist, or will be started in the next 5-10 years) will be big later. The flaw in the logic of "give a huge prefix to large ISPs now" is that it presumes that only currently-large ISPs will use up lots of allocations. Even if it may be true, we don't know for sure that it will be true. > For a nice technical question. Will those blocks you are going to > announce all be announced over physically different mediums or are you > going to announce them over the same paths? If it is the latter, then > why again did you request multiple blocks and are you going to pollute > the DFZ with that? > > Different mediums. There will be overlap by site, but definitely, and by design, not 100%. It is also fluid, changing as circumstances require, and on a per-prefix (i.e. per TLD) basis. >> And even though we only use a single IP address from the anycast blocks, >> the smallest direct assignment possible under ARIN policy is a /48. >> > > And thus you request and receive: > > 2001:500:16::/47 > 2001:500:18::/45 > 2001:500:20::/45 > 2001:500:28::/46 > 2001:500:2c::/48 > > Except for the latter one, they are all larger than a single /48. Can > you elaborate on that? Are you still going to stick a single box in that > huge /48? > > ARIN is allocating blocks all at one time. It is more convenient for ARIN to handle the allocations as a "set". These are in fact all used (and registered) as discrete /48's. > If you are so confident about the proposed /120 for home user, why not > request a /120 for your DNS servers? > > PI direct assignments are not available as /120 (currently). If they were, that would be what we request. (Trust me, we do not need more than that.) The size of PI allocations, however, is not an issue at all. A PI block uses one router slot, without any consideration of its size. The only issue with PA blocks is the fact that they are reassigned, and consumed, in an unpredictable fashion. Companies doing internal stuff, whether they get a reassignment *from* a PA block, or via a PI block, generally have much more predictable usage. > One last thing to summarize it all: Eat your own dog food. > How do you know I have dogs? I do - and feed them very well. They get only the best, and yes, I do share some of what they get. Filet mignon, or chateau-briand on occassion. :-) Brian D From tedm at ipinc.net Tue Oct 30 12:11:56 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 30 Oct 2007 09:11:56 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <025001c81a88$d722b6b0$3a3816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: Stephen Sprunk [mailto:stephen at sprunk.org] >Sent: Monday, October 29, 2007 4:44 PM >To: Ted Mittelstaedt >Cc: ARIN PPML >Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > > >> I just did a support call this morning with a customer who has a >> site down in SBCGlobal territory. They needed a static IP on a >> DSL line. They were assigned a /29. ... It's incredibly wasteful. > >Perhaps there are technical reasons you're not privvy to; perhaps >it's waste >or hoarding. Either way, it's close enough for us to not quibble over >here -- though presumably ARIN staff would require a justification >for such >when their next request comes in. > Think of how many DSL customers SBCglobal has. This is SOP for any of them that has a static. They could have used a /30 not a /29, the equipment would have supported it. I think if you multiply out the number of static customers they have you will find the numbers get very high very quick. >If you want to talk about waste, look at the folks with a /8 (or two) who >could likely fit into a handful of /16s, or the folks with dozens of /16s >who only use a single /24 outside of 10/8. > I'll look - but nobody has named names, so I have to assume that these /8's that are supposedly out there are more a matter of myth than fact. >>>If we did a straw poll of folks favoring carrots vs. sticks, I'm quite >>>sure the former would outnumber the latter by an overwhelming >>>margin. >> >> In a perfect world, yes. But when you actually start LOOKING at >> what the hell is HAPPENING out in the real world you will turn up >> PLENTY of stories like the one I just cited, and I think you will be >> getting the sticks out and tossing the carrots a lot faster than >> you think. > >I've seen plenty of horrifying examples, though NDAs prevent me >from naming >names. Please don't say stuff like that, it is just a bunch of straw men. We do not sign NDAs with any customers we do service work for, (none have asked) and all of these address assignments are a matter of public record in whois. In any case, you cannot hold someone to an NDA to cover up criminal actions, it's an illegal contract in that case. A holder like SBC Global who is under RSA is arguably violating their contract with ARIN by assigning an overage of IP addresses to customers that the customers aren't asking for, in an effort to hoard IPs. In any case, without names of actual consumers this discussion is merely an idea of what someone thinks is the reality, it is not the actual reality. >However, I know better than to think that all, or even the >majority >of, legacy holders deserved to be tarred with that brush; I was not tarring legacy holders - the block I brought up as an example is not legacy. >many have been >quite willing to voluntarily return space they don't need. So far, just >asking politely has netted ARIN quite a number of returned blocks -- and >threats have, so far, netted the community nothing but a bunch of >animosity >and/or fear. You don't have any proof of threats doing anything because, as you say, ARIN hasn't used threats. Therefore there is no data as to how wasteful holders would respond to a threat. I should hope that everyone reading, even those with feeble minds, would understand the fundamental basic that you get more flies with honey than vinegar. In short, IF your going to launch a reclamation effort you START with the Mr. Nice Guy approach. But eventually the law of diminishing returns is going to kick in and the flies will be full and no longer interested in vinegar. That's why they sell RAID in cans, after all. >I'm in favor of what gets us the most productive results for >the least effort. Making enemies of people we want something from is not >helpful on either front. > By the time the law of diminishing returns acts on a reclamation effort, the wasteful holders still out there who have so far ignored the nice pleas aren't going to respond to anything other than a threat. At that time it becomes a cost/benefit decision. Making a threat costs money because you have to back it up with lawyers and the willingness to use them and those cost money. Thus, nobody is going to be daft enough to make a threat over a single wasted /29. But, I would hope that the will exists in the numbering authority to make a threat over a wasted /8, if the nice guy appeal fails. It is an insult to the rest of us who ARE playing by the rules to allow a few bad apples to get off scott free, and it is particularly insulting when they are already under RSA - like the example I cited earlier. Thus, I do not agree with your insistence that we have to close the door on threats. The current RSA contains a threat anyway - you don't pay your bill, you lose you addresses. Shall we to remove that threat too in the interests of singing kumbiya around the campfire? You get more cooperation with a 2x4 and a nice word, then with just a nice word. Ted From tedm at ipinc.net Tue Oct 30 12:35:05 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 30 Oct 2007 09:35:05 -0700 Subject: [ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <47274694.5010300@ca.afilias.info> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Brian Dickson >Sent: Tuesday, October 30, 2007 7:58 AM >To: Jeroen Massar >Cc: IPv6 Operations; ARIN People Posting Mailing List >Subject: Re: [ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction > > >Wouldn't it be better to ensure that the rate of router slot >consumption, is low enough to match up >with natural router amortization and replacement periods (3-5 years) >instead of causing another >round of ISP bankruptcies? Brian, Just quick point here. It's unlikely that if the routing table grows past existing ISP equipment that it would result in ISP bankruptcies. A far more likely scenario among the smaller cash-poor ISP's is it will encourage single homing with the resultant lowering of Internet reliability for customers of those ISPs. Ted From sleibrand at internap.com Tue Oct 30 12:43:59 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 30 Oct 2007 09:43:59 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: Message-ID: <47275F4F.4000109@internap.com> Ted Mittelstaedt wrote: > It's unlikely that if the routing > table grows past existing ISP equipment that it would result in > ISP bankruptcies. A far more likely scenario among the smaller > cash-poor ISP's is it will encourage single homing with the resultant > lowering of Internet reliability for customers of those ISPs. Even that is a bit of a false binary dichotomy. Small ISPs have several options in addition to multihoming with full BGP routes or singly homing. They can multihome with default only, announcing their route(s) to the world, but doing their outbound TE by some method other than BGP. They could accept partial routes plus default, giving them a lot of the benefit of outbound BGP route selection without having to take a full table. Or, they could actively filter deaggregates, maintaining full BGP reachability without having to keep up with their competitors' upgrade cycles. -Scott From michael.dillon at bt.com Tue Oct 30 12:51:06 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 30 Oct 2007 16:51:06 -0000 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: References: <025001c81a88$d722b6b0$3a3816ac@atlanta.polycom.com> Message-ID: > In any case, you cannot hold someone > to an NDA to cover up criminal actions, it's an illegal > contract in that case. A holder like SBC Global who is under > RSA is arguably violating their contract with ARIN by > assigning an overage of IP addresses to customers that the > customers aren't asking for, in an effort to hoard IPs. Never attribute to malice that which can be adequately explained by stupidity. I could have assumed that you had evil intent in this slur against SBC and other list members, but instead I applied Hanlon's razor and assumed the other. > You don't have any proof of threats doing anything because, > as you say, ARIN hasn't used threats. Therefore there is no > data as to how wasteful holders would respond to a threat. There is plenty of data as to how humans react to threat. If ARIN did resort to threats regarding IPv4 addresses, many organizations would leave ARIN (flight) and many others would launch lawsuits (fight). Let's not bother with an experiment because it wouldn't improve the situation. > I should hope that everyone reading, even those with feeble > minds, would understand the fundamental basic that you get > more flies with honey than vinegar. In short, IF your going > to launch a reclamation effort you START with the Mr. Nice > Guy approach. And you END with the Mr. Nice Guy approach because the law of diminishing returns tells you that vinegar ain't worth the trouble. And as for RAID, that is more likely to harm your health (and that of your kids) than to reduce the fly population. Good construction techniques and steel mesh window screens (not plastic) will keep out more flies than RAID can kill. So what is the ARIN analogy of the window screen? Maybe the use of IPv6 addresses to ward off the need to deal with IPv4 depletion issues. > By the time the law of diminishing returns acts on a > reclamation effort, the wasteful holders still out there who > have so far ignored the nice pleas aren't going to respond to > anything other than a threat. It has already happened. Bill Manning started reclamation about 10 years ago, and at this point, there isn't much left except for the Defense address ranges but even there, it takes a lot of effort to get a huge bureaucratic organization to agree to something that is not threat-related. > The current RSA contains a threat anyway - you don't pay your > bill, you lose you addresses. Shall we to remove that threat > too in the interests of singing kumbiya around the campfire? Now there is an interesting comment. Because it implies that ARIN might get some significant aggregate results by mandating that RSA signers all do internal audits and report back to ARIN. Right now the responsibility for IP addressing in most companies is spread out and scattered. There is no single point of authority in the senior management team (or thereabouts). If ARIN required RSA signers to do a serious addressing audit signed off by the CFO of the company, that would shake things up a bit. In fact, such an audit requirement would probably extend the lifetime of IPv4 at least a few more months by shaking loose a lot of available addresses within a company. --Michael Dillon From briand at ca.afilias.info Tue Oct 30 12:58:51 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Tue, 30 Oct 2007 12:58:51 -0400 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <47275F4F.4000109@internap.com> References: <47275F4F.4000109@internap.com> Message-ID: <472762CB.4010507@ca.afilias.info> Scott Leibrand wrote: > Ted Mittelstaedt wrote: >> It's unlikely that if the routing >> table grows past existing ISP equipment that it would result in >> ISP bankruptcies. A far more likely scenario among the smaller >> cash-poor ISP's is it will encourage single homing with the resultant >> lowering of Internet reliability for customers of those ISPs. > > Even that is a bit of a false binary dichotomy. Small ISPs have > several options in addition to multihoming with full BGP routes or > singly homing. They can multihome with default only, announcing their > route(s) to the world, but doing their outbound TE by some method > other than BGP. They could accept partial routes plus default, giving > them a lot of the benefit of outbound BGP route selection without > having to take a full table. Or, they could actively filter > deaggregates, maintaining full BGP reachability without having to keep > up with their competitors' upgrade cycles. > > -Scott It's also not a problem limited to the smallest of ISPs. Having to replace significant portions of one's infrastructure, before that equipment has been amortized per one's business plan, is a very bad thing. And equipment costs are generally speaking proportional, for any size of ISP. Which is to say, even medium to large ISPs may find themselves in trouble (in some cases, again) if they have to replace equipment prematurely. And medium-to-large ISPs are likely not to have the luxury of going single-homed, or of taking partial routes. (The last round of bankruptcies certainly wasn't limited to small ISPs, for example. Worldcom? PSInet? to name two biggish networks.) Brian From sleibrand at internap.com Tue Oct 30 13:24:40 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Tue, 30 Oct 2007 10:24:40 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <472762CB.4010507@ca.afilias.info> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info> Message-ID: <472768D8.50809@internap.com> Brian Dickson wrote: > Scott Leibrand wrote: >> Small ISPs have several options in addition to multihoming with full >> BGP routes or singly homing. They can multihome with default only, >> announcing their route(s) to the world, but doing their outbound TE >> by some method other than BGP. They could accept partial routes plus >> default, giving them a lot of the benefit of outbound BGP route >> selection without having to take a full table. Or, they could >> actively filter deaggregates, maintaining full BGP reachability >> without having to keep up with their competitors' upgrade cycles. > It's also not a problem limited to the smallest of ISPs. > > Having to replace significant portions of one's infrastructure, before > that equipment has been amortized per one's business plan, is a very > bad thing. > > And equipment costs are generally speaking proportional, for any size > of ISP. > > Which is to say, even medium to large ISPs may find themselves in > trouble (in some cases, again) if they have to replace equipment > prematurely. > > And medium-to-large ISPs are likely not to have the luxury of going > single-homed, or of taking partial routes. > > (The last round of bankruptcies certainly wasn't limited to small > ISPs, for example. Worldcom? PSInet? to name two biggish networks.) Yes, explosive routing table growth would definitely a problem for everyone taking full BGP routes. However, I think it's a problem that can be addressed, if/when necessary, by requiring that everyone announce their minimum-allocation-size covering aggregates, so that folks can filter out unnecessary deaggregates. With that as an alternative, I don't think routing table growth alone will push anyone into bankruptcy. -Scott From stephen at sprunk.org Tue Oct 30 13:57:04 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 30 Oct 2007 12:57:04 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm References: Message-ID: <00f001c81b20$74437320$473816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" >>If you want to talk about waste, look at the folks with a /8 (or two) who >>could likely fit into a handful of /16s, or the folks with dozens of /16s >>who only use a single /24 outside of 10/8. > > I'll look - but nobody has named names, so I have to assume that > these /8's that are supposedly out there are more a matter of myth > than fact. They are not myth; I've done consulting work for companies in those exact situations. >>I've seen plenty of horrifying examples, though NDAs prevent me >>from naming names. > > Please don't say stuff like that, it is just a bunch of straw men. We > do not sign NDAs with any customers we do service work for, > (none have asked) Lucky you. I'm under NDA to that (past) employer, and that employer is under NDA to those customers; my NDA bound me to their NDAs. I've asked, and I'm not even allowed to say who those customers are, and certainly not details of their internal networks. Even on my own, I've never done consulting work for any company that _didn't_ demand an NDA, nor have I been employed by a company that didn't since I was worked retail as a teenager. So, you can either accept what little I'm able to say, or you can call me a liar. You have no more ability to prove the latter than I do to disprove it, but I'll let the audience sort out who they choose to believe. > and all of these address assignments are a matter of public record > in whois. The assignments are; the utilizations thereof are not. For that matter, a substantial fraction of legacy assignments are to defense contractors, who have parts of their network that are not only under NDA but classified. ARIN can't get details about those networks, since AFAIK they have no staff with the appropriate clearances, and no court can order disclosure. Even employees in the "white" parts of those companies often have no clue what the "black" parts look like. > In any case, you cannot hold someone to an NDA to cover up > criminal actions, it's an illegal contract in that case. Now you're alleging criminal actions? All I've seen so far is a _potential_ breach of contract, which is a civil matter. > A holder like SBC Global who is under RSA is arguably violating > their contract with ARIN by assigning an overage of IP addresses > to customers that the customers aren't asking for, in an effort to > hoard IPs. That's a matter for ARIN's counsel and/or staff, not us. For that matter, since the details are almost assuredly under NDA, we have no clue if staff has reviewed the practice and whether or not they've found it acceptable for reasons we're not privvy to. > In any case, without names of actual consumers this discussion > is merely an idea of what someone thinks is the reality, it is not > the actual reality. I know the reality (at least at a specific time in the past) of the networks where I was the one to design or approve the IP addressing plan -- and that includes nearly a dozen Fortune 100 companies. >>However, I know better than to think that all, or even the majority >>of, legacy holders deserved to be tarred with that brush; > > I was not tarring legacy holders - the block I brought up as an > example is not legacy. The company you were referring to is a legacy holder, two /8s in fact. If they also have non-legacy blocks, then we can presume ARIN staff is on top of the matter -- or will be next time they come back for more. >>many have been quite willing to voluntarily return space they don't >>need. So far, just asking politely has netted ARIN quite a number >>of returned blocks -- and threats have, so far, netted the >>community nothing but a bunch of animosity and/or fear. > > You don't have any proof of threats doing anything because, as > you say, ARIN hasn't used threats. Therefore there is no data as > to how wasteful holders would respond to a threat. ARIN staff has not, no, but there have been a large number of discussions here about sticks which show certain participants are out to get legacy holders and certain other large companies. We've also heard from legacy holders that they perceive these to be threats by "ARIN", by which they mean the community and not the corporation. Note that this isn't just "wasteful" holders that feel threatened; it also includes those that are completely within policy. > I should hope that everyone reading, even those with feeble > minds, would understand the fundamental basic that you get > more flies with honey than vinegar. In short, IF your going to > launch a reclamation effort you START with the Mr. Nice Guy > approach. If you truly believe that, then the only point we disagree on must be whether we should discuss threats before we exhaust politeness. I find that distasteful and unnecessarily harmful to public perception. > By the time the law of diminishing returns acts on a reclamation > effort, the wasteful holders still out there who have so far ignored > the nice pleas aren't going to respond to anything other than > a threat. If they have ignored the "nice pleas", of course they won't respond to anything other than a threat. That doesn't mean we need to start working out what that threat may eventually be, or if we'll even use one, before we see how well the "nice pleas" work. > At that time it becomes a cost/benefit decision. Making a threat > costs money because you have to back it up with lawyers and > the willingness to use them and those cost money. Thus, nobody is > going to be daft enough to make a threat over a single wasted /29. Of course. > But, I would hope that the will exists in the numbering authority to > make a threat over a wasted /8, if the nice guy appeal fails. OTOH, I bet we could recover 64k /24s for less in legal fees than a single /8; the folks with /8s have hundreds of lawyers each at their disposal with nothing better to do than sue annoyances like ARIN out of existance. And if we go after one, the rest will counterattack to prevent a precedent being established that they don't like. As you said, it's a cost/benefit decision. > Thus, I do not agree with your insistence that we have to close > the door on threats. I never said we should "close the door" on them, just that it's premature to discuss them now. I believe it would be much more productive to spend all this effort figuring out what sort of outreach we need to do, what carrots we can offer, etc. If/when that fails, we will have a much more solid idea of exactly who is left, what they have to offer, what it'll take to get it, and whether it's worth the effort. > You get more cooperation with a 2x4 and a nice word, then with > just a nice word. With the first guy, yes. The second guy will be watching and find his own 2x4 -- and a bunch of friends to back him up. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From tedm at ipinc.net Tue Oct 30 14:18:25 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 30 Oct 2007 11:18:25 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >michael.dillon at bt.com >Sent: Tuesday, October 30, 2007 9:51 AM >To: ppml at arin.net >Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > >> In any case, you cannot hold someone >> to an NDA to cover up criminal actions, it's an illegal >> contract in that case. A holder like SBC Global who is under >> RSA is arguably violating their contract with ARIN by >> assigning an overage of IP addresses to customers that the >> customers aren't asking for, in an effort to hoard IPs. > >Never attribute to malice that which can be adequately >explained by stupidity. > > >I could have assumed that you had evil intent in this >slur against SBC and other list members, but instead >I applied Hanlon's razor and assumed the other. > It's why I said "arguably" instead of just stating they were deliberately violating their RSA. I see your able to understand the meaning of a sentence from the context of the message it's in - good show! Lots of people seem to not be able to. :-) >> You don't have any proof of threats doing anything because, >> as you say, ARIN hasn't used threats. Therefore there is no >> data as to how wasteful holders would respond to a threat. > >There is plenty of data as to how humans react to threat. >If ARIN did resort to threats regarding IPv4 addresses, >many organizations would leave ARIN (flight) and many >others would launch lawsuits (fight). The RSA's main threat against wastage is that ARIN can deny NEW assignments unless the requestor meets utilization requirements that they already signed a contract for saying they would meet. Sure, in theory, ARIN could yank an allocation on account of wastage - but unless it really is something like a /8 that isn't used, I would think that doing this wouldn't meet the cost/benefit hurdle of ARIN making the threat in the first place, which I already explained about. The organization ARIN was making the threat against would, of course, understand this and thus the threat would have no value. Keep in mind we AREN'T talking aboout humans here, we are talking about corporations. There's probably no denying that some corporate CEO's would react with a "I'll sue those bastards out of business" when first encountering a denial by ARIN for new numbers - but there's also probably no denying that the Chairman of the Board would probably tell the CEO I'll be damned if your going to spend my money just because your pride is wounded. Incidentially, this is the main way that anti-trust regulations in the US are enforcd. Rarely are large companies broken up - but it is routine for the US government to order divestiture of pieces of monopolies when those monopolies acquire other companies. There is long legal history of this sort of thing and the idea that a corporation could field a winnable lawsuit against ARIN denying it a NEW assignment based on failing to follow terms of an RSA the corporation has already signed is patently absurd. I'm not saying some fool somewhere wouldn't try filing such a lawsuit, of course. Thus, it is a very real threat to SBCGlobal that if and when they eventually go to ARIN and request more IPv4, that ARIN has the power to tell them they won't get more numbers until they clean up what they have. >Let's not bother >with an experiment because it wouldn't improve the >situation. > ARIN has denied IPv4 requests already, and sent the requestors back to make changes, so we already have "bothered with an experiment" IMHO. >> I should hope that everyone reading, even those with feeble >> minds, would understand the fundamental basic that you get >> more flies with honey than vinegar. In short, IF your going >> to launch a reclamation effort you START with the Mr. Nice >> Guy approach. > >And you END with the Mr. Nice Guy approach because the law >of diminishing returns tells you that vinegar ain't worth >the trouble. Why don't you try that logic the next time you get pulled over for speeding and let us know if it works. ;-) >And as for RAID, that is more likely to harm >your health (and that of your kids) than to reduce the fly >population. Good construction techniques and steel mesh >window screens (not plastic) will keep out more flies than >RAID can kill. > >So what is the ARIN analogy of the window screen? Maybe the >use of IPv6 addresses to ward off the need to deal with IPv4 >depletion issues. > That's actually an interesting response - ARIN merely tells the requestor "sorry we aren't giving you more IPv4 because your wasting it, but we will give you IPv6 instead" >> By the time the law of diminishing returns acts on a >> reclamation effort, the wasteful holders still out there who >> have so far ignored the nice pleas aren't going to respond to >> anything other than a threat. > >It has already happened. Bill Manning started reclamation about >10 years ago, and at this point, there isn't much left except for >the Defense address ranges but even there, it takes a lot of effort >to get a huge bureaucratic organization to agree to something that >is not threat-related. > >> The current RSA contains a threat anyway - you don't pay your >> bill, you lose you addresses. Shall we to remove that threat >> too in the interests of singing kumbiya around the campfire? > >Now there is an interesting comment. Because it implies that ARIN >might get some significant aggregate results by mandating that >RSA signers all do internal audits and report back to ARIN. I'm not sure how you get from "pay your bill or else" to "audit your IP holdings or else" but let's run with it >Right >now the responsibility for IP addressing in most companies is spread >out and scattered. There is no single point of authority in the senior >management team (or thereabouts). If ARIN required RSA signers to do >a serious addressing audit signed off by the CFO of the company, that >would shake things up a bit. > >In fact, such an audit requirement would probably extend the lifetime >of IPv4 at least a few more months by shaking loose a lot of available >addresses within a company. > Sounds good to me - since ARIN is comissioning us to do an audit, I'll simply deduct the labor cost to do it from their annual payment. :-) Ted From briand at ca.afilias.info Tue Oct 30 14:41:16 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Tue, 30 Oct 2007 14:41:16 -0400 Subject: [ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <47276123.7020702@spaghetti.zurich.ibm.com> References: <471CC069.6040005@arin.net> <546B3558-09D5-4D9D-B56C-EBD7978DB392@muada.com> <20071030230521.0e01415c.ipng@69706e6720323030352d30312d31340a.nosense.org> <47272926.8010901@spaghetti.zurich.ibm.com> <47274694.5010300@ca.afilias.info> <47274D67.4000502@spaghetti.zurich.ibm.com> <47275773.7080706@ca.afilias.info> <47276123.7020702@spaghetti.zurich.ibm.com> Message-ID: <47277ACC.60907@ca.afilias.info> Jeroen Massar wrote: > Brian Dickson wrote: >> We use /48's because they are announced directly to the DFZ, and the >> following are (IMHO) applicable: >> > What about that those 2x /45, that /47 and that /46 you have now? > Are you going to announce those as /48's? > The prefixes that we are announcing currently, from those blocks, are announce already as /48's. All such allocations are going to be announced only as /48's. >> - The smallest PI block assigned by RIRs is /48 >> > > The main reason is because a /48 is considered to be a single site. > You are apparently proposing to change this boundary to a /120 for the > PA blocks that are being allocated by ISPs to their users. > No, I am proposed a policy whereby the ISPs reassign space from PA blocks to their users, based on the users' own plans. The proposed policy has *suggested* sizes for examples, and neither requires */120* use, nor specifies that any specific sizes is *mandatory*. It does, however, suggest *permitting* allocation of blocks longer than /64, and provide guidance on when different specific sizes of allocation might be "ideal" for the end-site. >> Because each TLD needs to be anycast from a topologically unique *set* >> of servers. >> > But why? > Routing follows policy, not the other way round. Policy dictates what goes where. And because each TLD is subject to different policy based on a variety of factors, it is mandatory that TLDs be de-coupled so as to permit implementation of non-congruent policies. If two TLDs, ".foo" and ".bar" are served from a site in a country Fakeland, and the supreme court of Fakeland decrees that ".bar" must not exist in Fakeland, having both ".foo" and ".bar" on the same anycaset prefix would mean that ".foo" would be effectively banned from Fakeland as well. (I'm aware that removing or changing NS "glue" can achieve similar results, but that ignores the problems of caching resolvers and TTLs. The latter preclude solutions that do not have near-instantaneous effectiveness.) >> If you have two TLDs whose topology of anycast is different, they must, >> by definition of anycast, have unique prefixes. >> > > Why are they going to be different? Are you going to locate the .info > server in one datacenter but not in another? Why? > Yes. For policy reasons See the above example for one policy that could require such a difference. > There is nothing special about a TLD server. Their addresses are not > hardcoded in any configuration files that are distributed around the > world. The root-server addresses are hardcoded. TLD servers though can > be found by asking those rootservers. As such they are not more special > than having google.com NS's. > > The TLDs are delegation-only zones. And their addresses are effectively hard-coded in resolver's caches, for the duration of $TTL seconds. That itself is reason enough for them to be "special". > You are using a routing slot per nameserver, that is apparently 2 slots > per TLD. Now who is being wasteful? Them or you? > The rate of growth of TLDs is constrained by ICANN. *Every* TLD is chartered by ICANN. You can see how often they approve a new TLD, no more than a small number per year, and often much less than that. None of this has anything to do with "waste", it has to do with management of scarce resources. There is no such fundamental upper bound, currently, on PA allocations. Rate limiting PA allocations can be done by edict ("thou shalt not have another PA"). Or, PA allocations can be limited by the law of big numbers ("You can have another PA block when you have assigned 2^87 customer prefixes"). (Hint - the universe is less than 2^88 seconds old.) Or, PA allocations can be completely uncapped, with no guarantees on the rate of growth or timeline of exponential growth. I should be clear here. I do not think there is an extraordinarily high probability of PA explosive growth in the short term. I am concerned that it can't be guaranteed that it won't happen. My proposal is attempting to address this concern, at little or no cost to the community. It is reducing a *risk*, the consequences of which are harmful to everyone (to a greater or lesser degree). Opposing the proposal, is advocating for taking risks. (I just want to make you aware of that.) > But I really don't see why you need to force those PA holders to force > their customers to do /120's I'm not suggesting *forcing* anyone to do anything. I'm proposing *allowing* longer assignments, and *suggesting* suitable sizes. Currently, no one is *allowed* to give out anything longer than a /64, although lots of smart folks use longer prefixes for things like point-to-point links on their infrastructure. >> Companies doing internal stuff, whether they get a reassignment *from* a >> PA block, or via a PI block, generally >> have much more predictable usage. >> > > Again, WHY is that? > > Stating things is easy, but please add an explanation about why you are > stating it. > The explanation is not difficult. When you are in control of the plan and the usage, it is more predictable. Internal use is generally a function of capital expenditure, which is for most companies well understood and has a long lead time. When you are not in control, e.g. when the assignments are to customers (and thus a function of "sales"), it is less predictable. (If you doubt me, ask any sales person about predictability of sales.) The lead time between a sale, and the request for an address block, is considerably shorter than the planning time for network expansion. And *that* makes the latter more predictable. Brian From tedm at ipinc.net Tue Oct 30 16:38:54 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 30 Oct 2007 13:38:54 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <00f001c81b20$74437320$473816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: Stephen Sprunk [mailto:stephen at sprunk.org] >Sent: Tuesday, October 30, 2007 10:57 AM >To: Ted Mittelstaedt >Cc: ARIN PPML >Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > >Thus spake "Ted Mittelstaedt" >>>If you want to talk about waste, look at the folks with a /8 (or two) who >>>could likely fit into a handful of /16s, or the folks with dozens of /16s >>>who only use a single /24 outside of 10/8. >> >> I'll look - but nobody has named names, so I have to assume that >> these /8's that are supposedly out there are more a matter of myth >> than fact. > >They are not myth; I've done consulting work for companies in those exact >situations. > >>>I've seen plenty of horrifying examples, though NDAs prevent me >>>from naming names. >> >> Please don't say stuff like that, it is just a bunch of straw men. We >> do not sign NDAs with any customers we do service work for, >> (none have asked) > >Lucky you. I'm under NDA to that (past) employer, and that employer is >under NDA to those customers; my NDA bound me to their NDAs. I've asked, >and I'm not even allowed to say who those customers are, and certainly not >details of their internal networks. Even on my own, I've never done >consulting work for any company that _didn't_ demand an NDA, nor >have I been >employed by a company that didn't since I was worked retail as a teenager. > Any contract that obligates you to conceal something illegal is unenforceable. You can ask any lawyer that does whistleblower work about this and get PLENTY of cites. Unless those /8's are legacy, that NDA is not enforcable against you because those companies are illegally breaking their RSA with ARIN. So let's have no more of this, please. You are CHOOSING to not say anything. Many people have what they feel are legitimate reasons for not being whistleblowers, and I understand that and would respect your decision to not whistle blow for your own reasons. But, be a man and be responsible for your own choices. The NDA is not a barrier here, it is you who have made that choice. > >For that matter, a substantial fraction of legacy assignments are >to defense >contractors, who have parts of their network that are not only >under NDA but >classified. ARIN can't get details about those networks, since AFAIK they >have no staff with the appropriate clearances, and no court can order >disclosure. Even employees in the "white" parts of those companies often >have no clue what the "black" parts look like. > That is a different deal. However, those classifications only hold true in the US. If I am not a US citizen and I live outside the US I can talk publically about any US DoD classified things I feel like. The US DoD certainly returns the favor by doing the same with a lot of other countries classified military secrets. And in any case, my example wasn't legacy, and I already said I wasn't talking about legacy holders. >> In any case, you cannot hold someone to an NDA to cover up >> criminal actions, it's an illegal contract in that case. > >Now you're alleging criminal actions? All I've seen so far is a >_potential_ >breach of contract, which is a civil matter. > Fraud is not a civil matter. >> A holder like SBC Global who is under RSA is arguably violating >> their contract with ARIN by assigning an overage of IP addresses >> to customers that the customers aren't asking for, in an effort to >> hoard IPs. > >That's a matter for ARIN's counsel and/or staff, not us. ARIN's policy is set by us, we elect ARIN officers, this is definitely a matter for us. It's no different than any other representative government. I think your probably not that familiar with how these sorts of organizations operate? Openness rules the roost. >For that matter, >since the details are almost assuredly under NDA, we have no clue if staff >has reviewed the practice and whether or not they've found it >acceptable for >reasons we're not privvy to. > ARIN is required to abide by it's policies which call for, what is it, 100% utilization? In other words, ARIN staff has no ability to give a group, whether under NDA or not, a special exemption from the utilization requirements unless such exemption is spelled out in policy. Which gets back to the original thrust of my response - the devil is in the details. What is your definition of 100% utilization? Mine certainly isn't an empty /8. >> In any case, without names of actual consumers this discussion >> is merely an idea of what someone thinks is the reality, it is not >> the actual reality. > >I know the reality (at least at a specific time in the past) of >the networks >where I was the one to design or approve the IP addressing plan -- >and that >includes nearly a dozen Fortune 100 companies. > I understand that - but unless your willing to discuss names, we simply cannot make policy based on your experiences. Thus, there is really no point in even saying that there's free /8s out there, because unless you or someone else is willing to name names, those /8s aren't going to be available. And this is just for stuff under RSA - the legacy stuff is a whole different discussion. I know you are certain in what you have seen. You must understand that me saying what you have seen has to be considered mythical, does not mean I personally disbelieve you have seen this. I am just saying nobody can do anything about these since we don't know who the abusers are. >>>However, I know better than to think that all, or even the majority >>>of, legacy holders deserved to be tarred with that brush; >> >> I was not tarring legacy holders - the block I brought up as an >> example is not legacy. > >The company you were referring to is a legacy holder, two /8s in fact. The specific block in particular I cited 76.192.0.0/10 is not legacy. Whether they have legacy blocks or not had no bearing on the example. >If >they also have non-legacy blocks, then we can presume ARIN staff is on top >of the matter -- or will be next time they come back for more. > Whether ARIN is on top of the matter and may or may not take care of it sometime in the future if they ever come back for more IPv4, has absolutely no relevance to the validity of the example in how I used it in the post. >>>many have been quite willing to voluntarily return space they don't >>>need. So far, just asking politely has netted ARIN quite a number >>>of returned blocks -- and threats have, so far, netted the >>>community nothing but a bunch of animosity and/or fear. >> >> You don't have any proof of threats doing anything because, as >> you say, ARIN hasn't used threats. Therefore there is no data as >> to how wasteful holders would respond to a threat. > >ARIN staff has not, no, but there have been a large number of discussions >here about sticks which show certain participants are out to get legacy >holders and certain other large companies. Fine. The example I cited wasn't legacy. >We've also heard from legacy >holders that they perceive these to be threats by "ARIN", by which >they mean >the community and not the corporation. > Fine. The example I cited wasn't legacy. >Note that this isn't just "wasteful" holders that feel threatened; it also >includes those that are completely within policy. > No, anyone completely within policy is unthreatenable. The threat we are talking about here is someone NOT fulfilling utilization requirements. An org that is completely within policy IS fulfilling utilization requirements, as well as many other requirements, and thus cannot be threatened. Unless you are talking about some other kind of threat? >> I should hope that everyone reading, even those with feeble >> minds, would understand the fundamental basic that you get >> more flies with honey than vinegar. In short, IF your going to >> launch a reclamation effort you START with the Mr. Nice Guy >> approach. > >If you truly believe that, then the only point we disagree on must be >whether we should discuss threats before we exhaust politeness. I >find that >distasteful and unnecessarily harmful to public perception. > I think the effort to sweep any threats under the rug to be much more distasteful. If your an RSA holder, your already committed, you signed on the dotted line, buddy. You certainly are going to want to know the extent of how much ARIN could screw you over if they had a mind to, and you are going to want to know if they have a mind to. Capability does not imply intent. If your a legacy holder, your already being threatened by the existence of the Legacy RSA. The very existence of it implies that if you don't sign it, something bad might happen. Would you rather know what that bad thing might be instead of every time you ask anyone about it, just being given a bunch of assurances that there is this bad thing out there somewhere? I think most Legacy holders that haven't signed the Legacy RSA would much prefer to have whatever possible threats ARIN could make out on the table, discussed in an open forum, so they can see if there really are benefits to signing the Legacy RSA and make an informed decision. In kindergarden, they NewSpeak the word "threat" as "consequence" But it's the same thing. I'm no longer in kindergarden and I don't appreciate being talked to like a kindergardener. A threat is a threat no matter how you sugar coat it. Threats don't bother me. What I want to know is the ability and willingness to carry them out. And if your sugar-coating everything you feed to me, your trying to conceal your willingness to carry out your threats, and that to me is much more unsettling than just being honest and open. >> By the time the law of diminishing returns acts on a reclamation >> effort, the wasteful holders still out there who have so far ignored >> the nice pleas aren't going to respond to anything other than >> a threat. > >If they have ignored the "nice pleas", of course they won't respond to >anything other than a threat. That doesn't mean we need to start working >out what that threat may eventually be, or if we'll even use one, >before we >see how well the "nice pleas" work. > It doesen't mean we shouldn't work out that threat now, either. >> At that time it becomes a cost/benefit decision. Making a threat >> costs money because you have to back it up with lawyers and >> the willingness to use them and those cost money. Thus, nobody is >> going to be daft enough to make a threat over a single wasted /29. > >Of course. > >> But, I would hope that the will exists in the numbering authority to >> make a threat over a wasted /8, if the nice guy appeal fails. > >OTOH, I bet we could recover 64k /24s for less in legal fees than a single >/8; the folks with /8s have hundreds of lawyers each at their >disposal with >nothing better to do than sue annoyances like ARIN out of >existance. Throwing hundreds of lawyers on a lawsuit does not change the basic dispute or conflict. In any lawsuit there's a certain amount of work to be done. You can hire 100 lawyers at an hour each or 1 lawyer at 100 hours each, but just throwing lawyers at it does not increase the actual work. I say actual, because of course those lawyers will definitely find things to do and bill you for doing, so the perceived work will of course rise. That's why Erin Brockabitch won, and why there's tons of other David vs Goliath court cases out there. The only thing that helps is the quality of the lawyer you use, and ARIN has enough money to hire lawyers that are every bit as good as the best lawyers the other side has. And if the other side wins, then what? You gotta have a numbering clearinghouse somewhere. Does one of these fightin' wasters want to be in charge of the numbering? Hell - let them! Sure they will get their own wastage protected - but then they will just turn and go out there and do the same thing ARIN was doing, and we will be right back again where we started. >And if >we go after one, the rest will counterattack to prevent a precedent being >established that they don't like. > "the rest" aren't going to spend a nickle on counterattacking. It's like the old saw that they came for this guy and I didn't speak up, they came for that guy and I didn't speak up, they came for this other guy and I didn't speak up, now they are coming for me, darn, I should have spoke up. You yourself are unwilling to divulge a "waster" of a /8, your a perfect example of why "the rest" aren't going to get involved. You don't want to get involved or you would name names, NDA be dammed. The others don't want to get involved for their reasons, they won't counterattack. For that matter, many of "the rest" probably need more IPv4 and are going to greedily wait on the sidelines to see if ARIN can extract any, then fight with each other over the scraps if it does. >As you said, it's a cost/benefit decision. > >> Thus, I do not agree with your insistence that we have to close >> the door on threats. > >I never said we should "close the door" on them, just that it's >premature to >discuss them now. I believe it would be much more productive to spend all >this effort figuring out what sort of outreach we need to do, what carrots >we can offer, etc. If/when that fails, we will have a much more >solid idea >of exactly who is left, what they have to offer, what it'll take >to get it, >and whether it's worth the effort. > >> You get more cooperation with a 2x4 and a nice word, then with >> just a nice word. > >With the first guy, yes. The second guy will be watching and find his own >2x4 -- and a bunch of friends to back him up. > Uh huh. I guess that is why when I get on the freeway that everyone drives 90Mph when they see a cop. Ted From ipng at 69706e6720323030352d30312d31340a.nosense.org Tue Oct 30 16:58:05 2007 From: ipng at 69706e6720323030352d30312d31340a.nosense.org (Mark Smith) Date: Wed, 31 Oct 2007 07:28:05 +1030 Subject: [ppml] Fwd: Policy Proposal: IPv6 Assignment Size Reduction In-Reply-To: <47272926.8010901@spaghetti.zurich.ibm.com> References: <471CC069.6040005@arin.net> <546B3558-09D5-4D9D-B56C-EBD7978DB392@muada.com> <20071030230521.0e01415c.ipng@69706e6720323030352d30312d31340a.nosense.org> <47272926.8010901@spaghetti.zurich.ibm.com> Message-ID: <20071031072805.b4d89601.ipng@69706e6720323030352d30312d31340a.nosense.org> On Tue, 30 Oct 2007 12:52:54 +0000 Jeroen Massar wrote: > Mark Smith wrote: > > Iljitsch van Beijnum wrote: > > > >> I thought this would be interesting reading for the working group. > >> > > > > I think the best thing to do is ignore it. If it gets any traction in > > ARIN, then we might have to do something. > > > > (I'm embarrassed to be listed in the acknowledgements section of the > > related draft, because it can imply I agree with it - and my position is > > the complete opposite - I'm even fairly strongly anti-/56.) > > > A proposal for changing the /48 boundary for *home users* to /56 though > might at a certain point be a good idea. Companies should be getting a > /48 IMHO. > (Note to ARIN people who might receive this, below is written for the V6OPS list, which is where this issue was brought up. I'm not addressing ARIN policy, and I'm not effected by it either, as I'm in the APNIC region. Thanks.) As an operator, my objection to /56 is that I like the simplicity of being able to always assume an end customer has a /48, regardless of what type of customer they are. The moment there are /48s or /56s, that means every single time I'm talking about customer address space, I'd have make sure or be sure it's clear to the other person or people that it's a /48 or a /56, meaning that every time I discuss it, I have to state it. It's a small cost, but one repeated many many times. It also creates an opportunity for error. /48s everywhere means one less thing to break. If customers were to get a /56, I'd probably be reserving the /48 that the /56 falls within to allow for that customer to grow without having to renumber. At some point in the future they might call me up and say I want to grow my /56, and I'd be saying, just shorten your prefix length. I figure since I'd be reserving the /48 for them anyway, I can even eliminate that cost of dealing with that query, and give them the /48 from the outset. I should never hear from the again, at least about addressing issues. I'm fairly strongly against /56s just because fundamentally it is extra complexity for which I can't see much practical benefit. I'm not absolutely against it though - it's something I'd compromise on because in the big picture, the increased complexity costs aren't all that significant, and if, over time, it helps people get used to giving enough address space for convenience, not for necessary funcationality, then I'll wear those costs. More than two boundaries though is something I'm absolutely against. That's unnecessary complexity. Regards, Mark. From info at arin.net Tue Oct 30 17:08:30 2007 From: info at arin.net (Member Services) Date: Tue, 30 Oct 2007 17:08:30 -0400 Subject: [ppml] ARIN XX Meeting Report Now Available Message-ID: <001301c81b39$06013f50$528888c0@arin.net> From 17-19 October, the ARIN community took part in the ARIN XX Public Policy and Members Meeting, held in Albuquerque, New Mexico. The report of that meeting, which includes presentations, summary notes, and transcripts of the entire meeting, is now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XX/ The URL referenced above also provides links to presentations for the Sunday IPv6 activities held jointly with NANOG 41. Please check back later this week when an archive of the meeting's webcast will be made available. ARIN would also like to extend congratulations to Rich Schultz and Elise Gerich, winners of the ARIN XX Meeting Survey Raffle! Their names were randomly selected from the ARIN XX meeting survey entries. Rich will receive an iPod nano with video and Elise will receive a D-Link 4-Port Broadband VPN Router, which was provided by Shaw Communications. We thank everyone in the community who participated in person or remotely at the meeting and those who responded to the survey. Please remember to mark you calendars and plan on joining us for ARIN XXI in Denver, Colorado, 6-9 April 2008. Regards, Member Services American Registry for Internet Numbers (ARIN) From bonomi at mail.r-bonomi.com Tue Oct 30 21:58:52 2007 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Tue, 30 Oct 2007 19:58:52 -0600 (CST) Subject: [ppml] IPv6 assignment - proposal for change to nrpm Message-ID: <200710310158.l9V1wq2u006555@mail.r-bonomi.com> > From: "Ted Mittelstaedt" > Date: Tue, 30 Oct 2007 13:38:54 -0700 > Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > Any contract that obligates you to conceal something illegal is > unenforceable. > You can ask any lawyer that does whistleblower work about this and get > PLENTY of cites. Unless those /8's are legacy, that NDA is not enforcable > against you because those companies are illegally breaking their RSA with > ARIN. *YOU* are wrong. "breach of contract" is not a criminal matter. It is a civil tort _only_. public disclosure of tortuous behavior _is_ ationable under an NDA. WITHOUT 'whistleblower'protetions. From michael.dillon at bt.com Wed Oct 31 02:46:39 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 31 Oct 2007 06:46:39 -0000 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <472768D8.50809@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info> <472768D8.50809@internap.com> Message-ID: > Yes, explosive routing table growth would definitely a > problem for everyone taking full BGP routes. However, I > think it's a problem that can be addressed, if/when > necessary, by requiring that everyone announce their > minimum-allocation-size covering aggregates, so that folks > can filter out unnecessary deaggregates. I don't believe that it is within the scope of ARIN's charter to require this. The same topic recently came up within RIPE and I had a look at their terms of reference and came to the same conclusion. As far as I can see, all decisions about route announcements can be freely made by network operators and the only mechanism for limiting this is bilateral peering agreements. --Michael Dillon From iggy at merit.edu Wed Oct 31 09:19:10 2007 From: iggy at merit.edu (Glenn S. Wiltse) Date: Wed, 31 Oct 2007 09:19:10 -0400 Subject: [ppml] ARIN XX Meeting Report Now Available In-Reply-To: <001301c81b39$06013f50$528888c0@arin.net> References: <001301c81b39$06013f50$528888c0@arin.net> Message-ID: <472880CE.3020601@merit.edu> Is there some place that has the results of the 'straw polls' that were taken at the meeting? Particularly as they relate to the various Policy Proposals? I had thought this would be included in the transcripts but they don't appear to be there. Glenn Wiltse Member Services wrote: > >From 17-19 October, the ARIN community took part in the ARIN XX Public > Policy and Members Meeting, held in Albuquerque, New Mexico. The report > of that meeting, which includes presentations, summary notes, and > transcripts of the entire meeting, is now available on the ARIN website > at: > > http://www.arin.net/meetings/minutes/ARIN_XX/ > > The URL referenced above also provides links to presentations for the > Sunday IPv6 activities held jointly with NANOG 41. Please check back > later this week when an archive of the meeting's webcast will be made > available. > > ARIN would also like to extend congratulations to Rich Schultz and Elise > Gerich, winners of the ARIN XX Meeting Survey Raffle! Their names were > randomly selected from the ARIN XX meeting survey entries. Rich will > receive an iPod nano with video and Elise will receive a D-Link 4-Port > Broadband VPN Router, which was provided by Shaw Communications. > > We thank everyone in the community who participated in person or > remotely at the meeting and those who responded to the survey.=20 > > Please remember to mark you calendars and plan on joining us for ARIN > XXI in Denver, Colorado, 6-9 April 2008. > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy > Mailing List (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services > Help Desk at info at arin.net if you experience any issues. > From plzak at arin.net Wed Oct 31 10:47:06 2007 From: plzak at arin.net (Ray Plzak) Date: Wed, 31 Oct 2007 10:47:06 -0400 Subject: [ppml] ARIN XX Meeting Report Now Available In-Reply-To: <472880CE.3020601@merit.edu> References: <001301c81b39$06013f50$528888c0@arin.net> <472880CE.3020601@merit.edu> Message-ID: Glenn, The show of hands that you are referring to are conducted by the chair as an input to the Advisory Council as part of a total picture that the AC puts together in its determination of consensus and the nature of that consensus. These "counts" are not intended to be independent events which could be used out of context of the overall discussion by the community that occurs on the ppml as well as at the meeting. Ray > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of > Glenn S. Wiltse > Sent: Wednesday, October 31, 2007 9:19 AM > To: info at arin.net > Cc: 'Public Policy Mailing List' > Subject: Re: [ppml] ARIN XX Meeting Report Now Available > > Is there some place that has the results of the 'straw polls' that > were taken at the meeting? Particularly as they relate to the various > Policy Proposals? I had thought this would be included in the > transcripts but they don't appear to be there. > > Glenn Wiltse > > Member Services wrote: > > >From 17-19 October, the ARIN community took part in the ARIN XX > Public > > Policy and Members Meeting, held in Albuquerque, New Mexico. The > report > > of that meeting, which includes presentations, summary notes, and > > transcripts of the entire meeting, is now available on the ARIN > website > > at: > > > > http://www.arin.net/meetings/minutes/ARIN_XX/ > > > > The URL referenced above also provides links to presentations for the > > Sunday IPv6 activities held jointly with NANOG 41. Please check back > > later this week when an archive of the meeting's webcast will be made > > available. > > > > ARIN would also like to extend congratulations to Rich Schultz and > Elise > > Gerich, winners of the ARIN XX Meeting Survey Raffle! Their names > were > > randomly selected from the ARIN XX meeting survey entries. Rich will > > receive an iPod nano with video and Elise will receive a D-Link 4- > Port > > Broadband VPN Router, which was provided by Shaw Communications. > > > > We thank everyone in the community who participated in person or > > remotely at the meeting and those who responded to the survey.=20 > > > > Please remember to mark you calendars and plan on joining us for > ARIN > > XXI in Denver, Colorado, 6-9 April 2008. > > > > Regards, > > > > Member Services > > American Registry for Internet Numbers (ARIN) > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to the ARIN > Public Policy > > Mailing List (PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > > Help Desk at 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 (PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN > Member Services > Help Desk at info at arin.net if you experience any issues. From michael.dillon at bt.com Wed Oct 31 11:01:29 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 31 Oct 2007 15:01:29 -0000 Subject: [ppml] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: <0ff601c81b2c$c38e4110$4aaac330$@net> References: <0ff601c81b2c$c38e4110$4aaac330$@net> Message-ID: > Policy summary: > This policy will establish a process for RIR-to-RIR > redistribution of the tail-end of the IPv4 pool, taking > effect after the IANA Reserve is exhausted. Each > redistribution Allocation will be triggered by the recipient > RIR depleting its reserve to a 30 day supply, and will result > in up to a 3 month supply being transferred from the RIR with > the longest remaining time before it exhausts its own pool. Finally some sensible discussion about the end-game that does not cause us to reach a crisis sooner, and may extend the overall life of IPv4 by a small amount. It also removes the incentives for companies to create shell companies in other regions to lock up a supply of IPv4 addresses. We should discard all the other silly end-game proposals and do some serious work on making a workable variation of this one. --Michael Dillon From sleibrand at internap.com Wed Oct 31 11:30:14 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 08:30:14 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info> <472768D8.50809@internap.com> Message-ID: <47289F86.3080809@internap.com> michael.dillon at bt.com wrote: >> Yes, explosive routing table growth would definitely a >> problem for everyone taking full BGP routes. However, I >> think it's a problem that can be addressed, if/when >> necessary, by requiring that everyone announce their >> minimum-allocation-size covering aggregates, so that folks >> can filter out unnecessary deaggregates. >> > > I don't believe that it is within the scope of ARIN's charter > to require this. The same topic recently came up within RIPE and > I had a look at their terms of reference and came to the same > conclusion. > If by "require" you mean "enforce", then you're probably right. However, if by "require" you mean "state what should happen" there is precedent: the IPv6 guidelines say you have to announce your allocation as a single netblock. > As far as I can see, all decisions about route announcements > can be freely made by network operators and the only mechanism > for limiting this is bilateral peering agreements. Yeah, in practice ISP filtering is the only enforcement mechanism here. However, as an earlier poster pointed out, ISPs currently have nothing to point to if they want to tell their customers that announcing their covering aggregates is the right thing to do. I think it would be useful for ARIN to state that such behavior is expected, either in the NRMP or the upcoming NPOG. -Scott From briand at ca.afilias.info Wed Oct 31 11:37:41 2007 From: briand at ca.afilias.info (Brian Dickson) Date: Wed, 31 Oct 2007 11:37:41 -0400 Subject: [ppml] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: References: <0ff601c81b2c$c38e4110$4aaac330$@net> Message-ID: <4728A145.90302@ca.afilias.info> michael.dillon at bt.com wrote: >> Policy summary: >> This policy will establish a process for RIR-to-RIR >> redistribution of the tail-end of the IPv4 pool, taking >> effect after the IANA Reserve is exhausted. Each >> redistribution Allocation will be triggered by the recipient >> RIR depleting its reserve to a 30 day supply, and will result >> in up to a 3 month supply being transferred from the RIR with >> the longest remaining time before it exhausts its own pool. >> This does sound interesting, and further helps fine-tune any tail-end disparity that exists following the final IANA allocations. However, I believe the value of this would be weakened by having this policy implemented too frequently, e.g. if the fastest-allocating RIRs need to do this more than once, or if a slow-allocating RIR is "hit" more than once. > Finally some sensible discussion about the end-game that does > not cause us to reach a crisis sooner, and may extend the overall > life of IPv4 by a small amount. It also removes the incentives > for companies to create shell companies in other regions to lock > up a supply of IPv4 addresses. > > We should discard all the other silly end-game proposals and do > some serious work on making a workable variation of this one. > I would point out that this policy applies *after* the IANA reserve has been allocated. The other policies under discussion apply *before* the reserve has run out, and concern when and how the final IANA blocks are allocated to RIRs. As such, the two kinds of proposals are orthogonal. And, in fact, if both kinds are implemented, the benefit is greater than if only one or the other were implemented. As such, I would have to encourage support for both the "pie" proposal, *and* this "cooperative" proposal. Brian From michael.dillon at bt.com Wed Oct 31 12:20:09 2007 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 31 Oct 2007 16:20:09 -0000 Subject: [ppml] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: <4728A145.90302@ca.afilias.info> References: <0ff601c81b2c$c38e4110$4aaac330$@net> <4728A145.90302@ca.afilias.info> Message-ID: > > We should discard all the other silly end-game proposals > and do some > > serious work on making a workable variation of this one. > > > I would point out that this policy applies *after* the IANA > reserve has been allocated. > > The other policies under discussion apply *before* the > reserve has run out, and concern when and how the final IANA > blocks are allocated to RIRs. > > As such, the two kinds of proposals are orthogonal. Exactly! The policies that apply before the IANA reserve has run out, are silly. This policy, which applies after the IANA reserve has run out, makes some sense and does result in a soft landing. > And, in fact, if both kinds are implemented, the benefit is > greater than if only one or the other were implemented. I disagree. And if Tony Hain's policy were to be implemented, then everything before that is basically meaningless. --Michael Dillon From bjohnson at drtel.com Wed Oct 31 12:45:29 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 31 Oct 2007 11:45:29 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <47289F86.3080809@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> Message-ID: <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> Scott Leibrand wrote: > > michael.dillon at bt.com wrote: > >> Yes, explosive routing table growth would definitely a > >> problem for everyone taking full BGP routes. However, I > >> think it's a problem that can be addressed, if/when > >> necessary, by requiring that everyone announce their > >> minimum-allocation-size covering aggregates, so that folks > >> can filter out unnecessary deaggregates. > >> > > > > I don't believe that it is within the scope of ARIN's charter > > to require this. The same topic recently came up within RIPE and > > I had a look at their terms of reference and came to the same > > conclusion. > > > > If by "require" you mean "enforce", then you're probably right. > However, if by "require" you mean "state what should happen" there is > precedent: the IPv6 guidelines say you have to announce your allocation > as a single netblock. > Question: Does it say you cannot advertise smaller portions as well as the larger block? > > As far as I can see, all decisions about route announcements > > can be freely made by network operators and the only mechanism > > for limiting this is bilateral peering agreements. > > Yeah, in practice ISP filtering is the only enforcement mechanism here. > However, as an earlier poster pointed out, ISPs currently have nothing > to point to if they want to tell their customers that announcing their > covering aggregates is the right thing to do. I think it would be > useful for ARIN to state that such behavior is expected, either in the > NRMP or the upcoming NPOG. I think Michael is right on this one. ARIN needs to stay out of the routing implications. This is getting too much into how the network is operated, instead of the allocation of public resources. - Brian From leo.vegoda at icann.org Wed Oct 31 13:06:52 2007 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 31 Oct 2007 18:06:52 +0100 Subject: [ppml] [address-policy-wg] Policy proposal - Cooperative distribution of the end of the IPv4 free pool. In-Reply-To: References: <0ff601c81b2c$c38e4110$4aaac330$@net> Message-ID: <31339337-6D56-4C48-9BAA-2D74BD6D13AA@icann.org> Hi, We'd be grateful if people could stop cc'ing iana at iana.org when posting messages to this discussion as it generates unnecessary tickets in our ticketing system. Many thanks, Leo Vegoda From tedm at ipinc.net Wed Oct 31 13:10:08 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 31 Oct 2007 10:10:08 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <200710310158.l9V1wq2u006555@mail.r-bonomi.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Robert Bonomi >Sent: Tuesday, October 30, 2007 6:59 PM >To: ppml at arin.net >Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > >> From: "Ted Mittelstaedt" >> Date: Tue, 30 Oct 2007 13:38:54 -0700 >> Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm >> >> Any contract that obligates you to conceal something illegal is >> unenforceable. >> You can ask any lawyer that does whistleblower work about this and get >> PLENTY of cites. Unless those /8's are legacy, that NDA is not >enforcable >> against you because those companies are illegally breaking their RSA with >> ARIN. > >*YOU* are wrong. > >"breach of contract" is not a criminal matter. It is a civil tort _only_. >public disclosure of tortuous behavior _is_ ationable under an NDA. >WITHOUT 'whistleblower'protetions. > Groan. Not again. Please review the following: http://www.arin.net/policy/nrpm.html 4.2.2 Initial allocations to ISPs. In fact, this entire page. If an org is purely legacy, and they are getting their first allocation under RSA, if they claim they have met "efficient utilization" for their first allocation, they are committing fraud if they have under utilized /8's floating around. http://www.arin.net/registration/guidelines/ipv4_add_alloc.html If an org requests additional space, and doesen't have efficient utilization of existing space, this is also fraud. You can have both fraud and breach of contract for the same action, of course. Fraud is criminal not civil. Whistleblower protections apply. Ted From sleibrand at internap.com Wed Oct 31 14:33:40 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 11:33:40 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> Message-ID: <4728CA84.8070501@internap.com> Brian Johnson wrote: > Scott Leibrand wrote: > >> If by "require" you mean "enforce", then you're probably right. >> However, if by "require" you mean "state what should happen" there is >> precedent: the IPv6 guidelines say you have to announce your allocation as a single netblock. >> > > Question: Does it say you cannot advertise smaller portions as well as > the larger block? > There's some debate on that, but as I read it, no. My understanding is that you're free to advertise subnets longer than /32 out of PA space, but other networks are free to filter them. I think it may eventually be necessary to move toward something similar for IPv4, but it's not all that urgent just yet. -Scott From bjohnson at drtel.com Wed Oct 31 14:41:34 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 31 Oct 2007 13:41:34 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728CA84.8070501@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> Message-ID: <29A54911243620478FF59F00EBB12F47C32365@ex01.drtel.lan> Scott Leibrand wrote: > >> precedent: the IPv6 guidelines say you have to announce your > allocation as a single netblock. > >> > > > > Question: Does it say you cannot advertise smaller portions as well > as > > the larger block? > > > > There's some debate on that, but as I read it, no. My understanding is > that you're free to advertise subnets longer than /32 out of PA space, > but other networks are free to filter them. > > I think it may eventually be necessary to move toward something similar > for IPv4, but it's not all that urgent just yet. > So I can announce subnets longer than /32 to my desire and anyone can filter as they desire. Sounds like the IPv4 status quo to me. - Brian From sleibrand at internap.com Wed Oct 31 14:43:44 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 11:43:44 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <29A54911243620478FF59F00EBB12F47C32365@ex01.drtel.lan> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> <29A54911243620478FF59F00EBB12F47C32365@ex01.drtel.lan> Message-ID: <4728CCE0.6030703@internap.com> Brian Johnson wrote: > Scott Leibrand wrote: > >>> Question: Does it say you cannot advertise smaller portions as well as the larger block? >>> >>> >> There's some debate on that, but as I read it, no. My understanding is that you're free to advertise subnets longer than /32 out of PA space, >> but other networks are free to filter them. >> >> I think it may eventually be necessary to move toward something similar for IPv4, but it's not all that urgent just yet. >> >> > > So I can announce subnets longer than /32 to my desire and anyone can > filter as they desire. > > Sounds like the IPv4 status quo to me. Almost, but with one important difference: you have to announce your covering aggregate, which makes it safe to filter more-specifics without affecting reachability. -Scott From bjohnson at drtel.com Wed Oct 31 14:59:50 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 31 Oct 2007 13:59:50 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728CCE0.6030703@internap.com> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> <29A54911243620478FF59F00EBB12F47C32365@ex01.drtel.lan> <4728CCE0.6030703@internap.com> Message-ID: <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan> Scott Leibrand wrote: > Brian Johnson wrote: > > So I can announce subnets longer than /32 to my desire and anyone can > > filter as they desire. > > > > Sounds like the IPv4 status quo to me. > > Almost, but with one important difference: you have to announce your > covering aggregate, which makes it safe to filter more-specifics > without > affecting reachability. This is true today; I can break-up my ARIN allocation and advertise longer prefixes down to a point where I will lose some network reachability. Actually, we should remove the language from the IPv6 policy that indicates anything about advertising the "covering aggregate" unless we are willing to cede that all assignments will remain purely hierarchical in nature. So anyone who multi-homes will have to get an assignment from a RIR to maintain reachability. Since my last statement appears to be implied by IPv6 policy, but not implied in IPv4 policy, I have no issues with the policy. - Brian From sleibrand at internap.com Wed Oct 31 15:22:40 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 12:22:40 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan> References: <47275F4F.4000109@internap.com> <472762CB.4010507@ca.afilias.info><472768D8.50809@internap.com> <47289F86.3080809@internap.com> <29A54911243620478FF59F00EBB12F47C32354@ex01.drtel.lan> <4728CA84.8070501@internap.com> <29A54911243620478FF59F00EBB12F47C32365@ex01.drtel.lan> <4728CCE0.6030703@internap.com> <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan> Message-ID: <4728D600.6060903@internap.com> Brian Johnson wrote: > This is true today; I can break-up my ARIN allocation and advertise > longer prefixes down to a point where I will lose some network > reachability. Actually, we should remove the language from the IPv6 > policy that indicates anything about advertising the "covering > aggregate" unless we are willing to cede that all assignments will > remain purely hierarchical in nature. So anyone who multi-homes will > have to get an assignment from a RIR to maintain reachability. > I don't think that's true. Today, anything you advertise in IPv4 down to a /24 will be accepted more or less by everyone. However, that's only a convenience for optimal TE. In order to just maintain reachability, all you really need is for your upstreams (all your transit providers and all their transit providers) to accept your deaggregated routes from you and from each other. The rest of the world need only accept the RIR-assignment-size covering aggregate, route the traffic toward one of your transit providers, and then let the more-specifics take over when they hand the traffic off to them. -Scott From bjohnson at drtel.com Wed Oct 31 15:49:02 2007 From: bjohnson at drtel.com (Brian Johnson) Date: Wed, 31 Oct 2007 14:49:02 -0500 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728D600.6060903@internap.com> References: <29A54911243620478FF59F00EBB12F47C32368@ex01.drtel.lan> <4728D600.6060903@internap.com> Message-ID: <29A54911243620478FF59F00EBB12F47C32370@ex01.drtel.lan> Scott Leibrand wrote: > Brian Johnson wrote: > > This is true today; I can break-up my ARIN allocation and advertise > > longer prefixes down to a point where I will lose some network > > reachability. Actually, we should remove the language from the IPv6 > > policy that indicates anything about advertising the "covering > > aggregate" unless we are willing to cede that all assignments will > > remain purely hierarchical in nature. So anyone who multi-homes will > > have to get an assignment from a RIR to maintain reachability. > > > > I don't think that's true. Today, anything you advertise in IPv4 down > to a /24 will be accepted more or less by everyone. Yes. But this came about due to common network policy and time, not ARIN policy. It could just as easily been a /20 if the screaming was not as loud. > However, that's > only a convenience for optimal TE. In order to just maintain > reachability, all you really need is for your upstreams (all your > transit providers and all their transit providers) to accept your > deaggregated routes from you and from each other. I have no control beyond my agreement with my direct upstream. If I am connected with provider A and B for multi-homed up-links, provider C (connected with both A and B) has no obligation to take anything I say. If I advertise /24 and they have a block on anything longer than /22, I'm not reachable from a network connected only by C. This is not an ARIN issue; it's a management and network policy issue. > The rest of the world > need only accept the RIR-assignment-size covering aggregate, route the > traffic toward one of your transit providers, and then let the > more-specifics take over when they hand the traffic off to them. This assumes that you have advertized the actual "RIR-assigned-size" block to your providers. This is sometimes not desirable and I have seen it often where the larger block is not advertized. Since IPv6 was "engineered" to get back to a more strictly hierarchical model, this forces us to find different ways of handling these issues. My only real point is that routing decisions should not be directly "governed" by ARIN policy. I think we are just beating this topic with a smelly herring. :) - Brian From tedm at ipinc.net Wed Oct 31 17:02:41 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 31 Oct 2007 14:02:41 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728D600.6060903@internap.com> Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Scott Leibrand >Sent: Wednesday, October 31, 2007 12:23 PM >To: Brian Johnson >Cc: ppml at arin.net >Subject: Re: [ppml] Effects of explosive routing table growth on ISP >behavior > > >Brian Johnson wrote: >> This is true today; I can break-up my ARIN allocation and advertise >> longer prefixes down to a point where I will lose some network >> reachability. Actually, we should remove the language from the IPv6 >> policy that indicates anything about advertising the "covering >> aggregate" unless we are willing to cede that all assignments will >> remain purely hierarchical in nature. So anyone who multi-homes will >> have to get an assignment from a RIR to maintain reachability. >> > >I don't think that's true. Today, anything you advertise in IPv4 down >to a /24 will be accepted more or less by everyone. However, that's >only a convenience for optimal TE. In order to just maintain >reachability, all you really need is for your upstreams (all your >transit providers and all their transit providers) to accept your >deaggregated routes from you and from each other. The rest of the world >need only accept the RIR-assignment-size covering aggregate, route the >traffic toward one of your transit providers, and then let the >more-specifics take over when they hand the traffic off to them. > But But But... Suppose you have an ISP who has a /20. He has 3 NOCs. The first has a /21 assigned, the second and 3rd each have /22's, all of these are out of this /20 The 3 NOCs are fully meshed for failover redundancy in case one of the providers tanks it, and he has a feed from each NOC to a transit provider. He starts out advertising the aggregate /20 to all 3 transit providers. But he then finds out that most of the destinations on the Internet favor 1 transit provider and so most of his traffic is coming in to 1 of the NOCs and being sent over the mesh failover links. He doesen't like this - so he splits the /20 advertisement into 3 advertisements, a /21 and 2 /22's and advertises all 4 out of each NOC, with prepending on the advertisements that are not for that specific NOC, (the 4th being the aggregated /20) If the rest of the world starts filtering out his RIR-assignment size, then won't his load balancing go right out the window? Ted From sleibrand at internap.com Wed Oct 31 17:23:23 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 14:23:23 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: Message-ID: <4728F24B.4060101@internap.com> Ted Mittelstaedt wrote: > > Suppose you have an ISP who has a /20. > > He has 3 NOCs. The first has a /21 assigned, the second and > 3rd each have /22's, all of these are out of this /20 > > The 3 NOCs are fully meshed for failover redundancy in case one > of the providers tanks it, and he has a feed from each NOC > to a transit provider. > > He starts out advertising the aggregate /20 to all 3 transit > providers. But he then finds out that most of the destinations > on the Internet favor 1 transit provider and so most of his > traffic is coming in to 1 of the NOCs and being sent over > the mesh failover links. > > He doesen't like this - so he splits the /20 advertisement into > 3 advertisements, a /21 and 2 /22's and advertises all 4 out > of each NOC, with prepending on the advertisements that are > not for that specific NOC, (the 4th being the aggregated /20) > Good. With those advertisements, he only needs to do a couple more things: make sure that his transit providers not only accept all those routes from him, but also accept them from each other, and announce a peer-level localpref community on the backup routes (in addition to the prepending). That way, the backup link will be truly backup, and will not receive inbound traffic from singly-homed downstream customers of that transit provider. (All the NSPs we work with offer some form of low-localpref community, and this is a routine current practice by our multihomed customers.) > If the rest of the world starts filtering out his RIR-assignment > size, then won't his load balancing go right out the window? > Not if you do peer-level localpref communities on the backup announcements. That way, if I'm a third party network filtering at RIR-assignment size, and I prefer transit provider 1 (like everyone else), then my packets hit that transit provider, then get immediately sent across the closest peering link to the preferred transit provider. Not completely optimal, but it preserves the ISP's ability to do inbound TE, while providing a safety valve to filter deaggregates where necessary without losing reachability. Again, I'm not advocating anyone start filtering just yet, but I think we need to design our policies to ensure we don't block the safety valve. -Scott From stephen at sprunk.org Wed Oct 31 17:10:29 2007 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 31 Oct 2007 16:10:29 -0500 Subject: [ppml] IPv6 assignment - proposal for change to nrpm References: Message-ID: <03b201c81c06$7dd917a0$473816ac@atlanta.polycom.com> Thus spake "Ted Mittelstaedt" >>>>I've seen plenty of horrifying examples, though NDAs prevent me >>>>from naming names. >>> >>> Please don't say stuff like that, it is just a bunch of straw men. >>> We do not sign NDAs with any customers we do service work >>> for, (none have asked) >> >>Lucky you. I'm under NDA to that (past) employer, and that >>employer is under NDA to those customers; my NDA bound me to >>their NDAs. I've asked, and I'm not even allowed to say who those >>customers are, and certainly not details of their internal networks. >>Even on my own, I've never done consulting work for any company >>that _didn't_ demand an NDA, nor have I been employed by a >>company that didn't since I was worked retail as a teenager. > > Any contract that obligates you to conceal something illegal is > unenforceable. If I had been aware of someone committing a crime, I would have contacted the appropriate law enforcement agency. AFAIK, no laws were broken. There was no fraud, for example, since they never represented that their utilization _was_ efficient to anyone -- and it so obviously wasn't that nobody would even attempt to claim such. >>For that matter, a substantial fraction of legacy assignments are >>to defense contractors, who have parts of their network that are >>not only under NDA but classified. ARIN can't get details about >>those networks, since AFAIK they have no staff with the appropriate >>clearances, and no court can order disclosure. Even employees >>in the "white" parts of those companies often have no clue what >>the "black" parts look like. > > That is a different deal. However, those classifications only hold true > in the US. If I am not a US citizen and I live outside the US I can talk > publically about any US DoD classified things I feel like. The only non-citizens outside the US which _should_ be able to get such information in the first place will be under similar laws from their own government. If anyone else obtained DoD classified information, someone with a clearance illegally gave it to them and they'll likely end up in a deep, dark hole. Depending on how sensitive the information is, the USG may perform a "rendition" and bring the unauthorized person to US soil for detention. In case you missed it, in the 80s Congress asserted worldwide jurisdiction and enforcement of its laws -- including over non-US citizens on non-US soil. Since victims don't usually get trials or press coverage, we have no clue how often it happens. >>> A holder like SBC Global who is under RSA is arguably violating >>> their contract with ARIN by assigning an overage of IP addresses >>> to customers that the customers aren't asking for, in an effort to >>> hoard IPs. >> >>That's a matter for ARIN's counsel and/or staff, not us. > > ARIN's policy is set by us, we elect ARIN officers, this is definitely > a matter for us. No, it is not. If you are unhappy with the actions of ARIN's board and you're a member, you can vote for different candidates. That's where your control ends. Only ARIN's employees and counsel are privvy to information given to ARIN under NDA -- even the BoT isn't due to potential conflicts of interest. > It's no different than any other representative government. ARIN is certainly not a government but rather a Virginia non-stock corporation. > I think your probably not that familiar with how these sorts of > organizations operate? Openness rules the roost. Openness of process and policy, yes, but not of implementation necessarily. Try getting someone else's tax records or individual census records less than 70 years old. Some things are beyond FOIA's reach for a reason. >>For that matter, since the details are almost assuredly under NDA, >>we have no clue if staff has reviewed the practice and whether or >>not they've found it acceptable for reasons we're not privvy to. > > ARIN is required to abide by it's policies which call for, what is it, > 100% utilization? Per 4.3.2.4.1, each customer must meet 80% utilization; there is no indication if that's to be assessed per assignment or somehow averaged across all assignments to a given customer. Per 4.2.4.1, an LIR has to have "efficiently" utilized all prior allocations and at least 80% of the most recent one. Since there's no explicit definition given for "efficient", let's say that means "100% assigned". However, those assignments only need to be 80% utilized themselves. For end users getting direct assignments, 4.3.3 says they must be able to reach 50% utilization within a year, and 4.3.6 says 80% of all previous assignments, if any. > In other words, ARIN staff has no ability to give a group, whether > under NDA or not, a special exemption from the utilization > requirements unless such exemption is spelled out in policy. The wording in the policy is intentionally loose so that staff can make a reasonable assessment of the records they're given. It's entirely possible that there is technical justification showing that a /30 is not possible in the case you described. I can't imagine what it may be, but SBCGlobal must have a reason for doing it that way since it's unusual, and staff will review that reason when they come back for more space -- if they haven't already. > Which gets back to the original thrust of my response - the devil > is in the details. What is your definition of 100% utilization? > Mine certainly isn't an empty /8. I'm unaware of any "empty" /8s, though it's common belief that many are poorly utilized. I'm personally aware of plenty of "empty" /24s and a few "mostly empty" /16s. All are legacy. I've also heard someone claim they were aware of one or more non-legacy allocations which were originally justified but the company went under and one of the employees/owners kept paying the bill so they could retain the block (perhaps "empty" today) for future purposes. That does appear to be an RSA violation, but I don't know who the alleged offenders were/are; I can't even recall who made the claim. > I know you are certain in what you have seen. You must understand > that me saying what you have seen has to be considered mythical, > does not mean I personally disbelieve you have seen this. I am > just saying nobody can do anything about these since we don't know > who the abusers are. _We_ don't know, except for the "abusers" hiding among us. ARIN staff may know or, failing that, have the power to ask for that information, which they will most likely only get under NDA. All we can do is tell them (a) to go do it and (b) what they should do if/when they get the information (or don't). We might be able to deduce some of what they find from the end results, but we might not; either way we have to trust they're doing what policy and the BoT tells them to do. >>> By the time the law of diminishing returns acts on a reclamation >>> effort, the wasteful holders still out there who have so far ignored >>> the nice pleas aren't going to respond to anything other than >>> a threat. >> >>If they have ignored the "nice pleas", of course they won't respond >>to anything other than a threat. That doesn't mean we need to >>start working out what that threat may eventually be, or if we'll even >>use one, before we see how well the "nice pleas" work. > > It doesen't mean we shouldn't work out that threat now, either. The threat (to non-legacy folks) is clearly stated in section 8 of the RSA: "If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources, (ii) cease providing the Services to Applicant, and/or (iii) terminate this Agreement. " The LRSA's threat is a bit weaker, since it's only to stop providing services that ARIN is providing to legacy holders anyways even if they haven't signed the LRSA. The only threat remaining to discuss, then, is what (if anything) ARIN might do to folks that haven't signed either the RSA or the LRSA. >>OTOH, I bet we could recover 64k /24s for less in legal fees than >>a single /8; the folks with /8s have hundreds of lawyers each at >>their disposal with nothing better to do than sue annoyances like >>ARIN out of existance. > > Throwing hundreds of lawyers on a lawsuit does not change the > basic dispute or conflict. No, but it may change the outcome if you can bankrupt the other party through legal costs or business distruptions before the case is settled. Many lawsuits are filed _knowing_ the plaintiff would lose on merit, and many defendants that would win end up settling because it's cheaper. > That's why Erin Brockabitch won, and why there's tons of other > David vs Goliath court cases out there. The only thing that > helps is the quality of the lawyer you use, and ARIN has enough > money to hire lawyers that are every bit as good as the best > lawyers the other side has. ARIN, with annual revenues of a few million and a small operating reserve, would be unlikely withstand a determined legal assault by a dozen companies that each rake in billions per month. >>And if we go after one, the rest will counterattack to prevent a >>precedent being established that they don't like. > > "the rest" aren't going to spend a nickle on counterattacking. It's > like the old saw that they came for this guy and I didn't speak up, > they came for that guy and I didn't speak up, they came for this > other guy and I didn't speak up, now they are coming for me, darn, > I should have spoke up. Counterexample: Novell's actions related to SCO v. IBM. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking From schiller at uu.net Wed Oct 31 17:43:00 2007 From: schiller at uu.net (Jason Schiller) Date: Wed, 31 Oct 2007 16:43:00 -0500 (EST) Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728D600.6060903@internap.com> Message-ID: Ted Mittelstaedt wrote: > It's unlikely that if the routing > table grows past existing ISP equipment that it would result in > ISP bankruptcies. A far more likely scenario among the smaller > cash-poor ISP's is it will encourage single homing with the resultant > lowering of Internet reliability for customers of those ISPs. When routing slots become scarse we all will have the difficult decesion of which routes to install. It is my suspicion that ISPs will discard non-customer routes first before customer routes. The first set of routes likely to be discarded are non-customer routes that are a more specific of an aggregate. This will break TE. The next set of routes likely to be discarded are non-customer aggregates. At this point, a paying customer may complain that it cannot reach some non-customer destination. The ISP will explain that the destination in question is not a customer, and does not pay to have its route in the table. The ISP will then offer the option for his or her customer to pay to have the route in the table, or the destination can pay to thave their route in the ISp's table. Talk about net neutrality issues. On Wed, 31 Oct 2007, Scott Leibrand wrote: > Yeah, in practice ISP filtering is the only enforcement mechanism here. > However, as an earlier poster pointed out, ISPs currently have nothing > to point to if they want to tell their customers that announcing their > covering aggregates is the right thing to do. I think it would be > useful for ARIN to state that such behavior is expected, either in the > NRMP or the upcoming NPOG. It would be nice to have a NPOG to reference to try and persuade people to do the right thing. On Wed, 31 Oct 2007, Scott Leibrand wrote: > I don't think that's true. Today, anything you advertise in IPv4 down > to a /24 will be accepted more or less by everyone. However, that's > only a convenience for optimal TE. In order to just maintain > reachability, all you really need is for your upstreams (all your > transit providers and all their transit providers) to accept your > deaggregated routes from you and from each other. The rest of the world > need only accept the RIR-assignment-size covering aggregate, route the > traffic toward one of your transit providers, and then let the > more-specifics take over when they hand the traffic off to them. For large ISPs with widespread peeing, and lots of mult-homed customer overlap, this basiclly means they need to carry nearly all of the routes. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. From sleibrand at internap.com Wed Oct 31 18:01:11 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 15:01:11 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: Message-ID: <4728FB27.8090704@internap.com> Jason Schiller wrote: > > When routing slots become scarse we all will have the difficult decesion > of which routes to install. > > It is my suspicion that ISPs will discard non-customer routes first before > customer routes. The first set of routes likely to be discarded are > non-customer routes that are a more specific of an aggregate. This will > break TE. Yes, it will *partially* break TE. I maintain that the vast majority of the TE benefit remains, however, via more-specific announcements to your upstreams, localpref communities, and AS path prepends. > The next set of routes likely to be discarded are non-customer > aggregates. > > At this point, a paying customer may complain that it cannot reach some > non-customer destination. The ISP will explain that the destination in > question is not a customer, and does not pay to have its route in the > table. The ISP will then offer the option for his or her customer to pay > to have the route in the table, or the destination can pay to thave their > route in the ISp's table. Talk about net neutrality issues. > I think there's a less messy alternative to going this far, which I have attempted to outline in other messages & threads. > On Wed, 31 Oct 2007, Scott Leibrand wrote: >> I don't think that's true. Today, anything you advertise in IPv4 down >> to a /24 will be accepted more or less by everyone. However, that's >> only a convenience for optimal TE. In order to just maintain >> reachability, all you really need is for your upstreams (all your >> transit providers and all their transit providers) to accept your >> deaggregated routes from you and from each other. The rest of the world >> need only accept the RIR-assignment-size covering aggregate, route the >> traffic toward one of your transit providers, and then let the >> more-specifics take over when they hand the traffic off to them. >> > > For large ISPs with widespread peeing, and lots of mult-homed customer > overlap, this basiclly means they need to carry nearly all of the routes. > Perhaps you could help us understand the magnitude of the difference a little better with some actual statistics, if you could share them. Of the /23 and /24 routes in your table (excluding class C swamp space), how many (and what percentage) are non-customer routes? My intuition / hypothesis would be that the non-customer routes outnumber the customer routes, so you would still get significant benefit from filtering the non-customer more-specifics if we come to a routing-table-size crunch. Thanks, Scott From tedm at ipinc.net Wed Oct 31 18:09:23 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 31 Oct 2007 15:09:23 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: Message-ID: >-----Original Message----- >From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of >Jason Schiller >Sent: Wednesday, October 31, 2007 2:43 PM >To: Scott Leibrand >Cc: ppml at arin.net >Subject: Re: [ppml] Effects of explosive routing table growth on ISP >behavior > > >Ted Mittelstaedt wrote: >> It's unlikely that if the routing >> table grows past existing ISP equipment that it would result in >> ISP bankruptcies. A far more likely scenario among the smaller >> cash-poor ISP's is it will encourage single homing with the resultant >> lowering of Internet reliability for customers of those ISPs. > >When routing slots become scarse we all will have the difficult decesion >of which routes to install. > >It is my suspicion that ISPs will discard non-customer routes first before >customer routes. The first set of routes likely to be discarded are >non-customer routes that are a more specific of an aggregate. This will >break TE. The next set of routes likely to be discarded are non-customer >aggregates. > >At this point, a paying customer may complain that it cannot reach some >non-customer destination. The ISP will explain that the destination in >question is not a customer, and does not pay to have its route in the >table. The ISP will then offer the option for his or her customer to pay >to have the route in the table, or the destination can pay to thave their >route in the ISp's table. My guess is if this kind of thing ever came to pass you would see some kind of "dynamic filtering" come into place. In other words, the ISP's BGP peer router would look at ALL inbound and outbound traffic that passes through it, and automatically modify the filter to allow the route into the table for any source or destination of any packet going through the router. You would set the expiration of the "hole" in the filter to be proportional to the number and size of the packets and how long they were coming through the hole. Oh dear, I've probably done gone and screwed up someone's patent application. But I still think that a lot of this is chicken little stuff. Think of how many credit card numbers there are in the world, and how any of them could suddenly appear at some card swipe machine anywhere in the world, yet the global banking community seems to be able to handle this just fine. The hardware exists to do that, it can be built to do this. Ted From sleibrand at internap.com Wed Oct 31 18:25:05 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 15:25:05 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: Message-ID: <472900C1.1040601@internap.com> Ted Mittelstaedt wrote: > > My guess is if this kind of thing ever came to pass you would see some > kind of "dynamic filtering" come into place. In other words, the ISP's > BGP peer router would look at ALL inbound and outbound traffic that > passes through it, and automatically modify the filter to allow the > route into the table for any source or destination of any packet going > through the router. You would set the expiration of the "hole" in the > filter to be proportional to the number and size of the packets and > how long they were coming through the hole. > > Oh dear, I've probably done gone and screwed up someone's patent > application. > Agreed. I've asked my router vendors for such features from time to time. Yet more prior art. :-) > But I still think that a lot of this is chicken little stuff. Think > of how many credit card numbers there are in the world, and how any > of them could suddenly appear at some card swipe machine anywhere in > the world, yet the global banking community seems to be able to > handle this just fine. The hardware exists to do that, it can be built > to do this. Agreed. However, doesn't dynamic filtering rely on having a less-specific covering route, so you can at least route whatever packets come in until you get enough of them to start accepting more-specifics? I'm not worried that the routing table will explode unexpectedly, but I am worried about implementing policies (such as allowing transfers of /24s at the RIR level) that are incompatible with the kind of filtering that would be needed to deal with a rapid routing table expansion. -Scott From schiller at uu.net Wed Oct 31 18:33:56 2007 From: schiller at uu.net (Jason Schiller) Date: Wed, 31 Oct 2007 17:33:56 -0500 (EST) Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: <4728FB27.8090704@internap.com> Message-ID: On Wed, 31 Oct 2007, Scott Leibrand wrote: > > It is my suspicion that ISPs will discard non-customer routes first before > > customer routes. The first set of routes likely to be discarded are > > non-customer routes that are a more specific of an aggregate. This will > > break TE. > Yes, it will *partially* break TE. I maintain that the vast majority of > the TE benefit remains, however, via more-specific announcements to your > upstreams, localpref communities, and AS path prepends. > > > For large ISPs with widespread peeing, and lots of mult-homed customer > > overlap, this basiclly means they need to carry nearly all of the routes. > > > > Perhaps you could help us understand the magnitude of the difference a > little better with some actual statistics, if you could share them. Of > the /23 and /24 routes in your table (excluding class C swamp space), > how many (and what percentage) are non-customer routes? My intuition / > hypothesis would be that the non-customer routes outnumber the customer > routes, so you would still get significant benefit from filtering the > non-customer more-specifics if we come to a routing-table-size crunch. > I am not authorized to share specific numbers. However, currently the Internet table is 241,847 A large ISP has between 50-150K internal routes. In the not so distant past, UUNET had more internal routes than Internet routes, but some agressive renumbering of our dial-up customers helped quite a bit. In short the number of Internal more specifics is very significant. If my customers want shortest path forwarding (as determined by BGP path selection) to destinations on the Internet than I need to carry are the multi-homed more specifics of all of my direct Peers. That will not reduce my tables by much. From sleibrand at internap.com Wed Oct 31 18:46:43 2007 From: sleibrand at internap.com (Scott Leibrand) Date: Wed, 31 Oct 2007 15:46:43 -0700 Subject: [ppml] Effects of explosive routing table growth on ISP behavior In-Reply-To: References: Message-ID: <472905D3.6080100@internap.com> Jason Schiller wrote: > On Wed, 31 Oct 2007, Scott Leibrand wrote: > > >>> For large ISPs with widespread peeing, and lots of mult-homed customer >>> overlap, this basiclly means they need to carry nearly all of the routes. >>> >>> >> Perhaps you could help us understand the magnitude of the difference a >> little better with some actual statistics, if you could share them. Of >> the /23 and /24 routes in your table (excluding class C swamp space), >> how many (and what percentage) are non-customer routes? My intuition / >> hypothesis would be that the non-customer routes outnumber the customer >> routes, so you would still get significant benefit from filtering the >> non-customer more-specifics if we come to a routing-table-size crunch. >> >> > I am not authorized to share specific numbers. Fair enough. > If my customers want shortest path forwarding (as determined by BGP path > selection) to destinations on the Internet than I need to carry are the > multi-homed more specifics of all of my direct Peers. That will not > reduce my tables by much. Yes, and today you and your customers value shortest path forwarding more than a smaller BGP table, with good reason. However, if the BGP table were to grow, wouldn't it be better for you and your customers to relax the requirement for shortest path forwarding rather than drop reachability altogether? While my customers might complain once in a while that their traceroute goes through a few extra hops and adds a few ms of latency, they get extremely upset if they lose reachability to a destination entirely. -Scott From tedm at ipinc.net Wed Oct 31 19:00:40 2007 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 31 Oct 2007 16:00:40 -0700 Subject: [ppml] IPv6 assignment - proposal for change to nrpm In-Reply-To: <03b201c81c06$7dd917a0$473816ac@atlanta.polycom.com> Message-ID: >-----Original Message----- >From: Stephen Sprunk [mailto:stephen at sprunk.org] >Sent: Wednesday, October 31, 2007 2:10 PM >To: Ted Mittelstaedt >Cc: ARIN PPML >Subject: Re: [ppml] IPv6 assignment - proposal for change to nrpm > > >Thus spake "Ted Mittelstaedt" >>>>>I've seen plenty of horrifying examples, though NDAs prevent me >>>>>from naming names. >>>> >>>> Please don't say stuff like that, it is just a bunch of straw men. >>>> We do not sign NDAs with any customers we do service work >>>> for, (none have asked) >>> >>>Lucky you. I'm under NDA to that (past) employer, and that >>>employer is under NDA to those customers; my NDA bound me to >>>their NDAs. I've asked, and I'm not even allowed to say who those >>>customers are, and certainly not details of their internal networks. >>>Even on my own, I've never done consulting work for any company >>>that _didn't_ demand an NDA, nor have I been employed by a >>>company that didn't since I was worked retail as a teenager. >> >> Any contract that obligates you to conceal something illegal is >> unenforceable. > >If I had been aware of someone committing a crime, I would have contacted >the appropriate law enforcement agency. AFAIK, no laws were >broken. There >was no fraud, for example, since they never represented that their >utilization _was_ efficient to anyone -- and it so obviously wasn't that >nobody would even attempt to claim such. > >>>For that matter, a substantial fraction of legacy assignments are >>>to defense contractors, who have parts of their network that are >>>not only under NDA but classified. ARIN can't get details about >>>those networks, since AFAIK they have no staff with the appropriate >>>clearances, and no court can order disclosure. Even employees >>>in the "white" parts of those companies often have no clue what >>>the "black" parts look like. >> >> That is a different deal. However, those classifications only hold true >> in the US. If I am not a US citizen and I live outside the US I can talk >> publically about any US DoD classified things I feel like. > >The only non-citizens outside the US which _should_ be able to get such >information in the first place will be under similar laws from their own >government. Of course. >If anyone else obtained DoD classified information, someone >with a clearance illegally gave it to them There have been lots of security breaches - Lawrence Livermore Lab just lost a backup tape or laptop or some such a couple months back for example - no need for someone with a clearance to actually make an effort to give out classified info. >and they'll likely end up in a >deep, dark hole. Valerie Plame? >Depending on how sensitive the information is, >the USG may >perform a "rendition" and bring the unauthorized person to US soil for >detention. correction - TRY TO bring the person to US soil for detention. >In case you missed it, in the 80s Congress asserted worldwide >jurisdiction and enforcement of its laws -- including over non-US citizens >on non-US soil. Since victims don't usually get trials or press coverage, >we have no clue how often it happens. > Yep, there's standing orders to detain all members of the DeBeers family for questioning on violations of the Sherman-anti-trust act for price fixing in the diamond industry. I think those were issued sometime in the 70's Needless to say, none of the DeBeers visit the US Almost certainly if any US citizen who published specs of, say, Israel's military arms were to travel to Israel, they would similarly find themselves in very uncomfortable quarters. There's lots of that data out there, by the way. >>>> A holder like SBC Global who is under RSA is arguably violating >>>> their contract with ARIN by assigning an overage of IP addresses >>>> to customers that the customers aren't asking for, in an effort to >>>> hoard IPs. >>> >>>That's a matter for ARIN's counsel and/or staff, not us. >> >> ARIN's policy is set by us, we elect ARIN officers, this is definitely >> a matter for us. > >No, it is not. If you are unhappy with the actions of ARIN's board and >you're a member, you can vote for different candidates. That's where your >control ends. Only ARIN's employees and counsel are privvy to information >given to ARIN under NDA I didn't say NDA I said RSA, two different things. I signed no NDA with SBCGlobal, so your claim that that example is only a matter for ARIN staff due to some specious NDA isn't true. > -- even the BoT isn't due to potential >conflicts of >interest. > >> It's no different than any other representative government. > >ARIN is certainly not a government but rather a Virginia non-stock >corporation. > >> I think your probably not that familiar with how these sorts of >> organizations operate? Openness rules the roost. > >Openness of process and policy, yes, but not of implementation >necessarily. >Try getting someone else's tax records or individual census records less >than 70 years old. Some things are beyond FOIA's reach for a reason. > "implementation necessairly" covers quite a bit of ground. Sure, competitive information like customer data and suchlike that is given to an RIR must remain confined to the RIR. There's plenty of moral and legal reason for that to happen. But to try to construe this to cover up someone's embarassment of not playing by the rules, that is wrong and there is no reason for it. Currently there's enough different orgs assigned IPv4 that clearly there are no vast caches of unused IPv4. Even those possibly-mythical /8's are small potatoes in the grand scheme of things, as they would hardly push the date of IPv4 runout more than a few years out. So, much of this is merely theoretical discussion. But, if there WERE large caches of IPv4 not being used out there that would possibly extend runout date out for another 20 years - then I think it would make it blindingly clear to you how much an org's utilization efficiency is everyone's concern. >>>For that matter, since the details are almost assuredly under NDA, >>>we have no clue if staff has reviewed the practice and whether or >>>not they've found it acceptable for reasons we're not privvy to. >> >> ARIN is required to abide by it's policies which call for, what is it, >> 100% utilization? > >Per 4.3.2.4.1, each customer must meet 80% utilization; there is no >indication if that's to be assessed per assignment or somehow averaged >across all assignments to a given customer. > >Per 4.2.4.1, an LIR has to have "efficiently" utilized all prior >allocations >and at least 80% of the most recent one. Since there's no explicit >definition given for "efficient", let's say that means "100% assigned". >However, those assignments only need to be 80% utilized themselves. > >For end users getting direct assignments, 4.3.3 says they must be able to >reach 50% utilization within a year, and 4.3.6 says 80% of all previous >assignments, if any. > >> In other words, ARIN staff has no ability to give a group, whether >> under NDA or not, a special exemption from the utilization >> requirements unless such exemption is spelled out in policy. > >The wording in the policy is intentionally loose so that staff can make a >reasonable assessment of the records they're given. It's entirely >possible >that there is technical justification showing that a /30 is not >possible in >the case you described. I can't imagine what it may be, but >SBCGlobal must >have a reason for doing it that way since it's unusual, and staff will >review that reason when they come back for more space -- if they haven't >already. > Why do you fight Occams razor on this? Obviously there is no technical justification, it is merely padding because a /29 can be assigned to a customer without complaint from the RIR. >> Which gets back to the original thrust of my response - the devil >> is in the details. What is your definition of 100% utilization? >> Mine certainly isn't an empty /8. > >I'm unaware of any "empty" /8s, though it's common belief that many are >poorly utilized. I'm personally aware of plenty of "empty" /24s and a few >"mostly empty" /16s. All are legacy. > >I've also heard someone claim they were aware of one or more non-legacy >allocations which were originally justified but the company went under and >one of the employees/owners kept paying the bill so they could retain the >block (perhaps "empty" today) for future purposes. That does appear to be >an RSA violation, but I don't know who the alleged offenders were/are; I >can't even recall who made the claim. > >> I know you are certain in what you have seen. You must understand >> that me saying what you have seen has to be considered mythical, >> does not mean I personally disbelieve you have seen this. I am >> just saying nobody can do anything about these since we don't know >> who the abusers are. > >_We_ don't know, except for the "abusers" hiding among us. ARIN staff may >know or, failing that, have the power to ask for that information, which >they will most likely only get under NDA. All we can do is tell >them (a) to >go do it and (b) what they should do if/when they get the information (or >don't). We might be able to deduce some of what they find from the end >results, but we might not; either way we have to trust they're doing what >policy and the BoT tells them to do. > Except as far as I know the policy isn't telling ARIN to go out there and spend money beating the bushes trying to do IPv4 reclamation. So for them to do it we need to tell it to them, and which leads back to the beginning of the discussion which is what to tell them? >>>> By the time the law of diminishing returns acts on a reclamation >>>> effort, the wasteful holders still out there who have so far ignored >>>> the nice pleas aren't going to respond to anything other than >>>> a threat. >>> >>>If they have ignored the "nice pleas", of course they won't respond >>>to anything other than a threat. That doesn't mean we need to >>>start working out what that threat may eventually be, or if we'll even >>>use one, before we see how well the "nice pleas" work. >> >> It doesen't mean we shouldn't work out that threat now, either. > >The threat (to non-legacy folks) is clearly stated in section 8 of >the RSA: >"If ARIN determines that the number resources or any other >Services are not >being used in compliance with this Agreement, the Policies, or the >purposes >for which they are intended, ARIN may: (i) revoke the number >resources, (ii) >cease providing the Services to Applicant, and/or (iii) terminate this >Agreement. " > >The LRSA's threat is a bit weaker, since it's only to stop providing >services that ARIN is providing to legacy holders anyways even if they >haven't signed the LRSA. > >The only threat remaining to discuss, then, is what (if anything) >ARIN might >do to folks that haven't signed either the RSA or the LRSA. > No, there is also to discuss whether ARIN is "determining that the number resources are being used in compliance" What evidence do you see that they are, other than for new assignment requests? >>>OTOH, I bet we could recover 64k /24s for less in legal fees than >>>a single /8; the folks with /8s have hundreds of lawyers each at >>>their disposal with nothing better to do than sue annoyances like >>>ARIN out of existance. >> >> Throwing hundreds of lawyers on a lawsuit does not change the >> basic dispute or conflict. > >No, but it may change the outcome if you can bankrupt the other party >through legal costs or business distruptions before the case is settled. >Many lawsuits are filed _knowing_ the plaintiff would lose on merit, and >many defendants that would win end up settling because it's cheaper. > >> That's why Erin Brockabitch won, and why there's tons of other >> David vs Goliath court cases out there. The only thing that >> helps is the quality of the lawyer you use, and ARIN has enough >> money to hire lawyers that are every bit as good as the best >> lawyers the other side has. > >ARIN, with annual revenues of a few million and a small operating reserve, >would be unlikely withstand a determined legal assault by a dozen >companies >that each rake in billions per month. > That isn't true. It would depend greatly on the nature of the dispute. If ARIN didn't have all it's ducks in line, then things would go bad for them. But if they did, then they would win and the countersuit would be very lucrative. But even if they lost, then so what? They can't go out of business as they have a guarenteed source of revenue - and if a winning company were to somehow gut ARIN and make it stop doing what it's doing, then everyone would stop paying and allow their allocations to revert back to ARIN, and you would have a free-for-all in which now the very assetss that these dozen companies were suing over would be subject to poaching and all kinds of stuff. ARIN is a goose and the numbering are the golden eggs, and if you kill it, you kill the RIR system and thus the Internet. The ONLY reason a single company would file a lawsuit against ARIN is to benefit -themselves only- because otherwise it makes no sense at all. >>>And if we go after one, the rest will counterattack to prevent a >>>precedent being established that they don't like. >> >> "the rest" aren't going to spend a nickle on counterattacking. It's >> like the old saw that they came for this guy and I didn't speak up, >> they came for that guy and I didn't speak up, they came for this >> other guy and I didn't speak up, now they are coming for me, darn, >> I should have spoke up. > >Counterexample: Novell's actions related to SCO v. IBM. > Ah - but, SCO was -wrong- in the beginning and everyone knew that, even I am sure, SCO. Otherwise they would have posted the actual sections of the offending code as they were called on to do hundreds of times. Your also assuming that the SCO lawsuit was intended to win, rather than what it actually was intended to be - namely, a diversion to the stockholders so the exec staff of SCO had enough time to bleed the company dry before the stockholders realized they were pulling their pants down. Ted