From cblecker at gmail.com Mon Apr 1 13:43:31 2013 From: cblecker at gmail.com (Christoph Blecker) Date: Mon, 1 Apr 2013 10:43:31 -0700 Subject: [arin-ppml] fee structure In-Reply-To: References: <5154D944.3070109@quark.net> <1754242843.68144.1364515558984.JavaMail.root@network1.net> <8DA1853CE466B041B104C1CAEE00B3748FA72499@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD239FC6C@SUEX10-mbx-10.ad.syr.edu> <8DA1853CE466B041B104C1CAEE00B3748FA83B45@CHAXCH01.corp.arin.net> <58A570A5-A0BE-4452-967A-29C606E89520@delong.com> <8DA1853CE466B041B104C1CAEE00B3748FA8D642@CHAXCH01.corp.arin.net> Message-ID: On Sun, Mar 31, 2013 at 6:54 PM, William Herrin wrote: > On Mar 31, 2013 7:11 AM, "John Curran" wrote: > > On Mar 31, 2013, at 4:20 AM, Owen DeLong wrote: > > >> No, it is not a "speed bump" but simply a choice available to > end-users; > > >> having an equal voice includes taking on some equal responsibility. > > > > > > In that case, shouldn't we get $100 off of our membership for each > resource > > > record subject to the $100 fee? > > > > The revised fee schedule did not change the ARIN membership fee, > > but as a result of this topic being discussed on ppml and as noted > > earlier, I will bring up this topic (of the most appropriate fee > > for membership) to the ARIN Board for their consideration. > > Hi John, > > When you do, I second Owen's notion that the end user membership fee > should not exceed the difference between that end user's annual fees and > the minimum annual fee for an ISP member. > > I'm not wed to the idea that an ISP paying a total of $500/year should > automatically be an ARIN member. But if they are, an end-user paying a > total of $500/year should be too. > > -Bill > > Thoughts: If the $500/year membership fee to end users is to offset the costs of governing ARIN and ensuring that the electorate is interested in participating, why isn't this extra membership fee charged to ISPs? Why would ISPs be assumed to be more or less interested then end users? Are there any statistics available on how many ISPs actually exercise their vote? Is the difference in treatment simply because ISPs already pay so much, why charge them more? I support a review of the $500/year fee structure. I believe that whatever the direction taken (offset by fees, or what have you), that the voting playing field should be equal between all users of ARIN resources. Cheers, Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From adudek16 at gmail.com Mon Apr 1 14:56:45 2013 From: adudek16 at gmail.com (Aaron Dudek) Date: Mon, 1 Apr 2013 14:56:45 -0400 Subject: [arin-ppml] fee structure In-Reply-To: References: <5154D944.3070109@quark.net> <1754242843.68144.1364515558984.JavaMail.root@network1.net> <8DA1853CE466B041B104C1CAEE00B3748FA72499@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD239FC6C@SUEX10-mbx-10.ad.syr.edu> <8DA1853CE466B041B104C1CAEE00B3748FA83B45@CHAXCH01.corp.arin.net> <58A570A5-A0BE-4452-967A-29C606E89520@delong.com> <8DA1853CE466B041B104C1CAEE00B3748FA8D642@CHAXCH01.corp.arin.net> Message-ID: It is already in their dues iirc On Monday, April 1, 2013, Christoph Blecker wrote: > On Sun, Mar 31, 2013 at 6:54 PM, William Herrin > > wrote: > >> On Mar 31, 2013 7:11 AM, "John Curran" > >> wrote: >> > On Mar 31, 2013, at 4:20 AM, Owen DeLong > >> wrote: >> > >> No, it is not a "speed bump" but simply a choice available to >> end-users; >> > >> having an equal voice includes taking on some equal responsibility. >> > > >> > > In that case, shouldn't we get $100 off of our membership for each >> resource >> > > record subject to the $100 fee? >> > >> > The revised fee schedule did not change the ARIN membership fee, >> > but as a result of this topic being discussed on ppml and as noted >> > earlier, I will bring up this topic (of the most appropriate fee >> > for membership) to the ARIN Board for their consideration. >> >> Hi John, >> >> When you do, I second Owen's notion that the end user membership fee >> should not exceed the difference between that end user's annual fees and >> the minimum annual fee for an ISP member. >> >> I'm not wed to the idea that an ISP paying a total of $500/year should >> automatically be an ARIN member. But if they are, an end-user paying a >> total of $500/year should be too. >> >> -Bill >> >> > Thoughts: If the $500/year membership fee to end users is to offset the > costs of governing ARIN and ensuring that the electorate is interested in > participating, why isn't this extra membership fee charged to ISPs? Why > would ISPs be assumed to be more or less interested then end users? Are > there any statistics available on how many ISPs actually exercise their > vote? Is the difference in treatment simply because ISPs already pay so > much, why charge them more? > > I support a review of the $500/year fee structure. I believe that whatever > the direction taken (offset by fees, or what have you), that the voting > playing field should be equal between all users of ARIN resources. > > Cheers, > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Apr 1 16:09:56 2013 From: jcurran at arin.net (John Curran) Date: Mon, 1 Apr 2013 20:09:56 +0000 Subject: [arin-ppml] fee structure In-Reply-To: References: <5154D944.3070109@quark.net> <1754242843.68144.1364515558984.JavaMail.root@network1.net> <8DA1853CE466B041B104C1CAEE00B3748FA72499@CHAXCH01.corp.arin.net> <855077AC3D7A7147A7570370CA01ECD239FC6C@SUEX10-mbx-10.ad.syr.edu> <8DA1853CE466B041B104C1CAEE00B3748FA83B45@CHAXCH01.corp.arin.net> <58A570A5-A0BE-4452-967A-29C606E89520@delong.com> <8DA1853CE466B041B104C1CAEE00B3748FA8D642@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAAD97C@CHAXCH01.corp.arin.net> On Apr 1, 2013, at 2:56 PM, Aaron Dudek wrote: > It is already in their dues iirc Correct. Prior to this revision in fees, the smallest amount that any ISP would have been paying was $1250/year, and that's been considered more than sufficient to include the approximately $250 per member for ARIN's non-registry organizational costs. With the lowest ISP annual fee (for xx-small) now being $500, this topic does seem worth reviewing to make sure it is still fair compared to the fee for end-users to be members. Thanks! /John John Curran President and CEO ARIn From farmer at umn.edu Tue Apr 2 19:24:30 2013 From: farmer at umn.edu (David Farmer) Date: Tue, 02 Apr 2013 18:24:30 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <23347.1364416515@sandelman.ca> <8DA1853CE466B041B104C1CAEE00B3748FA55224@CHAXCH01.corp.arin.net> <54710B7F-0F46-42E3-992F-E225470619A2@delong.com> <8DA1853CE466B041B104C1CAEE00B3748FA5578A@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA567A1@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA6C2D0@CHAXCH01.corp.arin.net> <5154BAB1.3070002@umn.edu> <5154EA18.6010905@umn.edu> <5155E1CD.1090003@umn.edu> <8DA1853CE466B041B104C1CAEE00B3748FA75A20@CHAXCH01.corp.arin.net> <51560153.9080908@umn.edu> Message-ID: <515B68AE.4080906@umn.edu> On 3/30/13 18:06 , Brandon Ross wrote: > On Fri, 29 Mar 2013, David Farmer wrote: > >> After thinking about it for a while, if we even need any policy at >> all, we should just have a general policy describing how IPv6 block >> can be reduced by returning only part of a block, it should probably >> be very generic and apply to allocations and end user assignments. It >> might even be better if it we a separate proposal all together. > > Agreed, which is why the language in this proposal allows for that, and > that was done on purpose. > > I don't want to see that separated to a separate policy proposal because > it is critical to making this one function as intended. Well, yes and no, John has already fix the operational issue, the only effect your proposed text would have at the moment would be to restrict it to the first or last blocks of the larger original block. This raise a question for me do we really need to restrict it to the first or last blocks? Personal, I'm ok with allowing the person making the return to have the flexibility to make choice of any contiguous and alined /40 out of the /32 they want. Next, I'm thinking about a new subsection; 6.12 Reduction or Return Organizations may return all or part of their allocations or assignments, that are not in use, to ARIN at any time with the following considerations; a. Such a return or reduction must not result in a larger number of blocks being held by an organization, if possible fewer blocks are preferred. b. If a whole block is not in use, the whole block should be returned to ARIN. c. If part of a block is returned; A single contiguous nibble alined block, no smaller than the applicable minimum block size allowed by policy, should be selected and retained by the organization. The remainder of the original block must not be in use and must be returned to ARIN. It is possible for multiple separate blocks to be retained from a single original block as long as clause (a) above is also meet. This is very generic covering both ISP/LIR allocations and end user assignments. The basic concept is that returns can't create additional block that will negatively impact aggregation. And with partial returns the retained portion must be a nibble alined and no smaller than policy allows. Also, related to this I'd like to delete section 6.5.8.4 "Consolidation and return of separate assignments", delete the last sentence of 6.5.3 clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space management"; 6.3.9 Consolidation and return Some organization will have multiple IPv6 blocks, obtained through subsequent allocations or assignments where an existing block could not be sufficiently expanded, or through transfers (mergers and acquisitions). Such organizations should consider consolidating to a single block, or at least minimizing the number of blocks used for new sub-assignments. This should not be considered a recommendation for large-scale active renumbering out of blocks at are in use. To the contrary, such consolidation is merely a goal and would likely occur over several years. Further, it should primarily be achieved through attrition and other normal operational change. Finally, return of a block is expected once it is no longer in active use. Moving the issue of consolidation to goals cleans up the subsequent allocation and assignment sections. It is intended to provide goals, motivation and some direction regarding why someone might want to return addresses. Putting it in the goals section prevents it from being confused with the issues of making subsequent allocations and assignments or the new Reduction or Return section above. This is why I was thinking about a separate proposal, because I think the consolidation issue is more closely linked to the return and reduction section than with the x-small and xx-small fee category issues. What do others think? -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen at delong.com Tue Apr 2 20:58:02 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Apr 2013 17:58:02 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515B68AE.4080906@umn.edu> References: <5153387E.6060700@arin.net> <23347.1364416515@sandelman.ca> <8DA1853CE466B041B104C1CAEE00B3748FA55224@CHAXCH01.corp.arin.net> <54710B7F-0F46-42E3-992F-E225470619A2@delong.com> <8DA1853CE466B041B104C1CAEE00B3748FA5578A@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA567A1@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA6C2D0@CHAXCH01.corp.arin.net> <5154BAB1.3070002@umn.edu> <5154EA18.6010905@umn.edu> <5155E1CD.1090003@umn.edu> <8DA1853CE466B041B104C1CAEE00B3748FA75A20@CHAXCH01.corp.arin.net> <51560153.9080908@umn.edu> <515B68AE.4080906@umn.edu> Message-ID: <0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551@delong.com> On Apr 2, 2013, at 16:24 , David Farmer wrote: > On 3/30/13 18:06 , Brandon Ross wrote: >> On Fri, 29 Mar 2013, David Farmer wrote: >> >>> After thinking about it for a while, if we even need any policy at >>> all, we should just have a general policy describing how IPv6 block >>> can be reduced by returning only part of a block, it should probably >>> be very generic and apply to allocations and end user assignments. It >>> might even be better if it we a separate proposal all together. >> >> Agreed, which is why the language in this proposal allows for that, and >> that was done on purpose. >> >> I don't want to see that separated to a separate policy proposal because >> it is critical to making this one function as intended. > > Well, yes and no, John has already fix the operational issue, the only effect your proposed text would have at the moment would be to restrict it to the first or last blocks of the larger original block. > > This raise a question for me do we really need to restrict it to the first or last blocks? Personal, I'm ok with allowing the person making the return to have the flexibility to make choice of any contiguous and alined /40 out of the /32 they want.j Since we're holding (at least) the /32 in reserve for them anyway and ideally the /28, I really don't think it matters which /40 they're using. > > Next, I'm thinking about a new subsection; > > 6.12 Reduction or Return > > Organizations may return all or part of their allocations or > assignments, that are not in use, to ARIN at any time with the > following considerations; > > a. Such a return or reduction must not result in a larger number of > blocks being held by an organization, if possible fewer blocks > are preferred. > > b. If a whole block is not in use, the whole block should be > returned to ARIN. > > c. If part of a block is returned; A single contiguous nibble > alined block, no smaller than the applicable minimum block size > allowed by policy, should be selected and retained by the > organization. The remainder of the original block must not be > in use and must be returned to ARIN. It is possible for > multiple separate blocks to be retained from a single original > block as long as clause (a) above is also meet. I think this vastly overcomplicates what should be relatively simple... How about this: 6.12 Reduction or Return ARIN will accept any return which allows an LIR to reduce their holdings to fit a lower tier in the fee schedule so long as: 1. The end result is not an increase in the number of non-contiguous blocks held by the LIR. 2. Whole blocks are returned to the extent practicable. 3. Retained block(s) are within the largest reserved space set aside for the LIR in the ARIN database to the extent practicable. I think it is better to express directly what it is that we want to happen in general terms and trust that ARIN and the LIRs will generally find a way to do the right thing so long as we do not prevent them from doing so. > Also, related to this I'd like to delete section 6.5.8.4 "Consolidation and return of separate assignments", delete the last sentence of 6.5.3 clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space management"; > > 6.3.9 Consolidation and return > > Some organization will have multiple IPv6 blocks, obtained through > subsequent allocations or assignments where an existing block could > not be sufficiently expanded, or through transfers (mergers and > acquisitions). Such organizations should consider consolidating to > a single block, or at least minimizing the number of blocks used > for new sub-assignments. This should not be considered a > recommendation for large-scale active renumbering out of blocks at > are in use. To the contrary, such consolidation is merely a goal > and would likely occur over several years. Further, it should > primarily be achieved through attrition and other normal > operational change. Finally, return of a block is expected once it > is no longer in active use. I think this is unnecessary and that the concerns driving this can be better addressed through improved operational practice. Owen From farmer at umn.edu Wed Apr 3 00:59:44 2013 From: farmer at umn.edu (David Farmer) Date: Tue, 02 Apr 2013 23:59:44 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551@delong.com> References: <5153387E.6060700@arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA55224@CHAXCH01.corp.arin.net> <54710B7F-0F46-42E3-992F-E225470619A2@delong.com> <8DA1853CE466B041B104C1CAEE00B3748FA5578A@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA567A1@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA6C2D0@CHAXCH01.corp.arin.net> <5154BAB1.3070002@umn.edu> <5154EA18.6010905@umn.edu> <5155E1CD.1090003@umn.edu> <8DA1853CE466B041B104C1CAEE00B3748FA75A20@CHAXCH01.corp.arin.net> <51560153.9080908@umn.edu> <515B68AE.4080906@umn.edu> <0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551@delong.com> Message-ID: <515BB740.3000602@umn.edu> On 4/2/13 19:58 , Owen DeLong wrote: > On Apr 2, 2013, at 16:24 , David Farmer wrote: >> Next, I'm thinking about a new subsection; >> >> 6.12 Reduction or Return >> >> Organizations may return all or part of their allocations or >> assignments, that are not in use, to ARIN at any time with the >> following considerations; >> >> a. Such a return or reduction must not result in a larger number of >> blocks being held by an organization, if possible fewer blocks >> are preferred. >> >> b. If a whole block is not in use, the whole block should be >> returned to ARIN. >> >> c. If part of a block is returned; A single contiguous nibble >> alined block, no smaller than the applicable minimum block size >> allowed by policy, should be selected and retained by the >> organization. The remainder of the original block must not be >> in use and must be returned to ARIN. It is possible for >> multiple separate blocks to be retained from a single original >> block as long as clause (a) above is also meet. > > I think this vastly overcomplicates what should be relatively simple... > > How about this: > > 6.12 Reduction or Return > > ARIN will accept any return which allows an LIR to reduce their > holdings to fit a lower tier in the fee schedule so long as: > > 1. The end result is not an increase in the number of > non-contiguous blocks held by the LIR. > > 2. Whole blocks are returned to the extent practicable. > > 3. Retained block(s) are within the largest reserved space > set aside for the LIR in the ARIN database to the extent > practicable. > > I think it is better to express directly what it is that we want to happen > in general terms and trust that ARIN and the LIRs will generally find > a way to do the right thing so long as we do not prevent them from > doing so. First, my intent was to use "organization" rather than "LIR" as I wanted it to be general and apply to both LIRs and end users, that is also why I moved it out to 6.12. Do you believe only LIR might wnat to reduce their holdings? You were advocating that end user annual fee be scaled to holding too, do you want to change the policy when that happens? Let keep it general and use "organization" Second, in your #3, what do the retained block(s) have to do with the reserved space? The retained block(s) are the block(s) kept by the organization and the reserved space is an ARIN operational issue. I believe we want the retained block(s) nibble aligned and no smaller than allowed by policy, /40 for an LIR and /48 for an end user. However, it would be better not to specify the minimums and get as a reference to applicable policy. Do you want to allow non-nibble alined blocks to be retained? If you do then why not just allocate them in the first place. Or, am I missing something? -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen at delong.com Wed Apr 3 01:08:35 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 2 Apr 2013 22:08:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515BB740.3000602@umn.edu> References: <5153387E.6060700@arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA55224@CHAXCH01.corp.arin.net> <54710B7F-0F46-42E3-992F-E225470619A2@delong.com> <8DA1853CE466B041B104C1CAEE00B3748FA5578A@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA567A1@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FA6C2D0@CHAXCH01.corp.arin.net> <5154BAB1.3070002@umn.edu> <5154EA18.6010905@umn.edu> <5155E1CD.1090003@umn.edu> <8DA1853CE466B041B104C1CAEE00B3748FA75A20@CHAXCH01.corp.arin.net> <51560153.9080908@umn.edu> <515B68AE.4080906@umn.edu> <0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551@delong.com> <515BB740.300! 0602@umn.edu> Message-ID: <3E2E8083-7C91-474E-87CE-42E6B90E3D49@delong.com> On Apr 2, 2013, at 9:59 PM, David Farmer wrote: > On 4/2/13 19:58 , Owen DeLong wrote: >> On Apr 2, 2013, at 16:24 , David Farmer wrote: >>> Next, I'm thinking about a new subsection; >>> >>> 6.12 Reduction or Return >>> >>> Organizations may return all or part of their allocations or >>> assignments, that are not in use, to ARIN at any time with the >>> following considerations; >>> >>> a. Such a return or reduction must not result in a larger number of >>> blocks being held by an organization, if possible fewer blocks >>> are preferred. >>> >>> b. If a whole block is not in use, the whole block should be >>> returned to ARIN. >>> >>> c. If part of a block is returned; A single contiguous nibble >>> alined block, no smaller than the applicable minimum block size >>> allowed by policy, should be selected and retained by the >>> organization. The remainder of the original block must not be >>> in use and must be returned to ARIN. It is possible for >>> multiple separate blocks to be retained from a single original >>> block as long as clause (a) above is also meet. >> >> I think this vastly overcomplicates what should be relatively simple... >> >> How about this: >> >> 6.12 Reduction or Return >> >> ARIN will accept any return which allows an LIR to reduce their >> holdings to fit a lower tier in the fee schedule so long as: >> >> 1. The end result is not an increase in the number of >> non-contiguous blocks held by the LIR. >> >> 2. Whole blocks are returned to the extent practicable. >> >> 3. Retained block(s) are within the largest reserved space >> set aside for the LIR in the ARIN database to the extent >> practicable. >> >> I think it is better to express directly what it is that we want to happen >> in general terms and trust that ARIN and the LIRs will generally find >> a way to do the right thing so long as we do not prevent them from >> doing so. > > First, my intent was to use "organization" rather than "LIR" as I wanted it to be general and apply to both LIRs and end users, that is also why I moved it out to 6.12. Do you believe only LIR might wnat to reduce their holdings? You were advocating that end user annual fee be scaled to holding too, do you want to change the policy when that happens? Let keep it general and use "organization" > s/LIR/organization/g is fine by me. I believe that only LIRs can reduce their charge tier by returning partial blocks. To save money an end-user would have to return an entire block and that's already permitted by existing policy elsewhere. > Second, in your #3, what do the retained block(s) have to do with the reserved space? The retained block(s) are the block(s) kept by the organization and the reserved space is an ARIN operational issue. I believe we want the retained block(s) nibble aligned and no smaller than allowed by policy, /40 for an LIR and /48 for an end user. However, it would be better not to specify the minimums and get as a reference to applicable policy. That's fine, but orthogonal to #3. My intent is to make sure that if they expand back to larger, their existing retained blocks are not from disparate reservations scattered throughout IPv6 and rather that they can expand into their single reservation. At least to the extent practicable. > Do you want to allow non-nibble alined blocks to be retained? If you do then why not just allocate them in the first place. No. I figured existing policy pretty well covered that elsewhere, but I'm happy to add that provision. How about: 4. All retained blocks shall fall on nibble-aligned boundaries. Owen > From msrachellecross at gmail.com Wed Apr 3 14:56:10 2013 From: msrachellecross at gmail.com (MsRachelleCross/GM) Date: Wed, 3 Apr 2013 13:56:10 -0500 Subject: [arin-ppml] ARIN-PPML Digest, Vol 94, Issue 3 In-Reply-To: References: Message-ID: <62B23031-1632-4E9A-843C-028B00078151@gmail.com> Good afternoon, pardon me, I've been a little under the weather; if someone could clarify for me; am I correct in understanding that some ARIN protocol is being re-drafted? If so, long overdue, and much needed. While this proposal appears to focus on IPv6 block protocol, Mr. Ross sufficiently inculcates that even though some organizations will have multiple IPv6 blocks, obtained through subsequent allocations or assignments where an existing block could not be adequately expanded or competently managed; It is my belief these situations occur already. Even with IPv6 in place, many hosts are finding difficulty protecting their servers and clients because even hackers have found ways to infiltrate the IPv6 system. In re-establishing draft protocol, I hope we can work out a system of checks and balances, and accountability for such cybercrimes. Additionally, Those registrants with so many IPs? If an audit were done, how many of those IP's are truly theirs by legal acquisition? We are ARIN. Therefore, it's our jobs to ensure safety on the Internet. I personally know of several IP hosts who have violated intellectual genre, and (c) laws, having taken over people's Domains after providing service. There are other people out here who's entire IPv6 networks get hacked. People have related stories of losing information off of all their computers, mainframe, and all software licenses. Sirs, will any of the new protocol protect innocent everyday people, making the Internet safe for everyone, and not just those of us with technical knowledge? I would very much appreciate an opportunity to work with your team if I can be of assistance. Namaste, Rev Rachelle C.Navarro PhD, MS On Apr 3, 2013, at 0:11, arin-ppml-request at arin.net wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs > (David Farmer) > 2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs > (Owen DeLong) > 3. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs > (David Farmer) > 4. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs > (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 02 Apr 2013 18:24:30 -0500 > From: David Farmer > To: Brandon Ross > Cc: John Curran , ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 > Allocations for ISPs > Message-ID: <515B68AE.4080906 at umn.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 3/30/13 18:06 , Brandon Ross wrote: >> On Fri, 29 Mar 2013, David Farmer wrote: >> >>> After thinking about it for a while, if we even need any policy at >>> all, we should just have a general policy describing how IPv6 block >>> can be reduced by returning only part of a block, it should probably >>> be very generic and apply to allocations and end user assignments. It >>> might even be better if it we a separate proposal all together. >> >> Agreed, which is why the language in this proposal allows for that, and >> that was done on purpose. >> >> I don't want to see that separated to a separate policy proposal because >> it is critical to making this one function as intended. > > Well, yes and no, John has already fix the operational issue, the only > effect your proposed text would have at the moment would be to restrict > it to the first or last blocks of the larger original block. > > This raise a question for me do we really need to restrict it to the > first or last blocks? Personal, I'm ok with allowing the person making > the return to have the flexibility to make choice of any contiguous and > alined /40 out of the /32 they want. > > Next, I'm thinking about a new subsection; > > 6.12 Reduction or Return > > Organizations may return all or part of their allocations or > assignments, that are not in use, to ARIN at any time with the > following considerations; > > a. Such a return or reduction must not result in a larger number of > blocks being held by an organization, if possible fewer blocks > are preferred. > > b. If a whole block is not in use, the whole block should be > returned to ARIN. > > c. If part of a block is returned; A single contiguous nibble > alined block, no smaller than the applicable minimum block size > allowed by policy, should be selected and retained by the > organization. The remainder of the original block must not be > in use and must be returned to ARIN. It is possible for > multiple separate blocks to be retained from a single original > block as long as clause (a) above is also meet. > > This is very generic covering both ISP/LIR allocations and end user > assignments. The basic concept is that returns can't create additional > block that will negatively impact aggregation. And with partial returns > the retained portion must be a nibble alined and no smaller than policy > allows. > > Also, related to this I'd like to delete section 6.5.8.4 "Consolidation > and return of separate assignments", delete the last sentence of 6.5.3 > clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space > management"; > > 6.3.9 Consolidation and return > > Some organization will have multiple IPv6 blocks, obtained through > subsequent allocations or assignments where an existing block could > not be sufficiently expanded, or through transfers (mergers and > acquisitions). Such organizations should consider consolidating to > a single block, or at least minimizing the number of blocks used > for new sub-assignments. This should not be considered a > recommendation for large-scale active renumbering out of blocks at > are in use. To the contrary, such consolidation is merely a goal > and would likely occur over several years. Further, it should > primarily be achieved through attrition and other normal > operational change. Finally, return of a block is expected once it > is no longer in active use. > > Moving the issue of consolidation to goals cleans up the subsequent > allocation and assignment sections. It is intended to provide goals, > motivation and some direction regarding why someone might want to return > addresses. Putting it in the goals section prevents it from being > confused with the issues of making subsequent allocations and > assignments or the new Reduction or Return section above. > > This is why I was thinking about a separate proposal, because I think > the consolidation issue is more closely linked to the return and > reduction section than with the x-small and xx-small fee category issues. > > What do others think? > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > > ------------------------------ > > Message: 2 > Date: Tue, 2 Apr 2013 17:58:02 -0700 > From: Owen DeLong > To: David Farmer > Cc: John Curran , ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 > Allocations for ISPs > Message-ID: <0BDA5B2D-09B6-47C5-8CBF-E3B2315A0551 at delong.com> > Content-Type: text/plain; charset=us-ascii > > > On Apr 2, 2013, at 16:24 , David Farmer wrote: > >> On 3/30/13 18:06 , Brandon Ross wrote: >>> On Fri, 29 Mar 2013, David Farmer wrote: >>> >>>> After thinking about it for a while, if we even need any policy at >>>> all, we should just have a general policy describing how IPv6 block >>>> can be reduced by returning only part of a block, it should probably >>>> be very generic and apply to allocations and end user assignments. It >>>> might even be better if it we a separate proposal all together. >>> >>> Agreed, which is why the language in this proposal allows for that, and >>> that was done on purpose. >>> >>> I don't want to see that separated to a separate policy proposal because >>> it is critical to making this one function as intended. >> >> Well, yes and no, John has already fix the operational issue, the only effect your proposed text would have at the moment would be to restrict it to the first or last blocks of the larger original block. >> >> This raise a question for me do we really need to restrict it to the first or last blocks? Personal, I'm ok with allowing the person making the return to have the flexibility to make choice of any contiguous and alined /40 out of the /32 they want.j > > Since we're holding (at least) the /32 in reserve for them anyway and ideally the /28, I really don't think it matters which /40 they're using. > >> >> Next, I'm thinking about a new subsection; >> >> 6.12 Reduction or Return >> >> Organizations may return all or part of their allocations or >> assignments, that are not in use, to ARIN at any time with the >> following considerations; >> >> a. Such a return or reduction must not result in a larger number of >> blocks being held by an organization, if possible fewer blocks >> are preferred. >> >> b. If a whole block is not in use, the whole block should be >> returned to ARIN. >> >> c. If part of a block is returned; A single contiguous nibble >> alined block, no smaller than the applicable minimum block size >> allowed by policy, should be selected and retained by the >> organization. The remainder of the original block must not be >> in use and must be returned to ARIN. It is possible for >> multiple separate blocks to be retained from a single original >> block as long as clause (a) above is also meet. > > I think this vastly overcomplicates what should be relatively simple... > > How about this: > > 6.12 Reduction or Return > > ARIN will accept any return which allows an LIR to reduce their > holdings to fit a lower tier in the fee schedule so long as: > > 1. The end result is not an increase in the number of > non-contiguous blocks held by the LIR. > > 2. Whole blocks are returned to the extent practicable. > > 3. Retained block(s) are within the largest reserved space > set aside for the LIR in the ARIN database to the extent > practicable. > > I think it is better to express directly what it is that we want to happen > in general terms and trust that ARIN and the LIRs will generally find > a way to do the right thing so long as we do not prevent them from > doing so. > >> Also, related to this I'd like to delete section 6.5.8.4 "Consolidation and return of separate assignments", delete the last sentence of 6.5.3 clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space management"; >> >> 6.3.9 Consolidation and return >> >> Some organization will have multiple IPv6 blocks, obtained through >> subsequent allocations or assignments where an existing block could >> not be sufficiently expanded, or through transfers (mergers and >> acquisitions). Such organizations should consider consolidating to >> a single block, or at least minimizing the number of blocks used >> for new sub-assignments. This should not be considered a >> recommendation for large-scale active renumbering out of blocks at >> are in use. To the contrary, such consolidation is merely a goal >> and would likely occur over several years. Further, it should >> primarily be achieved through attrition and other normal >> operational change. Finally, return of a block is expected once it >> is no longer in active use. > > I think this is unnecessary and that the concerns driving this can be better addressed through improved operational practice. > > Owen > > > > > ------------------------------ > > Message: 3 > Date: Tue, 02 Apr 2013 23:59:44 -0500 > From: David Farmer > To: Owen DeLong > Cc: John Curran , ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 > Allocations for ISPs > Message-ID: <515BB740.3000602 at umn.edu> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 4/2/13 19:58 , Owen DeLong wrote: >> On Apr 2, 2013, at 16:24 , David Farmer wrote: >>> Next, I'm thinking about a new subsection; >>> >>> 6.12 Reduction or Return >>> >>> Organizations may return all or part of their allocations or >>> assignments, that are not in use, to ARIN at any time with the >>> following considerations; >>> >>> a. Such a return or reduction must not result in a larger number of >>> blocks being held by an organization, if possible fewer blocks >>> are preferred. >>> >>> b. If a whole block is not in use, the whole block should be >>> returned to ARIN. >>> >>> c. If part of a block is returned; A single contiguous nibble >>> alined block, no smaller than the applicable minimum block size >>> allowed by policy, should be selected and retained by the >>> organization. The remainder of the original block must not be >>> in use and must be returned to ARIN. It is possible for >>> multiple separate blocks to be retained from a single original >>> block as long as clause (a) above is also meet. >> >> I think this vastly overcomplicates what should be relatively simple... >> >> How about this: >> >> 6.12 Reduction or Return >> >> ARIN will accept any return which allows an LIR to reduce their >> holdings to fit a lower tier in the fee schedule so long as: >> >> 1. The end result is not an increase in the number of >> non-contiguous blocks held by the LIR. >> >> 2. Whole blocks are returned to the extent practicable. >> >> 3. Retained block(s) are within the largest reserved space >> set aside for the LIR in the ARIN database to the extent >> practicable. >> >> I think it is better to express directly what it is that we want to happen >> in general terms and trust that ARIN and the LIRs will generally find >> a way to do the right thing so long as we do not prevent them from >> doing so. > > First, my intent was to use "organization" rather than "LIR" as I wanted > it to be general and apply to both LIRs and end users, that is also why > I moved it out to 6.12. Do you believe only LIR might wnat to reduce > their holdings? You were advocating that end user annual fee be scaled > to holding too, do you want to change the policy when that happens? Let > keep it general and use "organization" > > Second, in your #3, what do the retained block(s) have to do with the > reserved space? The retained block(s) are the block(s) kept by the > organization and the reserved space is an ARIN operational issue. I > believe we want the retained block(s) nibble aligned and no smaller than > allowed by policy, /40 for an LIR and /48 for an end user. However, it > would be better not to specify the minimums and get as a reference to > applicable policy. > > Do you want to allow non-nibble alined blocks to be retained? If you do > then why not just allocate them in the first place. > > Or, am I missing something? > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > > ------------------------------ > > Message: 4 > Date: Tue, 2 Apr 2013 22:08:35 -0700 > From: Owen DeLong > To: David Farmer > Cc: John Curran , ARIN PPML > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 > Allocations for ISPs > Message-ID: <3E2E8083-7C91-474E-87CE-42E6B90E3D49 at delong.com> > Content-Type: text/plain; charset=iso-8859-1 > > > On Apr 2, 2013, at 9:59 PM, David Farmer wrote: > >> On 4/2/13 19:58 , Owen DeLong wrote: >>> On Apr 2, 2013, at 16:24 , David Farmer wrote: >>>> Next, I'm thinking about a new subsection; >>>> >>>> 6.12 Reduction or Return >>>> >>>> Organizations may return all or part of their allocations or >>>> assignments, that are not in use, to ARIN at any time with the >>>> following considerations; >>>> >>>> a. Such a return or reduction must not result in a larger number of >>>> blocks being held by an organization, if possible fewer blocks >>>> are preferred. >>>> >>>> b. If a whole block is not in use, the whole block should be >>>> returned to ARIN. >>>> >>>> c. If part of a block is returned; A single contiguous nibble >>>> alined block, no smaller than the applicable minimum block size >>>> allowed by policy, should be selected and retained by the >>>> organization. The remainder of the original block must not be >>>> in use and must be returned to ARIN. It is possible for >>>> multiple separate blocks to be retained from a single original >>>> block as long as clause (a) above is also meet. >>> >>> I think this vastly overcomplicates what should be relatively simple... >>> >>> How about this: >>> >>> 6.12 Reduction or Return >>> >>> ARIN will accept any return which allows an LIR to reduce their >>> holdings to fit a lower tier in the fee schedule so long as: >>> >>> 1. The end result is not an increase in the number of >>> non-contiguous blocks held by the LIR. >>> >>> 2. Whole blocks are returned to the extent practicable. >>> >>> 3. Retained block(s) are within the largest reserved space >>> set aside for the LIR in the ARIN database to the extent >>> practicable. >>> >>> I think it is better to express directly what it is that we want to happen >>> in general terms and trust that ARIN and the LIRs will generally find >>> a way to do the right thing so long as we do not prevent them from >>> doing so. >> >> First, my intent was to use "organization" rather than "LIR" as I wanted it to be general and apply to both LIRs and end users, that is also why I moved it out to 6.12. Do you believe only LIR might wnat to reduce their holdings? You were advocating that end user annual fee be scaled to holding too, do you want to change the policy when that happens? Let keep it general and use "organization" > s/LIR/organization/g is fine by me. > > I believe that only LIRs can reduce their charge tier by returning partial blocks. To save money an end-user would have to return an entire block and that's already permitted by existing policy elsewhere. > >> Second, in your #3, what do the retained block(s) have to do with the reserved space? The retained block(s) are the block(s) kept by the organization and the reserved space is an ARIN operational issue. I believe we want the retained block(s) nibble aligned and no smaller than allowed by policy, /40 for an LIR and /48 for an end user. However, it would be better not to specify the minimums and get as a reference to applicable policy. > > That's fine, but orthogonal to #3. My intent is to make sure that if they expand back to larger, their existing retained blocks are not from disparate reservations scattered throughout IPv6 and rather that they can expand into their single reservation. At least to the extent practicable. > >> Do you want to allow non-nibble alined blocks to be retained? If you do then why not just allocate them in the first place. > > No. I figured existing policy pretty well covered that elsewhere, but I'm happy to add that provision. > > How about: > 4. All retained blocks shall fall on nibble-aligned boundaries. > > Owen > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 94, Issue 3 > **************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Apr 4 13:15:43 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Apr 2013 12:15:43 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5153387E.6060700@arin.net> References: <5153387E.6060700@arin.net> Message-ID: <515DB53F.1060809@umn.edu> Here is the update that I propose to submit tomorrow to meet the publication deadline for the Barbados meeting. I believe it accurately reflects the changes discussed so for. Any comments are appreciated. Thanks. --- Draft Policy ARIN-2013-3 Tiny IPv6 Allocations for ISPs Date: 4 April 2013 Problem Statement: ARIN's fee structure provides a graduated system wherein organizations pay based on the amount of number resources they consume. At the very bottom end of the scale, it is presently not possible to be an XX-Small ISP with an IPv6 allocation because the minimum allocation size of /36 automatically promotes one into Small ISP status, resulting in a doubling of annual fees. While tiny in absolute terms, the extra costs incurred represent a disincentive to IPv6 deployment. To the author's knowledge, it has never been possible for an LIR/ISP to get a /40 allocation direct from ARIN; assignments of /40s have been limited to organizations that qualify as end sites or critical infrastructure. It is understood there is an expected correction of the xx-small fee category to "/40 or smaller". Policy statement: Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at the end of the first sentence of subsection 6.5.2.1 clause (b), and add a new clause (g), resulting in; b. In no case shall an LIR receive smaller than a /32 unless they specifically request a /36 or /40. In no case shall an ISP receive more than a /16 initial allocation. ... g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to /32 or /36 at any time without additional justification. Such expansions are not considered subsequent allocations. However, any expansions beyond /32 are considered subsequent allocations, and must conform to section 6.5.3. Part 2: Add a new subsection to section 6 "IPv6"; 6.12 Reduction or Return ARIN will accept the return of whole or partial block(s) allowing an organization to reduce their holdings as long as: a. The end result is not an increase in the number of non-contiguous blocks held by the organization. b. Whole blocks are returned to the extent practicable. c. Partial block(s) retained must conform to applicable policies, as to size, alignment, etc? d. Partial block(s) retained are within a single reserved space or aggregate set aside for the organization in the ARIN database to the extent practicable. e. All returned block(s) must not be in use by the organization or its customers. Comments: The author acknowledges the shortcomings of providing an ISP with an allocation of a size that is more traditionally associated with end sites. In order to avoid possible bad effects on the routing table, the author encourages ARIN staff to adopt the same sparse allocation practice as currently exists for larger allocations, perhaps even reserving a block as large as the /28 that is reserved for /32s. Note the policy intent of part 1 requires a minimum of a /32 be reserved. Part 1 brings ARIN's allocation policies in line with the upcoming fee schedule, with the addition of an expected correction of the xx-small fee category to "/40 or smaller". This makes it possible to qualify for each ISP fee category while holding IPv6 number resources and allows expansion up to /32 without justification as a subsequent allocation as driven by an ISP's business demands. Part 2 codifies and expands upon current practice for selective return in the manner described by John Curran on the arin-discuss mailing list (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ) It specifies the generic requirements that should be meet for such returns. A more practical approach might to figure out a way to apply graduated fees to ISPs at the very small end of the scale using some metric other than prefix size. Fee schedules are outside of the purview of the Policy Development Process; such responsibility lies with the Board should they choose to take it up. Timetable for implementation: Immediate -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From admin at bango.org.bb Thu Apr 4 13:34:28 2013 From: admin at bango.org.bb (BANGO) Date: Thu, 4 Apr 2013 13:34:28 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DB53F.1060809@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: <2DA96EA9254548F7A6671DAF4B04585D@BANGOPC2> When is the Barbados meeting? ROK -----Original Message----- From: David Farmer Sent: Thursday, April 04, 2013 1:15 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs Here is the update that I propose to submit tomorrow to meet the publication deadline for the Barbados meeting. I believe it accurately reflects the changes discussed so for. Any comments are appreciated. Thanks. --- Draft Policy ARIN-2013-3 Tiny IPv6 Allocations for ISPs Date: 4 April 2013 Problem Statement: ARIN's fee structure provides a graduated system wherein organizations pay based on the amount of number resources they consume. At the very bottom end of the scale, it is presently not possible to be an XX-Small ISP with an IPv6 allocation because the minimum allocation size of /36 automatically promotes one into Small ISP status, resulting in a doubling of annual fees. While tiny in absolute terms, the extra costs incurred represent a disincentive to IPv6 deployment. To the author's knowledge, it has never been possible for an LIR/ISP to get a /40 allocation direct from ARIN; assignments of /40s have been limited to organizations that qualify as end sites or critical infrastructure. It is understood there is an expected correction of the xx-small fee category to "/40 or smaller". Policy statement: Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at the end of the first sentence of subsection 6.5.2.1 clause (b), and add a new clause (g), resulting in; b. In no case shall an LIR receive smaller than a /32 unless they specifically request a /36 or /40. In no case shall an ISP receive more than a /16 initial allocation. ... g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to /32 or /36 at any time without additional justification. Such expansions are not considered subsequent allocations. However, any expansions beyond /32 are considered subsequent allocations, and must conform to section 6.5.3. Part 2: Add a new subsection to section 6 "IPv6"; 6.12 Reduction or Return ARIN will accept the return of whole or partial block(s) allowing an organization to reduce their holdings as long as: a. The end result is not an increase in the number of non-contiguous blocks held by the organization. b. Whole blocks are returned to the extent practicable. c. Partial block(s) retained must conform to applicable policies, as to size, alignment, etc? d. Partial block(s) retained are within a single reserved space or aggregate set aside for the organization in the ARIN database to the extent practicable. e. All returned block(s) must not be in use by the organization or its customers. Comments: The author acknowledges the shortcomings of providing an ISP with an allocation of a size that is more traditionally associated with end sites. In order to avoid possible bad effects on the routing table, the author encourages ARIN staff to adopt the same sparse allocation practice as currently exists for larger allocations, perhaps even reserving a block as large as the /28 that is reserved for /32s. Note the policy intent of part 1 requires a minimum of a /32 be reserved. Part 1 brings ARIN's allocation policies in line with the upcoming fee schedule, with the addition of an expected correction of the xx-small fee category to "/40 or smaller". This makes it possible to qualify for each ISP fee category while holding IPv6 number resources and allows expansion up to /32 without justification as a subsequent allocation as driven by an ISP's business demands. Part 2 codifies and expands upon current practice for selective return in the manner described by John Curran on the arin-discuss mailing list (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ) It specifies the generic requirements that should be meet for such returns. A more practical approach might to figure out a way to apply graduated fees to ISPs at the very small end of the scale using some metric other than prefix size. Fee schedules are outside of the purview of the Policy Development Process; such responsibility lies with the Board should they choose to take it up. Timetable for implementation: Immediate -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2904 / Virus Database: 2641/6224 - Release Date: 04/04/13 From farmer at umn.edu Thu Apr 4 13:39:59 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Apr 2013 12:39:59 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <2DA96EA9254548F7A6671DAF4B04585D@BANGOPC2> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <2DA96EA9254548F7A6671DAF4B04585D@BANGOPC2> Message-ID: <515DBAEF.7020706@umn.edu> On 4/4/13 12:34 , BANGO wrote: > When is the Barbados meeting? > > ROK April 21st - 24th, see; http://www.arin.net/ARIN-31/ > -----Original Message----- From: David Farmer > Sent: Thursday, April 04, 2013 1:15 PM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations > for ISPs > > Here is the update that I propose to submit tomorrow to meet the > publication deadline for the Barbados meeting. I believe it accurately > reflects the changes discussed so for. Any comments are appreciated. > > Thanks. > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen at delong.com Thu Apr 4 14:27:51 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Apr 2013 11:27:51 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DB53F.1060809@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: I would remove the word Parital from 6.12(d). I would remove "perhaps" from ...perhaps even reserving a block as large as..." and replace it with "ideally". Explanation of part 2 s/meet/met/ in "...generic requirements that should be meet [sic] for such..." Owen On Apr 4, 2013, at 10:15 , David Farmer wrote: > Here is the update that I propose to submit tomorrow to meet the publication deadline for the Barbados meeting. I believe it accurately reflects the changes discussed so for. Any comments are appreciated. > > Thanks. > > --- > > Draft Policy ARIN-2013-3 > Tiny IPv6 Allocations for ISPs > > Date: 4 April 2013 > > Problem Statement: > > ARIN's fee structure provides a graduated system wherein organizations pay based on the amount of number resources they consume. > > At the very bottom end of the scale, it is presently not possible to be an XX-Small ISP with an IPv6 allocation because the minimum allocation size of /36 automatically promotes one into Small ISP status, resulting in a doubling of annual fees. > > While tiny in absolute terms, the extra costs incurred represent a disincentive to IPv6 deployment. > > To the author's knowledge, it has never been possible for an LIR/ISP to get a /40 allocation direct from ARIN; assignments of /40s have been limited to organizations that qualify as end sites or critical infrastructure. It is understood there is an expected correction of the xx-small fee category to "/40 or smaller". > > Policy statement: > > Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at the end of the first sentence of subsection 6.5.2.1 clause (b), and add a new clause (g), resulting in; > > b. In no case shall an LIR receive smaller than a /32 unless they specifically request a /36 or /40. In no case shall an ISP receive more than a /16 initial allocation. > > ... > > g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to /32 or /36 at any time without additional justification. Such expansions are not considered subsequent allocations. However, any expansions beyond /32 are considered subsequent allocations, and must conform to section 6.5.3. > > Part 2: Add a new subsection to section 6 "IPv6"; > > 6.12 Reduction or Return > > ARIN will accept the return of whole or partial block(s) allowing an organization to reduce their holdings as long as: > > a. The end result is not an increase in the number of non-contiguous blocks held by the organization. > > b. Whole blocks are returned to the extent practicable. > > c. Partial block(s) retained must conform to applicable policies, as to size, alignment, etc? > > d. Partial block(s) retained are within a single reserved space or aggregate set aside for the organization in the ARIN database to the extent practicable. > > e. All returned block(s) must not be in use by the organization or its customers. > > Comments: > > The author acknowledges the shortcomings of providing an ISP with an allocation of a size that is more traditionally associated with end sites. In order to avoid possible bad effects on the routing table, the author encourages ARIN staff to adopt the same sparse allocation practice as currently exists for larger allocations, perhaps even reserving a block as large as the /28 that is reserved for /32s. Note the policy intent of part 1 requires a minimum of a /32 be reserved. > > Part 1 brings ARIN's allocation policies in line with the upcoming fee schedule, with the addition of an expected correction of the xx-small fee category to "/40 or smaller". This makes it possible to qualify for each ISP fee category while holding IPv6 number resources and allows expansion up to /32 without justification as a subsequent allocation as driven by an ISP's business demands. > > Part 2 codifies and expands upon current practice for selective return in the manner described by John Curran on the arin-discuss mailing list (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ) It specifies the generic requirements that should be meet for such returns. > > A more practical approach might to figure out a way to apply graduated fees to ISPs at the very small end of the scale using some metric other than prefix size. Fee schedules are outside of the purview of the Policy Development Process; such responsibility lies with the Board should they choose to take it up. > > Timetable for implementation: Immediate > > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Thu Apr 4 14:41:53 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Apr 2013 13:41:53 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: <515DC971.1020502@umn.edu> On 4/4/13 13:27 , Owen DeLong wrote: > I would remove the word Parital from 6.12(d). > > I would remove "perhaps" from ...perhaps even reserving a block as large as..." and replace it with "ideally". > > Explanation of part 2 s/meet/met/ in "...generic requirements that should be meet [sic] for such..." > > Owen OK I'll incorporate those. Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bill at herrin.us Thu Apr 4 14:31:20 2013 From: bill at herrin.us (William Herrin) Date: Thu, 4 Apr 2013 14:31:20 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DB53F.1060809@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: On Thu, Apr 4, 2013 at 1:15 PM, David Farmer wrote: > Part 2: Add a new subsection to section 6 "IPv6"; > > 6.12 Reduction or Return > > ARIN will accept the return of whole or partial block(s) allowing an > organization to reduce their holdings as long as: > > a. The end result is not an increase in the number of non-contiguous blocks > held by the organization. Hi David, CIDR blocks or aggregable blocks. 10.0.0.0-10.11.12.13 is a contiguous block but it doesn't _aggregate_ for routing purposes per NRPM 6.3.4. > b. Whole blocks are returned to the extent practicable. I liked the original language in the proposal which was along the lines of: "the aggregate retained must be either the first (lowest numbered) subnet or the last (highest numbered) subnet of the original allocation." I see Owen's point but when the time eventually arrives that we have to think about allocating the space in these reserved areas, I'd rather that space be less fragmented than more. Anyone who doesn't have a /32 yet can read the policy and figure out what they need to do if they want to be able to shed cost. And anyone who already has their /32... thank you. But seriously, show of hands, which of you wants to return the start and end of your /32 and keep only a chunk in the middle somewhere? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Thu Apr 4 14:57:37 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Apr 2013 13:57:37 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: <515DCD21.5000509@umn.edu> On 4/4/13 13:31 , William Herrin wrote: > On Thu, Apr 4, 2013 at 1:15 PM, David Farmer wrote: >> Part 2: Add a new subsection to section 6 "IPv6"; >> >> 6.12 Reduction or Return >> >> ARIN will accept the return of whole or partial block(s) allowing an >> organization to reduce their holdings as long as: >> >> a. The end result is not an increase in the number of non-contiguous blocks >> held by the organization. OK, how about? a. The end result is not an increase in the number of aggregatable blocks held by the organization. > Hi David, > > CIDR blocks or aggregable blocks. 10.0.0.0-10.11.12.13 is a contiguous > block but it doesn't _aggregate_ for routing purposes per NRPM 6.3.4. > > >> b. Whole blocks are returned to the extent practicable. > > I liked the original language in the proposal which was along the > lines of: "the aggregate retained must be either the first (lowest > numbered) subnet or the last (highest numbered) subnet of the original > allocation." > > I see Owen's point but when the time eventually arrives that we have > to think about allocating the space in these reserved areas, I'd > rather that space be less fragmented than more. Anyone who doesn't > have a /32 yet can read the policy and figure out what they need to do > if they want to be able to shed cost. And anyone who already has their > /32... thank you. But seriously, show of hands, which of you wants to > return the start and end of your /32 and keep only a chunk in the > middle somewhere? It all depends where they started using there blocks. The current use case for this policy is to reduce your holding because of the fee schedule, but I'd prefer generic rules that allow flexibility for future conditions. Also, this is the current operational practice we have now, to allow the LIR to select which /36 to retain. If someone started using their /32 in the middle why force them to renumber? How do others feel, I was planning to bring this up as a discussion point in the Barbados meeting. Unless a number of others chime in, I'll go with the current language for the Barbados meeting. This policy has to come back for another consultation so we have plenty of time to change it to what you are talking about if there is consensus for it. Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen at delong.com Thu Apr 4 15:06:04 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Apr 2013 12:06:04 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: On Apr 4, 2013, at 11:31 , William Herrin wrote: > On Thu, Apr 4, 2013 at 1:15 PM, David Farmer wrote: >> Part 2: Add a new subsection to section 6 "IPv6"; >> >> 6.12 Reduction or Return >> >> ARIN will accept the return of whole or partial block(s) allowing an >> organization to reduce their holdings as long as: >> >> a. The end result is not an increase in the number of non-contiguous blocks >> held by the organization. > > Hi David, > > CIDR blocks or aggregable blocks. 10.0.0.0-10.11.12.13 is a contiguous > block but it doesn't _aggregate_ for routing purposes per NRPM 6.3.4. Bill, Since ARIN will be issuing them as aggregable nibble-boundary based blocks (we are talking IPv6 policy, so your example is specious), anything which doesn't increase the number of discontiguous blocks will, by definition, remain aggregable. >> b. Whole blocks are returned to the extent practicable. > > I liked the original language in the proposal which was along the > lines of: "the aggregate retained must be either the first (lowest > numbered) subnet or the last (highest numbered) subnet of the original > allocation." > > I see Owen's point but when the time eventually arrives that we have > to think about allocating the space in these reserved areas, I'd > rather that space be less fragmented than more. Anyone who doesn't > have a /32 yet can read the policy and figure out what they need to do > if they want to be able to shed cost. And anyone who already has their > /32... thank you. But seriously, show of hands, which of you wants to > return the start and end of your /32 and keep only a chunk in the > middle somewhere? I do not expect that IPv6 will be in use so long as for that time to come. I think we will be lucky if technology doesn't outpace the capabilities of IPv6 in the next 100 years. There is probably a few thousand years worth of IPv6 address space. Especially if we consider the use of the 6 remaining /3s. Owen From matthew at matthew.at Thu Apr 4 15:42:33 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 04 Apr 2013 12:42:33 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DCD21.5000509@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DCD21.5000509@umn.edu> Message-ID: <515DD7A9.7010004@matthew.at> On 4/4/2013 11:57 AM, David Farmer wrote: > > It all depends where they started using there blocks. The current use > case for this policy is to reduce your holding because of the fee schedule Doesn't this just mean that the new fee schedule is broken? IPv6 addresses are by no means scarce... why are we treating them that way? If we gave someone a /32 and they aren't using all of it yet, they should just keep the /32. > , but I'd prefer generic rules that allow flexibility for future > conditions. Agreed. How about "you can't give us back anything but what we gave you" and "we won't have stupid fee schedules that ever encourage you to want to do otherwise". > Also, this is the current operational practice we have now, to allow > the LIR to select which /36 to retain. If someone started using their > /32 in the middle why force them to renumber? > Why force them to give up the /32 at all? Are we running out of them or something? Matthew Kaufman From matthew at matthew.at Thu Apr 4 15:46:50 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 04 Apr 2013 12:46:50 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DB53F.1060809@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: <515DD8AA.5080506@matthew.at> Totally oppose the below. There's no reason why we should ever be giving an ISP something smaller than a /32. Fix the silly fee schedule. If charging $1000 instead of $500 is a disincentive (I certainly think it is) make the /32 be $500. Matthew Kaufman ps. Example as to why I think it is a disincentive: I run a microwave network linking multiple mountaintops serving the tiny needs of several different non-profit organizations, all paid for out of my own pocket. All of it is numbered out of legacy space I hold. Guess how much my wife thinks I should spend per year on an IPv6 allocation from ARIN so that I can add IPv6 to this network? I'll give you a hint: $500/year is too much. On 4/4/2013 10:15 AM, David Farmer wrote: > Here is the update that I propose to submit tomorrow to meet the > publication deadline for the Barbados meeting. I believe it > accurately reflects the changes discussed so for. Any comments are > appreciated. > > Thanks. > > --- > > Draft Policy ARIN-2013-3 > Tiny IPv6 Allocations for ISPs > > Date: 4 April 2013 > > Problem Statement: > > ARIN's fee structure provides a graduated system wherein organizations > pay based on the amount of number resources they consume. > > At the very bottom end of the scale, it is presently not possible to > be an XX-Small ISP with an IPv6 allocation because the minimum > allocation size of /36 automatically promotes one into Small ISP > status, resulting in a doubling of annual fees. > > While tiny in absolute terms, the extra costs incurred represent a > disincentive to IPv6 deployment. > > To the author's knowledge, it has never been possible for an LIR/ISP > to get a /40 allocation direct from ARIN; assignments of /40s have > been limited to organizations that qualify as end sites or critical > infrastructure. It is understood there is an expected correction of > the xx-small fee category to "/40 or smaller". > > Policy statement: > > Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" > at the end of the first sentence of subsection 6.5.2.1 clause (b), and > add a new clause (g), resulting in; > > b. In no case shall an LIR receive smaller than a /32 unless they > specifically request a /36 or /40. In no case shall an ISP receive > more than a /16 initial allocation. > > ... > > g. An LIR that requests a smaller /36 or /40 allocation is entitled to > expand the allocation to /32 or /36 at any time without additional > justification. Such expansions are not considered subsequent > allocations. However, any expansions beyond /32 are considered > subsequent allocations, and must conform to section 6.5.3. > > Part 2: Add a new subsection to section 6 "IPv6"; > > 6.12 Reduction or Return > > ARIN will accept the return of whole or partial block(s) allowing an > organization to reduce their holdings as long as: > > a. The end result is not an increase in the number of non-contiguous > blocks held by the organization. > > b. Whole blocks are returned to the extent practicable. > > c. Partial block(s) retained must conform to applicable policies, as > to size, alignment, etc? > > d. Partial block(s) retained are within a single reserved space or > aggregate set aside for the organization in the ARIN database to the > extent practicable. > > e. All returned block(s) must not be in use by the organization or its > customers. > > Comments: > > The author acknowledges the shortcomings of providing an ISP with an > allocation of a size that is more traditionally associated with end > sites. In order to avoid possible bad effects on the routing table, > the author encourages ARIN staff to adopt the same sparse allocation > practice as currently exists for larger allocations, perhaps even > reserving a block as large as the /28 that is reserved for /32s. Note > the policy intent of part 1 requires a minimum of a /32 be reserved. > > Part 1 brings ARIN's allocation policies in line with the upcoming fee > schedule, with the addition of an expected correction of the xx-small > fee category to "/40 or smaller". This makes it possible to qualify > for each ISP fee category while holding IPv6 number resources and > allows expansion up to /32 without justification as a subsequent > allocation as driven by an ISP's business demands. > > Part 2 codifies and expands upon current practice for selective return > in the manner described by John Curran on the arin-discuss mailing > list (7-Mar-2013 in > 8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ) It > specifies the generic requirements that should be meet for such returns. > > A more practical approach might to figure out a way to apply graduated > fees to ISPs at the very small end of the scale using some metric > other than prefix size. Fee schedules are outside of the purview of > the Policy Development Process; such responsibility lies with the > Board should they choose to take it up. > > Timetable for implementation: Immediate > > From bill at herrin.us Thu Apr 4 16:29:03 2013 From: bill at herrin.us (William Herrin) Date: Thu, 4 Apr 2013 16:29:03 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DD8AA.5080506@matthew.at> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DD8AA.5080506@matthew.at> Message-ID: On Thu, Apr 4, 2013 at 3:46 PM, Matthew Kaufman wrote: > Totally oppose the below. There's no reason why we should ever be giving an > ISP something smaller than a /32. Fix the silly fee schedule. > > If charging $1000 instead of $500 is a disincentive (I certainly think it > is) make the /32 be $500. > > Matthew Kaufman > > ps. Example as to why I think it is a disincentive: I run a microwave > network linking multiple mountaintops serving the tiny needs of several > different non-profit organizations, all paid for out of my own pocket. All > of it is numbered out of legacy space I hold. Guess how much my wife thinks > I should spend per year on an IPv6 allocation from ARIN so that I can add > IPv6 to this network? I'll give you a hint: $500/year is too much. Hi Matthew, This is yet another example why the Board should defer any non-trivial revenue collection on IPv6 until it supersedes IPv4 as the primary protocol in use on the Internet. They'll figure it out eventually and when they do they'll quit making choices which needlessly stall IPv6 deployment. I mean really, there are so many things stalling IPv6 deployment that we can't do anything about. Why gratuitously stall it even more with fees that the economics of the situation don't support? Se la vie. Today, the battle we can win is getting IPv6, *any* IPv6, into the hands of ISPs who are willing to do it if it doesn't change their ARIN costs. The board isn't willing to set the IPv6 fees for every ISP holding an IPv6 /32 at $500, but they'll apparently accept making a smaller allocation to an ISP for $500. For that reason, I'd encourage you to support the proposal. Let's just make sure they can convert to a /32 later without renumbering. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Thu Apr 4 16:52:08 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Apr 2013 15:52:08 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DD8AA.5080506@matthew.at> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DD8AA.5080506@matthew.at> Message-ID: <515DE7F8.2000200@umn.edu> On 4/4/13 14:46 , Matthew Kaufman wrote: > Totally oppose the below. There's no reason why we should ever be giving > an ISP something smaller than a /32. Fix the silly fee schedule. Current policy already allows /36s to be handed out, this adds /40s to that, and allow you to change it to /32 as you see fit. > If charging $1000 instead of $500 is a disincentive (I certainly think > it is) make the /32 be $500. I assume you didn't support the original version of the draft with /48s either, and your not opposed to the changes to the draft, but the policy intent overall. Or, is there something about the changes from the original draft that you oppose. > Matthew Kaufman > > ps. Example as to why I think it is a disincentive: I run a microwave > network linking multiple mountaintops serving the tiny needs of several > different non-profit organizations, all paid for out of my own pocket. > All of it is numbered out of legacy space I hold. Guess how much my wife > thinks I should spend per year on an IPv6 allocation from ARIN so that I > can add IPv6 to this network? I'll give you a hint: $500/year is too much. The last paragraph of the comments basically says that it would be better to have a different solution for the fee schedule, but that is out of scope of the PDP. I'd be interested in talking with you about finding a way to meet such needs. Thanks. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer at umn.edu Thu Apr 4 17:14:13 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Apr 2013 16:14:13 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DD8AA.5080506@matthew.at> Message-ID: <515DED25.3080404@umn.edu> On 4/4/13 15:29 , William Herrin wrote: > Se la vie. Today, the battle we can win is getting IPv6, *any* IPv6, > into the hands of ISPs who are willing to do it if it doesn't change > their ARIN costs. The board isn't willing to set the IPv6 fees for > every ISP holding an IPv6 /32 at $500, but they'll apparently accept > making a smaller allocation to an ISP for $500. For that reason, I'd > encourage you to support the proposal. > > Let's just make sure they can convert to a /32 later without renumbering. Actually, to that end I'll change the proposed 6.5.2.1 clause (g) adding "or renumbering" to the end of the first sentence, resulting in; g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to /32 or /36 at any time without additional justification or renumbering. Such expansions are not considered subsequent allocations. However, any expansions beyond /32 are considered subsequent allocations, and must conform to section 6.5.3. This makes the policy intent abundantly clear without specifying operational issues like the size of a reservation. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From matthew at matthew.at Thu Apr 4 17:28:53 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 04 Apr 2013 14:28:53 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DE7F8.2000200@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DD8AA.5080506@matthew.at> <515DE7F8.2000200@umn.edu> Message-ID: <515DF095.4030701@matthew.at> On 4/4/2013 1:52 PM, David Farmer wrote: > On 4/4/13 14:46 , Matthew Kaufman wrote: >> Totally oppose the below. There's no reason why we should ever be giving >> an ISP something smaller than a /32. Fix the silly fee schedule. > > Current policy already allows /36s to be handed out, this adds /40s to > that, and allow you to change it to /32 as you see fit. Well, that's a bug too. But certainly I don't think we should be handing out /40s to ISPs. Probably not /36s either. How about /32s only, and up to /16 with justification? > >> If charging $1000 instead of $500 is a disincentive (I certainly think >> it is) make the /32 be $500. > > I assume you didn't support the original version of the draft with > /48s either, and your not opposed to the changes to the draft, but the > policy intent overall. Or, is there something about the changes from > the original draft that you oppose. > Policy proposal as it stands exists only because of a bug in the fee schedule. No ISP in their right mind would request a /40 instead of a /36 (say) just because they can, given that initial allocation justification is identical. Except for the fee schedule of course. >> Matthew Kaufman >> >> ps. Example as to why I think it is a disincentive: I run a microwave >> network linking multiple mountaintops serving the tiny needs of several >> different non-profit organizations, all paid for out of my own pocket. >> All of it is numbered out of legacy space I hold. Guess how much my wife >> thinks I should spend per year on an IPv6 allocation from ARIN so that I >> can add IPv6 to this network? I'll give you a hint: $500/year is too >> much. > > The last paragraph of the comments basically says that it would be > better to have a different solution for the fee schedule, but that is > out of scope of the PDP. > I know it is. But this whole proposal is about working around the fee schedule instead of fixing the root problem (that some ISPs think the price for a /32 is too high and so incorrectly wish to get something smaller) > I'd be interested in talking with you about finding a way to meet such > needs. > You know where to find me :) Matthew Kaufman From matthew at matthew.at Thu Apr 4 17:32:12 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 04 Apr 2013 14:32:12 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DD8AA.5080506@matthew.at> Message-ID: <515DF15C.9050005@matthew.at> On 4/4/2013 1:29 PM, William Herrin wrote: > The board isn't willing to set the IPv6 fees for every ISP holding an > IPv6 /32 at $500, but they'll apparently accept making a smaller > allocation to an ISP for $500. Maybe we should get a different board then? > For that reason, I'd encourage you to support the proposal. Let's just > make sure they can convert to a /32 later without renumbering. > Regards, Bill Herrin Doesn't fix the root problem. ISPs should be getting /32s, and they should be charged fees which are affordable and reasonable when they do that. That ARIN wishes to make more money than that would bring in to fund whatever it does with that is a flaw that needs fixing and the PDP isn't going to be how that gets fixed. I'd rather have thousands of angry ISPs who can't afford the price of a /32 not deploying IPv6 because of that than having thousands of ISPs getting stupidly small allocations and then doing stupid internal conservation to keep their fees from rising when the whole point of a bigger address space was to avoid this altogether. One could make a good argument that if we made all the space allocated the way ULA is allocated that the statistical odds of collision are tiny and thus RIRs aren't even needed. Matthew Kaufman From owen at delong.com Thu Apr 4 17:34:00 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Apr 2013 14:34:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DD7A9.7010004@matthew.at> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DCD21.5000509@umn.edu> <515DD7A9.7010004@matthew.at> Message-ID: <89DE563E-D1C5-4D22-88A7-CD15CC8C0A8C@delong.com> On Apr 4, 2013, at 12:42 PM, Matthew Kaufman wrote: > On 4/4/2013 11:57 AM, David Farmer wrote: >> >> It all depends where they started using there blocks. The current use case for this policy is to reduce your holding because of the fee schedule > > Doesn't this just mean that the new fee schedule is broken? > Yes. However, we haven't yet found a good way to fix it, so we're contorting policy a little further to attempt to address the issue instead. > IPv6 addresses are by no means scarce... why are we treating them that way? If we gave someone a /32 and they aren't using all of it yet, they should just keep the /32. As was discussed earlier (and believe me, I'm no fan of this, but it does seem the best available outcome at this point), there are too many ISPs in the /32 category to sustain ARIN if /32 falls to $500/year. OTOH, there is a strong desire to provide support for ISPs that are in this XX-Small category in IPv4 (/22 or less) to be able to add IPv6 without having to pay more than the new fee structure for their IPv4 holdings. >> , but I'd prefer generic rules that allow flexibility for future conditions. > > Agreed. How about "you can't give us back anything but what we gave you" and "we won't have stupid fee schedules that ever encourage you to want to do otherwise". > This is a discussion about the manner in which they can give back part of what we gave them, so I'm not sure how the first part isn't already addressed. As to the latter, if you have a better fee structure proposal, I suggest submitting it to the ACSP and I'm sure the board will consider it. >> Also, this is the current operational practice we have now, to allow the LIR to select which /36 to retain. If someone started using their /32 in the middle why force them to renumber? >> > > Why force them to give up the /32 at all? Are we running out of them or something? No, it's all about the politics of money. Owen From owen at delong.com Thu Apr 4 17:40:20 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Apr 2013 14:40:20 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DED25.3080404@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DD8AA.5080506@matthew.at> <515DED25.3080404@umn.edu> Message-ID: I support this change. Owen On Apr 4, 2013, at 2:14 PM, David Farmer wrote: > On 4/4/13 15:29 , William Herrin wrote: >> Se la vie. Today, the battle we can win is getting IPv6, *any* IPv6, >> into the hands of ISPs who are willing to do it if it doesn't change >> their ARIN costs. The board isn't willing to set the IPv6 fees for >> every ISP holding an IPv6 /32 at $500, but they'll apparently accept >> making a smaller allocation to an ISP for $500. For that reason, I'd >> encourage you to support the proposal. >> >> Let's just make sure they can convert to a /32 later without renumbering. > > Actually, to that end I'll change the proposed 6.5.2.1 clause (g) adding "or renumbering" to the end of the first sentence, resulting in; > > g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to /32 or /36 at any time without additional justification or renumbering. Such expansions are not considered subsequent allocations. However, any expansions beyond /32 are considered subsequent allocations, and must conform to section 6.5.3. > > This makes the policy intent abundantly clear without specifying operational issues like the size of a reservation. > > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Apr 4 17:40:49 2013 From: owen at delong.com (Owen DeLong) Date: Thu, 4 Apr 2013 14:40:49 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DF095.4030701@matthew.at> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515DD8AA.5080506@matthew.at> <515DE7F8.2000200@umn.edu> <515DF095.4030701@matthew.at> Message-ID: <1C0CC67F-F259-494E-A5B1-EAF0937240CC@delong.com> +1 On Apr 4, 2013, at 2:28 PM, Matthew Kaufman wrote: > On 4/4/2013 1:52 PM, David Farmer wrote: >> On 4/4/13 14:46 , Matthew Kaufman wrote: >>> Totally oppose the below. There's no reason why we should ever be giving >>> an ISP something smaller than a /32. Fix the silly fee schedule. >> >> Current policy already allows /36s to be handed out, this adds /40s to that, and allow you to change it to /32 as you see fit. > > Well, that's a bug too. But certainly I don't think we should be handing out /40s to ISPs. Probably not /36s either. How about /32s only, and up to /16 with justification? > >> >>> If charging $1000 instead of $500 is a disincentive (I certainly think >>> it is) make the /32 be $500. >> >> I assume you didn't support the original version of the draft with /48s either, and your not opposed to the changes to the draft, but the policy intent overall. Or, is there something about the changes from the original draft that you oppose. >> > > Policy proposal as it stands exists only because of a bug in the fee schedule. No ISP in their right mind would request a /40 instead of a /36 (say) just because they can, given that initial allocation justification is identical. Except for the fee schedule of course. > >>> Matthew Kaufman >>> >>> ps. Example as to why I think it is a disincentive: I run a microwave >>> network linking multiple mountaintops serving the tiny needs of several >>> different non-profit organizations, all paid for out of my own pocket. >>> All of it is numbered out of legacy space I hold. Guess how much my wife >>> thinks I should spend per year on an IPv6 allocation from ARIN so that I >>> can add IPv6 to this network? I'll give you a hint: $500/year is too much. >> >> The last paragraph of the comments basically says that it would be better to have a different solution for the fee schedule, but that is out of scope of the PDP. >> > > I know it is. But this whole proposal is about working around the fee schedule instead of fixing the root problem (that some ISPs think the price for a /32 is too high and so incorrectly wish to get something smaller) > >> I'd be interested in talking with you about finding a way to meet such needs. >> > > You know where to find me :) > > Matthew Kaufman > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From sethm at rollernet.us Thu Apr 4 18:17:08 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 04 Apr 2013 15:17:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5153387E.6060700@arin.net> References: <5153387E.6060700@arin.net> Message-ID: <515DFBE4.8080100@rollernet.us> On 3/27/13 11:20 AM, ARIN wrote: > Draft Policy ARIN-2013-3 > Tiny IPv6 Allocations for ISPs > I can't honestly support this in any form because it's directly tied to the fee structure which is outside the scope of the PDP to influence. What if the fee structure gets changed in the future? ~Seth From farmer at umn.edu Thu Apr 4 18:53:43 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 04 Apr 2013 17:53:43 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DFBE4.8080100@rollernet.us> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> Message-ID: <515E0477.10706@umn.edu> On 4/4/13 17:17 , Seth Mattinen wrote: > On 3/27/13 11:20 AM, ARIN wrote: >> Draft Policy ARIN-2013-3 >> Tiny IPv6 Allocations for ISPs > > I can't honestly support this in any form because it's directly tied to > the fee structure which is outside the scope of the PDP to influence. > What if the fee structure gets changed in the future? If the lower ones go a way then, as was said no one in their right mind would choose /36 or /40. I can't imagine anything smaller, I just don't see room for more changes one the smaller side. At least without changing the IPv6 architecture and the /64 subnet standard, and that would be a big enough change that a whole bunch of assumptions need to change not just this one. Also, "/40 or smaller" for X-Small works well for end users, 93% are XX-Small, 5% are X-Small and 2% are Small.* *Dallas PPM - Policy Implementation & Experience Report, Slide 7 https://www.arin.net/participate/meetings/reports/ARIN_XXX/PDF/thursday/nobile_policy.pdf -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From narten at us.ibm.com Fri Apr 5 00:53:07 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 05 Apr 2013 00:53:07 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201304050453.r354r7nP028761@rotala.raleigh.ibm.com> Total of 93 messages in the last 7 days. script run at: Fri Apr 5 00:53:07 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.43% | 19 | 16.91% | 140509 | jcurran at arin.net 16.13% | 15 | 15.80% | 131284 | farmer at umn.edu 12.90% | 12 | 13.06% | 108566 | owen at delong.com 13.98% | 13 | 10.95% | 91036 | bill at herrin.us 6.45% | 6 | 5.37% | 44622 | bross at pobox.com 1.08% | 1 | 10.72% | 89065 | msrachellecross at gmail.com 5.38% | 5 | 4.27% | 35470 | matthew at matthew.at 2.15% | 2 | 3.71% | 30840 | sryerse at eclipse-networks.com 3.23% | 3 | 2.09% | 17387 | sethm at rollernet.us 2.15% | 2 | 2.37% | 19686 | frnkblk at iname.com 2.15% | 2 | 2.17% | 18011 | billdarte at gmail.com 2.15% | 2 | 1.75% | 14534 | scottleibrand at gmail.com 2.15% | 2 | 1.57% | 13070 | mike at nationwideinc.com 2.15% | 2 | 1.55% | 12896 | mueller at syr.edu 1.08% | 1 | 1.41% | 11678 | adudek16 at gmail.com 1.08% | 1 | 1.32% | 10935 | cblecker at gmail.com 1.08% | 1 | 1.28% | 10653 | admin at bango.org.bb 1.08% | 1 | 1.07% | 8864 | snoble at sonn.com 1.08% | 1 | 0.89% | 7359 | myamanis at japan-telecom.com 1.08% | 1 | 0.88% | 7309 | narten at us.ibm.com 1.08% | 1 | 0.88% | 7279 | dogwallah at gmail.com --------+------+--------+----------+------------------------ 100.00% | 93 |100.00% | 831053 | Total From farmer at umn.edu Fri Apr 5 08:23:29 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Apr 2013 07:23:29 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515DB53F.1060809@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> Message-ID: <515EC241.5050505@umn.edu> On 4/4/13 12:15 , David Farmer wrote: > Here is the update that I propose to submit tomorrow to meet the > publication deadline for the Barbados meeting. I believe it accurately > reflects the changes discussed so for. Any comments are appreciated. > > Thanks. Ok, here is another update that includes the changes discussed yesterday, and few others I found. I've also included a new section summarizing the community's discussion to this point, including the primary objection to the policy and how the policy attempts to mitigate it. Any additional comments are appreciated before I submit it to staff mid-day for publication in the Barbados meeting materials. Thanks -- Draft Policy ARIN-2013-3 Tiny IPv6 Allocations for ISPs Date: 5 April 2013 Problem Statement: ARIN's fee structure provides a graduated system wherein organizations pay based on the amount of number resources they consume. At the very bottom end of the scale, it is presently not possible to be an XX-Small ISP with an IPv6 allocation because the minimum allocation size of /36 automatically promotes one into X-Small ISP status, resulting in a doubling of annual fees. While tiny in absolute terms, the extra costs incurred represent a disincentive to IPv6 deployment. To the author's knowledge, it has never been possible for an LIR/ISP to get a /40 allocation direct from ARIN; such assignments have been limited to organizations that qualify as end sites or /48s for critical infrastructure. It is understood there is an expected correction of the XX-Small fee category to "/40 or smaller". Policy statement: Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at the end of the first sentence of subsection 6.5.2.1 clause (b), and add a new clause (g), resulting in; b. In no case shall an LIR receive smaller than a /32 unless they specifically request a /36 or /40. In no case shall an ISP receive more than a /16 initial allocation. ... g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to /32 or /36 at any time without renumbering or additional justification. Such expansions are not considered subsequent allocations. However, any expansions beyond /32 are considered subsequent allocations, and must conform to section 6.5.3. Part 2: Add a new subsection to section 6 "IPv6"; 6.12 Reduction or Return ARIN will accept the return of whole or partial block(s) allowing an organization to reduce their holdings as long as: a. The end result is not an increase in the number of aggregatable blocks held by the organization. b. Whole blocks are returned to the extent practicable. c. Partial block(s) retained must conform to current applicable allocation or assignment policies, as to size, alignment, etc? d. Block(s) retained are within a single reserved space or aggregate set aside for the organization in the ARIN database to the extent practicable. e. All returned block(s) must not be in use by the organization or its customers. Comments: The author acknowledges the shortcomings of providing an ISP with an allocation of a size that is more traditionally associated with end sites. In order to avoid possible bad effects on the routing table, the author encourages ARIN staff to adopt the same sparse allocation practice as currently exists for larger allocations, ideally even reserving a block as large as the /28 that is reserved for /32s currently. Note the policy intent of part 1 requires a minimum of a /32 be reserved. Part 1 brings ARIN's allocation policies in line with the upcoming fee schedule, with the addition of an expected correction of the XX-Small fee category to "/40 or smaller". This makes it possible to qualify for each ISP fee category while holding IPv6 number resources and allows expansion up to /32 without renumbering or additional justification as a subsequent allocation. The selection of a /32, /36 or /40 allocation is only driven by an ISP's own internal business justifications. Part 2 codifies and expands upon current practice for selective return in the manner described by John Curran on the arin-discuss mailing list (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ). It specifies the generic requirements that should be met for such returns. A more practical approach might to figure out a way to apply graduated fees to ISPs at the very small end of the scale using some metric other than prefix size. Fee schedules are outside of the purview of the Policy Development Process; such responsibility lies with the Board should they choose to take it up. Summary of community discussion: The fundamental argument against this draft policy is that the primary problem being solved is a billing or fee structure issue and not a number resource policy issue in itself. A significant minority of the community would prefer /32 be the sole minimum allocation size for ISPs and other LIRs, and they feel there is no need for smaller /36 or /40 allocations. They would prefer to solve the problem with changes in the fee structure rather than contorting number resource policy to solve the problem. However, there are to many ISPs that fit into the /32 allocation category for the fee level associated with the XX-Small category to be fiscally responsible and sustainable for ARIN. Furthermore, there are no obvious solutions to this problem within the fee structure domain that are fiscally responsible and sustainable for ARIN, especially in the long-term. Everyone agrees making /36 or /40 allocations to ISPs seems less than ideal from a number resource policy perspective. However, this is mitigated by ensuring that all ISPs have a /32 available to them without renumbering or additional justification and from a number resource policy perspective the selection of /36 or /40 allocations is completely voluntary. This allows each ISPs to make the decision to select from a /32, /36 or /40 initial allocation based solely on their own internal business justifications, and eliminating structural disincentives in the fee schedule for IPv6 adoption. This seems like the best balance available at this time of number resource policy, fiscal responsibility and sustainability for both ARIN and the ISPs that it servers. Timetable for implementation: Immediate -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bjones at vt.edu Fri Apr 5 09:22:33 2013 From: bjones at vt.edu (Brian Jones) Date: Fri, 5 Apr 2013 09:22:33 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EC241.5050505@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> Message-ID: I agree that you have summarized group discussion accurately. -- Brian On Fri, Apr 5, 2013 at 8:23 AM, David Farmer wrote: > On 4/4/13 12:15 , David Farmer wrote: > >> Here is the update that I propose to submit tomorrow to meet the >> publication deadline for the Barbados meeting. I believe it accurately >> reflects the changes discussed so for. Any comments are appreciated. >> >> Thanks. >> > > Ok, here is another update that includes the changes discussed yesterday, > and few others I found. I've also included a new section summarizing the > community's discussion to this point, including the primary objection to > the policy and how the policy attempts to mitigate it. > > Any additional comments are appreciated before I submit it to staff > mid-day for publication in the Barbados meeting materials. > > Thanks > > -- > > > Draft Policy ARIN-2013-3 > Tiny IPv6 Allocations for ISPs > > Date: 5 April 2013 > > Problem Statement: > > ARIN's fee structure provides a graduated system wherein organizations pay > based on the amount of number resources they consume. > > At the very bottom end of the scale, it is presently not possible to be an > XX-Small ISP with an IPv6 allocation because the minimum allocation size of > /36 automatically promotes one into X-Small ISP status, resulting in a > doubling of annual fees. > > > While tiny in absolute terms, the extra costs incurred represent a > disincentive to IPv6 deployment. > > To the author's knowledge, it has never been possible for an LIR/ISP to > get a /40 allocation direct from ARIN; such assignments have been limited > to organizations that qualify as end sites or /48s for critical > infrastructure. It is understood there is an expected correction of the > XX-Small fee category to "/40 or smaller". > > > Policy statement: > > Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at > the end of the first sentence of subsection 6.5.2.1 clause (b), and add a > new clause (g), resulting in; > > b. In no case shall an LIR receive smaller than a /32 unless they > specifically request a /36 or /40. In no case shall an ISP receive more > than a /16 initial allocation. > > ... > > g. An LIR that requests a smaller /36 or /40 allocation is entitled to > expand the allocation to /32 or /36 at any time without renumbering or > additional justification. Such expansions are not considered subsequent > allocations. However, any expansions beyond /32 are considered subsequent > allocations, and must conform to section 6.5.3. > > > Part 2: Add a new subsection to section 6 "IPv6"; > > 6.12 Reduction or Return > > ARIN will accept the return of whole or partial block(s) allowing an > organization to reduce their holdings as long as: > > a. The end result is not an increase in the number of aggregatable blocks > held by the organization. > > > b. Whole blocks are returned to the extent practicable. > > c. Partial block(s) retained must conform to current applicable allocation > or assignment policies, as to size, alignment, etc? > > d. Block(s) retained are within a single reserved space or aggregate set > aside for the organization in the ARIN database to the extent practicable. > > > e. All returned block(s) must not be in use by the organization or its > customers. > > Comments: > > The author acknowledges the shortcomings of providing an ISP with an > allocation of a size that is more traditionally associated with end sites. > In order to avoid possible bad effects on the routing table, the author > encourages ARIN staff to adopt the same sparse allocation practice as > currently exists for larger allocations, ideally even reserving a block as > large as the /28 that is reserved for /32s currently. Note the policy > intent of part 1 requires a minimum of a /32 be reserved. > > Part 1 brings ARIN's allocation policies in line with the upcoming fee > schedule, with the addition of an expected correction of the XX-Small fee > category to "/40 or smaller". This makes it possible to qualify for each > ISP fee category while holding IPv6 number resources and allows expansion > up to /32 without renumbering or additional justification as a subsequent > allocation. The selection of a /32, /36 or /40 allocation is only driven > by an ISP's own internal business justifications. > > Part 2 codifies and expands upon current practice for selective return in > the manner described by John Curran on the arin-discuss mailing list > (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3** > 748F9239EA at CHAXCH01.corp.arin.**net<8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net>). It specifies the generic requirements that should be met for such > returns. > > > A more practical approach might to figure out a way to apply graduated > fees to ISPs at the very small end of the scale using some metric other > than prefix size. Fee schedules are outside of the purview of the Policy > Development Process; such responsibility lies with the Board should they > choose to take it up. > > Summary of community discussion: > > The fundamental argument against this draft policy is that the primary > problem being solved is a billing or fee structure issue and not a number > resource policy issue in itself. A significant minority of the community > would prefer /32 be the sole minimum allocation size for ISPs and other > LIRs, and they feel there is no need for smaller /36 or /40 allocations. > They would prefer to solve the problem with changes in the fee structure > rather than contorting number resource policy to solve the problem. > However, there are to many ISPs that fit into the /32 allocation category > for the fee level associated with the XX-Small category to be fiscally > responsible and sustainable for ARIN. Furthermore, there are no obvious > solutions to this problem within the fee structure domain that are fiscally > responsible and sustainable for ARIN, especially in the long-term. > > Everyone agrees making /36 or /40 allocations to ISPs seems less than > ideal from a number resource policy perspective. However, this is > mitigated by ensuring that all ISPs have a /32 available to them without > renumbering or additional justification and from a number resource policy > perspective the selection of /36 or /40 allocations is completely > voluntary. This allows each ISPs to make the decision to select from a > /32, /36 or /40 initial allocation based solely on their own internal > business justifications, and eliminating structural disincentives in the > fee schedule for IPv6 adoption. This seems like the best balance available > at this time of number resource policy, fiscal responsibility and > sustainability for both ARIN and the ISPs that it servers. > > Timetable for implementation: Immediate > > > -- > ==============================**================== > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ==============================**================== > ______________________________**_________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Apr 5 09:45:28 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Apr 2013 08:45:28 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> Message-ID: <515ED578.6010508@umn.edu> On 4/5/13 08:31 , William Herrin wrote: > On Fri, Apr 5, 2013 at 8:23 AM, David Farmer wrote: >> g. An LIR that requests a smaller /36 or /40 allocation is entitled to >> expand the allocation to /32 or /36 at any time without renumbering or >> additional justification. > > Hi David, > > This could be misread to mean "/32 or /36 respectively" instead of > "either /32 or /36 as the registrant chooses." That's was bugging me too, but I wasn't sure how to fix it. How about; g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to either /32 or /36 at any time without renumbering or additional justification. ... Does that cover it without getting to wordy? >> e. All returned block(s) must not be in use by the organization or its >> customers. > > This verbiage is a little clumsy. I'm not sure how to word it better. How about; e. All block(s) returned must not be in use by the organization or its customers. Not a big change but it read a little better. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bill at herrin.us Fri Apr 5 09:31:57 2013 From: bill at herrin.us (William Herrin) Date: Fri, 5 Apr 2013 09:31:57 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EC241.5050505@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> Message-ID: On Fri, Apr 5, 2013 at 8:23 AM, David Farmer wrote: > g. An LIR that requests a smaller /36 or /40 allocation is entitled to > expand the allocation to /32 or /36 at any time without renumbering or > additional justification. Hi David, This could be misread to mean "/32 or /36 respectively" instead of "either /32 or /36 as the registrant chooses." > e. All returned block(s) must not be in use by the organization or its > customers. This verbiage is a little clumsy. I'm not sure how to word it better. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From JOHN at egh.com Fri Apr 5 10:07:32 2013 From: JOHN at egh.com (John Santos) Date: Fri, 5 Apr 2013 10:07:32 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: Message-ID: <1130405100550.2488A-100000@Ives.egh.com> On Fri, 5 Apr 2013, William Herrin wrote: > On Fri, Apr 5, 2013 at 8:23 AM, David Farmer wrote: > > g. An LIR that requests a smaller /36 or /40 allocation is entitled to > > expand the allocation to /32 or /36 at any time without renumbering or > > additional justification. > > Hi David, > > This could be misread to mean "/32 or /36 respectively" instead of > "either /32 or /36 as the registrant chooses." > > > > e. All returned block(s) must not be in use by the organization or its > > customers. > > This verbiage is a little clumsy. I'm not sure how to word it better. > > -Bill How about: e. No returned block may be in use by the organization or its customers. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From bill at herrin.us Fri Apr 5 11:07:05 2013 From: bill at herrin.us (William Herrin) Date: Fri, 5 Apr 2013 11:07:05 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515ED578.6010508@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <515ED578.6010508@umn.edu> Message-ID: On Fri, Apr 5, 2013 at 9:45 AM, David Farmer wrote: > On 4/5/13 08:31 , William Herrin wrote: >> This could be misread to mean "/32 or /36 respectively" instead of >> "either /32 or /36 as the registrant chooses." > > That's was bugging me too, but I wasn't sure how to fix it. How about; > > g. An LIR that requests a smaller /36 or /40 allocation is entitled to > expand the allocation to either /32 or /36 at any time without renumbering > or additional justification. ... > > Does that cover it without getting to wordy? Hi David, I'm not sure if "either" makes a difference. Maybe "expand the allocation to a choice of /36 or /32.: Might also help to reverse the order of /32 and /36 so that "respectively" doesn't fit right. Or redo the whole sentence as something like, "A LIR that requests a smaller than /32 allocation is entitled to expand the allocation to a choice of /36 or /32 at any time [...]" > e. All block(s) returned must not be in use by the organization or its > customers. > > Not a big change but it read a little better. It's the "All [] must not" construction that seems clumsy to me. Normally it's "all must" or "no may." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From farmer at umn.edu Fri Apr 5 11:25:21 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Apr 2013 10:25:21 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <515ED578.6010508@umn.edu> Message-ID: <515EECE1.105@umn.edu> On 4/5/13 10:07 , William Herrin wrote: > On Fri, Apr 5, 2013 at 9:45 AM, David Farmer wrote: >> On 4/5/13 08:31 , William Herrin wrote: >>> This could be misread to mean "/32 or /36 respectively" instead of >>> "either /32 or /36 as the registrant chooses." >> >> That's was bugging me too, but I wasn't sure how to fix it. How about; >> >> g. An LIR that requests a smaller /36 or /40 allocation is entitled to >> expand the allocation to either /32 or /36 at any time without renumbering >> or additional justification. ... >> >> Does that cover it without getting to wordy? > > Hi David, > > I'm not sure if "either" makes a difference. Maybe "expand the > allocation to a choice of /36 or /32.: Might also help to reverse the > order of /32 and /36 so that "respectively" doesn't fit right. > > Or redo the whole sentence as something like, "A LIR that requests a > smaller than /32 allocation is entitled to expand the allocation to a > choice of /36 or /32 at any time [...]" OK; g. An LIR that requests smaller than /32 allocation is entitled to expand the allocation to a choice of /36 or /32 at any time without renumbering or additional justification. ... >> e. All block(s) returned must not be in use by the organization or its >> customers. >> >> Not a big change but it read a little better. > > It's the "All [] must not" construction that seems clumsy to me. > Normally it's "all must" or "no may." How about; e. All block(s) returned are not in use by the organization or its customers. Which should be read as; ARIN will accept the return of whole or partial block(s) allowing an organization to reduce their holdings as long as: e. All block(s) returned are not in use by the organization or its customers. Better? -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From owen at delong.com Fri Apr 5 11:58:22 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Apr 2013 08:58:22 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515ED578.6010508@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <515ED578.6010508@umn.edu> Message-ID: How about "...expand the allocation to any nibble aligned size up to /32 without renumbering or additional..." Owen On Apr 5, 2013, at 06:45 , David Farmer wrote: > On 4/5/13 08:31 , William Herrin wrote: >> On Fri, Apr 5, 2013 at 8:23 AM, David Farmer wrote: >>> g. An LIR that requests a smaller /36 or /40 allocation is entitled to >>> expand the allocation to /32 or /36 at any time without renumbering or >>> additional justification. >> >> Hi David, >> >> This could be misread to mean "/32 or /36 respectively" instead of >> "either /32 or /36 as the registrant chooses." > > That's was bugging me too, but I wasn't sure how to fix it. How about; > > g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to either /32 or /36 at any time without renumbering or additional justification. ... > > Does that cover it without getting to wordy? > >>> e. All returned block(s) must not be in use by the organization or its >>> customers. >> >> This verbiage is a little clumsy. I'm not sure how to word it better. > > How about; > > e. All block(s) returned must not be in use by the organization or its customers. > > Not a big change but it read a little better. > > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Fri Apr 5 12:07:07 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 5 Apr 2013 09:07:07 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EC241.5050505@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> Message-ID: <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> > a. The end result is not an increase in the number of aggregatable blocks held by the organization. > This is problematic. This would allow an increase in the number of non-aggregatable blocks. While I'm not 100% sure that it is possible to create such a situation, I would rather see us express the direct intent. How about: a. The resulting number of aggregate retained blocks must not increase. > b. Whole blocks are returned to the extent practicable. > > c. Partial block(s) retained must conform to current applicable allocation or assignment policies, as to size, alignment, etc? > > d. Block(s) retained are within a single reserved space or aggregate set aside for the organization in the ARIN database to the extent practicable. > > e. All returned block(s) must not be in use by the organization or its customers. > > Comments: > > The author acknowledges the shortcomings of providing an ISP with an allocation of a size that is more traditionally associated with end sites. In order to avoid possible bad effects on the routing table, the author encourages ARIN staff to adopt the same sparse allocation practice as currently exists for larger allocations, ideally even reserving a block as large as the /28 that is reserved for /32s currently. Note the policy intent of part 1 requires a minimum of a /32 be reserved. > > Part 1 brings ARIN's allocation policies in line with the upcoming fee schedule, with the addition of an expected correction of the XX-Small fee category to "/40 or smaller". This makes it possible to qualify for each ISP fee category while holding IPv6 number resources and allows expansion up to /32 without renumbering or additional justification as a subsequent allocation. The selection of a /32, /36 or /40 allocation is only driven by an ISP's own internal business justifications. > > Part 2 codifies and expands upon current practice for selective return in the manner described by John Curran on the arin-discuss mailing list (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ). It specifies the generic requirements that should be met for such returns. > > A more practical approach might to figure out a way to apply graduated fees to ISPs at the very small end of the scale using some metric other than prefix size. Fee schedules are outside of the purview of the Policy Development Process; such responsibility lies with the Board should they choose to take it up. > > Summary of community discussion: > > The fundamental argument against this draft policy is that the primary problem being solved is a billing or fee structure issue and not a number resource policy issue in itself. A significant minority of the community would prefer /32 be the sole minimum allocation size for ISPs and other LIRs, and they feel there is no need for smaller /36 or /40 allocations. They would prefer to solve the problem with changes in the fee structure rather than contorting number resource policy to solve the problem. However, there are to many ISPs that fit into the /32 allocation category for the fee level associated with the XX-Small category to be fiscally responsible and sustainable for ARIN. Furthermore, there are no obvious solutions to this problem within the fee structure domain that are fiscally responsible and sustainable for ARIN, especially in the long-term. I would not call this "A significant minority". Rather, I would say that a significant minority are adamant to the extent they oppose this policy. I believe the vast majority of the community would prefer to see /32 be the sole minimum, but that most are willing to accept the tradeoffs incorporated into this policy. I believe that if we had an effective way to solve the problem through fee structure changes that was acceptable to the vast majority, it would be the preferred solution. I encourage anyone who has ideas of such a solution to please make them known to the community either here or on arin-discuss. While fees are outside of the policy process, at the point we start contorting policy to address problems with the fee structure, I certainly think it is appropriate to discuss the problems with the fee structure directly in that context. > Everyone agrees making /36 or /40 allocations to ISPs seems less than ideal from a number resource policy perspective. However, this is mitigated by ensuring that all ISPs have a /32 available to them without renumbering or additional justification and from a number resource policy perspective the selection of /36 or /40 allocations is completely voluntary. This allows each ISPs to make the decision to select from a /32, /36 or /40 initial allocation based solely on their own internal business justifications, and eliminating structural disincentives in the fee schedule for IPv6 adoption. This seems like the best balance available at this time of number resource policy, fiscal responsibility and sustainability for both ARIN and the ISPs that it servers. I would rather see the reservation set to a minimum of /28, personally, but /32 is better than smaller. Is there anyone in the community that objects to a minimum /28 reservation (which is the current situation for recipients of /32s)? Owen From sethm at rollernet.us Fri Apr 5 12:24:50 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Apr 2013 09:24:50 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515E0477.10706@umn.edu> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> Message-ID: <515EFAD2.1010101@rollernet.us> On 4/4/13 3:53 PM, David Farmer wrote: > > If the lower ones go a way then, as was said no one in their right mind > would choose /36 or /40. I can't imagine anything smaller, I just don't > see room for more changes one the smaller side. At least without > changing the IPv6 architecture and the /64 subnet standard, and that > would be a big enough change that a whole bunch of assumptions need to > change not just this one. I would want to see verbiage in the policy that would immediately revoke/revert it if any fee schedule changes are made. If we're going to start making policy based on the fees then we should have to rerun them through the them the PDP anytime the fees they are based on change. ~Seth From farmer at umn.edu Fri Apr 5 12:31:53 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Apr 2013 11:31:53 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EFAD2.1010101@rollernet.us> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> Message-ID: <515EFC79.9080406@umn.edu> On 4/5/13 11:24 , Seth Mattinen wrote: > On 4/4/13 3:53 PM, David Farmer wrote: >> >> If the lower ones go a way then, as was said no one in their right mind >> would choose /36 or /40. I can't imagine anything smaller, I just don't >> see room for more changes one the smaller side. At least without >> changing the IPv6 architecture and the /64 subnet standard, and that >> would be a big enough change that a whole bunch of assumptions need to >> change not just this one. > > I would want to see verbiage in the policy that would immediately > revoke/revert it if any fee schedule changes are made. If we're going to > start making policy based on the fees then we should have to rerun them > through the them the PDP anytime the fees they are based on change. I'm not going to include that right now but I will raise that question at the Barbados meeting. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From sethm at rollernet.us Fri Apr 5 12:37:13 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Apr 2013 09:37:13 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EFC79.9080406@umn.edu> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> Message-ID: <515EFDB9.2010700@rollernet.us> On 4/5/13 9:31 AM, David Farmer wrote: > On 4/5/13 11:24 , Seth Mattinen wrote: >> On 4/4/13 3:53 PM, David Farmer wrote: >>> >>> If the lower ones go a way then, as was said no one in their right mind >>> would choose /36 or /40. I can't imagine anything smaller, I just don't >>> see room for more changes one the smaller side. At least without >>> changing the IPv6 architecture and the /64 subnet standard, and that >>> would be a big enough change that a whole bunch of assumptions need to >>> change not just this one. >> >> I would want to see verbiage in the policy that would immediately >> revoke/revert it if any fee schedule changes are made. If we're going to >> start making policy based on the fees then we should have to rerun them >> through the them the PDP anytime the fees they are based on change. > > I'm not going to include that right now but I will raise that question > at the Barbados meeting. > I see no reason to have a policy motivated strictly by fees to remain after fee changes that may or may not negate it, and to determine that it should go back through the PDP. Otherwise we're just cluttering the NRPM with irrelevant policy. ~Seth From kkargel at polartel.com Fri Apr 5 12:41:41 2013 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 5 Apr 2013 11:41:41 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EFDB9.2010700@rollernet.us> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> Message-ID: <8695009A81378E48879980039EEDAD28012438E564@MAIL1.polartel.local> I am still trying to figure out how having one *additional* database entry costs $1000/year. Kevin -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Seth Mattinen Sent: Friday, April 05, 2013 11:37 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs On 4/5/13 9:31 AM, David Farmer wrote: > On 4/5/13 11:24 , Seth Mattinen wrote: >> On 4/4/13 3:53 PM, David Farmer wrote: >>> >>> If the lower ones go a way then, as was said no one in their right >>> mind would choose /36 or /40. I can't imagine anything smaller, I >>> just don't see room for more changes one the smaller side. At least >>> without changing the IPv6 architecture and the /64 subnet standard, >>> and that would be a big enough change that a whole bunch of >>> assumptions need to change not just this one. >> >> I would want to see verbiage in the policy that would immediately >> revoke/revert it if any fee schedule changes are made. If we're going >> to start making policy based on the fees then we should have to rerun >> them through the them the PDP anytime the fees they are based on change. > > I'm not going to include that right now but I will raise that question > at the Barbados meeting. > I see no reason to have a policy motivated strictly by fees to remain after fee changes that may or may not negate it, and to determine that it should go back through the PDP. Otherwise we're just cluttering the NRPM with irrelevant policy. ~Seth _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bill at herrin.us Fri Apr 5 12:45:04 2013 From: bill at herrin.us (William Herrin) Date: Fri, 5 Apr 2013 12:45:04 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8695009A81378E48879980039EEDAD28012438E564@MAIL1.polartel.local> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8695009A81378E48879980039EEDAD28012438E564@MAIL1.polartel.local> Message-ID: On Fri, Apr 5, 2013 at 12:41 PM, Kevin Kargel wrote: > I am still trying to figure out how having one *additional* database entry costs $1000/year. Registration in the database: $25/year Your share of the overhead costs of running a registry: $975/year Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bross at pobox.com Fri Apr 5 12:46:26 2013 From: bross at pobox.com (Brandon Ross) Date: Fri, 5 Apr 2013 12:46:26 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EFDB9.2010700@rollernet.us> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> Message-ID: On Fri, 5 Apr 2013, Seth Mattinen wrote: > I see no reason to have a policy motivated strictly by fees to remain after > fee changes that may or may not negate it, and to determine that it should go > back through the PDP. Otherwise we're just cluttering the NRPM with > irrelevant policy. But the problem is that you don't know how the fee schedule might change in the future, and it would be nearly impossible to capture every possible permutation and create a rational outcome. -- Brandon Ross Yahoo & AIM: BrandonNRoss +1-404-635-6667 ICQ: 2269442 Schedule a meeting: https://doodle.com/bross Skype: brandonross From farmer at umn.edu Fri Apr 5 12:47:49 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Apr 2013 11:47:49 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EFDB9.2010700@rollernet.us> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> Message-ID: <515F0035.3030401@umn.edu> On 4/5/13 11:37 , Seth Mattinen wrote: > On 4/5/13 9:31 AM, David Farmer wrote: >> On 4/5/13 11:24 , Seth Mattinen wrote: >>> On 4/4/13 3:53 PM, David Farmer wrote: >>>> >>>> If the lower ones go a way then, as was said no one in their right mind >>>> would choose /36 or /40. I can't imagine anything smaller, I just >>>> don't >>>> see room for more changes one the smaller side. At least without >>>> changing the IPv6 architecture and the /64 subnet standard, and that >>>> would be a big enough change that a whole bunch of assumptions need to >>>> change not just this one. >>> >>> I would want to see verbiage in the policy that would immediately >>> revoke/revert it if any fee schedule changes are made. If we're going to >>> start making policy based on the fees then we should have to rerun them >>> through the them the PDP anytime the fees they are based on change. >> >> I'm not going to include that right now but I will raise that question >> at the Barbados meeting. > > I see no reason to have a policy motivated strictly by fees to remain > after fee changes that may or may not negate it, and to determine that > it should go back through the PDP. Otherwise we're just cluttering the > NRPM with irrelevant policy. This would essentially be a sunset-clause, we had issues the last time we tried on of those. I'm not saying we can't or shouldn't do it but that I want more input before I add one into this policy. Note: we can't adopt this after Barbados it has to come back to the policy consultation at NANOG in June as a Recommended Draft Policy before it can be adopted. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From farmer at umn.edu Fri Apr 5 13:12:19 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Apr 2013 12:12:19 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> Message-ID: <515F05F3.2000802@umn.edu> On 4/5/13 11:07 , Owen DeLong wrote: >> a. The end result is not an increase in the number of aggregatable blocks held by the organization. >> > > This is problematic. This would allow an increase in the number of non-aggregatable blocks. While I'm not 100% sure that it is possible to create such a situation, I would rather see us express the direct intent. How about: > > a. The resulting number of aggregate retained blocks must not increase. Ok, I'll go with that. >> The fundamental argument against this draft policy is that the primary problem being solved is a billing or fee structure issue and not a number resource policy issue in itself. A significant minority of the community would prefer /32 be the sole minimum allocation size for ISPs and other LIRs, and they feel there is no need for smaller /36 or /40 allocations. They would prefer to solve the problem with changes in the fee structure rather than contorting number resource policy to solve the problem. However, there are to many ISPs that fit into the /32 allocation category for the fee level associated with the XX-Small category to be fiscally responsible and sustainable for ARIN. Furthermore, there are no obvious solutions to this problem within the fee structure domain that are fiscally responsible and sustainable for ARIN, especially in the long-term. > > I would not call this "A significant minority". Rather, I would say that a significant minority are adamant to the extent they oppose this policy. I believe the vast majority of the community would prefer to see /32 be the sole minimum, but that most are willing to accept the tradeoffs incorporated into this policy. I believe that if we had an effective way to solve the problem through fee structure changes that was acceptable to the vast majority, it would be the preferred solution. I encourage anyone who has ideas of such a solution to please make them known to the community either here or on arin-discuss. While fees are outside of the policy process, at the point we start contorting policy to address problems with the fee structure, I certainly think it is appropriate to discuss the problems with the fee structure directly in that context. Ok how about this then; The fundamental argument against this draft policy is that the primary problem being solved is a billing or fee structure issue and not a number resource policy issue in itself. A significant minority are adamant on this issue to the extent they oppose this policy. The majority of the community recognizes this issue, and would prefer /32 be the sole minimum allocation size for ISPs and other LIRs. However, the majority are willing to accept the tradeoffs incorporated into this policy. As there are too many ISPs that fit into the /32 allocation category for the fee level associated with the XX-Small category to be fiscally responsible and sustainable for ARIN. Furthermore, there are no obvious solutions to this problem within the fee structure domain that are fiscally responsible and sustainable for ARIN, especially in the long-term. >> Everyone agrees making /36 or /40 allocations to ISPs seems less than ideal from a number resource policy perspective. However, this is mitigated by ensuring that all ISPs have a /32 available to them without renumbering or additional justification and from a number resource policy perspective the selection of /36 or /40 allocations is completely voluntary. This allows each ISPs to make the decision to select from a /32, /36 or /40 initial allocation based solely on their own internal business justifications, and eliminating structural disincentives in the fee schedule for IPv6 adoption. This seems like the best balance available at this time of number resource policy, fiscal responsibility and sustainability for both ARIN and the ISPs that it servers. > > I would rather see the reservation set to a minimum of /28, personally, but /32 is better than smaller. In the comments section there is a suggestion that /28 reservations should be made, that is an operational issue. The policy issue is that they can get up to /32 for sure without renumbering. So from my perspective, a /32 reservation is a policy imperative, /28 is a recommendation for operational practice. > Is there anyone in the community that objects to a minimum /28 reservation (which is the current situation for recipients of /32s)? I haven't heard anyone object. > Owen > > -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bjones at vt.edu Fri Apr 5 13:21:58 2013 From: bjones at vt.edu (Brian Jones) Date: Fri, 5 Apr 2013 13:21:58 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515F05F3.2000802@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> <515F05F3.2000802@umn.edu> Message-ID: This seems like a reasonable and sensible approach from my perspective. It maintains the current practice and therefore creates less opportunity for confusion or error. -- Brian E Jones Director Converged Network Operations NI&S Virginia Tech bjones at vt.edu > Is there anyone in the community that objects to a minimum /28 >> reservation (which is the current situation for recipients of /32s)? >> > > I haven't heard anyone object. > > Owen >> >> >> > > -- > ==============================**================== > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ==============================**================== > ______________________________**_________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Fri Apr 5 13:26:43 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Apr 2013 10:26:43 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> Message-ID: <515F0953.8050202@rollernet.us> On 4/5/13 9:46 AM, Brandon Ross wrote: > On Fri, 5 Apr 2013, Seth Mattinen wrote: > >> I see no reason to have a policy motivated strictly by fees to remain >> after fee changes that may or may not negate it, and to determine that >> it should go back through the PDP. Otherwise we're just cluttering the >> NRPM with irrelevant policy. > > But the problem is that you don't know how the fee schedule might change > in the future, and it would be nearly impossible to capture every > possible permutation and create a rational outcome. > That's why I oppose fee-motivated policy in the first place. ~Seth From sethm at rollernet.us Fri Apr 5 13:29:37 2013 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 05 Apr 2013 10:29:37 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515F0035.3030401@umn.edu> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <515F0035.3030401@umn.edu> Message-ID: <515F0A01.6020301@rollernet.us> On 4/5/13 9:47 AM, David Farmer wrote: > On 4/5/13 11:37 , Seth Mattinen wrote: >> >> I see no reason to have a policy motivated strictly by fees to remain >> after fee changes that may or may not negate it, and to determine that >> it should go back through the PDP. Otherwise we're just cluttering the >> NRPM with irrelevant policy. > > This would essentially be a sunset-clause, we had issues the last time > we tried on of those. I'm not saying we can't or shouldn't do it but > that I want more input before I add one into this policy. > > Note: we can't adopt this after Barbados it has to come back to the > policy consultation at NANOG in June as a Recommended Draft Policy > before it can be adopted. > I'm thinking more drastic, as in "fee schedule changed, instantly struck". The policy proposal is dependent on fees, nothing more. So let it be dependent on the possibly of those fees changing and force it to go back through the PDP as soon as that happens. ~Seth From farmer at umn.edu Fri Apr 5 13:33:19 2013 From: farmer at umn.edu (David Farmer) Date: Fri, 05 Apr 2013 12:33:19 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <515ED578.6010508@umn.edu> Message-ID: <515F0ADF.3090305@umn.edu> On 4/5/13 10:58 , Owen DeLong wrote: > How about "...expand the allocation to any nibble aligned size up to /32 without renumbering or additional..." > > Owen OK, That was a helpful suggestion. How about this; g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to any nibble aligned size up to /32 at any time without renumbering or additional justification. ... > On Apr 5, 2013, at 06:45 , David Farmer wrote: > >> On 4/5/13 08:31 , William Herrin wrote: >>> On Fri, Apr 5, 2013 at 8:23 AM, David Farmer wrote: >>>> g. An LIR that requests a smaller /36 or /40 allocation is entitled to >>>> expand the allocation to /32 or /36 at any time without renumbering or >>>> additional justification. >>> >>> Hi David, >>> >>> This could be misread to mean "/32 or /36 respectively" instead of >>> "either /32 or /36 as the registrant chooses." >> >> That's was bugging me too, but I wasn't sure how to fix it. How about; >> >> g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to either /32 or /36 at any time without renumbering or additional justification. ... >> >> Does that cover it without getting to wordy? >> >>>> e. All returned block(s) must not be in use by the organization or its >>>> customers. >>> >>> This verbiage is a little clumsy. I'm not sure how to word it better. >> >> How about; >> >> e. All block(s) returned must not be in use by the organization or its customers. >> >> Not a big change but it read a little better. -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From bill at herrin.us Fri Apr 5 13:27:20 2013 From: bill at herrin.us (William Herrin) Date: Fri, 5 Apr 2013 13:27:20 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515F05F3.2000802@umn.edu> References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> <515F05F3.2000802@umn.edu> Message-ID: On Fri, Apr 5, 2013 at 1:12 PM, David Farmer wrote: > Furthermore, there are no obvious solutions to this problem within the fee > structure domain that are fiscally responsible and sustainable for ARIN, > especially in the long-term. Hi David, The obvious solutions within the fee structure are: 1. The non-profit discount 2. No-fee IPv6 for IPv4 holders until IPv6 becomes dominant #2 solves the short-term problem of folks who won't spend money on a protocol that won't yet make them money while #1 addresses the community network need. Both meet the fiscal responsibility test: #2 goes away before IPv4's ability to fund ARIN wanes and the general-purpose appropriateness of discounting services on behalf of non-profits is long established. For the for-profit ISPs after IPv6 becomes the dominant protocol... $2000/year to be in the for-profit Internet business is no hardship. So, it's not exactly accurate to say that, "there are no obvious solutions to this problem within the fee structure domain." That the board resists the obvious solutions doesn't make them any less obvious. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gary.buhrmaster at gmail.com Fri Apr 5 14:37:51 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 5 Apr 2013 18:37:51 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> <515F05F3.2000802@umn.edu> Message-ID: On Fri, Apr 5, 2013 at 5:27 PM, William Herrin wrote: .... > The obvious solutions within the fee structure are: > > 1. The non-profit discount > > 2. No-fee IPv6 for IPv4 holders until IPv6 becomes dominant > > > #2 solves the short-term problem of folks who won't spend money on a > protocol that won't yet make them money while #1 addresses the > community network need. NRPM section 6.5.9 already (to some extent) addresses the community network need, which allows community networks to request a /48 (/44 with justification). I have previous pointed to the boards decision to not provide a non-profit discount schedule, and while I can understand their reasoning, I also think in reality to get 501(c) qualified it can easily take $1000/yr (opportunity costs, if not out of pocket), so it is not really a solution for many to achieve a substantive savings in ARIN fees. [And 501(c) (or country equivalent) should be the requirement, not yet another definition by ARIN of what a non-profit might be.] Gary From ikiris at gmail.com Fri Apr 5 16:20:53 2013 From: ikiris at gmail.com (Blake Dunlap) Date: Fri, 5 Apr 2013 15:20:53 -0500 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> <515F05F3.2000802@umn.edu> Message-ID: I also opposed minimums for ISPs below /32 based on an issue of business model for ARIN. Fix the billing problem, or the board membership problem, don't try to make this a technical solution to a business problem. -Blake On Fri, Apr 5, 2013 at 1:37 PM, Gary Buhrmaster wrote: > On Fri, Apr 5, 2013 at 5:27 PM, William Herrin wrote: > .... > > The obvious solutions within the fee structure are: > > > > 1. The non-profit discount > > > > 2. No-fee IPv6 for IPv4 holders until IPv6 becomes dominant > > > > > > #2 solves the short-term problem of folks who won't spend money on a > > protocol that won't yet make them money while #1 addresses the > > community network need. > > NRPM section 6.5.9 already (to some extent) addresses the > community network need, which allows community networks > to request a /48 (/44 with justification). > > I have previous pointed to the boards decision to not provide > a non-profit discount schedule, and while I can understand > their reasoning, I also think in reality to get 501(c) qualified > it can easily take $1000/yr (opportunity costs, if not out > of pocket), so it is not really a solution for many to achieve > a substantive savings in ARIN fees. [And 501(c) (or country > equivalent) should be the requirement, not yet another > definition by ARIN of what a non-profit might be.] > > Gary > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cja at daydream.com Fri Apr 5 23:08:59 2013 From: cja at daydream.com (CJ Aronson) Date: Fri, 5 Apr 2013 21:08:59 -0600 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515F0A01.6020301@rollernet.us> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <515F0035.3030401@umn.edu> <515F0A01.6020301@rollernet.us> Message-ID: The policy can always be changed if circumstances change by anyone in the community submitting a proposal to make a change. I don't think we have to put text in this policy that says if or when it should change the policy in the future. This far in my life I have been unsuccessful at predicting the future. Maybe folks on this list have better luck :-) On Fri, Apr 5, 2013 at 11:29 AM, Seth Mattinen wrote: > On 4/5/13 9:47 AM, David Farmer wrote: > >> On 4/5/13 11:37 , Seth Mattinen wrote: >> >>> >>> I see no reason to have a policy motivated strictly by fees to remain >>> after fee changes that may or may not negate it, and to determine that >>> it should go back through the PDP. Otherwise we're just cluttering the >>> NRPM with irrelevant policy. >>> >> >> This would essentially be a sunset-clause, we had issues the last time >> we tried on of those. I'm not saying we can't or shouldn't do it but >> that I want more input before I add one into this policy. >> >> Note: we can't adopt this after Barbados it has to come back to the >> policy consultation at NANOG in June as a Recommended Draft Policy >> before it can be adopted. >> >> > > I'm thinking more drastic, as in "fee schedule changed, instantly struck". > The policy proposal is dependent on fees, nothing more. So let it be > dependent on the possibly of those fees changing and force it to go back > through the PDP as soon as that happens. > > ~Seth > > ______________________________**_________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/**listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Sat Apr 6 14:51:00 2013 From: andrew.dul at quark.net (Andrew Dul) Date: Sat, 06 Apr 2013 11:51:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy In-Reply-To: References: <5153386B.1040203@arin.net> Message-ID: <51606E94.3050409@quark.net> Inline On 3/27/2013 11:32 AM, Scott Leibrand wrote: > As one of the AC shepherds for the policy, I am hoping to have a > discussion, both here on PPML at at the upcoming ARIN meeting, to > cover a few key points: > > - Is the problem statement clear to the community? Do you have any > questions on the problem the proposal is attempting to solve? My read of the problem is that wireless operators have been using space beyond RFC 1918 (such as 1.0.0.0/8) to solve their addressing needs and now that this is becoming part of the "Internet" they need to move off of that space. > > - Do you feel that it is an important problem to try to solve? Do > you have any reasons you can share that we should or shouldn't do so? > With ARIN's /8 inventory currently at approximately 2.5, I'm skeptical that any policy using global IPv4 unicast space can actually solve this problem. Even if we were to give a whole /8 to this problem, I'm doubtful that is enough address space to solve this problem. Class E space is available...and so is IPv6 :) One could also use 100.64.0.0/10 > - If so, how would you prefer we approach solving it? Some > suggestions are outlined in the proposal below, but we'll need to > decide on an approach and write and discuss actual policy text in > order to move this Draft Policy forward. This proposal will *not* be > eligible for last call after ARIN 31 in Barbados, but we will be > discussing it there. > > So if you have any input now, please speak up. We'll be locking down > the version of the Draft Policy that will be printed in the ARIN 31 > discussion guides by April 5th, so please provide any input you can > before then. I currently don't see any "policy text" as we've normally come to expect. I'm certainly open to a discussion, but at this point we seem to be discussing concepts and a method to work the problem rather than specifically policy to solve the problem. It would be good to have some strawman text to discuss rather than just the concepts. > > Thanks, > Scott > > > On Wed, Mar 27, 2013 at 11:20 AM, ARIN > wrote: > > Draft Policy ARIN-2013-2 > 3GPP Network IP Resource Policy > > On 21 March 2013 the ARIN Advisory Council (AC) accepted > "ARIN-prop-184 3GPP Network IP Resource Policy" as a Draft Policy. > > Draft Policy ARIN-2013-2 is below and can be found at: > https://www.arin.net/policy/proposals/2013_2.html > > You are encouraged to discuss the merits and your concerns of > Draft Policy 2013-2 on the Public Policy Mailing List. 2013-2 will > also be on the agenda at the upcoming ARIN Public Policy Meeting > in Barbados. The AC will evaluate the discussion in order to > assess the conformance of this draft policy with ARIN's Principles > of Internet Number Resource Policy as stated in the PDP. > Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The ARIN Policy Development Process (PDP) can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2013-2 > 3GPP Network IP Resource Policy > > Date: 27 March 2013 > > Problem Statement: > > Current 3GPP architectures consist of hierarchical aggregation, > from cell site up to anchor nodes, approximately one per NFL city. > Anchor nodes are the point where IP addresses are assigned and > topologically positioned in the network. Generally an anchor node > must be provisioned with enough addresses to handle all > simultaneously attached users, plus enough headroom to handle > failover from an adjacent anchor node in the event of an outage. > Capacity planning generally ensures that all anchor nodes have > approximately the same number of attached users at steady state. > Moving addresses between anchor nodes would require significant > renumbering effort and substantial increases in operational > complexity, so cannot be performed during an outage. Generally > addresses are not renumbered between anchor nodes: instead, > aggregation nodes can be rehomed as needed to balance steady state > capacity levels. Because of the 3GPP architecture's failover and > capacity planning requirements, all cellular networks target > approximately 50% simultaneous usage of each anchor node's IP > addresses. However, even at 50% usage, the total number of > subscribers generally exceeds the number of addresses needed. > > Currently, a number of mobile networks are using non-RIR-assigned > space internally to meet customer demand. However, there is > insufficient private space (RFC1918, etc.) available for internal > use, so other unassigned space is currently being used. As this > unassigned space is brought into service via reclamation, returns, > and transfers, it is no longer possible to use it internally, so > globally unique space must be used instead. As a result, most of > the need for additional RIR-assigned space is to serve existing > customers, not to accommodate future growth. > > Policy statement: > > I can see two possible approaches to address this need. One > approach would be to continue counting simultaneously attached > users to measure IP needs, and apply a 50% usage requirement to > justify allocations. Another approach would be to instead count > total subscribers (rather than simultaneously attached users), and > apply a much higher threshold, such as 80% or even 90%, to justify > allocations. > > Timetable for implementation: ASAP > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael+ppml at burnttofu.net Sat Apr 6 15:00:53 2013 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Sat, 06 Apr 2013 12:00:53 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515392B9.807@umn.edu> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> Message-ID: <516070E5.2060603@burnttofu.net> On 03/27/13 17:45, David Farmer wrote: > On 3/27/13 18:00 , Michael Sinatra wrote: > >> Or, to put more bluntly, if ARIN's fee structure is itself creating >> disincentives for proper IPv6 adoption, then let's go back and (re-)fix >> that problem. >> >> Oppose 2013-3. > > Michael and others opposed, > > What about modifying the proposal to /40, require a minimum reservation > of /32 (or maybe /28) be held for ISPs that elect for /40 or /36 > allocations, allow subsequent allocations to expansion from /40 to /36 > and then to /32 without evaluating there current IPv6 usage. Thereby > ensuring they can grow their allocation in place and allowing policy > flexibility that enables the fee structure equity that the new xx-small > category seems to provided. Sorry to be responding to an earlier part of the thread, but I was on vacation and lost track of this thread, and you did ask me a direct question. I owe you the courtesy of an answer. The answer to your question is no. If I start out with a /40 or /36 and then rapidly grow into a /32 (and can justify the fees), then I am going to end up with a largely organic addressing plan. We're giving incentives for people to cram all of their addressing into a corner of the total space that they should be using and it will create a really messy IPv6 deployment. Again, when did we decide that ARIN should encourage parsimonious *IPv6* adoption? One thing that I understand from 19 years working at a large state university is a phenomenon called "ignoring the obvious solution." It's like the doctor who keeps prescribing more drugs to a patient to deal with the side effects of the drugs the patient is already on, rather than finding the one drug that will solve the patient's problem with minimal side-effects. When we face a big problem that should be tackled head on, we instead try to work around it. The big problem is that the fee schedule doesn't make sense. A university with 5 /16s (IPv4) and 1 /32 (IPv6) is an "X-Large" in IPv4 and "Small" in IPv6. (Note that such a fee schedule will definitely not encourage (L)RSA uptake, BTW.) It's increasingly hard to cut this new fee schedule in a way that treats ISPs or end users consistently across the two address families. This policy doesn't solve that problem, since a big part of the problem is on the IPv4 side. The second issue is that it's not even clear what the goals of the fee schedule are. Are we trying to provide incentives for IPv6 uptake? For IPv4 return? Are we trying to charge ISPs and end sites based on their size? On their profits? (Address space allocations measure neither.) [snip] > Finally, even if you continue to not support the proposal would you > support making the changes to the text about for the text to discuss at > the PPM? I couldn't quite parse this statement, but I think my answer is "yes." I really appreciate the original author's work on this and your work as shepherd, and I think the policy needs to be discussed. Still, I can't support a policy that simply codifies the bad incentives that inhere in the fee schedule. michael From jcurran at arin.net Sat Apr 6 22:31:21 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 02:31:21 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <516070E5.2060603@burnttofu.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> On Apr 6, 2013, at 12:00 PM, Michael Sinatra wrote: > The second issue is that it's not even clear what the goals of the fee > schedule are. " ARIN adopted the new Fee Schedule in order to: ? Ensure members receiving comparable services are paying comparable fees where feasible ? Meet the community's expectations for new and future services such as RPKI ? Maintain and reduce, where possible, cost for smaller ISPs ? Provide a revenue model based on long-term expenses " (This is also very similar to the information in community consultation held in October 2012 on the Revised Fee schedule.) Note that the present fee schedule does not provide an xx-small size category at all, and the fees associated with the current x-small category are also lowered by the Revised Fee schedule. > Are we trying to provide incentives for IPv6 uptake? For IPv4 return? We're trying to provide more more uniform fee categories and introduce lower fees for both x-small and xx-small ISPs as noted in the Revised Fee schedule faq. > Are we trying to charge ISPs and end sites based on their size? > On their profits? > (Address space allocations measure neither.) ARIN has always had fees based on relative size of organizations, generally based on the total address space held. This is the case with both the present fee schedule and the Revised Fee Schedule. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Sat Apr 6 22:58:23 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 02:58:23 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <515EFDB9.2010700@rollernet.us> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> On Apr 5, 2013, at 9:37 AM, Seth Mattinen wrote: > I see no reason to have a policy motivated strictly by fees to remain after fee changes that may or may not negate it, and to determine that it should go back through the PDP. Otherwise we're just cluttering the NRPM with irrelevant policy. Seth - The ARIN Board has often lowered the fee schedule as the financial circumstances allow, and in general this has been independent of number resource policy changes. The Revised Fee schedule is much improved over the existing fee schedule with respect to organizations being able to cost-effectively make use of IPv6 (as it is lower than the existing fee schedule's smallest IPv6 category today.) If the community does not support 2013-3, then smaller ISPs will still have the current option of receiving a /36 of IPv6 (if they wish); this will put them in the x-small fee category of $1000 per year. If the community supports 2013-3, then some very small ISPs will gain an option of taking a /40 allocation of IPv6 space, which will put them in the xx-small fee category with fees of $500 per year. If very small ISPs receiving /40 of IPv6 space does not make good technical sense, then the community should not support the draft policy... it's that simple. (These ISPs will still have lower fees under the Revised Fee schedule, just not as low as they might have had otherwise...) Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Sat Apr 6 23:36:48 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 03:36:48 +0000 Subject: [arin-ppml] ARIN-PPML Digest, Vol 94, Issue 3 In-Reply-To: <62B23031-1632-4E9A-843C-028B00078151@gmail.com> References: <62B23031-1632-4E9A-843C-028B00078151@gmail.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAE9C83@CHAXCH01.corp.arin.net> On Apr 3, 2013, at 11:56 AM, MsRachelleCross/GM wrote: > We are ARIN. Therefore, it's our jobs to ensure safety on the Internet. I personally know of several IP hosts who have violated intellectual genre, and (c) laws, having taken over people's Domains after providing service. There are other people out here who's entire IPv6 networks get hacked. People have related stories of losing information off of all their computers, mainframe, and all software licenses. > Sirs, will any of the new protocol protect innocent everyday people, making the Internet safe for everyone, and not just those of us with technical knowledge? > I would very much appreciate an opportunity to work with your team if I can be of assistance. > > Namaste, > Rev Rachelle C.Navarro Rev Rachelle C.Navarro - My apologies for not responding earlier, and do hope that this response finds you well. You are correct: We (the community participating on this list) are ARIN. ARIN strives to maintain open participation and it is fair to characterize those on this list as shaping how ARIN accomplishes its mission. The mission of ARIN is focused on the administration of the IP address space in this region, and not per se on ensuring "safety on the Internet" It is true that some aspects of administering IP addresses will have implications for safety on the Internet, but actually ensuring that outcome is a much bigger job requiring many more participants and the balancing of various public policy concerns of governments & law enforcement with due consideration to civil society and human rights. There is no central body which ensures "safety on the Internet" but you can find the topic discussed at the "Internet Governance Forum" (IGF), which is an open forum for multi-stakeholder policy dialogue about the Internet, including public policy issues such as sustainability, robustness, security, stability and development of the Internet. You can find out more information on the IGF here such how to participate in their workshops and conferences (including remote participation options) If you have any questions or would like to discuss this further, please feel free to contact me directly at Thank you! /John John Curran President and CEO ARIN From jcurran at arin.net Sat Apr 6 23:44:12 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 03:44:12 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> <515F05F3.2000802@umn.edu> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAE9DE7@CHAXCH01.corp.arin.net> On Apr 5, 2013, at 1:20 PM, Blake Dunlap wrote: > I also opposed minimums for ISPs below /32 based on an issue of business model for ARIN. Fix the billing problem, or the board membership problem, don't try to make this a technical solution to a business problem. Blake - There is not any business problem - the Revised Fee schedule lowers fees for smaller ISPs even under present IPv6 allocation policy, as ISPs already have the option to request a /36 allocation per existing NRPM 6.5.2. Thanks, /John John Curran President and CEO ARIN From matthew at matthew.at Sun Apr 7 01:07:08 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 06 Apr 2013 22:07:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8695009A81378E48879980039EEDAD28012438E564@MAIL1.polartel.local> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8695009A81378E48879980039EEDAD28012438E564@MAIL1.polartel.local> Message-ID: <5160FEFC.9040002@matthew.at> On 4/5/2013 9:41 AM, Kevin Kargel wrote: > I am still trying to figure out how having one *additional* database entry costs $1000/year. How about why the same number of database entries but different bits set costing different amounts? None of it really makes sense in the world of IPv6. Clearly the cost to maintain the entry for a single IPv6 /24 is no more or less than a single IPv6 /32 or /40, but there is some attempt to charge more to orgs that can afford to pay more here I guess. Matthew Kaufman From matthew at matthew.at Sun Apr 7 01:14:14 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 06 Apr 2013 22:14:14 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <516070E5.2060603@burnttofu.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> Message-ID: <516100A6.6030304@matthew.at> On 4/6/2013 12:00 PM, Michael Sinatra wrote: > On 03/27/13 17:45, David Farmer wrote: >> On 3/27/13 18:00 , Michael Sinatra wrote: >> >>> Or, to put more bluntly, if ARIN's fee structure is itself creating >>> disincentives for proper IPv6 adoption, then let's go back and (re-)fix >>> that problem. >>> >>> Oppose 2013-3. >> Michael and others opposed, >> >> What about modifying the proposal to /40, require a minimum reservation >> of /32 (or maybe /28) be held for ISPs that elect for /40 or /36 >> allocations, allow subsequent allocations to expansion from /40 to /36 >> and then to /32 without evaluating there current IPv6 usage. Thereby >> ensuring they can grow their allocation in place and allowing policy >> flexibility that enables the fee structure equity that the new xx-small >> category seems to provided. > Sorry to be responding to an earlier part of the thread, but I was on > vacation and lost track of this thread, and you did ask me a direct > question. I owe you the courtesy of an answer. > > The answer to your question is no. If I start out with a /40 or /36 and > then rapidly grow into a /32 (and can justify the fees), then I am going > to end up with a largely organic addressing plan. We're giving > incentives for people to cram all of their addressing into a corner of > the total space that they should be using and it will create a really > messy IPv6 deployment. Worse, we're creating a messy IPv6 situation downstream... as Owen points out, this type of financial pressure towards false conservation is going to give us things like /64-per-household instead of something sensible that lets the thermostat be on a different subnet than the Xbox. We should be telling ISPs of all sizes "IPv6 is huge... come get a /32 or bigger... do sensible things when you make your addressing plans... do sensible things when you sell service to your customers" and not "here's a way to save a buck by pretending IPv6 is like IPv4" You're right (in the part below that I deleted)... the bug is the fee structure and there's absolutely no reason to try to muck with the policy, which can't possibly fix the real problem. Matthew Kaufman From matthew at matthew.at Sun Apr 7 01:18:33 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 06 Apr 2013 22:18:33 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DB53F.1060809@umn.edu> <515EC241.5050505@umn.edu> <682B0E82-4540-4C0B-BAFD-85BBEC92748F@delong.com> <515F05F3.2000802@umn.edu> Message-ID: <516101A9.8040709@matthew.at> On 4/5/2013 10:27 AM, William Herrin wrote: > On Fri, Apr 5, 2013 at 1:12 PM, David Farmer wrote: >> Furthermore, there are no obvious solutions to this problem within the fee >> structure domain that are fiscally responsible and sustainable for ARIN, >> especially in the long-term. > Hi David, > > The obvious solutions within the fee structure are: > > 1. The non-profit discount > > 2. No-fee IPv6 for IPv4 holders until IPv6 becomes dominant > > > #2 solves the short-term problem of folks who won't spend money on a > protocol that won't yet make them money while #1 addresses the > community network need. For those community or other non-profit networks for which that discount is sufficient. In my case my legacy-numbered IPv4 network isn't getting IPv6 until IPv6 is free or enough money is made selling the IPv4 space to create a fund to pay for the IPv6 fees. But this is largely tangential to the issue at hand, which is that at the very least we should be giving nothing smaller than /32 to an ISP that is paying for their registration. If the board can't figure out how to charge small ISPs a small enough fee with an allocation policy of no-smaller-than-/32 (which is what it should be, despite the current availability of /36), then maybe they're not doing their job with regard to encouraging IPv6 deployment... but we're not going to magically fix that with a change to allocation policy without breaking a lot of other things that could be good about IPv6 in the process. Matthew Kaufman From michael+ppml at burnttofu.net Sun Apr 7 05:02:25 2013 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Sun, 07 Apr 2013 02:02:25 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> Message-ID: <51613621.9040702@burnttofu.net> On 04/06/13 19:31, John Curran wrote: > On Apr 6, 2013, at 12:00 PM, Michael Sinatra wrote: > >> The second issue is that it's not even clear what the goals of the fee >> schedule are. > > > " > ARIN adopted the new Fee Schedule in order to: > ? Ensure members receiving comparable services are paying comparable fees where feasible > ? Meet the community's expectations for new and future services such as RPKI > ? Maintain and reduce, where possible, cost for smaller ISPs > ? Provide a revenue model based on long-term expenses > " > (This is also very similar to the information in community > consultation held in October 2012 on the Revised Fee schedule.) > > Note that the present fee schedule does not provide an xx-small > size category at all, and the fees associated with the current > x-small category are also lowered by the Revised Fee schedule. That doesn't really answer my question. My question revolves around the following *types* of questions: o Is the fee schedule intended to be based on fairness? o Is the goal to reduce complexity at a (reasonable?) cost of fairness? Or increase fairness at a reasonable cost of complexity? If I suggest that we tweak the fee schedule, am I going against one of the fundamental goals of not making it "too complex" by some definition thereof? o Is fairness determined in terms of revenue, capitalization, or just address space? o How do we define terms like "comparable service." Given that ARIN provides registration services, not addresses, how *should* "comparable service" be defined. >> Are we trying to provide incentives for IPv6 uptake? For IPv4 return? > > We're trying to provide more more uniform fee categories and > introduce lower fees for both x-small and xx-small ISPs as > noted in the Revised Fee schedule faq. > > >> Are we trying to charge ISPs and end sites based on their size? >> On their profits? >> (Address space allocations measure neither.) > > ARIN has always had fees based on relative size of organizations, > generally based on the total address space held. This is the case > with both the present fee schedule and the Revised Fee Schedule. That may be true, but where is that codified and/or hashed out? What is that basic philosophy discussed and reviewed? I am not saying it needs to be right now, but I have a hard time understanding why we need to contort the NRPM to patch over bad incentives in the fee schedule. Moreover, that standard is called into question by the fact that ARIN charges based on the larger of the two address family allocations, with no regard to the situation where there are radical differences between IPv4 size and IPv6 size. What I am trying to say here is that there is huge amount of slack between the actual implementation of the fee schedule and what it appears to be trying to do. So let's stop pretending that policy ought to be beholden to the vagaries of the fee schedule and let's be willing to tweak the fee schedule where necessary to provide the right incentives, since we acknowledge that the fee schedule is imperfect. That said, I disagree with the comments section of the proposal that there is no obvious solution to the problem that still provides for sustainability of ARIN. One obvious possibility is to treat a /32 IPv6 allocation as a special case for ISPs: If you have both IPv4 and IPv6 allocations, and your IPv6 allocation is a /32, then your fees are based on your *IPv4* allocation, even if it drops you into a lower fee bracket. If we're reserving the /32 indefinitely anyway, then I don't think that creates a sustainability issue for ARIN. It's still a single allocation, so it's not costing ARIN anything more to provide a /32 but simply charge for only the smaller IPv4 allocation. Obviously, this would have to be revisited at the time that ARIN ceases to provide IPv4 registration services. But I suspect that at that point, it would be time to revise the fee schedule anyway. michael From jcurran at arin.net Sun Apr 7 07:21:38 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 11:21:38 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <516100A6.6030304@matthew.at> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> On Apr 6, 2013, at 10:14 PM, Matthew Kaufman wrote: > Worse, we're creating a messy IPv6 situation downstream... as Owen points out, this type of financial pressure towards false conservation is going to give us things like /64-per-household instead of something sensible that lets the thermostat be on a different subnet than the Xbox. Matthew - The current fee schedule reads as follows: IPV6 ANNUAL FEES (NOTE: FEE WAIVERS IN EFFECT), EFFECTIVE UNTIL 30 JUNE 2013 Size Category Fee (US Dollars) Block Size Small $2,250 /40 to /32 Medium $4,500 /31 to /30 There is 25% IPv6 fee waiver in effect (this started out at 100% and was to be phased out over the last 4 years, although it was extended at the 25% discount level for this year to carry us into the Revised Fee schedule.) So, any ISP using IPv6 under _today's_ fee schedule has a minimum annual fee of $1687 per year [$2250 * 75%] and that covers an allocation up to /32 of IPv6. Unless we continue with the Revised Fee schedule, this is effectively a minimum annual cost for any ISP making use of IPv6. If we want to lower that cost of using IPv6 for smaller organizations, we need to find some manner to distinguish these smaller ISPs from all ISPs, and this is typically done through the total address block holdings. At this point, ARIN can sustain some number of smaller ISPs having lower fees, and the Revised Fee schedule supports an ISP with no more than /20 of IPv4 space and /36 of IPv6 being categorized as "x-small" with annual fees of $1000/year. This category makes IPv6 more approachable for these ISPs but it is indeed at the downside of a smaller IPv6 allocation. As you are aware, /36 of IPv6 space would provide for more than 4000 /48 and _lots_ of /56 assignments (but there would be less in practice due to internal hierarchy in assignment management.) Draft Policy ARIN-2013-3, combined with the Revised Fee schedule as corrected, would continue this approach of allowing very small ISPs with no more than /22 of IPv4 to obtain a corresponding IPv6 allocation of /40 and have annual fees of $500 year in the "xx-small" category. The downside that you assert with Draft Policy ARIN-2013-3 is that "this type of financial pressure towards false conservation is going to give us things like/64-per-household instead of something sensible that lets the thermostat be on a different subnet than the Xbox." Given that any ISP qualifying as xx-small (even with wildly aggressive NAT) has no more 1024 customers each with a single IPv4 address, and the /40 IPv6 allocation would provide them with the ability to make 65K /56 assignments to these same customers, it does seem somewhat strange that "false conservation" of those 65 thousand potential assignments would drive xx-small ISPs to instead make /64 IPv6 customer assignments. The community can indicate that it does not support ARIN-2013-3 if the resulting "false conservation" is a problem, and then there will be no use of the xx-small/$500/yr fee category. Under the Revised Fee schedule, these ISPs would be paying at least $1000/year based on a /36 IPv6 allocation (which is still better than today's fees with IPv6 use as noted above.) It would be good to hear from ISPs who would qualify for the xx-small $500/year category about the resulting temptation that it poses for making smaller IPv6 customer assignments (and how they feel safer with the /36 IPv6 minimum and corresponding $1000/year annual fee), as they are the ones who are most affected by the outcome of this draft policy consideration. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Sun Apr 7 07:46:15 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 11:46:15 +0000 Subject: [arin-ppml] Fee Philosophy (was: Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs) In-Reply-To: <51613621.9040702@burnttofu.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> <51613621.9040702@burnttofu.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 2:02 AM, Michael Sinatra wrote: > On 04/06/13 19:31, John Curran wrote: >> On Apr 6, 2013, at 12:00 PM, Michael Sinatra wrote: >> >>> The second issue is that it's not even clear what the goals of the fee >>> schedule are. >> >> >> " >> ARIN adopted the new Fee Schedule in order to: >> ? Ensure members receiving comparable services are paying comparable fees where feasible >> ? Meet the community's expectations for new and future services such as RPKI >> ? Maintain and reduce, where possible, cost for smaller ISPs >> ? Provide a revenue model based on long-term expenses >> " >> (This is also very similar to the information in community >> consultation held in October 2012 on the Revised Fee schedule.) >> ... > > That doesn't really answer my question. My question revolves around the > following *types* of questions: > > o Is the fee schedule intended to be based on fairness? > o Is the goal to reduce complexity at a (reasonable?) cost of fairness? > Or increase fairness at a reasonable cost of complexity? If I suggest > that we tweak the fee schedule, am I going against one of the > fundamental goals of not making it "too complex" by some definition thereof? > o Is fairness determined in terms of revenue, capitalization, or just > address space? > o How do we define terms like "comparable service." Given that ARIN > provides registration services, not addresses, how *should* "comparable > service" be defined. All excellent questions, and while the Board has expressed a desire for a simple and fair fee schedule, there is no hard and fast rules for how these factors should be balanced. There was discussion of some of these considerations at the Dallas meeting presentation on the Revised Fee Schedule, with the general desire that a simpler fee schedule with less exceptions is preferred, and that ARIN should continue to lower fees as much as possible. >> ARIN has always had fees based on relative size of organizations, >> generally based on the total address space held. This is the case >> with both the present fee schedule and the Revised Fee Schedule. > > That may be true, but where is that codified and/or hashed out? What is > that basic philosophy discussed and reviewed? The ARIN Board establishes fees, and there are both public consultations and public discussions at the ARIN meetings when changes are proposed. > I am not saying it needs > to be right now, but I have a hard time understanding why we need to > contort the NRPM to patch over bad incentives in the fee schedule. No NRPM change is needed because of the Revised Fee schedule; fees under the new schedule will be lower for smallest ISPs in any case. The question is whether the community also provide support for a xx-small category which is even lower ($500/year) but distinguished by only a /40 IPv6 allocation. This is being discussed in Draft Policy ARIN-2013-3, and while it is enabled by the Revised Fee schedule, it is an independent item for the community to consider and can be adopted or not based on its merits. > Moreover, that standard is called into question by the fact that ARIN > charges based on the larger of the two address family allocations, with > no regard to the situation where there are radical differences between > IPv4 size and IPv6 size. Correct, and this has been covered on this mailing list before - "that is precisely the benefit of the revised fee schedule; every size ISP category now includes both IPv4 and IPv6, so every ISP can add an IPv6 allocation and see _no_ change in fees at all. (This does mean that we can get ISPs for whom there is a "mismatch" between their IPv4 and IPv6 allocations, and they end up in a higher category, but to be truly fair we'd need to have distinct proportional fee for each of IPv4 and IPv6, and that's exactly what you don't want: any addition of IPv6 means an additional fee.)" The advantage of the current approach is that every ISP with an IPv4 allocation can obtain a corresponding IPv6 allocation with no change in fees. It works against those with "radical differences" as you note above, but the only way to be 100% equitable in all cases would be to charge completely separately for IPv4 and IPv6, with the result being we would always have to have some fee associated with issuing IPv6. Given the community's indications in the past, having a fee schedule which provides for some IPv6 allocation in each category with no change in fees seems to better meet expectations. Thanks! /John John Curran President and CEO ARIN From bill at herrin.us Sun Apr 7 08:04:59 2013 From: bill at herrin.us (William Herrin) Date: Sun, 7 Apr 2013 08:04:59 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> Message-ID: On Sat, Apr 6, 2013 at 10:31 PM, John Curran wrote: > > " > ARIN adopted the new Fee Schedule in order to: > ? Ensure members receiving comparable services are paying comparable fees where feasible > ? Meet the community's expectations for new and future services such as RPKI > ? Maintain and reduce, where possible, cost for smaller ISPs > ? Provide a revenue model based on long-term expenses > " Hi John, Perhaps that's the error. It seems to me that ARIN's fee schedule objectives should be along the lines of (in this order): 1. Assure adequate funding to meet ARIN's mission over the next three years. 2. Optimize for compatibility between the funding model and the NRPM number policies. 3. Optimize for compatibility between the funding model and the technical objectives associated with world Internet number resources (e.g. wide deployment of IPv6, RPKI) 4. Optimize for a fair spread of cost between registrants based on resources consumed. ARIN's quoted objectives seem to forget about registrants all together in favor of members. That's dumb. Then they try to model _long-term_ funding during an unpredictable time of transition. That's dumber. Then they focus on services rather than community objectives. That's tone deaf. On Sat, Apr 6, 2013 at 10:58 PM, John Curran wrote: > If very small ISPs receiving /40 of IPv6 space does not make good > technical sense, then the community should not support the draft > policy... it's that simple. It's not that simple. If it was, we wouldn't have a policy draft on the table trying to work around errors in the fee schedule. 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 arin.net Sun Apr 7 08:29:54 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 12:29:54 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAF5360@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 5:04 AM, William Herrin wrote: > > On Sat, Apr 6, 2013 at 10:58 PM, John Curran wrote: >> If very small ISPs receiving /40 of IPv6 space does not make good >> technical sense, then the community should not support the draft >> policy... it's that simple. > > It's not that simple. If it was, we wouldn't have a policy draft on > the table trying to work around errors in the fee schedule. Bill - Actually, it is that simple. The Draft Policy proposal on the table "Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs" provides an option for ISPs who wish to be issued IPv6 allocations which are smaller than present policy allows. The Revised fee schedule will allow this but does not require it in any fashion. If adopted, it will indeed provide lower fees for those ISPs who make use of it, but the question of whether the policy change is worthwhile comes down to the community's consideration of whether it is fair and technically sound. If the community doesn't think so, then no policy change is needed (fees for smallest ISPs will still go down, but not as far as they might otherwise) Thanks! /John John Curran President and CEO ARIN From snoble at sonn.com Sun Apr 7 12:58:05 2013 From: snoble at sonn.com (Steven Noble) Date: Sun, 7 Apr 2013 09:58:05 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> Message-ID: <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> On Apr 7, 2013, at 4:21 AM, John Curran wrote: > > It would be good to hear from ISPs who would qualify for the xx-small > $500/year category about the resulting temptation that it poses for > making smaller IPv6 customer assignments (and how they feel safer with > the /36 IPv6 minimum and corresponding $1000/year annual fee), as they > are the ones who are most affected by the outcome of this draft policy > consideration. I would love to have PI IPv6 space and as I have no IPv4 space from ARIN, adding IPv6 will raise my fees. What is the proposal to get legacy holders to adopt IPv6? As noted before by others, I don't understand why a record has different costs based on what the record is for. The difference in fees seems to go against ARINs goal of allocating resources to the community. Is the overhead of an IPv6 allocation record 5x an ASN record? From jcurran at arin.net Sun Apr 7 13:13:34 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 17:13:34 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFA7F1@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 9:58 AM, Steven Noble wrote: > I would love to have PI IPv6 space and as I have no IPv4 space from ARIN, adding IPv6 will raise my fees. What is the proposal to get legacy holders to adopt IPv6? > > As noted before by others, I don't understand why a record has different costs based on what the record is for. The difference in fees seems to go against ARINs goal of allocating resources to the community. > > Is the overhead of an IPv6 allocation record 5x an ASN record? Actually, there is a significantly more registry operations and development costs associated with IP address blocks than AS numbers, if only because IP address blocks for ISPs end up with subassignments to customers, and this ends up in Whois via SWIP or restful interfaces. While we have lowered fees (and doing so again with this change) for the smaller ISPs, it still does not compare to either "free" or the nominal $100 per record fee for legacy holders. Do you have a view on whether or not policy should be changed (as proposed in ARIN-2013-3) to allow ISPs to request an IPv6 allocation of /40 if they want to, or should they be limited to at least a /36 allocation per current policy? FYI, /John John Curran President and CEO ARIN From snoble at sonn.com Sun Apr 7 13:24:05 2013 From: snoble at sonn.com (Steven Noble) Date: Sun, 7 Apr 2013 10:24:05 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161A9EE.3060304@bogus.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161A9EE.3060304@bogus.com> Message-ID: <2A7D98DF-4B38-46CA-A2FD-13A742C722BF@sonn.com> On Apr 7, 2013, at 10:16 AM, joel jaeggli wrote: >>> >> I would love to have PI IPv6 space and as I have no IPv4 space from ARIN, adding IPv6 will raise my fees. What is the proposal to get legacy holders to adopt IPv6? > The notion that legacy holders should be treated iconsistenly with others with regard to new assignments doesn't seem very consistent with needs based allocation. If you don't need it, don't request the resources. That is exactly my point, if ARIN says that someone requesting IPv6 will not have higher fees, then how does that work with a legacy holder? Do we want people to adopt IPv6 or not? A policy that makes it the same cost to request and hold IPv4 and IPv6 works both ways. If I am charged the same as someone who has both IPv4 and IPv6 resources, why would I not request IPv4 resources too? From snoble at sonn.com Sun Apr 7 13:28:34 2013 From: snoble at sonn.com (Steven Noble) Date: Sun, 7 Apr 2013 10:28:34 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAFA7F1@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <8DA1853CE466B041B104C1CAEE00B3748FAFA7F1@CHAXCH01.corp.arin.net> Message-ID: On Apr 7, 2013, at 10:13 AM, John Curran wrote: > > Actually, there is a significantly more registry operations > and development costs associated with IP address blocks than > AS numbers, if only because IP address blocks for ISPs end up > with subassignments to customers, and this ends up in Whois > via SWIP or restful interfaces. While we have lowered fees > (and doing so again with this change) for the smaller ISPs, > it still does not compare to either "free" or the nominal > $100 per record fee for legacy holders. This I understand, thank you John. I do not consider $100 nominal, when the cost was $30 it was nominal, with the new fee schedule instead of lowering the fee back to $30 and charging for each ASN, ARIN is raising the fees for ASNs to $100 each. Why not make a sliding scale? Those who consume more resources as a single ORG pay more: $30 for first ASN, $60 for second, etc. > > Do you have a view on whether or not policy should be changed > (as proposed in ARIN-2013-3) to allow ISPs to request an IPv6 > allocation of /40 if they want to, or should they be limited > to at least a /36 allocation per current policy? I believe it will allow for more IPv6 deployment which is the end goal. I can debate in my head paying $500 to have IPv6 PI space, I cannot justify paying $1000+ yearly. From joelja at bogus.com Sun Apr 7 13:16:30 2013 From: joelja at bogus.com (joel jaeggli) Date: Sun, 07 Apr 2013 10:16:30 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> Message-ID: <5161A9EE.3060304@bogus.com> On 4/7/13 9:58 AM, Steven Noble wrote: > On Apr 7, 2013, at 4:21 AM, John Curran wrote: > >> It would be good to hear from ISPs who would qualify for the xx-small >> $500/year category about the resulting temptation that it poses for >> making smaller IPv6 customer assignments (and how they feel safer with >> the /36 IPv6 minimum and corresponding $1000/year annual fee), as they >> are the ones who are most affected by the outcome of this draft policy >> consideration. > I would love to have PI IPv6 space and as I have no IPv4 space from ARIN, adding IPv6 will raise my fees. What is the proposal to get legacy holders to adopt IPv6? The notion that legacy holders should be treated iconsistenly with others with regard to new assignments doesn't seem very consistent with needs based allocation. If you don't need it, don't request the resources. > As noted before by others, I don't understand why a record has different costs based on what the record is for. The difference in fees seems to go against ARINs goal of allocating resources to the community. > > Is the overhead of an IPv6 allocation record 5x an ASN record? > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jcurran at arin.net Sun Apr 7 13:35:49 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 17:35:49 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <8DA1853CE466B041B104C1CAEE00B3748FAFA7F1@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFB0B7@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 10:28 AM, Steven Noble wrote: > On Apr 7, 2013, at 10:13 AM, John Curran wrote: >> Actually, there is a significantly more registry operations >> and development costs associated with IP address blocks than >> AS numbers, if only because IP address blocks for ISPs end up >> with subassignments to customers, and this ends up in Whois >> via SWIP or restful interfaces. While we have lowered fees >> (and doing so again with this change) for the smaller ISPs, >> it still does not compare to either "free" or the nominal >> $100 per record fee for legacy holders. > > This I understand, thank you John. I do not consider $100 nominal, when the cost was $30 it was nominal, with the new fee schedule instead of lowering the fee back to $30 and charging for each ASN, ARIN is raising the fees for ASNs to $100 each. Steve - The prior fee was $100 per year for all your resources; I am uncertain why you felt it was $30? The revised fee schedule changes this for end-users and legacy holders to $100 per year per resource record. > Why not make a sliding scale? Those who consume more resources as a single ORG pay more: $30 for first ASN, $60 for second, etc. It is a sliding scale under the revised fee schedule for end-users and legacy holders, but at $100 per record not $30 per record as you suggest. >> Do you have a view on whether or not policy should be changed >> (as proposed in ARIN-2013-3) to allow ISPs to request an IPv6 >> allocation of /40 if they want to, or should they be limited >> to at least a /36 allocation per current policy? > > I believe it will allow for more IPv6 deployment which is the end goal. I can debate in my head paying $500 to have IPv6 PI space, I cannot justify paying $1000+ yearly. That is helpful to know - Thank you! /John John Curran President and CEO ARIN From cb.list6 at gmail.com Sun Apr 7 13:30:36 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 10:30:36 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <516100A6.6030304@matthew.at> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> Message-ID: On Apr 6, 2013 10:14 PM, "Matthew Kaufman" wrote: > > On 4/6/2013 12:00 PM, Michael Sinatra wrote: >> >> On 03/27/13 17:45, David Farmer wrote: >>> >>> On 3/27/13 18:00 , Michael Sinatra wrote: >>> >>>> Or, to put more bluntly, if ARIN's fee structure is itself creating >>>> disincentives for proper IPv6 adoption, then let's go back and (re-)fix >>>> that problem. >>>> >>>> Oppose 2013-3. >>> >>> Michael and others opposed, >>> >>> What about modifying the proposal to /40, require a minimum reservation >>> of /32 (or maybe /28) be held for ISPs that elect for /40 or /36 >>> allocations, allow subsequent allocations to expansion from /40 to /36 >>> and then to /32 without evaluating there current IPv6 usage. Thereby >>> ensuring they can grow their allocation in place and allowing policy >>> flexibility that enables the fee structure equity that the new xx-small >>> category seems to provided. >> >> Sorry to be responding to an earlier part of the thread, but I was on >> vacation and lost track of this thread, and you did ask me a direct >> question. I owe you the courtesy of an answer. >> >> The answer to your question is no. If I start out with a /40 or /36 and >> then rapidly grow into a /32 (and can justify the fees), then I am going >> to end up with a largely organic addressing plan. We're giving >> incentives for people to cram all of their addressing into a corner of >> the total space that they should be using and it will create a really >> messy IPv6 deployment. > > > Worse, we're creating a messy IPv6 situation downstream... as Owen points out, this type of financial pressure towards false conservation is going to give us things like /64-per-household instead of something sensible that lets the thermostat be on a different subnet than the Xbox. > > We should be telling ISPs of all sizes "IPv6 is huge... come get a /32 or bigger... do sensible things when you make your addressing plans... do sensible things when you sell service to your customers" and not "here's a way to save a buck by pretending IPv6 is like IPv4" > > You're right (in the part below that I deleted)... the bug is the fee structure and there's absolutely no reason to try to muck with the policy, which can't possibly fix the real problem. > > Matthew Kaufman > Generally speaking we need to move away from conservation as goal for both ipv4 and ipv6 Structurally there is no need in v6 and the market will force it in v4 conservation at the rir level creates costly externalities in routing and other areas such as system design. Ripe is on the right track http://www.ripe.net/ripe/policies/proposals/2013-03 CB. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From snoble at sonn.com Sun Apr 7 13:44:58 2013 From: snoble at sonn.com (Steven Noble) Date: Sun, 7 Apr 2013 10:44:58 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAFB0B7@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <8DA1853CE466B041B104C1CAEE00B3748FAFA7F1@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAFB0B7@CHAXCH01.corp.arin.net> Message-ID: <0663F233-8E7F-4EC8-B6A6-77466D263B56@sonn.com> Hi John, On Apr 7, 2013, at 10:35 AM, John Curran wrote: >> > Steve - > > The prior fee was $100 per year for all your resources; > I am uncertain why you felt it was $30? I registered my ASN in 2000, at that time I was charged a $30 maintenance fee for the ASN. > > The revised fee schedule changes this for end-users and > legacy holders to $100 per year per resource record. Which is again higher than the $30 that I originally paid before the "consolidated" fee. > >> Why not make a sliding scale? Those who consume more resources as a single ORG pay more: $30 for first ASN, $60 for second, etc. > > It is a sliding scale under the revised fee schedule for > end-users and legacy holders, but at $100 per record not > $30 per record as you suggest. A sliding scale would start small for 1 ASN and then get larger (more than +n) for each ASN after that. If someone holds 1 ASN, they would pay $30, if someone holds 2, they would pay $90, 3 ASNs would be $210, that type of a sliding scale. >> >> I believe it will allow for more IPv6 deployment which is the end goal. I can debate in my head paying $500 to have IPv6 PI space, I cannot justify paying $1000+ yearly. > > That is helpful to know - Thank you! No problem, obviously lower costs help push adoption. If the cost of getting IPv6 is less than requesting both IPv4 and IPv6 it makes sense to me. From jcurran at arin.net Sun Apr 7 13:55:10 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 17:55:10 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <0663F233-8E7F-4EC8-B6A6-77466D263B56@sonn.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <8DA1853CE466B041B104C1CAEE00B3748FAFA7F1@CHAXCH01.corp.arin.net> <8DA1853CE466B041B104C1CAEE00B3748FAFB0B7@CHAXCH01.corp.arin.net> <0663F233-8E7F-4EC8-B6A6-77466D263B56@sonn.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFB849@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 10:44 AM, Steven Noble wrote: > Hi John, > > On Apr 7, 2013, at 10:35 AM, John Curran wrote: > >>> >> Steve - >> >> The prior fee was $100 per year for all your resources; >> I am uncertain why you felt it was $30? > > I registered my ASN in 2000, at that time I was charged a $30 maintenance fee for the ASN. Now I understand... Thank you. >> It is a sliding scale under the revised fee schedule for >> end-users and legacy holders, but at $100 per record not >> $30 per record as you suggest. > > A sliding scale would start small for 1 ASN and then get larger (more than +n) for each ASN after that. If someone holds 1 ASN, they would pay $30, if someone holds 2, they would pay $90, 3 ASNs would be $210, that type of a sliding scale. I'd like to see the fee per record be reduced to $75 (or even lower) over time but we need to use care in doing so and cannot head that direction until we understand long-term if ISP and end-user fees are to be harmonized or kept distinct (while the services are very similar, arguing for similar fees, there is a argument to be made that the end-users do not benefit "as a business" in the ways that the ISPs do, and hence should always have a distinct lower fee schedule.) Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Sun Apr 7 14:03:53 2013 From: jcurran at arin.net (John Curran) Date: Sun, 7 Apr 2013 18:03:53 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFBC34@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 10:30 AM, "cb.list6" > wrote: Generally speaking we need to move away from conservation as goal for both ipv4 and ipv6 Structurally there is no need in v6 and the market will force it in v4 conservation at the rir level creates costly externalities in routing and other areas such as system design. Ripe is on the right track http://www.ripe.net/ripe/policies/proposals/2013-03 CB - Could you be a little more specific with regards to whether you support "Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs"? It would provide an option for ISPs who wish to be issued IPv6 allocations of /40, which is smaller than present policy allows. The referenced RIPE policy proposal is with regards to IPv4 allocation policy, not IPv6, so it is hard to discern whether you support allowing ISPs to request a smaller allocation if they wish to. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Sun Apr 7 15:33:26 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sun, 7 Apr 2013 19:33:26 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> I agree with Mathew and CB. We do need to move away from conservation at the RIR level as a goal for both ipv4 and ipv6. Ripe is definitely on the right track with http://www.ripe.net/ripe/policies/proposals/2013-03 and I strongly support that. The same changes should happen for the Arin RIR. The IPv6 pricing issue is a difficult one in a world that is still IPv4 oriented. We purchased an IPv6 block in the Small category (/32) from Arin last year for $2250 less the 25% discount of $562.50 for a total of $1687.50. At the time I felt that was expensive since less than 5% of Internet traffic runs on IPv6 - but that was the cost so I made a business decision to pay it. We run BGP with IPv4 and we wanted to also run BGP with IPv6 which is why we purchased the block. To my surprise ? only one of my upstream providers has implemented IPv6 and of course we are in a 3 year agreement with them for their Metro-E line. They are a CLEC and they tell me that they have only had about 6 inquires about running IPv6. So now just today I received my renewal bill for our IPv6 block and it is again for $1687.50. Now I have to make a business decision on whether to pay it and hope I can twist our CLEC?s arm to support IPv6 - or let it lapse and wait until the end of our contract and switch upstream providers - and pay for another IPv6 allocation at that time. My preference would be to renew but not using an assigned IPv6 block for two years will costs me $3375 (even in the Small category) and if I can?t use it then I get no benefit for it. This is the real world of IPv6 and I am definitely for less expensive blocks for IPv6 and for allocations of extra small blocks of the Tiny size to further Arin?s Mission. I am for a Tiny IPv6 option for small ISP?s - but at an attractive price - because that is in line with Arin?s mission of allocating resources. I think even with the 25% discount all of the current IPv6 prices are too high for the current value being received from them. The price should be at least somewhat in line with the value that can be derived from the IPv6 resource. Adoption of IPv6 needs to be a high priority and the best way to make that happen is to allocate IPv6 of all sizes at a maybe 50% or more discount until the adoption is at a higher percentage ? maybe 15%-20% or more. I do think the entire fee Arin fee schedule needs to be enough for Arin to pay its bills. P.S. The email I just received says at the bottom of it that the Board approved a new fee schedule in January effective July. Maybe I missed something but I didn?t see any discussion of a totally new fee schedule discussed in this forum. While I acknowledge that Arin?s Board has the right and responsibility to set fees independent of this forum ? as there are a number of smart experienced folks participating in this forum ? this community?s input might have helped develop a better outcome for all. I?m guessing there would have been a lot of constructive feedback provided ? just like there has been on the fees portion of the Tiny IPv6 policy. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of cb.list6 Sent: Sunday, April 07, 2013 1:31 PM To: Matthew Kaufman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations forISPs On Apr 6, 2013 10:14 PM, "Matthew Kaufman" > wrote: > > On 4/6/2013 12:00 PM, Michael Sinatra wrote: >> >> On 03/27/13 17:45, David Farmer wrote: >>> >>> On 3/27/13 18:00 , Michael Sinatra wrote: >>> >>>> Or, to put more bluntly, if ARIN's fee structure is itself creating >>>> disincentives for proper IPv6 adoption, then let's go back and (re-)fix >>>> that problem. >>>> >>>> Oppose 2013-3. >>> >>> Michael and others opposed, >>> >>> What about modifying the proposal to /40, require a minimum reservation >>> of /32 (or maybe /28) be held for ISPs that elect for /40 or /36 >>> allocations, allow subsequent allocations to expansion from /40 to /36 >>> and then to /32 without evaluating there current IPv6 usage. Thereby >>> ensuring they can grow their allocation in place and allowing policy >>> flexibility that enables the fee structure equity that the new xx-small >>> category seems to provided. >> >> Sorry to be responding to an earlier part of the thread, but I was on >> vacation and lost track of this thread, and you did ask me a direct >> question. I owe you the courtesy of an answer. >> >> The answer to your question is no. If I start out with a /40 or /36 and >> then rapidly grow into a /32 (and can justify the fees), then I am going >> to end up with a largely organic addressing plan. We're giving >> incentives for people to cram all of their addressing into a corner of >> the total space that they should be using and it will create a really >> messy IPv6 deployment. > > > Worse, we're creating a messy IPv6 situation downstream... as Owen points out, this type of financial pressure towards false conservation is going to give us things like /64-per-household instead of something sensible that lets the thermostat be on a different subnet than the Xbox. > > We should be telling ISPs of all sizes "IPv6 is huge... come get a /32 or bigger... do sensible things when you make your addressing plans... do sensible things when you sell service to your customers" and not "here's a way to save a buck by pretending IPv6 is like IPv4" > > You're right (in the part below that I deleted)... the bug is the fee structure and there's absolutely no reason to try to muck with the policy, which can't possibly fix the real problem. > > Matthew Kaufman > Generally speaking we need to move away from conservation as goal for both ipv4 and ipv6 Structurally there is no need in v6 and the market will force it in v4 conservation at the rir level creates costly externalities in routing and other areas such as system design. Ripe is on the right track http://www.ripe.net/ripe/policies/proposals/2013-03 CB. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From gary.buhrmaster at gmail.com Sun Apr 7 15:40:38 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Sun, 7 Apr 2013 19:40:38 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> Message-ID: On Sun, Apr 7, 2013 at 4:58 PM, Steven Noble wrote: .... > I would love to have PI IPv6 space and as I have no IPv4 space from ARIN, adding IPv6 will raise my fees. What is the proposal to get legacy holders to adopt IPv6? The community has been fairly clear that Legacy holders are going to have to come into the tent (of ARIN or equivalent RIR) to register additional numbers of any type (ASN, IPv4, or IPv6). That includes the new fees and agreements. Interestingly, most of the legacy holders were, at the time, the early adopters (of the Internet). One would likely have expected that most would have wanted to be early adopters of IPv6, and recognized that as the Internet grew up, fees and regulations would also change, and they would have to change with those new realities. The "free lunch" of legacy holders has long been digested, and it is going to cost for the next meal (IPv6). So, the reason for legacy holders to adopt IPv6 is not because it will (again) be free (or nearly so), but because that is where one should be. Gary From owen at delong.com Sun Apr 7 15:41:42 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Apr 2013 12:41:42 -0700 Subject: [arin-ppml] Fee Philosophy (was: Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs) In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> <51613621.9040702@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> Message-ID: <36DDD38E-6C36-4B30-B537-25F2759591DD@delong.com> >> I am not saying it needs >> to be right now, but I have a hard time understanding why we need to >> contort the NRPM to patch over bad incentives in the fee schedule. > > No NRPM change is needed because of the Revised Fee schedule; fees under > the new schedule will be lower for smallest ISPs in any case. > > The question is whether the community also provide support for a xx-small > category which is even lower ($500/year) but distinguished by only a /40 > IPv6 allocation. This is being discussed in Draft Policy ARIN-2013-3, and > while it is enabled by the Revised Fee schedule, it is an independent item > for the community to consider and can be adopted or not based on its merits. > No, that is not the only question. Because of the situation created by the restructuring of the fee schedule, we have several negative incentives newly created. It is true that we can choose one negative incentive[1] by not modifying the NRPM. Policy 2013-3 attempts to replace that negative incentive with a different negative incentive[2]. No matter what, the fee schedule as it currently stands creates negative incentives and I believe that is what Michael is calling into question here. [1] The fee structure and policy as currently adopted will create the negative incentive for organizations in the xx-small IPv4 category to not deploy IPv6 in order to save $500/year. [2] The combination of the adopted fee structure (assuming it is modified to /40 instead of /48) and proposal 2013-3, if adopted would replace [1] with the negative incentive for those providers in the XX-Small category to obtain massively undersized allocations in order to save the same amount of money, allowing them to deploy IPv6 without additional address space cost, but very likely inflicting undue limitations on the space issued to their customers. This negative incentive already exists in both policy and the fee schedule for the X-Small category in the form of support for /36s. >> Moreover, that standard is called into question by the fact that ARIN >> charges based on the larger of the two address family allocations, with >> no regard to the situation where there are radical differences between >> IPv4 size and IPv6 size. > > Correct, and this has been covered on this mailing list before > - > > "that is precisely the benefit of the revised fee schedule; > every size ISP category now includes both IPv4 and IPv6, so every > ISP can add an IPv6 allocation and see _no_ change in fees at all. > (This does mean that we can get ISPs for whom there is a "mismatch" > between their IPv4 and IPv6 allocations, and they end up in a higher > category, but to be truly fair we'd need to have distinct proportional > fee for each of IPv4 and IPv6, and that's exactly what you don't want: > any addition of IPv6 means an additional fee.)" Another alternative would be to base all revenues on IPv4 until a flag day to be determined by the board at a later date with at least 12 months notice to the community after which flag day, all revenue calculations would shift to IPv6. Organizations which did not hold IPv6 after the flag day would have the option of maintaining their IPv4 records either by obtaining an IPv6 allocation or by continuing based on their IPv4 fee category. I'm sure there are also other possible ways to avoid some or all of the issues of mismatch. In fact, have we considered the possibility that instead of MAX(IPv4,IPv6) we charge based on MIN(IPv4,IPv6)? I'm not sure that would be a good idea, either, but I think it may not have ever been considered and I would be interested to see what the implications of such a structure might be. Owen From paul at redbarn.org Sun Apr 7 15:49:39 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 12:49:39 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> Message-ID: <5161CDD3.9090803@redbarn.org> Steven Ryerse wrote: > > I agree with Mathew and CB. We do need to move away from conservation > at the RIR level as a goal for both ipv4 and ipv6. Ripe is definitely > on the right track with > http://www.ripe.net/ripe/policies/proposals/2013-03 and I strongly > support that. The same changes should happen for the Arin RIR. > i know that it's a popular viewpoint -- many folks feel that the time for needs based allocation is over and that the invisible hand of the market is now capable of optimizing the holding of address space and the aggregation level of that space into routing table entries. so i thought i'd chime in: i consider that case to be extremely unmade as yet. even though i am in most other ways a free-marketeer. as stewards of a public resource ARIN has always been guided by RFC 2050 which requires recipients of these public resources to justify their need, no matter whether these resources are coming from a central pool or a private transfer. paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at redbarn.org Sun Apr 7 15:55:39 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 12:55:39 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> Message-ID: <5161CF3B.7050200@redbarn.org> Gary Buhrmaster wrote: > On Sun, Apr 7, 2013 at 4:58 PM, Steven Noble wrote: > .... >> I would love to have PI IPv6 space and as I have no IPv4 space from ARIN, adding IPv6 will raise my fees. What is the proposal to get legacy holders to adopt IPv6? > > The community has been fairly clear that Legacy holders are going to > have to come into the tent (of ARIN or equivalent RIR) to register > additional numbers of any type (ASN, IPv4, or IPv6). That includes > the new fees and agreements. indeed, "legacy holder" is not an exclusive property. one can be a "legacy and non-legacy holder", and that's what the community driven policies in the ARIN region have encouraged. if ipv6 space is needed, it's available. i can see how it might seem unfair to have received one kind of resource without fee and to then be asked to pay a fee for some other kind of resource. hopefully the unfairness in getting new resources for free even though others in like situations have to pay a fee is even more obvious. > So, the reason for legacy holders to adopt IPv6 is not because > it will (again) be free (or nearly so), but because that is where > one should be. +1. paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Sun Apr 7 15:53:49 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 12:53:49 -0700 Subject: [arin-ppml] Fee Philosophy (was: Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs) In-Reply-To: <36DDD38E-6C36-4B30-B537-25F2759591DD@delong.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> <51613621.9040702@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> <36DDD38E-6C36-4B30-B537-25F2759591DD@delong.com> Message-ID: On Apr 7, 2013 12:47 PM, "Owen DeLong" wrote: > > >> I am not saying it needs > >> to be right now, but I have a hard time understanding why we need to > >> contort the NRPM to patch over bad incentives in the fee schedule. > > > > No NRPM change is needed because of the Revised Fee schedule; fees under > > the new schedule will be lower for smallest ISPs in any case. > > > > The question is whether the community also provide support for a xx-small > > category which is even lower ($500/year) but distinguished by only a /40 > > IPv6 allocation. This is being discussed in Draft Policy ARIN-2013-3, and > > while it is enabled by the Revised Fee schedule, it is an independent item > > for the community to consider and can be adopted or not based on its merits. > > > > No, that is not the only question. Because of the situation created by the > restructuring of the fee schedule, we have several negative incentives > newly created. It is true that we can choose one negative incentive[1] by > not modifying the NRPM. Policy 2013-3 attempts to replace that negative > incentive with a different negative incentive[2]. > > No matter what, the fee schedule as it currently stands creates negative > incentives and I believe that is what Michael is calling into question here. > > [1] The fee structure and policy as currently adopted will create the > negative incentive for organizations in the xx-small IPv4 category to > not deploy IPv6 in order to save $500/year. > > [2] The combination of the adopted fee structure (assuming it is modified > to /40 instead of /48) and proposal 2013-3, if adopted would replace [1] > with the negative incentive for those providers in the XX-Small category > to obtain massively undersized allocations in order to save the same > amount of money, allowing them to deploy IPv6 without additional > address space cost, but very likely inflicting undue limitations on the > space issued to their customers. This negative incentive already > exists in both policy and the fee schedule for the X-Small category > in the form of support for /36s. > > >> Moreover, that standard is called into question by the fact that ARIN > >> charges based on the larger of the two address family allocations, with > >> no regard to the situation where there are radical differences between > >> IPv4 size and IPv6 size. > > > > Correct, and this has been covered on this mailing list before > > - > > > > "that is precisely the benefit of the revised fee schedule; > > every size ISP category now includes both IPv4 and IPv6, so every > > ISP can add an IPv6 allocation and see _no_ change in fees at all. > > (This does mean that we can get ISPs for whom there is a "mismatch" > > between their IPv4 and IPv6 allocations, and they end up in a higher > > category, but to be truly fair we'd need to have distinct proportional > > fee for each of IPv4 and IPv6, and that's exactly what you don't want: > > any addition of IPv6 means an additional fee.)" > > Another alternative would be to base all revenues on IPv4 until a flag > day to be determined by the board at a later date with at least 12 months > notice to the community after which flag day, all revenue calculations > would shift to IPv6. Organizations which did not hold IPv6 after the flag > day would have the option of maintaining their IPv4 records either by > obtaining an IPv6 allocation or by continuing based on their IPv4 fee > category. > I support the idea of an Ipv4 only fee structure. I support more the idea of an asn based fee structure. CB > I'm sure there are also other possible ways to avoid some or all of the > issues of mismatch. In fact, have we considered the possibility that > instead of MAX(IPv4,IPv6) we charge based on MIN(IPv4,IPv6)? > I'm not sure that would be a good idea, either, but I think it may not > have ever been considered and I would be interested to see what > the implications of such a structure might be. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Sun Apr 7 16:06:43 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Sun, 7 Apr 2013 20:06:43 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations forISPs In-Reply-To: <5161CDD3.9090803@redbarn.org> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CCAE4@ENI-MAIL.eclipse-networks.com> As I have offered in the recent past. No way should Arin assign me anything (IPv4) very large ? I used a /8 in a recent extreme example. But, as we are a small data center, I should be able to get at least whatever this community deems to be the minimum size. Arin?s current policies aside, I should be able to get a /22 for sure and maybe a /21 or a /20 ? as that is the right size for our organization. I?m all for right-sized block allocations probably based on a combination of current network size (Legacy included) and revenue or funding size plus things like BGP and so forth factored in. There are bright folks who can do a better job than me making something like that a policy but a similar change as currently being considered for RIPE should be made for ARIN as well. Thank you for your input! Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: Paul Vixie [mailto:paul at redbarn.org] Sent: Sunday, April 07, 2013 3:50 PM To: Steven Ryerse Cc: cb.list6; Matthew Kaufman; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations forISPs Steven Ryerse wrote: I agree with Mathew and CB. We do need to move away from conservation at the RIR level as a goal for both ipv4 and ipv6. Ripe is definitely on the right track with http://www.ripe.net/ripe/policies/proposals/2013-03 and I strongly support that. The same changes should happen for the Arin RIR. i know that it's a popular viewpoint -- many folks feel that the time for needs based allocation is over and that the invisible hand of the market is now capable of optimizing the holding of address space and the aggregation level of that space into routing table entries. so i thought i'd chime in: i consider that case to be extremely unmade as yet. even though i am in most other ways a free-marketeer. as stewards of a public resource ARIN has always been guided by RFC 2050 which requires recipients of these public resources to justify their need, no matter whether these resources are coming from a central pool or a private transfer. paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From owen at delong.com Sun Apr 7 16:24:11 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Apr 2013 13:24:11 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> Message-ID: <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> On Apr 6, 2013, at 19:58 , John Curran wrote: > On Apr 5, 2013, at 9:37 AM, Seth Mattinen wrote: > >> I see no reason to have a policy motivated strictly by fees to remain after fee changes that may or may not negate it, and to determine that it should go back through the PDP. Otherwise we're just cluttering the NRPM with irrelevant policy. > > Seth - > > The ARIN Board has often lowered the fee schedule as the > financial circumstances allow, and in general this has been > independent of number resource policy changes. > > The Revised Fee schedule is much improved over the existing > fee schedule with respect to organizations being able to > cost-effectively make use of IPv6 (as it is lower than the > existing fee schedule's smallest IPv6 category today.) Unless you are an end-user in which case adding IPv6 is still a (potentially significant percentage) increase over your IPv4 fees. > If the community does not support 2013-3, then smaller ISPs > will still have the current option of receiving a /36 of IPv6 > (if they wish); this will put them in the x-small fee category > of $1000 per year. > > If the community supports 2013-3, then some very small ISPs will > gain an option of taking a /40 allocation of IPv6 space, which > will put them in the xx-small fee category with fees of $500 per > year. > > If very small ISPs receiving /40 of IPv6 space does not make good > technical sense, then the community should not support the draft > policy... it's that simple. (These ISPs will still have lower fees > under the Revised Fee schedule, just not as low as they might have > had otherwise...) It's not that simple because we have to balance differing tradeoffs as a result of the fee structure. If we don't support the policy, then we create a disincentive to deploy IPv6 at all among these smaller ISPs. If we support the policy, then we create an incentive to do things which do not make good technical sense in order to avoid creating a disincentive to deploy IPv6. The current fee structure creates a Sophie's choice in policy. IMHO, the board seriously erred in creating this situation and should do whatever is possible to have a correction ready to present prior to the discussion of 2013-3 in Barbados. One possible way to distinguish ISP size for IPv6 would be to use annual gross revenue instead of total address holdings. I don't know if that would be an improvement or not. I realize it would be more complex to calculate and enforce. I think it would likely be more fair. I would like to hear about other creative ideas on ways to measure size and/or appropriate metrics to be used for fee determination. We have a lot of smart people in the community. I don't think we should look at the dysfunction of what we have always used and simply shrug it off to "but that's how we've always done it." Owen From matthew at matthew.at Sun Apr 7 16:29:29 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 13:29:29 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> Message-ID: <5161D729.9000502@matthew.at> On 4/7/2013 4:21 AM, John Curran wrote: > Matthew - > > The current fee schedule reads as follows: > > IPV6 ANNUAL FEES (NOTE: FEE WAIVERS IN EFFECT), EFFECTIVE UNTIL 30 JUNE 2013 > Size Category Fee (US Dollars) Block Size > Small $2,250 /40 to /32 > Medium $4,500 /31 to /30 > > There is 25% IPv6 fee waiver in effect (this started out at 100% and > was to be phased out over the last 4 years, although it was extended > at the 25% discount level for this year to carry us into the Revised > Fee schedule.) > > So, any ISP using IPv6 under _today's_ fee schedule has a minimum annual > fee of $1687 per year [$2250 * 75%] and that covers an allocation up to > /32 of IPv6. Unless we continue with the Revised Fee schedule, this is > effectively a minimum annual cost for any ISP making use of IPv6. > > If we want to lower that cost of using IPv6 for smaller organizations, > we need to find some manner to distinguish these smaller ISPs from all > ISPs, and this is typically done through the total address block holdings. I believe that way is not appropriate for the post-IPv4 world. No ISP should be getting smaller than /32. If you want to lower the cost of IPv6 for smaller organizations, you're free to do so, but tying to how much IPv6 space they have is likely to result in a very large number in the smallest category. And whether or not that's a problem *isn't a NRPM issue*. > > At this point, ARIN can sustain some number of smaller ISPs having lower > fees, and the Revised Fee schedule supports an ISP with no more than /20 > of IPv4 space and /36 of IPv6 being categorized as "x-small" with annual > fees of $1000/year. This category makes IPv6 more approachable for these > ISPs but it is indeed at the downside of a smaller IPv6 allocation. That shouldn't be happening. No reason an ISP should be getting a /36 instead of a /32, just encourages bad behavior. > As > you are aware, /36 of IPv6 space would provide for more than 4000 /48 > and _lots_ of /56 assignments (but there would be less in practice due > to internal hierarchy in assignment management.) Yes. So /36 is *barely* what it takes to remind an ISP that they shouldn't be treating IPv6 like a scarce commodity. Maybe. But /32 would be a lot safer, and so that's what *numbering policy* should be doing. > > Draft Policy ARIN-2013-3, combined with the Revised Fee schedule as > corrected, would continue this approach of allowing very small ISPs > with no more than /22 of IPv4 to obtain a corresponding IPv6 allocation > of /40 and have annual fees of $500 year in the "xx-small" category. The draft policy is bad numbering policy, and the fee schedule will provide an incentive for organizations to use the provisions of that bad numbering policy. Don't support. > The downside that you assert with Draft Policy ARIN-2013-3 is that > "this type of financial pressure towards false conservation is going > to give us things like/64-per-household instead of something sensible > that lets the thermostat be on a different subnet than the Xbox." > > Given that any ISP qualifying as xx-small (even with wildly aggressive > NAT) has no more 1024 customers each with a single IPv4 address, and the > /40 IPv6 allocation would provide them with the ability to make 65K /56 > assignments to these same customers, it does seem somewhat strange that > "false conservation" of those 65 thousand potential assignments would > drive xx-small ISPs to instead make /64 IPv6 customer assignments. Lets ignore IPv4 entirely for a moment... or pretend that in the near future people might single-home IPv4 with PA addresses but want their IPv6 to be PI space... In such a situation, organizations will choose to pack themselves and their customers into too little IPv6 space just to save a buck. I don't think that should be happening. > > The community can indicate that it does not support ARIN-2013-3 if the > resulting "false conservation" is a problem, and then there will be no use > of the xx-small/$500/yr fee category. The community on *this* mailing list should be debating what is best numbering policy, and not considering the tempting fruit of this week's fee schedule (subject to change without community input at any time). > Under the Revised Fee schedule, these > ISPs would be paying at least $1000/year based on a /36 IPv6 allocation > (which is still better than today's fees with IPv6 use as noted above.) > > It would be good to hear from ISPs who would qualify for the xx-small > $500/year category about the resulting temptation that it poses for > making smaller IPv6 customer assignments (and how they feel safer with > the /36 IPv6 minimum and corresponding $1000/year annual fee), as they > are the ones who are most affected by the outcome of this draft policy > consideration. It would be good to hear from small ISPs that are deploying IPv6 at all, but that's a whole separate problem. Matthew Kaufman From matthew at matthew.at Sun Apr 7 16:31:03 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 13:31:03 -0700 Subject: [arin-ppml] Fee Philosophy In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> <51613621.9040702@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> Message-ID: <5161D787.1050307@matthew.at> On 4/7/2013 4:46 AM, John Curran wrote: > No NRPM change is needed because of the Revised Fee schedule; fees > under the new schedule will be lower for smallest ISPs in any case. > The question is whether the community also provide support for a > xx-small category which is even lower ($500/year) but distinguished by > only a /40 IPv6 allocation. This is being discussed in Draft Policy > ARIN-2013-3, and while it is enabled by the Revised Fee schedule, it > is an independent item for the community to consider and can be > adopted or not based on its merits. And what happens when next week ARIN's board comes up with the xxxx-small category at $200/year, distinguished by a /60 IPv6 allocation. Are we supposed to create more bad numbering policy then too? Matthew Kaufman From matthew at matthew.at Sun Apr 7 16:35:26 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 13:35:26 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> Message-ID: <5161D88E.8090102@matthew.at> On 4/7/2013 9:58 AM, Steven Noble wrote: > On Apr 7, 2013, at 4:21 AM, John Curran wrote: > >> It would be good to hear from ISPs who would qualify for the xx-small >> $500/year category about the resulting temptation that it poses for >> making smaller IPv6 customer assignments (and how they feel safer with >> the /36 IPv6 minimum and corresponding $1000/year annual fee), as they >> are the ones who are most affected by the outcome of this draft policy >> consideration. > I would love to have PI IPv6 space and as I have no IPv4 space from ARIN, adding IPv6 will raise my fees. What is the proposal to get legacy holders to adopt IPv6? I'm in the same situation, and there isn't one. And it wouldn't be numbering policy anyway, it'd require a board that wants to set fees to zero or nearly so for your and my category. > > As noted before by others, I don't understand why a record has different costs based on what the record is for. The difference in fees seems to go against ARINs goal of allocating resources to the community. > > Is the overhead of an IPv6 allocation record 5x an ASN record? It is just ARIN trying to figure out how to maximize its own revenue. It knows that if it charged everyone the same amount, there would be some large organizations who could easily afford to pay more but from whom they aren't extracting any extra revenue. They justify this scaled pricing by then claiming that if they charged everyone so little that it was affordable to the smallest, they wouldn't bring in enough to pay for the usual overhead of costs that happens when there's money in the bank account to support those costs, despite the fact that the database itself could be run by volunteers for free or nearly so. Simple economics I'm afraid. Matthew Kaufman From matthew at matthew.at Sun Apr 7 16:46:29 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 13:46:29 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> Message-ID: <5161DB25.6000608@matthew.at> On 4/7/2013 1:24 PM, Owen DeLong wrote: > On Apr 6, 2013, at 19:58 , John Curran wrote: > >> On Apr 5, 2013, at 9:37 AM, Seth Mattinen wrote: >> >>> I see no reason to have a policy motivated strictly by fees to remain after fee changes that may or may not negate it, and to determine that it should go back through the PDP. Otherwise we're just cluttering the NRPM with irrelevant policy. >> Seth - >> >> The ARIN Board has often lowered the fee schedule as the >> financial circumstances allow, and in general this has been >> independent of number resource policy changes. >> >> The Revised Fee schedule is much improved over the existing >> fee schedule with respect to organizations being able to >> cost-effectively make use of IPv6 (as it is lower than the >> existing fee schedule's smallest IPv6 category today.) > Unless you are an end-user in which case adding IPv6 is still > a (potentially significant percentage) increase over your IPv4 > fees. Even more if you're a legacy IPv4 holder. > >> If the community does not support 2013-3, then smaller ISPs >> will still have the current option of receiving a /36 of IPv6 >> (if they wish); this will put them in the x-small fee category >> of $1000 per year. >> >> If the community supports 2013-3, then some very small ISPs will >> gain an option of taking a /40 allocation of IPv6 space, which >> will put them in the xx-small fee category with fees of $500 per >> year. >> >> If very small ISPs receiving /40 of IPv6 space does not make good >> technical sense, then the community should not support the draft >> policy... it's that simple. (These ISPs will still have lower fees >> under the Revised Fee schedule, just not as low as they might have >> had otherwise...) > It's not that simple because we have to balance differing tradeoffs > as a result of the fee structure. > > If we don't support the policy, then we create a disincentive to deploy > IPv6 at all among these smaller ISPs. But only a little, because the fees are still going down for the smaller ISPs... doing nothing with numbering policy and keeping the price change is a net win for them and doesn't break the future Internet. > > If we support the policy, then we create an incentive to do things which > do not make good technical sense in order to avoid creating a > disincentive to deploy IPv6. This *does* break the future Internet. I think I'd rather avoid that, even if it slows IPv6 adoption a little due to the appearance of bad pricing decisions (which are still lower than they were previously). > > The current fee structure creates a Sophie's choice in policy. IMHO, > the board seriously erred in creating this situation and should do > whatever is possible to have a correction ready to present prior > to the discussion of 2013-3 in Barbados. +1 on that. > > One possible way to distinguish ISP size for IPv6 would be to use > annual gross revenue instead of total address holdings. I don't know > if that would be an improvement or not. I realize it would be more > complex to calculate and enforce. I think it would likely be more fair. More fair would be everyone pays the same. Or everyone pays based on the amount of service they actually require from ARIN. Basing it on amount of space *or* gross revenue isn't "fair"... it is just a way to extract extra revenue from those who (in theory) have more to send to ARIN, which gives ARIN the opportunity to lower prices at the other end to keep the masses happy, or to just increase its overhead to ensure the money gets spent. But we see this all over the world these days, so it isn't like I'm surprised that they would behave this way. At least they're not creating additional address registries and then telling people they need to register their addresses there too in order to protect their trademarks, like some other winners of the how-can-we-charge-for-things-that-were-free game that the Internet played some years ago. > > I would like to hear about other creative ideas on ways to measure > size and/or appropriate metrics to be used for fee determination. Each email or call requires a fee payment above and beyond a tiny fee which everyone pays and which is equal for all. Or, worst case, a tiny fee per database row. Matthew Kaufman From paul at redbarn.org Sun Apr 7 17:05:28 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 14:05:28 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161D88E.8090102@matthew.at> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> Message-ID: <5161DF98.4010702@redbarn.org> ... Matthew Kaufman wrote: > On 4/7/2013 9:58 AM, Steven Noble wrote: >> As noted before by others, I don't understand why a record has >> different costs based on what the record is for. The difference in >> fees seems to go against ARINs goal of allocating resources to the >> community. >> >> Is the overhead of an IPv6 allocation record 5x an ASN record? > > It is just ARIN trying to figure out how to maximize its own revenue. i don't think that's a fair or true statement. > It knows that if it charged everyone the same amount, there would be > some large organizations who could easily afford to pay more but from > whom they aren't extracting any extra revenue. nor that one. > They justify this scaled pricing by then claiming that if they charged > everyone so little that it was affordable to the smallest, they > wouldn't bring in enough to pay for the usual overhead of costs that > happens when there's money in the bank account to support those costs, > despite the fact that the database itself could be run by volunteers > for free or nearly so. Simple economics I'm afraid. i've been here nine years now and i've been looking for the avoidable costs or the self-creating monetary vacuum that you're talking about here. i havn't found them. i don't think we'd like (you, me, anybody) a nearly-volunteer system without the controls, outreach, and policy process we're all getting from the RIR system in its current form. paul From owen at delong.com Sun Apr 7 17:14:47 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Apr 2013 14:14:47 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161DB25.6000608@matthew.at> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> <5161DB25.6000608@matthew.at> Message-ID: >> One possible way to distinguish ISP size for IPv6 would be to use >> annual gross revenue instead of total address holdings. I don't know >> if that would be an improvement or not. I realize it would be more >> complex to calculate and enforce. I think it would likely be more fair. > > More fair would be everyone pays the same. Or everyone pays based on the amount of service they actually require from ARIN. I disagree completely here. An end-user with a single /48 is not in any way reasonably expected to pay the same as an ISP with multiple ASNs, a /20 of IPv6 and an aggregate /6 of IPv4 space. I can't imagine in what possible universe anyone could imagine that to be fair. > Basing it on amount of space *or* gross revenue isn't "fair"... it is just a way to extract extra revenue from those who (in theory) have more to send to ARIN, which gives ARIN the opportunity to lower prices at the other end to keep the masses happy, or to just increase its overhead to ensure the money gets spent. We can agree to disagree on what constitutes "fair" here. I believe it is "fair" for those that are extracting a greater amount of revenue from the community resources they hold to contribute a greater share to the costs of maintaining said community resources. I don't see it so much as extracting extra revenue so much as differentiating the allocation of the total costs. I don't believe for a second that ARIN is increasing its overhead just to ensure the money gets spent. I have reviewed the ARIN public financials several years in a row and I believe that ARIN does a great deal for the community at a very reasonable cost to said community. > But we see this all over the world these days, so it isn't like I'm surprised that they would behave this way. At least they're not creating additional address registries and then telling people they need to register their addresses there too in order to protect their trademarks, like some other winners of the how-can-we-charge-for-things-that-were-free game that the Internet played some years ago. This really isn't a fair characterization of either structure. First, I agree that what has happened in the DNS realm has been badly mismanaged and that most of the mismanagement has come about as a result of various profit motives. However, to claim this was strictly a matter of "how can we charge for what was free?" is not at all accurate. The original switch to "charging for what was free" was an effort to sustain the existing infrastructure from a new funding source since the previous government contracts were about to become unfunded. I think that the number registries have done a vastly better job of the transition and keeping things cost-recovery based while providing the services the community has said it is valuable for them to provide at a very reasonable cost to the community. As much as I think that the new fee structure contains some really poor decisions that will drive poor number resource policy as a consequence, I do think that the board is trying to balance a number of tradeoffs and has made a reasonable attempt at doing so in a fair and consistent manner. >> I would like to hear about other creative ideas on ways to measure >> size and/or appropriate metrics to be used for fee determination. > > Each email or call requires a fee payment above and beyond a tiny fee which everyone pays and which is equal for all. Or, worst case, a tiny fee per database row. The problem with this is that it would again create negative incentives. It will financially incentivize the following negative behaviors: 1. Avoid updating records to reflect changes. 2. Downsize customer assignments to avoid having to request additional space. 3. Avoid interacting with ARIN until it's absolutely necessary and cannot be avoided through other contortions of ones own address space. I don't thin that's a desirable outcome any more than what is proposed in the adopted fee structure combined with what is proposed in 2013-3. Owen From cb.list6 at gmail.com Sun Apr 7 14:11:15 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 11:11:15 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAFBC34@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAFBC34@CHAXCH01.corp.arin.net> Message-ID: On Apr 7, 2013 11:04 AM, "John Curran" wrote: > > On Apr 7, 2013, at 10:30 AM, "cb.list6" wrote: >> >> Generally speaking we need to move away from conservation as goal for both ipv4 and ipv6 >> >> Structurally there is no need in v6 and the market will force it in v4 >> >> conservation at the rir level creates costly externalities in routing and other areas such as system design. >> >> Ripe is on the right track http://www.ripe.net/ripe/policies/proposals/2013-03 > > CB - > > Could you be a little more specific with regards to whether you support > "Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs"? It would > provide an option for ISPs who wish to be issued IPv6 allocations of > /40, which is smaller than present policy allows. The referenced RIPE > policy proposal is with regards to IPv4 allocation policy, not IPv6, so > it is hard to discern whether you support allowing ISPs to request a > smaller allocation if they wish to. > > Thanks! > /John > Do not support. I believe all allocations should be assigned at the /32 level and be automatically coupled with ASN assignment. The RIPE policy is too narrow, and unless someone beats me too it (please do ), I will introduce a similar but more general idea to ARIN that applies to v4 and v6. Without a conservation and audit mandate, I believe the arin community would benefit from smoother and more predictable interactions and business process. CB. > John Curran > President and CEO > ARIN > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Sun Apr 7 18:18:42 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 15:18:42 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161DF98.4010702@redbarn.org> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> Message-ID: <5161F0C2.9010800@matthew.at> On 4/7/2013 2:05 PM, Paul Vixie wrote: > ... > > Matthew Kaufman wrote: >> On 4/7/2013 9:58 AM, Steven Noble wrote: >>> As noted before by others, I don't understand why a record has >>> different costs based on what the record is for. The difference in >>> fees seems to go against ARINs goal of allocating resources to the >>> community. >>> >>> Is the overhead of an IPv6 allocation record 5x an ASN record? >> It is just ARIN trying to figure out how to maximize its own revenue. > i don't think that's a fair or true statement. Perhaps not. But we have clearly heard that we can't give everyone with a /32 of IPv6 the same low price otherwise ARIN wouldn't have enough money to operate. That's why there's this idea that somehow there need to be smaller categories than this, and scaled pricing schemes like this are always, at the root, a way to extract additional money from the top. > >> It knows that if it charged everyone the same amount, there would be >> some large organizations who could easily afford to pay more but from >> whom they aren't extracting any extra revenue. > nor that one. On this I'd definitely argue... We've heard several times that it wouldn't do to have all of the orgs holding IPv6 paying $500/year for that, because it wouldn't bring in enough money. > >> They justify this scaled pricing by then claiming that if they charged >> everyone so little that it was affordable to the smallest, they >> wouldn't bring in enough to pay for the usual overhead of costs that >> happens when there's money in the bank account to support those costs, >> despite the fact that the database itself could be run by volunteers >> for free or nearly so. Simple economics I'm afraid. > i've been here nine years now and i've been looking for the avoidable > costs or the self-creating monetary vacuum that you're talking about > here. i havn't found them. i don't think we'd like (you, me, anybody) a > nearly-volunteer system without the controls, outreach, and policy > process we're all getting from the RIR system in its current form. Well, some of the policy process and nearly all of the outreach are more than I would want to pay for, personally. Along with the entire travel budget. But even if it is true that ARIN is being exceptionally frugal, the draft policy is bad policy and we're only talking about it because ARIN doesn't want to ("can't") simply charge everyone the x-small price and be done with it. Matthew Kaufman From matthew at matthew.at Sun Apr 7 18:32:50 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 15:32:50 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> <5161DB25.6000608@matthew.at> Message-ID: <5161F412.6060405@matthew.at> On 4/7/2013 2:14 PM, Owen DeLong wrote: >>> One possible way to distinguish ISP size for IPv6 would be to use >>> annual gross revenue instead of total address holdings. I don't know >>> if that would be an improvement or not. I realize it would be more >>> complex to calculate and enforce. I think it would likely be more fair. >> More fair would be everyone pays the same. Or everyone pays based on the amount of service they actually require from ARIN. > I disagree completely here. An end-user with a single /48 is not in any way reasonably expected to pay the same as an ISP with multiple ASNs, a /20 of IPv6 and an aggregate /6 of IPv4 space. > > I can't imagine in what possible universe anyone could imagine that to be fair. Why not? As long as the price is reasonable I don't see who could possibly be opposed to a model where the only added costs are for those who actually cost ARIN more to service, not some arbitrary scaled scheme where well-run large orgs pay more than the tiny ones that need lots of handholding. Or, even better, a flat price for all. But of course there *would* be some opposed, because for every choice it isn't "fair" to someone. This is just like the US tax system... nobody thinks that any of the models are "fair". Flat tax? Unfair to the poor. Higher taxes for the rich? Disincentive to working harder and unfair to the rich. You can't win. And that's why we shouldn't be discussing the fee structure here at all. We should be discussing what numbering policy results in the best addressing plan for the Internet. And I believe that handing out /36 and /40 to ISPs doesn't do that. > >> Basing it on amount of space *or* gross revenue isn't "fair"... it is just a way to extract extra revenue from those who (in theory) have more to send to ARIN, which gives ARIN the opportunity to lower prices at the other end to keep the masses happy, or to just increase its overhead to ensure the money gets spent. > We can agree to disagree on what constitutes "fair" here. I believe it is "fair" for those that are extracting a greater amount of revenue from the community resources they hold to contribute a greater share to the costs of maintaining said community resources. So we should be charging mobile operators more than we charge dialup providers because the ARPU is higher? > > I don't see it so much as extracting extra revenue so much as differentiating the allocation of the total costs. Those are exactly the same thing. One just sounds better than the other. The idea is that you find the people who are willing to pay more, you figure out how to charge them more. In this case, you take some of that "extra" revenue and use it to drop the prices for the people who aren't willing to pay as much. Classic pricing theory covers this, and I would expect no less from any organization. But it doesn't make it "fair" either. > I don't believe for a second that ARIN is increasing its overhead just to ensure the money gets spent. I have reviewed the ARIN public financials several years in a row and I believe that ARIN does a great deal for the community at a very reasonable cost to said community. We've had offers to do it for less. > >> But we see this all over the world these days, so it isn't like I'm surprised that they would behave this way. At least they're not creating additional address registries and then telling people they need to register their addresses there too in order to protect their trademarks, like some other winners of the how-can-we-charge-for-things-that-were-free game that the Internet played some years ago. > This really isn't a fair characterization of either structure. First, I agree that what has happened in the DNS realm has been badly mismanaged and that most of the mismanagement has come about as a result of various profit motives. Ok, then we agree on that front. > However, to claim this was strictly a matter of "how can we charge for what was free?" is not at all accurate. The original switch to "charging for what was free" was an effort to sustain the existing infrastructure from a new funding source since the previous government contracts were about to become unfunded. I was there. It was a little of each. Lots of people volunteered to do things for free, but instead we had to play by the rules that were set up to make sure that a small number of people were able to sit at this newly-created trough. And here we are. Yes, numbering has worked out a lot better for the public interest than names did, but it still isn't great. > I think that the number registries have done a vastly better job of the transition and keeping things cost-recovery based while providing the services the community has said it is valuable for them to provide at a very reasonable cost to the community. Agreed. > > As much as I think that the new fee structure contains some really poor decisions that will drive poor number resource policy as a consequence, I do think that the board is trying to balance a number of tradeoffs and has made a reasonable attempt at doing so in a fair and consistent manner. Yes. But one of those tradeoffs is that they apparently can't figure out how to run ARIN in a world where everyone with a /32 pays the kind of fees that these "extra small" ISPs claim they can afford. That's not a numbering policy problem. > >>> I would like to hear about other creative ideas on ways to measure >>> size and/or appropriate metrics to be used for fee determination. >> Each email or call requires a fee payment above and beyond a tiny fee which everyone pays and which is equal for all. Or, worst case, a tiny fee per database row. > The problem with this is that it would again create negative incentives. It will financially incentivize the following negative behaviors: > > 1. Avoid updating records to reflect changes. > 2. Downsize customer assignments to avoid having to request additional space. > 3. Avoid interacting with ARIN until it's absolutely necessary and cannot be avoided > through other contortions of ones own address space. > > I don't thin that's a desirable outcome any more than what is proposed in the adopted fee structure combined with what is proposed in 2013-3. Of course not. But "charge the new extra small fee for everyone with a /32, and don't allocate anything smaller than /32" (which would provide enough of a fix for enough of the people right away) we are told isn't compatible with "don't drastically reduce ARIN's expenses", which is also not something we can impact with the numbering policy process. Matthew Kaufman From michael+ppml at burnttofu.net Sun Apr 7 21:06:34 2013 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Sun, 07 Apr 2013 18:06:34 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161DF98.4010702@redbarn.org> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> Message-ID: <5162181A.6000907@burnttofu.net> On 04/07/13 14:05, Paul Vixie wrote: > i've been here nine years now and i've been looking for the avoidable > costs or the self-creating monetary vacuum that you're talking about > here. i havn't found them. i don't think we'd like (you, me, anybody) a > nearly-volunteer system without the controls, outreach, and policy > process we're all getting from the RIR system in its current form. In many organizations, there's a perception of waste from those outside looking in. That's unfortunate, and frequently it's a misperception. My goal is to provide a revenue-neutral alternative to the current proposals on the table. As I mentioned in my previous email, I think we can just tweak the current fee schedule so that an IPv6 ISP allocation of exactly a /32 allows for pricing based on the IPv4 category, rather than MAX(IPv4,IPv6) as would continue to be the case for every other allocation in the ISP fee schedule. This attempts to minimize the disruption to the proposed fee schedule while fixing the incentive issues. It's revenue-neutral because ARIN would be holding the /32 in reserve anyway, in order to comply with 2013-3. I don't like discussing the fee schedule on PPML any more than anyone else, but as an operator, I am being asked to support an operationally-suboptimal policy as a band-aid for this one issue in the fee schedule, and that's what's giving me heartburn right now. michael From paul at redbarn.org Sun Apr 7 21:10:28 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 18:10:28 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5162181A.6000907@burnttofu.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5162181A.6000907@burnttofu.net> Message-ID: <51621904.5020005@redbarn.org> ... Michael Sinatra wrote: > ... > > I don't like discussing the fee schedule on PPML any more than anyone > else, but as an operator, I am being asked to support an > operationally-suboptimal policy as a band-aid for this one issue in the > fee schedule, and that's what's giving me heartburn right now. are you aware of the other arin mailing list, limited to members unlike this public policy mailing list (PPML), where discussions of fees paid would be somewhat more targeted since it would be a discussion of fee-payers? this mailing list is documented here: http://lists.arin.net/mailman/listinfo/arin-discuss paul From michael+ppml at burnttofu.net Sun Apr 7 21:18:48 2013 From: michael+ppml at burnttofu.net (Michael Sinatra) Date: Sun, 07 Apr 2013 18:18:48 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <51621904.5020005@redbarn.org> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5162181A.6000907@burnttofu.net> <51621904.5020005@redbarn.org> Message-ID: <51621AF8.6050200@burnttofu.net> On 04/07/13 18:10, Paul Vixie wrote: > ... > > Michael Sinatra wrote: >> ... >> >> I don't like discussing the fee schedule on PPML any more than anyone >> else, but as an operator, I am being asked to support an >> operationally-suboptimal policy as a band-aid for this one issue in the >> fee schedule, and that's what's giving me heartburn right now. > > are you aware of the other arin mailing list, limited to members unlike > this public policy mailing list (PPML), where discussions of fees paid > would be somewhat more targeted since it would be a discussion of > fee-payers? this mailing list is documented here: > > http://lists.arin.net/mailman/listinfo/arin-discuss Yes. To be honest with you, I don't like discussing the fee schedule at all. :) I think it's relevant for PPML because we're being asked to support a policy where I believe an operationally-superior option is to tweak the fee schedule, so I wanted to explain my opposition to that policy. However, I think it's a good idea to raise it on arin-discuss@, and I'll do that...after dinner. :) michael From snoble at sonn.com Sun Apr 7 21:31:59 2013 From: snoble at sonn.com (Steven Noble) Date: Sun, 7 Apr 2013 18:31:59 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <51621904.5020005@redbarn.org> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5162181A.6000907@burnttofu.net> <51621904.5020005@redbarn.org> Message-ID: <1CBE101B-9903-4B31-B040-480F64B5201E@sonn.com> On Apr 7, 2013, at 6:10 PM, Paul Vixie wrote: >> > > are you aware of the other arin mailing list, limited to members unlike > this public policy mailing list (PPML), where discussions of fees paid > would be somewhat more targeted since it would be a discussion of > fee-payers? this mailing list is documented here: I am a fee payer to ARIN, I pay $100 a year for my ASN. I do not have access to these lists, so I disagree. From paul at redbarn.org Sun Apr 7 21:41:38 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 18:41:38 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161F0C2.9010800@matthew.at> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5161F0C2.9010800@matthew.at> Message-ID: <51622052.6020401@redbarn.org> ... Matthew Kaufman wrote: > ... we have clearly heard that we can't give everyone with a /32 of > IPv6 the same low price otherwise ARIN wouldn't have enough money to > operate. ... can you hum a few bars? that is, i didn't clearly hear that. > ... We've heard several times that it wouldn't do to have all of the > orgs holding IPv6 paying $500/year for that, because it wouldn't bring > in enough money. this also. (somebody from ARIN, speaking for ARIN, said this?) > On 4/7/2013 2:05 PM, Paul Vixie wrote: >> i've been here nine years now and i've been looking for the avoidable >> costs or the self-creating monetary vacuum that you're talking about >> here. i havn't found them. i don't think we'd like (you, me, anybody) a >> nearly-volunteer system without the controls, outreach, and policy >> process we're all getting from the RIR system in its current form. > > Well, some of the policy process and nearly all of the outreach are > more than I would want to pay for, personally. > > Along with the entire travel budget. that's a short-sighted view. the thing we live on is round, and telepresence doesn't reach to the hallways. the RIR system and the larger internet governance community that the RIR system is part of, meets all over the world. as someone who just crossed the 85K mile threshold in the three months since january 1, i'm the first to admit that we all travel too much. but the travel budget is there for good reason. (as is the policy and outreach budgets.) if you think that stuff is all silly or crazy, that helps me understand why you think a mostly-volunteer org could do the important part of what ARIN does (maintaining the database) but it also puts a discount on all of your observations since it's so completely unrealistic. > But even if it is true that ARIN is being exceptionally frugal, the > draft policy is bad policy and we're only talking about it because > ARIN doesn't want to ("can't") simply charge everyone the x-small > price and be done with it. i think that arin is reasonably but not exceptionally frugal. and i'm listening carefully to your comments about the fee schedule. Matthew Kaufman wrote: > ... Or, even better, a flat price for all. But of course there *would* > be some opposed, because for every choice it isn't "fair" to someone. i think it's safe to say that any fee schedule will be deemed unfair by someone. that doesn't mean we should balance the perceived unfairness. rather, it means we have to form and then follow a theory of objective fairness. > This is just like the US tax system... nobody thinks that any of the > models are "fair". Flat tax? Unfair to the poor. Higher taxes for the > rich? Disincentive to working harder and unfair to the rich. You can't > win. we're way off the topic of arin policy at the moment, but i'm concerned that you think the progressive tax system is a disincentive to working harder. no matter how high the next tax bracket up might be, you keep more if you earn more. my incentives are based on what i earn and keep; are yours based on perceived fairness? >> I don't see it so much as extracting extra revenue so much as >> differentiating the allocation of the total costs. > > Those are exactly the same thing. One just sounds better than the other. > > The idea is that you find the people who are willing to pay more, you > figure out how to charge them more. In this case, you take some of > that "extra" revenue and use it to drop the prices for the people who > aren't willing to pay as much. Classic pricing theory covers this, and > I would expect no less from any organization. ... this is... completely wrong. the ARIN fee schedule is based in no way on willingness to pay more. >> I don't believe for a second that ARIN is increasing its overhead >> just to ensure the money gets spent. I have reviewed the ARIN public >> financials several years in a row and I believe that ARIN does a >> great deal for the community at a very reasonable cost to said >> community. > > We've had offers to do it for less. can you be more specific? has someone offered to maintain ARIN-like registry records for you, at a lower cost? got a URL? if someone out there can do it for less it may simply be that their real business model is in trading addresses and the registry function is a sunk cost for them. > [the ARIN Board] apparently can't figure out how to run ARIN in a > world where everyone with a /32 pays the kind of fees that these > "extra small" ISPs claim they can afford. That's not a numbering > policy problem. i think it is a numbering policy issue. in an address space with 4 billion /32's, the dominant cost to the community of any allocation will be the global routing table slot not the allocation, but the need for size categories still exists, simply because larger allocations (when justified) are a more conservative use of those routing table slots. that's a settled issue, though you're welcome to reopen it with a policy proposal of course. from the settled policy on this topic, fee schedules are constructed. paul From paul at redbarn.org Sun Apr 7 21:42:56 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 18:42:56 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <1CBE101B-9903-4B31-B040-480F64B5201E@sonn.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5162181A.6000907@burnttofu.net> <51621904.5020005@redbarn.org> <1CBE101B-9903-4B31-B040-480F64B5201E@sonn.com> Message-ID: <516220A0.2040209@redbarn.org> ... Steven Noble wrote: > On Apr 7, 2013, at 6:10 PM, Paul Vixie wrote: >> are you aware of the other arin mailing list, limited to members unlike >> this public policy mailing list (PPML), where discussions of fees paid >> would be somewhat more targeted since it would be a discussion of >> fee-payers? this mailing list is documented here: > > I am a fee payer to ARIN, I pay $100 a year for my ASN. I do not have access to these lists, so I disagree. you're right; my information was out of date. not all ARIN fee-payers are ARIN members. i guess that means PPML has to allow fee schedule discussions. paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Sun Apr 7 22:06:25 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 19:06:25 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161CDD3.9090803@redbarn.org> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> Message-ID: On Apr 7, 2013 12:49 PM, "Paul Vixie" wrote: > > > > Steven Ryerse wrote: >> >> I agree with Mathew and CB. We do need to move away from conservation at the RIR level as a goal for both ipv4 and ipv6. Ripe is definitely on the right track with http://www.ripe.net/ripe/policies/proposals/2013-03and I strongly support that. The same changes should happen for the Arin RIR. > > > i know that it's a popular viewpoint -- many folks feel that the time for needs based allocation is over and that the invisible hand of the market is now capable of optimizing the holding of address space and the aggregation level of that space into routing table entries. > Popular viewpoint go far in a bottom up process such as arin. In fact, the whole thing is a popularity contest. > so i thought i'd chime in: i consider that case to be extremely unmade as yet. even though i am in most other ways a free-marketeer. as stewards of a public resource ARIN has always been guided by RFC 2050 which requires recipients of these public resources to justify their need, no matter whether these resources are coming from a central pool or a private transfer. > > paul Does that mean you require an update to rfc 2050 to move ? I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01 As it stands, speaking from experience, the justification story in v4 and v6 drives design choices. That is an unfortunate fact and negatively impacts system design. Should 2050bis ask rir not do this fair policy? From what I read in 2050bis is that is says the rir can make their own policy and 2050 is dead. Do you read it differently? CB -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at redbarn.org Sun Apr 7 22:19:04 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 19:19:04 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> Message-ID: <51622918.7060104@redbarn.org> ... cb.list6 wrote: > > > On Apr 7, 2013 12:49 PM, "Paul Vixie" > wrote: > > > > i know that it's a popular viewpoint -- many folks feel that the > time for needs based allocation is over and that the invisible hand of > the market is now capable of optimizing the holding of address space > and the aggregation level of that space into routing table entries. > > > > Popular viewpoint go far in a bottom up process such as arin. In fact, > the whole thing is a popularity contest. > i said it was popular, not that it could win a popularity contest. > > so i thought i'd chime in: i consider that case to be extremely > unmade as yet. even though i am in most other ways a free-marketeer. > as stewards of a public resource ARIN has always been guided by RFC > 2050 which requires recipients of these public resources to justify > their need, no matter whether these resources are coming from a > central pool or a private transfer. > > > > paul > > Does that mean you require an update to rfc 2050 to move ? > not at all. i think RFC 2050 was and remains correct in this regard. i'll "move" when and if my mind changes on the matter. > I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01 > > ... > > Should 2050bis ask rir not do this fair policy? From what I read in > 2050bis is that is says the rir can make their own policy and 2050 is > dead. > > Do you read it differently? > i read it to accurately explain that not every RIR still follows the needs based justification described in RFC 2050. it's a description of the current RIR system. 2050bis does not "ask" RIRs to do anything, it's a description of what they actually do. > As it stands, speaking from experience, the justification story in v4 > and v6 drives design choices. That is an unfortunate fact and > negatively impacts system design. > i'm intrigued by this statement. i hope you are willing to share some of your experiences as to how needs based justification has negatively driven some design choices. paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Sun Apr 7 22:34:40 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 19:34:40 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <51622918.7060104@redbarn.org> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> <51622918.7060104@redbarn.org> Message-ID: On Apr 7, 2013 7:19 PM, "Paul Vixie" wrote: > > ... > > cb.list6 wrote: >> >> >> On Apr 7, 2013 12:49 PM, "Paul Vixie" wrote: >> > >> > i know that it's a popular viewpoint -- many folks feel that the time for needs based allocation is over and that the invisible hand of the market is now capable of optimizing the holding of address space and the aggregation level of that space into routing table entries. >> > >> >> Popular viewpoint go far in a bottom up process such as arin. In fact, the whole thing is a popularity contest. > > > i said it was popular, not that it could win a popularity contest. > > >> > so i thought i'd chime in: i consider that case to be extremely unmade as yet. even though i am in most other ways a free-marketeer. as stewards of a public resource ARIN has always been guided by RFC 2050 which requires recipients of these public resources to justify their need, no matter whether these resources are coming from a central pool or a private transfer. >> > >> > paul >> >> Does that mean you require an update to rfc 2050 to move ? > > > not at all. i think RFC 2050 was and remains correct in this regard. i'll "move" when and if my mind changes on the matter. > >> I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01 >> >> ... >> >> Should 2050bis ask rir not do this fair policy? From what I read in 2050bis is that is says the rir can make their own policy and 2050 is dead. >> >> Do you read it differently? > > > i read it to accurately explain that not every RIR still follows the needs based justification described in RFC 2050. it's a description of the current RIR system. 2050bis does not "ask" RIRs to do anything, it's a description of what they actually do. > > >> As it stands, speaking from experience, the justification story in v4 and v6 drives design choices. That is an unfortunate fact and negatively impacts system design. > > > i'm intrigued by this statement. i hope you are willing to share some of your experiences as to how needs based justification has negatively driven some design choices. > > paul I just wrote a page of explanation and deleted it. If I have to explain it, you would not understand. And you do not understand today's data networks at all. I feel bad and outrageous saying that. But, given hundreds of millions of mobile phone users behind cgn today, perhaps your question is outrageous Note that att and vz have both rolled cgn to their dsl subs. Yet arin is not exhausted. Interesting? CB. -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul at redbarn.org Sun Apr 7 23:23:25 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 20:23:25 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> <51622918.7060104@redbarn.org> Message-ID: <5162382D.5090208@redbarn.org> cb.list6 wrote: > > > On Apr 7, 2013 7:19 PM, "Paul Vixie" > wrote: > > > i'm intrigued by this statement. i hope you are willing to share > some of your experiences as to how needs based justification has > negatively driven some design choices. > > I just wrote a page of explanation and deleted it. > > If I have to explain it, you would not understand. And you do not > understand today's data networks at all. I feel bad and outrageous > saying that. But, given hundreds of millions of mobile phone users > behind cgn today, perhaps your question is outrageous > i'm like that. > Note that att and vz have both rolled cgn to their dsl subs. > > Yet arin is not exhausted. > > Interesting? > no. if i wanted to roll out way more devices in the next few years than are in ARIN's free pool, and i had several competitors who i knew were doing the same, then i'd try pretty hard to run V6 native, and if my hardware partners said they wouldn't be able to do that as soon or as cheaply, i'd look at CGN. paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Sun Apr 7 23:28:12 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 20:28:12 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5162382D.5090208@redbarn.org> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> <51622918.7060104@redbarn.org> <5162382D.5090208@redbarn.org> Message-ID: On Sun, Apr 7, 2013 at 8:23 PM, Paul Vixie wrote: > > > cb.list6 wrote: > > > On Apr 7, 2013 7:19 PM, "Paul Vixie" wrote: > >> i'm intrigued by this statement. i hope you are willing to share some of >> your experiences as to how needs based justification has negatively driven >> some design choices. > > I just wrote a page of explanation and deleted it. > > If I have to explain it, you would not understand. And you do not understand > today's data networks at all. I feel bad and outrageous saying that. But, > given hundreds of millions of mobile phone users behind cgn today, perhaps > your question is outrageous > > > i'm like that. > > > Note that att and vz have both rolled cgn to their dsl subs. > > Yet arin is not exhausted. > > Interesting? > > > no. if i wanted to roll out way more devices in the next few years than are > in ARIN's free pool, and i had several competitors who i knew were doing the > same, then i'd try pretty hard to run V6 native, and if my hardware partners > said they wouldn't be able to do that as soon or as cheaply, i'd look at > CGN. > > paul What if it was 2 years ago and you wanted to launch a cloud service? http://www.bbc.co.uk/news/technology-12859585 Then again, its not you, its them. Or, restated, it's us. And, here we are. CB From jcurran at arin.net Sun Apr 7 23:57:56 2013 From: jcurran at arin.net (John Curran) Date: Mon, 8 Apr 2013 03:57:56 +0000 Subject: [arin-ppml] fee schedule (was: Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs) In-Reply-To: <5161D88E.8090102@matthew.at> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFC7C0@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 1:35 PM, Matthew Kaufman wrote: > It is just ARIN trying to figure out how to maximize its own revenue. To be clear, the change in the Revised Fee schedule is revenue neutral; please review the slides referenced earlier for additional information. > It knows that if it charged everyone the same amount, there would be some large organizations who could easily afford to pay more but from whom they aren't extracting any extra revenue. Actually, we could easily go to a single fee for all ISP regardless of size. This would result in significantly higher fees for smaller ISPs (as the per-ISP fee would approximately $2800 per year.) This does not seem to be the right direction if we're trying not to burden smaller ISPs. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Mon Apr 8 00:19:47 2013 From: jcurran at arin.net (John Curran) Date: Mon, 8 Apr 2013 04:19:47 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161DB25.6000608@matthew.at> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> <5161DB25.6000608@matthew.at> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFCD57@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 1:46 PM, Matthew Kaufman wrote: > More fair would be everyone pays the same. Or everyone pays based on the amount of service they actually require from ARIN. We can have a fee schedule as complex or as simple as needed, but our approach has been size categories based on total IP address holdings, so we need to be certain to have community support and confidence in any other schedule if it is a major departure from that approach. Incrementing the schedule as we have done over the years is easier, but not the only possible type of change. > Basing it on amount of space *or* gross revenue isn't "fair"... it is just a way to extract extra revenue from those who (in theory) have more to send to ARIN, which gives ARIN the opportunity to lower prices at the other end to keep the masses happy, or to just increase its overhead to ensure the money gets spent. A wonderful (but incorrect) characterization given that we do not expect a meaningful change in revenue as a result of the Revised Fee schedule. > Each email or call requires a fee payment above and beyond a tiny fee which everyone pays and which is equal for all. Or, worst case, a tiny fee per database row. Actually, we get fairly close to a single fee per database row with the Revised Fee schedule; this is exactly the case with the end-user fees, whereas ISP fees still remain based on total holdings but are quite algorithmic. If ISPs were subsequently changed to be total records, you'd then have the structure that you suggest. Note that reducing the fees per record requires lowering the costs associated with changes to registry services (example: feature enhancements for ARIN Online, RESTful interfaces, DNSSEC, etc.) That plus reducing the change in policy that also results in more registry development work. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Mon Apr 8 00:34:27 2013 From: jcurran at arin.net (John Curran) Date: Mon, 8 Apr 2013 04:34:27 +0000 Subject: [arin-ppml] Fee Philosophy In-Reply-To: <5161D787.1050307@matthew.at> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> <51613621.9040702@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> <5161D787.1050307@matthew.at> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFD2ED@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 1:31 PM, Matthew Kaufman wrote: > On 4/7/2013 4:46 AM, John Curran wrote: >> No NRPM change is needed because of the Revised Fee schedule; fees under the new schedule will be lower for smallest ISPs in any case. The question is whether the community also provide support for a xx-small category which is even lower ($500/year) but distinguished by only a /40 IPv6 allocation. This is being discussed in Draft Policy ARIN-2013-3, and while it is enabled by the Revised Fee schedule, it is an independent item for the community to consider and can be adopted or not based on its merits. > > And what happens when next week ARIN's board comes up with the xxxx-small category at $200/year, distinguished by a /60 IPv6 allocation. Are we supposed to create more bad numbering policy then too? Matthew - You shouldn't support the Draft Policy ARIN-2013-3 if don't believe it to be fair and technically sound. If the draft policy is not adopted, the fee schedule entry does not matter. If it is supported by the community, then the policy change will happen because that meant that overall people felt it was fair and technically sound. IF the Board were to add a /60 xxx-small category, nothing would change unless someone also introduced a policy proposal to lower the minimum to that size. There's no obligation to make a policy change, but if some ISPs thought it made sense, you'd likely see it get submitted and also discussed here. If it were found to be supported by the community, it would be adopted and would not be "bad numbering policy" but just "policy Matthew doesn't agree with" FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Mon Apr 8 00:55:12 2013 From: jcurran at arin.net (John Curran) Date: Mon, 8 Apr 2013 04:55:12 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAFCD57@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> <5161DB25.6000608@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAFCD57@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFDA55@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 9:19 PM, John Curran wrote: > > We can have a fee schedule as complex or as simple as needed, > but our approach has been size categories based on total IP > address holdings, so we need to be certain to have community > support and confidence in any other schedule if it is a major > departure from that approach. Incrementing the schedule as we > have done over the years is easier, but not the only possible > type of change. > ... > Actually, we get fairly close to a single fee per database row > with the Revised Fee schedule; this is exactly the case with > the end-user fees, whereas ISP fees still remain based on total > holdings but are quite algorithmic. If ISPs were subsequently > changed to be total records, you'd then have the structure that > you suggest. As followup, I was reminded that the fee approach is not "either/or"; i.e. it is also possible to have a single flat fee per organization plus a fee per IP block if this is viewed as more equitable, and would be similar to the type of change that RIPE just went through - There is nothing to prevent ARIN from taking a similar approach (I do not know if such a structure would be seen as beneficial or not by the community) but it is very important to be certain before restructuring of the fees since any switchover of that type requires significant business process and system changes. FYI, /John John Curran President and CEO ARIN From matthew at matthew.at Mon Apr 8 01:00:31 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 22:00:31 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <51622052.6020401@redbarn.org> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5161F0C2.9010800@matthew.at> <51622052.6020401@redbarn.org> Message-ID: <51624EEF.9080208@matthew.at> On 4/7/2013 6:41 PM, Paul Vixie wrote: > ... > > Matthew Kaufman wrote: >> ... we have clearly heard that we can't give everyone with a /32 of >> IPv6 the same low price otherwise ARIN wouldn't have enough money to >> operate. ... > can you hum a few bars? that is, i didn't clearly hear that. Quoting John Curran from 28 March 2013 2:04 AM: "Owen - It's not 300 ISPs; it really has to be all ISPs with the same holdings and with /32 as the lower bound, then that will be the _majority of all ISPs_. Even with some aggressive efficiencies baked into ARIN's operating costs, the fees would be $1500 or more per year as a result. This is truly a question of trying to achieve the lowest fees for these smaller providers, and being able to have some amount of stratification allows their fees to be lower than the average otherwise." I am making the small leap here that since John believes it would be "$1500 or more per year as a result" best-case that numbers like $500/year (the new XX-Small rate that I'm referring to as "the same low price" above) would bring in about 1/3rd of what ARIN "needs". But I don't think that's much of a leap. > >> ... We've heard several times that it wouldn't do to have all of the >> orgs holding IPv6 paying $500/year for that, because it wouldn't bring >> in enough money. > this also. (somebody from ARIN, speaking for ARIN, said this?) See above. Don't even need to make the above leap to figure out that $500/year "wouldn't bring in enough money". > >> On 4/7/2013 2:05 PM, Paul Vixie wrote: >>> i've been here nine years now and i've been looking for the avoidable >>> costs or the self-creating monetary vacuum that you're talking about >>> here. i havn't found them. i don't think we'd like (you, me, anybody) a >>> nearly-volunteer system without the controls, outreach, and policy >>> process we're all getting from the RIR system in its current form. >> Well, some of the policy process and nearly all of the outreach are >> more than I would want to pay for, personally. >> >> Along with the entire travel budget. > that's a short-sighted view. the thing we live on is round, and > telepresence doesn't reach to the hallways. the RIR system and the > larger internet governance community that the RIR system is part of, > meets all over the world. as someone who just crossed the 85K mile > threshold in the three months since january 1, i'm the first to admit > that we all travel too much. but the travel budget is there for good > reason. (as is the policy and outreach budgets.) if you think that stuff > is all silly or crazy, that helps me understand why you think a > mostly-volunteer org could do the important part of what ARIN does > (maintaining the database) but it also puts a discount on all of your > observations since it's so completely unrealistic. I'm not sure why the entire address-holding community needs to be funding this outreach and worldwide face-to-face meetings for governance. Never mind that the idea that the governance can't be done over email just shows how useless this whole Internet thing is. > >> But even if it is true that ARIN is being exceptionally frugal, the >> draft policy is bad policy and we're only talking about it because >> ARIN doesn't want to ("can't") simply charge everyone the x-small >> price and be done with it. > i think that arin is reasonably but not exceptionally frugal. and i'm > listening carefully to your comments about the fee schedule. > thank you > > Matthew Kaufman wrote: > >> ... Or, even better, a flat price for all. But of course there *would* >> be some opposed, because for every choice it isn't "fair" to someone. > i think it's safe to say that any fee schedule will be deemed unfair by > someone. that doesn't mean we should balance the perceived unfairness. > rather, it means we have to form and then follow a theory of objective > fairness. or not, and just have it be unfair. but either way, having ISPs get smaller than /32 of IPv6 is a bad idea. > >> This is just like the US tax system... nobody thinks that any of the >> models are "fair". Flat tax? Unfair to the poor. Higher taxes for the >> rich? Disincentive to working harder and unfair to the rich. You can't >> win. > we're way off the topic of arin policy at the moment, but i'm concerned > that you think the progressive tax system is a disincentive to working > harder. no matter how high the next tax bracket up might be, you keep > more if you earn more. my incentives are based on what i earn and keep; > are yours based on perceived fairness? well, the US tax system is certainly an incentive to move my income from salary to long-term capital gains, but yes, we're way off the topic here. > >>> I don't see it so much as extracting extra revenue so much as >>> differentiating the allocation of the total costs. >> Those are exactly the same thing. One just sounds better than the other. >> >> The idea is that you find the people who are willing to pay more, you >> figure out how to charge them more. In this case, you take some of >> that "extra" revenue and use it to drop the prices for the people who >> aren't willing to pay as much. Classic pricing theory covers this, and >> I would expect no less from any organization. ... > this is... completely wrong. the ARIN fee schedule is based in no way on > willingness to pay more. Willingness, ability, same thing. Since I started writing this reply, John has chimed in to note that if everyone paid the same it would need to be $2800/year. So ARIN has happily found a few ISPs that are willing to pay so much more than some others can pay as little as $500. > >>> I don't believe for a second that ARIN is increasing its overhead >>> just to ensure the money gets spent. I have reviewed the ARIN public >>> financials several years in a row and I believe that ARIN does a >>> great deal for the community at a very reasonable cost to said >>> community. >> We've had offers to do it for less. > can you be more specific? has someone offered to maintain ARIN-like > registry records for you, at a lower cost? got a URL? if someone out > there can do it for less it may simply be that their real business model > is in trading addresses and the registry function is a sunk cost for them. I wish my email archive searching was this good... way back when, in the original formation of the RIRs days, several people volunteered to run free address registries out of the goodness of their heart (and I'm sure a few others had ulterior motives as well). I can't remember who right off hand though. > >> [the ARIN Board] apparently can't figure out how to run ARIN in a >> world where everyone with a /32 pays the kind of fees that these >> "extra small" ISPs claim they can afford. That's not a numbering >> policy problem. > i think it is a numbering policy issue. in an address space with 4 > billion /32's, the dominant cost to the community of any allocation will > be the global routing table slot not the allocation, but the need for > size categories still exists, simply because larger allocations (when > justified) are a more conservative use of those routing table slots. Yes. Which is a good reason for all ISPs to have as few chunks (preferably one) of as big as they need long term and to use them wisely. In IPv6, "wisely" doesn't mean "crowd down to the bottom /40 or smaller of a /32" however. > that's a settled issue, though you're welcome to reopen it with a policy > proposal of course. from the settled policy on this topic, fee schedules > are constructed. But then constructed in a way that opens the address allocation policy again. It happened once when /36 allocations were added (motivated mostly) because of the fee schedule, it might happen again now when /40 needs to be added because of the fee schedule,... when will it end? Matthew Kaufman From matthew at matthew.at Mon Apr 8 01:09:27 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 22:09:27 -0700 Subject: [arin-ppml] fee schedule In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAFC7C0@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAFC7C0@CHAXCH01.corp.arin.net> Message-ID: <51625107.9050305@matthew.at> On 4/7/2013 8:57 PM, John Curran wrote: > On Apr 7, 2013, at 1:35 PM, Matthew Kaufman wrote: > >> It is just ARIN trying to figure out how to maximize its own revenue. > To be clear, the change in the Revised Fee schedule is revenue neutral; > please review the slides referenced earlier for additional information. > I wasn't trying to claim that the revised fees aren't revenue neutral. All I was trying to claim is that ARIN gets more with the current fee schedule than they would with everyone paying $500. And they can do that because some organizations are more than willing to pay a lot more than $500. >> It knows that if it charged everyone the same amount, there would be some large organizations who could easily afford to pay more but from whom they aren't extracting any extra revenue. > Actually, we could easily go to a single fee for all ISP regardless of > size. This would result in significantly higher fees for smaller ISPs > (as the per-ISP fee would approximately $2800 per year.) This does not > seem to be the right direction if we're trying not to burden smaller ISPs. I believe this just proved my point above. Not finding the few who are willing to pay more and charging them more would result in $2800/year across the board fees. Which would then result in a bunch of small ISPs not bothering to pay that at all, which *wouldn't* be revenue neutral. (And then I suppose it would be even more than $2800/year, wouldn't it?) I'm not saying ARIN is evil... far from it, ARIN is doing *exactly* what I would expect an entity setting prices to do. It has segmented its pricing such that some can pay more and others can pay less and the number of customers is high. Making the price $2800/year for the smallest ISPs would result in fewer of them being able to afford the service, and yet the ones paying $32,000/year under the new schedule are clearly ok with paying that much so that there's a $500 price point available for others. The problem is that the current set of steps is based on something we shouldn't be messing with. There shouldn't be a /48 or smaller step and there shouldn't be a /36 to /48 step, because the existence of both of those has pressured the numbering policy into once offering /36 as an option instead of /32, and now trying to find something even smaller to offer... only because to have all of the small ones at the /32 step would (in order to be revenue neutral) require all of them to pay ~$1500/year. Find something else to base the fee steps on before we do something else stupid, please. Matthew Kaufman From owen at delong.com Mon Apr 8 01:09:08 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Apr 2013 22:09:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5161F412.6060405@matthew.at> References: <5153387E.6060700@arin.net> <515DFBE4.8080100@rollernet.us> <515E0477.10706@umn.edu> <515EFAD2.1010101@rollernet.us> <515EFC79.9080406@umn.edu> <515EFDB9.2010700@rollernet.us> <8DA1853CE466B041B104C1CAEE00B3748FAE974C@CHAXCH01.corp.arin.net> <59B7FA64-2C5E-40EC-A2BB-C1CBDB5831A0@delong.com> <5161DB25.6000608@matthew.at> <5161F412.6060405@matthew.at> Message-ID: On Apr 7, 2013, at 15:32 , Matthew Kaufman wrote: > On 4/7/2013 2:14 PM, Owen DeLong wrote: >>>> One possible way to distinguish ISP size for IPv6 would be to use >>>> annual gross revenue instead of total address holdings. I don't know >>>> if that would be an improvement or not. I realize it would be more >>>> complex to calculate and enforce. I think it would likely be more fair. >>> More fair would be everyone pays the same. Or everyone pays based on the amount of service they actually require from ARIN. >> I disagree completely here. An end-user with a single /48 is not in any way reasonably expected to pay the same as an ISP with multiple ASNs, a /20 of IPv6 and an aggregate /6 of IPv4 space. >> >> I can't imagine in what possible universe anyone could imagine that to be fair. > > Why not? As long as the price is reasonable I don't see who could possibly be opposed to a model where the only added costs are for those who actually cost ARIN more to service, not some arbitrary scaled scheme where well-run large orgs pay more than the tiny ones that need lots of handholding. Or, even better, a flat price for all. But of course there *would* be some opposed, because for every choice it isn't "fair" to someone. > I noted the reasons below. It puts strong incentives in bad directions. > This is just like the US tax system... nobody thinks that any of the models are "fair". Flat tax? Unfair to the poor. Higher taxes for the rich? Disincentive to working harder and unfair to the rich. You can't win. > Actually, I think that a flat consumption tax that excludes food and clothing items and written word matter (regardless of media) under $100 would be quite fair. It isn't unfair to the rich because it's based on consumption, not earning. However, this is far afield from PPML's purpose. > And that's why we shouldn't be discussing the fee structure here at all. We should be discussing what numbering policy results in the best addressing plan for the Internet. And I believe that handing out /36 and /40 to ISPs doesn't do that. > I agree with you, but the fee structure, like it or not, is going to drive consideration of those policies, or, we're going to need a discussion somewhere that drives a better fee structure. >>> Basing it on amount of space *or* gross revenue isn't "fair"... it is just a way to extract extra revenue from those who (in theory) have more to send to ARIN, which gives ARIN the opportunity to lower prices at the other end to keep the masses happy, or to just increase its overhead to ensure the money gets spent. >> We can agree to disagree on what constitutes "fair" here. I believe it is "fair" for those that are extracting a greater amount of revenue from the community resources they hold to contribute a greater share to the costs of maintaining said community resources. > > So we should be charging mobile operators more than we charge dialup providers because the ARPU is higher? > I'm not necessarily opposed, but I'm also not convinced that's true, either. >> >> I don't see it so much as extracting extra revenue so much as differentiating the allocation of the total costs. > > Those are exactly the same thing. One just sounds better than the other. > > The idea is that you find the people who are willing to pay more, you figure out how to charge them more. In this case, you take some of that "extra" revenue and use it to drop the prices for the people who aren't willing to pay as much. Classic pricing theory covers this, and I would expect no less from any organization. But it doesn't make it "fair" either. Another way of considering it, however, is you try to find ways to serve those that couldn't pay as much as it would take for everyone to pay the same amount. Over the time I've been involved in ARIN, combinations of better policy and fee reductions over time have created a better ability to serve a wider range of organizations. I think this is a good thing. Many organizations would simply be excluded from obtaining direct allocations/assignments if ARIN were to go to a flat-rate structure. I do not see that as being overall beneficial to the community. > >> I don't believe for a second that ARIN is increasing its overhead just to ensure the money gets spent. I have reviewed the ARIN public financials several years in a row and I believe that ARIN does a great deal for the community at a very reasonable cost to said community. > > We've had offers to do it for less. > No, we've had offers to do part of what ARIN does for less. I am not convinced that those offers represented a sustainable way to do it, either. >>> But we see this all over the world these days, so it isn't like I'm surprised that they would behave this way. At least they're not creating additional address registries and then telling people they need to register their addresses there too in order to protect their trademarks, like some other winners of the how-can-we-charge-for-things-that-were-free game that the Internet played some years ago. >> This really isn't a fair characterization of either structure. First, I agree that what has happened in the DNS realm has been badly mismanaged and that most of the mismanagement has come about as a result of various profit motives. > > Ok, then we agree on that front. > >> However, to claim this was strictly a matter of "how can we charge for what was free?" is not at all accurate. The original switch to "charging for what was free" was an effort to sustain the existing infrastructure from a new funding source since the previous government contracts were about to become unfunded. > > I was there. It was a little of each. Lots of people volunteered to do things for free, but instead we had to play by the rules that were set up to make sure that a small number of people were able to sit at this newly-created trough. And here we are. Yes, numbering has worked out a lot better for the public interest than names did, but it still isn't great. > Doing it for free sounds great, but in reality, anyone doing it for free isn't obliged to keep doing it. If you're not taking money, there's no "exchange of value" and legally that means there's no contract. Volunteers can quit any time they want. I would argue that these functions are too important and must be sustained as continual operations. Therefore, placing it in the hands of an organization offering to do it for free isn't exactly ideal. I actually think that the numbering situation is pretty good. >> I think that the number registries have done a vastly better job of the transition and keeping things cost-recovery based while providing the services the community has said it is valuable for them to provide at a very reasonable cost to the community. > > Agreed. > Then what, exactly, are you criticizing about ARIN spending? What money do you think is being wasted or spent improperly? Where do you think this alleged reduction in revenue is feasible? >> >> As much as I think that the new fee structure contains some really poor decisions that will drive poor number resource policy as a consequence, I do think that the board is trying to balance a number of tradeoffs and has made a reasonable attempt at doing so in a fair and consistent manner. > > Yes. But one of those tradeoffs is that they apparently can't figure out how to run ARIN in a world where everyone with a /32 pays the kind of fees that these "extra small" ISPs claim they can afford. That's not a numbering policy problem. True, but it is a fee structure problem. Unfortunately, if we can't solve the fee structure problem, we're probably faced with the reality of contorting number policy in order to address the reality of the situation. It's not ideal, but it's also not unusual. For example, it's hard to prove someone was impaired while they were driving. Instead, we substitute characteristic amounts of alcohol in their blood stream as evidence that they must have been impaired. >>>> I would like to hear about other creative ideas on ways to measure >>>> size and/or appropriate metrics to be used for fee determination. >>> Each email or call requires a fee payment above and beyond a tiny fee which everyone pays and which is equal for all. Or, worst case, a tiny fee per database row. >> The problem with this is that it would again create negative incentives. It will financially incentivize the following negative behaviors: >> >> 1. Avoid updating records to reflect changes. >> 2. Downsize customer assignments to avoid having to request additional space. >> 3. Avoid interacting with ARIN until it's absolutely necessary and cannot be avoided >> through other contortions of ones own address space. >> >> I don't thin that's a desirable outcome any more than what is proposed in the adopted fee structure combined with what is proposed in 2013-3. > > Of course not. But "charge the new extra small fee for everyone with a /32, and don't allocate anything smaller than /32" (which would provide enough of a fix for enough of the people right away) we are told isn't compatible with "don't drastically reduce ARIN's expenses", which is also not something we can impact with the numbering policy process. Right, so we agree that neither of those solutions is viable, now let's look elsewhere for one that is. Owen From paul at redbarn.org Mon Apr 8 01:13:32 2013 From: paul at redbarn.org (Paul Vixie) Date: Sun, 07 Apr 2013 22:13:32 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <51624EEF.9080208@matthew.at> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5161F0C2.9010800@matthew.at> <51622052.6020401@redbarn.org> <51624EEF.9080208@matthew.at> Message-ID: <516251FC.5000109@redbarn.org> ... Matthew Kaufman wrote: > On 4/7/2013 6:41 PM, Paul Vixie wrote: > > ... >> ... the ARIN fee schedule is based in no way on willingness to pay more. > Willingness, ability, same thing. Since I started writing this reply, > John has chimed in to note that if everyone paid the same it would > need to be $2800/year. So ARIN has happily found a few ISPs that are > willing to pay so much more than some others can pay as little as $500. willingness and ability aren't the same thing, but that doesn't matter, because the fee schedule isn't based on either one. paul From owen at delong.com Mon Apr 8 01:11:10 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Apr 2013 22:11:10 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <51621904.5020005@redbarn.org> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5162181A.6000907@burnttofu.net> <51621904.5020005@redbarn.org> Message-ID: <4270CDB1-98D9-4E0A-A256-FA59D289324E@delong.com> On Apr 7, 2013, at 18:10 , Paul Vixie wrote: > ... > > Michael Sinatra wrote: >> ... >> >> I don't like discussing the fee schedule on PPML any more than anyone >> else, but as an operator, I am being asked to support an >> operationally-suboptimal policy as a band-aid for this one issue in the >> fee schedule, and that's what's giving me heartburn right now. > > are you aware of the other arin mailing list, limited to members unlike > this public policy mailing list (PPML), where discussions of fees paid > would be somewhat more targeted since it would be a discussion of > fee-payers? this mailing list is documented here: > > http://lists.arin.net/mailman/listinfo/arin-discuss Unfortunately, that's not an entirely accurate characterization. arin-discuss is only open to members to the best of my knowledge. Many (if not most) of the entities paying fees to ARIN are not members. In fact, I could not be on that list by virtue of my own resources. I happen to be on there because I am a consultant to several members and an employee of one. Owen From cb.list6 at gmail.com Mon Apr 8 01:13:07 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 22:13:07 -0700 Subject: [arin-ppml] The case against need based justification Message-ID: Need-based justification is being reviewed in RIPE [1] That spurred me to review need based justification in ARIN for both IPv4 and IPv6. I would like to present some facts for review so that the ARIN community can judge the success of need-based justification and consider the role it will have in future policy. First, as of this writing, ARIN still has 2.47 /8s free [2]. Excluding the last /8 which is locked in a way by policy, that leaves approximately 24 Million addresses in the free pool. Assuming a free market cost of $10 per IPv4 address, that is $240 million worth of IPv4 cost off-set from which one would have to pay the free ipv4 market for those addresses. This is a relevant sum on nearly any balance sheet. So, it is not acceptable to say folks are turning away from it because ARIN is offering that space in a fair way. The free pool is relevant. There is a case that the need-based policy has done well, and it has done well for some. Comcast, for example, has 18 million subscribers and 70 Million IPv4 addresses [3]. For simple math, we can call that 3.8 addresses for every 1 customer. Then, you have a network like Metro PCS who has 9 million subscribers (2.2 million of which are LTE) [4] on what i can tell is 1,024 IPv4 addresses. Which is a 0.000113778 IPv4 addresses per subscriber from ARIN. I do not speak for Metro PCS, i just found their case interesting. So, there are winners and losers in need-based. Winners puts more time and money into the process, losers are busy optimizing other parts of their business instead of working the ARIN system. Looking back at [3], winners are also big companies with a lot of resource and ... they probably send people to ARIN meetings and ... maybe they even send lawyers to ARIN meetings. I don't know, i have never been to an ARIN meeting myself. So far, i hope we have seen that the free pool as of today is relevant and that need-based is not strictly "fair" in how the distribution happens, and that there are winners and losers. Winners invest more time and effort, and sometimes time and effort is from lawyers not engineers. Now, there is more. Many organizations have found ARIN unsuitable for their address needs. We know that in 2011 when the free pool was much larger than it is now (4+ /8s?), Microsoft bought IPv4 space from a bankruptcy court [6]. Amazon among others has also made substantial market buys. These companies are obviously not getting what they want from a need-based policy, and i assume they made cogent business case to close these deals. The difference is they have the money to work the policy like Comcast, but instead they worked a different angle also applying money. But, need-based is not a about money. Is it? It is about justified need, or the appearance of such. It would appear that Amazon and Microsoft could justify need, but the need-based policy does not appear to work for them. I am aware of the transfer policy and how need is, for some reason, a different standard there. So, that is open market end of things, organizations pay millions of dollars instead of thousands of dollars to not use a need-based policy of the ARIN free pool. Seems like the symptom of something broken. Here is another symptom of something broken. The largest internet growth engine is mobile. Mobile contributes a huge amount of traffic, growth, and "stuff" on the Internet. If Zuck does not mention mobile 20 times in an earnings call, FB stock dives. AT&T wireless and Verizon Wireless both have close to a 100 million subscribers each. And, just about every one of those subscribers uses RFC 1918 space. What about those 2 smaller players, Sprint and T-Mobile. Both of them use squat space. Despite spending time and money on outreach, this HUGE part of the internet is not part of the ARIN numbering system (unless you count the ARIN addresses on the CGN). At least, not part of ARIN's need-based policy. Mobile uses CGN because ARIN's policies have not and will not fit with the growth of these networks and their architectures. Not today, but also not in 2003. I would like that that to change [7]. Speaking for myself, what i saw was a network was designed to best fit the business needs. That network design did not fit ARIN policies for efficiency, and so ARIN would not provide addresses and CGNs were rolled in to close the gap between the best network design and the ARIN policies. Speaking more for myself, in 2000 i worked for an ISP, and one of my job roles was assigning addresses to T1 and T3 customers of the ISP. It was a painful process for me and my customers. We lived in world where people just wanted a /24 to turn up their LAN, but i could not just give it to them. It was a world of scarcity of addresses, emails full of made up justifications, and that persist today. In fact, last year i tried to get a /48 of address space for a lab network attached to a T3 from TWT. They would not give me more than a /56. I heard from another guy that Internap would only give him a /64. Need-based is a trickled down disease on network design. It is not just mobile doing CGN. AT&T has deployed CGN to landline DSL [8], and now Verizon DSL too [9] As previously noted, the ARIN free pool is a non-trivial sum of 24 million IPv4 addresses. Yet, companies continue to buy addresses and / or deploy CGN. And they do it at massive scale. We are talking about the biggest cloud and access network providers can't seem to get what they need from ARIN whether it be IPv4 addresses or effective IPv6 deployment advocacy. My conclusion from all this is that need-based policy did not help IPv4 and is actively hurting IPv6. NRPM and ARIN should get out of the business of telling people how to number their networks, it has not helped the businesses or the internet. I say this because "we" did not transition to IPv6 and the market for IPv4 and the technology known as CGN is seen as more effective solution than ARIN or IPv6 That brings me to policy changes that i would like feedback on. 1. Should ARIN continue to administer need-based policy now and after run-out? Please note the discussion of winners and loser with data points [3] and [5]. Who is ARIN serving with the need-based policy? 2. I have made the claim that ARIN's need-based policy has negatively impacted system design, the specific system being the internet. The squat / CGN internet that is on your phone [7] and coming to your DSL [8],[9]. 3. By moving away from need based policy from ipv4, we accept reality that the market rules [6]. IPv4 addresses are part of the means of production in a capitalist society. IPv4 addresses should not be acquired by playing some logic game with people via ARIN tickets or intellectual thumb-wrestling and posturing on PPML. 4. IPv6 is designed without need in mind, there is no reason for ARIN to import the notion that need is factor when each LAN is given 2^64 addresses. Organizations that want PI should get an ASN (existing policy) and a minimum /32 and be done. End of story. There is no logic for conservation of a limitless resource (in this case, it is bounded by ASN). Growth beyond a /32 should just be a simple written justification, not gear and subscriber logs showing 80% use. 5. These simplifications can be reflected in a rate structure that results from such simplification. [1] https://www.ripe.net/ripe/policies/proposals/2013-03/ [2] https://www.arin.net/resources/request/ipv4_countdown.html [3] http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf [4] http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight= [5] http://whois.arin.net/rest/net/NET-65-91-116-0-1.html [6] http://www.bbc.co.uk/news/technology-12859585 [7] https://www.arin.net/policy/proposals/2013_2.html [8] http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address- [9] https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm From matthew at matthew.at Mon Apr 8 01:23:16 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 07 Apr 2013 22:23:16 -0700 Subject: [arin-ppml] Fee Philosophy In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FAFD2ED@CHAXCH01.corp.arin.net> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAE8D10@CHAXCH01.corp.arin.net> <51613621.9040702@burnttofu.net> <8DA1853CE466B041B104C1CAEE00B3748FAF4563@CHAXCH01.corp.arin.net> <5161D787.1050307@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAFD2ED@CHAXCH01.corp.arin.net> Message-ID: <51625444.7030807@matthew.at> On 4/7/2013 9:34 PM, John Curran wrote: > On Apr 7, 2013, at 1:31 PM, Matthew Kaufman wrote: > >> On 4/7/2013 4:46 AM, John Curran wrote: >>> No NRPM change is needed because of the Revised Fee schedule; fees under the new schedule will be lower for smallest ISPs in any case. The question is whether the community also provide support for a xx-small category which is even lower ($500/year) but distinguished by only a /40 IPv6 allocation. This is being discussed in Draft Policy ARIN-2013-3, and while it is enabled by the Revised Fee schedule, it is an independent item for the community to consider and can be adopted or not based on its merits. >> And what happens when next week ARIN's board comes up with the xxxx-small category at $200/year, distinguished by a /60 IPv6 allocation. Are we supposed to create more bad numbering policy then too? > Matthew - > > You shouldn't support the Draft Policy ARIN-2013-3 if don't believe > it to be fair and technically sound. I don't. > If the draft policy is not > adopted, the fee schedule entry does not matter. True. > If it is supported > by the community, then the policy change will happen because that > meant that overall people felt it was fair and technically sound. Or it will happen because enough people wanted themselves or others to only need to pay $500 and were able to hold their nose long enough to ignore the technical soundness while raising their hands. If we could somehow figure out how to confine people to voting for or against policy changes based soley on their technical merit we should patent the process, because it would be useful in so many other venues. > > IF the Board were to add a /60 xxx-small category, nothing would > change unless someone also introduced a policy proposal to lower > the minimum to that size. Which they would, because someone would want numbering policy to change so they could pay less. > There's no obligation to make a policy > change, but if some ISPs thought it made sense, you'd likely see > it get submitted and also discussed here. No doubt. > If it were found to be > supported by the community, it would be adopted and would not be > "bad numbering policy" but just "policy Matthew doesn't agree with" If adopted it would be "policy Matthew doesn't agree with" *and* "bad numbering policy" (at least in the technical-soundness sense). This isn't the first time that similar reasons have resulted in similarly bad policy being adopted, you know. Matthew Kaufman From owen at delong.com Mon Apr 8 01:27:54 2013 From: owen at delong.com (Owen DeLong) Date: Sun, 7 Apr 2013 22:27:54 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> <51622918.7060104@redbarn.org> Message-ID: <037BE157-3179-42B7-9952-94353DA05A47@delong.com> Number resource policy is not the reason mobile phone users are behind CGN today. That's an excuse, not a legitimate reason. Until fairly recently, there were actually several mobile phone operators that did not place their subscribers behind CGN. Owen On Apr 7, 2013, at 19:34 , cb.list6 wrote: > > On Apr 7, 2013 7:19 PM, "Paul Vixie" wrote: > > > > ... > > > > cb.list6 wrote: > >> > >> > >> On Apr 7, 2013 12:49 PM, "Paul Vixie" wrote: > >> > > >> > i know that it's a popular viewpoint -- many folks feel that the time for needs based allocation is over and that the invisible hand of the market is now capable of optimizing the holding of address space and the aggregation level of that space into routing table entries. > >> > > >> > >> Popular viewpoint go far in a bottom up process such as arin. In fact, the whole thing is a popularity contest. > > > > > > i said it was popular, not that it could win a popularity contest. > > > > > >> > so i thought i'd chime in: i consider that case to be extremely unmade as yet. even though i am in most other ways a free-marketeer. as stewards of a public resource ARIN has always been guided by RFC 2050 which requires recipients of these public resources to justify their need, no matter whether these resources are coming from a central pool or a private transfer. > >> > > >> > paul > >> > >> Does that mean you require an update to rfc 2050 to move ? > > > > > > not at all. i think RFC 2050 was and remains correct in this regard. i'll "move" when and if my mind changes on the matter. > > > >> I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01 > >> > >> ... > >> > >> Should 2050bis ask rir not do this fair policy? From what I read in 2050bis is that is says the rir can make their own policy and 2050 is dead. > >> > >> Do you read it differently? > > > > > > i read it to accurately explain that not every RIR still follows the needs based justification described in RFC 2050. it's a description of the current RIR system. 2050bis does not "ask" RIRs to do anything, it's a description of what they actually do. > > > > > >> As it stands, speaking from experience, the justification story in v4 and v6 drives design choices. That is an unfortunate fact and negatively impacts system design. > > > > > > i'm intrigued by this statement. i hope you are willing to share some of your experiences as to how needs based justification has negatively driven some design choices. > > > > paul > > I just wrote a page of explanation and deleted it. > > If I have to explain it, you would not understand. And you do not understand today's data networks at all. I feel bad and outrageous saying that. But, given hundreds of millions of mobile phone users behind cgn today, perhaps your question is outrageous > > Note that att and vz have both rolled cgn to their dsl subs. > > Yet arin is not exhausted. > > Interesting? > > CB. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cb.list6 at gmail.com Mon Apr 8 01:37:18 2013 From: cb.list6 at gmail.com (cb.list6) Date: Sun, 7 Apr 2013 22:37:18 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <037BE157-3179-42B7-9952-94353DA05A47@delong.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> <51622918.7060104@redbarn.org> <037BE157-3179-42B7-9952-94353DA05A47@delong.com> Message-ID: On Apr 7, 2013 10:31 PM, "Owen DeLong" wrote: > > Number resource policy is not the reason mobile phone users are behind CGN today. > Applications were made prior to the g1 launch. They were denied. Cgn grew. Squat was deployed. First hand account, end of story. I did not handle the application, that was not my job. My job was to pick the squat and handle the cgn. CB. > That's an excuse, not a legitimate reason. > > Until fairly recently, there were actually several mobile phone operators that did not place their subscribers behind CGN. > > Owen > > On Apr 7, 2013, at 19:34 , cb.list6 wrote: > >> >> On Apr 7, 2013 7:19 PM, "Paul Vixie" wrote: >> > >> > ... >> > >> > cb.list6 wrote: >> >> >> >> >> >> On Apr 7, 2013 12:49 PM, "Paul Vixie" wrote: >> >> > >> >> > i know that it's a popular viewpoint -- many folks feel that the time for needs based allocation is over and that the invisible hand of the market is now capable of optimizing the holding of address space and the aggregation level of that space into routing table entries. >> >> > >> >> >> >> Popular viewpoint go far in a bottom up process such as arin. In fact, the whole thing is a popularity contest. >> > >> > >> > i said it was popular, not that it could win a popularity contest. >> > >> > >> >> > so i thought i'd chime in: i consider that case to be extremely unmade as yet. even though i am in most other ways a free-marketeer. as stewards of a public resource ARIN has always been guided by RFC 2050 which requires recipients of these public resources to justify their need, no matter whether these resources are coming from a central pool or a private transfer. >> >> > >> >> > paul >> >> >> >> Does that mean you require an update to rfc 2050 to move ? >> > >> > >> > not at all. i think RFC 2050 was and remains correct in this regard. i'll "move" when and if my mind changes on the matter. >> > >> >> I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01 >> >> >> >> ... >> >> >> >> Should 2050bis ask rir not do this fair policy? From what I read in 2050bis is that is says the rir can make their own policy and 2050 is dead. >> >> >> >> Do you read it differently? >> > >> > >> > i read it to accurately explain that not every RIR still follows the needs based justification described in RFC 2050. it's a description of the current RIR system. 2050bis does not "ask" RIRs to do anything, it's a description of what they actually do. >> > >> > >> >> As it stands, speaking from experience, the justification story in v4 and v6 drives design choices. That is an unfortunate fact and negatively impacts system design. >> > >> > >> > i'm intrigued by this statement. i hope you are willing to share some of your experiences as to how needs based justification has negatively driven some design choices. >> > >> > paul >> >> I just wrote a page of explanation and deleted it. >> >> If I have to explain it, you would not understand. And you do not understand today's data networks at all. I feel bad and outrageous saying that. But, given hundreds of millions of mobile phone users behind cgn today, perhaps your question is outrageous >> >> Note that att and vz have both rolled cgn to their dsl subs. >> >> Yet arin is not exhausted. >> >> Interesting? >> >> CB. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Mon Apr 8 02:02:47 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 8 Apr 2013 06:02:47 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <516251FC.5000109@redbarn.org> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5161F0C2.9010800@matthew.at> <51622052.6020401@redbarn.org> <51624EEF.9080208@matthew.at> <516251FC.5000109@redbarn.org> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CE658@ENI-MAIL.eclipse-networks.com> Arin and this community could of course - rewrite the allocation polices like the RIPE proposal http://www.ripe.net/ripe/policies/proposals/2013-03 and make it easier and more straightforward to "qualify" for IP resources. Then organizations that have been denied allocations (like ours) or organizations that haven't even bothered to apply to Arin for an allocation for fear of being denied - could then get resources and be added to the community that pays Arin fees. Then maybe Arin's board of directors wouldn't/won't have to approve fee increases because there would be many more organizations paying fees and Arin's total revenue would increase. Arin gets more revenue, Organizations get needed resources, Arin is fulfilling its Mission, Organizations get lower costs. Sounds like a win-win-win-win to me. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Paul Vixie Sent: Monday, April 08, 2013 1:14 AM To: Matthew Kaufman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs ... Matthew Kaufman wrote: > On 4/7/2013 6:41 PM, Paul Vixie wrote: > > ... >> ... the ARIN fee schedule is based in no way on willingness to pay more. > Willingness, ability, same thing. Since I started writing this reply, > John has chimed in to note that if everyone paid the same it would > need to be $2800/year. So ARIN has happily found a few ISPs that are > willing to pay so much more than some others can pay as little as $500. willingness and ability aren't the same thing, but that doesn't matter, because the fee schedule isn't based on either one. paul _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jcurran at arin.net Mon Apr 8 02:22:35 2013 From: jcurran at arin.net (John Curran) Date: Mon, 8 Apr 2013 06:22:35 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CE658@ENI-MAIL.eclipse-networks.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161D88E.8090102@matthew.at> <5161DF98.4010702@redbarn.org> <5161F0C2.9010800@matthew.at> <51622052.6020401@redbarn.org> <51624EEF.9080208@matthew.at> <516251FC.5000109@redbarn.org> <5B9E90747FA2974D91A54FCFA1B8AD12012F5CE658@ENI-MAIL.eclipse-networks.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FAFF5F9@CHAXCH01.corp.arin.net> On Apr 7, 2013, at 11:02 PM, Steven Ryerse wrote: > Arin and this community could of course - rewrite the allocation polices like the RIPE proposal http://www.ripe.net/ripe/policies/proposals/2013-03 and make it easier and more straightforward to "qualify" for IP resources. Then organizations that have been denied allocations (like ours) or organizations that haven't even bothered to apply to Arin for an allocation for fear of being denied - could then get resources and be added to the community that pays Arin fees. > > Then maybe Arin's board of directors wouldn't/won't have to approve fee increases because there would be many more organizations paying fees and Arin's total revenue would increase. > > Arin gets more revenue, Organizations get needed resources, Arin is fulfilling its Mission, Organizations get lower costs. Sounds like a win-win-win-win to me. Indeed. ARIN has actually seen a significant increase in members over time due to those receiving resources, but you are welcome to suggest any specific changes to policy that would improve access to number resources. You can find more information on the Policy Development Process here: Thanks! /John John Curran President and CEO ARIN From mcr at sandelman.ca Mon Apr 8 08:45:07 2013 From: mcr at sandelman.ca (Michael Richardson) Date: Mon, 08 Apr 2013 08:45:07 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <2A7D98DF-4B38-46CA-A2FD-13A742C722BF@sonn.com> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161A9EE.3060304@bogus.com> <2A7D98DF-4B38-46CA-A2FD-13A742C722BF@sonn.com> Message-ID: <15999.1365425107@sandelman.ca> >>>>> "Steven" == Steven Noble writes: Steven> That is exactly my point, if ARIN says that someone Steven> requesting IPv6 will not have higher fees, then how does Steven> that work with a legacy holder? Do we want people to adopt Steven> IPv6 or not? A policy that makes it the same cost to Steven> request and hold IPv4 and IPv6 works both ways. If I am Steven> charged the same as someone who has both IPv4 and IPv6 Steven> resources, why would I not request IPv4 resources too? +1 And, given that I can get IPv4 for the same price, why go to the hassle of doing anything with IPv6? The business case for doing new things with IPv6 should include "and the address space is essentially free,so we wilkl do the network architecture correctly, rather than creating a hack that supported IPv4 NAT/bridging" Do you know how many layer-2 **hack** have been created because IPv4 subnets are a fixed quantity? (particularly in the pre-CIDR days) IPv6 allocations and especially end-user assignments, need to be essentially free. In the IPv4 time scale, this is 1989, when enterprises just came to the table for address space, with *no intention* of advertising that space. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From info at arin.net Mon Apr 8 11:12:23 2013 From: info at arin.net (ARIN) Date: Mon, 08 Apr 2013 11:12:23 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs Message-ID: <5162DE57.9060102@arin.net> Draft Policy ARIN-2013-3 Tiny IPv6 Allocations for ISPs The text has been revised. Draft Policy ARIN-2013-3 is below and can be found at: https://www.arin.net/policy/proposals/2013_3.html This draft will be presented at ARIN 31. The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2013-3 Tiny IPv6 Allocations for ISPs Date: 8 April 2013 Problem Statement: ARIN's fee structure provides a graduated system wherein organizations pay based on the amount of number resources they consume. At the very bottom end of the scale, it is presently not possible to be an XX-Small ISP with an IPv6 allocation because the minimum allocation size of /36 automatically promotes one into X-Small ISP status, resulting in a doubling of annual fees. While tiny in absolute terms, the extra costs incurred represent a disincentive to IPv6 deployment. To the author's knowledge, it has never been possible for an LIR/ISP to get a /40 allocation direct from ARIN; such assignments have been limited to organizations that qualify as end sites or /48s for critical infrastructure. It is understood there is an expected correction of the XX-Small fee category to "/40 or smaller". Policy statement: Part 1: In subsection 6.5.2. Initial Allocation Size, insert "or /40" at the end of the first sentence of subsection 6.5.2.1 clause (b), and add a new clause (g), resulting in; b. In no case shall an LIR receive smaller than a /32 unless they specifically request a /36 or /40. In no case shall an ISP receive more than a /16 initial allocation. ... g. An LIR that requests a smaller /36 or /40 allocation is entitled to expand the allocation to any nibble aligned size up to /32 at any time without renumbering or additional justification. Such expansions are not considered subsequent allocations. However, any expansions beyond /32 are considered subsequent allocations, and must conform to section 6.5.3. Part 2: Add a new subsection to section 6 "IPv6"; 6.12 Reduction or Return ARIN will accept the return of whole or partial block(s) allowing an organization to reduce their holdings as long as: a. The resulting number of retained aggregate blocks does not increase. b. Whole blocks are returned to the extent practicable. c. Partial block(s) retained must conform to current applicable allocation or assignment policies, as to size, alignment, etc? d. Block(s) retained are within a single reserved space or aggregate set aside for the organization in the ARIN database to the extent practicable. e. All block(s) returned are not in use by the organization or its customers. Comments: The author acknowledges the shortcomings of providing an ISP with an allocation of a size that is more traditionally associated with end sites. In order to avoid possible bad effects on the routing table, the author encourages ARIN staff to adopt the same sparse allocation practice as currently exists for larger allocations, ideally even reserving a block as large as the /28 that is reserved for /32s currently. Note the policy intent of part 1 requires a minimum of a /32 be reserved. Part 1 brings ARIN's allocation policies in line with the upcoming fee schedule, with the addition of an expected correction of the XX-Small fee category to "/40 or smaller". This makes it possible to qualify for each ISP fee category while holding IPv6 number resources and allows expansion up to /32 without renumbering or additional justification as a subsequent allocation. The selection of a /32, /36 or /40 allocation is only driven by an ISP's own internal business justifications. Part 2 codifies and expands upon current practice for selective return in the manner described by John Curran on the arin-discuss mailing list (7-Mar-2013 in 8DA1853CE466B041B104C1CAEE00B3748F9239EA at CHAXCH01.corp.arin.net ). It specifies the generic requirements that should be met for such returns. A more practical approach might to figure out a way to apply graduated fees to ISPs at the very small end of the scale using some metric other than prefix size. Fee schedules are outside of the purview of the Policy Development Process; such responsibility lies with the Board should they choose to take it up. Summary of community discussion: The fundamental argument against this draft policy is that the primary problem being solved is a billing or fee structure issue and not a number resource policy issue in itself. A significant minority are adamant on this issue to the extent they oppose this policy. The majority of the community recognizes this issue, and would prefer /32 be the sole minimum allocation size for ISPs and other LIRs. However, the majority are willing to accept the tradeoffs incorporated into this policy. As there are too many ISPs that fit into the /32 allocation category for the fee level associated with the XX-Small category to be fiscally responsible and sustainable for ARIN. Furthermore, there are no obvious solutions to this problem within the fee structure domain that are fiscally responsible and sustainable for ARIN, especially in the long-term. Everyone agrees making /36 or /40 allocations to ISPs seems less than ideal from a number resource policy perspective. However, this is mitigated by ensuring that all ISPs have a /32 available to them without renumbering or additional justification and from a number resource policy perspective the selection of /36 or /40 allocations is completely voluntary. This allows each ISP to make the decision to select from a /32, /36 or /40 initial allocation based solely on their own internal business justifications, and eliminates structural disincentives in the fee schedule for IPv6 adoption. This seems like the best balance available at this time of number resource policy, fiscal responsibility and sustainability for both ARIN and the ISPs that it serves. Timetable for implementation: Immediate From adudek16 at gmail.com Mon Apr 8 11:15:06 2013 From: adudek16 at gmail.com (Aaron Dudek) Date: Mon, 8 Apr 2013 11:15:06 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <15999.1365425107@sandelman.ca> References: <5153387E.6060700@arin.net> <51536C77.8070405@rollernet.us> <51537A20.7020100@burnttofu.net> <515392B9.807@umn.edu> <516070E5.2060603@burnttofu.net> <516100A6.6030304@matthew.at> <8DA1853CE466B041B104C1CAEE00B3748FAF3FB3@CHAXCH01.corp.arin.net> <67E27463-1152-4A57-9EE4-DFEA0F8505F2@sonn.com> <5161A9EE.3060304@bogus.com> <2A7D98DF-4B38-46CA-A2FD-13A742C722BF@sonn.com> <15999.1365425107@sandelman.ca> Message-ID: Because IPv4 is disappearing. At some point in the near future it will cost more to do IPv4, specifically to acquire addresses, then IPv6. Nice reference to 1989. Where did that get us now? On Mon, Apr 8, 2013 at 8:45 AM, Michael Richardson wrote: > > >>>>> "Steven" == Steven Noble writes: > Steven> That is exactly my point, if ARIN says that someone > Steven> requesting IPv6 will not have higher fees, then how does > Steven> that work with a legacy holder? Do we want people to adopt > Steven> IPv6 or not? A policy that makes it the same cost to > Steven> request and hold IPv4 and IPv6 works both ways. If I am > Steven> charged the same as someone who has both IPv4 and IPv6 > Steven> resources, why would I not request IPv4 resources too? > > +1 > > And, given that I can get IPv4 for the same price, why go to the hassle > of doing anything with IPv6? The business case for doing new things > with IPv6 should include "and the address space is essentially free,so > we wilkl do the network architecture correctly, rather than creating a > hack that supported IPv4 NAT/bridging" > > Do you know how many layer-2 **hack** have been created because IPv4 > subnets are a fixed quantity? (particularly in the pre-CIDR days) > > IPv6 allocations and especially end-user assignments, need to be > essentially free. In the IPv4 time scale, this is 1989, when > enterprises just came to the table for address space, with *no > intention* of advertising that space. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Mon Apr 8 11:34:11 2013 From: heather.skanks at gmail.com (Heather Schiller) Date: Mon, 8 Apr 2013 11:34:11 -0400 Subject: [arin-ppml] The case against need based justification In-Reply-To: References: Message-ID: I find much of your argument flawed -- you seem to have chosen a conclusion and then tried to wrap theories around it. Re-read the nrpm... for a transfer to be recognized by ARIN, the criteria of justified need still applies. The "substantial market buys" you referenced still had justified need applied to them ---- the only difference between getting space directly from ARIN and getting it on the secondary market [aside from cost] is the window of time you can justify need for. Directly from ARIN you can get 3 months justified need and on the secondary market you can request up to 24 months need. Unless you participated in the engineering and design of each of the networks you reference, you can not have first hand knowledge of how addressing policy affected their decisions. You are making guesses from the outside, based on the size of their customer base and what you see today. In atleast one mobile provider you reference, I can say -with direct knowledge- that your conclusion is wrong. The move to CGN has nothing to do with justified need and everything to do with whether it is financially responsible to continue investing in a finite resource. Sure providers could buy up space on the secondary market for another year or 2 - and then what? The price for v4 could rise exorbitantly, to the point where the cost of an address becomes a significant cost toward offering the service. You will be stuck in the same place and out a bunch of cash. Or you can have multiple customers share an address, recover a bunch of space and continue to grow your business without investing in the secondary market. Its the expense of the secondary market itself, that makes CGN more appealing. With regard to use of RFC1918 space - again - unless you were involved in making the decision at those companies - you can not authoritatively say why they made the decision they did. You are speculating that they chose to use 1918 space because they were unable or unwilling to justify need - and that is very unlikely to be the case. Network Engineers tend to be reasonable, logical folks who give great thought to where public address space is necessary and where it isn't, as well as the pros and cons of using both. They may have chosen to respect a shared resource and conserve space, or been unsure how large the network would grow, or been unable to justify [to their mgr, themselves or whoever] the additional ARIN fees for being in a larger allocation category. Fair does not mean that every organization gets the same thing. The NEEDS of every organization are different. This is why ARIN takes the time to read through the request and help ensure that what the organization gets, meets their needs... not their competitor or neighbor's needs. http://imbloghoppin.blogspot.com/2011/08/power-of-bandaid.html Where I do empathize with you, is the problem you described about getting v6 address space from your provider for a lab and they wouldn't give you more than a /56. However, that is a business decision by your ISP. As of today, there is no mandatory minimum IPv6 assignment size for ISP's to their customers, only a small reference to a recommendation. In fact, justified need is not a requirement in making reallocations to customers in IPv6, so abolishing justified need would not affect the v6 assignment size your ISP offers. If you would like to see that changed - then read up on how we got there and submit a proposal to change it ( https://www.arin.net/policy/pdp_appendix_b.html) Otherwise, it is an issue between you and your provider and should be taken up with them directly. --Heather On Mon, Apr 8, 2013 at 1:13 AM, cb.list6 wrote: > Need-based justification is being reviewed in RIPE [1] > > That spurred me to review need based justification in ARIN for both > IPv4 and IPv6. > > I would like to present some facts for review so that the ARIN > community can judge the success of need-based justification and > consider the role it will have in future policy. > > First, as of this writing, ARIN still has 2.47 /8s free [2]. > Excluding the last /8 which is locked in a way by policy, that leaves > approximately 24 Million addresses in the free pool. Assuming a free > market cost of $10 per IPv4 address, that is $240 million worth of > IPv4 cost off-set from which one would have to pay the free ipv4 > market for those addresses. This is a relevant sum on nearly any > balance sheet. So, it is not acceptable to say folks are turning away > from it because ARIN is offering that space in a fair way. The free > pool is relevant. > > There is a case that the need-based policy has done well, and it has > done well for some. Comcast, for example, has 18 million subscribers > and 70 Million IPv4 addresses [3]. For simple math, we can call that > 3.8 addresses for every 1 customer. Then, you have a network like > Metro PCS who has 9 million subscribers (2.2 million of which are LTE) > [4] on what i can tell is 1,024 IPv4 addresses. Which is a > 0.000113778 IPv4 addresses per subscriber from ARIN. I do not speak > for Metro PCS, i just found their case interesting. > > So, there are winners and losers in need-based. Winners puts more > time and money into the process, losers are busy optimizing other > parts of their business instead of working the ARIN system. Looking > back at [3], winners are also big companies with a lot of resource > and ... they probably send people to ARIN meetings and ... maybe they > even send lawyers to ARIN meetings. I don't know, i have never been > to an ARIN meeting myself. > > So far, i hope we have seen that the free pool as of today is relevant > and that need-based is not strictly "fair" in how the distribution > happens, and that there are winners and losers. Winners invest more > time and effort, and sometimes time and effort is from lawyers not > engineers. > > Now, there is more. Many organizations have found ARIN unsuitable for > their address needs. We know that in 2011 when the free pool was much > larger than it is now (4+ /8s?), Microsoft bought IPv4 space from a > bankruptcy court [6]. Amazon among others has also made substantial > market buys. These companies are obviously not getting what they want > from a need-based policy, and i assume they made cogent business case > to close these deals. The difference is they have the money to work > the policy like Comcast, but instead they worked a different angle > also applying money. But, need-based is not a about money. Is it? > It is about justified need, or the appearance of such. It would > appear that Amazon and Microsoft could justify need, but the > need-based policy does not appear to work for them. I am aware of the > transfer policy and how need is, for some reason, a different standard > there. > > So, that is open market end of things, organizations pay millions of > dollars instead of thousands of dollars to not use a need-based policy > of the ARIN free pool. Seems like the symptom of something broken. > > Here is another symptom of something broken. The largest internet > growth engine is mobile. Mobile contributes a huge amount of traffic, > growth, and "stuff" on the Internet. If Zuck does not mention mobile > 20 times in an earnings call, FB stock dives. AT&T wireless and > Verizon Wireless both have close to a 100 million subscribers each. > And, just about every one of those subscribers uses RFC 1918 space. > What about those 2 smaller players, Sprint and T-Mobile. Both of them > use squat space. Despite spending time and money on outreach, this > HUGE part of the internet is not part of the ARIN numbering system > (unless you count the ARIN addresses on the CGN). At least, not part > of ARIN's need-based policy. Mobile uses CGN because ARIN's policies > have not and will not fit with the growth of these networks and their > architectures. Not today, but also not in 2003. I would like that > that to change [7]. Speaking for myself, what i saw was a network was > designed to best fit the business needs. That network design did not > fit ARIN policies for efficiency, and so ARIN would not provide > addresses and CGNs were rolled in to close the gap between the best > network design and the ARIN policies. > > Speaking more for myself, in 2000 i worked for an ISP, and one of my > job roles was assigning addresses to T1 and T3 customers of the ISP. > It was a painful process for me and my customers. We lived in world > where people just wanted a /24 to turn up their LAN, but i could not > just give it to them. It was a world of scarcity of addresses, emails > full of made up justifications, and that persist today. > > In fact, last year i tried to get a /48 of address space for a lab > network attached to a T3 from TWT. They would not give me more than a > /56. I heard from another guy that Internap would only give him a > /64. Need-based is a trickled down disease on network design. > > It is not just mobile doing CGN. AT&T has deployed CGN to landline > DSL [8], and now Verizon DSL too [9] > > As previously noted, the ARIN free pool is a non-trivial sum of 24 > million IPv4 addresses. Yet, companies continue to buy addresses and > / or deploy CGN. And they do it at massive scale. We are talking > about the biggest cloud and access network providers can't seem to get > what they need from ARIN whether it be IPv4 addresses or effective > IPv6 deployment advocacy. > > My conclusion from all this is that need-based policy did not help > IPv4 and is actively hurting IPv6. > > NRPM and ARIN should get out of the business of telling people how to > number their networks, it has not helped the businesses or the > internet. I say this because "we" did not transition to IPv6 and the > market for IPv4 and the technology known as CGN is seen as more > effective solution than ARIN or IPv6 > > That brings me to policy changes that i would like feedback on. > > 1. Should ARIN continue to administer need-based policy now and after > run-out? Please note the discussion of winners and loser with data > points [3] and [5]. Who is ARIN serving with the need-based policy? > > 2. I have made the claim that ARIN's need-based policy has negatively > impacted system design, the specific system being the internet. The > squat / CGN internet that is on your phone [7] and coming to your DSL > [8],[9]. > > 3. By moving away from need based policy from ipv4, we accept reality > that the market rules [6]. IPv4 addresses are part of the means of > production in a capitalist society. IPv4 addresses should not be > acquired by playing some logic game with people via ARIN tickets or > intellectual thumb-wrestling and posturing on PPML. > > 4. IPv6 is designed without need in mind, there is no reason for ARIN > to import the notion that need is factor when each LAN is given 2^64 > addresses. Organizations that want PI should get an ASN (existing > policy) and a minimum /32 and be done. End of story. There is no > logic for conservation of a limitless resource (in this case, it is > bounded by ASN). Growth beyond a /32 should just be a simple written > justification, not gear and subscriber logs showing 80% use. > > 5. These simplifications can be reflected in a rate structure that > results from such simplification. > > > [1] https://www.ripe.net/ripe/policies/proposals/2013-03/ > [2] https://www.arin.net/resources/request/ipv4_countdown.html > [3] > http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf > [4] > http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight= > [5] http://whois.arin.net/rest/net/NET-65-91-116-0-1.html > [6] http://www.bbc.co.uk/news/technology-12859585 > [7] https://www.arin.net/policy/proposals/2013_2.html > [8] > http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address- > [9] > https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Mon Apr 8 21:00:41 2013 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 9 Apr 2013 01:00:41 +0000 Subject: [arin-ppml] The case against need based justification In-Reply-To: References: Message-ID: <855077AC3D7A7147A7570370CA01ECD23A4E70@SUEX10-mbx-10.ad.syr.edu> I found his arguments quite interesting. They provide a useful and well-documented look at what is ordinarily taken for granted. The extreme variance in addresses per organization in particular should be raising eyebrows. While it is true that he hasn?t looked at the engineering plans of each applicant, neither have you, Heather, so you are in no better position to defend the result as plausible. The facts are perfectly consistent with both your view AND his view that some organizations know how to work the system better than others. We would need more information to decide which is correct. But this is one of the key flaws of the needs-based allocations in a climate of scarcity ? you have to base allocations on highly commercially sensitive information, and thus the plans and criteria cannot be transparent. Please note, however, that the rationale for RIPE?s impending abandonment of needs-based is a bit different from cb.list6?s. They are basically just saying that while needs assessment makes sense when you have a free pool, it doesn?t make any sense when the free pool is gone. Moreover, I suspect that this idea is getting huge support in RIPE because people who support IPv6 are coming around to the realization that prolonging the life of v4 through ever-more-stringent allocations is actually covering up the real cost of sticking with v4 ? if we only would let the market govern the price of v4 blocks the transition to v6 might be hastened. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Heather Schiller Sent: Monday, April 08, 2013 11:34 AM To: cb.list6 Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] The case against need based justification I find much of your argument flawed -- you seem to have chosen a conclusion and then tried to wrap theories around it. Re-read the nrpm... for a transfer to be recognized by ARIN, the criteria of justified need still applies. The "substantial market buys" you referenced still had justified need applied to them ---- the only difference between getting space directly from ARIN and getting it on the secondary market [aside from cost] is the window of time you can justify need for. Directly from ARIN you can get 3 months justified need and on the secondary market you can request up to 24 months need. Unless you participated in the engineering and design of each of the networks you reference, you can not have first hand knowledge of how addressing policy affected their decisions. You are making guesses from the outside, based on the size of their customer base and what you see today. In atleast one mobile provider you reference, I can say -with direct knowledge- that your conclusion is wrong. The move to CGN has nothing to do with justified need and everything to do with whether it is financially responsible to continue investing in a finite resource. Sure providers could buy up space on the secondary market for another year or 2 - and then what? The price for v4 could rise exorbitantly, to the point where the cost of an address becomes a significant cost toward offering the service. You will be stuck in the same place and out a bunch of cash. Or you can have multiple customers share an address, recover a bunch of space and continue to grow your business without investing in the secondary market. Its the expense of the secondary market itself, that makes CGN more appealing. With regard to use of RFC1918 space - again - unless you were involved in making the decision at those companies - you can not authoritatively say why they made the decision they did. You are speculating that they chose to use 1918 space because they were unable or unwilling to justify need - and that is very unlikely to be the case. Network Engineers tend to be reasonable, logical folks who give great thought to where public address space is necessary and where it isn't, as well as the pros and cons of using both. They may have chosen to respect a shared resource and conserve space, or been unsure how large the network would grow, or been unable to justify [to their mgr, themselves or whoever] the additional ARIN fees for being in a larger allocation category. Fair does not mean that every organization gets the same thing. The NEEDS of every organization are different. This is why ARIN takes the time to read through the request and help ensure that what the organization gets, meets their needs... not their competitor or neighbor's needs. http://imbloghoppin.blogspot.com/2011/08/power-of-bandaid.html Where I do empathize with you, is the problem you described about getting v6 address space from your provider for a lab and they wouldn't give you more than a /56. However, that is a business decision by your ISP. As of today, there is no mandatory minimum IPv6 assignment size for ISP's to their customers, only a small reference to a recommendation. In fact, justified need is not a requirement in making reallocations to customers in IPv6, so abolishing justified need would not affect the v6 assignment size your ISP offers. If you would like to see that changed - then read up on how we got there and submit a proposal to change it (https://www.arin.net/policy/pdp_appendix_b.html) Otherwise, it is an issue between you and your provider and should be taken up with them directly. --Heather On Mon, Apr 8, 2013 at 1:13 AM, cb.list6 > wrote: Need-based justification is being reviewed in RIPE [1] That spurred me to review need based justification in ARIN for both IPv4 and IPv6. I would like to present some facts for review so that the ARIN community can judge the success of need-based justification and consider the role it will have in future policy. First, as of this writing, ARIN still has 2.47 /8s free [2]. Excluding the last /8 which is locked in a way by policy, that leaves approximately 24 Million addresses in the free pool. Assuming a free market cost of $10 per IPv4 address, that is $240 million worth of IPv4 cost off-set from which one would have to pay the free ipv4 market for those addresses. This is a relevant sum on nearly any balance sheet. So, it is not acceptable to say folks are turning away from it because ARIN is offering that space in a fair way. The free pool is relevant. There is a case that the need-based policy has done well, and it has done well for some. Comcast, for example, has 18 million subscribers and 70 Million IPv4 addresses [3]. For simple math, we can call that 3.8 addresses for every 1 customer. Then, you have a network like Metro PCS who has 9 million subscribers (2.2 million of which are LTE) [4] on what i can tell is 1,024 IPv4 addresses. Which is a 0.000113778 IPv4 addresses per subscriber from ARIN. I do not speak for Metro PCS, i just found their case interesting. So, there are winners and losers in need-based. Winners puts more time and money into the process, losers are busy optimizing other parts of their business instead of working the ARIN system. Looking back at [3], winners are also big companies with a lot of resource and ... they probably send people to ARIN meetings and ... maybe they even send lawyers to ARIN meetings. I don't know, i have never been to an ARIN meeting myself. So far, i hope we have seen that the free pool as of today is relevant and that need-based is not strictly "fair" in how the distribution happens, and that there are winners and losers. Winners invest more time and effort, and sometimes time and effort is from lawyers not engineers. Now, there is more. Many organizations have found ARIN unsuitable for their address needs. We know that in 2011 when the free pool was much larger than it is now (4+ /8s?), Microsoft bought IPv4 space from a bankruptcy court [6]. Amazon among others has also made substantial market buys. These companies are obviously not getting what they want from a need-based policy, and i assume they made cogent business case to close these deals. The difference is they have the money to work the policy like Comcast, but instead they worked a different angle also applying money. But, need-based is not a about money. Is it? It is about justified need, or the appearance of such. It would appear that Amazon and Microsoft could justify need, but the need-based policy does not appear to work for them. I am aware of the transfer policy and how need is, for some reason, a different standard there. So, that is open market end of things, organizations pay millions of dollars instead of thousands of dollars to not use a need-based policy of the ARIN free pool. Seems like the symptom of something broken. Here is another symptom of something broken. The largest internet growth engine is mobile. Mobile contributes a huge amount of traffic, growth, and "stuff" on the Internet. If Zuck does not mention mobile 20 times in an earnings call, FB stock dives. AT&T wireless and Verizon Wireless both have close to a 100 million subscribers each. And, just about every one of those subscribers uses RFC 1918 space. What about those 2 smaller players, Sprint and T-Mobile. Both of them use squat space. Despite spending time and money on outreach, this HUGE part of the internet is not part of the ARIN numbering system (unless you count the ARIN addresses on the CGN). At least, not part of ARIN's need-based policy. Mobile uses CGN because ARIN's policies have not and will not fit with the growth of these networks and their architectures. Not today, but also not in 2003. I would like that that to change [7]. Speaking for myself, what i saw was a network was designed to best fit the business needs. That network design did not fit ARIN policies for efficiency, and so ARIN would not provide addresses and CGNs were rolled in to close the gap between the best network design and the ARIN policies. Speaking more for myself, in 2000 i worked for an ISP, and one of my job roles was assigning addresses to T1 and T3 customers of the ISP. It was a painful process for me and my customers. We lived in world where people just wanted a /24 to turn up their LAN, but i could not just give it to them. It was a world of scarcity of addresses, emails full of made up justifications, and that persist today. In fact, last year i tried to get a /48 of address space for a lab network attached to a T3 from TWT. They would not give me more than a /56. I heard from another guy that Internap would only give him a /64. Need-based is a trickled down disease on network design. It is not just mobile doing CGN. AT&T has deployed CGN to landline DSL [8], and now Verizon DSL too [9] As previously noted, the ARIN free pool is a non-trivial sum of 24 million IPv4 addresses. Yet, companies continue to buy addresses and / or deploy CGN. And they do it at massive scale. We are talking about the biggest cloud and access network providers can't seem to get what they need from ARIN whether it be IPv4 addresses or effective IPv6 deployment advocacy. My conclusion from all this is that need-based policy did not help IPv4 and is actively hurting IPv6. NRPM and ARIN should get out of the business of telling people how to number their networks, it has not helped the businesses or the internet. I say this because "we" did not transition to IPv6 and the market for IPv4 and the technology known as CGN is seen as more effective solution than ARIN or IPv6 That brings me to policy changes that i would like feedback on. 1. Should ARIN continue to administer need-based policy now and after run-out? Please note the discussion of winners and loser with data points [3] and [5]. Who is ARIN serving with the need-based policy? 2. I have made the claim that ARIN's need-based policy has negatively impacted system design, the specific system being the internet. The squat / CGN internet that is on your phone [7] and coming to your DSL [8],[9]. 3. By moving away from need based policy from ipv4, we accept reality that the market rules [6]. IPv4 addresses are part of the means of production in a capitalist society. IPv4 addresses should not be acquired by playing some logic game with people via ARIN tickets or intellectual thumb-wrestling and posturing on PPML. 4. IPv6 is designed without need in mind, there is no reason for ARIN to import the notion that need is factor when each LAN is given 2^64 addresses. Organizations that want PI should get an ASN (existing policy) and a minimum /32 and be done. End of story. There is no logic for conservation of a limitless resource (in this case, it is bounded by ASN). Growth beyond a /32 should just be a simple written justification, not gear and subscriber logs showing 80% use. 5. These simplifications can be reflected in a rate structure that results from such simplification. [1] https://www.ripe.net/ripe/policies/proposals/2013-03/ [2] https://www.arin.net/resources/request/ipv4_countdown.html [3] http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf [4] http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight= [5] http://whois.arin.net/rest/net/NET-65-91-116-0-1.html [6] http://www.bbc.co.uk/news/technology-12859585 [7] https://www.arin.net/policy/proposals/2013_2.html [8] http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address- [9] https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Apr 9 00:05:53 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 8 Apr 2013 21:05:53 -0700 Subject: [arin-ppml] The case against need based justification In-Reply-To: <855077AC3D7A7147A7570370CA01ECD23A4E70@SUEX10-mbx-10.ad.syr.edu> References: <855077AC3D7A7147A7570370CA01ECD23A4E70@SUEX10-mbx-10.ad.syr.edu> Message-ID: <7CC7AB6B-3078-40AD-BF17-828E2A63DE9D@delong.com> Cameron, by his own admission mostly chooses not to learn what is in the NRPM. Generally, if you are unwilling to read the rule book, you don't tend to do well in any venture. Abandoning needs basis is not the answer. I agree that making IPv4 policy continually more stringent and making it harder for deserving organizations to get the IPv4 that they need in order to create the illusion of a prolonged life for IPv4 in the ARIN region is anti-good. I'm all for relaxing the time-scale on IPv4 requests to 24 months to match the market provision, for example. I wanted to line them up a long time ago. The price of IPv4 blocks pales in comparison to the coming price of attempting to maintain IPv4 through an ever more complex set of layered hacks. Owen On Apr 8, 2013, at 18:00 , Milton L Mueller wrote: > I found his arguments quite interesting. They provide a useful and well-documented look at what is ordinarily taken for granted. The extreme variance in addresses per organization in particular should be raising eyebrows. > > While it is true that he hasn?t looked at the engineering plans of each applicant, neither have you, Heather, so you are in no better position to defend the result as plausible. The facts are perfectly consistent with both your view AND his view that some organizations know how to work the system better than others. We would need more information to decide which is correct. But this is one of the key flaws of the needs-based allocations in a climate of scarcity ? you have to base allocations on highly commercially sensitive information, and thus the plans and criteria cannot be transparent. > > Please note, however, that the rationale for RIPE?s impending abandonment of needs-based is a bit different from cb.list6?s. They are basically just saying that while needs assessment makes sense when you have a free pool, it doesn?t make any sense when the free pool is gone. Moreover, I suspect that this idea is getting huge support in RIPE because people who support IPv6 are coming around to the realization that prolonging the life of v4 through ever-more-stringent allocations is actually covering up the real cost of sticking with v4 ? if we only would let the market govern the price of v4 blocks the transition to v6 might be hastened. > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Heather Schiller > Sent: Monday, April 08, 2013 11:34 AM > To: cb.list6 > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] The case against need based justification > > I find much of your argument flawed -- you seem to have chosen a conclusion and then tried to wrap theories around it. > > Re-read the nrpm... for a transfer to be recognized by ARIN, the criteria of justified need still applies. The "substantial market buys" you referenced still had justified need applied to them ---- the only difference between getting space directly from ARIN and getting it on the secondary market [aside from cost] is the window of time you can justify need for. Directly from ARIN you can get 3 months justified need and on the secondary market you can request up to 24 months need. > > Unless you participated in the engineering and design of each of the networks you reference, you can not have first hand knowledge of how addressing policy affected their decisions. You are making guesses from the outside, based on the size of their customer base and what you see today. In atleast one mobile provider you reference, I can say -with direct knowledge- that your conclusion is wrong. The move to CGN has nothing to do with justified need and everything to do with whether it is financially responsible to continue investing in a finite resource. Sure providers could buy up space on the secondary market for another year or 2 - and then what? The price for v4 could rise exorbitantly, to the point where the cost of an address becomes a significant cost toward offering the service. You will be stuck in the same place and out a bunch of cash. Or you can have multiple customers share an address, recover a bunch of space and continue to grow your business without investing in the secondary market. Its the expense of the secondary market itself, that makes CGN more appealing. > > With regard to use of RFC1918 space - again - unless you were involved in making the decision at those companies - you can not authoritatively say why they made the decision they did. You are speculating that they chose to use 1918 space because they were unable or unwilling to justify need - and that is very unlikely to be the case. Network Engineers tend to be reasonable, logical folks who give great thought to where public address space is necessary and where it isn't, as well as the pros and cons of using both. They may have chosen to respect a shared resource and conserve space, or been unsure how large the network would grow, or been unable to justify [to their mgr, themselves or whoever] the additional ARIN fees for being in a larger allocation category. > > Fair does not mean that every organization gets the same thing. The NEEDS of every organization are different. This is why ARIN takes the time to read through the request and help ensure that what the organization gets, meets their needs... not their competitor or neighbor's needs. > > http://imbloghoppin.blogspot.com/2011/08/power-of-bandaid.html > > > Where I do empathize with you, is the problem you described about getting v6 address space from your provider for a lab and they wouldn't give you more than a /56. However, that is a business decision by your ISP. As of today, there is no mandatory minimum IPv6 assignment size for ISP's to their customers, only a small reference to a recommendation. In fact, justified need is not a requirement in making reallocations to customers in IPv6, so abolishing justified need would not affect the v6 assignment size your ISP offers. If you would like to see that changed - then read up on how we got there and submit a proposal to change it (https://www.arin.net/policy/pdp_appendix_b.html) Otherwise, it is an issue between you and your provider and should be taken up with them directly. > > --Heather > > > > On Mon, Apr 8, 2013 at 1:13 AM, cb.list6 wrote: > Need-based justification is being reviewed in RIPE [1] > > That spurred me to review need based justification in ARIN for both > IPv4 and IPv6. > > I would like to present some facts for review so that the ARIN > community can judge the success of need-based justification and > consider the role it will have in future policy. > > First, as of this writing, ARIN still has 2.47 /8s free [2]. > Excluding the last /8 which is locked in a way by policy, that leaves > approximately 24 Million addresses in the free pool. Assuming a free > market cost of $10 per IPv4 address, that is $240 million worth of > IPv4 cost off-set from which one would have to pay the free ipv4 > market for those addresses. This is a relevant sum on nearly any > balance sheet. So, it is not acceptable to say folks are turning away > from it because ARIN is offering that space in a fair way. The free > pool is relevant. > > There is a case that the need-based policy has done well, and it has > done well for some. Comcast, for example, has 18 million subscribers > and 70 Million IPv4 addresses [3]. For simple math, we can call that > 3.8 addresses for every 1 customer. Then, you have a network like > Metro PCS who has 9 million subscribers (2.2 million of which are LTE) > [4] on what i can tell is 1,024 IPv4 addresses. Which is a > 0.000113778 IPv4 addresses per subscriber from ARIN. I do not speak > for Metro PCS, i just found their case interesting. > > So, there are winners and losers in need-based. Winners puts more > time and money into the process, losers are busy optimizing other > parts of their business instead of working the ARIN system. Looking > back at [3], winners are also big companies with a lot of resource > and ... they probably send people to ARIN meetings and ... maybe they > even send lawyers to ARIN meetings. I don't know, i have never been > to an ARIN meeting myself. > > So far, i hope we have seen that the free pool as of today is relevant > and that need-based is not strictly "fair" in how the distribution > happens, and that there are winners and losers. Winners invest more > time and effort, and sometimes time and effort is from lawyers not > engineers. > > Now, there is more. Many organizations have found ARIN unsuitable for > their address needs. We know that in 2011 when the free pool was much > larger than it is now (4+ /8s?), Microsoft bought IPv4 space from a > bankruptcy court [6]. Amazon among others has also made substantial > market buys. These companies are obviously not getting what they want > from a need-based policy, and i assume they made cogent business case > to close these deals. The difference is they have the money to work > the policy like Comcast, but instead they worked a different angle > also applying money. But, need-based is not a about money. Is it? > It is about justified need, or the appearance of such. It would > appear that Amazon and Microsoft could justify need, but the > need-based policy does not appear to work for them. I am aware of the > transfer policy and how need is, for some reason, a different standard > there. > > So, that is open market end of things, organizations pay millions of > dollars instead of thousands of dollars to not use a need-based policy > of the ARIN free pool. Seems like the symptom of something broken. > > Here is another symptom of something broken. The largest internet > growth engine is mobile. Mobile contributes a huge amount of traffic, > growth, and "stuff" on the Internet. If Zuck does not mention mobile > 20 times in an earnings call, FB stock dives. AT&T wireless and > Verizon Wireless both have close to a 100 million subscribers each. > And, just about every one of those subscribers uses RFC 1918 space. > What about those 2 smaller players, Sprint and T-Mobile. Both of them > use squat space. Despite spending time and money on outreach, this > HUGE part of the internet is not part of the ARIN numbering system > (unless you count the ARIN addresses on the CGN). At least, not part > of ARIN's need-based policy. Mobile uses CGN because ARIN's policies > have not and will not fit with the growth of these networks and their > architectures. Not today, but also not in 2003. I would like that > that to change [7]. Speaking for myself, what i saw was a network was > designed to best fit the business needs. That network design did not > fit ARIN policies for efficiency, and so ARIN would not provide > addresses and CGNs were rolled in to close the gap between the best > network design and the ARIN policies. > > Speaking more for myself, in 2000 i worked for an ISP, and one of my > job roles was assigning addresses to T1 and T3 customers of the ISP. > It was a painful process for me and my customers. We lived in world > where people just wanted a /24 to turn up their LAN, but i could not > just give it to them. It was a world of scarcity of addresses, emails > full of made up justifications, and that persist today. > > In fact, last year i tried to get a /48 of address space for a lab > network attached to a T3 from TWT. They would not give me more than a > /56. I heard from another guy that Internap would only give him a > /64. Need-based is a trickled down disease on network design. > > It is not just mobile doing CGN. AT&T has deployed CGN to landline > DSL [8], and now Verizon DSL too [9] > > As previously noted, the ARIN free pool is a non-trivial sum of 24 > million IPv4 addresses. Yet, companies continue to buy addresses and > / or deploy CGN. And they do it at massive scale. We are talking > about the biggest cloud and access network providers can't seem to get > what they need from ARIN whether it be IPv4 addresses or effective > IPv6 deployment advocacy. > > My conclusion from all this is that need-based policy did not help > IPv4 and is actively hurting IPv6. > > NRPM and ARIN should get out of the business of telling people how to > number their networks, it has not helped the businesses or the > internet. I say this because "we" did not transition to IPv6 and the > market for IPv4 and the technology known as CGN is seen as more > effective solution than ARIN or IPv6 > > That brings me to policy changes that i would like feedback on. > > 1. Should ARIN continue to administer need-based policy now and after > run-out? Please note the discussion of winners and loser with data > points [3] and [5]. Who is ARIN serving with the need-based policy? > > 2. I have made the claim that ARIN's need-based policy has negatively > impacted system design, the specific system being the internet. The > squat / CGN internet that is on your phone [7] and coming to your DSL > [8],[9]. > > 3. By moving away from need based policy from ipv4, we accept reality > that the market rules [6]. IPv4 addresses are part of the means of > production in a capitalist society. IPv4 addresses should not be > acquired by playing some logic game with people via ARIN tickets or > intellectual thumb-wrestling and posturing on PPML. > > 4. IPv6 is designed without need in mind, there is no reason for ARIN > to import the notion that need is factor when each LAN is given 2^64 > addresses. Organizations that want PI should get an ASN (existing > policy) and a minimum /32 and be done. End of story. There is no > logic for conservation of a limitless resource (in this case, it is > bounded by ASN). Growth beyond a /32 should just be a simple written > justification, not gear and subscriber logs showing 80% use. > > 5. These simplifications can be reflected in a rate structure that > results from such simplification. > > > [1] https://www.ripe.net/ripe/policies/proposals/2013-03/ > [2] https://www.arin.net/resources/request/ipv4_countdown.html > [3] http://www.nanog.org/meetings/nanog57/presentations/Tuesday/tue.lightning3.howard.ipv4%20buyers.pdf > [4] http://investor.metropcs.com/phoenix.zhtml?c=177745&p=irol-newsArticle&ID=1789168&highlight= > [5] http://whois.arin.net/rest/net/NET-65-91-116-0-1.html > [6] http://www.bbc.co.uk/news/technology-12859585 > [7] https://www.arin.net/policy/proposals/2013_2.html > [8] http://www.broadbandreports.com/forum/r27139468-Uverse-wants-me-to-change-my-network-address- > [9] https://www22.verizon.com/support/residential/internet/highspeed/networking/troubleshooting/portforwarding/123897.htm > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at temk.in Tue Apr 9 12:38:00 2013 From: dave at temk.in (David Temkin) Date: Tue, 9 Apr 2013 09:38:00 -0700 Subject: [arin-ppml] NANOG 58 - New Orleans - Call For Presentations is open! In-Reply-To: References: Message-ID: Reminder- the RFP closed yesterday but we will continue to accept submissions through the end of the week. Regards, -Dave On Mon, Mar 25, 2013 at 9:47 AM, David Temkin wrote: > Just a reminder that the RFP is still open for NANOG 58! > > Regards, > -Dave > > On Fri, Mar 1, 2013 at 12:02 PM, David Temkin wrote: > >> *Fresh off of a great NANOG 57 in Orlando, your program committee is >> already working hard to provide a world-class program for NANOG 58 in NOLA >> - New Orleans, Louisiana - one of my favorite destinations in the world.* >> * >> * >> *As a reminder, we will be following the same Monday-Wednesday program >> that we started at NANOG 57, with Tutorials beginning Monday morning and >> closing with the Peering Track (and potentially a social) on Wednesday >> evening. * >> * >> * >> *We look forward to seeing everyone in The Big Easy!* >> * >> >> -------------------- >> >> The North American Network Operators' Group (NANOG) will hold its 58th >> meeting in New Orleans on June 3rd - 5th, 2013 Verizon Terremark will >> host NANOG 58. The NANOG Program Committee is now seeking proposals for >> presentations, panels, tutorials, tracks sessions, keynote materials, and >> the NOGLab experience for the NANOG 58 program. We invite presentations >> highlighting issues relating to technology already deployed or soon-to-be >> deployed in the Internet. Vendors are encouraged to work with operators to >> present real-world deployment experiences with the vendor's products and >> interoperability via the program and as part of the NOGLab. NANOG 58 >> submissions are welcome at http://pc.nanog.org. >> >> About NANOG >> NANOG is the premier meeting for network operators in North America. >> Meetings provide a forum for information exchange among network operators, >> engineers, and researchers. NANOG meets three times each year, and includes >> panels, presentations, tutorial sessions, tracks, informal BOFs, and a >> NOGLab which features interoperability demonstrations. NANOG attendees >> include operators from networks of all sizes, enterprise operators, peering >> coordinators, transport and switching equipment vendors, and network >> researchers. NANOG attendees will share ideas and interact with leaders in >> the field of network operations, discuss current operational events and >> issues, and learn about state-of-the-art operational techniques. >> >> Materials from NANOG 58 will be archived at: >> http://www.nanog.org/meetings/nanog58/ >> >> Key Dates for NANOG 58 >> >> ? CFP Opens for NANOG 58: 25-February-2013 >> ? CFP Deadline #1: Presentation Abstracts Due: 8-April-2013 >> ? CFP Deadline #2: Presentation Slides Due: 29-April-2013 >> ? NANOG Highlights Page Posted: 22-April-2013 >> ? Preliminary Topic List Posted: 26-April-2013 >> ? Meeting Agenda Published: 13-May-2013 >> ? Meeting Agenda Final sent to printer: 20-May-2013 >> ? Lightning Talk Submissions Open (Abstracts Only): 2-June-2013 >> ? Speaker FINAL presentations to PCTool or speaker-support: 31-May-2013 >> ? On-Site Registration: 31-May-2013 >> >> The NANOG Program Committee seeks proposals for presentations, panels, >> tutorial sessions, tracks, and BOFs in all areas of network operations, >> including (but not limited to): >> >> - Power and facilities - Topics may include power reliability and >> engineering, green power, power efficiency, cooling, and facilities >> management. >> - Interconnections - Topics may include IXes, intra-building, MMR, >> metro-wide connections, peering, and transit purchasing tactics and >> strategies. >> - Security - Topics may include routing security, route filtering of >> large peers/customers, and inter-AS security and cooperation. >> - DNS - Topics may include using DNS data for network metrics, botnet >> discovery, and geolocation. >> - IPv6 - Topics may include real-world deployment challenges, Carrier >> Grade NAT, NAT-PT implementations that work and scale, and allocation >> strategies. >> - Content - Topics may include Distribution (p2p, IPTV), content >> payment models, content distribution technologies and networks, and >> storage/archiving. >> - Disaster recovery - Topics may include risk analysis, training, >> agencies, planning methods, hardware portability, key tools, transport >> audits, and other lessons learned. >> >> In general, presentations are being sought by and for network operators >> of all sizes. Presentations about difficult problems (and interesting >> solutions) that you encounter in the course of your job are encouraged. >> >> In addition, the Program Committee, through participation with other >> organizations and vendor?s, will be programming a NOGLab experience. >> The topic of the NOGLab will be timely and feature real-world experiences >> faced by operators of today?s Internet. >> >> If you think you have an interesting topic but want some feedback or >> assistance working it into a presentation, please email the Program >> Committee chair (chair at pc.nanog.org), and a representative on the >> Program Committee will give you the feedback needed to work it into a >> presentation. Otherwise, don't delay in submitting your talk, keynote, >> track, or panel into the NANOG Program Committee tool, located at >> http://pc.nanog.org. For more information about talk types and format, >> please see http://nanog.org/presentations/guidelines/talktips.php >> >> How to Present >> The deadline for accepting abstracts and slides is April 8, 2013 . While >> the majority of speaking slots may be filled by that date, a limited number >> of slots may be available after that date for topics that are exceptionally >> timely, important, or critical to the operations of the Internet. >> >> Complete Presentation Guidelines can be found at >> http://nanog.org/presentations/ >> >> The primary speaker, moderator, or author should submit presentation >> information and an abstract online at: http://pc.nanog.org once you have >> done this, you will receive instructions for submitting your draft slides. >> >> - Author's name(s) >> - Preferred contact email address >> - A preferred phone number for contact >> - Submission category (General Session, Panel, Tutorial, or Research >> Forum) >> - Presentation title >> - Abstract >> - Slides (attachment or URL), in PDF (preferred) or PowerPoint format. >> >> We look forward to reviewing your submission. >> >> Talks >> Keynote Presentation: The Program Committee invites speakers to submit >> materials for up to one-hour keynote presentations. Speakers should >> indicate that their submission is for a keynote in their abstracts. Speaker >> must submit slides for a Keynote Presentation. >> >> General Session Talk: A General Session presentation should be on a >> topic of interest to the general NANOG audience, and may be up to >> 30-minutes long (including time for Q&A). Speakers must submit slides for a >> General Session presentation. >> >> General Session Panel: Panels are 60-90-minute discussion sessions >> between a moderator and a team of panelists. The panel moderator should >> submit an abstract on the panel topic, a list of panelists, and how the >> panel will be organized. Panel selection will be based on the importance, >> originality, focus and timeliness of the topic, expertise of proposed >> panelists, as well as the potential for informative and controversial >> discussion. After acceptance the panel leader will be given the option to >> invite panel authors to submit their presentations to the NANOG program >> Committee for review. Until then authors should not submit their individual >> presentations for the panel. >> >> Tracks: Tracks are 90-minute informal agenda blocks on topics, which are >> of interest to a portion of the NANOG community. The 90-minute block can be >> subdivided into a number of smaller, highly related presentations, panels >> or open discussion. A moderator coordinates content within the 90-minute >> block of time, and must submit a detailed outline to the Program Committee, >> including sub-topics and presenters >> Peering >> ISP Security >> Tools >> Typically two tracks or three tracks will be run concurrently. >> >> Tutorials: Tutorials are 90-minute sessions. A presentation from the >> introductory through advanced level on all related topics, including: >> Disaster Recovery Planning >> Troubleshooting BGP >> Best Practices for Determining Traffic Matrices >> Options for Blackhole and Discard Routing >> BGP/MPLS Layer 3 VPNs >> Peering business and engineering basics >> A tutorial submission should include an abstract and slides. >> >> BOFs: BOFs (Birds of a Feather sessions) are informal sessions on >> topics, which are of interest to a portion of the NANOG community. BOFs may >> be held in the hallways, breakout areas or in an unscheduled tutorial room. >> Requests for scheduled BOFs will be take place on site at the meeting. >> >> A typical BOF session may include some structure or presentations, but >> usually is focused on community discussion and interaction. >> >> Frequent BOF topics include: >> R&D collaboration >> Hot-topics in the media >> The less structured nature of BOF sessions allows for the greatest >> flexibility from a timing perspective. >> >> Lightning Talks: A lightning talk is a very short presentation or speech >> by any attendee on any topic relevant to the NANOG audience. These are >> limited to ten minutes; this will be strictly enforced. >> >> If you have a topic that's timely, interesting, or even a crackpot idea >> you want to share, we encourage you to consider presenting it. The Program >> Committee will vote on all Lightning Talk submissions onsite at the >> meeting, and a submitter will be notified about his or her submission one >> day prior to the scheduled talk time. >> >> Submit your lightning talk proposal at http://pc.nanog.org starting June >> 2, 2013. >> >> Research Forum: Researchers are invited to present short (10-minute) >> summaries of their work for operator feedback. Topics include routing, >> network performance, statistical measurement and analysis, and protocol >> development and implementation. Studies presented may be works in progress. >> Researchers from academia, government, and industry are encouraged to >> present. >> >> The NANOG registration fee is waived for: >> >> - For General Session presentations, the registration fee will be >> waived for a maximum of one speaker. >> - For General Session panels, fees will be waived for one panel >> moderator and all panelists. >> - For Tracks, fees will be waived for one moderator. >> - For Research Forum presentations, fees will be waived for one >> speaker. >> - For Tutorials, fees will be waived for one instructor. >> >> * > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wesley.george at twcable.com Tue Apr 9 14:07:13 2013 From: wesley.george at twcable.com (George, Wes) Date: Tue, 9 Apr 2013 14:07:13 -0400 Subject: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy In-Reply-To: References: <5153386B.1040203@arin.net> Message-ID: <2671C6CDFBB59E47B64C10B3E0BD5923042D458C81@PRVPEXVS15.corp.twcable.com> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Subject: Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy [WEG] /delurk, sorry I missed the deadline, but thought it was still important to provide some input before the meeting. I am opposed to this policy. - Is the problem statement clear to the community? Do you have any questions on the problem the proposal is attempting to solve? [WEG] clear, yes. Technically justified, not so much. I do not dispute that shuffling numbers around between mobility anchor (HA/P-GW/GGSN) or CGN instances within a mobile network is unpleasant, as is multiple reuse of RFC1918/6598 space. I also do not dispute that the submitter of the policy is attempting to solve a real problem within his company's implementation. I do, however, dispute the assertion that this is a mobile-industry-wide problem or somehow technically inherent to 3GPP networks, technically impossible, or even a new problem. I can speak from personal experience that some mobile providers waited as long as possible before moving to CGN, and as a result were/are required to do this shuffling of address blocks between mobility anchors to address uneven usage until they reached a documentable 80% utilization network-wide per ARIN policy. This was the reality, and they designed their tools and access lists and routing to manage that reality. Further, I can make a reasonable assumption based on what I know about other mobile providers that some of them have been successfully reusing the same 1918 space in multiple locations. Sure, it's cleaner to have addresses that are unique across a network, and to use global addresses instead of CGN, but sometimes one must make concessions to the cleanest design based on other factors (cost, resources, etc). - Do you feel that it is an important problem to try to solve? Do you have any reasons you can share that we should or shouldn't do so? [WEG] no, it's not an important problem to solve. At this point, changes to the burn rate of IPv4 due to changes in IPv4 *policy* rather than demand really need to stop. Most of the community have timelines built around assumptions for exhaustion that we have hung significant business and technical implementation plans on, and IMO this issue does not pass the bar to justify the change and upset those. Should we really be making it easier to justify more resources sooner for a specific industry that has already been both a major consumer of IPv4 addresses and reticent to deploy IPv6? I realize that it is unfair to paint the entire mobile industry with the same brush, as some providers are much better than others about both deploying IPv6 and conserving IPv4, but the reality is that if this policy is adopted, all of them benefit, and other potential consumers of addresses lose out for questionable technical benefit. - If so, how would you prefer we approach solving it? Some suggestions are outlined in the proposal below, but we'll need to decide on an approach and write and discuss actual policy text in order to move this Draft Policy forward. This proposal will *not* be eligible for last call after ARIN 31 in Barbados, but we will be discussing it there. [WEG] Regarding the specific policy statement: in the mobile world, the difference between attached users and total subscribers has been rapidly disappearing as smartphones have replaced what the mobile industry calls "feature" phones for all but the most basic users (IIRC, smartphones overtook them as the majority last year). Even a few years ago, it was possible to assume a 3:1 or higher oversubscription on address use because the majority of phones were not using a data connection that frequently, and short DHCP leases could allow you to share addresses. The duration an address was in use largely tracked with the short periods of time when people were actively accessing content on their phones, and that usage was limited by the crap experience it represented. But smartphones offer a better user experience and therefore increase usage, and more importantly, are inherently "chatty" even when the user is not actively doing anything, due to background application updates. When you think about the fact that even one application relying on push notification can essentially drive you toward a constant data connection, and most devices have multiple simultaneous push apps running, it becomes increasingly difficult to assume that a significant percentage of devices will be idle long enough to make much of a difference when it comes to IP allocation (DHCP lease times). Note too that there is a difference between the amount of time that the *radio* is idle compared with the time that the data connection is idle, which is why push notifications are useful. Thanks, Wes George On Wed, Mar 27, 2013 at 11:20 AM, ARIN > wrote: Draft Policy ARIN-2013-2 3GPP Network IP Resource Policy On 21 March 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-184 3GPP Network IP Resource Policy" as a Draft Policy. Draft Policy ARIN-2013-2 is below and can be found at: https://www.arin.net/policy/proposals/2013_2.html You are encouraged to discuss the merits and your concerns of Draft Policy 2013-2 on the Public Policy Mailing List. 2013-2 will also be on the agenda at the upcoming ARIN Public Policy Meeting in Barbados. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The ARIN Policy Development Process (PDP) can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2013-2 3GPP Network IP Resource Policy Date: 27 March 2013 Problem Statement: Current 3GPP architectures consist of hierarchical aggregation, from cell site up to anchor nodes, approximately one per NFL city. Anchor nodes are the point where IP addresses are assigned and topologically positioned in the network. Generally an anchor node must be provisioned with enough addresses to handle all simultaneously attached users, plus enough headroom to handle failover from an adjacent anchor node in the event of an outage. Capacity planning generally ensures that all anchor nodes have approximately the same number of attached users at steady state. Moving addresses between anchor nodes would require significant renumbering effort and substantial increases in operational complexity, so cannot be performed during an outage. Generally addresses are not renumbered between anchor nodes: instead, aggregation nodes can be rehomed as needed to balance steady state capacity levels. Because of the 3GPP architecture's failover and capacity planning requirements, all cellular networks target approximately 50% simultaneous usage of each anchor node's IP addresses. However, even at 50% usage, the total number of subscribers generally exceeds the number of addresses needed. Currently, a number of mobile networks are using non-RIR-assigned space internally to meet customer demand. However, there is insufficient private space (RFC1918, etc.) available for internal use, so other unassigned space is currently being used. As this unassigned space is brought into service via reclamation, returns, and transfers, it is no longer possible to use it internally, so globally unique space must be used instead. As a result, most of the need for additional RIR-assigned space is to serve existing customers, not to accommodate future growth. Policy statement: I can see two possible approaches to address this need. One approach would be to continue counting simultaneously attached users to measure IP needs, and apply a 50% usage requirement to justify allocations. Another approach would be to instead count total subscribers (rather than simultaneously attached users), and apply a much higher threshold, such as 80% or even 90%, to justify allocations. Timetable for implementation: ASAP _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Wed Apr 10 05:21:41 2013 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 10 Apr 2013 09:21:41 +0000 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <51622918.7060104@redbarn.org> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> <51622918.7060104@redbarn.org> Message-ID: <855077AC3D7A7147A7570370CA01ECD23A6E68@SUEX10-mbx-10.ad.syr.edu> > so i thought i'd chime in: i consider that case to be extremely unmade as yet. even though i am in most other ways a free-marketeer. as stewards of a public resource ARIN has always been guided by RFC 2050 which requires recipients of these public resources to justify their need, no matter whether these resources are coming from a central pool or a private transfer. [Milton L Mueller] This is a religious argument Paul. A statement of your belief, nothing more. Can we try to move beyond that? We've all got beliefs. I would like to know your definition of "public resource," and precisely how such resources are different from other resources. Addresses are clearly not "public goods" which is a term with a precise definition in economics, so don't waste time arguing about that. The characteristics of public goods are well known and IP numbers don't fit them (IP numbers are both rival in consumption and excludable, so they are not public goods.) But there is more. If you somehow succeed in providing a definition, I then would like to see a scientific and/or logical derivation of how "being a public resource" requires administrative needs assessment rather than market-based allocation. What exactly is being optimized via needs assessment? Conservation? Unlikely, higher prices do a better job of conserving than any other social mechanism. In an environment in which the free pool is completely or almost gone, and in which prices can do the work of rationing, please tell me why needs assessments do anything we need to have done. After you do those two things, you might explain why there is strong, perhaps overwhelming support for eliminating needs assessment in the RIPE region. Have they all gone mad there? Are they possessed by the Devil? Looking forward to substantive exchanges on this topic --MM -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Wed Apr 10 12:22:07 2013 From: joelja at bogus.com (joel jaeggli) Date: Wed, 10 Apr 2013 09:22:07 -0700 Subject: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs In-Reply-To: <037BE157-3179-42B7-9952-94353DA05A47@delong.com> References: <5B9E90747FA2974D91A54FCFA1B8AD12012F5CC8A3@ENI-MAIL.eclipse-networks.com> <5161CDD3.9090803@redbarn.org> <51622918.7060104@redbarn.org> <037BE157-3179-42B7-9952-94353DA05A47@delong.com> Message-ID: <516591AF.9040903@bogus.com> On 4/7/13 10:27 PM, Owen DeLong wrote: > Number resource policy is not the reason mobile phone users are behind > CGN today. > > That's an excuse, not a legitimate reason. > The fact that one can write a needs based request for the resources doesn't eliminate the fact that there aren't enough v4 IPs remaining to number them all in north america or anywhere else. > Until fairly recently, there were actually several mobile phone > operators that did not place their subscribers behind CGN. > > Owen > > On Apr 7, 2013, at 19:34 , cb.list6 > wrote: > >> >> On Apr 7, 2013 7:19 PM, "Paul Vixie" > > wrote: >> > >> > ... >> > >> > cb.list6 wrote: >> >> >> >> >> >> On Apr 7, 2013 12:49 PM, "Paul Vixie" > > wrote: >> >> > >> >> > i know that it's a popular viewpoint -- many folks feel that the >> time for needs based allocation is over and that the invisible hand >> of the market is now capable of optimizing the holding of address >> space and the aggregation level of that space into routing table entries. >> >> > >> >> >> >> Popular viewpoint go far in a bottom up process such as arin. In >> fact, the whole thing is a popularity contest. >> > >> > >> > i said it was popular, not that it could win a popularity contest. >> > >> > >> >> > so i thought i'd chime in: i consider that case to be extremely >> unmade as yet. even though i am in most other ways a free-marketeer. >> as stewards of a public resource ARIN has always been guided by RFC >> 2050 which requires recipients of these public resources to justify >> their need, no matter whether these resources are coming from a >> central pool or a private transfer. >> >> > >> >> > paul >> >> >> >> Does that mean you require an update to rfc 2050 to move ? >> > >> > >> > not at all. i think RFC 2050 was and remains correct in this >> regard. i'll "move" when and if my mind changes on the matter. >> > >> >> I noticed this http://tools.ietf.org/html/draft-housley-rfc2050bis-01 >> >> >> >> ... >> >> >> >> Should 2050bis ask rir not do this fair policy? From what I read >> in 2050bis is that is says the rir can make their own policy and 2050 >> is dead. >> >> >> >> Do you read it differently? >> > >> > >> > i read it to accurately explain that not every RIR still follows >> the needs based justification described in RFC 2050. it's a >> description of the current RIR system. 2050bis does not "ask" RIRs to >> do anything, it's a description of what they actually do. >> > >> > >> >> As it stands, speaking from experience, the justification story in >> v4 and v6 drives design choices. That is an unfortunate fact and >> negatively impacts system design. >> > >> > >> > i'm intrigued by this statement. i hope you are willing to share >> some of your experiences as to how needs based justification has >> negatively driven some design choices. >> > >> > paul >> >> I just wrote a page of explanation and deleted it. >> >> If I have to explain it, you would not understand. And you do not >> understand today's data networks at all. I feel bad and outrageous >> saying that. But, given hundreds of millions of mobile phone users >> behind cgn today, perhaps your question is outrageous >> >> Note that att and vz have both rolled cgn to their dsl subs. >> >> Yet arin is not exhausted. >> >> Interesting? >> >> CB. >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >> ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From mysidia at gmail.com Wed Apr 10 21:28:37 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 10 Apr 2013 20:28:37 -0500 Subject: [arin-ppml] The case against need based justification In-Reply-To: References: Message-ID: On 4/8/13, cb.list6 wrote: > I would like to present some facts for review so that the ARIN > community can judge the success of need-based justification and There are some non-facts included there as well; opinions which have not been proven nor substantiated through experiment. > Excluding the last /8 which is locked in a way by policy, that leaves > approximately 24 Million addresses in the free pool. Correct > Assuming a free market cost of $10 per IPv4 address, that is > $240 million worth of IPv4 cost off-set from which one would > have to pay the free ipv4 market for those addresses. There are some errors here: o Unwarranted assumption of a supposed per-IPv4 address market cost. o Unsubstantiated assignment of value to an entire free IP pool. o To a large corporation, $240 million is a nominal price. Supposing, there was no justified needs criterion, that would be a very attractive price for a speculator to pay in order to buy out the remaining IPv4 free pool, and thereby get a license to print money. > balance sheet. So, it is not acceptable to say folks are turning away > from it because ARIN is offering that space in a fair way. The free > pool is relevant. The free pool is relevant to ARIN, because it is a common resource that it is ARIN's responsibility to manage. You could say that it is relevant to ARIN, in the responsible management of the resource, for ARIN to impose costs, partitioning, and requirements, in order for registrations and delegations to be made from the community resource to private individuals: Otherwise; if any network participant were allowed to register as many free IP addresses as they like, you have a tragedy of the commons situation, where everyone's costs go up, the number of participants becomes limited, and the total utility of the IPv4 address space is reduced below its optimal level. > There is a case that the need-based policy has done well, and it has > done well for some. Comcast, for example, has 18 million subscribers One should first take note: this is the effect of changing policy over time. This is not a result of needs-based policy in general, it is a result of one specific implementation of needs-based policy. Furthermore, at one time needs-based policy included assignments of /8s, to organizations that would in all likelihood go on to never utilize a significant portion. > and 70 Million IPv4 addresses [3]. For simple math, we can call that > 3.8 addresses for every 1 customer. Then, you have a network like > Metro PCS who has 9 million subscribers (2.2 million of which are LTE) > [4] on what i can tell is 1,024 IPv4 addresses. Which is a > 0.000113778 IPv4 addresses per subscriber from ARIN. Yes; different network operators, have designed their networks with different ratios of IP addresses per subscriber required, through the use of IP address sharing mechanisms. This provides an increase in flexibility to the network operator, with the also potential benefit of requiring fewer IP addresses, and therefore -- being a more efficient consumer of IP address resources, Which could serve them well, after exhaustion, when someone might like to attempt to assign a dollar amount to the state of an IPv4 network allocation existing. > So, there are winners and losers in need-based. Winners puts more > time and money into the process, losers are busy optimizing other > parts of their business instead of working the ARIN system. Looking The next error, is characterization of more efficient users of IP resources as losers. Their networks have been around for a while, and obtaining IPv4 resources an option. We can infer that intuitively, the most likely reason they require few IPv4 resources is primarily an engineering choice, not exclusively any kind of reflection on the quality of ARIN policies. The characterization of "loser" presumes that they desired more IPv4 resources, and were forced to design their network in such way, when in fact, it may have been a choice -- based on future predictions and perceived future risks of IPv4 resource shortages. > back at [3], winners are also big companies with a lot of resource > and ... they probably send people to ARIN meetings and ... maybe they > even send lawyers to ARIN meetings. I don't know, i have never been > to an ARIN meeting myself. If you never attended an ARIN meeting; one could infer that your intuition is /not/ well-informed, and therefore, the chance that your blind guess is erroneous is more likely than not. Either way, the insinuation is unfair, because you didn't see who went to the ARIN meetings, or report any research showing any bearing or influence exactly 'big companies' may have had on policy development. > Now, there is more. Many organizations have found ARIN unsuitable for > their address needs. We know that in 2011 when the free pool was much > larger than it is now (4+ /8s?), Microsoft bought IPv4 space from a > bankruptcy court [6]. Amazon among others has also made substantial It should be noted, that Microsoft's acquisition of networks leading to them obtaining IPv4 resources, was done within the ARIN policy framework. Microsoft obtained IP address resources from ARIN, after satisfying ARIN, in regards to justified need; they would not have been able to purchase IP addresses directly, although they essentially did that indirectly. ARIN provided the mechanism they used. Furthermore, by preserving the free pool, it was beneficial to the community that Microsoft used this mechanism to obtained the resources, in order to preserve the free pool, by clearing the demand from the market (as well as unused resources), and therefore preserving the "liquidity" and ease of small IPv4 allocations provided by the free pool. > appear that Amazon and Microsoft could justify need, but the > need-based policy does not appear to work for them. I am aware of the Did you consider that maybe it works for them just fine, but it was easier to obtain the resources they wanted in sufficient number through the specified transfer process; where the burden of review practices (not just justified need) for a free pool allocation would be just slightly higher enough, that the bankruptcy presented a little bit of an opportunity ? > So, that is open market end of things, organizations pay millions of > dollars instead of thousands of dollars to not use a need-based policy > of the ARIN free pool. Seems like the symptom of something broken. You could say that the allocation from non-free-pool addresses could have been perceived as delivering additional value, or the person responsible for bidding could have made an error. Perhaps they had reasons for entering the transaction that have nothing to do with a "difference" between free pool addresses and specified transfer addresses. They may have preferred to /choose/ what IP addresses they would get, through contract, rather than virgin IP addresses (that might be in bogon filter lists) from a luck of the draw. Or there might have been some other special reason they wanted traffic towards what used to be Nortel IP addresses. Either way, the mechanism of the transaction cannot be safely assumed to be a result of a problem with justified needs policy. > In fact, last year i tried to get a /48 of address space for a lab > network attached to a T3 from TWT. They would not give me more than a > /56. I heard from another guy that Internap would only give him a > /64. Need-based is a trickled down disease on network design. That is not needs-based policy. That is a braindead private policy of your network service provider that has nothing to do with justified need policy implemented by ARIN. The criteria for IPv6 allocation is the "end site"; the /48. And the allowed PA allocations are sized accordingly. There is no such thing as a network not having justified need for at least 1 /48. > As previously noted, the ARIN free pool is a non-trivial sum of 24 > million IPv4 addresses. Yet, companies continue to buy addresses and The next error is that 24 million IPv4 addresses is a non-trivial sum. On the contrary, this is substantially less than 2% of the IPv4 address space. > NRPM and ARIN should get out of the business of telling people how to > number their networks, it has not helped the businesses or the NRPM doesn't specify how you number; it provides criteria for determining how large of an additional allocation you need right now. Anyways, of course... what ARIN should or should not do is non-fact. Various arguments can be made about what ARIN should or should not do. > 2. I have made the claim that ARIN's need-based policy has negatively > impacted system design, the specific system being the internet. The Your claim is abstract, and requires insinuation. Now, if you had interviewed someone at Microsoft or PCS, and obtained an explanation from a competent engineer about how ARIN rules pressured them into designing their network in a manner that was less than optimal, then that might be useful. > 3. By moving away from need based policy from ipv4, we accept reality > that the market rules Justified need is not a non-market situation. > [6]. IPv4 addresses are part of the means of > production in a capitalist society. Only in the same sense that Telephone numbers or Social security numbers are a means of production. It doesn't matter who you ask, you're only getting the one SSN that you need. And NANPA won't give you an infinite supply of phone numbers either, & usage reporting and allocation justification is required, even if you have infinite cash. > IPv4 addresses should not be acquired by playing some logic > game with people via ARIN tickets or intellectual thumb-wrestling > and posturing on PPML. ARIN policies and logical are simple and trivial, compared to the convoluted technical rules of most governments, and markets. The idea that there is a situation of "no logic games" in reality is an error. [snip] > _______________________________________________ > PPML [snip] -- -JH From mcr at sandelman.ca Thu Apr 11 09:26:21 2013 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 11 Apr 2013 09:26:21 -0400 Subject: [arin-ppml] The case against need based justification In-Reply-To: References: Message-ID: <25525.1365686781@sandelman.ca> >>>>> "Jimmy" == Jimmy Hess writes: Jimmy> o To a large corporation, $240 million is a nominal price. Jimmy> Supposing, there was no justified needs criterion, that would Jimmy> be a very attractive Jimmy> price for a speculator to pay in order to buy out the remaining Jimmy> IPv4 free pool, and Jimmy> thereby get a license to print money. Sounds good to me. Should drive significant IPv6 deployment. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From narten at us.ibm.com Fri Apr 12 00:53:04 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 12 Apr 2013 00:53:04 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201304120453.r3C4r42W002184@rotala.raleigh.ibm.com> Total of 117 messages in the last 7 days. script run at: Fri Apr 12 00:53:04 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.53% | 17 | 9.90% | 120146 | jcurran at arin.net 11.97% | 14 | 8.99% | 109109 | matthew at matthew.at 11.97% | 14 | 8.89% | 107863 | paul at redbarn.org 8.55% | 10 | 11.68% | 141750 | owen at delong.com 6.84% | 8 | 7.84% | 95208 | cb.list6 at gmail.com 5.98% | 7 | 5.18% | 62873 | farmer at umn.edu 2.56% | 3 | 6.47% | 78518 | mueller at syr.edu 2.56% | 3 | 5.55% | 67405 | sryerse at eclipse-networks.com 4.27% | 5 | 3.12% | 37869 | michael+ppml at burnttofu.net 4.27% | 5 | 2.80% | 33980 | snoble at sonn.com 4.27% | 5 | 2.66% | 32274 | bill at herrin.us 3.42% | 4 | 1.93% | 23389 | sethm at rollernet.us 0.85% | 1 | 4.21% | 51054 | dave at temk.in 1.71% | 2 | 2.81% | 34109 | bjones at vt.edu 2.56% | 3 | 1.60% | 19392 | gary.buhrmaster at gmail.com 0.85% | 1 | 2.77% | 33633 | heather.skanks at gmail.com 0.85% | 1 | 2.49% | 30273 | wesley.george at twcable.com 1.71% | 2 | 1.30% | 15818 | joelja at bogus.com 0.85% | 1 | 1.92% | 23284 | andrew.dul at quark.net 1.71% | 2 | 1.00% | 12171 | mcr at sandelman.ca 0.85% | 1 | 1.27% | 15354 | mysidia at gmail.com 0.85% | 1 | 0.96% | 11655 | adudek16 at gmail.com 0.85% | 1 | 0.88% | 10661 | cja at daydream.com 0.85% | 1 | 0.86% | 10384 | info at arin.net 0.85% | 1 | 0.84% | 10203 | ikiris at gmail.com 0.85% | 1 | 0.59% | 7176 | narten at us.ibm.com 0.85% | 1 | 0.54% | 6579 | bross at pobox.com 0.85% | 1 | 0.53% | 6489 | kkargel at polartel.com 0.85% | 1 | 0.41% | 5002 | john at egh.com --------+------+--------+----------+------------------------ 100.00% | 117 |100.00% | 1213621 | Total From scottleibrand at gmail.com Mon Apr 15 12:01:00 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 15 Apr 2013 09:01:00 -0700 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <516C121F.3050901@communicatefreely.net> References: <516C121F.3050901@communicatefreely.net> Message-ID: <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Tim, Thanks for bringing this up. It sounds like a real issue, which could use some policy work. Cross-posting to PPML, where such policy discussions occur. Scott On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" wrote: > Hello, > > We are a new ISP, and we have had some interesting dilemma's getting > started. I'm curious to know if this is something that has affected > others, or if I'm just in a strange situation. > > We are building out an access network to reach business customers in a > small town. We will probably never be very big, but we like are town > and are hoping to eventually extend our reach to most business in town. > When we started, we requested a /32 IPv6 from ARIN. We had to explain > what we were doing, and our coverage area, etc. This seems reasonable > and all, and eventually we got our /32. At this point, all we had was a > /28 IPv4 SWIP'd from an upstream, so our fees jumped from $0 to $1800 > for the year. > > Now we have a running network, with real customers, and we need IPv4 > allocations, since running IPv6 only for retail Internet is a bit > problematic. We tried to get a /24 out of our upstream, but they are > essentially out of address space and can't give us any. They can't get > any more either, because they just got taken over by a larger carrier > that has free pools, but on a different AS. > > We do have another upstream that we could connect to, but they can't > give us anything more than a /28 either. > > I applied for a /22 under the immediate need category, but I don't > qualify, since I can really only use about 2/3 of it within 30 days. > > So now I'm stuck with a customer base that has native IPv6 for everyone, > but only a /29 IPv4 to share between 12 offices and about 200 or so > retail WiFi users. I have to do crazy incoming NAT nonsense to support > my customers mail servers and VPN devices, and I'm crossing my fingers > that the wireless users don't do something stupid and get us all > blacklisted. > > Should there be an additional policy to deal with initial allocations > where efficient utilization of X number of IPv6 /64s would serve as > justification for a /22 IPv4, or perhaps some other scheme that makes it > a little easier for new ISPs. I understand that IPv4 is constrained, > but we aren't out of them yet, and a small ISP still needs an allocation > to function. > > Another alternative would be a new entrant policy similar to the > immediate need clause, but with the following changes: > -Only 50% must be used within 30 days > -ISP must demonstrate that IPv6 has been deployed to end users > -The same documentation of customer contracts and purchased equipment > would still apply. > > I look around and see the big incumbents with no IPv6 to speak of, yet > they have IPv4 for every customer. Here I am as the little startup > trying to make a go of it, but I'm at a serious disadvantage because I > can't get any address resources. > > Am I just terribly unlucky, or is this becoming a problem for others as > well? I think the main issue is that upstream providers aren't able to > hand out /24s like they used to, so showing a /23 equivalent from an > upstream is next to impossible now. > > Thanks! > -Tim > > -- > -- > Tim St. Pierre > System Operator > Communicate Freely > 289 225 1220 x5101 > tim at communicatefreely.net > www.communicatefreely.net > > _______________________________________________ > 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 info at arin.net if you experience any issues. From matthew at matthew.at Mon Apr 15 12:53:23 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 15 Apr 2013 09:53:23 -0700 Subject: [arin-ppml] The case against need based justification In-Reply-To: <25525.1365686781@sandelman.ca> References: <25525.1365686781@sandelman.ca> Message-ID: <516C3083.6050104@matthew.at> On 4/11/2013 6:26 AM, Michael Richardson wrote: > Sounds good to me. Should drive significant IPv6 deployment. Exactly my thought. Run it out ASAP, then we can stop talking about v4 here and get on to real problems. Matthew Kaufman From aaron at wholesaleinternet.net Mon Apr 15 12:58:40 2013 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Mon, 15 Apr 2013 11:58:40 -0500 Subject: [arin-ppml] The case against need based justification In-Reply-To: <516C3083.6050104@matthew.at> References: <25525.1365686781@sandelman.ca> <516C3083.6050104@matthew.at> Message-ID: <516C31C0.1050000@wholesaleinternet.net> What are these "real problems" we are ignoring? On 4/15/2013 11:53 AM, Matthew Kaufman wrote: > On 4/11/2013 6:26 AM, Michael Richardson wrote: >> Sounds good to me. Should drive significant IPv6 deployment. > > Exactly my thought. Run it out ASAP, then we can stop talking about v4 > here and get on to real problems. > > Matthew Kaufman > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From scottleibrand at gmail.com Mon Apr 15 16:17:50 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 15 Apr 2013 13:17:50 -0700 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Message-ID: Tim, I think this is an issue that is only going to get worse as IPv4 exhaustion makes upstream ISPs less willing to allocate large blocks of addresses to downstream customers. In such a situation, I think it is entirely appropriate to allow a downstream ISP, which has a customer base large enough to justify a /23 (and is allocating those customers ARIN-assigned IPv6 space) to also get approved for an IPv4 /22, and be eligible to acquire it on the transfer market if the ARIN free pool is exhausted. I would personally rather not liberalize 4.2.1.6. Immediate need, as that is supposed to be for "exceptional" cases, but perhaps adding a clause to the first bullet point of 4.2.2.2. Multihomed would be appropriate. Maybe something like "or demonstrate the assignment of IPv6 addresses to more than 500 devices"? Would that kind of policy help for a situation like yours? -Scott On Mon, Apr 15, 2013 at 9:01 AM, Scott Leibrand wrote: > Tim, > > Thanks for bringing this up. It sounds like a real issue, which could use > some policy work. Cross-posting to PPML, where such policy discussions > occur. > > Scott > > On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" > wrote: > > > Hello, > > > > We are a new ISP, and we have had some interesting dilemma's getting > > started. I'm curious to know if this is something that has affected > > others, or if I'm just in a strange situation. > > > > We are building out an access network to reach business customers in a > > small town. We will probably never be very big, but we like are town > > and are hoping to eventually extend our reach to most business in town. > > When we started, we requested a /32 IPv6 from ARIN. We had to explain > > what we were doing, and our coverage area, etc. This seems reasonable > > and all, and eventually we got our /32. At this point, all we had was a > > /28 IPv4 SWIP'd from an upstream, so our fees jumped from $0 to $1800 > > for the year. > > > > Now we have a running network, with real customers, and we need IPv4 > > allocations, since running IPv6 only for retail Internet is a bit > > problematic. We tried to get a /24 out of our upstream, but they are > > essentially out of address space and can't give us any. They can't get > > any more either, because they just got taken over by a larger carrier > > that has free pools, but on a different AS. > > > > We do have another upstream that we could connect to, but they can't > > give us anything more than a /28 either. > > > > I applied for a /22 under the immediate need category, but I don't > > qualify, since I can really only use about 2/3 of it within 30 days. > > > > So now I'm stuck with a customer base that has native IPv6 for everyone, > > but only a /29 IPv4 to share between 12 offices and about 200 or so > > retail WiFi users. I have to do crazy incoming NAT nonsense to support > > my customers mail servers and VPN devices, and I'm crossing my fingers > > that the wireless users don't do something stupid and get us all > > blacklisted. > > > > Should there be an additional policy to deal with initial allocations > > where efficient utilization of X number of IPv6 /64s would serve as > > justification for a /22 IPv4, or perhaps some other scheme that makes it > > a little easier for new ISPs. I understand that IPv4 is constrained, > > but we aren't out of them yet, and a small ISP still needs an allocation > > to function. > > > > Another alternative would be a new entrant policy similar to the > > immediate need clause, but with the following changes: > > -Only 50% must be used within 30 days > > -ISP must demonstrate that IPv6 has been deployed to end users > > -The same documentation of customer contracts and purchased equipment > > would still apply. > > > > I look around and see the big incumbents with no IPv6 to speak of, yet > > they have IPv4 for every customer. Here I am as the little startup > > trying to make a go of it, but I'm at a serious disadvantage because I > > can't get any address resources. > > > > Am I just terribly unlucky, or is this becoming a problem for others as > > well? I think the main issue is that upstream providers aren't able to > > hand out /24s like they used to, so showing a /23 equivalent from an > > upstream is next to impossible now. > > > > Thanks! > > -Tim > > > > -- > > -- > > Tim St. Pierre > > System Operator > > Communicate Freely > > 289 225 1220 x5101 > > tim at communicatefreely.net > > www.communicatefreely.net > > > > _______________________________________________ > > 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 info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Mon Apr 15 16:18:27 2013 From: heather.skanks at gmail.com (Heather Schiller) Date: Mon, 15 Apr 2013 16:18:27 -0400 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Message-ID: The second upstream that says they can't give more than a /28 either -- did they give an explanation? It sounds like you qualify for space.. does the second provider also not have space to allocate? The free pool isn't out yet.. the problems at the first provider that was just bought out aside -- your other provider should still be able to get address space from ARIN and allocate to you. The rules/requirements haven't really changed -- just the window of time they can get space for has changed. That aside, I'm in favor of the idea of allocating/justifying PI v4 space to folks with a v6 deployment. I'd like to hear more about how common a problem this is. --Heather On Mon, Apr 15, 2013 at 12:01 PM, Scott Leibrand wrote: > Tim, > > Thanks for bringing this up. It sounds like a real issue, which could use > some policy work. Cross-posting to PPML, where such policy discussions > occur. > > Scott > > On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" > wrote: > > > Hello, > > > > We are a new ISP, and we have had some interesting dilemma's getting > > started. I'm curious to know if this is something that has affected > > others, or if I'm just in a strange situation. > > > > We are building out an access network to reach business customers in a > > small town. We will probably never be very big, but we like are town > > and are hoping to eventually extend our reach to most business in town. > > When we started, we requested a /32 IPv6 from ARIN. We had to explain > > what we were doing, and our coverage area, etc. This seems reasonable > > and all, and eventually we got our /32. At this point, all we had was a > > /28 IPv4 SWIP'd from an upstream, so our fees jumped from $0 to $1800 > > for the year. > > > > Now we have a running network, with real customers, and we need IPv4 > > allocations, since running IPv6 only for retail Internet is a bit > > problematic. We tried to get a /24 out of our upstream, but they are > > essentially out of address space and can't give us any. They can't get > > any more either, because they just got taken over by a larger carrier > > that has free pools, but on a different AS. > > > > We do have another upstream that we could connect to, but they can't > > give us anything more than a /28 either. > > > > I applied for a /22 under the immediate need category, but I don't > > qualify, since I can really only use about 2/3 of it within 30 days. > > > > So now I'm stuck with a customer base that has native IPv6 for everyone, > > but only a /29 IPv4 to share between 12 offices and about 200 or so > > retail WiFi users. I have to do crazy incoming NAT nonsense to support > > my customers mail servers and VPN devices, and I'm crossing my fingers > > that the wireless users don't do something stupid and get us all > > blacklisted. > > > > Should there be an additional policy to deal with initial allocations > > where efficient utilization of X number of IPv6 /64s would serve as > > justification for a /22 IPv4, or perhaps some other scheme that makes it > > a little easier for new ISPs. I understand that IPv4 is constrained, > > but we aren't out of them yet, and a small ISP still needs an allocation > > to function. > > > > Another alternative would be a new entrant policy similar to the > > immediate need clause, but with the following changes: > > -Only 50% must be used within 30 days > > -ISP must demonstrate that IPv6 has been deployed to end users > > -The same documentation of customer contracts and purchased equipment > > would still apply. > > > > I look around and see the big incumbents with no IPv6 to speak of, yet > > they have IPv4 for every customer. Here I am as the little startup > > trying to make a go of it, but I'm at a serious disadvantage because I > > can't get any address resources. > > > > Am I just terribly unlucky, or is this becoming a problem for others as > > well? I think the main issue is that upstream providers aren't able to > > hand out /24s like they used to, so showing a /23 equivalent from an > > upstream is next to impossible now. > > > > Thanks! > > -Tim > > > > -- > > -- > > Tim St. Pierre > > System Operator > > Communicate Freely > > 289 225 1220 x5101 > > tim at communicatefreely.net > > www.communicatefreely.net > > > > _______________________________________________ > > 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 info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Apr 15 17:37:15 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 15 Apr 2013 14:37:15 -0700 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <516C62CA.50807@communicatefreely.net> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <516C62CA.50807@communicatefreely.net> Message-ID: Would you be interested in submitting a policy proposal to address the issue? If so, just fill out the short template at https://www.arin.net/policy/pdp_appendix_b.html and submit it to policy at arin.net (and Cc: arin-ppml at arin.net if you want it posted here). I (and likely several other AC members) would also be happy to help if you're unsure about anything. Once you propose a policy change, the AC assigns shepherds to work directly with you, verifies that the topic is in scope and has a clearly defined problem statement / rationale (or works with you to clarify it), and then if it meets those requirements, accepts it as a draft policy to be discussed at an upcoming policy meeting. Thanks for participating in improving ARIN's policies. I'm looking forward to hopefully working with you more in the near future. -Scott On Mon, Apr 15, 2013 at 1:27 PM, Tim St. Pierre wrote: > Hi Scott, > > Yes, if that clause were added, I would have my allocation by the end of > the week. In fact, in my immediate need application attempt, I was able to > document that I was actively providing connectivity to over 500 devices. > > The silly thing about requiring the /23 first, is that I have to somehow > find a /23, assign it, then get my /22 and give back the /23. A lot of > nuisance for customers with static assignments and more work than it ought > to be, since I can meet the spirit of the policy, just not the letter of it. > > Thanks! > > -Tim > > > On 13-04-15 04:17 PM, Scott Leibrand wrote: > > Tim, > > I think this is an issue that is only going to get worse as IPv4 > exhaustion makes upstream ISPs less willing to allocate large blocks of > addresses to downstream customers. In such a situation, I think it is > entirely appropriate to allow a downstream ISP, which has a customer base > large enough to justify a /23 (and is allocating those customers > ARIN-assigned IPv6 space) to also get approved for an IPv4 /22, and be > eligible to acquire it on the transfer market if the ARIN free pool is > exhausted. I would personally rather not liberalize 4.2.1.6. Immediate > need, as that is supposed to be for "exceptional" cases, but perhaps adding > a clause to the first bullet point of 4.2.2.2. Multihomed would be > appropriate. Maybe something like "or demonstrate the assignment of IPv6 > addresses to more than 500 devices"? > > Would that kind of policy help for a situation like yours? > > -Scott > > > On Mon, Apr 15, 2013 at 9:01 AM, Scott Leibrand wrote: > >> Tim, >> >> Thanks for bringing this up. It sounds like a real issue, which could use >> some policy work. Cross-posting to PPML, where such policy discussions >> occur. >> >> Scott >> >> On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" >> wrote: >> >> > Hello, >> > >> > We are a new ISP, and we have had some interesting dilemma's getting >> > started. I'm curious to know if this is something that has affected >> > others, or if I'm just in a strange situation. >> > >> > We are building out an access network to reach business customers in a >> > small town. We will probably never be very big, but we like are town >> > and are hoping to eventually extend our reach to most business in town. >> > When we started, we requested a /32 IPv6 from ARIN. We had to explain >> > what we were doing, and our coverage area, etc. This seems reasonable >> > and all, and eventually we got our /32. At this point, all we had was a >> > /28 IPv4 SWIP'd from an upstream, so our fees jumped from $0 to $1800 >> > for the year. >> > >> > Now we have a running network, with real customers, and we need IPv4 >> > allocations, since running IPv6 only for retail Internet is a bit >> > problematic. We tried to get a /24 out of our upstream, but they are >> > essentially out of address space and can't give us any. They can't get >> > any more either, because they just got taken over by a larger carrier >> > that has free pools, but on a different AS. >> > >> > We do have another upstream that we could connect to, but they can't >> > give us anything more than a /28 either. >> > >> > I applied for a /22 under the immediate need category, but I don't >> > qualify, since I can really only use about 2/3 of it within 30 days. >> > >> > So now I'm stuck with a customer base that has native IPv6 for everyone, >> > but only a /29 IPv4 to share between 12 offices and about 200 or so >> > retail WiFi users. I have to do crazy incoming NAT nonsense to support >> > my customers mail servers and VPN devices, and I'm crossing my fingers >> > that the wireless users don't do something stupid and get us all >> > blacklisted. >> > >> > Should there be an additional policy to deal with initial allocations >> > where efficient utilization of X number of IPv6 /64s would serve as >> > justification for a /22 IPv4, or perhaps some other scheme that makes it >> > a little easier for new ISPs. I understand that IPv4 is constrained, >> > but we aren't out of them yet, and a small ISP still needs an allocation >> > to function. >> > >> > Another alternative would be a new entrant policy similar to the >> > immediate need clause, but with the following changes: >> > -Only 50% must be used within 30 days >> > -ISP must demonstrate that IPv6 has been deployed to end users >> > -The same documentation of customer contracts and purchased equipment >> > would still apply. >> > >> > I look around and see the big incumbents with no IPv6 to speak of, yet >> > they have IPv4 for every customer. Here I am as the little startup >> > trying to make a go of it, but I'm at a serious disadvantage because I >> > can't get any address resources. >> > >> > Am I just terribly unlucky, or is this becoming a problem for others as >> > well? I think the main issue is that upstream providers aren't able to >> > hand out /24s like they used to, so showing a /23 equivalent from an >> > upstream is next to impossible now. >> > >> > Thanks! >> > -Tim >> > >> > -- >> > -- >> > Tim St. Pierre >> > System Operator >> > Communicate Freely >> > 289 225 1220 x5101 >> > tim at communicatefreely.net >> > www.communicatefreely.net >> > >> > _______________________________________________ >> > 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 info at arin.net if you experience any issues. >> > > > > -- > -- > Tim St. Pierre > System Operator > Communicate Freely289 225 1220 x5101tim at communicatefreely.netwww.communicatefreely.net > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Apr 15 17:38:46 2013 From: bill at herrin.us (William Herrin) Date: Mon, 15 Apr 2013 17:38:46 -0400 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Message-ID: > On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" wrote: >> Now we have a running network, with real customers, and we need IPv4 >> allocations, since running IPv6 only for retail Internet is a bit >> problematic. We tried to get a /24 out of our upstream, but they are >> essentially out of address space and can't give us any. They can't get >> any more either, because they just got taken over by a larger carrier >> that has free pools, but on a different AS. >> >> We do have another upstream that we could connect to, but they can't >> give us anything more than a /28 either. >> >> I applied for a /22 under the immediate need category, but I don't >> qualify, since I can really only use about 2/3 of it within 30 days. Hi Tim, If an IPv4 address market is going to work *at all* then it will work for this situation. It looks like you drew the short straw and get to be the guinea pig. Find someone with a /24 willing to sell and acquire it under NRPM 8.3. And document the heck out of the process so that your experience can guide the next policy changes around the IPv4 market concept. At a practical level, push your ISP harder too. By which I mean the salesmen, not the tech staff. They have upstreams too, and one of them has a /24 available for multihoming use. You may have to pay for the extra work acquiring it, but they *can* get it for you. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Mon Apr 15 17:57:51 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 15 Apr 2013 14:57:51 -0700 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Message-ID: On Mon, Apr 15, 2013 at 2:38 PM, William Herrin wrote: > > On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" > wrote: > >> Now we have a running network, with real customers, and we need IPv4 > >> allocations, since running IPv6 only for retail Internet is a bit > >> problematic. We tried to get a /24 out of our upstream, but they are > >> essentially out of address space and can't give us any. They can't get > >> any more either, because they just got taken over by a larger carrier > >> that has free pools, but on a different AS. > >> > >> We do have another upstream that we could connect to, but they can't > >> give us anything more than a /28 either. > >> > >> I applied for a /22 under the immediate need category, but I don't > >> qualify, since I can really only use about 2/3 of it within 30 days. > > Hi Tim, > > If an IPv4 address market is going to work *at all* then it will work > for this situation. It looks like you drew the short straw and get to > be the guinea pig. Find someone with a /24 willing to sell and acquire > it under NRPM 8.3. And document the heck out of the process so that > your experience can guide the next policy changes around the IPv4 > market concept. > If he can't qualify for space from ARIN, how is he going to qualify to receive space via transfer? The requirements are the same (with the exception of 3-month vs. 24-month need, which isn't the limiting factor here). And the minimum allocation size for ISPs is /22 per NRPM 4.2.2.2: only end-users can get /24's from ARIN (or via transfer), under NRPM 4.3.2.2. > At a practical level, push your ISP harder too. By which I mean the > salesmen, not the tech staff. They have upstreams too, and one of them > has a /24 available for multihoming use. You may have to pay for the > extra work acquiring it, but they *can* get it for you. > Agreed, this is likely the most expeditious path forward. You'll need two /24s to qualify for a /22 under current policy. If your upstreams still refuse to allocate them to you, you might be able to find a third party willing to do so. They typically refer to it as "leasing", but under ARIN policy it's just another form of reallocation. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Mon Apr 15 18:09:29 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 15 Apr 2013 15:09:29 -0700 Subject: [arin-ppml] The case against need based justification In-Reply-To: <516C31C0.1050000@wholesaleinternet.net> References: <25525.1365686781@sandelman.ca> <516C3083.6050104@matthew.at> <516C31C0.1050000@wholesaleinternet.net> Message-ID: <516C7A99.4080604@matthew.at> On 4/15/2013 9:58 AM, Aaron Wendel wrote: > What are these "real problems" we are ignoring? > > ISPs trying to get smaller than /32 of IPv6 from ARIN in order to save a few bucks? Matthew Kaufman From matthew at matthew.at Mon Apr 15 18:13:11 2013 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 15 Apr 2013 15:13:11 -0700 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Message-ID: <516C7B77.9030700@matthew.at> On 4/15/2013 2:38 PM, William Herrin wrote: >> On Apr 15, 2013, at 7:43 AM, "Tim St. Pierre" wrote: >>> Now we have a running network, with real customers, and we need IPv4 >>> allocations, since running IPv6 only for retail Internet is a bit >>> problematic. We tried to get a /24 out of our upstream, but they are >>> essentially out of address space and can't give us any. They can't get >>> any more either, because they just got taken over by a larger carrier >>> that has free pools, but on a different AS. >>> >>> We do have another upstream that we could connect to, but they can't >>> give us anything more than a /28 either. >>> >>> I applied for a /22 under the immediate need category, but I don't >>> qualify, since I can really only use about 2/3 of it within 30 days. > Hi Tim, > > If an IPv4 address market is going to work *at all* then it will work > for this situation. Well, the IPv4 market won't work if we enforce the same needs rules on transfers as we do on new allocations. > It looks like you drew the short straw and get to > be the guinea pig. Find someone with a /24 willing to sell and acquire > it under NRPM 8.3. And document the heck out of the process so that > your experience can guide the next policy changes around the IPv4 > market concept. If he went to the transfer market, he'd want to get at least a /22 and probably a lot more (so that he doesn't need to take the risk of going back repeatedly). But the stupid thing is that ARIN's rules that keep him from getting a /22 from ARIN also disqualify him from being a transfer recipient for enough space for justify raising the money to buy space. Matthew Kaufman From bill at herrin.us Mon Apr 15 19:00:08 2013 From: bill at herrin.us (William Herrin) Date: Mon, 15 Apr 2013 19:00:08 -0400 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Message-ID: On Mon, Apr 15, 2013 at 5:57 PM, Scott Leibrand wrote: > On Mon, Apr 15, 2013 at 2:38 PM, William Herrin wrote: >> If an IPv4 address market is going to work *at all* then it will work >> for this situation. It looks like you drew the short straw and get to >> be the guinea pig. Find someone with a /24 willing to sell and acquire >> it under NRPM 8.3. And document the heck out of the process so that >> your experience can guide the next policy changes around the IPv4 >> market concept. > > If he can't qualify for space from ARIN, how is he going to qualify to > receive space via transfer? The requirements are the same (with the > exception of 3-month vs. 24-month need, which isn't the limiting factor > here). And the minimum allocation size for ISPs is /22 per NRPM 4.2.2.2: > only end-users can get /24's from ARIN (or via transfer), under NRPM > 4.3.2.2. Hi John, Can you comment on this? Are ISPs able to receive /24 and /23 blocks via NRPM 8.3 transfers? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From ppml at rs.seastrom.com Tue Apr 16 07:27:29 2013 From: ppml at rs.seastrom.com (Rob Seastrom) Date: Tue, 16 Apr 2013 07:27:29 -0400 Subject: [arin-ppml] [arin-discuss] IPv6 as justification for IPv4? In-Reply-To: <516C121F.3050901@communicatefreely.net> (Tim St. Pierre's message of "Mon, 15 Apr 2013 10:43:43 -0400") References: <516C121F.3050901@communicatefreely.net> Message-ID: <86ppxuiula.fsf@valhalla.seastrom.com> "Tim St. Pierre" writes: > I applied for a /22 under the immediate need category, but I don't > qualify, since I can really only use about 2/3 of it within 30 days. Something seems wrong here. I've filled out an immediate need request or two in my time and had the luxury of being constrained by devices that want address pools (LNSes, CMTSes) so I can round up to the next power of 2. I will note for Mr. St. Pierre's benefit that it is possible that he misread the reason for his denial - the bar for supporting documentation is extraordinarily high in an immediate need application, since one is substituting a big pile of paperwork for one's slow start utilization record that is normally used to justify space. Assuming that Mr. St. Pierre didn't misread his reason for denial, I'm a bit confused. Once upon a time, Immediate Need was a one-size-fits-all /20. That got fixed to be an appropriate sized block some years ago (see https://www.arin.net/policy/proposals/2007_9.html for details). Is ARIN staff currently interpreting NRPM 4.2.1.6 to mean that immediate need can only be demonstrated for exact powers of two, with 100% utilization immediately? Has the 80% rule somehow gotten applied here? This would seem to me to be the wrong test to apply. When I authored 2007-9 I assumed that Staff would evaluate immediate need and issue the smallest aggregate that would cover the number of addresses justified for immediate use. Without commenting on Mr. St. Pierre's particular case, could ARIN staff comment on whether current policy is creating a problem at the low size end of the justification window (i.e., is the fully filled /23 a problem when an ISP can not get a /23 under current policy?) or is being interpreted to mean only exact precise powers of two, no more and no less, and any other perceived inadequacies in the current immediate need policy? I am not in favor of using IPv6 utilization as a justification for IPv4 addresses at this time. I am however in favor of smoking out whether 4.2.1.6 needs to be revisited. -r From scottleibrand at gmail.com Tue Apr 16 20:44:14 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 16 Apr 2013 17:44:14 -0700 Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: <2ABC191402431F42867832ECFA921CB514B2FB96@sky-mb1.skycomp.local> References: <8DA1853CE466B041B104C1CAEE00B3748FB81737@CHAXCH01.corp.arin.net> <33B5C85E-9CB9-4902-A30F-CEF81D666474@la-broadband.com> <8DA1853CE466B041B104C1CAEE00B3748FB82023@CHAXCH01.corp.arin.net> <3F3069E7-2167-49A0-AE2E-3F9C4CAA556D@la-broadband.com> <94B488F6-30D4-4DF7-8D80-B2041588096B@delong.com> <205888087.220513.1366085190001.JavaMail.root@network1.net> <49D0CA78-CAA8-4D6E-80E4-FE237F006929@la-broadband.com> <2034009167.221693.1366096028800.JavaMail.root@network1.net> <87B4EB04-B774-4AFD-B1A2-83796F117375@la-broadband.com> <8DA1853CE466B041B104C1CAEE00B3748FB93023@CHAXCH01.corp.arin.net> <516D7CF4.1050508@umn.edu> <553DDA40-CE75-408E-9AB4-66F25720D1CB@corp.arin.net> <9534c6e12e6f26d26fac9fb23c314633@robertmarder.com> <928F9EF76967CE4A9E9524585CCDF60507D3CF2287@P1MBX05.HMC1.COMCAST.NET> <2ABC191402431F42867832ECFA921CB514B2 FB96@sky-mb1.skycomp.local> Message-ID: (Moving this over to a new thread on PPML to discuss the policy aspects...) Serge, Do you have any other ideas for how to justify that an ISP really needs a /22 from the free pool, that would be easier than getting PA, using it, and then remembering? Or, let's say you could get a /22 from the transfer market with minimal justification (just that you're an actual network operator, say). Would it have been worth your while to pay market price for the addresses and avoid the application and renumbering hassles? Scott On Apr 16, 2013, at 4:36 PM, "Serge Paquin" wrote: > As for the Barrier to Entry; I don't believe it is the fees so much (The fee was not our issue at all) as the very hard time to justify the initial /22 allocation. Until you already have space swiped to you from your ISP and in production you can't get a direct assignment since you can't prove need. > > Then when you get your allocation you have a timeframe to renumber your now production clients into the new space and hand back your ISP allocated space. > > We did this a couple years ago and it was a major undertaking in additional costs of staff, tech support and scheduling to work with each client to renumber. > > It was a business decision that we'd be a more stable and healthy company having our own IP space and set forth with that goal in mind and accepted the cost but it was a lot more than the ARIN fees. > > I do have to say that the ARIN support staff were helpful and we had no issues dealing with them. We just had to meet all the criteria before they could issue us a direct allocation of course. > > Serge. > From rcarpen at network1.net Tue Apr 16 21:05:00 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 16 Apr 2013 21:05:00 -0400 (EDT) Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: References: <516D7CF4.1050508@umn.edu> <553DDA40-CE75-408E-9AB4-66F25720D1CB@corp.arin.net> <9534c6e12e6f26d26fac9fb23c314633@robertmarder.com> <928F9EF76967CE4A9E9524585CCDF60507D3CF2287@P1MBX05.HMC1.COMCAST.NET> <2ABC191402431F42867832ECFA921CB514B2FB96@sky-mb1.skycomp.local> Message-ID: <181563816.226343.1366160700304.JavaMail.root@network1.net> I think the criteria should be: 1. Be an ISP with *any* amount of space from an upstream 2. Be able to justify a 3-month need for a /22 3. Have upstream ISPs that refuse to hand out any more PA space (which appears to be the rule rather than the exception now) (I'm not sure how one would go about proving this, but I have seen situations where the upstream would likely write a letter of support) 4. Be forced to take an automatic IPv6 allocation (at whatever NRPM-supported size is appropriate (preferably /32 min.)) I also think this should be expanded to being able to get a larger initial allocation if you can justify the need. e.g. if an ISP has a /20 from an upstream, but has a justified need for a /18, they should be able to jump right to the /18 without having to get the /20 first. This would reduce the amount of work needed. thanks, -Randy ----- Original Message ----- > (Moving this over to a new thread on PPML to discuss the policy aspects...) > > Serge, > > Do you have any other ideas for how to justify that an ISP really needs a /22 > from the free pool, that would be easier than getting PA, using it, and then > remembering? > > Or, let's say you could get a /22 from the transfer market with minimal > justification (just that you're an actual network operator, say). Would it > have been worth your while to pay market price for the addresses and avoid > the application and renumbering hassles? > > Scott > > On Apr 16, 2013, at 4:36 PM, "Serge Paquin" wrote: > > > As for the Barrier to Entry; I don't believe it is the fees so much (The > > fee was not our issue at all) as the very hard time to justify the initial > > /22 allocation. Until you already have space swiped to you from your ISP > > and in production you can't get a direct assignment since you can't prove > > need. > > > > Then when you get your allocation you have a timeframe to renumber your now > > production clients into the new space and hand back your ISP allocated > > space. > > > > We did this a couple years ago and it was a major undertaking in additional > > costs of staff, tech support and scheduling to work with each client to > > renumber. > > > > It was a business decision that we'd be a more stable and healthy company > > having our own IP space and set forth with that goal in mind and accepted > > the cost but it was a lot more than the ARIN fees. > > > > I do have to say that the ARIN support staff were helpful and we had no > > issues dealing with them. We just had to meet all the criteria before > > they could issue us a direct allocation of course. > > > > Serge. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From jcurran at arin.net Tue Apr 16 22:09:17 2013 From: jcurran at arin.net (John Curran) Date: Wed, 17 Apr 2013 02:09:17 +0000 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> On Apr 15, 2013, at 5:00 PM, William Herrin wrote: > On Mon, Apr 15, 2013 at 5:57 PM, Scott Leibrand wrote: >> >> If he can't qualify for space from ARIN, how is he going to qualify to >> receive space via transfer? The requirements are the same (with the >> exception of 3-month vs. 24-month need, which isn't the limiting factor >> here). And the minimum allocation size for ISPs is /22 per NRPM 4.2.2.2: >> only end-users can get /24's from ARIN (or via transfer), under NRPM >> 4.3.2.2. > > Hi John, > > Can you comment on this? Are ISPs able to receive /24 and /23 blocks > via NRPM 8.3 transfers? Bill - The ISP must demonstrate the need for IPv4 address resources under ARIN standard allocation policies (i.e. a single-homed ISP showing need for a /20 or multi-homed ISP showing need for a /22) in order to qualify to receive resources via transfer. Once qualified, we can approve the transfer of IPv4 space; this can be to a maximum of their documented need based on their current utilization rate extended 24 months out, and down to a minimum of a single /24 (as /24 is the explicit minimum transfer size specified in NRPM 8.3) FYI, /John John Curran President and CEO ARIN From serge at skycomp.ca Tue Apr 16 22:33:37 2013 From: serge at skycomp.ca (Serge Paquin) Date: Wed, 17 Apr 2013 02:33:37 +0000 Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FB81737@CHAXCH01.corp.arin.net> <33B5C85E-9CB9-4902-A30F-CEF81D666474@la-broadband.com> <8DA1853CE466B041B104C1CAEE00B3748FB82023@CHAXCH01.corp.arin.net> <3F3069E7-2167-49A0-AE2E-3F9C4CAA556D@la-broadband.com> <94B488F6-30D4-4DF7-8D80-B2041588096B@delong.com> <205888087.220513.1366085190001.JavaMail.root@network1.net> <49D0CA78-CAA8-4D6E-80E4-FE237F006929@la-broadband.com> <2034009167.221693.1366096028800.JavaMail.root@network1.net> <87B4EB04-B774-4AFD-B1A2-83796F117375@la-broadband.com> <8DA1853CE466B041B104C1CAEE00B3748FB93023@CHAXCH01.corp.arin.net> <516D7CF4.1050508@umn.edu> <553DDA40-CE75-408E-9AB4-66F25720D1CB@corp.arin.net> <9534c6e12e6f26d26fac9fb23c314633@robertmarder.com> <928F9EF76967CE4A9E9524585CCDF60507D3CF2287@P1MBX05.HMC1.COMCAST.NET> <2ABC191402431F42867832ECFA921CB514B2FB96@sky-mb1.skycomp.local> Message-ID: <2ABC191402431F42867832ECFA921CB514B30AEE@sky-mb1.skycomp.local> Scott, To be honest I hadn't thought of it. Since before being an ARIN member I was not familiar at all with the policy creation process. Once an ARIN member I've stayed on the discuss list to try and get familiar, but hadn't really thought about the process until the current thread. As for the transfer market to be honest I don't know what the market price is. Doing a quick search it seems to be $10 to $20 per IP so no I don't think I would want to drop $22k on IP space as a small startup. Heck that's more than the biggest ISP's in the world pay for all their IP space. That is not a long term investment (in theory) as IPv6 adoption grows. My first thought would be having a /24 allocation min rather than /22, but issuing on /22 boundaries so as a member grew you could issue them the adjacent space while not increasing the BGP table size. Once confirming their legal entity as well as the Upstream ASN they will BGP Peer with a /24 should be relatively straight forward to get. I realize that there are likely other factors which I'm not aware of which could make my suggestion problematic. The issue with the current system is that at the start your destiny is strongly tied to the whim of your upstream and how much IP space they will give you and what they will potentially charge for it. As well you have to plan from the start on an IP renumbering for your installed client base which is disruptive internally and to your customers. The barrier to entry for new companies I don't believe should be so high. It seems to be a system to discourage ARIN membership and have small ISP's / Datacenters get their IP space directly from their upstream ISP which potentially reduces redundancy (Multi-homing) as well locks the company into a single upstream which can then dictate price since they own the IP space. Serge. -----Original Message----- From: Scott Leibrand [mailto:scottleibrand at gmail.com] Sent: Tuesday, April 16, 2013 8:44 PM To: Serge Paquin; ARIN-PPML List Subject: Justifying an ISP /22 (Moving this over to a new thread on PPML to discuss the policy aspects...) Serge, Do you have any other ideas for how to justify that an ISP really needs a /22 from the free pool, that would be easier than getting PA, using it, and then remembering? Or, let's say you could get a /22 from the transfer market with minimal justification (just that you're an actual network operator, say). Would it have been worth your while to pay market price for the addresses and avoid the application and renumbering hassles? Scott On Apr 16, 2013, at 4:36 PM, "Serge Paquin" wrote: > As for the Barrier to Entry; I don't believe it is the fees so much (The fee was not our issue at all) as the very hard time to justify the initial /22 allocation. Until you already have space swiped to you from your ISP and in production you can't get a direct assignment since you can't prove need. > > Then when you get your allocation you have a timeframe to renumber your now production clients into the new space and hand back your ISP allocated space. > > We did this a couple years ago and it was a major undertaking in additional costs of staff, tech support and scheduling to work with each client to renumber. > > It was a business decision that we'd be a more stable and healthy company having our own IP space and set forth with that goal in mind and accepted the cost but it was a lot more than the ARIN fees. > > I do have to say that the ARIN support staff were helpful and we had no issues dealing with them. We just had to meet all the criteria before they could issue us a direct allocation of course. > > Serge. > From bill at herrin.us Wed Apr 17 00:08:14 2013 From: bill at herrin.us (William Herrin) Date: Wed, 17 Apr 2013 00:08:14 -0400 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> Message-ID: On Tue, Apr 16, 2013 at 10:09 PM, John Curran wrote: > The ISP must demonstrate the need for IPv4 address resources under > ARIN standard allocation policies (i.e. a single-homed ISP showing > need for a /20 or multi-homed ISP showing need for a /22) in order > to qualify to receive resources via transfer. Once qualified, we > can approve the transfer of IPv4 space; this can be to a maximum > of their documented need based on their current utilization rate > extended 24 months out, and down to a minimum of a single /24 (as > /24 is the explicit minimum transfer size specified in NRPM 8.3) Thanks John. So, what would folks think of a policy adjustment along these lines: "Add to: 8.3 Conditions on recipient of the transfer: * Minimum address block size qualifications defined in section 4 do not apply to transfers to specified recipients." 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 arin.net Wed Apr 17 01:06:55 2013 From: jcurran at arin.net (John Curran) Date: Wed, 17 Apr 2013 05:06:55 +0000 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FB9B01F@CHAXCH01.corp.arin.net> On Apr 16, 2013, at 10:08 PM, William Herrin wrote: > On Tue, Apr 16, 2013 at 10:09 PM, John Curran wrote: >> The ISP must demonstrate the need for IPv4 address resources under >> ARIN standard allocation policies (i.e. a single-homed ISP showing >> need for a /20 or multi-homed ISP showing need for a /22) in order >> to qualify to receive resources via transfer. Once qualified, we >> can approve the transfer of IPv4 space; this can be to a maximum >> of their documented need based on their current utilization rate >> extended 24 months out, and down to a minimum of a single /24 (as >> /24 is the explicit minimum transfer size specified in NRPM 8.3) > > Thanks John. > > So, what would folks think of a policy adjustment along these lines: > > "Add to: 8.3 Conditions on recipient of the transfer: > > * Minimum address block size qualifications defined in section 4 do > not apply to transfers to specified recipients." Bill - You are suggesting a policy change, but I'm unsure what you are trying to accomplish in terms of a goal (and hence the text you suggest may not be the most logical place to accomplish it.) The anchor in NRPM 8.3 is the following text: "The recipient must demonstrate the need for up to a 24-month supply of IP address resources under current ARIN policies and sign an RSA." I would generally recommend against putting a reference requiring compliance to "need... under current ARIN policies" and then cutting particular pieces of those policies out in subsequent statements Note - we'll implement whatever is adopted, but doing so as you suggest has a high risk of multiple interpretations and/or member confusion when the try to decode the result. If the intent is that their maximum transfer brings their total IPv4 holdings which meets their anticipated needs for IPv4 address space for 24 months, then you might want to drop the current reference to the allocation policy and simply state the intended maximum in plain language. I do not know if I've addressed your question, and will note that the elected ARIN AC excels at doing this sort of language (if you want to submit a problem statement to the ARIN AC and work with them on it...) I hope this helps answer your question! /John John Curran President and CEO ARIN From owen at delong.com Wed Apr 17 11:59:46 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Apr 2013 09:59:46 -0600 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> Message-ID: <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> On Apr 16, 2013, at 10:08 PM, William Herrin wrote: > On Tue, Apr 16, 2013 at 10:09 PM, John Curran wrote: >> The ISP must demonstrate the need for IPv4 address resources under >> ARIN standard allocation policies (i.e. a single-homed ISP showing >> need for a /20 or multi-homed ISP showing need for a /22) in order >> to qualify to receive resources via transfer. Once qualified, we >> can approve the transfer of IPv4 space; this can be to a maximum >> of their documented need based on their current utilization rate >> extended 24 months out, and down to a minimum of a single /24 (as >> /24 is the explicit minimum transfer size specified in NRPM 8.3) > > Thanks John. > > So, what would folks think of a policy adjustment along these lines: > > "Add to: 8.3 Conditions on recipient of the transfer: > > * Minimum address block size qualifications defined in section 4 do > not apply to transfers to specified recipients." What problem do you think that would solve? In the current case being discussed, it isn't the block size minimums he is having a problem with, it is the amount he can get SWIPd vs. the inability to qualify under immediate need. IMHO, the correct fix is to modify the pre-existing space requirements so as to allow documented need to substitute for SWIP'd space. Owen From farmer at umn.edu Wed Apr 17 12:38:01 2013 From: farmer at umn.edu (David Farmer) Date: Wed, 17 Apr 2013 11:38:01 -0500 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> Message-ID: <516ECFE9.3070600@umn.edu> On 4/17/13 10:59 , Owen DeLong wrote: > > On Apr 16, 2013, at 10:08 PM, William Herrin wrote: > >> On Tue, Apr 16, 2013 at 10:09 PM, John Curran wrote: >>> The ISP must demonstrate the need for IPv4 address resources under >>> ARIN standard allocation policies (i.e. a single-homed ISP showing >>> need for a /20 or multi-homed ISP showing need for a /22) in order >>> to qualify to receive resources via transfer. Once qualified, we >>> can approve the transfer of IPv4 space; this can be to a maximum >>> of their documented need based on their current utilization rate >>> extended 24 months out, and down to a minimum of a single /24 (as >>> /24 is the explicit minimum transfer size specified in NRPM 8.3) >> >> Thanks John. >> >> So, what would folks think of a policy adjustment along these lines: >> >> "Add to: 8.3 Conditions on recipient of the transfer: >> >> * Minimum address block size qualifications defined in section 4 do >> not apply to transfers to specified recipients." > > What problem do you think that would solve? > > In the current case being discussed, it isn't the block size minimums he > is having a problem with, it is the amount he can get SWIPd vs. the > inability to qualify under immediate need. > > IMHO, the correct fix is to modify the pre-existing space requirements > so as to allow documented need to substitute for SWIP'd space. > > Owen I'll just add; The new PDP requires Policy Proposals to have "a clear statement of the problem with existing Internet number resource policy". I'd like to suggest, with the new PDP it may be more fruitful for us to change our habits and try to focus pre-proposal discussions on honing a common understanding of the problem statement rather than honing policy text as we have frequently done in the past. I believe that if we clearly define the problem in its correct context then finding the correct text to solve that problem will likely be much easier. I'm not saying we shouldn't discuss policy text, but that policy text without a clear problem statement may not be helpful. That said, good policy text can sometimes help people understand the problem. So, I believe there is a problem here, I'm just not sure we have a clear definition of the problem that is trying to be solved, yet. And, in this case the policy text you propose isn't helping me understand the problem any better, if anything it has confused the problem for me. Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From springer at inlandnet.com Wed Apr 17 13:48:15 2013 From: springer at inlandnet.com (John Springer) Date: Wed, 17 Apr 2013 10:48:15 -0700 (PDT) Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> Message-ID: On Wed, 17 Apr 2013, Owen DeLong wrote: > > In the current case being discussed, it isn't the block size minimums he > is having a problem with, it is the amount he can get SWIPd vs. the > inability to qualify under immediate need. > > IMHO, the correct fix is to modify the pre-existing space requirements > so as to allow documented need to substitute for SWIP'd space. > > Owen > Agree John Springer From springer at inlandnet.com Wed Apr 17 13:55:24 2013 From: springer at inlandnet.com (John Springer) Date: Wed, 17 Apr 2013 10:55:24 -0700 (PDT) Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <516ECFE9.3070600@umn.edu> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> <516ECFE9.3070600@umn.edu> Message-ID: Inline On Wed, 17 Apr 2013, David Farmer wrote: > On 4/17/13 10:59 , Owen DeLong wrote: >> >> On Apr 16, 2013, at 10:08 PM, William Herrin wrote: >> >>> On Tue, Apr 16, 2013 at 10:09 PM, John Curran wrote: >>>> The ISP must demonstrate the need for IPv4 address resources under >>>> ARIN standard allocation policies (i.e. a single-homed ISP showing >>>> need for a /20 or multi-homed ISP showing need for a /22) in order >>>> to qualify to receive resources via transfer. Once qualified, we >>>> can approve the transfer of IPv4 space; this can be to a maximum >>>> of their documented need based on their current utilization rate >>>> extended 24 months out, and down to a minimum of a single /24 (as >>>> /24 is the explicit minimum transfer size specified in NRPM 8.3) >>> >>> Thanks John. >>> >>> So, what would folks think of a policy adjustment along these lines: >>> >>> "Add to: 8.3 Conditions on recipient of the transfer: >>> >>> * Minimum address block size qualifications defined in section 4 do >>> not apply to transfers to specified recipients." >> >> What problem do you think that would solve? >> >> In the current case being discussed, it isn't the block size minimums he >> is having a problem with, it is the amount he can get SWIPd vs. the >> inability to qualify under immediate need. >> >> IMHO, the correct fix is to modify the pre-existing space requirements >> so as to allow documented need to substitute for SWIP'd space. >> >> Owen > > I'll just add; The new PDP requires Policy Proposals to have "a clear > statement of the problem with existing Internet number resource policy". I'd > like to suggest, with the new PDP it may be more fruitful for us to change > our habits and try to focus pre-proposal discussions on honing a common > understanding of the problem statement rather than honing policy text as we > have frequently done in the past. > > I believe that if we clearly define the problem in its correct context then > finding the correct text to solve that problem will likely be much easier. > I'm not saying we shouldn't discuss policy text, but that policy text without > a clear problem statement may not be helpful. That said, good policy text > can sometimes help people understand the problem. > > So, I believe there is a problem here, I'm just not sure we have a clear > definition of the problem that is trying to be solved, yet. And, in this > case the policy text you propose isn't helping me understand the problem any > better, if anything it has confused the problem for me. Paste from arin-discuss, from an exchange between Owen and Randy Carpenter >> I think the real problem here is requiring pre-existing PA space of >> certain amounts as the initial test. The combination of a customer >> base, need, and efficient utilization of any PA space is probably the >> better test. > This is something that I believe really needs fixed (and needs to be > fixed very quickly). > -Randy This seems to be rather far along to a problem statement. I agree with both statements. John Springer From otis at ocosa.com Wed Apr 17 17:41:03 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Wed, 17 Apr 2013 16:41:03 -0500 Subject: [arin-ppml] Justifying an ISP /22 Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AE@ocsbs.ocosa.com> Jumping on ppml late.. Randy, >1. Be an ISP with *any* amount of space from an upstream I'm not so sure this would be advisable? Wouldn't it be better to have at least a /24? Or is this what you had in mind? >2. Be able to justify a 3-month need for a /22 >3. Have upstream ISPs that refuse to hand out any more PA space (which appears to be the rule rather than the exception now) (I'm not sure how one would go about proving this, but I have seen situations where the upstream would likely write a letter of support) >4. Be forced to take an automatic IPv6 allocation (at whatever NRPM-supported size is appropriate (preferably /32 min.)) I agree with the /32 minimum. I remember when we became an ARIN member we had 1 /24 PA and 1 /23 PA plus we were multi-homed so we could justify the /22. We actually had an ASN first then we got our first allocation about 1 month later. Either way, renumbering was not that bad but still could have been avoided with what you are proposing. - Otis From rcarpen at network1.net Wed Apr 17 18:11:45 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 17 Apr 2013 18:11:45 -0400 (EDT) Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AE@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AE@ocsbs.ocosa.com> Message-ID: <1410088997.229897.1366236705981.JavaMail.root@network1.net> ----- Original Message ----- > Jumping on ppml late.. > > Randy, > > >1. Be an ISP with *any* amount of space from an upstream > > I'm not so sure this would be advisable? Wouldn't it be better to have > at least a /24? Or is this what you had in mind? A /24 would not be too much of a hurdle, so that would be fine. Most of the frustrating examples I have seen are small ISPs that have a /22 or a /21, but are not multi-homed. They are expanding to the point of needing more space, e.g. they have a /21, but need a /20. They don't already have a /20, so they can't get the /20. The upstream ISP will not issue them any more space. I have seen this on several occasions. Some have chosen to get multi-homed, but for some, multi-homing (at least to different upstreams) is not possible. Looking at the NRPM more closely, I think it would be pretty a simple to have a policy change that simply reduced the amount of PA space required for a single-homed ISP to /24, but also require justification for a full /22. Basically, even the playing field for single-home and multi-home, since there is now a situation where ARIN has available address space, but upstream ISPs seem not to have (or unwilling to provide). The one situation that is still left hanging by this is a brand new ISP, which can not get any PI space at all, since they have no upstream space yet. It may be as hard for them to get new PA space as it is existing ISPs to get additional PA space. I understand the intent of the current NRPM, which is to prevent every Joe Wannabe with a day-old certificate of incorporation from snagging up space that they may never actually use. However, when if reach the point that upstream ISPs across the board refuse to hand out any space at all, and there is still space in ARIN's free pool, I think that may need to be revisited as well. I don't think we are quite there yet (assuming we make the previously mentioned changes to only require a /24 of PA space). -Randy From otis at ocosa.com Wed Apr 17 18:49:08 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Wed, 17 Apr 2013 17:49:08 -0500 Subject: [arin-ppml] Justifying an ISP /22 Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AF@ocsbs.ocosa.com> Reply inline -----Original Message----- From: Randy Carpenter [mailto:rcarpen at network1.net] Sent: Wednesday, April 17, 2013 5:12 PM To: Otis L. Surratt, Jr. Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Justifying an ISP /22 ----- Original Message ----- > Jumping on ppml late.. > > Randy, > > >1. Be an ISP with *any* amount of space from an upstream > > I'm not so sure this would be advisable? Wouldn't it be better to have > at least a /24? Or is this what you had in mind? >A /24 would not be too much of a hurdle, so that would be fine. Most of the frustrating examples I have seen are small ISPs that have a /22 or a /21, but are not multi-homed. They are expanding to the point >of needing more space, e.g. they have a /21, but need a /20. They don't already have a /20, so they can't get the /20. The upstream ISP will not issue them any more space. I have seen this on several >occasions. I've seen this as well. In particular, was involving moving from /20 range to /19. That seems to be the case with many of the stories I hear. >Some have chosen to get multi-homed, but for some, multi-homing (at least to different upstreams) is not possible. This is always a tough one. Because it costs money to bring in a separate pipe. But one could simple fix this by colocating gear in a neutral carrier data center and speaking BGP. By use of PTP or tunnels to get it back to your POP. But that defeats the point of redundancy but it achieves multi-homing to satisfy policy. But couldn't those ISPs with those issues simply explain their situation and I'm sure ARIN could work with them? >Looking at the NRPM more closely, I think it would be pretty a simple to have a policy change that simply reduced the amount of PA space required for a single-homed ISP to /24, but also require justification >for a full /22. Basically, even the playing field for single-home and multi-home, since there is now a situation where ARIN has available address space, but upstream ISPs seem not to have (or unwilling to >provide). But couldn't you just adjust the language to account for dual-homing to the single ISP? The /24 PA would help out. >The one situation that is still left hanging by this is a brand new ISP, which can not get any PI space at all, since they have no upstream space yet. It may be as hard for them to get new PA space as it is >existing ISPs to get additional PA space. This can be a tough one... But it could be fixed by having the applicant submit copies of contract with an ISP(s) and their request for PA. This is the same approach that is done for ASNs I believe if you are not yet multihomed. From mysidia at gmail.com Wed Apr 17 20:14:18 2013 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 17 Apr 2013 19:14:18 -0500 Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: <181563816.226343.1366160700304.JavaMail.root@network1.net> References: <516D7CF4.1050508@umn.edu> <553DDA40-CE75-408E-9AB4-66F25720D1CB@corp.arin.net> <9534c6e12e6f26d26fac9fb23c314633@robertmarder.com> <928F9EF76967CE4A9E9524585CCDF60507D3CF2287@P1MBX05.HMC1.COMCAST.NET> <2ABC191402431F42867832ECFA921CB514B2FB96@sky-mb1.skycomp.local> <181563816.226343.1366160700304.JavaMail.root@network1.net> Message-ID: On 4/16/13, Randy Carpenter wrote: [snip] > 3. Have upstream ISPs that refuse to hand out any more PA space (which > appears to be the rule rather than the exception now) (I'm not sure how one > would go about proving this, but I have seen situations where the upstream > would likely write a letter of support) [snip] So the concern is... if ARIN adopts a policy allowing additional IP addresses to be acquired specifically if the ISP refuses to allocate them to satisfy the justified need; ARIN could essentially be encouraging the ISP to collude with the subscriber, and refuse to allocate. Because the service provider's benefits of refusing increase then; they can still provide the subscriber service, after refusing them IP addresses (thanks to the subscriber's suddenly gained ability to get addresses through ARIN). The subscriber receives benefit of (1), the space they want, and (2) the addresses in PI format, which is more desirable. The benefit the ISP receives is (1) they conserve what PA space they still have available, for use with higher evenue, or applications where the allocation requirement cannot be offloaded. (2) they might still in some cases be "inadvertently" using that subscriber's service to justify certain future allocations. -- -JH From rcarpen at network1.net Wed Apr 17 20:51:56 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 17 Apr 2013 20:51:56 -0400 (EDT) Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: References: <9534c6e12e6f26d26fac9fb23c314633@robertmarder.com> <928F9EF76967CE4A9E9524585CCDF60507D3CF2287@P1MBX05.HMC1.COMCAST.NET> <2ABC191402431F42867832ECFA921CB514B2FB96@sky-mb1.skycomp.local> <181563816.226343.1366160700304.JavaMail.root@network1.net> Message-ID: <2023553541.230275.1366246316728.JavaMail.root@network1.net> ----- Original Message ----- > On 4/16/13, Randy Carpenter wrote: > [snip] > > 3. Have upstream ISPs that refuse to hand out any more PA space (which > > appears to be the rule rather than the exception now) (I'm not sure how one > > would go about proving this, but I have seen situations where the upstream > > would likely write a letter of support) > [snip] Yeah, that part is a little too specific, and I would say unnecessary, provided proper re-working of the other parts. (lowering to a /22 from a /20 is the big one) > So the concern is... if ARIN adopts a policy allowing additional IP > addresses to be acquired specifically if the ISP refuses to allocate > them to satisfy the justified need; ARIN could essentially be > encouraging the ISP to collude with the subscriber, and refuse to > allocate. I think there is almost the same incentive for collusion now: Upstream: "I'll give you a /20 for a month (just log enough for you to get PI space from ARIN)" ISP: "Sounds good. I'll put it in production on some dynamic IP customers, for which changing is easy" Upstream: "Here ya go." ISP: "Thanks, I'm now done with it" Upstream: Rinse, repeat. This is all perfectly within the policies of the NRPM as far as I can tell. I have been party to very similar conversations before. I have always looked (and continue to) for ways of accomplishing the desired result without resorting to such a situation. -Randy From owen at delong.com Wed Apr 17 23:38:09 2013 From: owen at delong.com (Owen DeLong) Date: Wed, 17 Apr 2013 21:38:09 -0600 Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AE@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AE@ocsbs.ocosa.com> Message-ID: On Apr 17, 2013, at 3:41 PM, "Otis L. Surratt, Jr." wrote: > Jumping on ppml late.. > > Randy, > >> 1. Be an ISP with *any* amount of space from an upstream > > I'm not so sure this would be advisable? Wouldn't it be better to have > at least a /24? Or is this what you had in mind? > In at least one case, part of the problem is he can't even get a /24 from his upstreams. This will become a more and more prevalent problem as runout continues to progress. >> 2. Be able to justify a 3-month need for a /22 >> 3. Have upstream ISPs that refuse to hand out any more PA space (which > appears to be the rule rather than the exception now) (I'm not sure how > one would go about proving this, but I have seen situations where the > upstream would likely write a letter of support) I'm not sure we need to include this as a criteria anyway. >> 4. Be forced to take an automatic IPv6 allocation (at whatever > NRPM-supported size is appropriate (preferably /32 min.)) I'm not sure I buy this, either. As much as I support IPv6 and favor increased IPv6 rollout (the sooner we're off v4 the better we will all be), I don't believe that inflicting IPv6 allocations on people that aren't ready to ask for them does anything other than skew statistics. Owen > From farmer at umn.edu Thu Apr 18 14:58:06 2013 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Apr 2013 13:58:06 -0500 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> <516ECFE9.3070600@umn.edu> Message-ID: <5170423E.9010700@umn.edu> On 4/17/13 12:55 , John Springer wrote: > > Paste from arin-discuss, from an exchange between Owen and Randy Carpenter > >>> I think the real problem here is requiring pre-existing PA space of >>> certain amounts as the initial test. The combination of a customer >>> base, need, and efficient utilization of any PA space is probably the >>> better test. > >> This is something that I believe really needs fixed (and needs to be >> fixed very quickly). > >> -Randy > > This seems to be rather far along to a problem statement. I agree with > both statements. > > John Springer While not policy text this is still more about the solution than the problem. There needs to be more about why "requiring pre-existing PA" creates undesirable results for example, or how current policy effects new ISPs businesses in undesirable ways. A problem statement needs to motivate why change is necessary as well as how to solve it. So, what's wrong with the current policy? Not just what should the new policy look like. In the above I mostly only see what should the new policy look like and almost nothing about issues created by the current policy. Thanks -- ================================================ David Farmer Email: farmer at umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From lar at mwtcorp.net Thu Apr 18 16:29:19 2013 From: lar at mwtcorp.net (lar at mwtcorp.net) Date: Thu, 18 Apr 2013 14:29:19 -0600 Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <5170423E.9010700@umn.edu> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> <516ECFE9.3070600@umn.edu> <5170423E.9010700@umn.edu> Message-ID: On Thu, 18 Apr 2013 13:58:06 -0500 David Farmer wrote: > On 4/17/13 12:55 , John Springer wrote: >> >> Paste from arin-discuss, from an exchange between Owen and Randy Carpenter >> >>>> I think the real problem here is requiring pre-existing PA space of >>>> certain amounts as the initial test. The combination of a customer >>>> base, need, and efficient utilization of any PA space is probably the >>>> better test. >> >>> This is something that I believe really needs fixed (and needs to be >>> fixed very quickly). >> >>> -Randy >> >> This seems to be rather far along to a problem statement. I agree with >> both statements. >> >> John Springer > > While not policy text this is still more about the solution than the >problem. There needs to be more about why "requiring pre-existing PA" >creates undesirable results for example, or how current policy effects new >ISPs businesses in undesirable ways. A problem statement needs to motivate >why change is necessary as well as how to solve it. So, what's wrong with >the current policy? Not just what should the new policy look like. In the >above I mostly only see what should the new policy look like and almost >nothing about issues created by the current policy. The current problem is that the amount of PA space a "new" ISP has is becoming more a function of the amount of available PI space the upstream provider has at his disposal, than it is the need or size of the ISP. In rural settings switching providers or multi-homing may not be economically possible because of distance or access to needed infrastructure. I have seen this first hand as a small upstream. I cannot qualify for more PI space because I don't meet the 80% rule, (It's quite difficult if all you have is a /20) and due to restructuring and careful use of IP I have been able to do without additional IP for a number of years. From ARIN's perspective my 3-month usage rate is 0. I am also an upstream for two WISP's each with aprox 1000-1500 customers. They can easily justify a /22. Each one would be 25% of my total PI space. I can't do it and they can't qualify for their own PI space because I could only squeeze out /24 to each. > > Thanks > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. Larry Ash Network Administrator Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From otis at ocosa.com Thu Apr 18 17:21:19 2013 From: otis at ocosa.com (Otis L. Surratt, Jr.) Date: Thu, 18 Apr 2013 16:21:19 -0500 Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: References: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AE@ocsbs.ocosa.com> Message-ID: <5FE1FB6D43B8A647BBC821840C1AEA8B0185C2@ocsbs.ocosa.com> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, April 17, 2013 10:38 PM To: Otis L. Surratt, Jr. Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Justifying an ISP /22 On Apr 17, 2013, at 3:41 PM, "Otis L. Surratt, Jr." wrote: > Jumping on ppml late.. > > Randy, > >> 1. Be an ISP with *any* amount of space from an upstream > > I'm not so sure this would be advisable? Wouldn't it be better to have > at least a /24? Or is this what you had in mind? > >>In at least one case, part of the problem is he can't even get a /24 from his upstreams. This will become a more and more prevalent problem as runout continues to progress. I see your point and that is a concern as well. So, as runout continues do you think it would be advisable to accept any PA space as Randy suggested? >> 4. Be forced to take an automatic IPv6 allocation (at whatever > NRPM-supported size is appropriate (preferably /32 min.)) >>I'm not sure I buy this, either. As much as I support IPv6 and favor increased >>IPv6 rollout (the sooner we're off v4 the better we will all be), I don't believe that inflicting IPv6 allocations on people that aren't ready to ask for them does anything other than skew statistics. I see the point here also. I think most that take an IPv6 allocation don't immediately deploy so the statistics could be skewed anyway? New networks should have the mind set of IPv6 anyway but I agree forcing doesn't seem like the best way but then again... Otis From springer at inlandnet.com Thu Apr 18 17:38:40 2013 From: springer at inlandnet.com (John Springer) Date: Thu, 18 Apr 2013 14:38:40 -0700 (PDT) Subject: [arin-ppml] IPv6 as justification for IPv4? In-Reply-To: <5170423E.9010700@umn.edu> References: <516C121F.3050901@communicatefreely.net> <4300218B-DF10-41C1-9057-D067F94B3ECE@gmail.com> <8DA1853CE466B041B104C1CAEE00B3748FB98582@CHAXCH01.corp.arin.net> <8E6D77B8-6F6A-42DD-A775-EE135E1FAD61@delong.com> <516ECFE9.3070600@umn.edu> <5170423E.9010700@umn.edu> Message-ID: OK, I'll bite. On Thu, 18 Apr 2013, David Farmer wrote: > On 4/17/13 12:55 , John Springer wrote: >> >> Paste from arin-discuss, from an exchange between Owen and Randy Carpenter >> >>>> I think the real problem here is requiring pre-existing PA space of >>>> certain amounts as the initial test. The combination of a customer >>>> base, need, and efficient utilization of any PA space is probably the >>>> better test. >> >>> This is something that I believe really needs fixed (and needs to be >>> fixed very quickly). >> >>> -Randy >> >> This seems to be rather far along to a problem statement. I agree with >> both statements. >> >> John Springer > Thanks to Tim St. Pierre. Any contextual defects are mine. > While not policy text this is still more about the solution than the problem. I take it that you refer to this: >>>> I think the real problem here is requiring pre-existing PA space of >>>> certain amounts as the initial test. Do you think that "Current policy requiring pre-existing PA creates undesirable results such as that cited by OP at: http://lists.arin.net/pipermail/arin-discuss/2013-April/002531.html" is a superior construction? > There needs to be more about why "requiring pre-existing PA" creates > undesirable results for example, or how current policy effects new ISPs > businesses in undesirable ways. Perhaps something along the line of: OP, in his post on arin-discuss cited above, details the following reasons "why "requiring pre-existing PA" creates undesirable results". 1) ...we requested a /32 IPv6 from ARIN. We had to explain what we were doing, and our coverage area, etc. This seems reasonable and all, and eventually we got our /32. At this point, all we had was a /28 IPv4 SWIP'd from an upstream, so our fees jumped from $0 to $1800 for the year. 2) Now we have a running network, with real customers, and we need IPv4 allocations, since running IPv6 only for retail Internet is a bit problematic. We tried to get a /24 out of our upstream, but they are essentially out of address space and can't give us any. They can't get any more either, because they just got taken over by a larger carrier that has free pools, but on a different AS. We do have another upstream that we could connect to, but they can't give us anything more than a /28 either. 3) I applied for a /22 under the immediate need category, but I don't qualify, since I can really only use about 2/3 of it within 30 days. 4) So now I'm stuck with a customer base that has native IPv6 for everyone, but only a /29 IPv4 to share between 12 offices and about 200 or so retail WiFi users. I have to do crazy incoming NAT nonsense to support my customers mail servers and VPN devices, and I'm crossing my fingers that the wireless users don't do something stupid and get us all blacklisted. Is this enough or do we need more? There _IS_ more from OP and others. > A problem statement needs to motivate why > change is necessary as well as how to solve it. I don't think this is correct. When we were working with the author of 3GPP, we left the details of the solution to the AC and concentrated on the problem statement. I think the new PDP requires this. > So, what's wrong with the current policy? See above and we can sure re-read discuss and ppml for more ammo, if needed. > Not just what should the new policy look like. Which is cart before the horse right here, correct? Have I eliminated that? > In the above > I mostly only see what should the new policy look like and almost nothing > about issues created by the current policy. Have I fixed that now? I tried to restrict myself to "issues created by the current policy" and no "what should the new policy look like"? Did I succeed? John Springer > > Thanks > > -- > ================================================ > David Farmer Email: farmer at umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ================================================ > > From mje at posix.co.za Thu Apr 18 19:22:03 2013 From: mje at posix.co.za (Mark Elkins) Date: Fri, 19 Apr 2013 01:22:03 +0200 Subject: [arin-ppml] ARIN 31 travel Message-ID: <1366327323.7677.5.camel@mjelap.posix.co.za> Not sure how appropriate this is but... Just arrived at the Hilton Barbados. Taxi fare is US$21.00 and there will be a Hotel Rep with sign board with your name on a list just as you are about to exit the Airport. They'll write out a receipt and should find a Taxi for you. -- . . ___. .__ Posix Systems - (South) Africa /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6147 bytes Desc: not available URL: From scottleibrand at gmail.com Thu Apr 18 19:36:25 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 18 Apr 2013 16:36:25 -0700 Subject: [arin-ppml] ARIN 31 travel In-Reply-To: <1366327323.7677.5.camel@mjelap.posix.co.za> References: <1366327323.7677.5.camel@mjelap.posix.co.za> Message-ID: Thanks, Mark. Good info. I look forward to seeing you (all) sometime after I arrive tomorrow evening. It's worth noting that additional arrival information is published at https://www.arin.net/participate/meetings/ARIN-31/hotel.html, which also has a link to a mailing list "for use by meeting registrants wishing to connect with the family or guests of other registrants in order to plan outside activities during ARIN meeting hours or evenings", which seems perfect for follow-ups on this topic. I just subscribed. :-) -Scott On Thu, Apr 18, 2013 at 4:22 PM, Mark Elkins wrote: > Not sure how appropriate this is but... > > Just arrived at the Hilton Barbados. Taxi fare is US$21.00 and there > will be a Hotel Rep with sign board with your name on a list just as > you are about to exit the Airport. They'll write out a receipt and > should find a Taxi for you. > -- > . . ___. .__ Posix Systems - (South) Africa > /| /| / /__ mje at posix.co.za - Mark J Elkins, Cisco CCIE > / |/ |ARK \_/ /__ LKINS Tel: +27 12 807 0590 Cell: +27 82 601 0496 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Apr 19 00:53:03 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 19 Apr 2013 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201304190453.r3J4r3Hp025149@rotala.raleigh.ibm.com> Total of messages in the last 7 days. script run at: Fri Apr 19 00:53:03 EDT 2013 From owen at delong.com Fri Apr 19 03:09:46 2013 From: owen at delong.com (Owen DeLong) Date: Fri, 19 Apr 2013 00:09:46 -0700 Subject: [arin-ppml] Justifying an ISP /22 In-Reply-To: <5FE1FB6D43B8A647BBC821840C1AEA8B0185C2@ocsbs.ocosa.com> References: <5FE1FB6D43B8A647BBC821840C1AEA8B0185AE@ocsbs.ocosa.com> <5FE1FB6D43B8A647BBC821840C1AEA8B0185C2@ocsbs.ocosa.com> Message-ID: <2CCFD327-72C4-4CAF-A2B3-B43A873CBDB9@delong.com> On Apr 18, 2013, at 14:21 , "Otis L. Surratt, Jr." wrote: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, April 17, 2013 10:38 PM > To: Otis L. Surratt, Jr. > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Justifying an ISP /22 > > > On Apr 17, 2013, at 3:41 PM, "Otis L. Surratt, Jr." > wrote: > >> Jumping on ppml late.. >> >> Randy, >> >>> 1. Be an ISP with *any* amount of space from an upstream >> >> I'm not so sure this would be advisable? Wouldn't it be better to have > >> at least a /24? Or is this what you had in mind? >> > >>> In at least one case, part of the problem is he can't even get a /24 > from his upstreams. This will become a more and more prevalent problem > as runout continues to progress. > > I see your point and that is a concern as well. So, as runout continues > do you think it would be advisable to accept any PA space as Randy > suggested? > I think it would be better to simply eliminate the PA space requirement and simply require documented need. > >>> 4. Be forced to take an automatic IPv6 allocation (at whatever >> NRPM-supported size is appropriate (preferably /32 min.)) > >>> I'm not sure I buy this, either. As much as I support IPv6 and favor > increased >>> IPv6 rollout (the sooner we're off v4 the better we will all be), I > don't believe that inflicting IPv6 allocations on people that aren't > ready to ask for them does anything other than skew statistics. > > I see the point here also. I think most that take an IPv6 allocation > don't immediately deploy so the statistics could be skewed anyway? > New networks should have the mind set of IPv6 anyway but I agree forcing > doesn't seem like the best way but then again... Sure, but I don't see force-feeding as helping that situation. At least if they asked for it, it's a case of they intended to do something with it or felt that there was some benefit to having it. Owen From narten at us.ibm.com Fri Apr 19 07:03:55 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 19 Apr 2013 07:03:55 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201304191103.r3JB3tLq026352@rotala.raleigh.ibm.com> Total of 35 messages in the last 7 days. script run at: Fri Apr 19 07:03:55 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 17.14% | 6 | 26.73% | 79053 | scottleibrand at gmail.com 8.57% | 3 | 7.79% | 23040 | springer at inlandnet.com 8.57% | 3 | 7.13% | 21076 | rcarpen at network1.net 8.57% | 3 | 6.75% | 19976 | bill at herrin.us 8.57% | 3 | 6.09% | 18006 | otis at ocosa.com 8.57% | 3 | 5.32% | 15721 | matthew at matthew.at 5.71% | 2 | 5.82% | 17228 | farmer at umn.edu 5.71% | 2 | 4.69% | 13862 | jcurran at arin.net 5.71% | 2 | 4.45% | 13163 | owen at delong.com 2.86% | 1 | 5.87% | 17370 | heather.skanks at gmail.com 2.86% | 1 | 4.62% | 13652 | mje at posix.co.za 2.86% | 1 | 3.15% | 9311 | serge at skycomp.ca 2.86% | 1 | 2.76% | 8154 | lar at mwtcorp.net 2.86% | 1 | 2.58% | 7627 | narten at us.ibm.com 2.86% | 1 | 2.28% | 6739 | mysidia at gmail.com 2.86% | 1 | 2.17% | 6428 | ppml at rs.seastrom.com 2.86% | 1 | 1.81% | 5358 | aaron at wholesaleinternet.net --------+------+--------+----------+------------------------ 100.00% | 35 |100.00% | 295764 | Total From narten at us.ibm.com Fri Apr 19 07:07:07 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 19 Apr 2013 07:07:07 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201304191107.r3JB77Tw015588@cichlid.raleigh.ibm.com> Total of messages in the last 7 days. script run at: Fri Apr 19 07:07:07 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ --------+------+--------+----------+------------------------ From narten at us.ibm.com Fri Apr 26 00:53:03 2013 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 26 Apr 2013 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201304260453.r3Q4r3dZ014664@rotala.raleigh.ibm.com> Total of 4 messages in the last 7 days. script run at: Fri Apr 26 00:53:03 EDT 2013 Messages | Bytes | Who --------+------+--------+----------+------------------------ 75.00% | 3 | 72.08% | 18535 | narten at us.ibm.com 25.00% | 1 | 27.92% | 7181 | owen at delong.com --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 25716 | Total From info at arin.net Mon Apr 29 14:23:09 2013 From: info at arin.net (ARIN) Date: Mon, 29 Apr 2013 14:23:09 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - April 2013 Message-ID: <517EBA8D.5070206@arin.net> In accordance with the ARIN Policy Development Process the ARIN Advisory Council (AC) held a meeting on 24 April 2013 and made decisions about several draft policies. The AC moved the following draft policy to last call (it will be posted separately to last call): Recommended Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement The following remain on the AC's docket: Recommended Draft Policy ARIN-2013-1: Section 8.4 Inter-RIR Transfers of ASNs Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy The AC abandoned the following: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs The AC provided the following statement: "Based on the community's input at ARIN 31 and on PPML the Advisory Council has abandoned ARIN-2013-3: Tiny IPv6 Allocations for ISPs. There was broad community consensus that /40 ISP allocations are technically undesirable, and that any desire for lower fees should be resolved within the fee structure itself, rather than by adapting policy to fit the current fee table." The AC abandoned ARIN-2013-3. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Apr 29 14:23:42 2013 From: info at arin.net (ARIN) Date: Mon, 29 Apr 2013 14:23:42 -0400 Subject: [arin-ppml] LAST CALL - Recommended Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement Message-ID: <517EBAAE.60508@arin.net> The ARIN Advisory Council (AC) met on 24 April 2013 and decided to send the following draft policy to last call: Recommended Draft Policy ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 13 May 2013. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2012-2 IPv6 Subsequent Allocations Utilization Requirement Date: 26 March 2013 AC's assessment of conformance with the Principles of Internet Number Resource Policy: Policy 2012-2 enables fair and impartial resource administration by creating an additional criteria under which LIRs can qualify for a subsequent allocation. This policy does not modify the definition of who is covered under the existing policy. This proposal addresses a technical blindspot in the existing subsequent allocation policy that limits initial IPv6 deployment growth. Over the last year, there has been significant community support on the mailing list and at meetings to rectify this blindspot. Coming to an agreement on specific wording that does not open this to abuse has been more difficult. Policy statement: The change to the NRPM is the addition of the third bullet in 6.5.3.b. 2.14. Serving Site (IPv6) When applied to IPv6 policies, the term serving site shall mean a location where an ISP terminates or aggregates customer connections, including, but, not limited to Points of Presence (POPs), Datacenters, Central or Local switching office or regional or local combinations thereof. 6.5.3. Subsequent Allocations to LIRs a. Where possible ARIN will make subsequent allocations by expanding the existing allocation. b. An LIR qualifies for a subsequent allocation if they meet any of the following criteria: * Shows utilization of 75% or more of their total address space * Shows utilization of more than 90% of any serving site * Has allocated more than 90% of their total address space to serving sites, with the block size allocated to each serving site being justified based on the criteria specified in section 6.5.2 c. If ARIN can not expand one or more existing allocations, ARIN shall make a new allocation based on the initial allocation criteria above. The LIR is encouraged, but not required to renumber into the new allocation over time and return any allocations no longer in use. d. If an LIR has already reached a /12 or more, ARIN will allocate a single additional /12 rather than continue expanding nibble boundaries. Rationale/Problem Statement: Subnet expansion may occur rapidly and unevenly in the early stages of IPv6 deployment. Providers may find that they have put all of their subnets/serving sites into service, and do not have enough space to add an additional serving site. They may have plenty of space available within subnets to make customer assignments, but can not turn up a new location (eg city, pop). Timetable for implementation: Immediately From info at arin.net Mon Apr 29 14:24:16 2013 From: info at arin.net (ARIN) Date: Mon, 29 Apr 2013 14:24:16 -0400 Subject: [arin-ppml] ARIN-prop-186 Section 8.2 Reorganizations - Notice of intent to make editorial update Message-ID: <517EBAD0.6030504@arin.net> The ARIN Advisory Council (AC) met on 24 April 2013 and requested that the following proposed editorial update to the Number Resource Policy Manual (NRPM) be posted for review by the community. The AC provided the following statement: ---- "Having reviewed ARIN-prop-186 'Section 8.2 Reorganizations' the AC believes that the requested change is editorial in nature. This decision is based on the facts that the author of the current text did not intend to remove reorganizations, that ARIN's operational procedure will not change based on this update, as they currently consider reorganizations to be valid. It was pointed out by staff that unless the term were reintroduced into policy, their operational procedure may have to change accordingly. Based on this position, the ARIN AC proposes that the following editorial change be made to the NRPM: Re-insert the word 'reorganization' into section 8.2; the resulting text will read: "ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions, and reorganizations under the following conditions: ..." Please voice any concerns to the AC as soon as possible." ---- The process for editorial updates to the NRPM is found in Part One, Section 3.1, paragraph 3 of the PDP: "Changes to policy that are purely editorial and non-substantial in nature are outside the scope of the full Policy Development Process and may only be made with 30 days public notice followed by the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees that the changes are non-substantial in nature." The review period will close on 29 May 2013. ARIN-prop-186 is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Policy Proposal Name: Section 8.2 Reorganizations Proposal Originator: John Springer Date: 23 April 2013 Problem Statement: There is no longer a reference to corporate reorganizations in the policy. ARIN often sees corporate reorganizations as the basis for transfer. Corporate reorganizations were part of the previous version of 8.2 policy as follows: "ARIN will consider requests for the transfer of number resources only upon receipt of evidence that the new entity has acquired the assets which had, as of the date of the acquisition or proposed reorganization, justified the current entity's use of the number resource." Current policy reads: "ARIN will consider requests for the transfer of number resources in the case of mergers and acquisitions under the following conditions: ..." Corporate reorganizations are currently being allowed under the following conditions: A parent organization can transfer resources to a child organization or vice versa as long as the child is a 100% wholly owned subsidiary. Various documentary requirements apply. Policy statement: "ARIN will consider requests for the transfer of number resources in the case of mergers, acquisitions and corporate reorganizations under the following conditions: ..." Timetable for implementation: Immediately From scottleibrand at gmail.com Mon Apr 29 16:41:56 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 29 Apr 2013 13:41:56 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Message-ID: At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdfor https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. In light of the above, I would propose the following revised definitions: 2.4. Local Internet Registry (LIR) The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thoughts? Should I submit this as a policy proposal? -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcarpen at network1.net Mon Apr 29 17:25:38 2013 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 29 Apr 2013 17:25:38 -0400 (EDT) Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: Message-ID: <510462539.276231.1367270738333.JavaMail.root@network1.net> One clarification that would be nice is for an org who is providing transit and a single IP address to customer(s') router(s) for purposes of routing. That sounds "ISP" at first glance, but if the org in question does not actually reassign "blocks" of addresses that need to be SWIPed/WHOISed, then I would think they would be an end-user with regard to number policy. thanks, -Randy ----- Original Message ----- > At ARIN 31 last week, Leslie's Policy Experience Report (slides at > https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf > or > https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx > ) reported that, in ARIN staff's experience, the NRPM does not adequately > define ISP/LIR vs. end-user. For example, by literally applying the existing > definitions as currently written, my employer would be neither an ISP nor > and end-user, because while they do not *primarily* assign address space to > users, neither do they *exclusively* use it in their own networks. So I > think those definitions need a few tweaks. > > I would propose that the primary difference between ISPs/LIRs vs. end-users, > for purposes of the NRPM, is whether an organization reassigns address > blocks to third parties. If an organization maintains full control of all of > the equipment on its network, and doesn't need to make any reassignments to > other organizations, then it can qualify as an end-user. In particular, an > end user organization must be able to supply a full list of all the IP > addresses in use on its network, and know what devices are using those > addresses. > > An ISP/LIR, on the other hand, should be defined by whether they delegate > that responsibility to another organization. In that case, they need to > reassign the network space via SWIP/rwhois, which makes them an LIR. > > I understand that there are other considerations, such as the expectation in > the security community that addresses within an ISP allocation are generally > controlled by third parties, whereas addresses in an end-user assignment are > generally controlled by the end-user organization. However, I don't believe > it's practical to try to draw a distinction there: rather, organizations can > decide for themselves whether they need to make reassignments (for that or > several other reasons), and that decision can drive whether they are > considered an ISP/LIR or end-user for purposes of ARIN policy. > > In light of the above, I would propose the following revised definitions: > > 2.4. Local Internet Registry (LIR) > The terms Internet Service Provider (ISP) and LIR are used interchangeably in > this document. A Local Internet Registry (LIR) is an IR that assigns address > space to the users of the network services that it provides. Therefore, LIRs > / ISPs are organizations that reassign addresses to end users and/or > reallocate addresses to other ISPs/LIRs. > > 2.6. End-user > An end-user is an organization receiving assignments of IP addresses > exclusively for use in its operational networks, and does not register any > reassignments of that space. > > Thoughts? Should I submit this as a policy proposal? > > -Scott > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bill at herrin.us Mon Apr 29 17:31:11 2013 From: bill at herrin.us (William Herrin) Date: Mon, 29 Apr 2013 17:31:11 -0400 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: Message-ID: On Mon, Apr 29, 2013 at 4:41 PM, Scott Leibrand wrote: > I would propose that the primary difference between ISPs/LIRs vs. end-users, > for purposes of the NRPM, is whether an organization reassigns address > blocks to third parties. If an organization maintains full control of all > of the equipment on its network, and doesn't need to make any reassignments > to other organizations, then it can qualify as an end-user. In particular, > an end user organization must be able to supply a full list of all the IP > addresses in use on its network, and know what devices are using those > addresses. Hi Scott, Keep it simple: 1. There is no LIR. Only ISP. I get the distinction but it's needlessly confusing for everybody who isn't steeped in ARIN policy. 2. If you don't claim to be an end user, you're an ISP subject to all rules, privileges and fees. 3. If no portion of your justification for IP addresses is based on assignment to and opaque use by a third party you may claim to be an end-user subject to end-user rules, privileges and fees. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Mon Apr 29 20:04:53 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Apr 2013 17:04:53 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <510462539.276231.1367270738333.JavaMail.root@network1.net> References: <510462539.276231.1367270738333.JavaMail.root@network1.net> Message-ID: <963C89FD-A988-4270-A6FE-1CB6D629EE4E@delong.com> There are some relatively large ISPs in the residential world that could fit that definition. I don't think we necessarily want to allow that to make them end-users for the following reasons: 1. It seems inequitable from a fee perspective vs. their competitors that provide more than one address to their customers. 2. It creates a negative incentive on IPv6 because they certainly shouldn't be doing that when they start moving their customers to IPv6, so they would be faced with the following possible outcomes: 1. Substantially larger annual fees. 2. Force their IPv6 users into IPv6 address poverty (single IPv6 address, not good.) 3. Do not deploy IPv6 or use some other IPv6 translational technology to avoid assigning IPv6 addresses to their customers. As a general rule, I think 1 is sufficient reason to avoid this change. However, even if you are not convinced by 1, I think the second set of tradeoffs is more than adequate. Owen On Apr 29, 2013, at 2:25 PM, Randy Carpenter wrote: > > One clarification that would be nice is for an org who is providing transit and a single IP address to customer(s') router(s) for purposes of routing. That sounds "ISP" at first glance, but if the org in question does not actually reassign "blocks" of addresses that need to be SWIPed/WHOISed, then I would think they would be an end-user with regard to number policy. > > > thanks, > -Randy > > > ----- Original Message ----- >> At ARIN 31 last week, Leslie's Policy Experience Report (slides at >> https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf >> or >> https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx >> ) reported that, in ARIN staff's experience, the NRPM does not adequately >> define ISP/LIR vs. end-user. For example, by literally applying the existing >> definitions as currently written, my employer would be neither an ISP nor >> and end-user, because while they do not *primarily* assign address space to >> users, neither do they *exclusively* use it in their own networks. So I >> think those definitions need a few tweaks. >> >> I would propose that the primary difference between ISPs/LIRs vs. end-users, >> for purposes of the NRPM, is whether an organization reassigns address >> blocks to third parties. If an organization maintains full control of all of >> the equipment on its network, and doesn't need to make any reassignments to >> other organizations, then it can qualify as an end-user. In particular, an >> end user organization must be able to supply a full list of all the IP >> addresses in use on its network, and know what devices are using those >> addresses. >> >> An ISP/LIR, on the other hand, should be defined by whether they delegate >> that responsibility to another organization. In that case, they need to >> reassign the network space via SWIP/rwhois, which makes them an LIR. >> >> I understand that there are other considerations, such as the expectation in >> the security community that addresses within an ISP allocation are generally >> controlled by third parties, whereas addresses in an end-user assignment are >> generally controlled by the end-user organization. However, I don't believe >> it's practical to try to draw a distinction there: rather, organizations can >> decide for themselves whether they need to make reassignments (for that or >> several other reasons), and that decision can drive whether they are >> considered an ISP/LIR or end-user for purposes of ARIN policy. >> >> In light of the above, I would propose the following revised definitions: >> >> 2.4. Local Internet Registry (LIR) >> The terms Internet Service Provider (ISP) and LIR are used interchangeably in >> this document. A Local Internet Registry (LIR) is an IR that assigns address >> space to the users of the network services that it provides. Therefore, LIRs >> / ISPs are organizations that reassign addresses to end users and/or >> reallocate addresses to other ISPs/LIRs. >> >> 2.6. End-user >> An end-user is an organization receiving assignments of IP addresses >> exclusively for use in its operational networks, and does not register any >> reassignments of that space. >> >> Thoughts? Should I submit this as a policy proposal? >> >> -Scott >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Mon Apr 29 20:06:40 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Apr 2013 17:06:40 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: Message-ID: <28C7E014-EE80-498A-877F-3760D7F79C93@delong.com> On Apr 29, 2013, at 2:31 PM, William Herrin wrote: > On Mon, Apr 29, 2013 at 4:41 PM, Scott Leibrand wrote: >> I would propose that the primary difference between ISPs/LIRs vs. end-users, >> for purposes of the NRPM, is whether an organization reassigns address >> blocks to third parties. If an organization maintains full control of all >> of the equipment on its network, and doesn't need to make any reassignments >> to other organizations, then it can qualify as an end-user. In particular, >> an end user organization must be able to supply a full list of all the IP >> addresses in use on its network, and know what devices are using those >> addresses. > > Hi Scott, > > Keep it simple: > > 1. There is no LIR. Only ISP. I get the distinction but it's > needlessly confusing for everybody who isn't steeped in ARIN policy. For policy purposes, LIR and ISP are identical. However, if you were going to eliminate a term from policy, the term ISP would be the one to eliminate. An ISP which fits into the ISP/LIR policy category is, by definition an LIR. It is possible, however, for an LIR to exist which is not actually an ISP. Owen From owen at delong.com Mon Apr 29 20:15:35 2013 From: owen at delong.com (Owen DeLong) Date: Mon, 29 Apr 2013 17:15:35 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: <510462539.276231.1367270738333.JavaMail.root@network1.net> <963C89FD-A988-4270-A6FE-1CB6D629EE4E@delong.com> Message-ID: I was commenting on Randy's statement. I think your proposal is fine. Owen On Apr 29, 2013, at 5:10 PM, Scott Leibrand wrote: > I would agree that we don't want large residential ISPs to qualify as end users. Do you think my proposed definition would allow that, or just disagreeing with Randy's proposal with regard to single-IP transit links? > > -Scott > > > On Mon, Apr 29, 2013 at 5:04 PM, Owen DeLong wrote: > There are some relatively large ISPs in the residential world that could fit that definition. I don't think we necessarily want to allow that to make them end-users for the following reasons: > > 1. It seems inequitable from a fee perspective vs. their competitors that provide more than one address to their > customers. > > 2. It creates a negative incentive on IPv6 because they certainly shouldn't be doing that when they start moving > their customers to IPv6, so they would be faced with the following possible outcomes: > > 1. Substantially larger annual fees. > 2. Force their IPv6 users into IPv6 address poverty (single IPv6 address, not good.) > 3. Do not deploy IPv6 or use some other IPv6 translational technology to avoid > assigning IPv6 addresses to their customers. > > As a general rule, I think 1 is sufficient reason to avoid this change. However, even if you are not convinced by 1, I think the second set of tradeoffs is more than adequate. > > Owen > > On Apr 29, 2013, at 2:25 PM, Randy Carpenter wrote: > > > > > One clarification that would be nice is for an org who is providing transit and a single IP address to customer(s') router(s) for purposes of routing. That sounds "ISP" at first glance, but if the org in question does not actually reassign "blocks" of addresses that need to be SWIPed/WHOISed, then I would think they would be an end-user with regard to number policy. > > > > > > thanks, > > -Randy > > > > > > ----- Original Message ----- > >> At ARIN 31 last week, Leslie's Policy Experience Report (slides at > >> https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf > >> or > >> https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx > >> ) reported that, in ARIN staff's experience, the NRPM does not adequately > >> define ISP/LIR vs. end-user. For example, by literally applying the existing > >> definitions as currently written, my employer would be neither an ISP nor > >> and end-user, because while they do not *primarily* assign address space to > >> users, neither do they *exclusively* use it in their own networks. So I > >> think those definitions need a few tweaks. > >> > >> I would propose that the primary difference between ISPs/LIRs vs. end-users, > >> for purposes of the NRPM, is whether an organization reassigns address > >> blocks to third parties. If an organization maintains full control of all of > >> the equipment on its network, and doesn't need to make any reassignments to > >> other organizations, then it can qualify as an end-user. In particular, an > >> end user organization must be able to supply a full list of all the IP > >> addresses in use on its network, and know what devices are using those > >> addresses. > >> > >> An ISP/LIR, on the other hand, should be defined by whether they delegate > >> that responsibility to another organization. In that case, they need to > >> reassign the network space via SWIP/rwhois, which makes them an LIR. > >> > >> I understand that there are other considerations, such as the expectation in > >> the security community that addresses within an ISP allocation are generally > >> controlled by third parties, whereas addresses in an end-user assignment are > >> generally controlled by the end-user organization. However, I don't believe > >> it's practical to try to draw a distinction there: rather, organizations can > >> decide for themselves whether they need to make reassignments (for that or > >> several other reasons), and that decision can drive whether they are > >> considered an ISP/LIR or end-user for purposes of ARIN policy. > >> > >> In light of the above, I would propose the following revised definitions: > >> > >> 2.4. Local Internet Registry (LIR) > >> The terms Internet Service Provider (ISP) and LIR are used interchangeably in > >> this document. A Local Internet Registry (LIR) is an IR that assigns address > >> space to the users of the network services that it provides. Therefore, LIRs > >> / ISPs are organizations that reassign addresses to end users and/or > >> reallocate addresses to other ISPs/LIRs. > >> > >> 2.6. End-user > >> An end-user is an organization receiving assignments of IP addresses > >> exclusively for use in its operational networks, and does not register any > >> reassignments of that space. > >> > >> Thoughts? Should I submit this as a policy proposal? > >> > >> -Scott > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Apr 29 20:10:43 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 29 Apr 2013 17:10:43 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <963C89FD-A988-4270-A6FE-1CB6D629EE4E@delong.com> References: <510462539.276231.1367270738333.JavaMail.root@network1.net> <963C89FD-A988-4270-A6FE-1CB6D629EE4E@delong.com> Message-ID: I would agree that we don't want large residential ISPs to qualify as end users. Do you think my proposed definition would allow that, or just disagreeing with Randy's proposal with regard to single-IP transit links? -Scott On Mon, Apr 29, 2013 at 5:04 PM, Owen DeLong wrote: > There are some relatively large ISPs in the residential world that could > fit that definition. I don't think we necessarily want to allow that to > make them end-users for the following reasons: > > 1. It seems inequitable from a fee perspective vs. their competitors > that provide more than one address to their > customers. > > 2. It creates a negative incentive on IPv6 because they certainly > shouldn't be doing that when they start moving > their customers to IPv6, so they would be faced with the following > possible outcomes: > > 1. Substantially larger annual fees. > 2. Force their IPv6 users into IPv6 address poverty > (single IPv6 address, not good.) > 3. Do not deploy IPv6 or use some other IPv6 > translational technology to avoid > assigning IPv6 addresses to their customers. > > As a general rule, I think 1 is sufficient reason to avoid this change. > However, even if you are not convinced by 1, I think the second set of > tradeoffs is more than adequate. > > Owen > > On Apr 29, 2013, at 2:25 PM, Randy Carpenter wrote: > > > > > One clarification that would be nice is for an org who is providing > transit and a single IP address to customer(s') router(s) for purposes of > routing. That sounds "ISP" at first glance, but if the org in question does > not actually reassign "blocks" of addresses that need to be SWIPed/WHOISed, > then I would think they would be an end-user with regard to number policy. > > > > > > thanks, > > -Randy > > > > > > ----- Original Message ----- > >> At ARIN 31 last week, Leslie's Policy Experience Report (slides at > >> > https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf > >> or > >> > https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx > >> ) reported that, in ARIN staff's experience, the NRPM does not > adequately > >> define ISP/LIR vs. end-user. For example, by literally applying the > existing > >> definitions as currently written, my employer would be neither an ISP > nor > >> and end-user, because while they do not *primarily* assign address > space to > >> users, neither do they *exclusively* use it in their own networks. So I > >> think those definitions need a few tweaks. > >> > >> I would propose that the primary difference between ISPs/LIRs vs. > end-users, > >> for purposes of the NRPM, is whether an organization reassigns address > >> blocks to third parties. If an organization maintains full control of > all of > >> the equipment on its network, and doesn't need to make any > reassignments to > >> other organizations, then it can qualify as an end-user. In particular, > an > >> end user organization must be able to supply a full list of all the IP > >> addresses in use on its network, and know what devices are using those > >> addresses. > >> > >> An ISP/LIR, on the other hand, should be defined by whether they > delegate > >> that responsibility to another organization. In that case, they need to > >> reassign the network space via SWIP/rwhois, which makes them an LIR. > >> > >> I understand that there are other considerations, such as the > expectation in > >> the security community that addresses within an ISP allocation are > generally > >> controlled by third parties, whereas addresses in an end-user > assignment are > >> generally controlled by the end-user organization. However, I don't > believe > >> it's practical to try to draw a distinction there: rather, > organizations can > >> decide for themselves whether they need to make reassignments (for that > or > >> several other reasons), and that decision can drive whether they are > >> considered an ISP/LIR or end-user for purposes of ARIN policy. > >> > >> In light of the above, I would propose the following revised > definitions: > >> > >> 2.4. Local Internet Registry (LIR) > >> The terms Internet Service Provider (ISP) and LIR are used > interchangeably in > >> this document. A Local Internet Registry (LIR) is an IR that assigns > address > >> space to the users of the network services that it provides. Therefore, > LIRs > >> / ISPs are organizations that reassign addresses to end users and/or > >> reallocate addresses to other ISPs/LIRs. > >> > >> 2.6. End-user > >> An end-user is an organization receiving assignments of IP addresses > >> exclusively for use in its operational networks, and does not register > any > >> reassignments of that space. > >> > >> Thoughts? Should I submit this as a policy proposal? > >> > >> -Scott > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Apr 29 17:50:01 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 29 Apr 2013 14:50:01 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: Message-ID: On Mon, Apr 29, 2013 at 2:31 PM, William Herrin wrote: > On Mon, Apr 29, 2013 at 4:41 PM, Scott Leibrand > wrote: > > I would propose that the primary difference between ISPs/LIRs vs. > end-users, > > for purposes of the NRPM, is whether an organization reassigns address > > blocks to third parties. If an organization maintains full control of > all > > of the equipment on its network, and doesn't need to make any > reassignments > > to other organizations, then it can qualify as an end-user. In > particular, > > an end user organization must be able to supply a full list of all the IP > > addresses in use on its network, and know what devices are using those > > addresses. > > Hi Scott, > > Keep it simple: > > 1. There is no LIR. Only ISP. I get the distinction but it's > needlessly confusing for everybody who isn't steeped in ARIN policy. > I was considering a global search-and-replace of LIR with ISP. If people think that'd be helpful, I'd be happy to include that change in the policy proposal. (FWIW, the term LIR is primarily used by some of the other RIRs, and the main reason it's in ARIN policy was that the IPv6 policy was originally a globally coordinated policy that used common language with all the other RIRs. But we can change it if we feel like it.) > > 2. If you don't claim to be an end user, you're an ISP subject to all > rules, privileges and fees. > > 3. If no portion of your justification for IP addresses is based on > assignment to and opaque use by a third party you may claim to be an > end-user subject to end-user rules, privileges and fees. > Yes, I think those summarize the distinction I'm trying to draw. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From dogwallah at gmail.com Mon Apr 29 22:12:45 2013 From: dogwallah at gmail.com (McTim) Date: Mon, 29 Apr 2013 22:12:45 -0400 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <28C7E014-EE80-498A-877F-3760D7F79C93@delong.com> References: <28C7E014-EE80-498A-877F-3760D7F79C93@delong.com> Message-ID: On Mon, Apr 29, 2013 at 8:06 PM, Owen DeLong wrote: > > For policy purposes, LIR and ISP are identical. However, if you were going > to eliminate a term from policy, the term ISP would be the one to eliminate. +1 > > An ISP which fits into the ISP/LIR policy category is, by definition an LIR. > > It is possible, however, for an LIR to exist which is not actually an ISP. right. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel From Daniel_Alexander at Cable.Comcast.com Mon Apr 29 23:37:49 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 30 Apr 2013 03:37:49 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: Message-ID: Hello All, I would be curious to hear people's opinions of whether the distinctions are still necessary within ARIN policy. Once the IPv4 free pool is depleted, and the policies become focused on processing transfers, do we need to distinguish between End Users, non-End Users, and PA vs PI within ARIN policy? What are the criteria in which these distinctions matter, and will they still apply next year? Dan ARIN AC From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf or https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. In light of the above, I would propose the following revised definitions: 2.4. Local Internet Registry (LIR) The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thoughts? Should I submit this as a policy proposal? -Scott _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From billdarte at gmail.com Tue Apr 30 07:21:15 2013 From: billdarte at gmail.com (Bill Darte) Date: Tue, 30 Apr 2013 06:21:15 -0500 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: Message-ID: The distinction between end user and ISP that seemed to have value in early v4 policy is the PI addresses gave the holder flexibility to choose between ISPs for their announcements and access. If anyone's address availability is through the transfer market, then I suggest that is all PI addressing at that point and would remove that one distinction at least. bd On Mon, Apr 29, 2013 at 10:37 PM, Alexander, Daniel < Daniel_Alexander at cable.comcast.com> wrote: > Hello All, > > I would be curious to hear people's opinions of whether the distinctions > are still necessary within ARIN policy. Once the IPv4 free pool is > depleted, and the policies become focused on processing transfers, do we > need to distinguish between End Users, non-End Users, and PA vs PI within > ARIN policy? > > What are the criteria in which these distinctions matter, and will they > still apply next year? > > Dan > ARIN AC > > From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 > To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user > > At ARIN 31 last week, Leslie's Policy Experience Report (slides at > https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdfor > https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) > reported that, in ARIN staff's experience, the NRPM does not adequately > define ISP/LIR vs. end-user. For example, by literally applying the > existing definitions as currently written, my employer would be neither an > ISP nor and end-user, because while they do not *primarily* assign address > space to users, neither do they *exclusively* use it in their own > networks. So I think those definitions need a few tweaks. > > I would propose that the primary difference between ISPs/LIRs vs. > end-users, for purposes of the NRPM, is whether an organization reassigns > address blocks to third parties. If an organization maintains full control > of all of the equipment on its network, and doesn't need to make any > reassignments to other organizations, then it can qualify as an end-user. > In particular, an end user organization must be able to supply a full list > of all the IP addresses in use on its network, and know what devices are > using those addresses. > > An ISP/LIR, on the other hand, should be defined by whether they > delegate that responsibility to another organization. In that case, they > need to reassign the network space via SWIP/rwhois, which makes them an LIR. > > I understand that there are other considerations, such as the > expectation in the security community that addresses within an ISP > allocation are generally controlled by third parties, whereas addresses in > an end-user assignment are generally controlled by the end-user > organization. However, I don't believe it's practical to try to draw a > distinction there: rather, organizations can decide for themselves whether > they need to make reassignments (for that or several other reasons), and > that decision can drive whether they are considered an ISP/LIR or end-user > for purposes of ARIN policy. > > In light of the above, I would propose the following revised definitions: > > 2.4. Local Internet Registry (LIR) > The terms Internet Service Provider (ISP) and LIR are used interchangeably > in this document. A Local Internet Registry (LIR) is an IR that assigns > address space to the users of the network services that it provides. > Therefore, LIRs / ISPs are organizations that reassign addresses to end > users and/or reallocate addresses to other ISPs/LIRs. > > 2.6. End-user > An end-user is an organization receiving assignments of IP addresses > exclusively for use in its operational networks, and does not register any > reassignments of that space. > > Thoughts? Should I submit this as a policy proposal? > > -Scott > _______________________________________________ PPML You are receiving > this message because you are subscribed to the ARIN Public Policy Mailing > List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list > subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please > contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From droisman at softlayer.com Tue Apr 30 09:11:06 2013 From: droisman at softlayer.com (Dani Roisman) Date: Tue, 30 Apr 2013 13:11:06 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Message-ID: | Date: Mon, 29 Apr 2013 14:50:01 -0700 | From: Scott Leibrand | To: William Herrin | Cc: ARIN-PPML List | Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user | Message-ID: | | Content-Type: text/plain; charset="iso-8859-1" | | On Mon, Apr 29, 2013 at 2:31 PM, William Herrin wrote: | | > On Mon, Apr 29, 2013 at 4:41 PM, Scott Leibrand | | > wrote: | > > I would propose that the primary difference between ISPs/LIRs vs. | > end-users, | > > for purposes of the NRPM, is whether an organization reassigns address | > > blocks to third parties. If an organization maintains full control of | > all | > > of the equipment on its network, and doesn't need to make any | > reassignments | > > to other organizations, then it can qualify as an end-user. In | > particular, | > > an end user organization must be able to supply a full list of all the IP | > > addresses in use on its network, and know what devices are using those | > > addresses. | > | > Hi Scott, | > | > Keep it simple: | > | > 1. There is no LIR. Only ISP. I get the distinction but it's | > needlessly confusing for everybody who isn't steeped in ARIN policy. | > | | I was considering a global search-and-replace of LIR with ISP. If people | think that'd be helpful, I'd be happy to include that change in the policy | proposal. | | (FWIW, the term LIR is primarily used by some of the other RIRs, and the | main reason it's in ARIN policy was that the IPv6 policy was originally a | globally coordinated policy that used common language with all the other | RIRs. But we can change it if we feel like it.) | Here's the way I understand the history of these terms, and have explained to others why ARIN says "ISP" but the other RIRs say "LIR" and really mean the same thing: ARIN policy is written with a North-American bias, where there are a very small number of countries, the language is primarily English, and the culture and manner of doing business on the Internet is fairly standard throughout the region. ARIN typically assigns to two different types of members: * end-user organizations = large companies, large content hosters who exclusively use the IPs on their equipment * ISP organizations = network operators who then issue pieces of those IP allocations to their down-stream customers for use on customer-owned/operated equipment The other RIR's service a larger number of countries, with diverse language sets and cultures, and thus the term "LIR" (local Internet registry) was used to describe the practice of end-users typically receiving IPs from providers "local" to them. However, I've always thought of LIR/ISP as interchangeable terms, depending on who's policy you happen to be reading at the time. My vote goes towards a global replacement of "ISP" in all ARIN documents with the term "LIR" in order to match the language used by the other 4 RIRs. I would then support an brief statement early in the NRPM which explains that "The term LIR has replaced the term ISP formerly used in ARIN policy documents in order to simplify the global understanding of RIR policy documents. The definition of LIR exactly matches the previous definition of ISP for the purpose of the ARIN NRPM." (well, something like that, you get the point). ---- Dani Roisman From jcurran at arin.net Tue Apr 30 10:17:53 2013 From: jcurran at arin.net (John Curran) Date: Tue, 30 Apr 2013 14:17:53 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> On Apr 30, 2013, at 9:11 AM, Dani Roisman wrote: > | On Mon, Apr 29, 2013 at 2:31 PM, William Herrin wrote: > | >... > | > Keep it simple: > | > > | > 1. There is no LIR. Only ISP. I get the distinction but it's > | > needlessly confusing for everybody who isn't steeped in ARIN policy. > | > > | > | I was considering a global search-and-replace of LIR with ISP. If people > | think that'd be helpful, I'd be happy to include that change in the policy > | proposal. > | > | (FWIW, the term LIR is primarily used by some of the other RIRs, and the > | main reason it's in ARIN policy was that the IPv6 policy was originally a > | globally coordinated policy that used common language with all the other > | RIRs. But we can change it if we feel like it.) > > Here's the way I understand the history of these terms, and have explained to others why ARIN says "ISP" but the other RIRs say "LIR" and really mean the same thing: > > ARIN policy is written with a North-American bias, where there are a very small number of countries, the language is primarily English, and the culture and manner of doing business on the Internet is fairly standard throughout the region. ARIN typically assigns to two different types of members: > * end-user organizations = large companies, large content hosters who exclusively use the IPs on their equipment > * ISP organizations = network operators who then issue pieces of those IP allocations to their down-stream customers for use on customer-owned/operated equipment > > The other RIR's service a larger number of countries, with diverse language sets and cultures, and thus the term "LIR" (local Internet registry) was used to describe the practice of end-users typically receiving IPs from providers "local" to them. Note that ARIN serves more than 25 countries at present and used to serve both South America and Sub-Saharan Africa (i.e. "Rest of World" (ROW) region, which was everything outside of RIPE NCC and APNIC regions) It is true that we use one language for the registry (English), and "ISP" is a well recognized term in that language. > However, I've always thought of LIR/ISP as interchangeable terms, depending on who's policy you happen to be reading at the time. They generally are, reference the "LIR" definition in NRPM 2.4 "A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs), whose customers are primarily end users and possibly other ISPs." and then NRPM 6.5 - "6.5.1. Terminology ? The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings." > My vote goes towards a global replacement of "ISP" in all ARIN documents with the term "LIR" in order to match the language used by the other 4 RIRs. I would then support an brief statement early in the NRPM which explains that "The term LIR has replaced the term ISP formerly used in ARIN policy documents in order to simplify the global understanding of RIR policy documents. The definition of LIR exactly matches the previous definition of ISP for the purpose of the ARIN NRPM." (well, something like that, you get the point). Easy enough to accomplish, if folks believe that the end result will be more clear than present approach. FYI, /John John Curran President and CEO ARIN From alh-ietf at tndh.net Tue Apr 30 13:05:50 2013 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 30 Apr 2013 10:05:50 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> References: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> Message-ID: <015501ce45c4$f78a5df0$e69f19d0$@tndh.net> > ..... > They generally are, reference the "LIR" definition in NRPM 2.4 > > > "A Local Internet Registry (LIR) is an IR that primarily assigns address space to > the users of the network services that it provides. LIRs are generally Internet > Service Providers (ISPs), whose customers are primarily end users and > possibly other ISPs." > > and then NRPM 6.5 - > > "6.5.1. Terminology > > . The terms ISP and LIR are used interchangeably in this document and any > use of either term shall be construed to include both meanings." > > > My vote goes towards a global replacement of "ISP" in all ARIN documents > with the term "LIR" in order to match the language used by the other 4 RIRs. > I would then support an brief statement early in the NRPM which explains > that "The term LIR has replaced the term ISP formerly used in ARIN policy > documents in order to simplify the global understanding of RIR policy > documents. The definition of LIR exactly matches the previous definition of > ISP for the purpose of the ARIN NRPM." (well, something like that, you get > the point). > > > Easy enough to accomplish, if folks believe that the end result will be more > clear than present approach. While I agree that from the perspective of 'this allocation is for 3rd party use' leads to LIR==ISP, the justification process and unit sizes were historically a little different in that ISP customer ~= /30 - /32 blocks while typical LIR customer ~< /27, and the ISP was also getting space for an internal infrastructure while the LIR did not. My concern is that by merging terms there might be an unintended consequence in the evaluation side of this. I have no objection to the merge and actually support the simplification, just asking that someone comment about potential confusion between those with an infrastructure (ISP), and those without (LIR). If we effectively split the ISPs into the LIR part supporting customers, and the end-user part for their infrastructure, that may simplify policy language, but make the justification/evaluation process more difficult. Tony From scottleibrand at gmail.com Tue Apr 30 14:06:32 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 30 Apr 2013 11:06:32 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <015501ce45c4$f78a5df0$e69f19d0$@tndh.net> References: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> <015501ce45c4$f78a5df0$e69f19d0$@tndh.net> Message-ID: The term LIR is not used in IPv4 policy (NRPM section 4), only in IPv6 policy (section 6). -Scott On Tue, Apr 30, 2013 at 10:05 AM, Tony Hain wrote: > > ..... > > They generally are, reference the "LIR" definition in NRPM 2.4 > > > > > > "A Local Internet Registry (LIR) is an IR that primarily assigns address > space to > > the users of the network services that it provides. LIRs are generally > Internet > > Service Providers (ISPs), whose customers are primarily end users and > > possibly other ISPs." > > > > and then NRPM 6.5 - > > > > "6.5.1. Terminology > > > > . The terms ISP and LIR are used interchangeably in this document and > any > > use of either term shall be construed to include both meanings." > > > > > My vote goes towards a global replacement of "ISP" in all ARIN > documents > > with the term "LIR" in order to match the language used by the other 4 > RIRs. > > I would then support an brief statement early in the NRPM which explains > > that "The term LIR has replaced the term ISP formerly used in ARIN policy > > documents in order to simplify the global understanding of RIR policy > > documents. The definition of LIR exactly matches the previous definition > of > > ISP for the purpose of the ARIN NRPM." (well, something like that, you > get > > the point). > > > > > > Easy enough to accomplish, if folks believe that the end result will be > more > > clear than present approach. > > While I agree that from the perspective of 'this allocation is for 3rd > party > use' leads to LIR==ISP, the justification process and unit sizes were > historically a little different in that ISP customer ~= /30 - /32 blocks > while typical LIR customer ~< /27, and the ISP was also getting space for > an internal infrastructure while the LIR did not. My concern is that by > merging terms there might be an unintended consequence in the evaluation > side of this. I have no objection to the merge and actually support the > simplification, just asking that someone comment about potential confusion > between those with an infrastructure (ISP), and those without (LIR). If we > effectively split the ISPs into the LIR part supporting customers, and the > end-user part for their infrastructure, that may simplify policy language, > but make the justification/evaluation process more difficult. > > Tony > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Apr 30 14:36:30 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 30 Apr 2013 11:36:30 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: Message-ID: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com> Dan, The definitions apply to IPv6 as well. I believe they are still necessary. Owen On Apr 29, 2013, at 20:37 , "Alexander, Daniel" wrote: > Hello All, > > I would be curious to hear people's opinions of whether the distinctions are still necessary within ARIN policy. Once the IPv4 free pool is depleted, and the policies become focused on processing transfers, do we need to distinguish between End Users, non-End Users, and PA vs PI within ARIN policy? > > What are the criteria in which these distinctions matter, and will they still apply next year? > > Dan > ARIN AC > > From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 > To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user > > At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf or https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. > > I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. > > An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. > > I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. > > In light of the above, I would propose the following revised definitions: > > 2.4. Local Internet Registry (LIR) > The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. > > 2.6. End-user > An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. > > Thoughts? Should I submit this as a policy proposal? > > -Scott > _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gary.buhrmaster at gmail.com Tue Apr 30 14:41:54 2013 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 30 Apr 2013 18:41:54 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> References: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> Message-ID: On Tue, Apr 30, 2013 at 2:17 PM, John Curran wrote: ... > Easy enough to accomplish, if folks believe that the end result will be more > clear than present approach. Using one term (LIR) everywhere has an advantage in reading of the NRPM (although I would assert few do (present company are the exception, of course), and fewer still can actually figure out all the nuances (or maybe I am projecting my own limits when reading the NRPM :-)). But, so that those that think of themselves as ISPs know how they are being referred to as, the 2.4 reference should probably be enhanced with something like: .. 2.4 Local Internet Registry [LIR] / ISPs ..... For consistency ... the document uses the term LIR. As an editorial only change (since 6.5.1 explicitly states that LIR == ISP), this should not be especially controversial. On the other hand, I do not consider this important enough to invest a lot of resources into. From owen at delong.com Tue Apr 30 15:09:27 2013 From: owen at delong.com (Owen DeLong) Date: Tue, 30 Apr 2013 12:09:27 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <015501ce45c4$f78a5df0$e69f19d0$@tndh.net> References: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> <015501ce45c4$f78a5df0$e69f19d0$@tndh.net> Message-ID: <805E03FD-AB8B-40EC-A34F-95740C90F416@delong.com> > While I agree that from the perspective of 'this allocation is for 3rd party > use' leads to LIR==ISP, the justification process and unit sizes were > historically a little different in that ISP customer ~= /30 - /32 blocks > while typical LIR customer ~< /27, and the ISP was also getting space for > an internal infrastructure while the LIR did not. My concern is that by > merging terms there might be an unintended consequence in the evaluation > side of this. I have no objection to the merge and actually support the > simplification, just asking that someone comment about potential confusion > between those with an infrastructure (ISP), and those without (LIR). If we > effectively split the ISPs into the LIR part supporting customers, and the > end-user part for their infrastructure, that may simplify policy language, > but make the justification/evaluation process more difficult. > I've never seen anything like that in the ARIN region. It is not uncommon for ISPs in the ARIN region today to receive /28 and even /24 allocations. (IMHO, this is a good thing). Owen From scottleibrand at gmail.com Tue Apr 30 15:15:39 2013 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 30 Apr 2013 12:15:39 -0700 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> Message-ID: I think my language makes it clear that LIR == ISP, and defines both. The more important question, IMO, is how to define and differentiate LIRs/ISPs vs. End-user orgs, so that ARIN staff can apply policy consistently, and in a way that matches the community's intent. Do you think this accomplishes that? Any other thoughts or suggestions before I submit it as a policy proposal? *2.4. Local Internet Registry (LIR) / Internet Service Provider (ISP)* The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thanks, Scott On Tue, Apr 30, 2013 at 11:41 AM, Gary Buhrmaster wrote: > On Tue, Apr 30, 2013 at 2:17 PM, John Curran wrote: > ... > > Easy enough to accomplish, if folks believe that the end result will be > more > > clear than present approach. > > Using one term (LIR) everywhere has an advantage in reading of > the NRPM (although I would assert few do (present company are > the exception, of course), and fewer still can actually figure out > all the nuances (or maybe I am projecting my own limits when > reading the NRPM :-)). But, so that those that think of themselves > as ISPs know how they are being referred to as, the 2.4 reference > should probably be enhanced with something like: > .. 2.4 Local Internet Registry [LIR] / ISPs > ..... For consistency ... the document uses the term LIR. > > As an editorial only change (since 6.5.1 explicitly states that > LIR == ISP), this should not be especially controversial. On > the other hand, I do not consider this important enough to > invest a lot of resources into. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen at sprunk.org Tue Apr 30 15:40:26 2013 From: stephen at sprunk.org (Stephen Sprunk) Date: Tue, 30 Apr 2013 14:40:26 -0500 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: <8DA1853CE466B041B104C1CAEE00B3748FC669AB@CHAXCH01.corp.arin.net> <015501ce45c4$f78a5df0$e69f19d0$@tndh.net> Message-ID: <51801E2A.3020904@sprunk.org> On 30-Apr-13 13:06, Scott Leibrand wrote: > The term LIR is not used in IPv4 policy (NRPM section 4), only in IPv6 > policy (section 6). IIRC, that is because Section 4 evolved in-house by ARIN over the years, whereas Section 6 was (initially) copied en toto from a policy developed by the RIRs working together. IMHO, we should use the term LIR to be consistent with other RIRs. To make the transition easier, it may be helpful for Section 2 to note that "LIR" is a superset of the older term "ISP", but "ISP" shouldn't appear anywhere else in the NRPM. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2381 bytes Desc: S/MIME Cryptographic Signature URL: From Daniel_Alexander at Cable.Comcast.com Tue Apr 30 15:54:06 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 30 Apr 2013 19:54:06 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com> Message-ID: I suggest it is a worthwhile conversation to explore why they will be necessary? If the Internet is a network of networks, why does ARIN, an RIR, need to make the distinctions in how it allocates or assigns resources? Why shouldn't ARIN simply allocate resources to networks, regardless of how they operate simply based on what they need? Are we over complicating things, not only for the Registry, but for those who don't do this for a living who are struggling to understand what all this means and why? This goes back to the original PI/PA debate. There are End User networks that dwarf many ISP/LIR networks and vise versa. Why should we maintain multiple layers of requirements to justify IPv4 transfers and an exceedingly large pool of IPv6 space? -Dan From: Owen DeLong > Date: Tue, 30 Apr 2013 11:36:30 -0700 To: Microsoft Office User > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Dan, The definitions apply to IPv6 as well. I believe they are still necessary. Owen On Apr 29, 2013, at 20:37 , "Alexander, Daniel" > wrote: Hello All, I would be curious to hear people's opinions of whether the distinctions are still necessary within ARIN policy. Once the IPv4 free pool is depleted, and the policies become focused on processing transfers, do we need to distinguish between End Users, non-End Users, and PA vs PI within ARIN policy? What are the criteria in which these distinctions matter, and will they still apply next year? Dan ARIN AC From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf or https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. In light of the above, I would propose the following revised definitions: 2.4. Local Internet Registry (LIR) The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thoughts? Should I submit this as a policy proposal? -Scott _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Tue Apr 30 16:34:07 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Tue, 30 Apr 2013 20:34:07 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201313DA3E4@ENI-MAIL.eclipse-networks.com> I agree with Daniel. I strongly believe it is Arin?s charter and mission to further the Internet and not impede access to it. Debating about what an organization is doing on the Internet or what they are called is really a discussion on how to limit access to the Internet. I don?t believe that Arin should be trying to deny or limit an organization?s access to the Internet. I believe Arin should be trying to expand the Internet for good of everyone as was done before Arin?s existence. I?m all for right sizing an organizations access with reasonable polices but I am not in favor of policies that have the sole purpose of denying or restricting access to the Internet. I believe that Arin and this community need to adopt a similar set of policies like have been proposed in Europe https://www.ripe.net/ripe/policies/proposals/2013-03 This would require a wholesale rewrite of a lot of policies which I am not capable of doing - but removing the needs requirements in all policies and just instituting right-sizing policies would be in line with Arin?s mission and be best for all. I would support anyone willing to take the time to submit a proposal to Arin similar to the one above that has been proposed for RIPE. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Tuesday, April 30, 2013 3:54 PM To: Owen DeLong; ARIN-PPML List Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user I suggest it is a worthwhile conversation to explore why they will be necessary? If the Internet is a network of networks, why does ARIN, an RIR, need to make the distinctions in how it allocates or assigns resources? Why shouldn't ARIN simply allocate resources to networks, regardless of how they operate simply based on what they need? Are we over complicating things, not only for the Registry, but for those who don't do this for a living who are struggling to understand what all this means and why? This goes back to the original PI/PA debate. There are End User networks that dwarf many ISP/LIR networks and vise versa. Why should we maintain multiple layers of requirements to justify IPv4 transfers and an exceedingly large pool of IPv6 space? -Dan From: Owen DeLong > Date: Tue, 30 Apr 2013 11:36:30 -0700 To: Microsoft Office User > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Dan, The definitions apply to IPv6 as well. I believe they are still necessary. Owen On Apr 29, 2013, at 20:37 , "Alexander, Daniel" > wrote: Hello All, I would be curious to hear people's opinions of whether the distinctions are still necessary within ARIN policy. Once the IPv4 free pool is depleted, and the policies become focused on processing transfers, do we need to distinguish between End Users, non-End Users, and PA vs PI within ARIN policy? What are the criteria in which these distinctions matter, and will they still apply next year? Dan ARIN AC From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf or https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. In light of the above, I would propose the following revised definitions: 2.4. Local Internet Registry (LIR) The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thoughts? Should I submit this as a policy proposal? -Scott _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From Daniel_Alexander at Cable.Comcast.com Tue Apr 30 16:43:36 2013 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Tue, 30 Apr 2013 20:43:36 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: Message-ID: I should also clarify that I support what Scott has started below and think the two efforts would take a separate path. Scott's clarification effort is a near term fix. If the community thinks what I am discussing is worthwhile it would be a longer term effort and spun off in a separate thread. -Dan From: Microsoft Office User > Date: Tue, 30 Apr 2013 19:54:06 +0000 To: Owen DeLong >, ARIN-PPML List > Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user I suggest it is a worthwhile conversation to explore why they will be necessary? If the Internet is a network of networks, why does ARIN, an RIR, need to make the distinctions in how it allocates or assigns resources? Why shouldn't ARIN simply allocate resources to networks, regardless of how they operate simply based on what they need? Are we over complicating things, not only for the Registry, but for those who don't do this for a living who are struggling to understand what all this means and why? This goes back to the original PI/PA debate. There are End User networks that dwarf many ISP/LIR networks and vise versa. Why should we maintain multiple layers of requirements to justify IPv4 transfers and an exceedingly large pool of IPv6 space? -Dan From: Owen DeLong > Date: Tue, 30 Apr 2013 11:36:30 -0700 To: Microsoft Office User > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Dan, The definitions apply to IPv6 as well. I believe they are still necessary. Owen On Apr 29, 2013, at 20:37 , "Alexander, Daniel" > wrote: Hello All, I would be curious to hear people's opinions of whether the distinctions are still necessary within ARIN policy. Once the IPv4 free pool is depleted, and the policies become focused on processing transfers, do we need to distinguish between End Users, non-End Users, and PA vs PI within ARIN policy? What are the criteria in which these distinctions matter, and will they still apply next year? Dan ARIN AC From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf or https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. In light of the above, I would propose the following revised definitions: 2.4. Local Internet Registry (LIR) The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thoughts? Should I submit this as a policy proposal? -Scott _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Tue Apr 30 17:30:49 2013 From: bill at herrin.us (William Herrin) Date: Tue, 30 Apr 2013 17:30:49 -0400 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com> Message-ID: On Tue, Apr 30, 2013 at 3:54 PM, Alexander, Daniel wrote: > If the Internet is a network of networks, why does ARIN, an RIR, need to > make the distinctions in how it allocates or assigns resources? Why > shouldn't ARIN simply allocate resources to networks, regardless of how they > operate simply based on what they need? Hi Daniel, Because they aren't ARIN's addresses. They're ours, yours and mine. And we direct ARIN to act as a steward for those addresses on our behalf, making them available to you and I. ARIN is not permitted to abdicate that responsibility to third parties. It may delegate the responsibility, but such delegation comes with duties on the third party to also act as a steward for those addresses on our behalf. So, unless the supply is sufficiently inexhaustible in the quantities requested as to pose no imaginable need to conserve, ARIN has to decide whether each request is a case of providing addresses to the public or delegating its responsibility for doing so to a third party. Regards Bill Herrin -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From billdarte at gmail.com Tue Apr 30 19:52:39 2013 From: billdarte at gmail.com (Bill Darte) Date: Tue, 30 Apr 2013 18:52:39 -0500 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201313DA3E4@ENI-MAIL.eclipse-networks.com> References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com> <5B9E90747FA2974D91A54FCFA1B8AD1201313DA3E4@ENI-MAIL.eclipse-networks.com> Message-ID: Steven Ryerse wrote: I believe that Arin and this community need to adopt a similar set of policies like have been proposed in Europe https://www.ripe.net/ripe/policies/proposals/2013-03 This would require a wholesale rewrite of a lot of policies which I am not capable of doing - but removing the needs requirements in all policies and just instituting right-sizing policies would be in line with Arin?s mission and be best for all. I would support anyone willing to take the time to submit a proposal to Arin similar to the one above that has been proposed for RIPE. Steven, please tell what right-sizing means to you and how that differs from assigning addresses according to an explicit need... Thanks, bd On Tue, Apr 30, 2013 at 3:34 PM, Steven Ryerse wrote: > I agree with Daniel. I strongly believe it is Arin?s charter and > mission to further the Internet and not impede access to it. Debating > about what an organization is doing on the Internet or what they are called > is really a discussion on how to limit access to the Internet. I don?t > believe that Arin should be trying to deny or limit an organization?s > access to the Internet. I believe Arin should be trying to expand the > Internet for good of everyone as was done before Arin?s existence. I?m all > for right sizing an organizations access with reasonable polices but I am > not in favor of policies that have the sole purpose of denying or > restricting access to the Internet. **** > > ** ** > > I believe that Arin and this community need to adopt a similar set of > policies like have been proposed in Europe > https://www.ripe.net/ripe/policies/proposals/2013-03 This would require > a wholesale rewrite of a lot of policies which I am not capable of doing - > but removing the needs requirements in all policies and just instituting > right-sizing policies would be in line with Arin?s mission and be best for > all. I would support anyone willing to take the time to submit a proposal > to Arin similar to the one above that has been proposed for RIPE. **** > > ** ** > > *Steven L Ryerse* > > *President* > > *100 Ashford Center North, Suite 110, Atlanta, GA 30338* > > *770.656.1460 - Cell* > > *770.399.9099 - Office* > > *770.392-0076 - Fax* > > ** ** > > [image: Description: Description: Description: Eclipse Networks > Logo_small.png]? Eclipse Networks, Inc.**** > > Conquering Complex Networks?**** > > ** ** > > *From:* arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] *On > Behalf Of *Alexander, Daniel > *Sent:* Tuesday, April 30, 2013 3:54 PM > *To:* Owen DeLong; ARIN-PPML List > *Subject:* Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user**** > > ** ** > > I suggest it is a worthwhile conversation to explore why they will be > necessary?**** > > ** ** > > If the Internet is a network of networks, why does ARIN, an RIR, need to > make the distinctions in how it allocates or assigns resources? Why > shouldn't ARIN simply allocate resources to networks, regardless of how > they operate simply based on what they need? **** > > ** ** > > Are we over complicating things, not only for the Registry, but for those > who don't do this for a living who are struggling to understand what all > this means and why? **** > > ** ** > > This goes back to the original PI/PA debate. There are End User networks > that dwarf many ISP/LIR networks and vise versa. Why should we maintain > multiple layers of requirements to justify IPv4 transfers and an > exceedingly large pool of IPv6 space?**** > > ** ** > > -Dan**** > > ** ** > > *From: *Owen DeLong > *Date: *Tue, 30 Apr 2013 11:36:30 -0700 > *To: *Microsoft Office User > *Cc: *ARIN-PPML List > *Subject: *Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user**** > > ** ** > > Dan, **** > > ** ** > > The definitions apply to IPv6 as well.**** > > ** ** > > I believe they are still necessary.**** > > ** ** > > Owen**** > > ** ** > > On Apr 29, 2013, at 20:37 , "Alexander, Daniel" < > Daniel_Alexander at Cable.Comcast.com> wrote:**** > > > > **** > > Hello All,**** > > ** ** > > I would be curious to hear people's opinions of whether the distinctions > are still necessary within ARIN policy. Once the IPv4 free pool is > depleted, and the policies become focused on processing transfers, do we > need to distinguish between End Users, non-End Users, and PA vs PI within > ARIN policy?**** > > ** ** > > What are the criteria in which these distinctions matter, and will they > still apply next year?**** > > ** ** > > Dan **** > > ARIN AC**** > > ** ** > > *From: *Scott Leibrand > *Date: *Mon, 29 Apr 2013 13:41:56 -0700 > *To: *ARIN-PPML List > *Subject: *[arin-ppml] Clean up definition of LIR/ISP vs. end-user**** > > ** ** > > At ARIN 31 last week, Leslie's Policy Experience Report (slides at > https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdfor > https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) > reported that, in ARIN staff's experience, the NRPM does not adequately > define ISP/LIR vs. end-user. For example, by literally applying the > existing definitions as currently written, my employer would be neither an > ISP nor and end-user, because while they do not *primarily* assign address > space to users, neither do they *exclusively* use it in their own > networks. So I think those definitions need a few tweaks. **** > > ** ** > > I would propose that the primary difference between ISPs/LIRs vs. > end-users, for purposes of the NRPM, is whether an organization reassigns > address blocks to third parties. If an organization maintains full control > of all of the equipment on its network, and doesn't need to make any > reassignments to other organizations, then it can qualify as an end-user. > In particular, an end user organization must be able to supply a full list > of all the IP addresses in use on its network, and know what devices are > using those addresses.**** > > ** ** > > An ISP/LIR, on the other hand, should be defined by whether they delegate > that responsibility to another organization. In that case, they need to > reassign the network space via SWIP/rwhois, which makes them an LIR.**** > > ** ** > > I understand that there are other considerations, such as the expectation > in the security community that addresses within an ISP allocation are > generally controlled by third parties, whereas addresses in an end-user > assignment are generally controlled by the end-user organization. However, > I don't believe it's practical to try to draw a distinction there: rather, > organizations can decide for themselves whether they need to make > reassignments (for that or several other reasons), and that decision can > drive whether they are considered an ISP/LIR or end-user for purposes of > ARIN policy.**** > > ** ** > > In light of the above, I would propose the following revised definitions:* > *** > > ** ** > > 2.4. Local Internet Registry (LIR)**** > > The terms Internet Service Provider (ISP) and LIR are used interchangeably > in this document. A Local Internet Registry (LIR) is an IR that assigns > address space to the users of the network services that it provides. > Therefore, LIRs / ISPs are organizations that reassign addresses to end > users and/or reallocate addresses to other ISPs/LIRs.**** > > ** ** > > 2.6. End-user**** > > An end-user is an organization receiving assignments of IP addresses > exclusively for use in its operational networks, and does not register any > reassignments of that space.**** > > ** ** > > Thoughts? Should I submit this as a policy proposal?**** > > ** ** > > -Scott**** > > _______________________________________________ PPML You are receiving > this message because you are subscribed to the ARIN Public Policy Mailing > List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list > subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please > contact info at arin.net if you experience any issues.**** > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues.**** > > ** ** > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: not available URL: From SRyerse at eclipse-networks.com Tue Apr 30 21:45:20 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 1 May 2013 01:45:20 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com><5B9E90747FA2974D9 1A54FCFA1B8AD1201313DA3E4@ENI-MAIL.eclipse-networks.com> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201313DB2BF@ENI-MAIL.eclipse-networks.com> Bill thanks for your question! It means that allocations should be made by a combination of the size of the organization and the size of their network and maybe the total size of their current allocations. There should never be a time when the allocation by Arin is zero. Arin?s mission is to allocate - and it isn?t to not allocate. We run a small data center and we run BGP and should easily be able to qualify for a /22 (which I believe is the current minimum block size Arin allocates per current policy) and maybe even qualify for a /21. We would never and should never qualify for a /17 or a /18 as that is way too big for our size. T-Mobile got something like three quarters of a /8 a while back and of course their company and network size certainly could have justified that. We were denied a /22 allocation ? the minimum size this ?community? has decided to allocate - because of ?policy? and T-Mobile was not denied. That isn?t a level playing field, adjusted for size of course, and all organizations should be able to get right sized allocations without having to meet some arbitrary needs test (and the current needs based allocation policies are very arbitrary) - even if this community wants a needs test for whatever reason. I?ve said many times that Arin?s mission is to allocate first and conserve second - and the conserve part should never override the allocate part of the mission for any reason including IPv4 depletion. I don?t believe this community should be able to override Arin?s mission statement without changing the mission statement first. I used to think that the current needs based policies were put in place to slow IPv4 depletion but now I?m not so sure. I was shocked to see some recent opinions in this forum that actual live installations of IPv6 should not be able to be used to help justify an IPv4 allocation. Wow! I don?t know how wide spread that opinion is in this community but I sure hope it doesn?t prevail. It just shows how crazy any needs based policy really is and that all needs based policies are arbitrary. It cements my belief that the whole Arin Community very much needs and very much would benefit from a major rewrite of all of the needs based policies a la https://www.ripe.net/ripe/policies/proposals/2013-03 I will keep on advocating this as long as I can breathe until sanity prevails. For those who argue that there is no other way to fix IPv4 depletion, I would suggest that the free market will take care of that problem for us. Either IPv6 will get adopted and depletion will be fixed that way - or - the free market will find more IPv4 resources as needed a la http://www.hilcobid.net/auction/listOffers.htm?auction_id=13186&elementsPerPage=25#barranavegacaoleilao I for one prefer that the allocation process work within the charter of Arin - but then I tried that route and was denied. Does this community really want me and many others to go outside because of the arbitrary needs based policies. I guess that is for this community to ultimately decide. From: Bill Darte [mailto:billdarte at gmail.com] Sent: Tuesday, April 30, 2013 7:53 PM To: Steven Ryerse Cc: Alexander, Daniel; Owen DeLong; ARIN-PPML List Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Steven Ryerse wrote: I believe that Arin and this community need to adopt a similar set of policies like have been proposed in Europe https://www.ripe.net/ripe/policies/proposals/2013-03 This would require a wholesale rewrite of a lot of policies which I am not capable of doing - but removing the needs requirements in all policies and just instituting right-sizing policies would be in line with Arin?s mission and be best for all. I would support anyone willing to take the time to submit a proposal to Arin similar to the one above that has been proposed for RIPE. Steven, please tell what right-sizing means to you and how that differs from assigning addresses according to an explicit need... Thanks, bd On Tue, Apr 30, 2013 at 3:34 PM, Steven Ryerse > wrote: I agree with Daniel. I strongly believe it is Arin?s charter and mission to further the Internet and not impede access to it. Debating about what an organization is doing on the Internet or what they are called is really a discussion on how to limit access to the Internet. I don?t believe that Arin should be trying to deny or limit an organization?s access to the Internet. I believe Arin should be trying to expand the Internet for good of everyone as was done before Arin?s existence. I?m all for right sizing an organizations access with reasonable polices but I am not in favor of policies that have the sole purpose of denying or restricting access to the Internet. I believe that Arin and this community need to adopt a similar set of policies like have been proposed in Europe https://www.ripe.net/ripe/policies/proposals/2013-03 This would require a wholesale rewrite of a lot of policies which I am not capable of doing - but removing the needs requirements in all policies and just instituting right-sizing policies would be in line with Arin?s mission and be best for all. I would support anyone willing to take the time to submit a proposal to Arin similar to the one above that has been proposed for RIPE. Steven L Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392-0076 - Fax [Description: Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel Sent: Tuesday, April 30, 2013 3:54 PM To: Owen DeLong; ARIN-PPML List Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user I suggest it is a worthwhile conversation to explore why they will be necessary? If the Internet is a network of networks, why does ARIN, an RIR, need to make the distinctions in how it allocates or assigns resources? Why shouldn't ARIN simply allocate resources to networks, regardless of how they operate simply based on what they need? Are we over complicating things, not only for the Registry, but for those who don't do this for a living who are struggling to understand what all this means and why? This goes back to the original PI/PA debate. There are End User networks that dwarf many ISP/LIR networks and vise versa. Why should we maintain multiple layers of requirements to justify IPv4 transfers and an exceedingly large pool of IPv6 space? -Dan From: Owen DeLong > Date: Tue, 30 Apr 2013 11:36:30 -0700 To: Microsoft Office User > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user Dan, The definitions apply to IPv6 as well. I believe they are still necessary. Owen On Apr 29, 2013, at 20:37 , "Alexander, Daniel" > wrote: Hello All, I would be curious to hear people's opinions of whether the distinctions are still necessary within ARIN policy. Once the IPv4 free pool is depleted, and the policies become focused on processing transfers, do we need to distinguish between End Users, non-End Users, and PA vs PI within ARIN policy? What are the criteria in which these distinctions matter, and will they still apply next year? Dan ARIN AC From: Scott Leibrand > Date: Mon, 29 Apr 2013 13:41:56 -0700 To: ARIN-PPML List > Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user At ARIN 31 last week, Leslie's Policy Experience Report (slides at https://www.arin.net/participate/meetings/reports/ARIN_31/PDF/monday/nobile_policy.pdf or https://www.arin.net/participate/meetings/reports/ARIN_31/PPT/monday/nobile_policy.pptx) reported that, in ARIN staff's experience, the NRPM does not adequately define ISP/LIR vs. end-user. For example, by literally applying the existing definitions as currently written, my employer would be neither an ISP nor and end-user, because while they do not *primarily* assign address space to users, neither do they *exclusively* use it in their own networks. So I think those definitions need a few tweaks. I would propose that the primary difference between ISPs/LIRs vs. end-users, for purposes of the NRPM, is whether an organization reassigns address blocks to third parties. If an organization maintains full control of all of the equipment on its network, and doesn't need to make any reassignments to other organizations, then it can qualify as an end-user. In particular, an end user organization must be able to supply a full list of all the IP addresses in use on its network, and know what devices are using those addresses. An ISP/LIR, on the other hand, should be defined by whether they delegate that responsibility to another organization. In that case, they need to reassign the network space via SWIP/rwhois, which makes them an LIR. I understand that there are other considerations, such as the expectation in the security community that addresses within an ISP allocation are generally controlled by third parties, whereas addresses in an end-user assignment are generally controlled by the end-user organization. However, I don't believe it's practical to try to draw a distinction there: rather, organizations can decide for themselves whether they need to make reassignments (for that or several other reasons), and that decision can drive whether they are considered an ISP/LIR or end-user for purposes of ARIN policy. In light of the above, I would propose the following revised definitions: 2.4. Local Internet Registry (LIR) The terms Internet Service Provider (ISP) and LIR are used interchangeably in this document. A Local Internet Registry (LIR) is an IR that assigns address space to the users of the network services that it provides. Therefore, LIRs / ISPs are organizations that reassign addresses to end users and/or reallocate addresses to other ISPs/LIRs. 2.6. End-user An end-user is an organization receiving assignments of IP addresses exclusively for use in its operational networks, and does not register any reassignments of that space. Thoughts? Should I submit this as a policy proposal? -Scott _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1473 bytes Desc: image001.jpg URL: From jcurran at arin.net Tue Apr 30 23:03:45 2013 From: jcurran at arin.net (John Curran) Date: Wed, 1 May 2013 03:03:45 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201313DB2BF@ENI-MAIL.eclipse-networks.com> References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com> <"B64177493F39BA 4A81233AA84B50049E9B8A9684"@PACDCEXMB12.cable.comcast.com> <"5B9E90747FA2974D9 1A54FCFA1B8AD1201313DA3E4"@ENI-MAIL.eclipse-networks.com> <5B9E90747FA2974D91A54FCFA1B8AD1201313DB2BF@ENI-MAIL.eclipse-networks.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC79128@CHAXCH01.corp.arin.net> On Apr 30, 2013, at 9:45 PM, Steven Ryerse > wrote: It means that allocations should be made by a combination of the size of the organization and the size of their network and maybe the total size of their current allocations. There should never be a time when the allocation by Arin is zero. Arin?s mission is to allocate - and it isn?t to not allocate. We run a small data center and we run BGP and should easily be able to qualify for a /22 (which I believe is the current minimum block size Arin allocates per current policy) and maybe even qualify for a /21. ... We were denied a /22 allocation ? the minimum size this ?community? has decided to allocate - because of ?policy? This is why it is important to remember that such a practice originated even before ARIN's formation, and it is not about conservation of address space as much as it is about encouraging routing aggregation by making use of hierarchical addressing (as described in the following text from RFC 2050, November 1996) - " ISPs who exchange routing information with other ISPs at multiple locations and operate without default routing may request space directly from the regional registry in its geographical area. ... To facilitate hierarchical addressing, implemented using Classless Inter-Domain Routing (CIDR), all other ISPs should request address space directly from its upstream provider. " Whether such a practice is still relevant certainly should be discussed by the community, but encouraging use of address space from the upstream provider has been fundamental principle of the Internet Registry System since inception. ARIN reflects this for IPv4 in NRPM 4.1.1 (General Principles/Routability) and in the initial ISP allocation policy. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From SRyerse at eclipse-networks.com Tue Apr 30 23:28:59 2013 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 1 May 2013 03:28:59 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <8DA1853CE466B041B104C1CAEE00B3748FC79128@CHAXCH01.corp.arin.net> References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com><"B64177493F39B A 4A81233AA84B50049E9B8A9684"@PACDCEXMB12.cable.comcast.com><"5B9E90747FA2974 D91A54FCFA1B8AD1201313DA3E4"@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54F CFA1B8AD1201313DB2BF@ENI-MAIL.eclipse-networks.com> <8DA1853CE466B041B104C1CAEE00B3748FC79128@CHAXCH01.corp.arin.net> Message-ID: <5B9E90747FA2974D91A54FCFA1B8AD1201313DB4AA@ENI-MAIL.eclipse-networks.com> So then the logical question that I would ask is: As a matter of current policy and practice does Arin first require an organization that requests say a /17 to request one first from a larger say /12 upstream before Arin will allocate the block, or maybe a /14 from an upstream /8, or /whatever from a larger upstream /whatever? What if the larger upstream refuses the smaller organization the requested size block? Does Arin require larger allocation holders to honor smaller allocation requests as a condition of their allocation? What about an organization who runs BGP and needs an independent block but their upstream doesn't want to permanently give them what they consider a large portion of their own assigned block because it is somewhat difficult for them to get more resources from Arin? And most importantly if this is current policy, does Arin actually enforce it every time for every organization no matter what their size or the size of their request? If not then fair is fair and everyone should be treated equally albeit adjusted for their size and the size of their request. From: John Curran [mailto:jcurran at arin.net] Sent: Tuesday, April 30, 2013 11:04 PM To: Steven Ryerse Cc: ARIN-PPML List Subject: Re: [arin-ppml] Clean up definition of LIR/ISP vs. end-user On Apr 30, 2013, at 9:45 PM, Steven Ryerse > wrote: It means that allocations should be made by a combination of the size of the organization and the size of their network and maybe the total size of their current allocations. There should never be a time when the allocation by Arin is zero. Arin's mission is to allocate - and it isn't to not allocate. We run a small data center and we run BGP and should easily be able to qualify for a /22 (which I believe is the current minimum block size Arin allocates per current policy) and maybe even qualify for a /21. ... We were denied a /22 allocation - the minimum size this "community" has decided to allocate - because of "policy" This is why it is important to remember that such a practice originated even before ARIN's formation, and it is not about conservation of address space as much as it is about encouraging routing aggregation by making use of hierarchical addressing (as described in the following text from RFC 2050, November 1996) - " ISPs who exchange routing information with other ISPs at multiple locations and operate without default routing may request space directly from the regional registry in its geographical area. ... To facilitate hierarchical addressing, implemented using Classless Inter-Domain Routing (CIDR), all other ISPs should request address space directly from its upstream provider. " Whether such a practice is still relevant certainly should be discussed by the community, but encouraging use of address space from the upstream provider has been fundamental principle of the Internet Registry System since inception. ARIN reflects this for IPv4 in NRPM 4.1.1 (General Principles/Routability) and in the initial ISP allocation policy. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Apr 30 23:34:21 2013 From: jcurran at arin.net (John Curran) Date: Wed, 1 May 2013 03:34:21 +0000 Subject: [arin-ppml] Clean up definition of LIR/ISP vs. end-user In-Reply-To: <5B9E90747FA2974D91A54FCFA1B8AD1201313DB4AA@ENI-MAIL.eclipse-networks.com> References: <0AA40348-4CD0-4896-8639-D46ED2022D21@delong.com><"B64177493F39B A 4A81233AA84B50049E9B8A9684"@PACDCEXMB12.cable.comcast.com><"5B9E90747FA2974 D91A54FCFA1B8AD1201313DA3E4"@ENI-MAIL.eclipse-networks.com><5B9E90747FA2974D91A54F CFA1B8AD1201313DB2BF@ENI-MAIL.eclipse-networks.com> <8DA1853CE466B041B104C1CAEE00B3748FC79128@CHAXCH01.corp.arin.net> <5B9E90747FA2974D91A54FCFA1B8AD1201313DB4AA@ENI-MAIL.eclipse-networks.com> Message-ID: <8DA1853CE466B041B104C1CAEE00B3748FC79286@CHAXCH01.corp.arin.net> On Apr 30, 2013, at 11:28 PM, Steven Ryerse > wrote: So then the logical question that I would ask is: As a matter of current policy and practice does Arin first require an organization that requests say a /17 to request one first from a larger say /12 upstream before Arin will allocate the block, or maybe a /14 from an upstream /8, or /whatever from a larger upstream /whatever? What if the larger upstream refuses the smaller organization the requested size block? Does Arin require larger allocation holders to honor smaller allocation requests as a condition of their allocation? What about an organization who runs BGP and needs an independent block but their upstream doesn?t want to permanently give them what they consider a large portion of their own assigned block because it is somewhat difficult for them to get more resources from Arin? And most importantly if this is current policy, does Arin actually enforce it every time for every organization no matter what their size or the size of their request? If not then fair is fair and everyone should be treated equally albeit adjusted for their size and the size of their request. Steven - There is an initial allocation policy (which ISPs must meet to receive their first allocation from ARIN), and then there is additional ISP allocation policy applies to all future requests. This is regardless of the size of the request or size of the organization requesting. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: