From spiffnolee at yahoo.com Wed Feb 2 15:23:30 2011 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 2 Feb 2011 12:23:30 -0800 (PST) Subject: [arin-ppml] projections Message-ID: <509417.80831.qm@web63304.mail.re1.yahoo.com> Silence on PPML for two days? Nothing going on that people want to talk about on PPML? For those who missed it, this chart is interesting: http://www.potaroo.net/tools/ipv4/rir.jpg But I caution readers to temper it with this chart: http://www.potaroo.net/tools/ipv4/predict.png (i.e., accelerating demand is likely to trigger those events sooner) Lee From cgrundemann at gmail.com Wed Feb 2 15:46:27 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 2 Feb 2011 13:46:27 -0700 Subject: [arin-ppml] projections In-Reply-To: <509417.80831.qm@web63304.mail.re1.yahoo.com> References: <509417.80831.qm@web63304.mail.re1.yahoo.com> Message-ID: On Wed, Feb 2, 2011 at 13:23, Lee Howard wrote: > Silence on PPML for two days? > Nothing going on that people want to talk about on PPML? > > For those who missed it, this chart is interesting: > http://www.potaroo.net/tools/ipv4/rir.jpg A note on that graph from the horse's mouth that is worth considering, especially as it relates to inter-RIR transfer policy: "This is a different graph - it is a probabilistic graph that shows the predicted month when the RIR will be down to its last /8 policy (whatever that policy may be), and the relative probability that the event will occur in that particular month. The assumption behind this graph is that the barricades will go up across the regions and each region will work from its local address pools and service only its local client base, and that as each region gets to its last /8 policy the applicants will not transfer their demand to those regions where addresses are still available. Its not possible to quantify how (in)accurate this assumption may be, so beyond the prediction of the first exhaustion point (which is at this stage looking more likely to occur in July 2011 than not) the predictions for the other RIRs are highly uncertain." http://mailman.nanog.org/pipermail/nanog/2011-February/031788.html ~Chris > But I caution readers to temper it with this chart: > http://www.potaroo.net/tools/ipv4/predict.png > > (i.e., accelerating demand is likely to trigger those events sooner) > > Lee > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From alh-ietf at tndh.net Wed Feb 2 16:28:50 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 2 Feb 2011 13:28:50 -0800 Subject: [arin-ppml] projections In-Reply-To: References: <509417.80831.qm@web63304.mail.re1.yahoo.com> Message-ID: <16dd01cbc320$30f678a0$92e369e0$@net> There is no reasonable way to correlate the reality that APnic handed out 2.3 /8's in the last 2 months, and are sitting on ~3, with the idea that they will survive until July/Aug. The only way you can get there is a linear projection off of a long data history to drop the slope below 1/2 /8 per month. Events will occur well before July. Tony http://www.tndh.net/~tony/ietf/IPv4-rir-pools-zoom.pdf > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Wednesday, February 02, 2011 12:46 PM > To: Lee Howard > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] projections > > On Wed, Feb 2, 2011 at 13:23, Lee Howard wrote: > > Silence on PPML for two days? > > Nothing going on that people want to talk about on PPML? > > > > For those who missed it, this chart is interesting: > > http://www.potaroo.net/tools/ipv4/rir.jpg > > A note on that graph from the horse's mouth that is worth considering, > especially as it relates to inter-RIR transfer policy: > > "This is a different graph - it is a probabilistic graph that shows > the predicted month when the RIR will be down to its last /8 policy > (whatever that policy may be), and the relative probability that the > event will occur in that particular month. > > The assumption behind this graph is that the barricades will go up > across the regions and each region will work from its local address > pools and service only its local client base, and that as each region > gets to its last /8 policy the applicants will not transfer their > demand to those regions where addresses are still available. Its not > possible to quantify how (in)accurate this assumption may be, so > beyond the prediction of the first exhaustion point (which is at this > stage looking more likely to occur in July 2011 than not) the > predictions for the other RIRs are highly uncertain." > > http://mailman.nanog.org/pipermail/nanog/2011-February/031788.html > > ~Chris > > > But I caution readers to temper it with this chart: > > http://www.potaroo.net/tools/ipv4/predict.png > > > > (i.e., accelerating demand is likely to trigger those events sooner) > > > > Lee > > > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From z0ink at yahoo.com Wed Feb 2 16:42:35 2011 From: z0ink at yahoo.com (lucas karisny) Date: Wed, 2 Feb 2011 13:42:35 -0800 (PST) Subject: [arin-ppml] ping Message-ID: <260871.7314.qm@web111108.mail.gq1.yahoo.com> n/t - From arin-mail at AegisInfoSys.com Wed Feb 2 17:54:34 2011 From: arin-mail at AegisInfoSys.com (Henry Yen) Date: Wed, 2 Feb 2011 17:54:34 -0500 Subject: [arin-ppml] projections In-Reply-To: <509417.80831.qm@web63304.mail.re1.yahoo.com> References: <509417.80831.qm@web63304.mail.re1.yahoo.com> Message-ID: <20110202225434.GK28104@nntp.AegisInfoSys.com> FWIW, "lists.arin.net", the outbound mailserver, lost its reverse DNS as of Sunday night; this is a likely factor in overall non-deliverability. On Wed, Feb 02, 2011 at 12:23:30PM -0800, Lee Howard wrote: > Silence on PPML for two days? -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York From bill at herrin.us Thu Feb 3 13:49:54 2011 From: bill at herrin.us (William Herrin) Date: Thu, 3 Feb 2011 13:49:54 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: Note: moved this to the ARIN PPML list from NANOG. On Thu, Feb 3, 2011 at 11:54 AM, John Curran wrote: > For the ARIN region, it would be nice to know how you'd like ARIN perform > in the presence of such activity ("leasing" IP addresses by ISP not providing > connectivity). ?It's possible that such is perfectly reasonable and to simply > be ignored, it's also possible that such should be considered a fraudulent > transfer and the resources reclaimed. ?At the end of the day, the policy is > set by this community, and clarity over ambiguity is very helpful. Options: 1. Whatever arrangements work out in the market are fine, including leasing. Pros: Noninterference. Let's the market do its thing. Cons: Contrary to the needs basis we've adhered to for the last 20 years. The the end user needs the addresses enough to pay the price and the lessor can spare them then obviously the end user needs those addresses, not the lessor. 2. Address leasing is not allowed. Must get your addresses from a primary or at least major bandwidth provider. Addresses found to be leased or provided in with a paper-tiger transit arrangement are subject to reclamation by ARIN. Pros: Keeps the market more or less honest. IP addresses are a public resource; they don't belong to you. As incentive to put your uneeded addresses back into the supply, you're allowed to sell them at market... but you don't get to be like the landlords of Europe that prompted the 19th century emigration to the Americas, refusing to sell to the folks living on the land at any price. Cons: Unenforceable. 3. Any multihomed registrant using an ARIN AS number and SWIPed for at least one year with a /24 or larger is entitled to convert the registration to an ARIN direct assignment upon filing the proper paperwork. Refusing SWIP or assigning addresses out of region is grounds for reclamation. Pros: Lets the original registrant earn his money but guarantees that address assignments will move towards the multihomed end users. Cons: Fragmentation. No way to ever move growing entities from individual /24's to aggregable address blocks. Have to hope the IPv6 migration solves this problem before it can get serious. Also, it implies a change in ISP's internal routing management. These new registrations are functionally different from older direct registrations - they'll likely still be subject to some ISP's covering route, even though they're no longer used with that ISP. Any other sensible ways to slice and dice the issue? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Thu Feb 3 13:59:04 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 3 Feb 2011 10:59:04 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: <20110203185904.GA78738@ussenterprise.ufp.org> In a message written on Thu, Feb 03, 2011 at 01:49:54PM -0500, William Herrin wrote: > Any other sensible ways to slice and dice the issue? Well, one is to recognize at least one form of this happens now, and the parties are sometimes ok with it. I've seen folks multi-home using PA space (with the providers blessing) and then drop the provider who gave them the space. Depending on the relationship I've seen grace periods as long as 12 months to renumber out of the space. During that time they are effectively "leasing" only the space with no transit. I'm not sure if we ned to take action in this space or not, but if the action makes this sort of semi-common arrangement against the letter of the law it will significantly weaken people's opinion of the rules. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From scottleibrand at gmail.com Thu Feb 3 15:19:42 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 3 Feb 2011 12:19:42 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: I would be very reluctant to make any rules around this, at least until we have real-world examples of leasing behavior causing significant issues that can't be dealt with through normal processes. As long as number resources are being put to productive use, and the whois database is kept up-to-date with regards to who's actually using the space, I'd be hesitant to try to micromanage the arrangements between consenting parties... -Scott On Thu, Feb 3, 2011 at 10:49 AM, William Herrin wrote: > Note: moved this to the ARIN PPML list from NANOG. > > On Thu, Feb 3, 2011 at 11:54 AM, John Curran wrote: > > For the ARIN region, it would be nice to know how you'd like ARIN perform > > in the presence of such activity ("leasing" IP addresses by ISP not > providing > > connectivity). It's possible that such is perfectly reasonable and to > simply > > be ignored, it's also possible that such should be considered a > fraudulent > > transfer and the resources reclaimed. At the end of the day, the policy > is > > set by this community, and clarity over ambiguity is very helpful. > > Options: > > 1. Whatever arrangements work out in the market are fine, including > leasing. > > Pros: Noninterference. Let's the market do its thing. > > Cons: Contrary to the needs basis we've adhered to for the last 20 > years. The the end user needs the addresses enough to pay the price > and the lessor can spare them then obviously the end user needs those > addresses, not the lessor. > > > 2. Address leasing is not allowed. Must get your addresses from a > primary or at least major bandwidth provider. Addresses found to be > leased or provided in with a paper-tiger transit arrangement are > subject to reclamation by ARIN. > > Pros: Keeps the market more or less honest. IP addresses are a public > resource; they don't belong to you. As incentive to put your uneeded > addresses back into the supply, you're allowed to sell them at > market... but you don't get to be like the landlords of Europe that > prompted the 19th century emigration to the Americas, refusing to sell > to the folks living on the land at any price. > > Cons: Unenforceable. > > > 3. Any multihomed registrant using an ARIN AS number and SWIPed for at > least one year with a /24 or larger is entitled to convert the > registration to an ARIN direct assignment upon filing the proper > paperwork. Refusing SWIP or assigning addresses out of region is > grounds for reclamation. > > Pros: Lets the original registrant earn his money but guarantees that > address assignments will move towards the multihomed end users. > > Cons: Fragmentation. No way to ever move growing entities from > individual /24's to aggregable address blocks. Have to hope the IPv6 > migration solves this problem before it can get serious. Also, it > implies a change in ISP's internal routing management. These new > registrations are functionally different from older direct > registrations - they'll likely still be subject to some ISP's covering > route, even though they're no longer used with that ISP. > > > Any other sensible ways to slice and dice the issue? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From khelms at zcorum.com Thu Feb 3 15:24:46 2011 From: khelms at zcorum.com (Scott Helms) Date: Thu, 03 Feb 2011 15:24:46 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers Message-ID: <4D4B0F0E.2080308@zcorum.com> Options: > 1. Whatever arrangements work out in the market are fine, including leasing. > > Pros: Noninterference. Let's the market do its thing. > > Cons: Contrary to the needs basis we've adhered to for the last 20 > years. The the end user needs the addresses enough to pay the price > and the lessor can spare them then obviously the end user needs those > addresses, not the lessor. We currently (and have for a number of years) leased IP space to ISPs who didn't have the ability or desire to qualify for their own ARIN disbursement. All of our customers for this service are retail ISPs, mainly small and mid size telco and cable companies, and pass through all of the requirements for utilization and documentation that ARIN puts on us. In all cases the blocks are properly SWIPed (either reassign or reallocate). We charge a minimal fee for record keeping on an annual basis. Our reason for providing this service was to reduce the disruption and work that needed to be done every time one of our ISP customers decided to swap to a cheaper bandwidth provider. > > 2. Address leasing is not allowed. Must get your addresses from a > primary or at least major bandwidth provider. Addresses found to be > leased or provided in with a paper-tiger transit arrangement are > subject to reclamation by ARIN. > > Pros: Keeps the market more or less honest. IP addresses are a public > resource; they don't belong to you. As incentive to put your uneeded > addresses back into the supply, you're allowed to sell them at > market... but you don't get to be like the landlords of Europe that > prompted the 19th century emigration to the Americas, refusing to sell > to the folks living on the land at any price. > > Cons: Unenforceable. I think its probably unenforceable and I doubt we are the only organization doing reassigns for legitimate reasons. How you could separate out an organization like ours from, which has been providing IP space for ~5 years at little over cost to organizations jumping in and trying to profit from their suddenly valuable IPv4 space? In our case the smaller ISPs we are providing this service to don't want a direct disbursement and in the only case we've had where a customer wanted to convert we helped them do just that. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- Looking for hand-selected news, views and tips for independent broadband providers? Follow us on Twitter! http://twitter.com/ZCorum -------------------------------- From bill at herrin.us Thu Feb 3 15:58:55 2011 From: bill at herrin.us (William Herrin) Date: Thu, 3 Feb 2011 15:58:55 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: On Thu, Feb 3, 2011 at 3:19 PM, Scott Leibrand wrote: > I would be very reluctant to make any rules around this, at least until we > have real-world examples of leasing behavior causing significant issues that > can't be dealt with through normal processes.? As long as number resources > are being put to productive use, and the whois database is kept up-to-date > with regards to who's actually using the space, I'd be hesitant to try to > micromanage the arrangements between consenting parties... Hi Scott, Call that option 4? 4. Wait and see whether addresses are reasonably available for purchase before considering policy related to address leasing. Pros: If it ain't broke... Cons: Disruption postponed is disruption increased. -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Thu Feb 3 16:02:34 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Feb 2011 13:02:34 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: <4D4B17EA.4070600@ipinc.net> I concur 100%. If your in favor of reclamation or other stretching out of IPv4 usage then leasing arrangements allow unused IPv4 to go into use. If your opposed to reclamation and just want IPv6 to go on as soon as possible, then leasing arrangements help to drive up the cost of IPv4 much more rapidly as they allow orgs to monetize IPv4. The real losers in any IPv4 leasing arrangement are the ISP's that are the actual lessors. The problem is that those ISP's don't believe that they are losing when they are able to get additional IPv4. They are convinced that their future is rolling out more IPv4 so they sink a lot of capital into leasing IPv4 from others - instead of sinking it into building out their IPv6 presence. So then what will happen is that when the day comes that IPv6 becomes de rigueur, those leasing ISP's will be so invested in an obsolete infrastructure that they will quickly go out of business. That will then take choice away from customers who will then be forced into IPv6. Once those customers make the transition they will never go back and will just increase pressure for everyone to go to IPv6. So what's not to like about such arrangements? Ted PS Historical instruction can be obtained by examining the VHS vs Betamax wars. For a while both formats had equal market share - but when the customers in the market all SENSED the inevitability of VHS, then within a very short time Betamax disappeared - much to the consternation of betamax users who had invested significantly in it. On 2/3/2011 12:19 PM, Scott Leibrand wrote: > I would be very reluctant to make any rules around this, at least until > we have real-world examples of leasing behavior causing significant > issues that can't be dealt with through normal processes. As long as > number resources are being put to productive use, and the whois database > is kept up-to-date with regards to who's actually using the space, I'd > be hesitant to try to micromanage the arrangements between consenting > parties... > > -Scott > > On Thu, Feb 3, 2011 at 10:49 AM, William Herrin > wrote: > > Note: moved this to the ARIN PPML list from NANOG. > > On Thu, Feb 3, 2011 at 11:54 AM, John Curran > wrote: > > For the ARIN region, it would be nice to know how you'd like ARIN > perform > > in the presence of such activity ("leasing" IP addresses by ISP > not providing > > connectivity). It's possible that such is perfectly reasonable > and to simply > > be ignored, it's also possible that such should be considered a > fraudulent > > transfer and the resources reclaimed. At the end of the day, the > policy is > > set by this community, and clarity over ambiguity is very helpful. > > Options: > > 1. Whatever arrangements work out in the market are fine, including > leasing. > > Pros: Noninterference. Let's the market do its thing. > > Cons: Contrary to the needs basis we've adhered to for the last 20 > years. The the end user needs the addresses enough to pay the price > and the lessor can spare them then obviously the end user needs those > addresses, not the lessor. > > > 2. Address leasing is not allowed. Must get your addresses from a > primary or at least major bandwidth provider. Addresses found to be > leased or provided in with a paper-tiger transit arrangement are > subject to reclamation by ARIN. > > Pros: Keeps the market more or less honest. IP addresses are a public > resource; they don't belong to you. As incentive to put your uneeded > addresses back into the supply, you're allowed to sell them at > market... but you don't get to be like the landlords of Europe that > prompted the 19th century emigration to the Americas, refusing to sell > to the folks living on the land at any price. > > Cons: Unenforceable. > > > 3. Any multihomed registrant using an ARIN AS number and SWIPed for at > least one year with a /24 or larger is entitled to convert the > registration to an ARIN direct assignment upon filing the proper > paperwork. Refusing SWIP or assigning addresses out of region is > grounds for reclamation. > > Pros: Lets the original registrant earn his money but guarantees that > address assignments will move towards the multihomed end users. > > Cons: Fragmentation. No way to ever move growing entities from > individual /24's to aggregable address blocks. Have to hope the IPv6 > migration solves this problem before it can get serious. Also, it > implies a change in ISP's internal routing management. These new > registrations are functionally different from older direct > registrations - they'll likely still be subject to some ISP's covering > route, even though they're no longer used with that ISP. > > > Any other sensible ways to slice and dice the issue? > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com > bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > > _______________________________________________ > 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 gbonser at seven.com Thu Feb 3 16:21:51 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 3 Feb 2011 13:21:51 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net><712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> >? As long as number resources are being put to productive use, > and the whois database is kept up-to-date with regards to > who's actually using the space, I'd be hesitant to try to > micromanage the arrangements between consenting parties... I agree with this. Unless something is broken, ARIN has enough to do without attempting to enforce philosophical positions. The thing is that allocations from ARIN are based on the conditions that existed at the time the resources were allocated. Say someone qualified for a /16 and got it, then used it for a number of years but 15 years later find their business has shrunk and they aren't using all of that allocation anymore. Now they certainly wouldn't qualify for a new allocation but I am not aware of any policy (not saying one doesn't exist, just saying that I am not aware of any) that requires a regular audit and periodic re-justification of issued resources. One might easily have a few scattered /24 nets within a larger allocation that they don't plan to use for a while. Those now become a potential source of revenue. I see nothing wrong or "dishonest" with allowing someone else to use such a block provided the network leasing the space legitimately qualifies for the space and isn't simply some "snowshoe" spammer looking to churn through address space. There comes the rub but it is really no different than the situation today. I would guess that most of the IP address leasing today (noting exceptions mentioned in this thread) are people who for one reason or another either wouldn't qualify for a direct allocation or don't want to go through the paperwork. That will change after runout to include people who *do* qualify for more space but it isn't available. So the bottom line is that I don't believe the problem will get worse than it currently is because as it stands today the majority of the people "leasing" IP address resources are people who wouldn't get it otherwise. After runout that percentage will change and most of the leasing would be from people who are just fine but can't get the resources otherwise. The "bad guys" are already doing it. This proposal would just make it harder for the "good guys" after runout. From info at arin.net Thu Feb 3 16:44:40 2011 From: info at arin.net (ARIN) Date: Thu, 03 Feb 2011 16:44:40 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 Message-ID: <4D4B21C8.9090506@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) held a meeting on 28 January 2011 and made decisions about several draft policies and proposals. The AC recommended that the ARIN Board of Trustees adopt the following draft policy: ARIN-2010-14: Standardize IP Reassignment Registration Requirements The AC selected the following proposals as draft policies for adoption discussion online and at the ARIN XXVII Public Policy Meeting in San Juan, Puerto Rico. Each draft policy will be posted shortly to the PPML. ARIN-prop-119. Globally Coordinated Transfer Policy ARIN-prop-120. Protecting Number Resources ARIN-prop-121. Better IPv6 Allocation for ISPs ARIN-prop-123. Reserved Pool for Critical Infrastructure ARIN-prop-127. Shared Transition Space for IPv4 Address Extension The AC added the following proposal to their docket but decided not to select it as a draft policy at this time: ARIN-prop-126. Compliance Requirement The AC abandoned the following proposals: ARIN-prop-128. Replacement of Section 4.2.4.4 ARIN-prop-129. IPv4 Addresses for Process Participants ARIN-prop-130. IPv4 Transition Reservation for Every ASN The AC abandoned ARIN-prop-128 due to opposition on the list, and because there is insufficient time to implement the proposal through the normal PDP. As a result, the proposal would need to be a Board Emergency PDP action to have any effect. The AC understands that the use of the emergency process requires that there be significant risk to ARIN should the Board allow a situation to continue. This matter does not warrant the use of the emergency process. The AC abandoned ARIN-prop-129 and ARIN-prop-130 because they violate the community principle of needs-based assignments. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? Proposals 126, 128, 129 and 130 may be petitioned (Discussion Petition) to try to change them into draft policies for adoption discussion on the Public Policy Mailing List and at the April Public Policy Meeting. 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 Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Thu Feb 3 16:48:15 2011 From: info at arin.net (ARIN) Date: Thu, 03 Feb 2011 16:48:15 -0500 Subject: [arin-ppml] Draft Policy 2011-1: Globally Coordinated Transfer Policy Message-ID: <4D4B229F.6010301@arin.net> Draft Policy ARIN-2011-1 Globally Coordinated Transfer Policy On 28 January 2011 the ARIN Advisory Council (AC) selected "Globally Coordinated Transfer Policy" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-119. Globally Coordinated Transfer Policy". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2011-1 is below and can be found at: https://www.arin.net/policy/proposals/2011_1.html You are encouraged to discuss Draft Policy 2011-1 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-1 Globally Coordinated Transfer Policy Version/date: 23 December 2011 Policy statement: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. Rationale: Since individual RIRs now allow transfers, it makes sense to be able to transfer between regions as well. Timetable for implementation: upon ratification by the ARIN Board of Trustees ##### STAFF ASSESSMENT Proposal: Globally Coordinated Transfer Policy Policy Version (Date): 23 December 2010 Date of Assessment: 10 January 2011 1. Proposal Summary (Staff Understanding) This proposal would allow a registrant of IPv4 addresses from one RIR to transfer those resources to a registrant (or future registrant) of another RIR as long as both RIRs agree to the transfer, and apply compatible, needs-based policies in accordance with the stewardship principles expressed in RFC 2050. 2. Comments A. ARIN Staff Comments 1. This policy seems to directly contradict NRPM 8.3, Transfers to Specified Recipients which disallows IPv4 number resources to be transferred outside of ARIN?s region. Without a change to NRPM 8.3, ARIN would only be able to apply NRPM 8.2, Mergers and Acquisitions when reviewing inter-RIR policies. 2. The staff would implement this policy in the following manner: a. For transfers from the ARIN region into another RIR region, ARIN would: o Confirm that the other RIR has "compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC 2050 o Apply the relevant ARIN transfer policy criteria to the resource registrant o Seek confirmation from the other RIR that the requesting organization is physically located and has a verified legal presence in the region o Closely coordinate with the other RIR, informing them when ARIN is ready to complete the transfer o Complete transfer upon confirmation from the other RIR that the recipient has met that RIR?s applicable transfer policies b. For transfers into the ARIN region from another RIR region, ARIN would: o Confirm that the other RIR has "compatible, needs-based transfer policies that exercise Internet stewardship is consistent with the values expressed in expressed in RFC2050" o Apply the relevant ARIN transfer policy criteria to the resource recipient o Verify that the requesting organization is physically located and has a verified legal presence in the region o Closely coordinate with the other RIR, informing them when ARIN is ready to complete the transfer o Complete transfer upon confirmation from the other RIR that the registrant has met that RIR?s applicable transfer policies 3. This proposal allows the transfer of any IPv4 resource, whether it be Legacy/ERX address space or address space that was directly delegated to the RIR by IANA. Allowing the transfer of directly delegated number resources between RIRs could cause a variety of issues including: ? Zone fragmentation ? DNS synchronization problems ? Potential administrative and operational issues in coordinating reverse addressing 4. The phrasing "to the resource registrant of another RIR" might be made more accurate if the word ?resource? was dropped and just the words ?to the registrant of another RIR? were retained. The recipient of a resource transfer may not already have resources registered. This rephrasing would make it clear that you have to be registered with the RIR, but not necessarily be a current resource holder to utilize this policy. 5. The text implies that the resources being transferred go directly from Registrant>Recipient rather than from Registrant>RIR A>RIR B>Recipient. If the space gets transferred directly from registrant to recipient without coming back to the RIR first, it is unclear which RIR is ultimately authoritative for the space. B. ARIN General Counsel o First, I suggest one major addition to this policy which may be totally consistent with the drafter's intent. Currently, it is my understanding that ARIN policy does not permit transfers within the region unless the resources are covered by RSA or LRSA. The language of this section might properly be clarified to reinforce the requirement that the resources be put under LRSA (or RSA) before they are transferred. o Second, in addition, I believe the word 'compatible' might better be described as 'comparable'. o Third, don't we have to make the transfer to a specific registrant 'thru' the other RIR and not directly to that recipient from ARIN? I made some other suggestions on language in caps for you to consider: ?Any RIR's resource [RSA OR LRSA] registrant may transfer IPv4 addresses to a SPECIFIC resource registrant of another RIR, THRU THAT RIR, so long as the RECEIVING RIR agrees to and maintains comparable, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. NO TRANSFER MAY BE MADE TO AN RIR THAT DOES NOT MAINTAIN COMPARABLE NEEDS-BASED TRANSFER POLICIES CONSISTENT WITH THE VALUES IN RFC2050.? As drafted this policy has no 'out': for example, it does not on its face permit ARIN to refuse a transfer because the recipient is someone who violates US or the recipient country's laws; or violates other ARIN policies. Do you want any flexibility built in to permit ARIN staff to refuse an inter-region transfer if it would refuse an intra-region transfer? I am not sure such a right to refuse is implied or could be exercised. 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. However, maintaining the policy is another matter and could require significant (human) resources to carry out the potential increase in inter-RIR transfers. The following would be needed in order to implement: ? Updated guidelines ? Staff training ? Careful coordination between RIRs on reverse addressing issues 4. Proposal Text Policy statement: Any RIR's resource registrant may transfer IPv4 addresses to the resource registrant of another RIR as long as the two RIRs agree and maintain compatible, needs-based transfer policies that exercise Internet stewardship consistent with the values expressed in RFC2050. Rationale: Since individual RIRs now allow transfers, it makes sense to be able to transfer between regions as well. From info at arin.net Thu Feb 3 16:48:30 2011 From: info at arin.net (ARIN) Date: Thu, 03 Feb 2011 16:48:30 -0500 Subject: [arin-ppml] Draft Policy 2011-2: Protecting Number Resources Message-ID: <4D4B22AE.7020603@arin.net> Draft Policy ARIN-2011-2 Protecting Number Resources On 28 January 2011 the ARIN Advisory Council (AC) selected "Protecting Number Resources" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-120. Protecting Number Resources". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2011-2 is below and can be found at: https://www.arin.net/policy/proposals/2011_2.html You are encouraged to discuss Draft Policy 2011-2 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-2 Protecting Number Resources Version/Date: 28 January 2011 Policy statement: ARIN shall use any reasonable and practical methods to proactively look for fraudulently obtained or abandoned number resources and seek the return of those resources to ARIN. Abandoned resources include, but are not limited to: * resources with no valid POC (per section 3.6), * resources assigned or allocated to a deceased individual, * resources assigned or allocated to a defunct or otherwise no longer viable entity, and * resources declared unused or abandoned by the organization to which they are allocated. A report of activities under this policy shall be delivered at each ARIN meeting. Rationale: ARIN has generally only reactively looked for fraudulently obtained or abandoned number resources, generally via reports to https://www.arin.net/resources/fraud/. Taking these community reports is a good first step, but ARIN can be in a far better position to know which resources were fraudulently obtained or abandoned due to the additional paperwork that ARIN holds which is not available to the public, and the record of interactions (or lack thereof) with the resource holder. Implementation suggestions: It is expected that the board/executive management will interpret "reasonable and practical" to mean "some amount of staff time that is not zero", but will also be fiscally viable, and to direct reviews in such a way as to provide the community a good return on invested resources. For example, ARIN could check resources without a valid POC, reclaim resources that aren't being routed, and contact the announcing/upstream ASNs of any resources that are being routed to implement record updates or to implement section 8 transfers as appropriate. The next lowest hanging fruit might be prefixes that were originally visible in the routing table, but have not been present for a long time. ARIN should also 1) report on the aggregate quantity of number resources that were returned due to this proactive activity, 2) report on the aggregate cost to the members of this activity, and 3) obtain feedback from the membership as to whether more or less resources should be devoted to this endeavor. Resources in use by a successor organization should not be considered abandoned, but may be reviewed as appropriate via the processes outlined in current ARIN policy (for example, sections 8.2 or 12 of the NRPM). ARIN should attempt to contact all known POCs for a block, and only determine that it is abandoned if no POC indicates it is still in use. If a BGP advertisement for the resource in question is visible in the Internet routing table, ARIN should attempt to contact the organization responsible for the advertising ASN, as well as any organizations seen to be providing transit services for the resource, to inform them that the resource is being considered for abandoned status. At least 30 days before reclaiming any number resource, ARIN should publicly announce their declaration that the resource is considered abandoned, and shall reconsider such declaration if additional information is provided to ARIN about the use of the resource in question. Timetable for implementation: immediate ##### STAFF ASSESSMENT Proposal: ?Protecting Number Resources? (pp 120) Policy Version (Date): 9 January 2011 Date of Assessment: 27 January 2011 1. Proposal Summary (Staff Understanding) This policy directs ARIN to pro-actively identify and research abandoned, unused, or fraudulently obtained number resources for the purposes of trying to reclaim them when appropriate. It would require staff to report on the activities associated with this policy (without improperly disclosing details of individual matters) during ARIN?s Public Policy meetings. 2. Comments A. ARIN Staff Comments ? Based on staff?s experience with resource reclamations and revocations, the process of identifying and reclaiming resources (especially due to fraud or misuse) can take anywhere from a few days to several weeks from start to finish, so there will be a significant time factor involved. ? Given the current workload at ARIN and the limited number of staff available to do this type of work, additional experienced staff would be needed before this policy could be fully implemented. ? This policy could have very significant financial implications due to the need for additional staff, the time involved in identifying, researching, and reclaiming these resources, and the potential additional legal fees involved for review. ? Reclaiming legacy resources is more complex than reclaiming ARIN issued resources. Therefore, ARIN staff would need to carefully consider this complexity when determining which number resources to seek out first. ? Staff will need to develop detailed, well thought out, and well-documented procedures due to the potential legal issues involved in reclaiming resources. B. ARIN General Counsel No legal comments 3. Resource Impact This policy would have a moderate resource impact from an initial implementation aspect. It is estimated that implementation would occur within 6 ? 9 months after ratification by the ARIN Board of Trustees. However, this policy will have a significant resource impact from an execution aspect. Based on our experience with resource reclamations and revocations, the process of identifying and reclaiming resources (especially due to fraud or misuse) takes a great deal of time from start to finish. It requires significant research, documentation, and fact checking. A single fraudulent event can take a number of days or weeks, to properly fact-find and document. The following would be needed in order to implement and fulfill: ? Updated documentation on the ARIN website ? Significant staff training ? Additional staff to proactively seek, research and reclaim unused IP number resources ?Software development to create new tools to assist in identifying unused resources 4. Proposal Text Policy statement: ARIN shall use any reasonable and practical methods to proactively look for fraudulently obtained or abandoned number resources and seek the return of those resources to ARIN. Abandoned resources include, but are not limited to, resources with no valid POC (per section 3.6), resources assigned or allocated to a deceased, defunct, or otherwise no longer viable entity, and resources declared unused or abandoned by the organization to which they are allocated. A report of activities under this policy shall be delivered at each ARIN meeting. Rationale: ARIN has generally only reactively looked for fraudulently obtained or abandoned number resources, generally via reports to https://www.arin.net/resources/fraud/ www.arin.net/resources/fraud/ > . Taking these community reports is a good first step, but ARIN can be in a far better position to know which resources were fraudulently obtained or abandoned due to the additional paperwork that ARIN holds which is not available to the public, and the record of interactions (or lack thereof) with the resource holder. Implementation suggestions: It is expected that the board/executive management will interpret reasonable and practical to be some amount of staff time that is not zero, but will also not "break the bank". For example, ARIN could first check resources with no valid POCs, reclaim the ones that aren't being routed, and contact the announcing/upstream ASNs of any that are being routed to get records updated or section 8 transfers completed. The next lowest hanging fruit might be prefixes that were originally visible in the routing table, but have not been present for a long time. ARIN should also report on the aggregate quantity of number resources that were returned due to this proactive activity, as well as the aggregate cost to the members of this activity, and obtain feedback from the membership as to whether more or less resources should be used in this area. Resources in use by a successor organization should not be considered abandoned, but may be reviewed as appropriate via the processes outlined in current ARIN policy (for example, sections 8.2 or 12 of the NRPM). ARIN should attempt to contact all known POCs for a block, and only declare that it is abandoned if no POC contradicts the claim. If a BGP advertisement for the resource in question is visible in the Internet routing table, ARIN should attempt to contact the organization responsible for the advertising ASN, as well as any ASNs seen to be providing transit services for the resource, to inform them that the resource is being considered for abandoned status. At least 30 days before reclaiming any number resource, ARIN should publicly announce their declaration that the resource is considered abandoned, and shall reconsider such declaration if additional information is provided about the use of the resource. From info at arin.net Thu Feb 3 16:48:46 2011 From: info at arin.net (ARIN) Date: Thu, 03 Feb 2011 16:48:46 -0500 Subject: [arin-ppml] Draft Policy 2011-3: Better IPv6 Allocations for ISPs Message-ID: <4D4B22BE.9030306@arin.net> Draft Policy ARIN-2011-3 Better IPv6 Allocations for ISPs On 28 January 2011 the ARIN Advisory Council (AC) selected "Better IPv6 Allocations for ISPs" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-121. Better IPv6 Allocation for ISPs". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2011-3 is below and can be found at: https://www.arin.net/policy/proposals/2011_3.html You are encouraged to discuss Draft Policy 2011-3 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-3 Better IPv6 Allocations for ISPs Version/Date: 30 January 2011 Policy Statement: Amend section 2 as follows: Delete section 2.9 (Obsolete) Replace section 2.10 with the following: 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location). Add the following: 2.12 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. 2.13 When applied to IPv6 policies, the term "provider assignment unit" shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48). 2.14 The term utilized shall have the following definitions when applied to IPv6 policies: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site. (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) Replace sections 6.5.1 through 6.5.3 with the following: 6.5.1 Terminology (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) 6.5.2 Initial Allocations to LIRs 6.5.2.1 Size (a) All allocations shall be made on nibble boundaries. (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. (c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. This calculation can be summarized as /N where N = 48-(X+Y) and X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site. (d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy. (e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. (f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled. 6.5.2.2 Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: (a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. (b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments from allocation(s) under this policy to other organizations. (c) Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. 6.5.3 Subsequent Allocations to LIRs (a) Where possible ARIN will make subsequent allocations by expanding the existing allocation. (b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation. (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. Replace section 6.5.4 with the following 6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Add the following to 6.5.7 LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return. == Rationale: == The current ISP policy for IPv6 allocations is both short-sighted and insufficient for rational deployments by most ISPs. We have gained significant operational experience with IPv6 in the time since it was written and it is clear that current policy is driving many ISPs to choices of excess conservatism that will eventually harm innovation in the consumer space. Under the proposed policy, the entirety of the ARIN region can still be numbered in no more than 2 /12s (quite probably 1). There are still 506 /12s free within the current /3. It is unreasonable to shoot ourselves in the foot with address scarcity thinking so early into the IPv6 deployment. This policy seeks to strike a more reasonable and harmonious balance of the goals stated in NRPM 6.3. The lower bound of /36 is intended to facilitate extremely small ISPs getting a smaller block if they do not need to support more than ~4000 customers. It is hoped that the board will take subsequent action to adjust the fee structure to eliminate the $1,000/year price hike for those extremely small ISPs. These ISPs can, of course, get a /32 if they wish. The intent of section 6.5.4 is to create and preserve parity between the requirements for LIR->End User and ARIN->End User policies. This section presumes that 6.5.8 has already been modified as described in draft policy 2010-8. Some examples of determining the size of block for which an organization is eligible: Bill's Bait, Sushi, and IP Transit: Largest serving site: 200 end sites Number of serving sites: 5 200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 * 0.75), so, round up to 4096 (12 bits) 5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75), so, no further round up. 16 (4 bits) 48 - (12+4) = 32 -- This organization could receive up to a /32. Lee's Rural Internet, Inc. Largest serving site: 1024 end sites Number of serving sites: 30 1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072 (4096 * 0.75), so 4096 (12 bits) 30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 * 0.75), so, 256 (8 bits) 48 - (12+8) = 28 -- This organization could receive up to a /28. Paul's Mega Metro ISP, LLC Largest serving site: 3,500 end sites Number of serving sites: 140 3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072 (4096 * 0.75), so, round up to 65,536 (16 bits) 140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 * 0.75), so, 256 (8 bits) 48 - (16+8) = 24 -- This organization could receive up to a /24 PON's CMTS mega DSL Corp. Largest serving site: 30,000 end sites Number of serving sites: 700 30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 < 49,152 (65536 * 0.75), so, 65,536 (16 bits) 700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072 (4096 * 0.75), so, 4,096 (12 bits) 48 - (16+12) = 20 -- This organization could receive up to a /20. Clarifications in response to Staff and Legal Assessment In the Proposal Summary (Staff understanding) staff states "This policy will lower the current minimum allocation size from a /32 to a /36 as it allows ISPs to request a /36". It should be noted that this policy still allows any ISP to receive at least a /32. However, the /36 is provided as an option specifically to allow very small ISPs currently in the x-small IPv4 category a reduced option. It is the intent that by allowing this, the board may reconsider the minimum IPv6 ISP fee table and allow these particularly small organizations to obtain IPv6 without increasing their annual subscription fees from ARIN. Since Fees are not a policy matter, the fee request must be considered elsewhere, but, the enabling policy language contained in this policy is a precursor to that discussion. The author has submitted a request that the board consider this fee structure through the ACSP. ##### STAFF ASSESSMENT Proposal: ?Better IPv6 Allocations for ISPs? (pp 121) Policy Version (Date): 16 December 2010 Date of Assessment: 26 January 2011 1. Proposal Summary (Staff Understanding) ? This policy allows an ISP to receive an initial allocation large enough to give each site in its network the block size required for its largest single site. Site block size and overall block size would be based on a less than 75% used threshold. ISPs will be eligible to obtain an additional allocation when they have either allocated 75% of their existing allocation to sites or have a serving site that has allocated at least 90% of its existing block. ISP customers of ISPs will be eligible to obtain an allocation based on the same methodology. All allocations (including those to customer ISPs and to ISP serving sites) will be made on nibble boundaries. This policy will lower the current minimum allocation size from a /32 to a /36 as it allows ISPs to request a /36. 2. Comments A. ARIN Staff Comments ? The proposed addition of 2.14, a definition of "utilized" is meant to only refer to IPv6 and the application of this policy. The word "utilized" is very important to IPv4 policy, and this new definition could introduce unnecessary ambiguity. Perhaps the proposed definition could have a qualifier noting that it's only applicable to IPv6 addressing. ? The proposed additions of 2.12 and 2.13 suffer the same problem as in comment #1, albeit without the same wide-ranging effect of the proposed 2.14. They, too, should probably be qualified as only relating to IPv6 policy. ? 6.5.2.2.b has both an OR and an AND clause that is unclear and ambiguous. We believe the OR refers to the two possibilities for qualifying, and the AND refers to only the second possibility. The text should be re-written to remove the ambiguity. ? 6.5.2.2.b needs editing for grammar. The clause shifts between tenses. ? 6.5.2.2.c needs editing for punctuation and grammar. B. ARIN General Counsel No comments 3. Resource Impact This policy would have moderate resource impact from an implementation aspect. It is estimated that implementation would occur within 6 - 9 months after ratification by the ARIN Board of Trustees. The implementation of this policy will require staff to develop new sparse allocation methods and software. The following would be needed in order to implement: ? Updated documentation/guidelines on the ARIN website ? Staff training ? Engineering labor to modify our sparse allocation tools 4. Proposal Text Policy Proposal: Better IPv6 Allocations for ISPs Version/Date: 16 December 2010 Amend section 2 as follows: Delete section 2.9 (Obsolete) Replace section 2.10 with the following: 2.10 The term End Site shall mean a single structure or service delivery address, or, in the case of a multi-tenant structure, a single tenant within said structure (a single customer location). Add the following: 2.12 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. 2.13 The term provider assignment unit shall mean the prefix of the smallest block a given ISP assigns to end sites (recommended /48). 2.14 The term utilized shall have the following definitions: (i) A provider assignment unit shall be considered fully utilized when it is assigned to an end-site. (ii) Larger blocks shall have their utilization defined by dividing the number of provider assignment units assigned from the containing block by the total number of provider assignment units. This ratio will often be expressed as a percentage (e.g. a/t*100, for a /36 3072/4096 * 100 = 75% utilization) Replace sections 6.5.1 through 6.5.3 with the following: 6.5.1 Terminology (a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. (b) The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) 6.5.2 Initial Allocations to LIRs 6.5.2.1 Size (a) All allocations shall be made on nibble boundaries. (b) In no case shall an LIR receive smaller than a /32 unless they specifically request a /36. (c) The maximum allowable allocation shall be the smallest nibble-boundary aligned block that can provide an equally sized nibble-boundary aligned block to each of the requesters serving sites large enough to satisfy the needs of the requesters largest single serving site using no more than 75% of the available addresses. This calculation can be summarized as /N where N = 48-(X+Y) and X is a multiple of 4 greater than 4/3*serving sites and Y is a multiple of 4 greater than 4/3*end sites served by largest serving site. (d) For purposes of the calculation in (c), an end site which can justify more than a /48 under the end-user assignment criteria in 6.5.8 shall count as the appropriate number of /48s that would be assigned under that policy. (e) For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. (f) An LIR is not required to design or deploy their network according to this structure. It is strictly a mechanism to determine the largest IP address block to which the LIR is entitled. 6.5.2.2 Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: (a) Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. (b) Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number and will be making reassignments to other organizations. (c) Provide ARIN a reasonable technical justification, indicating why an allocation is necessary, including the intended purposes for the allocation, and describing the network infrastructure the allocation will be used to support. Justification must include a plan detailing assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. 6.5.3 Subsequent Allocations to LIRs (a) Where possible ARIN will make subsequent allocations by expanding the existing allocation. (b) An LIR which can show utilization of 75% or more of their total address space, or more than 90% of any serving site shall be entitled to a subsequent allocation. (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. Replace section 6.5.4 with the following 6.5.4 Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Add the following to 6.5.7 LIRs which received an allocation under previous policies which is smaller than what they are entitled to under this policy may receive a new initial allocation under this policy provided that they agree to renumber into that new allocation and return their prior allocation(s) within 5 years. If possible, ARIN will simply expand their existing allocation rather than requiring renumber and return. Rationale: The current ISP policy for IPv6 allocations is both short-sighted and insufficient for rational deployments by most ISPs. We have gained significant operational experience with IPv6 in the time since it was written and it is clear that current policy is driving many ISPs to choices of excess conservatism that will eventually harm innovation in the consumer space. Under the proposed policy, the entirety of the ARIN region can still be numbered in no more than 2 /12s (quite probably 1). There are still 506 /12s free within the current /3. It is unreasonable to shoot ourselves in the foot with address scarcity thinking so early into the IPv6 deployment. This policy seeks to strike a more reasonable and harmonious balance of the goals stated in NRPM 6.3. The lower bound of /36 is intended to facilitate extremely small ISPs getting a smaller block if they do not need to support more than ~4000 customers. It is hoped that the board will take subsequent action to adjust the fee structure to eliminate the $1,000/year price hike for those extremely small ISPs. These ISPs can, of course, get a /32 if they wish. The intent of section 6.5.4 is to create and preserve parity between the requirements for LIR->End User and ARIN->End User policies. This section presumes that 6.5.8 has already been modified as described in draft policy 2010-8. Some examples of determining the size of block for which an organization is eligible: Bill's Bait, Sushi, and IP Transit: Largest serving site: 200 end sites Number of serving sites: 5 200 rounds up to 256 (nibble boundary, 8 bits). 200 > 192 (256 * 0.75), so, round up to 4096 (12 bits) 5 rounds up to 16 (nibble boundary, 4 bits). 5 < 12 (16 * 0.75), so, no further round up. 16 (4 bits) 48 - (12+4) = 32 -- This organization could receive up to a /32. Lee's Rural Internet, Inc. Largest serving site: 1024 end sites Number of serving sites: 30 1024 rounds up to 4096 (nibble boundary, 12 bits) 1024 < 3072 (4096 * 0.75), so 4096 (12 bits) 30 rounds up to 256 (nibble boundary, 8 bits). 30 < 192 (256 * 0.75), so, 256 (8 bits) 48 - (12+8) = 28 -- This organization could receive up to a /28. Paul's Mega Metro ISP, LLC Largest serving site: 3,500 end sites Number of serving sites: 140 3,500 rounds up to 4096 (nibble boundary, 12 bits). 3500 > 3072 (4096 * 0.75), so, round up to 65,536 (16 bits) 140 rounds up to 256 (nibble boundary, 8 bits) 140 < 192 (256 * 0.75), so, 256 (8 bits) 48 - (16+8) = 24 -- This organization could receive up to a /24 PON's CMTS mega DSL Corp. Largest serving site: 30,000 end sites Number of serving sites: 700 30,000 rounds up to 65,536 (nibble boundary, 16 bits). 30,000 < 49,152 (65536 * 0.75), so, 65,536 (16 bits) 700 rounds up to 4,096 (nibble boundary, 12 bits). 700 < 3072 (4096 * 0.75), so, 4,096 (12 bits) 48 - (16+12) = 20 -- This organization could receive up to a /20. Sizing table: Units Round-up Bits 0-11 16 4 12-191 256 8 192-3,071 4,096 12 3,072-49,151 65,536 16 49,152-786,431 1,048,576 20 From info at arin.net Thu Feb 3 16:48:59 2011 From: info at arin.net (ARIN) Date: Thu, 03 Feb 2011 16:48:59 -0500 Subject: [arin-ppml] Draft Policy 2011-4: Reserved Pool for Critical Infrastructure Message-ID: <4D4B22CB.4090007@arin.net> Draft Policy ARIN-2011-4 Reserved Pool for Critical Infrastructure On 28 January 2011 the ARIN Advisory Council (AC) selected "Reserved Pool for Critical Infrastructure" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-123. Reserved Pool for Critical Infrastructure". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2011-4 is below and can be found at: https://www.arin.net/policy/proposals/2011_4.html You are encouraged to discuss Draft Policy 2011-4 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-4 Reserved Pool for Critical Infrastructure Version/Date: 23 November 2010 Policy term: 36 Months following implementation Policy statement: Upon receipt of the last /8 that the IANA will allocate to ARIN per the Global Policy for the Allocation of the Remaining IPv4 Address Space, ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. Rationale: Section 4.10 of the NRPM is insufficient with respect to insuring the continued operation of critical infrastructure. This proposal, if adopted, will protect those resources with a reasonable amount of reserved v4 address space and prevent an overrun of CI needs by NRPM Section 4.10 or any successor. The intent is to separate CI needs and make a distinct pool available to insure the continuity of CI allocations per NRPM Section 4.4 for at least 36 months. This proposal should be considered an emergency proposal. IANA exhaustion is likely to occur prior to the next ARIN meeting. Timetable for implementation: Immediate ##### STAFF ASSESSMENT Proposal: ?Reserved Pool for Critical Infrastructure? (pp 123) Policy Version (Date): 23 November 2010 Date of Assessment: 27 January 2011 1. Proposal Summary (Staff Understanding) This policy would set aside a /16 equivalent when the IANA issues its last /8 to ARIN. These addresses would be reserved for issuing under the IPv4 micro-allocations for critical infrastructure policy (NRPM 4.4). If any of the reserved addresses are unused 36 months after implementation, ARIN may begin using the addresses for other purposes. 2. Comments A. ARIN Staff Comments ? The proposal says, ?reserve for critical infrastructure? but doesn?t elaborate on what critical infrastructure actually is. NRPM 4.4. ("Micro-allocation") defines a specific list of uses that qualifies as critical infrastructure. For coherency, perhaps this policy should specifically state that ?critical infrastructure? as defined in NRPM 4.4. That way, there can be no misinterpretation of its meaning. B. ARIN General Counsel No comments 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Updated documentation on the ARIN website 4. Proposal Text Policy statement: Upon receipt of the last /8 that the IANA will allocate to ARIN per the Global Policy for the Allocation of the Remaining IPv4 Address Space, ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. Rationale: Section 4.10 of the NRPM is insufficient with respect to insuring the continued operation of critical infrastructure. This proposal, if adopted, will protect those resources with a reasonable amount of reserved v4 address space and prevent an overrun of CI needs by NRPM Section 4.10 or any successor. The intent is to separate CI needs and make a distinct pool available to insure the continuity of CI allocations per NRPM Section 4.4 for at least 36 months. This proposal should be considered an emergency proposal. IANA exhaustion is likely to occur prior to the next ARIN meeting. From info at arin.net Thu Feb 3 16:49:13 2011 From: info at arin.net (ARIN) Date: Thu, 03 Feb 2011 16:49:13 -0500 Subject: [arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension Message-ID: <4D4B22D9.4030306@arin.net> Draft Policy ARIN-2011-5 Shared Transition Space for IPv4 Address Extension On 28 January 2011 the ARIN Advisory Council (AC) selected "Shared Transition Space for IPv4 Address Extension" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-127. Shared Transition Space for IPv4 Address Extension". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2011-5 is below and can be found at: https://www.arin.net/policy/proposals/2011_5.html You are encouraged to discuss Draft Policy 2011-5 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-5 Shared Transition Space for IPv4 Address Extension Date: 20 January 2011 Policy statement: Updates 4.10 of the NRPM: A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators. Rationale: The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet. Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider. Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed. Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. ?squat?). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs. Timetable for implementation: immediately ##### STAFF ASSESSMENT Proposal: ?Shared Transition Space for IPv4 Address Extension? Policy Version (Date): 20 January 2011 Date of Assessment: 26 January 2011 1. Proposal Summary (Staff Understanding) This proposal asks ARIN to reserve and register a single, contiguous /10 in ARIN's Whois in a fashion similar to blocks reserved by RFCs (like RFC1918 or RFC3068). The block is never to be assigned directly to any organization and is to be shared by anyone who wishes to use it, with no further registration actions required by ARIN. Staff understands that this space is not to be routed on the public Internet and that there will be multiple people using the same address space much like is done with RFC 1918 space today. 2. Comments A. ARIN Staff Comments ? This proposal would have ARIN acting as the registrant for this single IP block and maintaining it without us (or the public) knowing who is actually using it or how they are using it. This will likely generate a great deal of abuse and spam complaints to ARIN. ? It is unclear whether ARIN would need to set up nameservers for this block to provide rDNS. B. ARIN General Counsel No legal comments 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Updated guidelines ? Staff training 4. Proposal Text Policy statement: Updates 4.10 of the NRPM: A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators. Rationale: The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet. Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider. Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed. Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. ?squat?). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs. From bill at herrin.us Thu Feb 3 17:18:01 2011 From: bill at herrin.us (William Herrin) Date: Thu, 3 Feb 2011 17:18:01 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: <4D4B21C8.9090506@arin.net> References: <4D4B21C8.9090506@arin.net> Message-ID: On Thu, Feb 3, 2011 at 4:44 PM, ARIN wrote: > The AC abandoned ARIN-prop-128 [...] > because there is insufficient time to implement the proposal through the > normal PDP. If Geoff's projections are correct there will be two more meetings before ARIN is down to its last /8. Just sayin'. > The AC abandoned ARIN-prop-129 and ARIN-prop-130 because they violate > the community principle of needs-based assignments. Just once I'd like to see this read, "The AC abandoned ... because the proposal appeared to have been made in jest." 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 Thu Feb 3 18:04:36 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Feb 2011 15:04:36 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> Message-ID: <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> ... > > 2. Address leasing is not allowed. Must get your addresses from a > primary or at least major bandwidth provider. Addresses found to be > leased or provided in with a paper-tiger transit arrangement are > subject to reclamation by ARIN. ... > Cons: Unenforceable. > Not entirely true. It may be difficult to enforce, but, it is not unenforceable. If that's the best you can do in the con column for this idea, I think keeping things this way is vastly superior to your proposed option 1. > > 3. Any multihomed registrant using an ARIN AS number and SWIPed for at > least one year with a /24 or larger is entitled to convert the > registration to an ARIN direct assignment upon filing the proper > paperwork. Refusing SWIP or assigning addresses out of region is > grounds for reclamation. > > Pros: Lets the original registrant earn his money but guarantees that > address assignments will move towards the multihomed end users. > > Cons: Fragmentation. No way to ever move growing entities from > individual /24's to aggregable address blocks. Have to hope the IPv6 > migration solves this problem before it can get serious. Also, it > implies a change in ISP's internal routing management. These new > registrations are functionally different from older direct > registrations - they'll likely still be subject to some ISP's covering > route, even though they're no longer used with that ISP. > I have to admit this third option is interesting and has some appeal. Owen From spiffnolee at yahoo.com Thu Feb 3 18:21:10 2011 From: spiffnolee at yahoo.com (Lee Howard) Date: Thu, 3 Feb 2011 15:21:10 -0800 (PST) Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: <253009.86614.qm@web63304.mail.re1.yahoo.com> ----- Original Message ---- > From: William Herrin > To: arin-ppml at arin.net > Sent: Thu, February 3, 2011 5:18:01 PM > Subject: Re: [arin-ppml] Advisory Council Meeting Results - January 2011 > > On Thu, Feb 3, 2011 at 4:44 PM, ARIN wrote: > > The AC abandoned ARIN-prop-128 [...] > > because there is insufficient time to implement the proposal through the > > normal PDP. > > If Geoff's projections are correct there will be two more meetings > before ARIN is down to its last /8. Just sayin'. If Tony's projections are correct, San Juan is the last IPv4 meeting. But the point is moot, since prop-128 had to do with a policy set to change at the time of the last IANA allocation, not the last ARIN allocation. Since the last IANA allocation of IPv4 addresses has now happened, the proposal has been Overtaken By Events. Lee From farmer at umn.edu Thu Feb 3 18:31:34 2011 From: farmer at umn.edu (David Farmer) Date: Thu, 03 Feb 2011 17:31:34 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: <4D4B3AD6.9020804@umn.edu> On 2/3/11 16:18 CST, William Herrin wrote: > On Thu, Feb 3, 2011 at 4:44 PM, ARIN wrote: >> The AC abandoned ARIN-prop-128 [...] >> because there is insufficient time to implement the proposal through the >> normal PDP. > > If Geoff's projections are correct there will be two more meetings > before ARIN is down to its last /8. Just sayin'. Yes, but the current policy (2009-8) activated today with IANA exhaustion, it would have taken emergency action to prevent that. Or are you suggestion we should go down to three months, back to twelve months, and then back down to three months again? Honestly, that doesn't sound like a good idea to me. >> The AC abandoned ARIN-prop-129 and ARIN-prop-130 because they violate >> the community principle of needs-based assignments. > > Just once I'd like to see this read, "The AC abandoned ... because the > proposal appeared to have been made in jest." I'll admit we should have probably added a smiley. :) > Regards, > Bill Herrin > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From alh-ietf at tndh.net Thu Feb 3 19:37:04 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 3 Feb 2011 16:37:04 -0800 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: <253009.86614.qm@web63304.mail.re1.yahoo.com> References: <4D4B21C8.9090506@arin.net> <253009.86614.qm@web63304.mail.re1.yahoo.com> Message-ID: <19c201cbc403$a7d7b9f0$f7872dd0$@net> I would never claim my projections are any more accurate than Geoff's. We are both working from the same data set with slightly different models. As someone put it, mine tend to be more pessimistic while Geoff's tend to be more optimistic. I tend to believe that people don't like to be told they have 6 months to live, then die in 3; but rather they would prefer to be told they have 3 months that might get extended by 3. At the same time there are those that won't accept anything except an exact answer and will criticize inaccuracies despite any disclaimers that 'past behavior is no guarantee of future performance'. All I will say is that anything projected after the first RIR runs out is highly suspect. Given that it is likely to be APnic, and their burn rate has been more than 2x of the rest combined, that demand will go somewhere and my crystal ball is not clear enough for me to figure out where. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Lee Howard > Sent: Thursday, February 03, 2011 3:21 PM > To: William Herrin; arin-ppml at arin.net > Subject: Re: [arin-ppml] Advisory Council Meeting Results - January > 2011 > > > > > > ----- Original Message ---- > > From: William Herrin > > To: arin-ppml at arin.net > > Sent: Thu, February 3, 2011 5:18:01 PM > > Subject: Re: [arin-ppml] Advisory Council Meeting Results - January > 2011 > > > > On Thu, Feb 3, 2011 at 4:44 PM, ARIN wrote: > > > The AC abandoned ARIN-prop-128 [...] > > > because there is insufficient time to implement the proposal > through the > > > normal PDP. > > > > If Geoff's projections are correct there will be two more meetings > > before ARIN is down to its last /8. Just sayin'. > > If Tony's projections are correct, San Juan is the last IPv4 meeting. > But the point is moot, since prop-128 had to do with a policy set to > change at the time of the last IANA allocation, not the last ARIN > allocation. Since the last IANA allocation of IPv4 addresses has now > happened, the proposal has been Overtaken By Events. > > Lee > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Thu Feb 3 20:01:38 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 03 Feb 2011 17:01:38 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net><712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> Message-ID: <4D4B4FF2.8040000@ipinc.net> On 2/3/2011 1:21 PM, George Bonser wrote: > > > >> As long as number resources are being put to productive use, and >> the whois database is kept up-to-date with regards to who's >> actually using the space, I'd be hesitant to try to micromanage the >> arrangements between consenting parties... > > I agree with this. Unless something is broken, ARIN has enough to do > without attempting to enforce philosophical positions. > > The thing is that allocations from ARIN are based on the conditions > that existed at the time the resources were allocated. Say someone > qualified for a /16 and got it, then used it for a number of years > but 15 years later find their business has shrunk and they aren't > using all of that allocation anymore. Now they certainly wouldn't > qualify for a new allocation but I am not aware of any policy (not > saying one doesn't exist, just saying that I am not aware of any) > that requires a regular audit and periodic re-justification of issued > resources. > There never was a need for one. The reason why is that those unused addresses are costing that someone a lot of money, if his business has shrunk then he doesn't have the cash flow anymore to pay the fees. As long as addresses were given out on request the market value of IPv4 was effectively $0.00 so nobody would pay anyone to lease anything. The economic of it changes a lot post-runout. It's going to change enormously during the REAL IPv4 endgame. What people are calling "IPv4 endgame" right now really isn't. It's more of an "IPv4-for-the-asking endgame" The REAL IPv4 endgame is when significant numbers of customers on the Internet don't NEED IPv4 anymore - but rather it's a "nice to have" but at the same time a significant number of customers on the Internet desperately need IPv4. That is when large pressure builds to lease out IPv4. If an IPv4 holder sees for example that the actual end of IPv4 is 5 years out, yet right now can move 25% of his existing IPv4 customers to IPv6, why then he can take that freed IPv4 and lease it to someone else who can't move any of their customers to IPv4 right now. It's a great deal for him because he is in the situation of a competitor of his is paying him for themselves becoming less and less competitive as the years pass. Ted > One might easily have a few scattered /24 nets within a larger > allocation that they don't plan to use for a while. Those now become > a potential source of revenue. I see nothing wrong or "dishonest" > with allowing someone else to use such a block provided the network > leasing the space legitimately qualifies for the space and isn't > simply some "snowshoe" spammer looking to churn through address > space. There comes the rub but it is really no different than the > situation today. I would guess that most of the IP address leasing > today (noting exceptions mentioned in this thread) are people who for > one reason or another either wouldn't qualify for a direct allocation > or don't want to go through the paperwork. That will change after > runout to include people who *do* qualify for more space but it isn't > available. > > So the bottom line is that I don't believe the problem will get worse > than it currently is because as it stands today the majority of the > people "leasing" IP address resources are people who wouldn't get it > otherwise. After runout that percentage will change and most of the > leasing would be from people who are just fine but can't get the > resources otherwise. The "bad guys" are already doing it. This > proposal would just make it harder for the "good guys" after runout. > > _______________________________________________ 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 Thu Feb 3 21:18:41 2011 From: bill at herrin.us (William Herrin) Date: Thu, 3 Feb 2011 21:18:41 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: On Thu, Feb 3, 2011 at 6:31 PM, David Farmer wrote: > Yes, but the current policy (2009-8) activated today with IANA exhaustion, > it would have taken emergency action to prevent that. Or are you suggestion > we should go down to three months, back to twelve months, and then back down > to three months again? Honestly, that doesn't sound like a good idea to me. David, That might have been a good reason for bouncing it. But "there isn't time" is disingenuous. There's always time. It sets me off when a member of the AC (or the AC as a whole) announces that there isn't time for something. Not enough time to get this through the process. Too many proposals, not enough time to work on this one. Call it a pet peeve. Many of you are past your first terms. If you couldn't figure out how to make time, you shouldn't have run for reelection. You know: lead, follow or ::get out of the way::. Those of you past your first terms did run for reelection. So now it's just a wussy excuse. This is part of another irritant for me as well: I find the brusque way the AC disposes of proposals it decides to abandon to be disrespectful to their authors. A proposal author has spent hours behind the scenes carefully crafting language, researching process and writing justification. When you make the decision instead of leaving it to consensus, simple courtesy demands at least a paragraph from each of you explaining why the proposal wasn't good enough. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From packetgrrl at gmail.com Thu Feb 3 21:31:01 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 3 Feb 2011 19:31:01 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: Bill, I am sorry you feel that the AC brusquely disposes of policy proposals. We actually aren't hasty. We spend a lot of time debating and discussing and attempting to do the best job we can for the community. We get input from proposers, ppml, legal counsel, and ARIN staff. We came to the conclusion after much debate and discussion that 2009-8 should not move forward. If you feel strongly that it should then please petition it. Thanks! ----Cathy On Thu, Feb 3, 2011 at 7:18 PM, William Herrin wrote: > On Thu, Feb 3, 2011 at 6:31 PM, David Farmer wrote: > > Yes, but the current policy (2009-8) activated today with IANA > exhaustion, > > it would have taken emergency action to prevent that. Or are you > suggestion > > we should go down to three months, back to twelve months, and then back > down > > to three months again? Honestly, that doesn't sound like a good idea to > me. > > David, > > That might have been a good reason for bouncing it. But "there isn't > time" is disingenuous. There's always time. > > It sets me off when a member of the AC (or the AC as a whole) > announces that there isn't time for something. Not enough time to get > this through the process. Too many proposals, not enough time to work > on this one. Call it a pet peeve. > > Many of you are past your first terms. If you couldn't figure out how > to make time, you shouldn't have run for reelection. You know: lead, > follow or ::get out of the way::. Those of you past your first terms > did run for reelection. So now it's just a wussy excuse. > > This is part of another irritant for me as well: I find the brusque > way the AC disposes of proposals it decides to abandon to be > disrespectful to their authors. A proposal author has spent hours > behind the scenes carefully crafting language, researching process and > writing justification. When you make the decision instead of leaving > it to consensus, simple courtesy demands at least a paragraph from > each of you explaining why the proposal wasn't good enough. > > -Bill > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Thu Feb 3 22:19:46 2011 From: bill at herrin.us (William Herrin) Date: Thu, 3 Feb 2011 22:19:46 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: On Thu, Feb 3, 2011 at 9:31 PM, cja at daydream.com wrote: > I am sorry you feel that the AC brusquely disposes of policy proposals. But you're not sorry for doing it, you're only sorry I feel that way. >?We actually aren't hasty. We spend a lot of time debating and discussing Behind closed doors with, at best, an abbreviated version eventually appearing in the form of meeting minutes. > and > attempting to do the best job we can for the community. ?We get input from > proposers, ppml, legal counsel, and ARIN staff. ? We came to the conclusion > after much debate and discussion that 2009-8 should not move forward. Perhaps you mean proposal 128? It is, after all, communication skills that I'm complaining about. If you don't adequately explain yourselves, and how can a brief, generic paragraph that 15 people grudgingly assent to offer an adequate explanation, then how are the proposal authors supposed to understand your decisions well enough to do better with the next attempt? How indeed is the author to believe that you gave his proposal any care at all? >?If you feel strongly that it should then please petition it. I have no dog in that fight. My complaint lies where the AC can't find the time for the -people- that try to participate in the policy process. It would cost so little for each AC member voting to abandon to write just one paragraph explaining their own reasons why. Yet it would make such a difference. It's not like I'm asking you to meet a standard I wouldn't have held myself to had I been the one elected. Just some basic courtesy for the folks whose efforts you choose to discard. I'm going to shut up now before I beat the topic to death, but I hope you'll take some of these comments to heart and decide that you can do better. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From BillD at cait.wustl.edu Thu Feb 3 22:34:57 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Thu, 3 Feb 2011 21:34:57 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 References: <4D4B21C8.9090506@arin.net> Message-ID: Bill, So in the case of PP 130 for example. The PP was abandoned because it didn't conform to the communities principle of needs-based assignments. And, that was the stated reason. A paragraph to say that would be no clearer, nor would it make the author feel any better. I suppose we could state the obvious, that we appreciate the author's involvement and willingness to engage in the PDP. We all do appreciate that and I guess we should state it....but somehow I believe you might find fault with that statement...and perhaps this one....considering each disingenuous. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of William Herrin Sent: Thu 2/3/2011 8:18 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Advisory Council Meeting Results - January 2011 On Thu, Feb 3, 2011 at 6:31 PM, David Farmer wrote: > Yes, but the current policy (2009-8) activated today with IANA exhaustion, > it would have taken emergency action to prevent that. Or are you suggestion > we should go down to three months, back to twelve months, and then back down > to three months again? Honestly, that doesn't sound like a good idea to me. David, That might have been a good reason for bouncing it. But "there isn't time" is disingenuous. There's always time. It sets me off when a member of the AC (or the AC as a whole) announces that there isn't time for something. Not enough time to get this through the process. Too many proposals, not enough time to work on this one. Call it a pet peeve. Many of you are past your first terms. If you couldn't figure out how to make time, you shouldn't have run for reelection. You know: lead, follow or ::get out of the way::. Those of you past your first terms did run for reelection. So now it's just a wussy excuse. This is part of another irritant for me as well: I find the brusque way the AC disposes of proposals it decides to abandon to be disrespectful to their authors. A proposal author has spent hours behind the scenes carefully crafting language, researching process and writing justification. When you make the decision instead of leaving it to consensus, simple courtesy demands at least a paragraph from each of you explaining why the proposal wasn't good enough. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Thu Feb 3 23:42:00 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 3 Feb 2011 23:42:00 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: On Thu, Feb 3, 2011 at 10:19 PM, William Herrin wrote: > On Thu, Feb 3, 2011 at 9:31 PM, cja at daydream.com wrote: >>?We actually aren't hasty. We spend a lot of time debating and discussing [ clip ] >>?If you feel strongly that it should then please petition it. > >It would cost so little for each AC member voting to abandon > to write just one paragraph explaining their own reasons why. Yet it > would make such a difference. I'll sign up for this and I'll suggest it to my co-AC members on our next call. Best, -M< From matthew at matthew.at Fri Feb 4 01:31:11 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 03 Feb 2011 22:31:11 -0800 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: <4D4B9D2F.9040008@matthew.at> On 2/3/2011 7:34 PM, Bill Darte wrote: > > Bill, > > So in the case of PP 130 for example. The PP was abandoned because it > didn't conform to the communities principle of needs-based assignments. > And, that was the stated reason. > IMHO, PP 129 doesn't confirm to needs-based assignment and dismissing it for that reason is reasonable... but PP 130 simply *reserves* space for future needs-based assignment, and doesn't change the needs basis for the actual assignments under it at all. Furthermore, it makes "needs based" assignment more reasonable for organizations that come with a genuine need but "too late" for the existing reserved transition space. > > > A paragraph to say that would be no clearer, nor would it make the > author feel any better. > In this case the author doesn't particularly care whether it is one sentence or a long-winded explanation, but thinks that for one of them (130) the analysis may be a bit off. However, given the icy reaction to 130 on the list, it doesn't make sense to waste everyone's email inbox space with the petition process. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Feb 4 00:32:07 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 00:32:07 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: <1B7C0F6E-DDCE-454C-B616-B00288776E16@delong.com> Sent from my iPad On Feb 3, 2011, at 9:18 PM, William Herrin wrote: > On Thu, Feb 3, 2011 at 6:31 PM, David Farmer wrote: >> Yes, but the current policy (2009-8) activated today with IANA exhaustion, >> it would have taken emergency action to prevent that. Or are you suggestion >> we should go down to three months, back to twelve months, and then back down >> to three months again? Honestly, that doesn't sound like a good idea to me. > > David, > > That might have been a good reason for bouncing it. But "there isn't > time" is disingenuous. There's always time. > Bill, the AC said there was insufficient time for the normal policy process to bring said proposal to fruition before it was rendered moot. Since the normal policy process requires Resonation at a public policy meeting (next one in April) and the proposal was rendered moot in February, I think it was an accurate statement of the facts of the situation. I fail to see how there "is always time". > It sets me off when a member of the AC (or the AC as a whole) > announces that there isn't time for something. Not enough time to get > this through the process. Too many proposals, not enough time to work > on this one. Call it a pet peeve. > > Many of you are past your first terms. If you couldn't figure out how > to make time, you shouldn't have run for reelection. You know: lead, > follow or ::get out of the way::. Those of you past your first terms > did run for reelection. So now it's just a wussy excuse. > It was not a matter of how much time we had. It had to do with external events overtaking then(glacial) speed of the ARIN policy process. Yes, this policy could have been addresses as an emergency by the board. The AC does not have the ability to invoke the emergency process. There did not appear to be significant support in the community to do so. I think the AC acted appropriately in the best interests of the community and made an accurate determination of the situation based on the data available at the time. > This is part of another irritant for me as well: I find the brusque > way the AC disposes of proposals it decides to abandon to be > disrespectful to their authors. A proposal author has spent hours > behind the scenes carefully crafting language, researching process and > writing justification. When you make the decision instead of leaving > it to consensus, simple courtesy demands at least a paragraph from > each of you explaining why the proposal wasn't good enough. > I believe the author in this case received an adequate and courteous explanation. The author participated in the deliberations of the proposal. Owen From packetgrrl at gmail.com Fri Feb 4 09:05:46 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 4 Feb 2011 07:05:46 -0700 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: I am sorry Bill you're right I meant PP-128. With respect to my communication skills everyone makes a typo. We are 15 volunteers with day jobs and sometimes we make typos. I agree with Bill Darte however, we do send a written reason in the minutes of why a proposal was acted on in a particular way. If you think the process is incomplete please make suggestions via the ARIN suggestion and consultation process. The board is working on a new PDP right now and I am sure they would love your suggestions. I know the ideas floating around in the new PDP discussion include a little working group for each proposal and that might help. Thanks again! ----Cathy On Thu, Feb 3, 2011 at 8:19 PM, William Herrin wrote: > On Thu, Feb 3, 2011 at 9:31 PM, cja at daydream.com > wrote: > > I am sorry you feel that the AC brusquely disposes of policy proposals. > > But you're not sorry for doing it, you're only sorry I feel that way. > > > > We actually aren't hasty. We spend a lot of time debating and discussing > > Behind closed doors with, at best, an abbreviated version eventually > appearing in the form of meeting minutes. > > > > and > > attempting to do the best job we can for the community. We get input > from > > proposers, ppml, legal counsel, and ARIN staff. We came to the > conclusion > > after much debate and discussion that 2009-8 should not move forward. > > Perhaps you mean proposal 128? It is, after all, communication skills > that I'm complaining about. If you don't adequately explain > yourselves, and how can a brief, generic paragraph that 15 people > grudgingly assent to offer an adequate explanation, then how are the > proposal authors supposed to understand your decisions well enough to > do better with the next attempt? How indeed is the author to believe > that you gave his proposal any care at all? > > > > If you feel strongly that it should then please petition it. > > I have no dog in that fight. My complaint lies where the AC can't find > the time for the -people- that try to participate in the policy > process. It would cost so little for each AC member voting to abandon > to write just one paragraph explaining their own reasons why. Yet it > would make such a difference. > > It's not like I'm asking you to meet a standard I wouldn't have held > myself to had I been the one elected. Just some basic courtesy for the > folks whose efforts you choose to discard. > > > I'm going to shut up now before I beat the topic to death, but I hope > you'll take some of these comments to heart and decide that you can do > better. > > -Bill > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaitken at aitken.com Fri Feb 4 09:17:25 2011 From: jaitken at aitken.com (Jeff Aitken) Date: Fri, 4 Feb 2011 14:17:25 +0000 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> Message-ID: <20110204141725.GA29492@eagle.aitken.com> On Thu, Feb 03, 2011 at 03:04:36PM -0800, Owen DeLong wrote: > > 2. Address leasing is not allowed. Must get your addresses from a > > primary or at least major bandwidth provider. Addresses found to be > > leased or provided in with a paper-tiger transit arrangement are > > subject to reclamation by ARIN. > > > Cons: Unenforceable. > > > Not entirely true. > > It may be difficult to enforce, but, it is not unenforceable. Owen, For all practical purposes, it is unenforceable. ARIN cannot make a meaningful distinction between "you buy a T1 and you get a /X" and "you buy a GRE tunnel and you get a /X". More to the point, I don't want ARIN to waste time trying to do so. IMO ARIN should be working to ensure two things: 1. that the barriers to v6 adoption are as low as we can make them, and 2. that the database be as accurate as we can make it. The market will handle the rest, including the issue of putting unused IPv4 addresses to use. To borrow a phrase from Randy, I don't want a bunch of ametuer regulators attempting to decide what constitutes "connectivity". > If that's the best you can do in the con column for this idea, I think > keeping things this way is vastly superior to your proposed option 1. Option #1 is reality, today, and let's not pretend otherwise. > > 3. Any multihomed registrant using an ARIN AS number and SWIPed for at > > least one year with a /24 or larger is entitled to convert the > > registration to an ARIN direct assignment upon filing the proper > > paperwork. Refusing SWIP or assigning addresses out of region is > > grounds for reclamation. > > I have to admit this third option is interesting and has some appeal. Agreed, although I would remove the threat of reclamation because I don't think this is something ARIN needs to regulate. The commercial agreements between the parties should spell out the expected behavior, including whether or not the addresses may be transferred to the lessee, and under what conditions. Let's do what we can to make sure that the database is accurate, and focus our efforts on v6 going forward. --Jeff From hannigan at gmail.com Fri Feb 4 09:36:24 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 4 Feb 2011 09:36:24 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <20110204141725.GA29492@eagle.aitken.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> <20110204141725.GA29492@eagle.aitken.com> Message-ID: +1 On 2/4/11, Jeff Aitken wrote: > On Thu, Feb 03, 2011 at 03:04:36PM -0800, Owen DeLong wrote: >> > 2. Address leasing is not allowed. Must get your addresses from a >> > primary or at least major bandwidth provider. Addresses found to be >> > leased or provided in with a paper-tiger transit arrangement are >> > subject to reclamation by ARIN. >> >> > Cons: Unenforceable. >> > >> Not entirely true. >> >> It may be difficult to enforce, but, it is not unenforceable. > > Owen, > > For all practical purposes, it is unenforceable. ARIN cannot make a > meaningful distinction between "you buy a T1 and you get a /X" and > "you buy a GRE tunnel and you get a /X". > > More to the point, I don't want ARIN to waste time trying to do so. IMO > ARIN should be working to ensure two things: > > 1. that the barriers to v6 adoption are as low as we can make them, and > 2. that the database be as accurate as we can make it. > > The market will handle the rest, including the issue of putting unused IPv4 > addresses to use. To borrow a phrase from Randy, I don't want a bunch of > ametuer regulators attempting to decide what constitutes "connectivity". > > >> If that's the best you can do in the con column for this idea, I think >> keeping things this way is vastly superior to your proposed option 1. > > Option #1 is reality, today, and let's not pretend otherwise. > > >> > 3. Any multihomed registrant using an ARIN AS number and SWIPed for at >> > least one year with a /24 or larger is entitled to convert the >> > registration to an ARIN direct assignment upon filing the proper >> > paperwork. Refusing SWIP or assigning addresses out of region is >> > grounds for reclamation. >> >> I have to admit this third option is interesting and has some appeal. > > Agreed, although I would remove the threat of reclamation because I don't > think this is something ARIN needs to regulate. The commercial agreements > between the parties should spell out the expected behavior, including > whether or not the addresses may be transferred to the lessee, and under > what conditions. > > Let's do what we can to make sure that the database is accurate, and focus > our efforts on v6 going forward. > > > --Jeff > > _______________________________________________ > 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 warren at wholesaleinternet.com Fri Feb 4 10:28:52 2011 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 4 Feb 2011 09:28:52 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <20110204141725.GA29492@eagle.aitken.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> <20110204141725.GA29492@eagle.aitken.com> Message-ID: <04ae01cbc480$3c70bb30$b5523190$@com> I agree with your sentiment. At this stage of the game it is prudent to ask ourselves the following questions: 1) Will the attempted enforcement of this policy force ARIN into legal wrangling with various well-funded corporate entities? 2) Will the attempted enforcement of this policy encourage entities to ignore ARIN's enforcement procedures? Enough parties interested in ignoring ARIN's enforcement policies could potentially muscle bandwidth providers into routing their IP addresses regardless of what ARIN wants. Personally, I think it's time to acknowledge the elephant in the room that is "market forces on a scarce resource" and tread lightly. -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeff Aitken Sent: Friday, February 04, 2011 8:17 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) On Thu, Feb 03, 2011 at 03:04:36PM -0800, Owen DeLong wrote: > > 2. Address leasing is not allowed. Must get your addresses from a > > primary or at least major bandwidth provider. Addresses found to be > > leased or provided in with a paper-tiger transit arrangement are > > subject to reclamation by ARIN. > > > Cons: Unenforceable. > > > Not entirely true. > > It may be difficult to enforce, but, it is not unenforceable. Owen, For all practical purposes, it is unenforceable. ARIN cannot make a meaningful distinction between "you buy a T1 and you get a /X" and "you buy a GRE tunnel and you get a /X". More to the point, I don't want ARIN to waste time trying to do so. IMO ARIN should be working to ensure two things: 1. that the barriers to v6 adoption are as low as we can make them, and 2. that the database be as accurate as we can make it. The market will handle the rest, including the issue of putting unused IPv4 addresses to use. To borrow a phrase from Randy, I don't want a bunch of ametuer regulators attempting to decide what constitutes "connectivity". > If that's the best you can do in the con column for this idea, I think > keeping things this way is vastly superior to your proposed option 1. Option #1 is reality, today, and let's not pretend otherwise. > > 3. Any multihomed registrant using an ARIN AS number and SWIPed for at > > least one year with a /24 or larger is entitled to convert the > > registration to an ARIN direct assignment upon filing the proper > > paperwork. Refusing SWIP or assigning addresses out of region is > > grounds for reclamation. > > I have to admit this third option is interesting and has some appeal. Agreed, although I would remove the threat of reclamation because I don't think this is something ARIN needs to regulate. The commercial agreements between the parties should spell out the expected behavior, including whether or not the addresses may be transferred to the lessee, and under what conditions. Let's do what we can to make sure that the database is accurate, and focus our efforts on v6 going forward. --Jeff _______________________________________________ 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 -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4098 bytes Desc: not available URL: From gbonser at seven.com Fri Feb 4 14:02:49 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 4 Feb 2011 11:02:49 -0800 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13866@RWC-EX1.corp.seven.com> > > >?We actually aren't hasty. We spend a lot of time debating and > discussing > > Behind closed doors with, at best, an abbreviated version eventually > appearing in the form of meeting minutes. At some point certain things have to be done behind closed doors or nothing would get done and debate will continue endlessly. No matter what decision is taken, someone is going to be unhappy. That's just how it is. Sometimes even the majority might be unhappy if it is a decision that needs to be made for bigger reasons. I don't think the goal should be to make the maximum number of people happy. The goal should be for a working internet for the maximum number of people. While things can be somewhat "democratic" in that people get to voice their opinions, at some point the decisions need to be made by the people elected to make them. From bill at herrin.us Fri Feb 4 14:27:20 2011 From: bill at herrin.us (William Herrin) Date: Fri, 4 Feb 2011 14:27:20 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> Message-ID: On Thu, Feb 3, 2011 at 4:21 PM, George Bonser wrote: > I agree with this. ?Unless something is broken, ARIN has > enough to do without attempting to enforce philosophical positions. Hi George, ARIN has always enforced a philosophical position: IP addresses go to those with justified technical need. IP addresses are not property. Address leasing without ARIN in the loop holds the prospect of demolishing those principles, far more so than paid address transfers with the recipient explicitly evaluated by ARIN. At least with the transfers the "legal fiction" is relatively close to the reality: that you're paying someone the one time cost of altering his network to consume fewer addresses. What fiction for leasing meets those two principles? A potential is not a reality. Scott's right about wait-and-see. BUT, from the ounce of prevention worth a pound of cure corner, it might be helpful for ARIN to signal early that address leasing in the absence of a healthy transfer market would be treated as a public policy problem to be solved to the detriment of the lessors. If it does no more than cause the leasing companies to set a buy price for every assignment, we'll have avoided the worst of the danger. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gbonser at seven.com Fri Feb 4 14:38:09 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 4 Feb 2011 11:38:09 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> > > Hi George, > > ARIN has always enforced a philosophical position: By philosophical I meant the notion that leasing IPs was somehow "dishonest" or would be more "dishonest" after runout than it is today. > IP addresses go to those with justified technical need. > IP addresses are not property. Wouldn't the use of one's IP space by someone else actually improve the assignee's usage ratio? That can be thought of as in improvement in usage efficiency. > Address leasing without ARIN in the loop holds the prospect of > demolishing those principles. Ok, why moreso after runout than now? If someone doesn't qualify for addresses from ARIN today, they might "lease" them from someone else. After runout, more people wanting to lease space will be people who would qualify for IP space but it isn't available. In other words, the proportion of "bad guys" to "good guys" in the mix will change. > far more so than paid address transfers > with the recipient explicitly evaluated by ARIN. At least with the > transfers the "legal fiction" is relatively close to the reality: that > you're paying someone the one time cost of altering his network to > consume fewer addresses. What fiction for leasing meets those two > principles? Mantra: "It doesn't matter. V4 is dead." More of the people leasing addresses will be people who legitimately qualify for the space. The problem will become smaller after runout than it is today in a relative sense. So you toss someone a $150/month circuit that you never use in order to get a /24 SWIPed to you or you just pay them $150/month and do without the circuit you never use, what's the difference? I just don't see where there is a problem. It seems that some just don't like the notion of someone "leasing" IP space. From khelms at zcorum.com Fri Feb 4 14:50:08 2011 From: khelms at zcorum.com (Scott Helms) Date: Fri, 04 Feb 2011 14:50:08 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> Message-ID: <4D4C5870.1020009@zcorum.com> > Address leasing without ARIN in the loop holds the prospect of > demolishing those principles, far more so than paid address transfers > with the recipient explicitly evaluated by ARIN. At least with the > transfers the "legal fiction" is relatively close to the reality: that > you're paying someone the one time cost of altering his network to > consume fewer addresses. What fiction for leasing meets those two > principles? So what do you think of what we do today, and have for over 5 years, which is reassign or reallocate space to ISPs we are not providing a connection to in order for smaller providers to gain access to portable address space? We started doing this to help ISPs that don't qualify in some way (hard to be multi-homed in areas without more than one provider) or don't want to deal with ARIN. You could say we are a corner case and most of the customers that leverage this service from us are smaller (often in rural) retail ISPs, which ARIN seems to be recognizing have different needs from their larger brethren. I'd also point out that we push the same requirements down to those ISPs that ARIN places on us and frankly our ability to accurately assess utilization is _much_ better than ARIN's because in most of these cases we're also helping take care of the network infrastructure. That was the other reason we started leasing space, we were spending too much time renumbering networks for ISPs that were desperate to obtain lower cost Internet connectivity. > > A potential is not a reality. Scott's right about wait-and-see. BUT, > from the ounce of prevention worth a pound of cure corner, it might be > helpful for ARIN to signal early that address leasing in the absence > of a healthy transfer market would be treated as a public policy > problem to be solved to the detriment of the lessors. If it does no > more than cause the leasing companies to set a buy price for every > assignment, we'll have avoided the worst of the danger. Frankly I wouldn't care if this happened since we only charge a little above what ARIN charges directly to cover our record keeping costs, but I have no idea how any of the RIRs could possibly enforce it. One thing I could see happening is ARIN (and the other RIRs) could offer information about what space ought to cost, i.e. break down what it costs a direct registrant per /24 etc. Also, a listing of providers that have space and don't gouge for it might be workable, though again verification could be an issue. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bill at herrin.us Fri Feb 4 15:11:53 2011 From: bill at herrin.us (William Herrin) Date: Fri, 4 Feb 2011 15:11:53 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <4D4C5870.1020009@zcorum.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <4D4C5870.1020009@zcorum.com> Message-ID: On Fri, Feb 4, 2011 at 2:50 PM, Scott Helms wrote: > So what do you think of what we do today, and have for over 5 years, which > is reassign or reallocate space to ISPs we are not providing a connection to > in order for smaller providers to gain access to portable address space? ?We > started doing this to help ISPs that don't qualify in some way (hard to be > multi-homed in areas without more than one provider) or don't want to deal > with ARIN. Hi Scott, Sounds "mostly harmless." > Frankly I wouldn't care if this happened since we only charge a little above > what ARIN charges directly to cover our record keeping costs, but I have no > idea how any of the RIRs could possibly enforce it. Enforce it in the breach: start with a complaint from the lessee who isn't being allowed to transfer the addresses at ARIN. If the complaint is sustained, that both triggers an involuntary transfer (assuming the registrant qualifies and pays the ARIN fees) and a full audit of the lessor's allocations. ARIN won't have to go looking for this. IF there's a real problem, ARIN will be deluged in complaints from the folks whose address lessors won't sell. In other words, your practices would be at very low risk, especially if you allow folks a reasonable buyout when they're ready to move out from under your umbrella. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From khelms at zcorum.com Fri Feb 4 15:25:33 2011 From: khelms at zcorum.com (Scott Helms) Date: Fri, 04 Feb 2011 15:25:33 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <4D4C5870.1020009@zcorum.com> Message-ID: <4D4C60BD.60105@zcorum.com> Hi Bill, > Enforce it in the breach: start with a complaint from the lessee who > isn't being allowed to transfer the addresses at ARIN. If the > complaint is sustained, that both triggers an involuntary transfer > (assuming the registrant qualifies and pays the ARIN fees) and a full > audit of the lessor's allocations. That makes sense, though the cost of investigation could be problematic. I suppose we could have "community investigation" which would help gather data about the networks for ARIN to look at. > ARIN won't have to go looking for this. IF there's a real problem, > ARIN will be deluged in complaints from the folks whose address > lessors won't sell. > > In other words, your practices would be at very low risk, especially > if you allow folks a reasonable buyout when they're ready to move out > from under your umbrella. We do and we also help ISPs navigate through getting their own ASN and IP space and understand why they need to do certain things like turning in the blocks they were given by their backbone provider once they do get an allocation from us or directly from ARIN. > Regards, > Bill Herrin > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bensons at queuefull.net Fri Feb 4 15:28:31 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 4 Feb 2011 14:28:31 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> Message-ID: <66378892-6907-4AF2-BBCE-293224A05F77@queuefull.net> On Feb 4, 2011, at 1:27 PM, William Herrin wrote: > IP addresses go to those with justified technical need. > IP addresses are not property. > > Address leasing without ARIN in the loop holds the prospect of > demolishing those principles, far more so than paid address transfers > with the recipient explicitly evaluated by ARIN. For addresses that were allocated by ARIN, an organization sub-allocating addresses to their customers is required to follow the philosophically-inspired "justified need" policy. Basically, that organization has the delegated responsibility to enforce ARIN policy. I don't think there are any new problems caused by address leasing, that being the case. More fundamentally, the business relationship shouldn't matter as long as the policy is enforced. The "traditional" mechanism of sub-allocation might provide addresses as part of a network service. But that's not a requirement. Why not lease addresses as a component of some consulting service? Or as a bonus for buying a box of donuts? Why would anybody care, as long as the "justified need" policy is enforced? Cheers, -Benson From bensons at queuefull.net Fri Feb 4 15:30:14 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 4 Feb 2011 14:30:14 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> Message-ID: <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> On Feb 4, 2011, at 1:38 PM, George Bonser wrote: > Mantra: "It doesn't matter. V4 is dead." IPv4 is not dead. It's an aging parent with a young child - hopefully it will be around long enough to see IPv6 reach maturity. :) Cheers, -Benson From gbonser at seven.com Fri Feb 4 15:33:08 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 4 Feb 2011 12:33:08 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Benson Schliesser > Sent: Friday, February 04, 2011 12:30 PM > To: George Bonser > Cc: William Herrin; John Curran; arin-ppml at arin.net > Subject: Re: [arin-ppml] "Leasing" of space via non-connectivity > providers (was: Re: And so it ends... ) > > > On Feb 4, 2011, at 1:38 PM, George Bonser wrote: > > > Mantra: "It doesn't matter. V4 is dead." > > IPv4 is not dead. It's an aging parent with a young child - hopefully > it will be around long enough to see IPv6 reach maturity. :) Hi, Benson I guess my feeling when I wrote that is that we are possibly going to get in a situation of diminishing return where more and more work is being done on something that is no longer growing. "Dead" might be the wrong word but maybe we should treat it as "fully mature". From scottleibrand at gmail.com Fri Feb 4 15:49:56 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 4 Feb 2011 12:49:56 -0800 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: <4D4B21C8.9090506@arin.net> References: <4D4B21C8.9090506@arin.net> Message-ID: In order to help address Bill's concerns, I thought I'd try posting to the list an explanation of my own personal thoughts and opinions on each of the proposals and draft policies the AC voted on at our most recent meeting. (I'm speaking only for myself, not for the AC.) Please let me know whether or not you find this useful. On Thu, Feb 3, 2011 at 1:44 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) held a meeting on 28 January 2011 and made > decisions about several draft policies and proposals. > > The AC recommended that the ARIN Board of Trustees adopt the following > draft policy: > > ARIN-2010-14: Standardize IP Reassignment Registration Requirements > I feel that this proposal is a step in the right direction toward consistent registration requirements for IPv6, and also meets a legitimate need with regard to non-cable ISPs assigning address space to residential market areas. I saw quite a bit of community support for the policy, and very little opposition, so I voted to send it to the Board. > The AC selected the following proposals as draft policies for adoption > discussion online and at the ARIN XXVII Public Policy Meeting in San > Juan, Puerto Rico. Each draft policy will be posted shortly to the PPML. > > ARIN-prop-119. Globally Coordinated Transfer Policy > I believe this is a policy that will become increasingly necessary as the different RIRs exhaust their IPv4 free pools at different rates, and we see the effect of varying levels of IPv4 supply and demand in different regions' transfer markets, so I voted to bring this up for discussion in San Juan. > ARIN-prop-120. Protecting Number Resources > This seems to be necessary if we want ARIN to proactively look for abandoned or fraudulently obtained resources. Doing so seems like a good idea, and there seems to be quite a bit of community support for some level of proactive effort here. > ARIN-prop-121. Better IPv6 Allocation for ISPs > I'm generally in favor of the goals of this policy, and believe it needs wider discussion at the public policy meeting to determine whether we want to adopt something along these lines. > ARIN-prop-123. Reserved Pool for Critical Infrastructure > There seems to be a fair bit of community support for this idea. The amount of address space required for CI reservations would be small, so I felt this was worthy of discussion. > ARIN-prop-127. Shared Transition Space for IPv4 Address Extension > This is a very timely proposal with a lot of community support. I am undecided as to whether it's necessary, but definitely feel it needs to be discussed in Puerto Rico. > > The AC added the following proposal to their docket but decided not to > select it as a draft policy at this time: > > ARIN-prop-126. Compliance Requirement > I believe the goals behind this proposal are sound, and would like to see it discussed further by the community. There are some definite concerns around the exact structure and text of the proposal that still need to be worked on. I voted to select it as a draft policy, because I believe those can be worked out before the April meeting, but the majority of the AC disagreed, and voted not to select it for adoption discussion at this time. > > The AC abandoned the following proposals: > > ARIN-prop-128. Replacement of Section 4.2.4.4 > As already discussed in this thread, I felt this proposal is not needed (due to the small number of organizations with requests in process at any given time), and that it had been overtaken by events (since IANA exhaustion was going to occur just days after our meeting). Since I don't believe emergency Board action was warranted, I feel abandonment was the proper action. ARIN-prop-129. IPv4 Addresses for Process Participants > ARIN-prop-130. IPv4 Transition Reservation for Every ASN > It wasn't clear to me whether these policy proposals were serious, or made in jest, but either way they did not warrant further work by the AC or further consideration by the community. -Scott > > The AC abandoned ARIN-prop-128 due to opposition on the list, and > because there is insufficient time to implement the proposal through the > normal PDP. As a result, the proposal would need to be a Board Emergency > PDP action to have any effect. The AC understands that the use of the > emergency process requires that there be significant risk to ARIN should > the Board allow a situation to continue. This matter does not warrant > the use of the emergency process. > > The AC abandoned ARIN-prop-129 and ARIN-prop-130 because they violate > the community principle of needs-based assignments. > > The PDP states, ?Any member of the community, including a proposal > originator, may initiate a Discussion Petition if they are dissatisfied > with the action taken by the Advisory Council regarding any specific > policy proposal.? Proposals 126, 128, 129 and 130 may be petitioned > (Discussion Petition) to try to change them into draft policies for > adoption discussion on the Public Policy Mailing List and at the April > Public Policy Meeting. 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 Policy Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > > > > > _______________________________________________ > 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 bensons at queuefull.net Fri Feb 4 16:37:15 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 4 Feb 2011 15:37:15 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> Message-ID: <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> On Feb 4, 2011, at 2:33 PM, George Bonser wrote: >>> Mantra: "It doesn't matter. V4 is dead." >> >> IPv4 is not dead. It's an aging parent with a young child - hopefully >> it will be around long enough to see IPv6 reach maturity. :) > > I guess my feeling when I wrote that is that we are possibly going to > get in a situation of diminishing return where more and more work is > being done on something that is no longer growing. "Dead" might be the > wrong word but maybe we should treat it as "fully mature". I think we can agree on your last paragraph. IPv4 is no longer the focus for growing networks. But my perspective is that some work needs to be done to keep IPv4 viable during the transition - work in the opposite direction of ARIN's current momentum. ARIN has done a fine job of making sure that IP addresses were not an advantage or hurdle to growth of the Internet. They did this by rationing according to need. Very socialist, in the best sense of the word. And as a result of that policy it was easier to build networks, start businesses, etc; the RIR's socialist policy was a great boon to the capitalism that drove the Internet's growth. But the situation has changed. Soon, we will no longer be rationing supply, because the supply is gone. As a result of IPv4 maturity, and the impending scarcity that entails, I'd suggest RIR policy should be to relax control of the resource. Allow a market to do what markets do best: efficiently distribute a scarce resource. The benefit of an open address market would be significant. Hosting companies need IPv4 addresses more than broadband companies; Western countries have more IPv4 addresses than non-Western countries. And without a market, organizations with excess supply have no incentive to redistribute it. Markets create the incentive. If ARIN relaxes the official position regarding IPv4 management policy, then we can step away from IPv4 and focus on IPv6. Cheers, -Benson From jcurran at arin.net Fri Feb 4 17:00:05 2011 From: jcurran at arin.net (John Curran) Date: Fri, 4 Feb 2011 22:00:05 +0000 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> Message-ID: <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> On Feb 4, 2011, at 4:37 PM, Benson Schliesser wrote: > But the situation has changed. Soon, we will no longer be rationing supply, because the supply is gone. As a result of IPv4 maturity, and the impending scarcity that entails, I'd suggest RIR policy should be to relax control of the resource. Allow a market to do what markets do best: efficiently distribute a scarce resource. There is presently the specified transfer that provides some support for a limited market of sorts, without departing from the conservation and aggregation goals in the policy framework. Is this insufficient to provide the incentive for efficient distribution? If a less restricted, more dynamic market is desirable, then would it be one that operated without consideration of the need or aggregation requirements (i.e. any size block transfer allowed, and to any party?) Some of these topics were discussed at length in the formation of the current specified transfer policy, so it would be good to discuss how the policy requirements have since changed. > The benefit of an open address market would be significant. Hosting companies need IPv4 addresses more than broadband companies; Western countries have more IPv4 addresses than non-Western countries. And without a market, organizations with excess supply have no incentive to redistribute it. Markets create the incentive. > > If ARIN relaxes the official position regarding IPv4 management policy, then we can step away from IPv4 and focus on IPv6. I believe you mean "if the ARIN Community develops such policy"... FYI, /John From tedm at ipinc.net Fri Feb 4 17:59:42 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 04 Feb 2011 14:59:42 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> Message-ID: <4D4C84DE.1060208@ipinc.net> On 2/4/2011 1:37 PM, Benson Schliesser wrote: > > On Feb 4, 2011, at 2:33 PM, George Bonser wrote: > >>>> Mantra: "It doesn't matter. V4 is dead." >>> >>> IPv4 is not dead. It's an aging parent with a young child - >>> hopefully it will be around long enough to see IPv6 reach >>> maturity. :) >> >> I guess my feeling when I wrote that is that we are possibly going >> to get in a situation of diminishing return where more and more >> work is being done on something that is no longer growing. "Dead" >> might be the wrong word but maybe we should treat it as "fully >> mature". > > I think we can agree on your last paragraph. IPv4 is no longer the > focus for growing networks. But my perspective is that some work > needs to be done to keep IPv4 viable during the transition - work in > the opposite direction of ARIN's current momentum. > > ARIN has done a fine job of making sure that IP addresses were not an > advantage or hurdle to growth of the Internet. They did this by > rationing according to need. Very socialist, in the best sense of > the word. And as a result of that policy it was easier to build > networks, start businesses, etc; the RIR's socialist policy was a > great boon to the capitalism that drove the Internet's growth. > > But the situation has changed. Soon, we will no longer be rationing > supply, because the supply is gone. As a result of IPv4 maturity, > and the impending scarcity that entails, I'd suggest RIR policy > should be to relax control of the resource. Allow a market to do > what markets do best: efficiently distribute a scarce resource. > > The benefit of an open address market would be significant. Hosting > companies need IPv4 addresses more than broadband companies; Western > countries have more IPv4 addresses than non-Western countries. And > without a market, organizations with excess supply have no incentive > to redistribute it. Markets create the incentive. > You talk about creating a market like someone can just sit back and wave a wand and bang - a market is created. Markets are created by customer demand and the bulk of the customer demand is coming from the end users not the hosters. And there is an ENORMOUS amount of IPv4 tied up with end users right now. Once the end users start shifting and letting it go, there will be tons of IPv4 available for hosting companies. If for example the cellular carriers were to sunset their 3G networks tomorrow then there would be no IPv4 shortage. The IPv4 "value" curve is going to be very, very sharp. Over the next few years as supplies tighten the value of IPv4 will go up, but the moment that end users start accepting and using IPv6 then the value of IPv4 will collapse. This is the speculators realm. You CANNOT built a sustainable business on just this one spike. If there was a chance that there would be PERMANENTLY larger amount of demand for IPv4 than supply of it, THEN a business could be built on this. But there won't be. It is nothing more than a region to gamble in. Existing businesses that specialize in gambling, such as stock investment houses, are the ones to get involved in this. But none of them are moving to do it because they can see that this isn't sustainable. Ted > If ARIN relaxes the official position regarding IPv4 management > policy, then we can step away from IPv4 and focus on IPv6. > > Cheers, -Benson > > _______________________________________________ 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 aaron at wholesaleinternet.net Fri Feb 4 18:03:24 2011 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 4 Feb 2011 17:03:24 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: <0cd201cbc4bf$baf95090$30ebf1b0$@net> I would question whether that's a valid reason to abandon a proposal. It's my understanding that if one doesn't like the way ARIN does something the proper channel for change is the PDP. If the AC is going to abandon those proposals because "it's not the way we do it" then what IS the proper channel? Aaron From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte Sent: Thursday, February 03, 2011 9:35 PM To: William Herrin; arin-ppml at arin.net Subject: Re: [arin-ppml] Advisory Council Meeting Results - January 2011 Bill, So in the case of PP 130 for example. The PP was abandoned because it didn't conform to the communities principle of needs-based assignments. And, that was the stated reason. A paragraph to say that would be no clearer, nor would it make the author feel any better. I suppose we could state the obvious, that we appreciate the author's involvement and willingness to engage in the PDP. We all do appreciate that and I guess we should state it....but somehow I believe you might find fault with that statement...and perhaps this one....considering each disingenuous. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of William Herrin Sent: Thu 2/3/2011 8:18 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Advisory Council Meeting Results - January 2011 On Thu, Feb 3, 2011 at 6:31 PM, David Farmer wrote: > Yes, but the current policy (2009-8) activated today with IANA exhaustion, > it would have taken emergency action to prevent that. Or are you suggestion > we should go down to three months, back to twelve months, and then back down > to three months again? Honestly, that doesn't sound like a good idea to me. David, That might have been a good reason for bouncing it. But "there isn't time" is disingenuous. There's always time. It sets me off when a member of the AC (or the AC as a whole) announces that there isn't time for something. Not enough time to get this through the process. Too many proposals, not enough time to work on this one. Call it a pet peeve. Many of you are past your first terms. If you couldn't figure out how to make time, you shouldn't have run for reelection. You know: lead, follow or ::get out of the way::. Those of you past your first terms did run for reelection. So now it's just a wussy excuse. This is part of another irritant for me as well: I find the brusque way the AC disposes of proposals it decides to abandon to be disrespectful to their authors. A proposal author has spent hours behind the scenes carefully crafting language, researching process and writing justification. When you make the decision instead of leaving it to consensus, simple courtesy demands at least a paragraph from each of you explaining why the proposal wasn't good enough. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3420 - Release Date: 02/03/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Fri Feb 4 18:14:57 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 04 Feb 2011 15:14:57 -0800 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: <0cd201cbc4bf$baf95090$30ebf1b0$@net> References: <4D4B21C8.9090506@arin.net> <0cd201cbc4bf$baf95090$30ebf1b0$@net> Message-ID: <4D4C8871.7090706@bogus.com> On 2/4/11 3:03 PM, Aaron Wendel wrote: > I would question whether that?s a valid reason to abandon a proposal. > It?s my understanding that if one doesn?t like the way ARIN does > something the proper channel for change is the PDP. If the AC is going > to abandon those proposals because ?it?s not the way we do it? then what > IS the proper channel? Or it's possible that widespread opposition to the proposal at a more basic level than the AC is a factor in considering whether we should consider doing it some other way. I and many other's opposed 130 because we belive that assignment method lacks any justification. A lack of consensus that it's even remotely a good idea seems like a factor for the AC to consider. No, we don't do it that way. joel > > Aaron > > > > > > *From:*arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > *On Behalf Of *Bill Darte > *Sent:* Thursday, February 03, 2011 9:35 PM > *To:* William Herrin; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Advisory Council Meeting Results - January 2011 > > > > Bill, > > So in the case of PP 130 for example. The PP was abandoned because it > didn't conform to the communities principle of needs-based assignments. > And, that was the stated reason. > > A paragraph to say that would be no clearer, nor would it make the > author feel any better. > I suppose we could state the obvious, that we appreciate the author's > involvement and willingness to engage in the PDP. > > We all do appreciate that and I guess we should state it....but somehow > I believe you might find fault with that statement...and perhaps this > one....considering each disingenuous. > > bd > > > -----Original Message----- > From: arin-ppml-bounces at arin.net on behalf of William Herrin > Sent: Thu 2/3/2011 8:18 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Advisory Council Meeting Results - January 2011 > > On Thu, Feb 3, 2011 at 6:31 PM, David Farmer wrote: >> Yes, but the current policy (2009-8) activated today with IANA exhaustion, >> it would have taken emergency action to prevent that. Or are you > suggestion >> we should go down to three months, back to twelve months, and then back > down >> to three months again? Honestly, that doesn't sound like a good idea > to me. > > David, > > That might have been a good reason for bouncing it. But "there isn't > time" is disingenuous. There's always time. > > It sets me off when a member of the AC (or the AC as a whole) > announces that there isn't time for something. Not enough time to get > this through the process. Too many proposals, not enough time to work > on this one. Call it a pet peeve. > > Many of you are past your first terms. If you couldn't figure out how > to make time, you shouldn't have run for reelection. You know: lead, > follow or ::get out of the way::. Those of you past your first terms > did run for reelection. So now it's just a wussy excuse. > > This is part of another irritant for me as well: I find the brusque > way the AC disposes of proposals it decides to abandon to be > disrespectful to their authors. A proposal author has spent hours > behind the scenes carefully crafting language, researching process and > writing justification. When you make the decision instead of leaving > it to consensus, simple courtesy demands at least a paragraph from > each of you explaining why the proposal wasn't good enough. > > -Bill > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > ------------------------------------------------------------------------ > > No virus found in this message. > Checked by AVG - www.avg.com > Version: 10.0.1204 / Virus Database: 1435/3420 - Release Date: 02/03/11 > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From BillD at cait.wustl.edu Fri Feb 4 19:40:37 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Fri, 4 Feb 2011 18:40:37 -0600 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 References: <4D4B21C8.9090506@arin.net> <0cd201cbc4bf$baf95090$30ebf1b0$@net> Message-ID: The overwhelming sentiment on the PPML for both the PP129 and PP130 was opposed. And, most of that sentiment reflected the tradition of the world based upon RFC 2050's needs-based assignments. BTW the author is correct in that PP130 is not as directly associated with needs based assignment, since it simply reserves space for future use of ASN holders. However, the AC believed that in a time of scarcity, such reserves would preclude others with immediate needs from acquiring those resource and was thus tantamount to the same problem. bd -----Original Message----- From: Aaron Wendel [mailto:aaron at wholesaleinternet.net] Sent: Fri 2/4/2011 5:03 PM To: Bill Darte; 'William Herrin'; arin-ppml at arin.net Subject: RE: [arin-ppml] Advisory Council Meeting Results - January 2011 I would question whether that's a valid reason to abandon a proposal. It's my understanding that if one doesn't like the way ARIN does something the proper channel for change is the PDP. If the AC is going to abandon those proposals because "it's not the way we do it" then what IS the proper channel? Aaron From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Bill Darte Sent: Thursday, February 03, 2011 9:35 PM To: William Herrin; arin-ppml at arin.net Subject: Re: [arin-ppml] Advisory Council Meeting Results - January 2011 Bill, So in the case of PP 130 for example. The PP was abandoned because it didn't conform to the communities principle of needs-based assignments. And, that was the stated reason. A paragraph to say that would be no clearer, nor would it make the author feel any better. I suppose we could state the obvious, that we appreciate the author's involvement and willingness to engage in the PDP. We all do appreciate that and I guess we should state it....but somehow I believe you might find fault with that statement...and perhaps this one....considering each disingenuous. bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of William Herrin Sent: Thu 2/3/2011 8:18 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Advisory Council Meeting Results - January 2011 On Thu, Feb 3, 2011 at 6:31 PM, David Farmer wrote: > Yes, but the current policy (2009-8) activated today with IANA exhaustion, > it would have taken emergency action to prevent that. Or are you suggestion > we should go down to three months, back to twelve months, and then back down > to three months again? Honestly, that doesn't sound like a good idea to me. David, That might have been a good reason for bouncing it. But "there isn't time" is disingenuous. There's always time. It sets me off when a member of the AC (or the AC as a whole) announces that there isn't time for something. Not enough time to get this through the process. Too many proposals, not enough time to work on this one. Call it a pet peeve. Many of you are past your first terms. If you couldn't figure out how to make time, you shouldn't have run for reelection. You know: lead, follow or ::get out of the way::. Those of you past your first terms did run for reelection. So now it's just a wussy excuse. This is part of another irritant for me as well: I find the brusque way the AC disposes of proposals it decides to abandon to be disrespectful to their authors. A proposal author has spent hours behind the scenes carefully crafting language, researching process and writing justification. When you make the decision instead of leaving it to consensus, simple courtesy demands at least a paragraph from each of you explaining why the proposal wasn't good enough. -Bill -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _____ No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1204 / Virus Database: 1435/3420 - Release Date: 02/03/11 -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Feb 4 20:48:55 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Feb 2011 17:48:55 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <4D4C84DE.1060208@ipinc.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> Message-ID: > > And there is an ENORMOUS amount of IPv4 tied up with end users right > now. Once the end users start shifting and letting it go, there > will be tons of IPv4 available for hosting companies. If for example > the cellular carriers were to sunset their 3G networks tomorrow then > there would be no IPv4 shortage. > Not to rain on your parade or anything, but, once the end users have shifted to IPv6 and deprecated their IPv4, what use is IPv4 to content providers? Content providers need to provide the content to end users for it to be useful, no? If the end-users are all on IPv6, I don't think IPv4 will help so much with that. > The IPv4 "value" curve is going to be very, very sharp. Over the > next few years as supplies tighten the value of IPv4 will go up, but the moment that end users start accepting and using IPv6 then the value of IPv4 will collapse. > s/years/months/ The value curve on IPv4 addresses will also serve as an incentive to deploy IPv6. Owen From jbates at brightok.net Fri Feb 4 21:28:28 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 20:28:28 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <20110204141725.GA29492@eagle.aitken.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> <20110204141725.GA29492@eagle.aitken.com> Message-ID: <4D4CB5CC.2010705@brightok.net> >>> 2. Address leasing is not allowed. Must get your addresses from a >>> primary or at least major bandwidth provider. Addresses found to be >>> leased or provided in with a paper-tiger transit arrangement are >>> subject to reclamation by ARIN. Okay. Can't find the original. This is just horrid. You do know that ISPs actually enjoy maintaining customers who have no desire to renumber out of IP addresses they were assigned? I keep a sprint circuit when they can't meet my bandwidth requirements. I have some nice /20's from them that are so deeply entrenched by business customers and other ISPs, I'll NEVER renumber out of them. Here's to hoping they go away when IPv6 is more prevalent. However, if I continue to grow my bandwidth needs and sprint still cannot keep up with me, I will downgrade to a token link (DS3 perhaps, and I can still let sprint directs use it) which I must maintain so they don't gripe about me keeping the networks. Jack From jbates at brightok.net Fri Feb 4 21:36:25 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 20:36:25 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <4D4C5870.1020009@zcorum.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <4D4C5870.1020009@zcorum.com> Message-ID: <4D4CB7A9.5030607@brightok.net> On 2/4/2011 1:50 PM, Scott Helms wrote: > So what do you think of what we do today, and have for over 5 years, > which is reassign or reallocate space to ISPs we are not providing a > connection to in order for smaller providers to gain access to > portable address space? We started doing this to help ISPs that don't > qualify in some way (hard to be multi-homed in areas without more than > one provider) or don't want to deal with ARIN. You could say we are a > corner case and most of the customers that leverage this service from > us are smaller (often in rural) retail ISPs, which ARIN seems to be > recognizing have different needs from their larger brethren. I'd also > point out that we push the same requirements down to those ISPs that > ARIN places on us and frankly our ability to accurately assess > utilization is _much_ better than ARIN's because in most of these > cases we're also helping take care of the network infrastructure. > That was the other reason we started leasing space, we were spending > too much time renumbering networks for ISPs that were desperate to > obtain lower cost Internet connectivity. Basically, you are an LIR (as compared to the ISP), which while ARIN distinctions are muddled on such, does exist in the wild. Most charge something for the service, though often it also ends up being someone that is also performing management duties. Connectivity should never be a requirement. If people want to start charging more for being an LIR, let them. They can't go back for more from ARIN or use the transfer options without justifying what they have given out. I do agree that work should be done to deal with IPv4 justifications and whois enforcement, but kicking every LIR or organization who is validly using address space without needing the connectivity anymore is silly. Jack From bensons at queuefull.net Fri Feb 4 23:39:06 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 4 Feb 2011 22:39:06 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> Message-ID: On Feb 4, 2011, at 7:48 PM, Owen DeLong wrote: >> The IPv4 "value" curve is going to be very, very sharp. Over the >> next few years as supplies tighten the value of IPv4 will go up, but the moment that end users start accepting and using IPv6 then the value of IPv4 will collapse. >> > s/years/months/ > > The value curve on IPv4 addresses will also serve as an incentive to deploy IPv6. That's exactly correct, in my opinion. RIR policy has kept the cost of IPv4 addresses lower than they would be "naturally", e.g. if valued as a commodity with growing demand and decreasing supply. When the RIR is no longer a source of addresses, their cost skyrockets compared to historical norms. It's like a balloon held at the bottom of a swimming pool. And as Owen points out, when businesses recognize the cost to continue deploying IPv4, it becomes an obvious incentive to transition to IPv6. In fact, IPv6 is the only way (as far as I'm aware) that a service provider can continue to operate under historical economic models (i.e. when addresses were "free"). Choosing to continue deploying IPv4 will require investment, in addresses and/or NATs. Sadly, because we've waited too long to grow IPv6 penetration to the inflection point ("the moment that end users start accepting and using IPv6"), people will still need to deploy IPv4. Vendors will make money on NATs. And people will find ways to get addresses - one way or another. Cheers, -Benson From tedm at ipinc.net Fri Feb 4 23:52:16 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 04 Feb 2011 20:52:16 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> Message-ID: <4D4CD780.5040604@ipinc.net> On 2/4/2011 5:48 PM, Owen DeLong wrote: >> >> And there is an ENORMOUS amount of IPv4 tied up with end users right >> now. Once the end users start shifting and letting it go, there >> will be tons of IPv4 available for hosting companies. If for example >> the cellular carriers were to sunset their 3G networks tomorrow then >> there would be no IPv4 shortage. >> > Not to rain on your parade or anything, but, once the end users have > shifted to IPv6 and deprecated their IPv4, what use is IPv4 to content > providers? Content providers need to provide the content to end users > for it to be useful, no? If the end-users are all on IPv6, I don't think IPv4 > will help so much with that. > I doubt that they all are going to shift at one time. And even when 90% of them have shifted there's still going to be a few holdouts. I am dead serious, I actually took a support call a few years ago from a guy running the following: http://www.armory.com/~spectre/cwi/hl/ and he actually said that the 128 was a -better- machine than a modern Windows system. Quit laughing!!!! I'm serious!!! >> The IPv4 "value" curve is going to be very, very sharp. Over the >> next few years as supplies tighten the value of IPv4 will go up, but the moment that end users start accepting and using IPv6 then the value of IPv4 will collapse. >> > s/years/months/ > Heh > The value curve on IPv4 addresses will also serve as an incentive to deploy IPv6. > Actually I think it's much more the uncertainty of supply than the price that is the incentive. Businesses (at least, businesses in America) do not have a problem with designing and building products, even expensive products, that require an expensive or limited item to function. But nobody builds products that require things that might not be available from time to time, regardless of the expense. At least, not products for the general public. Take for comparison, gasoline-burning cars and propane powered cars and trucks. Propane is in every city if you are willing to pay enough. In practice, only a handful of gas stations can dispense it into a vehicle. As a result owners of propane=powered vehicles never know if in any given situation there is a gas station around that has a propane tank. It is the uncertainty of knowing if a supply will be available that killed the propane-powered vehicle market. This is why the IPv4 shortage is going to kill IPv4 so quickly, because the mass-market CPE vendors are going to eventually start getting support calls from people who live in po-dunkville with a one-horse ISP in town who for the moment is out of IPv4 but they have IPv6 available. When that happens even the dumbest CPE vendor will throw the towel in on IPv4. But once the stampede of the herd happens there's going to be plenty of people still around, running old software, old hardware or whatever, that will be IPv4 only. And since IPv4 will be plentiful, they won't have any incentive to switch as long as they can keep cannibalizing the computer wrecking yards (ebay, etc.) for parts for their setup. So while the masses will go to IPv6, there will be a minority that will persist on IPv4 for many, many years. The major content providers will still want to service those guys. And so they will keep IPv4 around to do it. In a way the situation is like bicycles in a city. It is impossible for all traffic in a city to move from cars and trucks to bicycles. But it is possible for a minority of commuters to use bicycles. So, these folks are tolerated to the extent that some accommodations are made for them, a bike path here and a bike rack there. And the mass-marketers make a little bit of money selling BSO's (bicycle-shaped objects) so most of them have a rack of BSO's and a rack of bicycle lights and other mostly useless bike accessories. IPv4 will probably end up like that on the Internet - the occasional accommodation make for it here and there. It will never go away completely, but it will never be possible for it to carry the Internet like it does today. Ted > Owen > > From tedm at ipinc.net Sat Feb 5 00:04:44 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 04 Feb 2011 21:04:44 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <4D4CB5CC.2010705@brightok.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> <20110204141725.GA29492@eagle.aitken.com> <4D4CB5CC.2010705@brightok.net> Message-ID: <4D4CDA6C.2020305@ipinc.net> On 2/4/2011 6:28 PM, Jack Bates wrote: > >>>> 2. Address leasing is not allowed. Must get your addresses from a >>>> primary or at least major bandwidth provider. Addresses found to be >>>> leased or provided in with a paper-tiger transit arrangement are >>>> subject to reclamation by ARIN. > > Okay. Can't find the original. This is just horrid. You do know that > ISPs actually enjoy maintaining customers who have no desire to renumber > out of IP addresses they were assigned? > > I keep a sprint circuit when they can't meet my bandwidth requirements. > I have some nice /20's from them that are so deeply entrenched by > business customers and other ISPs, I'll NEVER renumber out of them. But don't you see that this situation isn't going to go away under IPv6? You have circuits today from networks that meet your requirements. Let's assume that you don't have your own numbers and so you get numbers from them. 10 years from now, you have deployed those IPv6 numbers to business customers who don't want to renumber and those networks are no longer meeting your needs - and you will be in exactly the same position. Every ISP that goes from LIR-assigned numbers to their own numbers goes through this. I went through it myself. I also went through it again when we acquired an ISP. In both cases I renumbered instead of keeping old circuits going. And with the benefit of hindsight today, I think the decisions I made to renumber instead of keeping old circuits going were some of the smarter decisions I have made. Ted > Here's to hoping they go away when IPv6 is more prevalent. However, if I > continue to grow my bandwidth needs and sprint still cannot keep up with > me, I will downgrade to a token link (DS3 perhaps, and I can still let > sprint directs use it) which I must maintain so they don't gripe about > me keeping the networks. > > > Jack > _______________________________________________ > 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 jbates at brightok.net Sat Feb 5 00:52:10 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 04 Feb 2011 23:52:10 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <4D4CDA6C.2020305@ipinc.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <57A6FD08-B6E6-4A35-8AA0-A85EE5C4385D@delong.com> <20110204141725.GA29492@eagle.aitken.com> <4D4CB5CC.2010705@brightok.net> <4D4CDA6C.2020305@ipinc.net> Message-ID: <4D4CE58A.4070508@brightok.net> On 2/4/2011 11:04 PM, Ted Mittelstaedt wrote: > > You have circuits today from networks that meet your requirements. > Let's assume that you don't have your own numbers and so you get numbers > from them. 10 years from now, you have deployed those IPv6 numbers to > business customers who don't want to renumber and those networks are > no longer meeting your needs - and you will be in exactly the same > position. > I don't think I was clear. I have a /19 worth of sprint space which wasn't renumbered when I renumbered into my first /18 from ARIN. Since then, I've grown to a total of a /16 worth of space, but those 2 /20's aren't going away until they decide they no longer went the IPv4 addresses. > Every ISP that goes from LIR-assigned numbers to their own numbers > goes through this. I went through it myself. I also went through it > again when we acquired an ISP. In both cases I renumbered instead of > keeping old circuits going. And with the benefit of hindsight today, > I think the decisions I made to renumber instead of keeping old > circuits going were some of the smarter decisions I have made. > Don't get me wrong. I probably should have renumbered them. The cost benefit wasn't worth it, though. It still isn't. Forcing a renumber on those blocks would cost me much more revenue (if they are going to renumber, the business customer might just go to the competitor while they are at it) than paying for a sprint circuit. Jack From bensons at queuefull.net Sun Feb 6 00:32:36 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Sat, 5 Feb 2011 23:32:36 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> Message-ID: <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> Hi, John. On Feb 4, 2011, at 4:00 PM, John Curran wrote: > On Feb 4, 2011, at 4:37 PM, Benson Schliesser wrote: >> But the situation has changed. Soon, we will no longer be rationing supply, because the supply is gone. As a result of IPv4 maturity, and the impending scarcity that entails, I'd suggest RIR policy should be to relax control of the resource. Allow a market to do what markets do best: efficiently distribute a scarce resource. > > There is presently the specified transfer that provides some support for > a limited market of sorts, without departing from the conservation and > aggregation goals in the policy framework. > > Is this insufficient to provide the incentive for efficient distribution? > If a less restricted, more dynamic market is desirable, then would it > be one that operated without consideration of the need or aggregation > requirements (i.e. any size block transfer allowed, and to any party?) > Some of these topics were discussed at length in the formation of the > current specified transfer policy, so it would be good to discuss how > the policy requirements have since changed. The specified transfer service, in its current form, is not sufficient to facilitate efficient distribution. A less-regulated market would be much more dynamic and appealing to buyers and sellers, especially at this stage. But, of course, neither of us wish to recommend a market system that damages the stability of the Internet. Given this fact, and per your suggestion, I'm working on some policy text that I hope to submit this coming week. I look forward to discussing the ideas and improving them based on the constructive feedback of the community. Cheers, -Benson From jcurran at arin.net Sun Feb 6 00:43:19 2011 From: jcurran at arin.net (John Curran) Date: Sun, 6 Feb 2011 05:43:19 +0000 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> Message-ID: On Feb 6, 2011, at 12:32 AM, Benson Schliesser wrote: > The specified transfer service, in its current form, is not sufficient to facilitate efficient distribution. A less-regulated market would be much more dynamic and appealing to buyers and sellers, especially at this stage. To the extent that the current specified transfer policy does not facilitate efficient distribution in your view, it would be good to further elaborate on "how efficient" we should be aiming for, and why. If there is consensus on this point, it's relatively easy to change the specified transfer policy to match... > But, of course, neither of us wish to recommend a market system that damages the stability of the Internet. Given this fact, and per your suggestion, I'm working on some policy text that I hope to submit this coming week. I look forward to discussing the ideas and improving them based on the constructive feedback of the community. Sounds good (and thanks for your efforts on this!) /John John Curran President and CEO ARIN From jbates at brightok.net Sun Feb 6 10:30:34 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 09:30:34 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> Message-ID: <4D4EBE9A.308@brightok.net> On 2/5/2011 11:32 PM, Benson Schliesser wrote: > > The specified transfer service, in its current form, is not sufficient to facilitate efficient distribution. A less-regulated market would be much more dynamic and appealing to buyers and sellers, especially at this stage. > The problem, i believe, with a less-regulated market is that we'd see much smaller address block transfers, which would jeopardize core routing (as if it's not going to be bad enough). A lot of individual /24 transfers could prove very dangerous for us, while the parties involved in such transfers may not understand or care about the problem. Removing ARIN completely would destroy what use is left in the whois database. One of the stated goals of ARIN is to protect routing tables from bloat, which is reflected in the minimum requirements to receive an allocation. This doesn't, in practice, actually protect the tables, as there are many who deaggregate their allocations, but that is beyond the control of ARIN. Jack From spiffnolee at yahoo.com Sun Feb 6 11:36:02 2011 From: spiffnolee at yahoo.com (Lee Howard) Date: Sun, 6 Feb 2011 08:36:02 -0800 (PST) Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> Message-ID: <839813.74109.qm@web63302.mail.re1.yahoo.com> > From: Benson Schliesser > > Sadly, because we've waited too long to grow IPv6 penetration to > the inflection point ("the moment that end users start accepting and > using IPv6"), people will still need to deploy IPv4. Vendors will > make money on NATs. And people will find ways to get addresses > - one way or another. This is often asserted and generally accepted. Is it true? Nobody wants NAT: ISPs, content providers, law enforcement, copyright holders, game console manufacturers, web advertisers, home gateway vendors, and end users all have an interest in avoiding NAT. Even NAT vendors are decorously sheepish in selling their products. If everyone wants to avoid it, why are we stuck with it? 1. ISPs aren't ready for IPv6. This belief is rapidly being overtaken by events--most ISPs will have broad IPv6 this year. 2. Content isn't ready for IPv6. This belief is rapidly being overtaken by events. World IPv6 Day is a test-drive of content, which should go a long way toward eliminating barriers. 3. Home gateways aren't ready for IPv6. This belief is slowly being overtaken by events. All home gateway makers are developing IPv6, and industry is doing better as telling them what needs to be fixed. However, it may still be true that all home gateways sold before ARIN runout have to be replaced. 4. Consumer electronics aren't ready for IPv6. This is widely true, although more embedded OSs are becoming IPv6-capable. Most web-capable devices will be capable of simple firmware or OS updates. Untraditional networked devices (like entertainment systems) are in trouble. How do we improve IPv6 uptake in these categories? If all of a household's devices speak IPv6, and the ISP provides IPv6, and all of the content the household accesses is available over IPv6 (including NAT64), that household no longer needs IPv4. What would it take for the number of households in that state to increase faster than new Internet activations? Think big-- there are a lot of stakeholders whose interests align against NAT. Lee From jcurran at arin.net Sun Feb 6 11:50:02 2011 From: jcurran at arin.net (John Curran) Date: Sun, 6 Feb 2011 16:50:02 +0000 Subject: [arin-ppml] Desirability of a more efficient transfer market (was: "Leasing" of space via non-connectivity providers) In-Reply-To: <4D4EBE9A.308@brightok.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> <4D4EBE9A.308@brightok.net> Message-ID: <9ECB4EC4-97EA-44EA-ABBD-B1E3D212830A@arin.net> On Feb 6, 2011, at 10:30 AM, Jack Bates wrote: > On 2/5/2011 11:32 PM, Benson Schliesser wrote: >> >> The specified transfer service, in its current form, is not sufficient to facilitate efficient distribution. A less-regulated market would be much more dynamic and appealing to buyers and sellers, especially at this stage. > The problem, i believe, with a less-regulated market is that we'd see much smaller address block transfers, which would jeopardize core routing (as if it's not going to be bad enough). A lot of individual /24 transfers could prove very dangerous for us, while the parties involved in such transfers may not understand or care about the problem. Removing ARIN completely would destroy what use is left in the whois database. Potential introduction of many smaller routes was identified as one of the reasons for holding to existing allocation policy for transfers. If this no longer matches the community's expectations, then it should be discussed again. There is another effect of having a documented-need requirement in the transfer policy: because the existing allocation policy only provides for short-term relief of a service providers needs, transfers via the policy can only meet short-term needs for IPv4 address space. I do not believe that this aspect was discussed in any detail during the policy discussion, but would also warrant consideration. It's been noted that there's a significant amount of non-routed IPv4 address space, and it's clear that a highly- efficient market would provide the ability for the well-funded to satisfy their *long-term* IPv4 requirements, hence allowing them to opt out of any consideration of IPv6 altogether. One might argue that this indeed should be an option available to well-funded ISPs, and further that if there's sufficient IPv4 space for the Internet to continue to grow such a manner, then IPv6 actually isn't needed. Under that viewpoint, the present specified-transfer policy with its short-term transfer limit does not suffice. FYI only; as both sides of this matter have been raised to me as a non-obvious aspect of the present policy, I felt it worth outlining for consideration during discussion. /John John Curran President and CEO ARIN From scottleibrand at gmail.com Sun Feb 6 15:54:14 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sun, 6 Feb 2011 12:54:14 -0800 Subject: [arin-ppml] Desirability of a more efficient transfer market (was: "Leasing" of space via non-connectivity providers) In-Reply-To: <9ECB4EC4-97EA-44EA-ABBD-B1E3D212830A@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> <4D4EBE9A.308@brightok.net> <9ECB4EC4-97EA-44EA-ABBD-B1E3D212830A @arin.net> Message-ID: <6F0AF3BC-3DD7-44CC-AEC5-70E7F6D61330@gmail.com> On Feb 6, 2011, at 8:50 AM, John Curran wrote: > There is another effect of having a documented-need requirement > in the transfer policy: because the existing allocation policy > only provides for short-term relief of a service providers needs, > transfers via the policy can only meet short-term needs for IPv4 > address space. I do not believe that this aspect was discussed > in any detail during the policy discussion, but would also warrant > consideration. We did discuss (and adopt) policy that allows for orgs to meet 1 year of justified need through transfers, as opposed to 3 months for post-IANA-exhaustion allocations and assignments from the ARIN free pool. If anyone believes that 1 year is not optimal, or that we should change transfer policy in any other ways, I suspect we'll start to see data to inform the debate over the next year or so as demand for transfers solidifies, so I'm guessing we'll likely want to discuss possible amendments to transfer policy before too long. -Scott From hannigan at gmail.com Sun Feb 6 18:46:30 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 6 Feb 2011 18:46:30 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <4D4EBE9A.308@brightok.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> <4D4EBE9A.308@brightok.net> Message-ID: On Sun, Feb 6, 2011 at 10:30 AM, Jack Bates wrote: > On 2/5/2011 11:32 PM, Benson Schliesser wrote: >> >> The specified transfer service, in its current form, is not sufficient to >> facilitate efficient distribution. ?A less-regulated market would be much >> more dynamic and appealing to buyers and sellers, especially at this stage. >> > > The problem, i believe, with a less-regulated market is that we'd see much > smaller address block transfers, which would jeopardize core routing (as if > it's not going to be bad enough). A lot of individual /24 transfers could > prove very dangerous for us, while the parties involved in such transfers > may not understand or care about the problem. Removing ARIN completely would > destroy what use is left in the whois database. > > One of the stated goals of ARIN is to protect routing tables from bloat, > which is reflected in the minimum requirements to receive an allocation. > This doesn't, in practice, actually protect the tables, as there are many > who deaggregate their allocations, but that is beyond the control of ARIN. > > I think that network operators are better suited to manage this as part of a market activity than a "regulation" devised by ARIN. Historically, "regulation" of routing has been considered operational and ARIN policy in this area is generally ignored. From hannigan at gmail.com Sun Feb 6 18:48:46 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Sun, 6 Feb 2011 18:48:46 -0500 Subject: [arin-ppml] Application requests for IPv6? Message-ID: Staff et. Al, Can we get a recap of activity around resource requests for IPv6 and a characterization of refusals, if any? If there are none, it would be interesting to hear a general conclusion as to why. I'm interested to see if there are any holes here considering all of the work that has been done to ease access to v6 for transition. Best, and go Steelers! -M< From jcurran at arin.net Sun Feb 6 19:13:26 2011 From: jcurran at arin.net (John Curran) Date: Mon, 7 Feb 2011 00:13:26 +0000 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> <4D4EBE9A.308@brightok.net> Message-ID: On Feb 6, 2011, at 6:46 PM, Martin Hannigan wrote: > > On Sun, Feb 6, 2011 at 10:30 AM, Jack Bates wrote: >> >> >> One of the stated goals of ARIN is to protect routing tables from bloat, >> which is reflected in the minimum requirements to receive an allocation. >> This doesn't, in practice, actually protect the tables, as there are many >> who deaggregate their allocations, but that is beyond the control of ARIN. >> > > I think that network operators are better suited to manage this as > part of a market activity than a "regulation" devised by ARIN. > Historically, "regulation" of routing has been considered operational > and ARIN policy in this area is generally ignored. Martin is correct, in that ARIN's mission is number resource management not regulation of the routing of number resources. Historically, the address policies that have been developed by the community do consider the indirect routing impact as only one of the many factors, but in general we have avoided setting any explicit routing requirements for number resources. In the case of the specified transfer policy, the requirement to qualify to receive such just as an allocation under current policies doesn't create any "regulation" of the routing table, but it does propagate policies which were designed with routing impact in mind. To the extent that the community feels that such considerations are unnecessary in policy in general or with respect to IPv4 at this point in time, that's a very important discussion to have. /John John Curran President and CEO ARIN From jbates at brightok.net Sun Feb 6 19:25:45 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 18:25:45 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> <4D4EBE9A.308@brightok.net> Message-ID: <4D4F3C08.2010705@brightok.net> On 2/6/2011 6:13 PM, John Curran wrote: > In the case of the specified transfer policy, the requirement to qualify to > receive such just as an allocation under current policies doesn't create > any "regulation" of the routing table, but it does propagate policies which > were designed with routing impact in mind. To the extent that the community > feels that such considerations are unnecessary in policy in general or with > respect to IPv4 at this point in time, that's a very important discussion > to have. > That's my point. In practice (because it's the operator community who defines actual routing policy) ARIN policy doesn't actually restrict table bloat. However, the allocation policies DO take routing bloat into consideration. This is generally in the form of restrictions on how small a network will be allocated. As a good portion of the operator community does advertise the largest aggregates they can, the size allocated determines the number of routes each must advertise. Jack From gbonser at seven.com Sun Feb 6 20:29:28 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 6 Feb 2011 17:29:28 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <4D4F3C08.2010705@brightok.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net><712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net><5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com><3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net><5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com><134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net><551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net><7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net><4D4EBE9A.308@brightok.net> <4D4F3C08.2010705@brightok.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC138AB@RWC-EX1.corp.seven.com> > As a good portion of the operator > community does advertise the largest aggregates they can, the size > allocated determines the number of routes each must advertise. > > > Jack Heh, have you looked at the CIDR report lately? http://www.cidr-report.org/as2.0/#Gains http://www.cidr-report.org/v6/as2.0/#Gains I have an upstream announcing >3500 /30 and /32 to me by BGP even though they are part of larger aggregates that I hear from no other source (aggregates smaller than /24). I called them on Friday about it thinking maybe I would give them a "heads up" thinking maybe their aggregation was broken. They told me that was intentional. So I am now filtering them. From bill at herrin.us Sun Feb 6 20:36:45 2011 From: bill at herrin.us (William Herrin) Date: Sun, 6 Feb 2011 20:36:45 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net> <7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net> <4D4EBE9A.308@brightok.net> Message-ID: On Sun, Feb 6, 2011 at 6:46 PM, Martin Hannigan wrote: > On Sun, Feb 6, 2011 at 10:30 AM, Jack Bates wrote: >> One of the stated goals of ARIN is to protect routing tables from bloat, >> which is reflected in the minimum requirements to receive an allocation. >> This doesn't, in practice, actually protect the tables, as there are many >> who deaggregate their allocations, but that is beyond the control of ARIN. > > I think that network operators are better suited to manage this as > part of a market activity than a "regulation" devised by ARIN. > Historically, "regulation" of routing has been considered operational > and ARIN policy in this area is generally ignored. Yet representatives of the largest ISPs stood opposed to every reduction of the minimum allocation since /19. Solely because of routing bloat, or at least that's what was said. Historically speaking. The network operators only want ARIN out of routing when it's convenient. They don't want to be the ones responsible for keeping the small fish out of the BGP table so that the process remains viable. Even today, network operators' only tools for managing BGP bloat are: the /24 barrier and RIR policy. And the /24 barrier is both harmful to address scarcity and of very limited utility in controlling bloat. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Sun Feb 6 21:50:40 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 20:50:40 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC138AB@RWC-EX1.corp.seven.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net><5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com><3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net><5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com><134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net><551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net><7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net><4D4EBE9A.308@brightok.net> <4D4F3C08.2010705@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC138AB@RWC-EX1.corp.seve! n.com> Message-ID: <4D4F5E00.5060002@brightok.net> On 2/6/2011 7:29 PM, George Bonser wrote: > > I have an upstream announcing>3500 /30 and /32 to me by BGP even though > they are part of larger aggregates that I hear from no other source > (aggregates smaller than /24). I called them on Friday about it > thinking maybe I would give them a "heads up" thinking maybe their > aggregation was broken. They told me that was intentional. So I am now > filtering them. > Some policies are strange. To be honest, though, /24 is the standard unless you're receiving directly from your transit, and while I know there are quite a few networks (unfortunately some of the largest) which deaggregate on a massive scale, I would say that most ASNs advertise at the highest aggregation possible. I'm personally sad that I'm having to start advertising 5 new /23 routes as 2 of my ISP customers are multihoming and aren't aggregated (IPv4 didn't allow for any growth when I assigned to them). Thanks for reminding me to check, though. I screwed a bgp config up. Currently (and never do this, I just haven't finished fixing it), I flag to not send routes out (instead of flagging to send them), and a screwup deaggregated a route. 67.207.230.0/23 4777 2516 3356 8025 - Withdrawn - matching aggregate 67.207.224.0/19 4777 2516 3356 8025 ^--- errr, neighbor x.x.x.x send-communities please. :) Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbonser at seven.com Sun Feb 6 22:47:51 2011 From: gbonser at seven.com (George Bonser) Date: Sun, 6 Feb 2011 19:47:51 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <4D4F5E00.5060002@brightok.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net><5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com><3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net><5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com><134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net><551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net><7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net><4D4EBE9A.308@brightok.net> <4D4F3C08.2010705@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC138AB@RWC-EX1.corp.seve! n.com> <4D4F5E00.5060002@brightok.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC138AC@RWC-EX1.corp.seven.com> Some policies are strange. To be honest, though, /24 is the standard unless you're receiving directly from your transit, and while I know there are quite a few networks (unfortunately some of the largest) which deaggregate on a massive scale, I would say that most ASNs advertise at the highest aggregation possible. It's funny, though, because in some cases I got a /24, the /25's, all of the /26's, /27's, /28's, /29's, and some /30's and then all of the /32's for all of the IPs in the /24! It was just nuts. Guvf jnf Fniivf, ol gur jnl. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbates at brightok.net Sun Feb 6 23:00:15 2011 From: jbates at brightok.net (Jack Bates) Date: Sun, 06 Feb 2011 22:00:15 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC138AC@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com><3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net><5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com><134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net><551D6BC6-3C77-43C0-A7B8-14BC81A4D0AE@arin.net><7BFB706D-894D-4551-B903-0776FEFD665E@queuefull.net><4D4EBE9A.308@brightok.net> <4D4F3C08.2010705@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC138AB@RWC-EX1.corp.seve! n.com> <4D4F5E00.5060002@brightok.net> <5A6D953473350C4B9995546AFE9939EE0BC138AC@RWC-EX1.corp.seven.! com> Message-ID: <4D4F6E4F.8070609@brightok.net> On 2/6/2011 9:47 PM, George Bonser wrote: > > It's funny, though, because in some cases I got a /24, the /25's, all > of the /26's, /27's, /28's, /29's, and some /30's and then all of the > /32's for all of the IPs in the /24! > > It was just nuts. > > That's what I said of a sister company's network when their engineer left and I took it over. /32's for every ppp session advertised via 3 IGPs! I did a little bit more work. I tried to make sure my scripts pulled the correct information, and it does look accurate, though I won't attest to complete accuracy. ;) Taking the data from the overall ASN report, 28,579 ASNs were at 0.00% or 78% of the ASNs recorded. Granted, they only advertised 55,788 combined routes which would be 27% of the report's Annce total. However, I would still stand on the premise that if the market starts transferring networks at the /24 level, routing table bloat would increase. Operators only have the choice to aggregate as much as their allocations allow. Networks grow over the years and IPv4 required multiple non-contiguous allocations. The 55,788 routes most likely will be a much smaller number for those 28,579 ASNs in IPv6. However, if RIRs had given out smaller allocations, the number would likely be much larger. Jack -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Mon Feb 7 01:47:00 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sun, 06 Feb 2011 22:47:00 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <839813.74109.qm@web63302.mail.re1.yahoo.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> Message-ID: <4D4F9564.1010500@ipinc.net> On 2/6/2011 8:36 AM, Lee Howard wrote: > > >> From: Benson Schliesser > >> >> Sadly, because we've waited too long to grow IPv6 penetration to >> the inflection point ("the moment that end users start accepting and >> using IPv6"), people will still need to deploy IPv4. Vendors will >> make money on NATs. And people will find ways to get addresses >> - one way or another. > > This is often asserted and generally accepted. Is it true? > Today - yes. Tomorrow - IMHO it is completely dependent on the CPE vendors. > Nobody wants NAT: ISPs, content providers, law enforcement, > copyright holders, game console manufacturers, web advertisers, > home gateway vendors, agreed. and end users all have an interest in > avoiding NAT. wrong. End users absolutely need inexpensive - and I'm talking $60 and under - stateful packet inspection hardware firewalls. So far the only devices that meet that criteria are NAT devices. Even the few SOHO CPE's like the D-link and Cisco RVS4000 that implement IPv6 do NOT include stateful packet inspection in their CPE's on the IPv6 part of it. > Even NAT vendors are decorously sheepish in > selling their products. If everyone wants to avoid it, why are we > stuck with it? > Because in the beginning none of those stakeholders that have an interest against NAT nowadays were in play, many did not exist. And the end users needed stateful packet inspection, address portability, and an unconstrained source of addresses. NAT solved those problems. What has IMHO changed is the coming into existence of stakeholders who want to "reach into the consumers network" Groups like law enforcement, copyright digital rights management people, advertisers, and so on would all love to gain "authorized" access to consumers machines for their own purposes. Today, EVEN IF a consumer WANTS a corporation like itunes to contact one of their network devices in their homes, there is no way they can click a box or whatever on their network device to allow this - other than having a program on that device initiate contact to the stakeholder. And that kind of architecture is not scalable because the stakeholder cannot schedule the incoming contacts. The irony of it is that once the CPE market matures and we have many products including IPv6, the consumers will be demanding them to have firewalling. As an admin of an ISP I would never deploy IPv6 to my "ma and pa kettle" customers until a CPE existed that included firewalling on the IPv6 side out of the box. The reason is that if I did then within hours Ma and Pa Kettle's peecee's would be cracked into and they would be on the phone with me, costing me precious support dollars, wanting to know why their peecee was running so slow. So I do not see that the stakeholders you mentioned - law enforcement, the DRM crowd, etc. - are going to be any better off under IPv6. They still won't have a defined way of getting at consumer network devices. > 1. ISPs aren't ready for IPv6. This belief is rapidly being > overtaken by events--most ISPs will have broad IPv6 this year. > 2. Content isn't ready for IPv6. This belief is rapidly being > overtaken by events. World IPv6 Day is a test-drive of content, > which should go a long way toward eliminating barriers. > 3. Home gateways aren't ready for IPv6. This belief is > slowly being overtaken by events. All home gateway makers > are developing IPv6, and industry is doing better as telling them > what needs to be fixed. However, it may still be true that all > home gateways sold before ARIN runout have to be replaced. Well, all of those were sold to customers who were connecting in with IPv4 so they only would need to be replaced if those customers's ISP's wanted to retract the IPv4 originally assigned to them. > 4. Consumer electronics aren't ready for IPv6. This is widely > true, although more embedded OSs are becoming IPv6-capable. > Most web-capable devices will be capable of simple firmware > or OS updates. Untraditional networked devices (like > entertainment systems) are in trouble. > I would tend to disagree with that last, because it is mandatory that anything that plays a Blue Ray disk be easily updatable by the consumer, because the blue Ray standard permits future modification of the encryption algorithms. Blu Ray players that become orphaned because their manufacturers go out of business or whatever, they will be unable to play newer disks eventually and will have to be scrapped. And there are very few entertainment systems that are IPv4 networkable that AREN'T blue-ray players. There's some game consoles but those will be obsoleted long before this is a problem because frequent obsolescence of game consoles is part of any game console manufacturer's business plan. And there are some HD TV sets that can do netflix that may have a problem. > How do we improve IPv6 uptake in these categories? > Well, if you could get NetFlix to mandate IPv6 in any hardware device that is sold to stream Netflix that would be a big help. If you could get them to do that now it would be great since that would force Roku and the TV set makers who added support for that into their products to release firmware updates now, before those products get too old that those companies can skank out of providing updates. > If all of a household's devices speak IPv6, and the ISP provides > IPv6, and all of the content the household accesses is available > over IPv6 (including NAT64), that household no longer needs > IPv4. > > What would it take for the number of households in that state > to increase faster than new Internet activations? Think big-- > there are a lot of stakeholders whose interests align against > NAT. > If there was some way to get the content providers who are now providing television over the Internet to require IPv6 for higher resolution streaming you would have it in the bag. Netflix has done some work in this area and they say now for 1080p at 60 fps the end user needs at least 3MB of bandwidth. Few users are at this level since Netflix also charges an additional fee for HD streaming. But it is inevitable that as TV broadcasting moves to the Internet that demand will grow for them to stream shows at the full 1080p. If what your saying about advertisers wanting to get rid of NAT is true, then the broadcasting industry should come out with an Internet broadcasting standard that would specify IPv6 and no-NAT and UPnP for 1080p streaming. I would propose that ARIN write a "best practices" RFC that says just that. Ted > Lee > > > From gbonser at seven.com Mon Feb 7 04:12:52 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 7 Feb 2011 01:12:52 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D4F9564.1010500@ipinc.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net><712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net><5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com><3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net><5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com><134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net><4D4C84DE.1060208@ipinc.net><839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC138AF@RWC-EX1.corp.seven.com> > > wrong. End users absolutely need inexpensive - and I'm talking $60 and > under - stateful packet inspection hardware firewalls. Doesn't even need to be a firewall. A router that does NAT for v4 can do the same for v6 except it doesn't do the NAT. In other words, you only allow an incoming packet if an outgoing packet has already been seen. So basically you "connect" a local address/port with a remote address/port when you see the outgoing packet. When you see an incoming packet, unless there is an explicit "allow" for it, you drop it unless the source address/port is "connected" to an inside address/port from an earlier outgoing packet. Basically it is tracking all the state that it tracks for NAT without actually doing the NAT. Note this isn't deep packet inspection, it isn't really a "firewall" in that respect, but it shouldn't be too hard to code an adaptive (or connection tracking) filter. Any router doing overload NAT is doing more than that for v4 now. From owen at delong.com Mon Feb 7 04:21:47 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 01:21:47 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D4F9564.1010500@ipinc.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> Message-ID: <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> On Feb 6, 2011, at 10:47 PM, Ted Mittelstaedt wrote: > On 2/6/2011 8:36 AM, Lee Howard wrote: >> >> >>> From: Benson Schliesser >> >>> >>> Sadly, because we've waited too long to grow IPv6 penetration to >>> the inflection point ("the moment that end users start accepting and >>> using IPv6"), people will still need to deploy IPv4. Vendors will >>> make money on NATs. And people will find ways to get addresses >>> - one way or another. >> >> This is often asserted and generally accepted. Is it true? >> > > Today - yes. Tomorrow - IMHO it is completely dependent on the > CPE vendors. > >> Nobody wants NAT: ISPs, content providers, law enforcement, >> copyright holders, game console manufacturers, web advertisers, >> home gateway vendors, > > agreed. > > and end users all have an interest in >> avoiding NAT. > > wrong. End users absolutely need inexpensive - and I'm talking $60 and > under - stateful packet inspection hardware firewalls. > Your statement is absolutely correct except for the first word. > So far the only devices that meet that criteria are NAT devices. > A temporary problem. > Even the few SOHO CPE's like the D-link and Cisco RVS4000 that > implement IPv6 do NOT include stateful packet inspection in their > CPE's on the IPv6 part of it. > As you point out, nothing currently available to the consumer does IPv6 SPI with or without NAT. The CPE router requirements bis document that is in the final stages at IAB and should be out shortly will require SPI, among other improvements. I think you will see more capable IPv6 CPE shortly. I vote we fix the CPE rather than break the internet, OK? >> Even NAT vendors are decorously sheepish in >> selling their products. If everyone wants to avoid it, why are we >> stuck with it? >> > > Because in the beginning none of those stakeholders that have > an interest against NAT nowadays were in play, many did not exist. > And the end users needed stateful packet inspection, address > portability, and an unconstrained source of addresses. NAT > solved those problems. > Sort of. > What has IMHO changed is the coming into existence of stakeholders > who want to "reach into the consumers network" Groups like > law enforcement, copyright digital rights management people, > advertisers, and so on would all love to gain "authorized" > access to consumers machines for their own purposes. > No, what has changed is that with IPv6, we now have enough addresses that we can abandon the kludgy hack that allowed us to recycle addresses rapidly (NAT). > Today, EVEN IF a consumer WANTS a corporation like itunes to > contact one of their network devices in their homes, there is > no way they can click a box or whatever on their network device > to allow this - other than having a program on that device > initiate contact to the stakeholder. And that kind of > architecture is not scalable because the stakeholder cannot > schedule the incoming contacts. > Actually, yeah, they sort of can. It's called "port forwarding" and most home gateways allow you to configure a static state table entry that way. > The irony of it is that once the CPE market matures and we > have many products including IPv6, the consumers will be demanding > them to have firewalling. > That's not a bad thing, but, it has nothing to do with NAT. Repeat after me... SPI is security. NAT is just mutilation of the address fields in the packet header. > As an admin of an ISP I would never deploy IPv6 to my "ma > and pa kettle" customers until a CPE existed that included > firewalling on the IPv6 side out of the box. The reason is > that if I did then within hours Ma and Pa Kettle's peecee's > would be cracked into and they would be on the phone with > me, costing me precious support dollars, wanting to know why > their peecee was running so slow. > Sure... Good call. I would agree. And those boxes are coming. > So I do not see that the stakeholders you mentioned - law > enforcement, the DRM crowd, etc. - are going to be any better > off under IPv6. They still won't have a defined way of > getting at consumer network devices. > Way way way better off. They don't have to get at the consumer network device, but, it sure is nice to be able to identify the exact device rather than just "something somewhere behind that gateway over there". It's also nice that consumers will now have the option of allowing connections directly into their network if they so choose. A good SPI firewall with real addresses on the inside provides all of that. >> 1. ISPs aren't ready for IPv6. This belief is rapidly being >> overtaken by events--most ISPs will have broad IPv6 this year. >> 2. Content isn't ready for IPv6. This belief is rapidly being >> overtaken by events. World IPv6 Day is a test-drive of content, >> which should go a long way toward eliminating barriers. >> 3. Home gateways aren't ready for IPv6. This belief is >> slowly being overtaken by events. All home gateway makers >> are developing IPv6, and industry is doing better as telling them >> what needs to be fixed. However, it may still be true that all >> home gateways sold before ARIN runout have to be replaced. > > Well, all of those were sold to customers who were connecting in > with IPv4 so they only would need to be replaced if those > customers's ISP's wanted to retract the IPv4 originally assigned > to them. > Which is very likely to happen as address scarcity forces residential ISPs to look to reclaiming addresses for low value services ($20-40/month residential, for example) and re-use those addresses for services that produce more revenue (web hosting, content, etc.) >> 4. Consumer electronics aren't ready for IPv6. This is widely >> true, although more embedded OSs are becoming IPv6-capable. >> Most web-capable devices will be capable of simple firmware >> or OS updates. Untraditional networked devices (like >> entertainment systems) are in trouble. >> > > I would tend to disagree with that last, because it is mandatory > that anything that plays a Blue Ray disk be easily updatable > by the consumer, because the blue Ray standard permits future > modification of the encryption algorithms. > Yep... They'll have to provide IPv6 upgrades for all those BD players. > Blu Ray players that become orphaned because their manufacturers go out of business or whatever, they will be unable to play newer disks eventually and will have to be scrapped. > Also true. One of the many reasons I am really annoyed that Toshiba threw in the towel on HD-DVD. > And there are very few entertainment systems that are IPv4 > networkable that AREN'T blue-ray players. There's some game consoles but those will be obsoleted long before this is a problem because frequent obsolescence of game consoles is part of any game console manufacturer's business plan. And there are some HD TV sets that can do netflix that may have a problem. > I have to disagree with you there. Of the 10 network-connected entertainment devices in my house, 2 are blu-ray players. By my calculations, that has the BD players outnumbered 4:1. >> How do we improve IPv6 uptake in these categories? >> > > Well, if you could get NetFlix to mandate IPv6 in any hardware > device that is sold to stream Netflix that would be a big help. > If you could get them to do that now it would be great since > that would force Roku and the TV set makers who added support > for that into their products to release firmware updates now, > before those products get too old that those companies can > skank out of providing updates. > I like it. I doubt NF would do it and I suspect some of them would simply skank out of NF support rather than do the right thing anyway. >> If all of a household's devices speak IPv6, and the ISP provides >> IPv6, and all of the content the household accesses is available >> over IPv6 (including NAT64), that household no longer needs >> IPv4. >> >> What would it take for the number of households in that state >> to increase faster than new Internet activations? Think big-- >> there are a lot of stakeholders whose interests align against >> NAT. >> > > If there was some way to get the content providers who are > now providing television over the Internet to require IPv6 > for higher resolution streaming you would have it in the bag. > Sure, but, if we could have gotten various players to cut off their noses to spite their faces years ago, we'd be done with the IPv6 transition already. > Netflix has done some work in this area and they say now for 1080p at 60 fps the end user needs at least 3MB of bandwidth. Few users are at this level since Netflix also charges an additional fee for HD streaming. > > But it is inevitable that as TV broadcasting moves to the Internet that demand will grow for them to stream shows at the full 1080p. If what your saying about advertisers wanting to get rid of NAT is true, then the broadcasting industry should come out with an Internet broadcasting standard that would specify IPv6 and no-NAT and UPnP for 1080p streaming. > I like it. Now we just need to get them to understand that instead of insisting that Ipv4 is just fine and they don't see any near-term need for IPv6. The level of denial in the entertainment industry when it comes to the reality of the customer environment and network transport is impressive. They seem to live in a completely different world where even some of the laws of physics seem not to apply. Owen From jcurran at arin.net Mon Feb 7 09:08:22 2011 From: jcurran at arin.net (John Curran) Date: Mon, 7 Feb 2011 14:08:22 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: Message-ID: Marty - We'll work to get some more detailed information on IPv6 requests and status made available. Thanks! /John John Curran President and CEO ARIN On Feb 6, 2011, at 6:48 PM, Martin Hannigan wrote: > Staff et. Al, > > Can we get a recap of activity around resource requests for IPv6 and a > characterization of refusals, if any? If there are none, it would be > interesting to hear a general conclusion as to why. I'm interested to > see if there are any holes here considering all of the work that has > been done to ease access to v6 for transition. > > Best, and go Steelers! > > -M< > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Mon Feb 7 12:57:55 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 07 Feb 2011 09:57:55 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> Message-ID: <4D5032A3.6060302@ipinc.net> On 2/7/2011 1:21 AM, Owen DeLong wrote: > > On Feb 6, 2011, at 10:47 PM, Ted Mittelstaedt wrote: > >> On 2/6/2011 8:36 AM, Lee Howard wrote: >>> >>> >>>> From: Benson Schliesser >>> >>>> >>>> Sadly, because we've waited too long to grow IPv6 penetration to >>>> the inflection point ("the moment that end users start accepting and >>>> using IPv6"), people will still need to deploy IPv4. Vendors will >>>> make money on NATs. And people will find ways to get addresses >>>> - one way or another. >>> >>> This is often asserted and generally accepted. Is it true? >>> >> >> Today - yes. Tomorrow - IMHO it is completely dependent on the >> CPE vendors. >> >>> Nobody wants NAT: ISPs, content providers, law enforcement, >>> copyright holders, game console manufacturers, web advertisers, >>> home gateway vendors, >> >> agreed. >> >> and end users all have an interest in >>> avoiding NAT. >> >> wrong. End users absolutely need inexpensive - and I'm talking $60 and >> under - stateful packet inspection hardware firewalls. >> > Your statement is absolutely correct except for the first word. > I did say "today - yes" >> So far the only devices that meet that criteria are NAT devices. >> > > A temporary problem. > But a very big one. The CPE market is characterized by manufacturers stripping every bit of functionality out of the devices that is not demanded by customers, and cheapening the devices down to the point it's incredible that they operate at all. IPv6 hasn't been on the demand list and it's amazing any CPE vendors even offer the limited variants of it that they do on the few devices that they do now. >> Even the few SOHO CPE's like the D-link and Cisco RVS4000 that >> implement IPv6 do NOT include stateful packet inspection in their >> CPE's on the IPv6 part of it. >> > As you point out, nothing currently available to the consumer does > IPv6 SPI with or without NAT. The CPE router requirements bis > document that is in the final stages at IAB and should be out shortly > will require SPI, among other improvements. > > I think you will see more capable IPv6 CPE shortly. I vote we > fix the CPE rather than break the internet, OK? > dd-wrt already has this capability in the mega load that runs on OLDER Linksys WRT54GS devices. But the newer WRT54GS devices have halved the amount of flash - as a cost-cutting move - and cannot run it. In short the CPE vendors have RETARDED development in a way. Obviously they have to step up to the plate. IMHO adding SPI to just about all of the currently available devices - based on BusyBox Linux as they are - means adding more code, which means adding flash ram - which to the CPE vendors means the device costs more. Comcast also fell down when they provided their IPv6 modified CPE code to flash on a Linksys 160NS - all that was, was the wrt load with a few of the already existing IPv6 apps added. I don't have a lot of hope for these vendors to Do The Right Thing so far. I agree with you that we need to fix the CPE but the selfish self-interest of these vendors is to do exactly the opposite. >>> Even NAT vendors are decorously sheepish in >>> selling their products. If everyone wants to avoid it, why are we >>> stuck with it? >>> >> >> Because in the beginning none of those stakeholders that have >> an interest against NAT nowadays were in play, many did not exist. >> And the end users needed stateful packet inspection, address >> portability, and an unconstrained source of addresses. NAT >> solved those problems. >> > Sort of. > >> What has IMHO changed is the coming into existence of stakeholders >> who want to "reach into the consumers network" Groups like >> law enforcement, copyright digital rights management people, >> advertisers, and so on would all love to gain "authorized" >> access to consumers machines for their own purposes. >> > No, what has changed is that with IPv6, we now have enough addresses > that we can abandon the kludgy hack that allowed us to recycle > addresses rapidly (NAT). > >> Today, EVEN IF a consumer WANTS a corporation like itunes to >> contact one of their network devices in their homes, there is >> no way they can click a box or whatever on their network device >> to allow this - other than having a program on that device >> initiate contact to the stakeholder. And that kind of >> architecture is not scalable because the stakeholder cannot >> schedule the incoming contacts. >> > Actually, yeah, they sort of can. It's called "port forwarding" and > most home gateways allow you to configure a static state table > entry that way. > The problem with this is: 1) Among all the CPE's there is no accepted way to do this so client programs have no way to talk to the CPE to tell it to open a port forward. UPnP is helping in this regard but it's completely unauthenticated and being implemented as a massive security hole. 2) The mothership cannot schedule the clients when they call in so the client callins are not evenly distributed over the day. >> The irony of it is that once the CPE market matures and we >> have many products including IPv6, the consumers will be demanding >> them to have firewalling. >> > That's not a bad thing, but, it has nothing to do with NAT. > > Repeat after me... SPI is security. NAT is just mutilation of the > address fields in the packet header. > Repeat after me... current CPE's treat them as the same thing, forcing the consumers to do likewise. Any CPE discussion is academic until the CPE vendors start separating the two functions. >> As an admin of an ISP I would never deploy IPv6 to my "ma >> and pa kettle" customers until a CPE existed that included >> firewalling on the IPv6 side out of the box. The reason is >> that if I did then within hours Ma and Pa Kettle's peecee's >> would be cracked into and they would be on the phone with >> me, costing me precious support dollars, wanting to know why >> their peecee was running so slow. >> > Sure... Good call. I would agree. And those boxes are coming. > >> So I do not see that the stakeholders you mentioned - law >> enforcement, the DRM crowd, etc. - are going to be any better >> off under IPv6. They still won't have a defined way of >> getting at consumer network devices. >> > Way way way better off. They don't have to get at the consumer > network device, but, it sure is nice to be able to identify the > exact device rather than just "something somewhere behind > that gateway over there". > Without being able to interrogate the device to get ownership info from it, they are still relying on whois data to be accurate. It is better for most of those stakeholders but it isn't really what most of them want. > It's also nice that consumers will now have the option of > allowing connections directly into their network if they so choose. > > A good SPI firewall with real addresses on the inside provides > all of that. > >>> 1. ISPs aren't ready for IPv6. This belief is rapidly being >>> overtaken by events--most ISPs will have broad IPv6 this year. >>> 2. Content isn't ready for IPv6. This belief is rapidly being >>> overtaken by events. World IPv6 Day is a test-drive of content, >>> which should go a long way toward eliminating barriers. >>> 3. Home gateways aren't ready for IPv6. This belief is >>> slowly being overtaken by events. All home gateway makers >>> are developing IPv6, and industry is doing better as telling them >>> what needs to be fixed. However, it may still be true that all >>> home gateways sold before ARIN runout have to be replaced. >> >> Well, all of those were sold to customers who were connecting in >> with IPv4 so they only would need to be replaced if those >> customers's ISP's wanted to retract the IPv4 originally assigned >> to them. >> > Which is very likely to happen as address scarcity forces residential > ISPs to look to reclaiming addresses for low value services ($20-40/month > residential, for example) and re-use those addresses for services > that produce more revenue (web hosting, content, etc.) > I don't think so. The number of low-value customers far exceeds the number of high value customers. ISP's would not need to inconvenience more than a handful of low value ones to gain sufficient IPv4 for high value ones. >>> 4. Consumer electronics aren't ready for IPv6. This is widely >>> true, although more embedded OSs are becoming IPv6-capable. >>> Most web-capable devices will be capable of simple firmware >>> or OS updates. Untraditional networked devices (like >>> entertainment systems) are in trouble. >>> >> >> I would tend to disagree with that last, because it is mandatory >> that anything that plays a Blue Ray disk be easily updatable >> by the consumer, because the blue Ray standard permits future >> modification of the encryption algorithms. >> > Yep... They'll have to provide IPv6 upgrades for all those BD > players. > >> Blu Ray players that become orphaned because their manufacturers go out of business or whatever, they will be unable to play newer disks eventually and will have to be scrapped. >> > Also true. > > One of the many reasons I am really annoyed that Toshiba threw > in the towel on HD-DVD. > >> And there are very few entertainment systems that are IPv4 >> networkable that AREN'T blue-ray players. There's some game consoles but those will be obsoleted long before this is a problem because frequent obsolescence of game consoles is part of any game console manufacturer's business plan. And there are some HD TV sets that can do netflix that may have a problem. >> > I have to disagree with you there. Of the 10 network-connected > entertainment devices in my house, 2 are blu-ray players. > > By my calculations, that has the BD players outnumbered 4:1. > how many aren't firmware updatable? And how many aren't scheduled for early obsolescense (ie: game consoles) >>> How do we improve IPv6 uptake in these categories? >>> >> >> Well, if you could get NetFlix to mandate IPv6 in any hardware >> device that is sold to stream Netflix that would be a big help. >> If you could get them to do that now it would be great since >> that would force Roku and the TV set makers who added support >> for that into their products to release firmware updates now, >> before those products get too old that those companies can >> skank out of providing updates. >> > I like it. I doubt NF would do it and I suspect some of them would > simply skank out of NF support rather than do the right thing > anyway. > >>> If all of a household's devices speak IPv6, and the ISP provides >>> IPv6, and all of the content the household accesses is available >>> over IPv6 (including NAT64), that household no longer needs >>> IPv4. >>> >>> What would it take for the number of households in that state >>> to increase faster than new Internet activations? Think big-- >>> there are a lot of stakeholders whose interests align against >>> NAT. >>> >> >> If there was some way to get the content providers who are >> now providing television over the Internet to require IPv6 >> for higher resolution streaming you would have it in the bag. >> > Sure, but, if we could have gotten various players to cut off their > noses to spite their faces years ago, we'd be done with the IPv6 > transition already. > >> Netflix has done some work in this area and they say now for 1080p at 60 fps the end user needs at least 3MB of bandwidth. Few users are at this level since Netflix also charges an additional fee for HD streaming. >> >> But it is inevitable that as TV broadcasting moves to the Internet that demand will grow for them to stream shows at the full 1080p. If what your saying about advertisers wanting to get rid of NAT is true, then the broadcasting industry should come out with an Internet broadcasting standard that would specify IPv6 and no-NAT and UPnP for 1080p streaming. >> > I like it. Now we just need to get them to understand that instead of insisting that Ipv4 > is just fine and they don't see any near-term need for IPv6. The level of denial > in the entertainment industry when it comes to the reality of the customer > environment and network transport is impressive. They seem to live in a > completely different world where even some of the laws of physics seem > not to apply. > > Owen > > From owen at delong.com Mon Feb 7 15:39:06 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 12:39:06 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D5032A3.6060302@ipinc.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D5032A3.! 6060302@ipinc.net> Message-ID: On Feb 7, 2011, at 9:57 AM, Ted Mittelstaedt wrote: > On 2/7/2011 1:21 AM, Owen DeLong wrote: >> >> On Feb 6, 2011, at 10:47 PM, Ted Mittelstaedt wrote: >> >>> On 2/6/2011 8:36 AM, Lee Howard wrote: >>>> >>>> >>>>> From: Benson Schliesser >>>> >>>>> >>>>> Sadly, because we've waited too long to grow IPv6 penetration to >>>>> the inflection point ("the moment that end users start accepting and >>>>> using IPv6"), people will still need to deploy IPv4. Vendors will >>>>> make money on NATs. And people will find ways to get addresses >>>>> - one way or another. >>>> >>>> This is often asserted and generally accepted. Is it true? >>>> >>> >>> Today - yes. Tomorrow - IMHO it is completely dependent on the >>> CPE vendors. >>> >>>> Nobody wants NAT: ISPs, content providers, law enforcement, >>>> copyright holders, game console manufacturers, web advertisers, >>>> home gateway vendors, >>> >>> agreed. >>> >>> and end users all have an interest in >>>> avoiding NAT. >>> >>> wrong. End users absolutely need inexpensive - and I'm talking $60 and >>> under - stateful packet inspection hardware firewalls. >>> >> Your statement is absolutely correct except for the first word. >> > > I did say "today - yes" > >>> So far the only devices that meet that criteria are NAT devices. >>> >> >> A temporary problem. >> > > But a very big one. The CPE market is characterized by manufacturers > stripping every bit of functionality out of the devices that is not > demanded by customers, and cheapening the devices down to the point > it's incredible that they operate at all. IPv6 hasn't been on the > demand list and it's amazing any CPE vendors even offer the limited > variants of it that they do on the few devices that they do now. > Big problem: Yes. Does NAT solve it today? No. Will NAT solve it in the future? No. NAT isn't the solution. SPI is the solution. NAT is unnecessary in IPv6. You, yourself admitted that the SOHO CPE that doesn't do SPI for IPv6 also doesn't NAT it. If there's no security solution in the SOHO CPE today, then, the question isn't NAT or not NAT, the question is what is the right SOHO security solution to be encouraging the vendors to put in these products. SPI is a security solution. NAT is not. As such, I think we should dispense with the NAT discussion and get them to implement SPI. >>> Even the few SOHO CPE's like the D-link and Cisco RVS4000 that >>> implement IPv6 do NOT include stateful packet inspection in their >>> CPE's on the IPv6 part of it. >>> >> As you point out, nothing currently available to the consumer does >> IPv6 SPI with or without NAT. The CPE router requirements bis >> document that is in the final stages at IAB and should be out shortly >> will require SPI, among other improvements. >> >> I think you will see more capable IPv6 CPE shortly. I vote we >> fix the CPE rather than break the internet, OK? >> > > dd-wrt already has this capability in the mega load that runs on > OLDER Linksys WRT54GS devices. But the newer WRT54GS devices > have halved the amount of flash - as a cost-cutting move - and > cannot run it. > Yep. > In short the CPE vendors have RETARDED development in a way. > Sure. > Obviously they have to step up to the plate. IMHO adding SPI > to just about all of the currently available devices - based on > BusyBox Linux as they are - means adding more code, which means > adding flash ram - which to the CPE vendors means the device > costs more. > And I think that they will. > Comcast also fell down when they provided their IPv6 modified > CPE code to flash on a Linksys 160NS - all that was, was the > wrt load with a few of the already existing IPv6 apps added. > Your point being? I think they did what they could with the tools available at the time. I know Comcast is pushing the CPE vendors for a number of features they want but don't have currently. > I don't have a lot of hope for these vendors to Do The Right > Thing so far. I agree with you that we need to fix the CPE > but the selfish self-interest of these vendors is to do > exactly the opposite. > I think the vendors will do the right thing when they see agreement in the community on what the right thing is. That's why I'm hoping we can get the cpe-router-bis document through IAB soon. I think it is a major step forward in the correct direction. >>>> Even NAT vendors are decorously sheepish in >>>> selling their products. If everyone wants to avoid it, why are we >>>> stuck with it? >>>> >>> >>> Because in the beginning none of those stakeholders that have >>> an interest against NAT nowadays were in play, many did not exist. >>> And the end users needed stateful packet inspection, address >>> portability, and an unconstrained source of addresses. NAT >>> solved those problems. >>> >> Sort of. >> >>> What has IMHO changed is the coming into existence of stakeholders >>> who want to "reach into the consumers network" Groups like >>> law enforcement, copyright digital rights management people, >>> advertisers, and so on would all love to gain "authorized" >>> access to consumers machines for their own purposes. >>> >> No, what has changed is that with IPv6, we now have enough addresses >> that we can abandon the kludgy hack that allowed us to recycle >> addresses rapidly (NAT). >> >>> Today, EVEN IF a consumer WANTS a corporation like itunes to >>> contact one of their network devices in their homes, there is >>> no way they can click a box or whatever on their network device >>> to allow this - other than having a program on that device >>> initiate contact to the stakeholder. And that kind of >>> architecture is not scalable because the stakeholder cannot >>> schedule the incoming contacts. >>> >> Actually, yeah, they sort of can. It's called "port forwarding" and >> most home gateways allow you to configure a static state table >> entry that way. >> > > The problem with this is: > > 1) Among all the CPE's there is no accepted way to do this > so client programs have no way to talk to the CPE to tell it > to open a port forward. UPnP is helping in this regard > but it's completely unauthenticated and being implemented > as a massive security hole. > You're talking about two different things. I'm talking about a static permanent port forward which the user can configure to permit inbound flows by using the configuration tools on the router. You're talking about a dynamic temporary state table entry under the control of the application (which leads me to question the value of even having a firewall in such an environment). > 2) The mothership cannot schedule the clients when they call > in so the client callins are not evenly distributed over > the day. > I'm not sure I understand what you mean by this or how it relates to the discussion at hand. FWIW, TiVO, at least does represent a case of the mothership scheduling when the clients call in for the most part. >>> The irony of it is that once the CPE market matures and we >>> have many products including IPv6, the consumers will be demanding >>> them to have firewalling. >>> >> That's not a bad thing, but, it has nothing to do with NAT. >> >> Repeat after me... SPI is security. NAT is just mutilation of the >> address fields in the packet header. >> > > Repeat after me... current CPE's treat them as the same thing, > forcing the consumers to do likewise. Any CPE discussion is > academic until the CPE vendors start separating the two functions. > Repeat after me... We need to tell the CPE vendors what we want. Talking about what is and how to bring what is forward into IPv6 only creates confusion and exacerbates the situation. Especially when you use terms like inevitable. >>> As an admin of an ISP I would never deploy IPv6 to my "ma >>> and pa kettle" customers until a CPE existed that included >>> firewalling on the IPv6 side out of the box. The reason is >>> that if I did then within hours Ma and Pa Kettle's peecee's >>> would be cracked into and they would be on the phone with >>> me, costing me precious support dollars, wanting to know why >>> their peecee was running so slow. >>> >> Sure... Good call. I would agree. And those boxes are coming. >> >>> So I do not see that the stakeholders you mentioned - law >>> enforcement, the DRM crowd, etc. - are going to be any better >>> off under IPv6. They still won't have a defined way of >>> getting at consumer network devices. >>> >> Way way way better off. They don't have to get at the consumer >> network device, but, it sure is nice to be able to identify the >> exact device rather than just "something somewhere behind >> that gateway over there". >> > > Without being able to interrogate the device to get ownership > info from it, they are still relying on whois data to be > accurate. It is better for most of those stakeholders but it > isn't really what most of them want. > Better is at least a step in the right direction. NAT is worse. I'm not sure why you're arguing here. You've agreed that they all would feel that SPI without NAT is an improvement, yet you say that because it isn't everything they want, they want NAT? Sorry, that isn't making any sense to me. >> It's also nice that consumers will now have the option of >> allowing connections directly into their network if they so choose. >> >> A good SPI firewall with real addresses on the inside provides >> all of that. >> >>>> 1. ISPs aren't ready for IPv6. This belief is rapidly being >>>> overtaken by events--most ISPs will have broad IPv6 this year. >>>> 2. Content isn't ready for IPv6. This belief is rapidly being >>>> overtaken by events. World IPv6 Day is a test-drive of content, >>>> which should go a long way toward eliminating barriers. >>>> 3. Home gateways aren't ready for IPv6. This belief is >>>> slowly being overtaken by events. All home gateway makers >>>> are developing IPv6, and industry is doing better as telling them >>>> what needs to be fixed. However, it may still be true that all >>>> home gateways sold before ARIN runout have to be replaced. >>> >>> Well, all of those were sold to customers who were connecting in >>> with IPv4 so they only would need to be replaced if those >>> customers's ISP's wanted to retract the IPv4 originally assigned >>> to them. >>> >> Which is very likely to happen as address scarcity forces residential >> ISPs to look to reclaiming addresses for low value services ($20-40/month >> residential, for example) and re-use those addresses for services >> that produce more revenue (web hosting, content, etc.) >> > > I don't think so. The number of low-value customers far exceeds > the number of high value customers. ISP's would not need to > inconvenience more than a handful of low value ones to gain > sufficient IPv4 for high value ones. > ISPs depend heavily on the cookie cutter model for consumer services. Once they inconvenience a few customers, it won't be long before they do the same thing universally to all of them just to avoid having to track exceptions. >>>> 4. Consumer electronics aren't ready for IPv6. This is widely >>>> true, although more embedded OSs are becoming IPv6-capable. >>>> Most web-capable devices will be capable of simple firmware >>>> or OS updates. Untraditional networked devices (like >>>> entertainment systems) are in trouble. >>>> >>> >>> I would tend to disagree with that last, because it is mandatory >>> that anything that plays a Blue Ray disk be easily updatable >>> by the consumer, because the blue Ray standard permits future >>> modification of the encryption algorithms. >>> >> Yep... They'll have to provide IPv6 upgrades for all those BD >> players. >> >>> Blu Ray players that become orphaned because their manufacturers go out of business or whatever, they will be unable to play newer disks eventually and will have to be scrapped. >>> >> Also true. >> >> One of the many reasons I am really annoyed that Toshiba threw >> in the towel on HD-DVD. >> >>> And there are very few entertainment systems that are IPv4 >>> networkable that AREN'T blue-ray players. There's some game consoles but those will be obsoleted long before this is a problem because frequent obsolescence of game consoles is part of any game console manufacturer's business plan. And there are some HD TV sets that can do netflix that may have a problem. >>> >> I have to disagree with you there. Of the 10 network-connected >> entertainment devices in my house, 2 are blu-ray players. >> >> By my calculations, that has the BD players outnumbered 4:1. >> > > how many aren't firmware updatable? And how many aren't > scheduled for early obsolescense (ie: game consoles) > Everything I have with an ethernet connection is firmware updatable. I have one BD player (not in the 10 above) which is firmware updatable, but, which doesn't have a network connection. (Requires USB stick to upgrade). In terms of obsolescence, you might be able to make the argument on the PS/2, Wii, and PS/3. The Toshiba HD-A30 probably is already considered obsolete. The others (TiVOs, Yamaha RX-V3900, One BD player) do not meet that definition. Finally, the remaining device (Apple Mac Mini) already supports IPv6 and is running native dual stack now. Yes, I count this Mac Mini as a home entertainment system because it was purchased specifically as a media player and is connected via HDMI to the amplifier. The only display attached to it is a Sharp LCD flat-screen Television (32" 1080p). While I have a keyboard and mouse for it that I can break out at need, it is 95% controlled with the Apple remote. 4% of the time, I use RowMote on the iPad to control it. The keyboard and mouse are used for the remaining 1% of the time, usually for configuration changes or other more serious hacking on the device. For general purpose computing, there are 2 other iMacs and 2 Macbook Pros in the house as well as a Linux based server. Note, all of the general purpose computing platforms are running native dual stack now. Owen From mueller at syr.edu Mon Feb 7 16:07:36 2011 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 7 Feb 2011 16:07:36 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > ARIN has always enforced a philosophical position: > > IP addresses go to those with justified technical need. > IP addresses are not property. > > Address leasing without ARIN in the loop holds the prospect of > demolishing those principles So what? You correctly identify those principles as "philosophical". When facts change, philosophies change, or at least, they'd better. We have words - religious dogma - that apply when they don't. Neither old principle corresponds well with free pool depletion and the existence of competition among multiple claimants for the same resources. With "leasing," we see an even simpler process for achieving the same result as address transfers. Existing holders take on all the transactions costs of effecting the transfer that ARIN would otherwise have to assume. Also seems to have good aggregation properties, which a straight transfer does not. What's not to like? From mueller at syr.edu Mon Feb 7 16:14:09 2011 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 7 Feb 2011 16:14:09 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF217CE@SUEX07-MBX-04.ad.syr.edu> Nice image, but since the ipv6 transition depends completely on dual stack, we don't have a choice about that. IPv4 _must_ be around to see v6 reach maturity. > -----Original Message----- > > IPv4 is not dead. It's an aging parent with a young child - hopefully it will be > around long enough to see IPv6 reach maturity. :) > > Cheers, > -Benson > From heather.skanks at gmail.com Mon Feb 7 16:51:20 2011 From: heather.skanks at gmail.com (Heather Schiller) Date: Mon, 7 Feb 2011 16:51:20 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 In-Reply-To: References: <4D4B21C8.9090506@arin.net> Message-ID: On Thu, Feb 3, 2011 at 5:18 PM, William Herrin wrote: > On Thu, Feb 3, 2011 at 4:44 PM, ARIN wrote: >> The AC abandoned ARIN-prop-128 [...] >> because there is insufficient time to implement the proposal through the >> normal PDP. > > If Geoff's projections are correct there will be two more meetings > before ARIN is down to its last /8. Just sayin'. > Bill, It is helpful to take into context the whole paragraph explaining the abandonment of Prop 128 and not just pull at one part of it. Prop 128 would have gone into effect when IANA depleted (not ARIN, as you seem to reference above). The AC meeting was on Jan 28. IANA depleted 6 days later on February 3. We knew IANA would deplete prior to the next AC meeting. As shepherd for this proposal, I suggested abandonment after discussing it with one of the authors and several other AC's members. The suggestion was based on opposition to the proposal on the mailing list AND the fact that it would take emergency action by the board prior to IANA depletion. In order for the board to take "emergency action" on something, there must be significant risk to the ARIN organization. The change from 12 month allocation to 3 month allocation upon IANA depletion has long been published, and projections for IANA depletion were well known. Regarding: "It sets me off when a member of the AC (or the AC as a whole) announces that there isn't time for something. Not enough time to get this through the process. Too many proposals, not enough time to work on this one. " I don't believe we have ever (atleast in my experience) abandoned a proposal because of a time constraint like this. I would say that this was a fairly unique case, we've never had such a deadline before. It is quite different from when the AC says, "we accept this onto the docket to work on it, but it missed the deadline for the next in person meeting" We did not say there were too many proposals, just that there was not enough time to go through the PDP - which includes presentation at an in person meeting. which meant the only option would have been emergency board action - and we determined this prop would not meet the criteria for emergency action. > >> The AC abandoned ARIN-prop-129 and ARIN-prop-130 because they violate >> the community principle of needs-based assignments. > > Just once I'd like to see this read, "The AC abandoned ... because the > proposal appeared to have been made in jest." > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Mon Feb 7 16:50:07 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 13:50:07 -0800 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: <53FD4C50-C5AA-43ED-B794-CE5EBF2387C5@delong.com> On Feb 7, 2011, at 1:07 PM, Milton L Mueller wrote: > > >> -----Original Message----- > >> ARIN has always enforced a philosophical position: >> >> IP addresses go to those with justified technical need. >> IP addresses are not property. >> >> Address leasing without ARIN in the loop holds the prospect of >> demolishing those principles > > So what? You correctly identify those principles as "philosophical". When facts change, philosophies change, or at least, they'd better. We have words - religious dogma - that apply when they don't. > > Neither old principle corresponds well with free pool depletion and the existence of competition among multiple claimants for the same resources. > > With "leasing," we see an even simpler process for achieving the same result as address transfers. Existing holders take on all the transactions costs of effecting the transfer that ARIN would otherwise have to assume. Also seems to have good aggregation properties, which a straight transfer does not. What's not to like? > How do you figure address leasing absent connectivity in any way helps aggregation? The transfer of address space without regard to the policies set by the community and without notification and transparency to the community is harmful. That's even more true in the face of free pool exhaustion and resource contention than before. Owen From hannigan at gmail.com Mon Feb 7 17:39:08 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 7 Feb 2011 17:39:08 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Mon, Feb 7, 2011 at 4:07 PM, Milton L Mueller wrote: > > >> -----Original Message----- > >> ARIN has always enforced a philosophical position: >> >> IP addresses go to those with justified technical need. >> IP addresses are not property. >> >> Address leasing without ARIN in the loop holds the prospect of >> demolishing those principles > > So what? You correctly identify those principles as "philosophical". When facts change, philosophies change, or at least, they'd better. We have words - religious dogma - ?that apply when they don't. > > Neither old principle corresponds well with free pool depletion and the existence of competition among multiple claimants for the same resources. > > With "leasing," we see an even simpler process for achieving the same result as address transfers. Existing holders take on all the transactions costs of effecting the transfer that ARIN would otherwise have to assume. Also seems to have good aggregation properties, which a straight transfer does not. What's ?not to like? I agree with everything you've said with the exception of aggregation. It's not relevant to policy even though a minority consistently link it. Overall, leasing is significantly advantageous over "purchasing" since we can't really own IP addresses according to the current regime. I'm pretty certain that the STLS will see light if any volume and won't see any significant sized block pass through it as a result of the current onerous policy considerations (L\RSA) in using it. Best, -M< From bill at herrin.us Mon Feb 7 17:59:36 2011 From: bill at herrin.us (William Herrin) Date: Mon, 7 Feb 2011 17:59:36 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Mon, Feb 7, 2011 at 4:07 PM, Milton L Mueller wrote: >> ARIN has always enforced a philosophical position: >> >> IP addresses go to those with justified technical need. >> IP addresses are not property. >> >> Address leasing without ARIN in the loop holds the prospect of >> demolishing those principles > > So what? You correctly identify those principles as > "philosophical". When facts change, philosophies > change, or at least, they'd better. We have words > - religious dogma - ?that apply when they don't. So what? So unless you want to revisit all of the problems with markets encountered since the feudal era, you don't blunder into a market carelessly. If we're to have a market, we want an open, free market. Historically, that's not a market's natural state. > With "leasing," we see an even simpler process for > achieving the same result as address transfers. > Existing holders take on all the transactions > costs of effecting the transfer that ARIN would > otherwise have to assume. Also seems to have > good aggregation properties, which a straight > transfer does not. What's?not to like? Leaseholds are a healthy part of a market that includes Freeholds. And they're a soul crushing part of closed market that does not. For anyone not familiar with the terms, a freehold is where you buy the house and the land, while a leasehold is where you buy the house and the right to use the land for 99 years or some such. Freeholds are The Way It Is for residential real estate in most of the US and Canada, but they're very hard to come by in parts of Europe and Asia. Historically, much of the 19th century immigration to the new world was driven by the promise of escaping the European landlords. With ownership spread thin enough, you get a free market in which Freeholds and Leaseholds compete for best value. But even in the US it takes tax incentives (mortgage interest write off) and other government interference to prevent that ownership from coalescing with a few barons, after which the market is closed. IP address "ownership" is not starting with a thin spread. It's very concentrated with fewer than a hundred ISPs holding most of it while the rest is scattered here and there. The leasehold-only market which could develop naturally from that is not a healthy market at all. You don't have to look far to understand what that would look like -- land ownership in Hawaii still suffers the legacy of Dole and his contemporaries where vast tracks of underutilized land simply aren't available at any price. But then you know all this and could surely explain it better than I can if you care to. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jbates at brightok.net Mon Feb 7 19:51:11 2011 From: jbates at brightok.net (Jack Bates) Date: Mon, 07 Feb 2011 18:51:11 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D5032A3.! 6060302@ipinc.net> Message-ID: <4D50937F.7040703@brightok.net> On 2/7/2011 2:39 PM, Owen DeLong wrote: > NAT isn't the solution. SPI is the solution. NAT is unnecessary in IPv6. > Just because I love arguing with you, Owen. NPTv6 on 6to4 anycast implementation is currently under way. It has 2 possible uses (1 I like, 2 I'm iffy on) 1) CGN networks needing 6to4 anycast support can use NPTv6 to NAT the 2002:bogusCGNIP:: address to ISP prefixes. 2) By using NAT to convert 2002:: addresses to ISP prefixes, you void out the need of a return anycast relay in any 6to4 implementation (at the cost of having used NAT66). 6to4 is still a temporary transition mechanism. #1 is required to use 6to4 in CGN environments. #2 is a safeguard mechanism so you don't depend on the return anycast relay, but the cost is NAT66 (it's a poor mans 6rd to be honest and a hack). I honestly expect to see it deployed with #1, as CGN is expected to be prevalent which voids out the #2 cases. Jack From jcurran at arin.net Mon Feb 7 20:09:33 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 01:09:33 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Feb 7, 2011, at 6:39 PM, Martin Hannigan wrote: > I'm pretty certain that the STLS will see light if any volume > and won't see any significant sized block pass through it as a result > of the current onerous policy considerations (L\RSA) in using it. Interesting perspective... I can't tell if you are referring to the Specified Transfer policy in NRPM 8.3: if so, your conclusion is rather surprising. For a party (e.g. legacy holder) who plans to monetize their space in any case, there are two downsides to doing it via the Specified Transfer policy: 1) You have to enter into an LRSA, but from a practical matter it is only going to be meaningful for the fairly short duration from when you enter into it and until you transferred all your address holdings -and- 2) You can only transfer what the recipient qualifies for, which is limited to 12 months of their documented address need per the NRPM in the ARIN region. Because your address holdings actually get vetted when you entered the LRSA, the benefits to the recipient is that they know you actually have the ability to transfer per policy (and aren't just someone who hijacked the space by registering an expired domain name on a contact & emailing) This certainty is key for most organizations that intend to build a long-term business based on use of the number resource. Note also a (growing) recipient probably has many existing address blocks that are already under RSA, and the one received by transfer is no different. I'm looking for the onerous policy considerations regarding the need for L/RSA agreements, and for the vast majority of expected users of the policy, it's not clear that is any agreement-related downside. I agree that the policy isn't likely to be favored by speculators or address squatters, and that those segments may have been historically underrepresented in the policy development process. Correcting that is left as an exercise for the community, if so desired. FYI, /John John Curran President and CEO ARIN From hannigan at gmail.com Mon Feb 7 21:23:29 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 7 Feb 2011 21:23:29 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Mon, Feb 7, 2011 at 8:09 PM, John Curran wrote: > On Feb 7, 2011, at 6:39 PM, Martin Hannigan wrote: > >> I'm pretty certain that the STLS will see light if any volume >> and won't see any significant sized block pass through it as a result >> of the current onerous policy considerations (L\RSA) in using it. > > Interesting perspective... ?I can't tell if you are referring to the > Specified Transfer policy in NRPM 8.3: if so, your conclusion is rather > surprising. Both. 8.3 requires the use of the STLS. They are effectively one. > For a party (e.g. legacy holder) who plans to monetize their space in > any case, there are two downsides to doing it via the Specified Transfer > policy: "STLS" https://www.arin.net/resources/transfer_listing/ > > 1) You have to enter into an LRSA, but from a practical matter it is > ? only going to be meaningful for the fairly short duration from when > ? you enter into it and until you transferred all your address holdings > -and- "LRSA" https://www.arin.net/resources/legacy/index.html > 2) You can only transfer what the recipient qualifies for, which is > ? limited to 12 months of their documented address need per the NRPM > ? in the ARIN region. > [ .. ] > Because your address holdings actually get vetted when you entered the > LRSA, the benefits to the recipient is that they know you actually have > the ability to transfer per policy (and aren't just someone who hijacked > the space by registering an expired domain name on a contact & emailing) Members do not want those(Illegitimate) people to benefit. But there are likely other more efficient ways to deal with this problem and allow legitimate holders to conduct private transactions with limited difficulty and _limited expense_. > This certainty is key for most organizations that intend to build a > long-term business based on use of the number resource. ?Note also a > (growing) recipient probably has many existing address blocks that are > already under RSA, and the one received by transfer is no different. > I'm looking for the onerous policy considerations regarding the need > for L/RSA agreements, and for the vast majority of expected users of > the policy, it's not clear that is any agreement-related downside. Signing the LRSA is significantly risky IMHO. I found many requirements that if I were holding legacy resources I would find non conducive to a mutually beneficial relationship with the ARIN community especially since there's no incentive to do so now: - no mutual termination - termination only for cause - no membership benefits - fees - less rights that members e.g. audits, etc. - Subject to current and future policies without recourse Without carrot, we'll see limited use of the 8.3 required transfer mechanisms. I would suggest the carrots would be: -no fees -mutual termination -membership > I agree that the policy isn't likely to be favored by speculators or > address squatters, and that those segments may have been historically > underrepresented in the policy development process. This seems off. The rules for transfer were written outside of the policy process. Based on the leasing thread it would seem that the membership does want "softer" rules with respect to transfers and the market in general. That in turn will invite those people to participate and become legitimate actors to the benefit of the community. >Correcting that is left as an exercise for the community, if so desired. Since the onerous part is not policy, how do we go about getting this changed? Best Regards, [and congratulations Green Bay fans! Steelers gave it to you. :) ] -M< From jcurran at arin.net Mon Feb 7 21:53:52 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 02:53:52 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> On Feb 7, 2011, at 10:23 PM, Martin Hannigan wrote: > Both. 8.3 requires the use of the STLS. They are effectively one. NRPM 8.3 is a policy, and ARIN will process specified transfer requests from two parties which appear and meet the criteria. Neither of them has to be a participant in the Specified Transfer Listing Service (STLS); the STLS is simply a convenience for those parties who want some help finding a match. Think of it this way: STLS is a dating service, which you don't need to use if you already have a partner and just want to go (via NRPM 8.3) and get married. > Members do not want those(Illegitimate) people to benefit. But there > are likely other more efficient ways to deal with this problem and > allow legitimate holders to conduct private transactions with limited > difficulty and _limited expense_. ARIN does charge $250 one-time to process transfers, per the fee schedule here > Signing the LRSA is significantly risky IMHO. I found many > requirements that if I were holding legacy resources I would find non > conducive to a mutually beneficial relationship with the ARIN > community especially since there's no incentive to do so now: > > - no mutual termination > - termination only for cause > - no membership benefits > - fees > - less rights that members e.g. audits, etc. > - Subject to current and future policies without recourse You might want to reread the LRSA as well. The LRSA does contain a nominal annual fee ($100) but also explicitly takes precedence over any policy changes and requires ARIN to provide registry services (whois, reverse) for the resources, even those which are unused. > Without carrot, we'll see limited use of the 8.3 required transfer > mechanisms. I would suggest the carrots would be: > > -no fees > -mutual termination > -membership While the present terms are actually quite favorable, it's always worth revisiting if the community wishes. There is a parity issue, in that most of the community is paying significant more for these same services today, and equitable sharing of the registry costs is viewed by many as expected. > This seems off. The rules for transfer were written outside of the > policy process. Based on the leasing thread it would seem that the > membership does want "softer" rules with respect to transfers and the > market in general. That in turn will invite those people to > participate and become legitimate actors to the benefit of the > community. The Specified Transfer policy is NRPM 8.3 and was developed by community via the policy development process. The STLS is completely optional and I welcome any suggestions for change. > Since the onerous part is not policy, how do we go about getting this changed? If it's in NRPM 8.3, then it's the policy development process. If it's the LRSA, I'd recommend encouraging discussion at the next PPM (either in person or remote) so that the Board has fresh and recent insight into the community views on this. Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Mon Feb 7 22:08:02 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 7 Feb 2011 22:08:02 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> Message-ID: On Mon, Feb 7, 2011 at 9:53 PM, John Curran wrote: > On Feb 7, 2011, at 10:23 PM, Martin Hannigan wrote: > >> Both. 8.3 requires the use of the STLS. They are effectively one. > > NRPM 8.3 is a policy, and ARIN will process specified transfer > requests from two parties which appear and meet the criteria. > Neither of them has to be a participant in the Specified Transfer > Listing Service (STLS); the STLS is simply a convenience for those > parties who want some help finding a match. ?Think of it this way: > STLS is a dating service, which you don't need to use if you already > have a partner and just want to go (via NRPM 8.3) and get married. > >> Members do not want those(Illegitimate) people to benefit. But there >> are likely other more efficient ways to deal with this problem and >> allow legitimate holders to conduct private transactions with limited >> difficulty and _limited expense_. > > ARIN does charge $250 one-time to process transfers, per the fee > schedule here > >> Signing the LRSA is significantly risky IMHO. I found many >> requirements that if I were holding legacy resources I would find non >> conducive to a mutually beneficial relationship with the ARIN >> community especially since there's no incentive to do so now: >> >> - no mutual termination >> - termination only for cause >> - no membership benefits >> - fees >> - less rights that members e.g. audits, etc. >> - Subject to current and future policies without recourse > > You might want to reread the LRSA as well. ?The LRSA does contain > a nominal annual fee ($100) but also explicitly takes precedence over > any policy changes and requires ARIN to provide registry services > (whois, reverse) for the resources, even those which are unused. "Reread the LRSA" is a blanket statement. Can you specify what I'm inaccurate about? If it's just fees, thanks. If not, I'd appreciate further explanation. > >> Without carrot, we'll see limited use of the 8.3 required transfer >> mechanisms. I would suggest the carrots would be: >> >> -no fees >> -mutual termination >> -membership > > While the present terms are actually quite favorable, it's always We disagree. > worth revisiting if the community wishes. ?There is a parity issue, > in that most of the community is paying significant more for these > same services today, and equitable sharing of the registry costs is > viewed by many as expected. That we agree on, but the benefit of having a vibrant transfer market may be deemed by the members to outweigh the need for extended fees. My estimates show that the cost of a /24 for a small member would be more than doubled after fees and expenses as a result of the non policy part of transfer and the LRSA are passed through. Does ARIN have any estimates as to what a transfer will really cost all of us? [ clip ] Best, -M< From mksmith at adhost.com Mon Feb 7 22:16:29 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 8 Feb 2011 03:16:29 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: Message-ID: On 2/6/11 3:48 PM, "Martin Hannigan" wrote: >Staff et. Al, > >Can we get a recap of activity around resource requests for IPv6 and a >characterization of refusals, if any? If there are none, it would be >interesting to hear a general conclusion as to why. I'm interested to >see if there are any holes here considering all of the work that has >been done to ease access to v6 for transition. > >Best, and go Steelers! > >-M< To add to Martin's request - could it be added to the daily allocation RSS feed as well? Regards, Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From hannigan at gmail.com Mon Feb 7 22:18:56 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 7 Feb 2011 22:18:56 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> Message-ID: On Mon, Feb 7, 2011 at 9:53 PM, John Curran wrote: > On Feb 7, 2011, at 10:23 PM, Martin Hannigan wrote: > >> Both. 8.3 requires the use of the STLS. They are effectively one. > > NRPM 8.3 is a policy, and ARIN will process specified transfer > requests from two parties which appear and meet the criteria. > Neither of them has to be a participant in the Specified Transfer > Listing Service (STLS); the STLS is simply a convenience for those > parties who want some help finding a match. ?Think of it this way: > STLS is a dating service, which you don't need to use if you already > have a partner and just want to go (via NRPM 8.3) and get married. NRPM 8.3 is the policy related to "Specified Transfers". The Specified Transfer Listing Service is a process and it says: "ARIN?s Specified Transfer Listing Service (STLS) provides a mechanism by which validated organizations may identify potentially complementary parties suitable to participate in a transfer of IPv4 number resources per ARIN?s Number Resource Policy Manual, section 8.3, ?Transfers to Specified Recipients? That's a direct linkage and from my perspective its adjunct policy. I'm not sure why you are saying that this is optional. It certainly does not appear to be optional. As usual, thanks for the explanation. Best, -M< From hannigan at gmail.com Mon Feb 7 22:21:55 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 7 Feb 2011 22:21:55 -0500 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: Message-ID: On Mon, Feb 7, 2011 at 10:16 PM, Michael K. Smith - Adhost wrote: > > > On 2/6/11 3:48 PM, "Martin Hannigan" wrote: > >>Staff et. Al, >> >>Can we get a recap of activity around resource requests for IPv6 and a >>characterization of refusals, if any? If there are none, it would be >>interesting to hear a general conclusion as to why. I'm interested to >>see if there are any holes here considering all of the work that has >>been done to ease access to v6 for transition. >> >>Best, and go Steelers! >> >>-M< > > > To add to Martin's request - could it be added to the daily allocation RSS > feed as well? That's a great idea. I don't know what the use stats are on the v4 RSS, but I get it and actually analyze it frequently. I'm looking for something more immediate. I'd like to see the results of my query here in this thread so that there can be a discussion. The policy meeting is coming up soon and time is getting short to make any corrections that may appear evident as a result. Best! And thanks! -M< From jcurran at arin.net Mon Feb 7 22:26:40 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 03:26:40 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> Message-ID: <1C361F1D-3616-48A2-98BC-1F3A05B4F2B4@arin.net> On Feb 7, 2011, at 11:08 PM, Martin Hannigan wrote: > "Reread the LRSA" is a blanket statement. Can you specify what I'm > inaccurate about? If it's just fees, thanks. If not, I'd appreciate > further explanation. Section 7 provides contractual precedence and 10(b) precludes reducing services to number resources under agreement, even those unused. > My estimates show that the cost of a /24 for a small member would be > more than doubled after fees and expenses as a result of the non > policy part of transfer and the LRSA are passed through. The small member doesn't need to use the STLS, and the processing fee for a transfer is $250 per the schedule. I imagine that a legacy holder of a /24 might want to pass along the $100 that they are charged for the first year to a recipient and this would make it a grand total of $350. FYI, /John John Curran President and CEO ARIN From owen at delong.com Mon Feb 7 22:29:19 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 19:29:19 -0800 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> Message-ID: > > My estimates show that the cost of a /24 for a small member would be > more than doubled after fees and expenses as a result of the non > policy part of transfer and the LRSA are passed through. Does ARIN > have any estimates as to what a transfer will really cost all of us? > You estimated $40/address. For a /24, that's $10,240. LRSA fees: $100 Transfer fee: $250 ($10240 + $100 + $250) / 2 = $5,295 Where is this doubling of which you speak? Owen From owen at delong.com Mon Feb 7 22:41:10 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 19:41:10 -0800 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> Message-ID: On Feb 7, 2011, at 7:18 PM, Martin Hannigan wrote: > On Mon, Feb 7, 2011 at 9:53 PM, John Curran wrote: >> On Feb 7, 2011, at 10:23 PM, Martin Hannigan wrote: >> >>> Both. 8.3 requires the use of the STLS. They are effectively one. >> >> NRPM 8.3 is a policy, and ARIN will process specified transfer >> requests from two parties which appear and meet the criteria. >> Neither of them has to be a participant in the Specified Transfer >> Listing Service (STLS); the STLS is simply a convenience for those >> parties who want some help finding a match. Think of it this way: >> STLS is a dating service, which you don't need to use if you already >> have a partner and just want to go (via NRPM 8.3) and get married. > > > NRPM 8.3 is the policy related to "Specified Transfers". > > The Specified Transfer Listing Service is a process and it says: > > "ARIN?s Specified Transfer Listing Service (STLS) provides a mechanism > by which validated organizations may identify potentially > complementary parties suitable to participate in a transfer of IPv4 > number resources per ARIN?s Number Resource Policy Manual, section > 8.3, ?Transfers to Specified Recipients? > > That's a direct linkage and from my perspective its adjunct policy. > The STLS is absolutely dependent on and linked to NRPM 8.3. NRPM 8.3 is NOT linked in the other direction. You are completely free to engage in an NRPM 8.3 transfer without using STLS. > I'm not sure why you are saying that this is optional. It certainly > does not appear to be optional. As usual, thanks for the explanation. > Perhaps you misunderstand the meaning of the English word "may". in what you referred to as direct language above. Perhaps there is some other issue. STLS has a one-way dependency on NRPM 8.3. NRPM 8.3 does NOT depend on STLS. If you read NRPM 8.3, I think that is pretty clear. There is not even a reference to STLS in NRPM 8.3. Owen From jcurran at arin.net Mon Feb 7 22:47:39 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 03:47:39 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> Message-ID: On Feb 7, 2011, at 11:18 PM, Martin Hannigan wrote: > The Specified Transfer Listing Service is a process and it says: > > "ARIN?s Specified Transfer Listing Service (STLS) provides a mechanism > by which validated organizations may identify potentially > complementary parties suitable to participate in a transfer of IPv4 > number resources per ARIN?s Number Resource Policy Manual, section > 8.3, ?Transfers to Specified Recipients? > > That's a direct linkage and from my perspective its adjunct policy. > > I'm not sure why you are saying that this is optional. It certainly > does not appear to be optional. As usual, thanks for the explanation. I have taken the action item to get this text revised to make it more explicit, as we want to make sure that many folks unfamiliar with ARIN have good chance of getting it right the first time they see it. Thanks for pointing it out! /John John Curran President and CEO ARIN From bensons at queuefull.net Mon Feb 7 22:59:51 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 7 Feb 2011 21:59:51 -0600 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Feb 7, 2011, at 7:09 PM, John Curran wrote: > For a party (e.g. legacy holder) who plans to monetize their space in > any case, there are two downsides to doing it via the Specified Transfer > policy: > > 1) You have to enter into an LRSA, but from a practical matter it is > only going to be meaningful for the fairly short duration from when > you enter into it and until you transferred all your address holdings > -and- > 2) You can only transfer what the recipient qualifies for, which is > limited to 12 months of their documented address need per the NRPM > in the ARIN region. Except that the current LRSA forces the holder to waive any claim of property rights and cannot be terminated without forfeiting the legacy addresses, encumbering the holder's legal recourse to redress. And while it is in force there is no guarantee that the policy and contracts applied to ARIN participants (including the potential recipients) will remain consistent. So, the "short duration" that you described actually has a great deal of risk, including a risk that the duration itself stretches out materially. This is a pretty bad situation to be in, if one is trying to monetize address resources within a limited window of time i.e. while IPv4 still has value. > Because your address holdings actually get vetted when you entered the > LRSA, the benefits to the recipient is that they know you actually have > the ability to transfer per policy (and aren't just someone who hijacked > the space by registering an expired domain name on a contact & emailing) I agree that this assurance has value. But the value of ARIN's vetting is minimal unless ARIN 1) is able to represent itself as the sole legal "authority" in the matter of address allocations, as applied to the legacy address block, and/or 2) is willing to provide some form of insurance against loss (title insurance?) due to incorrect vetting. > This certainty is key for most organizations that intend to build a > long-term business based on use of the number resource. Note also a > (growing) recipient probably has many existing address blocks that are > already under RSA, and the one received by transfer is no different. > I'm looking for the onerous policy considerations regarding the need > for L/RSA agreements, and for the vast majority of expected users of > the policy, it's not clear that is any agreement-related downside. For any recipient of addresses under the transfer policy, because of the RSA requirement, there is real risk associated with the ongoing ability to use an address block. The RSA has a very one-sided auto-update provision as well as the forfeiture at termination clause, and ARIN policy is subject to change. You might argue that the risk is the same as RIR-provided addresses historically, and I wouldn't object. But that class of holders has paid only a nominal fee to receive their addresses, not "market rates". Further, the risks associated with the LRSA/RSA don't apply to legacy holders that have not signed the LRSA, making non-encumbered address blocks much more appealing. > I agree that the policy isn't likely to be favored by speculators or > address squatters, and that those segments may have been historically > underrepresented in the policy development process. Correcting that > is left as an exercise for the community, if so desired. Given my comments above, I hope you're recognize that there are concerns applicable to buyers other than "speculators or address squatters". That said, the avoidance at any cost of market speculation isn't necessarily in the community's interest. I'll comment more on that as part of a draft policy proposal I'm working on, and look forward to debating it. Cheers, -Benson From jcurran at arin.net Mon Feb 7 23:27:43 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 04:27:43 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Feb 7, 2011, at 11:59 PM, Benson Schliesser wrote: > Except that the current LRSA forces the holder to waive any claim of property rights and cannot be terminated without forfeiting the legacy addresses, encumbering the holder's legal recourse to redress. And while it is in force there is no guarantee that the policy and contracts applied to ARIN participants (including the potential recipients) will remain consistent. That is correct, and parallels the situation that all other resource holders face as well. If the community changes policies by which number resources are managed, then the resources get managed by the new policies. > I agree that this assurance has value. But the value of ARIN's vetting is minimal unless ARIN 1) is able to represent itself as the sole legal "authority" in the matter of address allocations, as applied to the legacy address block, and/or 2) is willing to provide some form of insurance against loss (title insurance?) due to incorrect vetting. With regarding to #1, ARIN is the sole maintainer of the ARIN WHOIS database, and so based on the policies developed by the community. I'm not aware of anyone offering such insurance, but then, that does not preclude someone from trying to sell such. > For any recipient of addresses under the transfer policy, because of the RSA requirement, there is real risk associated with the ongoing ability to use an address block. The RSA has a very one-sided auto-update provision as well as the forfeiture at termination clause, and ARIN policy is subject to change. You might argue that the risk is the same as RIR-provided addresses historically, and I wouldn't object. Correct. > Further, the risks associated with the LRSA/RSA don't apply to legacy holders that have not signed the LRSA, making non-encumbered address blocks much more appealing. Attempting to transfer a legacy block contrary to policy entails risk. > Given my comments above, I hope you're recognize that there are concerns applicable to buyers other than "speculators or address squatters". Absolutely, particularly with respect to the "uncertainty" regarding changes to policy while post-LRSA. I expect its a matter of outlook regarding transfer demand; I expect the period post-LRSA to be very brief given that every request for space in 6 to 9 months is going to be a potential recipient. /John John Curran President and CEO ARIN From hannigan at gmail.com Tue Feb 8 00:08:43 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Feb 2011 00:08:43 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: <1C361F1D-3616-48A2-98BC-1F3A05B4F2B4@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <2344EA83-9BD4-4D8C-A3C7-EE39BBFEEFDF@arin.net> <1C361F1D-3616-48A2-98BC-1F3A05B4F2B4@arin.net> Message-ID: On Mon, Feb 7, 2011 at 10:26 PM, John Curran wrote: > On Feb 7, 2011, at 11:08 PM, Martin Hannigan wrote: > >> "Reread the LRSA" is a blanket statement. Can you specify what I'm >> inaccurate about? If it's just fees, thanks. If not, I'd appreciate >> further explanation. > > Section 7 provides contractual precedence and 10(b) precludes reducing > services to number resources under agreement, even those unused. Context? I'm not concerned about the services impact for an LRSA signatory other than I agree that there is a cost recovery component that needs to be considered. I am concerned that the agreement is significantly lopsided to the detriment of the membership. If another entity offers services like ARIN's to legacy holders, we may lose the opportunity as a community to participate in making it work to the benefit of all. >> My estimates show that the cost of a /24 for a small member would be >> more than doubled after fees and expenses as a result of the non >> policy part of transfer and the LRSA are passed through. > > The small member doesn't need to use the STLS, and the processing fee > for a transfer is $250 per the schedule. ?I imagine that a legacy holder > of a /24 might want to pass along the $100 that they are charged for the > first year to a recipient and this would make it a grand total of $350. > There are other costs likely to be passed on. The LRSA is nine pages of legality that will need significant evaluation and discussion. ARIN is likely to have a negative stance with respect to negotiating the agreement which will add more cost. For example purposes: If we use a known unit cost basis of $4 per address, we're talking about a raw cost of $1,024 for a /24. If we add on the $350, we have a cost of $1374, $5.36 per address, or a 24% increase over the actual cost which at $4 is already a > 260% increase in cost pre-market. It's significant no matter which way you cut it. I would offer these as suggestions: 1. Remove section 14(d) and add mutual termination 2. Present a legacy holder fee waiver to the membership in a neutral manner 3. Require use of ARIN's whois services in compliance with policy 4. Modify Section 7 to require whois compliance only 5. Offer a clearinghouse and (arrange for) escrow services to reduce risk to members 6. Make legacy holders card carrying ARIN members for free I saw your note on clarifying the STLS language. Thanks. That is a good thing. That linkage makes it policy made outside of the policy framework. Hope that's helpful. Best, Marty From bensons at queuefull.net Tue Feb 8 00:23:20 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 7 Feb 2011 23:23:20 -0600 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> On Feb 7, 2011, at 10:27 PM, John Curran wrote: >> I agree that this assurance has value. But the value of ARIN's vetting is minimal unless ARIN 1) is able to represent itself as the sole legal "authority" in the matter of address allocations, as applied to the legacy address block, and/or 2) is willing to provide some form of insurance against loss (title insurance?) due to incorrect vetting. > > With regarding to #1, ARIN is the sole maintainer of the ARIN WHOIS > database, and so based on the policies developed by the community. > I'm not aware of anyone offering such insurance, but then, that does > not preclude someone from trying to sell such. My comment was targeted at your statement about ARIN "vetting" address rights (or whatever you want to call it) associated with a legacy block. You stated that there was value in such vetting, and I'm inclined to agree. But the degree of value could be wildly different depending on the vetting process, associated authority or insurance, etc. Take this hypothetical case as example: ARIN receives a LRSA for a legacy block, vets the legacy address holder and accepts the LRSA, and then facilitates the transfer of addresses to a specified recipient. The recipient and their ISPs are then hit with a court order instructing them, in whatever manner, to stop routing the addresses because they belong to somebody else. This might have happened due to sloppy records, convoluted M&A and/or bankruptcy history, or whatever else you want to imagine including outright mistake or even fraud. Maybe ARIN was consulted by the court, or maybe ARIN wasn't consulted - after all, ARIN is just one of the many possible Whois database sources that exist, and claims only to be self-referentially authoritative. In this situation, does the recipient have any recourse? Who pays their legal fees, and if they lose the address block who refunds their costs? They can sue the "seller", but I'd also expect them to also sue ARIN for incorrectly "vetting" the original legacy block holder. Now, this is completely hypothetical, but it's also plausible. I don't think ARIN should shy away from vetting and facilitating these transfers - that's not my point in the least. My point is that ARIN should establish the process in a legally defensible way, and back up the process with the sort of risk mitigation that businesses would expect. Otherwise, your previous comment about LRSA value for transfer transactions is moot. >> Further, the risks associated with the LRSA/RSA don't apply to legacy holders that have not signed the LRSA, making non-encumbered address blocks much more appealing. > > Attempting to transfer a legacy block contrary to policy entails risk. Absolutely. But it's a risk that hasn't been tested: whether ARIN has any authority to reclaim legacy address blocks (especially from entities that it has no contractual relationship with) and/or whether ARIN is liable for damages if such a reclamation results in a negative outcome for any parties involved or third parties, etc. Entering into an RSA and leveraging ARIN's services for transfer etc might remove the untested risk you've mentioned, but at the cost of the identifiable risks I described in my previous note. >> Given my comments above, I hope you're recognize that there are concerns applicable to buyers other than "speculators or address squatters". > > Absolutely, particularly with respect to the "uncertainty" regarding > changes to policy while post-LRSA. I expect its a matter of outlook > regarding transfer demand; I expect the period post-LRSA to be very > brief given that every request for space in 6 to 9 months is going > to be a potential recipient. What I think you're saying, in that last comment, is that demand will significantly outpace the supply - and that the demand/supply spread will result in very short durations of LRSA-to-transfer periods. I think I agree with you, at least for a period of time in the near future, and especially if legacy holders can identify recipients before entering into the LRSA. (Perhaps ARIN would permit an LRSA for only part of a de-aggregated legacy block?) But it doesn't mitigate the ongoing encumbrance to the recipient, relative to the original legacy allocation. Admittedly, I think we disagree on this point; see my comments above. Cheers, -Benson From tedm at ipinc.net Tue Feb 8 01:05:09 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 07 Feb 2011 22:05:09 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D5032A3.! 6060302@ipinc.net> Message-ID: <4D50DD15.3000807@ipinc.net> On 2/7/2011 12:39 PM, Owen DeLong wrote: > > On Feb 7, 2011, at 9:57 AM, Ted Mittelstaedt wrote: > >> On 2/7/2011 1:21 AM, Owen DeLong wrote: >>> >>> On Feb 6, 2011, at 10:47 PM, Ted Mittelstaedt wrote: >>> >>>> On 2/6/2011 8:36 AM, Lee Howard wrote: >>>>> >>>>> >>>>>> From: Benson Schliesser >>>>> >>>>>> >>>>>> Sadly, because we've waited too long to grow IPv6 penetration to >>>>>> the inflection point ("the moment that end users start accepting and >>>>>> using IPv6"), people will still need to deploy IPv4. Vendors will >>>>>> make money on NATs. And people will find ways to get addresses >>>>>> - one way or another. >>>>> >>>>> This is often asserted and generally accepted. Is it true? >>>>> >>>> >>>> Today - yes. Tomorrow - IMHO it is completely dependent on the >>>> CPE vendors. >>>> >>>>> Nobody wants NAT: ISPs, content providers, law enforcement, >>>>> copyright holders, game console manufacturers, web advertisers, >>>>> home gateway vendors, >>>> >>>> agreed. >>>> >>>> and end users all have an interest in >>>>> avoiding NAT. >>>> >>>> wrong. End users absolutely need inexpensive - and I'm talking $60 and >>>> under - stateful packet inspection hardware firewalls. >>>> >>> Your statement is absolutely correct except for the first word. >>> >> >> I did say "today - yes" >> >>>> So far the only devices that meet that criteria are NAT devices. >>>> >>> >>> A temporary problem. >>> >> >> But a very big one. The CPE market is characterized by manufacturers >> stripping every bit of functionality out of the devices that is not >> demanded by customers, and cheapening the devices down to the point >> it's incredible that they operate at all. IPv6 hasn't been on the >> demand list and it's amazing any CPE vendors even offer the limited >> variants of it that they do on the few devices that they do now. >> > Big problem: Yes. Does NAT solve it today? No. Will NAT solve it in > the future? No. > > NAT isn't the solution. Nobody is saying that it is. SPI is the solution. NAT is unnecessary in IPv6. > > You, yourself admitted that the SOHO CPE that doesn't do SPI for IPv6 > also doesn't NAT it. If there's no security solution in the SOHO CPE today, > then, the question isn't NAT or not NAT, the question is what is the right > SOHO security solution to be encouraging the vendors to put in these > products. SPI is a security solution. NAT is not. As such, I think we > should dispense with the NAT discussion and get them to implement > SPI. > Hang on, the topic proposed was Do We Need Nat with the implication I belive of Do We Need IPv4? Please don't hijack it for a discussion of SPI. So far there is no NAT implementation for IPv6 that would meet any standard of production quality or reliability, at least not under linux, and so IPv6 NAT is a non-starter at the current time for the "el cheapo CPE vendor" crowd since all their stuff is based on Linux. The CPE people are going to do what the Linux developers do and they aren't embracing any type of IPv6 NAT and unless something like it is standardized by IETF it is unlikely that they will. >>>> Even the few SOHO CPE's like the D-link and Cisco RVS4000 that >>>> implement IPv6 do NOT include stateful packet inspection in their >>>> CPE's on the IPv6 part of it. >>>> >>> As you point out, nothing currently available to the consumer does >>> IPv6 SPI with or without NAT. The CPE router requirements bis >>> document that is in the final stages at IAB and should be out shortly >>> will require SPI, among other improvements. >>> >>> I think you will see more capable IPv6 CPE shortly. I vote we >>> fix the CPE rather than break the internet, OK? >>> >> >> dd-wrt already has this capability in the mega load that runs on >> OLDER Linksys WRT54GS devices. But the newer WRT54GS devices >> have halved the amount of flash - as a cost-cutting move - and >> cannot run it. >> > Yep. > >> In short the CPE vendors have RETARDED development in a way. >> > Sure. > >> Obviously they have to step up to the plate. IMHO adding SPI >> to just about all of the currently available devices - based on >> BusyBox Linux as they are - means adding more code, which means >> adding flash ram - which to the CPE vendors means the device >> costs more. >> > And I think that they will. > >> Comcast also fell down when they provided their IPv6 modified >> CPE code to flash on a Linksys 160NS - all that was, was the >> wrt load with a few of the already existing IPv6 apps added. >> > Your point being? > > I think they did what they could with the tools available at the time. > I know Comcast is pushing the CPE vendors for a number of features > they want but don't have currently. > both ddwrt and openwrt have demonstrated ipv6 filtering since before Comcast got involved so I don't buy that excuse. Comcast would have been a lot more helpful to have worked with the openwrt people instead of taking an openwrt load - that requires an atheros chipset with 8MB of flash, which exists in practically no CPE other than that one Linksys "Linuxized" version - and "forking" it off openwrt. Because of that all the work Comcast did on that fork is pretty much a dead end. A much wiser course would have been for Comcast to create an IPv6ized load on a Broadcom-based 4MB flash CPE. It's possible. crushedhat did it with dd-wrt. And such a load would have run on a hell of a lot more CPEs out there than what they did. >> I don't have a lot of hope for these vendors to Do The Right >> Thing so far. I agree with you that we need to fix the CPE >> but the selfish self-interest of these vendors is to do >> exactly the opposite. >> > I think the vendors will do the right thing when they see agreement > in the community on what the right thing is. That's why I'm hoping > we can get the cpe-router-bis document through IAB soon. I think > it is a major step forward in the correct direction. > >>>>> Even NAT vendors are decorously sheepish in >>>>> selling their products. If everyone wants to avoid it, why are we >>>>> stuck with it? >>>>> >>>> >>>> Because in the beginning none of those stakeholders that have >>>> an interest against NAT nowadays were in play, many did not exist. >>>> And the end users needed stateful packet inspection, address >>>> portability, and an unconstrained source of addresses. NAT >>>> solved those problems. >>>> >>> Sort of. >>> >>>> What has IMHO changed is the coming into existence of stakeholders >>>> who want to "reach into the consumers network" Groups like >>>> law enforcement, copyright digital rights management people, >>>> advertisers, and so on would all love to gain "authorized" >>>> access to consumers machines for their own purposes. >>>> >>> No, what has changed is that with IPv6, we now have enough addresses >>> that we can abandon the kludgy hack that allowed us to recycle >>> addresses rapidly (NAT). >>> >>>> Today, EVEN IF a consumer WANTS a corporation like itunes to >>>> contact one of their network devices in their homes, there is >>>> no way they can click a box or whatever on their network device >>>> to allow this - other than having a program on that device >>>> initiate contact to the stakeholder. And that kind of >>>> architecture is not scalable because the stakeholder cannot >>>> schedule the incoming contacts. >>>> >>> Actually, yeah, they sort of can. It's called "port forwarding" and >>> most home gateways allow you to configure a static state table >>> entry that way. >>> >> >> The problem with this is: >> >> 1) Among all the CPE's there is no accepted way to do this >> so client programs have no way to talk to the CPE to tell it >> to open a port forward. UPnP is helping in this regard >> but it's completely unauthenticated and being implemented >> as a massive security hole. >> > You're talking about two different things. I'm talking about a static > permanent port forward which the user can configure you lost it right there "user can configure" We don't want that. We want itunes(or whatever) software to have a button that Sally Joe User clicks and itunes automagically goes to Sally Joe User's router and opens up the appropriate control port so that Apple can come in and do whatever she wants them to do with her itunes. 90% of consumers don't know anything about their CPE's and DON'T WANT TO LEARN. to permit > inbound flows by using the configuration tools on the router. > > You're talking about a dynamic temporary state table entry under > the control of the application (which leads me to question the > value of even having a firewall in such an environment). > Any discussion of firewalling for the consumer eventually leads down to the inevitable - consumers want the benefits of being behind a firewall, but they don't want to lift a finger to DO anything to configure the firewall for their environment. You can put all the SPI you want into the CPE but if any of it is dependent on the customer using a web browser or whatever to configure it, then your wasting your effort. Most of them won't do it. This is why the current paradigm on the Internet is a "fetch" one. The user wants something from the network, they initiate a request for it (ftp, http or whatever) We can design a firewall "toaster" that sort of works in that environment because the toaster assumes that a request from a host on the "inside" is legitimate. What we can't do is design a firewall that when it boots up it "knows" that the user has a particular program that is expecting a polled connection from a mothership on the Internet at 3:46am every morning. And your never going to get 90% of the consumers with that program to go into their firewalls and tell the firewall about it. >> 2) The mothership cannot schedule the clients when they call >> in so the client callins are not evenly distributed over >> the day. >> > I'm not sure I understand what you mean by this or how it relates > to the discussion at hand. FWIW, TiVO, at least does represent > a case of the mothership scheduling when the clients call in for > the most part. > If your building a server farm that is going to contact 5 million users on the Internet every night and deliver a 5MB data payload are you going to want to make your farm dependent on all of those users having accurate clocks? No, you are going to want to push the data out on your schedule, under your control. That's why you want all of the destinations your pushing data to to have public numbers on the Internet. You don't want to be talking to firewalls or NATs you want to connect to what it behind those things. Otherwise you end up with what Microsoft has with their Windows Update Servers, a gigantic pipe that is mostly empty most of the month and is saturated every Tuesday. > >>>> The irony of it is that once the CPE market matures and we >>>> have many products including IPv6, the consumers will be demanding >>>> them to have firewalling. >>>> >>> That's not a bad thing, but, it has nothing to do with NAT. >>> >>> Repeat after me... SPI is security. NAT is just mutilation of the >>> address fields in the packet header. >>> >> >> Repeat after me... current CPE's treat them as the same thing, >> forcing the consumers to do likewise. Any CPE discussion is >> academic until the CPE vendors start separating the two functions. >> > Repeat after me... We need to tell the CPE vendors what we want. > Talking about what is and how to bring what is forward into IPv6 > only creates confusion and exacerbates the situation. Especially > when you use terms like inevitable. > I would like exactly the same thing that happened with PC's to happen with CPEs. In the PC market today you have a single software package - Windows - that runs on a lot of variety of hardware from many different vendors. Hardware box makers compete on the basis of hardware I would like the CPE vendors to settle on a standard load. The obvious choice would be openwrt because they don't have to pay anyone to license it. Then you would have a single software package - openwrt that runs on a lot of variety of CPE hardware from many different vendors. Hardware CPE box makers compete on the basis of hardware. >>>> As an admin of an ISP I would never deploy IPv6 to my "ma >>>> and pa kettle" customers until a CPE existed that included >>>> firewalling on the IPv6 side out of the box. The reason is >>>> that if I did then within hours Ma and Pa Kettle's peecee's >>>> would be cracked into and they would be on the phone with >>>> me, costing me precious support dollars, wanting to know why >>>> their peecee was running so slow. >>>> >>> Sure... Good call. I would agree. And those boxes are coming. >>> >>>> So I do not see that the stakeholders you mentioned - law >>>> enforcement, the DRM crowd, etc. - are going to be any better >>>> off under IPv6. They still won't have a defined way of >>>> getting at consumer network devices. >>>> >>> Way way way better off. They don't have to get at the consumer >>> network device, but, it sure is nice to be able to identify the >>> exact device rather than just "something somewhere behind >>> that gateway over there". >>> >> >> Without being able to interrogate the device to get ownership >> info from it, they are still relying on whois data to be >> accurate. It is better for most of those stakeholders but it >> isn't really what most of them want. >> > Better is at least a step in the right direction. NAT is worse. > > I'm not sure why you're arguing here. You've agreed that they > all would feel that SPI without NAT is an improvement, yet you > say that because it isn't everything they want, they want NAT? > > Sorry, that isn't making any sense to me. > They want unimpeded access to the consumers hosts! The advertising people want to reach out and connect to your computer and query your computer for all of the places that it has been. They don't want a SPI firewall or NAT preventing this. They see IPv6 as a wonderful advancement because to use it you can't use a NAT device that will block them out. The law enforcement people want to get search warrants and reach out and do electronic searches of your computer without the bother of sending people to your door or even telling you they are searching. They don't want a SPI firewall or NAT preventing this. They see IPv6 as a wonderful advancement because to use it you can't use a NAT device that will block them out. The Motion Picture Association people want to reach out and get into your computer and inspect any movies that you may have on your disk to protect their copyrights. They don't want a SPI firewall or NAT preventing this. They see IPv6 as a wonderful advancement because to use it you can't use a NAT device that will block them out. You yourself said that there's a lot of big stakeholders out there with plenty vested interest in Ipv6. Well, this is who they are! They want IPv6 because they all think they have the right to access your machine. They don't want it for YOUR health, they want it for THEIRS! Ted >>> It's also nice that consumers will now have the option of >>> allowing connections directly into their network if they so choose. >>> >>> A good SPI firewall with real addresses on the inside provides >>> all of that. >>> >>>>> 1. ISPs aren't ready for IPv6. This belief is rapidly being >>>>> overtaken by events--most ISPs will have broad IPv6 this year. >>>>> 2. Content isn't ready for IPv6. This belief is rapidly being >>>>> overtaken by events. World IPv6 Day is a test-drive of content, >>>>> which should go a long way toward eliminating barriers. >>>>> 3. Home gateways aren't ready for IPv6. This belief is >>>>> slowly being overtaken by events. All home gateway makers >>>>> are developing IPv6, and industry is doing better as telling them >>>>> what needs to be fixed. However, it may still be true that all >>>>> home gateways sold before ARIN runout have to be replaced. >>>> >>>> Well, all of those were sold to customers who were connecting in >>>> with IPv4 so they only would need to be replaced if those >>>> customers's ISP's wanted to retract the IPv4 originally assigned >>>> to them. >>>> >>> Which is very likely to happen as address scarcity forces residential >>> ISPs to look to reclaiming addresses for low value services ($20-40/month >>> residential, for example) and re-use those addresses for services >>> that produce more revenue (web hosting, content, etc.) >>> >> >> I don't think so. The number of low-value customers far exceeds >> the number of high value customers. ISP's would not need to >> inconvenience more than a handful of low value ones to gain >> sufficient IPv4 for high value ones. >> > ISPs depend heavily on the cookie cutter model for consumer services. > Once they inconvenience a few customers, it won't be long before they > do the same thing universally to all of them just to avoid having to track > exceptions. > >>>>> 4. Consumer electronics aren't ready for IPv6. This is widely >>>>> true, although more embedded OSs are becoming IPv6-capable. >>>>> Most web-capable devices will be capable of simple firmware >>>>> or OS updates. Untraditional networked devices (like >>>>> entertainment systems) are in trouble. >>>>> >>>> >>>> I would tend to disagree with that last, because it is mandatory >>>> that anything that plays a Blue Ray disk be easily updatable >>>> by the consumer, because the blue Ray standard permits future >>>> modification of the encryption algorithms. >>>> >>> Yep... They'll have to provide IPv6 upgrades for all those BD >>> players. >>> >>>> Blu Ray players that become orphaned because their manufacturers go out of business or whatever, they will be unable to play newer disks eventually and will have to be scrapped. >>>> >>> Also true. >>> >>> One of the many reasons I am really annoyed that Toshiba threw >>> in the towel on HD-DVD. >>> >>>> And there are very few entertainment systems that are IPv4 >>>> networkable that AREN'T blue-ray players. There's some game consoles but those will be obsoleted long before this is a problem because frequent obsolescence of game consoles is part of any game console manufacturer's business plan. And there are some HD TV sets that can do netflix that may have a problem. >>>> >>> I have to disagree with you there. Of the 10 network-connected >>> entertainment devices in my house, 2 are blu-ray players. >>> >>> By my calculations, that has the BD players outnumbered 4:1. >>> >> >> how many aren't firmware updatable? And how many aren't >> scheduled for early obsolescense (ie: game consoles) >> > Everything I have with an ethernet connection is firmware updatable. > I have one BD player (not in the 10 above) which is firmware updatable, > but, which doesn't have a network connection. (Requires USB stick > to upgrade). > > In terms of obsolescence, you might be able to make the argument > on the PS/2, Wii, and PS/3. The Toshiba HD-A30 probably is already > considered obsolete. The others (TiVOs, Yamaha RX-V3900, > One BD player) do not meet that definition. Finally, the remaining > device (Apple Mac Mini) already supports IPv6 and is running native > dual stack now. Yes, I count this Mac Mini as a home entertainment > system because it was purchased specifically as a media player and > is connected via HDMI to the amplifier. The only display attached > to it is a Sharp LCD flat-screen Television (32" 1080p). While I have > a keyboard and mouse for it that I can break out at need, it is > 95% controlled with the Apple remote. 4% of the time, I use > RowMote on the iPad to control it. The keyboard and mouse are > used for the remaining 1% of the time, usually for configuration > changes or other more serious hacking on the device. > > For general purpose computing, there are 2 other iMacs and > 2 Macbook Pros in the house as well as a Linux based server. > > Note, all of the general purpose computing platforms are running > native dual stack now. > > Owen > > From owen at delong.com Tue Feb 8 01:11:08 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 7 Feb 2011 22:11:08 -0800 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Feb 7, 2011, at 8:27 PM, John Curran wrote: > On Feb 7, 2011, at 11:59 PM, Benson Schliesser wrote: > >> Except that the current LRSA forces the holder to waive any claim of property rights and cannot be terminated without forfeiting the legacy addresses, encumbering the holder's legal recourse to redress. And while it is in force there is no guarantee that the policy and contracts applied to ARIN participants (including the potential recipients) will remain consistent. > > That is correct, and parallels the situation that all other resource holders > face as well. If the community changes policies by which number resources > are managed, then the resources get managed by the new policies. > With the exception of the protections afforded LRSA signatories in LRSA 10b, right? Owen From jcurran at arin.net Tue Feb 8 03:43:10 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 08:43:10 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> Message-ID: <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> On Feb 8, 2011, at 1:23 AM, Benson Schliesser wrote: > My comment was targeted at your statement about ARIN "vetting" address rights (or whatever you want to call it) associated with a legacy block. You stated that there was value in such vetting, and I'm inclined to agree. But the degree of value could be wildly different depending on the vetting process, associated authority or insurance, etc. Because parties do attempt to hijack address blocks (and have had the ability to make changes to their record over time), ARIN needs to be particularly careful when formalizing relations with a party during the signing of the LRSA. > Take this hypothetical case as example: ARIN receives a LRSA for a legacy block, vets the legacy address holder and accepts the LRSA, and then facilitates the transfer of addresses to a specified recipient. The recipient and their ISPs are then hit with a court order instructing them, in whatever manner, to stop routing the addresses because they belong to somebody else. This might have happened due to sloppy records, convoluted M&A and/or bankruptcy history, or whatever else you want to imagine including outright mistake or even fraud. Maybe ARIN was consulted by the court, or maybe ARIN wasn't consulted - after all, ARIN is just one of the many possible Whois database sources that exist, and claims only to be self-referentially authoritative. Such cases due to occur, and ARIN has filed with courts in cases of error with 100% success to date. > In this situation, does the recipient have any recourse? Who pays their legal fees, and if they lose the address block who refunds their costs? They can sue the "seller", but I'd also expect them to also sue ARIN for incorrectly "vetting" the original legacy block holder. Litigation is common in the United States, indeed. > Now, this is completely hypothetical, but it's also plausible. I don't think ARIN should shy away from vetting and facilitating these transfers - that's not my point in the least. My point is that ARIN should establish the process in a legally defensible way, and back up the process with the sort of risk mitigation that businesses would expect. Otherwise, your previous comment about LRSA value for transfer transactions is moot. Already done. > Absolutely. But it's a risk that hasn't been tested: whether ARIN has any authority to reclaim legacy address blocks (especially from entities that it has no contractual relationship with) and/or whether ARIN is liable for damages if such a reclamation results in a negative outcome for any parties involved or third parties, etc. Entering into an RSA and leveraging ARIN's services for transfer etc might remove the untested risk you've mentioned, but at the cost of the identifiable risks I described in my previous note. ARIN routinely revokes address blocks, including legacy blocks, and ARIN's ability to enforce community-developed policy in maintaining the database has withstood challenges in both District and Bankruptcy courts. Repeating from November email send to PPML: > A summary is presented at each ARIN meeting during the Registration > Services report: https://www.arin.net/participate/meetings/reports/ARIN_XXVI/PDF/Friday/nobile_rsd_update.pdf > (slide 4) This is a total cumulative slide and reflects space in > /16 equivalents; ... This has lines for returned, revoked (for > non-payment), and reclaimed (generally due to fraud). > What I think you're saying, in that last comment, is that demand will significantly outpace the supply - and that the demand/supply spread will result in very short durations of LRSA-to-transfer periods. I think I agree with you, at least for a period of time in the near future, and especially if legacy holders can identify recipients before entering into the LRSA. (Perhaps ARIN would permit an LRSA for only part of a de-aggregated legacy block?) > > But it doesn't mitigate the ongoing encumbrance to the recipient, relative to the original legacy allocation. Admittedly, I think we disagree on this point; see my comments above. I believe we are actually in agreement regarding the "ongoing encumbrance" to the recipient; it exists, and is materially no different than that of any current resource holder under RSA. It is remarkably similar in all of the regions, and represents the requirements of having a common registry system. /John From hannigan at gmail.com Tue Feb 8 12:14:16 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Feb 2011 12:14:16 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Tue, Feb 8, 2011 at 3:43 AM, John Curran wrote: > On Feb 8, 2011, at 1:23 AM, Benson Schliesser wrote: > [ snip ] >> In this situation, does the recipient have any recourse? ?Who pays their legal fees, and if they lose the address block who refunds their costs? ?They can sue the "seller", but I'd also expect them to also sue ARIN for incorrectly "vetting" the original legacy block holder. > > Litigation is common in the United States, indeed. But as a membership organization, shouldn't we endeavor to avoid litigation, both for the organization and for the members? We are pooling our resources to manage addresses and that entails pooling risk. A vibrant transfer market requires trust. Providing a mechanism to instill trust in the transactions would seem to be key. The LRSA does not instill trust. Best, -M< From jcurran at arin.net Tue Feb 8 12:28:53 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 17:28:53 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: <3CA868D1-9E82-4A0D-9389-CA91839852F4@arin.net> On Feb 8, 2011, at 1:14 PM, Martin Hannigan wrote: >> Litigation is common in the United States, indeed. > > But as a membership organization, shouldn't we endeavor to avoid > litigation, both for the organization and for the members? Absolutely. Ultimately the Board determines the appropriate balance in these matters for the organization. I do not see any unusual risk related to ARIN managing the database in accordance with community developed policies, including with respect to the entries for legacy resources. We absolutely need to treat legacy address holders (just as all address holders) with respect, provide open participation in the policy development process, and provide an opportunity for them to enter a contractual relationship similar to that of other members. > We are pooling our resources to manage addresses and that entails pooling > risk. A vibrant transfer market requires trust. Providing a mechanism > to instill trust in the transactions would seem to be key. The LRSA > does not instill trust. To the extent that we can build consensus support for changes to the LRSA to improve trust, that is definitely worth discussing (e.g. at the upcoming San Juan meeting). Thanks! /John John Curran President and CEO ARIN From woody at pch.net Tue Feb 8 13:10:38 2011 From: woody at pch.net (Bill Woodcock) Date: Tue, 8 Feb 2011 10:10:38 -0800 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 8, 2011, at 9:14 AM, Martin Hannigan wrote: > A vibrant transfer market requires trust. The LRSA does not instill trust. Orthogonal issues. A vibrant transfer market is not, per se, a goal of ARIN or the community. Nobody _in_ the community makes a commission per transaction. And the LRSA does not exist to serve the transfer market. It predates the transfer market, and has its own goals, notably dispelling murkiness around the rights and obligations of legacy holders. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1Rhx4ACgkQGvQy4xTRsBGmoACdGEf7YEbX5AUccXCZAfsI639R ipoAn2nsKlHdg2U+RPLjHkqt41x/dcoP =yawq -----END PGP SIGNATURE----- From hannigan at gmail.com Tue Feb 8 13:27:33 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Feb 2011 13:27:33 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Tue, Feb 8, 2011 at 1:10 PM, Bill Woodcock wrote: > On Feb 8, 2011, at 9:14 AM, Martin Hannigan wrote: >> A vibrant transfer market requires trust. The LRSA does not instill trust. > > Orthogonal issues. ?A vibrant transfer market is not, per se, a goal of ARIN or the community. ?Nobody _in_ the community makes a commission per transaction. ?And the LRSA does not exist to serve the transfer market. ?It predates the transfer market, and has its own goals, notably dispelling murkiness around the rights and obligations of legacy holders. > I think you have it backwards, Bill. Commissions are orthogonal, the LRSA is a roadblock. -M< From jcurran at arin.net Tue Feb 8 14:04:04 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 19:04:04 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Feb 8, 2011, at 2:27 PM, Martin Hannigan wrote: > I think you have it backwards, Bill. Commissions are orthogonal, the > LRSA is a roadblock. Martin - The LRSA may be a roadblock depending on your particular goal. From your prior message, you propose three major areas for change: A. Need for a "mutual termination"/"walk away" option B. Need to be obligated to comply only with WHOIS-related policies B. Need for favorable fees and inclusion of ARIN membership (My summary, apologizes if I missed anything major...) With respect to "B", are you proposing that the currently adopted transfer policies not apply to legacy holders who enter an LRSA, or only that the policy set (other than for WHOIS policies) not change for them once they have entered into agreement? Thanks! /John John Curran President and CEO ARIN From hannigan at gmail.com Tue Feb 8 14:41:43 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 8 Feb 2011 14:41:43 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Tue, Feb 8, 2011 at 2:04 PM, John Curran wrote: > On Feb 8, 2011, at 2:27 PM, Martin Hannigan wrote: >> I think you have it backwards, Bill. Commissions are orthogonal, the >> LRSA is a roadblock. > > Martin - > > The LRSA may be a roadblock depending on your particular goal. From > your prior message, you propose three major areas for change: > > ?A. Need for a "mutual termination"/"walk away" option > ?B. Need to be obligated to comply only with WHOIS-related policies > ?B. Need for favorable fees and inclusion of ARIN membership > > ?(My summary, apologizes if I missed anything major...) This looks good. > With respect to "B", are you proposing that the currently adopted > transfer policies not apply to legacy holders who enter an LRSA, > or only that the policy set (other than for WHOIS policies) not > change for them once they have entered into agreement? That's a good question. Best, -M< From owen at delong.com Tue Feb 8 14:49:42 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Feb 2011 11:49:42 -0800 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Feb 8, 2011, at 10:27 AM, Martin Hannigan wrote: > On Tue, Feb 8, 2011 at 1:10 PM, Bill Woodcock wrote: > > >> On Feb 8, 2011, at 9:14 AM, Martin Hannigan wrote: >>> A vibrant transfer market requires trust. The LRSA does not instill trust. >> >> Orthogonal issues. A vibrant transfer market is not, per se, a goal of ARIN or the community. Nobody _in_ the community makes a commission per transaction. And the LRSA does not exist to serve the transfer market. It predates the transfer market, and has its own goals, notably dispelling murkiness around the rights and obligations of legacy holders. >> > > > > I think you have it backwards, Bill. Commissions are orthogonal, the > LRSA is a roadblock. > No, Bill has it right. Owen From frnkblk at iname.com Tue Feb 8 15:09:47 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 8 Feb 2011 14:09:47 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D4F9564.1010500@ipinc.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> Message-ID: <014d01cbc7cc$226f81e0$674e85a0$@iname.com> Due to device (storage) limitations D-Link wasn't able to put a firewall in many of its IPv-6 capable releases for its different hardware models, but DIR-655 is supposed to support SPI. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Monday, February 07, 2011 12:47 AM To: Lee Howard Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] inevitability of NAT? and end users all have an interest in > avoiding NAT. wrong. End users absolutely need inexpensive - and I'm talking $60 and under - stateful packet inspection hardware firewalls. So far the only devices that meet that criteria are NAT devices. Even the few SOHO CPE's like the D-link and Cisco RVS4000 that implement IPv6 do NOT include stateful packet inspection in their CPE's on the IPv6 part of it. From schiller at uu.net Tue Feb 8 16:11:32 2011 From: schiller at uu.net (Jason Schiller) Date: Tue, 08 Feb 2011 16:11:32 -0500 (EST) Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <839813.74109.qm@web63302.mail.re1.yahoo.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> Message-ID: Lee, I am starting a new thread, as your existing thread got polluted with a conversation about the need to protect consumer end-sites from in-bound sessions, and if that can only or best be accomplished with NAT or statefull firewall (with no DPI), or if DPI is required to explicitly permit or block certain tyraffic. If I understood your email you were asking a different question. Can we transition from IPv4 to IPv6 without widespread dependence on NAT as a translation technology? A decade ago IETF suggested that all IPv4-only systems should dual-stack prior to the depletion of IPv4 addresses, and the deployment of the first IPv6-only network. In that case there is no transition problem. At the moment a vast majority of the Internet facing content is IPv4-only. This is a result of two things; 1. a chicken and egg problem, where the end-sites don't feel a need to go dual-stack, as there is no IPv6-only content, and the content provider don.t feel a need to go dual stack as there are no IPv6 users. 2. There is real cost and risk involved in deploying IPv6 with no new products, services, capabilities, or revenue. As such it is in a company's best interest to defer the added cost of deploying IPv6 until the last moment. Now is the time to see if everyone planned accordingly, and started in time. If there is a rapid wide spread IPv4 / IPv6 dual-stack deployment (I mean end systems can use both protocols equally well regardless of the technology leveraged) then this will drive content providers and application developers to support IPv6 in a real way. If all of this can happen in the time period between IANA depletion and when the first organizations are forced to build green field IPv6-only networks, then dependance on NAT can be mostly avoided as a protocol translation mechanism. Is likely that 100% of the content will be dual-stacked or even most of the important content? That question misses the point. To the extent that we are successful with getting content dual-stack prior to organizations being forced to deploy IPv6-only networks, we *minimize* the amount of dependence (and hence pain) of IPv4 / IPv6 NAT style translation. Is it likely we will all be forced to deploy some flavor of IPv4 / IPv6 NAT style translation? That question misses the point, see above, but yes. To the extend that we don't want to turn away new customers that refuse to upgrade their hw / sw to support IPv6, we will have to deploy some flavor of translation. The important point here is the people that feel the pain of the poorly operating translation services are the people who refuse to upgrade. When the pain of poor performance outweighs the pain of upgrading the problem will resolve itself. __Jason ========================================================================== Jason Schiller (703)886.6648 Senior Internet Network Engineer fax:(703)886.0512 Public IP Global Network Engineering schiller at uu.net UUNET / Verizon jason.schiller at verizonbusiness.com The good news about having an email address that is twice as long is that it increases traffic on the Internet. On Sun, 6 Feb 2011, Lee Howard wrote: |Date: Sun, 06 Feb 2011 08:36:02 -0800 (PST) |From: Lee Howard |To: Benson Schliesser , Owen DeLong , | Ted Mittelstaedt |Cc: arin-ppml at arin.net |Subject: [arin-ppml] inevitability of NAT? | | | |> From: Benson Schliesser | |> |> Sadly, because we've waited too long to grow IPv6 penetration to |> the inflection point ("the moment that end users start accepting and |> using IPv6"), people will still need to deploy IPv4. Vendors will |> make money on NATs. And people will find ways to get addresses |> - one way or another. | |This is often asserted and generally accepted. Is it true? | |Nobody wants NAT: ISPs, content providers, law enforcement, |copyright holders, game console manufacturers, web advertisers, |home gateway vendors, and end users all have an interest in |avoiding NAT. Even NAT vendors are decorously sheepish in |selling their products. If everyone wants to avoid it, why are we |stuck with it? | |1. ISPs aren't ready for IPv6. This belief is rapidly being |overtaken by events--most ISPs will have broad IPv6 this year. |2. Content isn't ready for IPv6. This belief is rapidly being |overtaken by events. World IPv6 Day is a test-drive of content, |which should go a long way toward eliminating barriers. |3. Home gateways aren't ready for IPv6. This belief is |slowly being overtaken by events. All home gateway makers |are developing IPv6, and industry is doing better as telling them |what needs to be fixed. However, it may still be true that all |home gateways sold before ARIN runout have to be replaced. |4. Consumer electronics aren't ready for IPv6. This is widely |true, although more embedded OSs are becoming IPv6-capable. |Most web-capable devices will be capable of simple firmware |or OS updates. Untraditional networked devices (like |entertainment systems) are in trouble. | |How do we improve IPv6 uptake in these categories? | |If all of a household's devices speak IPv6, and the ISP provides |IPv6, and all of the content the household accesses is available |over IPv6 (including NAT64), that household no longer needs |IPv4. | |What would it take for the number of households in that state |to increase faster than new Internet activations? Think big-- |there are a lot of stakeholders whose interests align against |NAT. | |Lee | | | |_______________________________________________ |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 jbates at brightok.net Tue Feb 8 16:46:03 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Feb 2011 15:46:03 -0600 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> Message-ID: <4D51B99B.8000202@brightok.net> On 2/8/2011 3:11 PM, Jason Schiller wrote: > If all of this can > happen in the time period between IANA depletion and when the first > organizations are forced to build green field IPv6-only networks, then > dependance on NAT can be mostly avoided as a protocol translation > mechanism. > Actually, IANA would have already run out if not for there already being green field IPv6-only networks AND there already being huge LSN deployments (even using bogon space). > The important point here is the people that > feel the pain of the poorly operating translation services are the people > who refuse to upgrade. When the pain of poor performance outweighs the > pain of upgrading the problem will resolve itself. Right now we are stuck with partial pains either way. Now that market pressure is starting to exert itself, we see the core networks finally converging and deploying proper peering/pathing of IPv6 (still work to be done). As they complete, the eyeballs can turn up IPv6 without the problem of isolation deadness, which in turn means the content providers can use AAAA. At the same time, many providers will either offer dualstack with LSN deployments or NAT64. In both cases, the end to end model is shot beyond recovery and pushes applications towards IPv6. The good news is, core/provider based NAT should be short lived. It is too painful for anyone to want to keep it. Jack From alh-ietf at tndh.net Tue Feb 8 17:14:59 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 8 Feb 2011 14:14:59 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <4D51B99B.8000202@brightok.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n et> Message-ID: <22d101cbc7dd$a1f021c0$e5d06540$@net> FWIW: IANA would have run out 2 years ago if the RIRs had not changed their behavior of maintaining 2 years of projected need as a local pool. In other words, we could have focused global attention to the issue with time to do a dual-stack deployment, but people wanted to put off the inevitable as long as possible, so we are now stuck with the result. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Jack Bates > Sent: Tuesday, February 08, 2011 1:46 PM > To: Jason Schiller > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 > transition > > > > On 2/8/2011 3:11 PM, Jason Schiller wrote: > > If all of this can > > happen in the time period between IANA depletion and when the first > > organizations are forced to build green field IPv6-only networks, > then > > dependance on NAT can be mostly avoided as a protocol translation > > mechanism. > > > > Actually, IANA would have already run out if not for there already > being > green field IPv6-only networks AND there already being huge LSN > deployments (even using bogon space). > > > The important point here is the people that > > feel the pain of the poorly operating translation services are the > people > > who refuse to upgrade. When the pain of poor performance outweighs > the > > pain of upgrading the problem will resolve itself. > > Right now we are stuck with partial pains either way. Now that market > pressure is starting to exert itself, we see the core networks finally > converging and deploying proper peering/pathing of IPv6 (still work to > be done). As they complete, the eyeballs can turn up IPv6 without the > problem of isolation deadness, which in turn means the content > providers > can use AAAA. At the same time, many providers will either offer > dualstack with LSN deployments or NAT64. In both cases, the end to end > model is shot beyond recovery and pushes applications towards IPv6. > > The good news is, core/provider based NAT should be short lived. It is > too painful for anyone to want to keep it. > > Jack > _______________________________________________ > 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 Feb 8 17:21:30 2011 From: jcurran at arin.net (John Curran) Date: Tue, 8 Feb 2011 22:21:30 +0000 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <22d101cbc7dd$a1f021c0$e5d06540$@net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n> <22d101cbc7dd$a1f021c0$e5d06540$@net> Message-ID: <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> On Feb 8, 2011, at 6:14 PM, Tony Hain wrote: > FWIW: IANA would have run out 2 years ago if the RIRs had not changed their > behavior of maintaining 2 years of projected need as a local pool. In other > words, we could have focused global attention to the issue with time to do a > dual-stack deployment, but people wanted to put off the inevitable as long > as possible, so we are now stuck with the result. Tony - We've done lots of things to keep IPv4 running, but the RIRs have also been telling operators to deploy IPv6 in parallel and get ready for the day when there is no free pool left. When you say "we could have focused global attention to the issue", what exactly do you mean? /John John Curran President and CEO ARIN From jbates at brightok.net Tue Feb 8 17:31:36 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Feb 2011 16:31:36 -0600 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <22d101cbc7dd$a1f021c0$e5d06540$@net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.net> <22d101cbc7dd$a1f021c0$e5d06540$@net> Message-ID: <4D51C448.80601@brightok.net> On 2/8/2011 4:14 PM, Tony Hain wrote: > FWIW: IANA would have run out 2 years ago if the RIRs had not changed their > behavior of maintaining 2 years of projected need as a local pool. In other > words, we could have focused global attention to the issue with time to do a > dual-stack deployment, but people wanted to put off the inevitable as long > as possible, so we are now stuck with the result. > Yeah, the problem with reducing the need isn't so much when you run out, but how much you have at your disposal when you run out. It would have been better to hit the crunch with 2 year supplies to allow time for a more graceful cutover (as public companies require market pressure to actually cut, as their interests are in the stock holders). Jack From alh-ietf at tndh.net Tue Feb 8 17:38:33 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 8 Feb 2011 14:38:33 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> Message-ID: <22e101cbc7e0$ecaeee00$c60cca00$@net> If the IANA pool had run dry in 2009, the media attention we are seeing this past week would have already occurred, and CIOs would have already started efforts that are just now getting underway. The point is that dual-stack requires sufficient time to keep the old one working, so waiting until that is no longer an option as the starting point is guaranteed to create failure modes. There is no one place to assign blame here, and blame was never my intent. If I had not put out my graph in 2005, attention on the consumption rate from IANA might have been ignored until it was too late to have any significant effect on the date, because Geoff's graphs from that time said 2019. If the RIR's collectively had not changed the practice of when & how much to acquire from IANA at one time, the pool would have clearly burned down at least 2 years ago. The point is simply that an opportunity for a graceful transition was lost because high level attention to the issue was deferred to the point where it was too late. Tony > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Tuesday, February 08, 2011 2:22 PM > To: Tony Hain > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 > transition > > On Feb 8, 2011, at 6:14 PM, Tony Hain wrote: > > > FWIW: IANA would have run out 2 years ago if the RIRs had not changed > their > > behavior of maintaining 2 years of projected need as a local pool. In > other > > words, we could have focused global attention to the issue with time > to do a > > dual-stack deployment, but people wanted to put off the inevitable as > long > > as possible, so we are now stuck with the result. > > Tony - > > We've done lots of things to keep IPv4 running, but the RIRs have > also been telling operators to deploy IPv6 in parallel and get ready > for the day when there is no free pool left. > > When you say "we could have focused global attention to the issue", > what exactly do you mean? > > /John > > John Curran > President and CEO > ARIN From jcurran at istaff.org Tue Feb 8 18:06:42 2011 From: jcurran at istaff.org (John Curran) Date: Tue, 8 Feb 2011 19:06:42 -0400 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <22e101cbc7e0$ecaeee00$c60cca00$@net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> Message-ID: <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> On Feb 8, 2011, at 6:38 PM, Tony Hain wrote: > If the IANA pool had run dry in 2009, the media attention we are seeing this > past week would have already occurred, and CIOs would have already started > efforts that are just now getting underway. The point is that dual-stack > requires sufficient time to keep the old one working, so waiting until that > is no longer an option as the starting point is guaranteed to create failure > modes. > > There is no one place to assign blame here, and blame was never my intent. > If I had not put out my graph in 2005, attention on the consumption rate > from IANA might have been ignored until it was too late to have any > significant effect on the date, because Geoff's graphs from that time said > 2019. If the RIR's collectively had not changed the practice of when & how > much to acquire from IANA at one time, the pool would have clearly burned > down at least 2 years ago. > > The point is simply that an opportunity for a graceful transition was lost > because high level attention to the issue was deferred to the point where it > was too late. Hah. High-level attention doesn't drive deployment (except in a central- planning or heavily regulated environment), a successful business case drives deployment. The opportunity for graceful transition was lost when we both failed to include transparent interoperability and then further provided no additional functionality to drive deployment. Reference RFC 1669. /John From tedm at ipinc.net Tue Feb 8 20:21:49 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 08 Feb 2011 17:21:49 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> Message-ID: <4D51EC2D.5070708@ipinc.net> On 2/8/2011 3:06 PM, John Curran wrote: > On Feb 8, 2011, at 6:38 PM, Tony Hain wrote: > >> If the IANA pool had run dry in 2009, the media attention we are seeing this >> past week would have already occurred, and CIOs would have already started >> efforts that are just now getting underway. The point is that dual-stack >> requires sufficient time to keep the old one working, so waiting until that >> is no longer an option as the starting point is guaranteed to create failure >> modes. >> >> There is no one place to assign blame here, and blame was never my intent. >> If I had not put out my graph in 2005, attention on the consumption rate >> from IANA might have been ignored until it was too late to have any >> significant effect on the date, because Geoff's graphs from that time said >> 2019. If the RIR's collectively had not changed the practice of when& how >> much to acquire from IANA at one time, the pool would have clearly burned >> down at least 2 years ago. >> >> The point is simply that an opportunity for a graceful transition was lost >> because high level attention to the issue was deferred to the point where it >> was too late. > > Hah. High-level attention doesn't drive deployment (except in a central- > planning or heavily regulated environment), a successful business case > drives deployment. > No, I have to disagree with this statement. A successful business case only insures that your going to snare a sucker or two to make an investment. What drives deployment is customer demand. Sure, you can build a business case on customer demand - but the demand comes first, not the business case. > The opportunity for graceful transition was lost when we both failed > to include transparent interoperability and then further provided no > additional functionality to drive deployment. Reference RFC 1669. > I think you both must have extremely overinflated opinions of your own importance to assume that anything that you or anyone else would do would have motivated more than a fraction of people to bother with graceful transition any earlier than they did. ;-) The situation with IPv4->IPv6 transition is a game of chicken between competing ISPs. Anyone running an ISP knows perfectly well that the ISPs who are later into the IPv6 game will benefit from the burned fingers of the ones earlier into the game. So it is perfectly logical that most ISPs will wait until the very last minute to go to IPv6. They will wait till the day that they get the first call from a customer saying that they must have IPv6 or they will quit service, then they will think about moving on it. We see Comcast doing trials now, because they are so large that they are probably already getting those calls from at least a few customers. But it is going to take a while for the rest of them to follow along. How many customers out there are demanding IPv6? Not many. Only the ones who have no IPv4 at all are demanding it. For all the rest of them, IPv6 is still on the "nice to have" list. Ted > /John > > _______________________________________________ > 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 istaff.org Tue Feb 8 20:27:33 2011 From: jcurran at istaff.org (John Curran) Date: Tue, 8 Feb 2011 21:27:33 -0400 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <4D51EC2D.5070708@ipinc.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n> <"22d101 cbc7dd$a1f021c0$e5d06540$"@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <4D51EC2D.5070708@ip inc.net> Message-ID: <7156C0E5-C4D6-4E53-A180-14DF87DE7BB4@istaff.org> On Feb 8, 2011, at 9:21 PM, Ted Mittelstaedt wrote: > > I think you both must have extremely overinflated opinions of your own > importance to assume that anything that you or anyone else would do would have motivated more than a fraction of people to bother with > graceful transition any earlier than they did. ;-) Since we didn't give anyone a reason to deploy it any sooner than they absolutely had to, you are correct. If we actually had made it easier to deploy and provided some benefit, who knows... > The situation with IPv4->IPv6 transition is a game of chicken between competing ISPs. Anyone running an ISP knows perfectly well that the ISPs who are later into the IPv6 game will benefit from the burned fingers of the ones earlier into the game. So it is perfectly logical that most ISPs will wait until the very last minute to go to IPv6. > They will wait till the day that they get the first call from a customer saying that they must have IPv6 or they will quit service, then they will think about moving on it. We see Comcast doing trials now, because they are so large that they are probably already getting those calls from at least a few customers. But it is going to take a while for the rest of them to follow along. > > How many customers out there are demanding IPv6? Not many. Only the ones who have no IPv4 at all are demanding it. For all the rest of them, IPv6 is still on the "nice to have" list. Exactly my point. No customer demand equals no deployment till the last minute. /John From marka at isc.org Tue Feb 8 20:31:06 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 09 Feb 2011 12:31:06 +1100 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: Your message of "Tue, 08 Feb 2011 14:09:47 MDT." <014d01cbc7cc$226f81e0$674e85a0$@iname.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <014d01cb c7cc$226f81e0$674e85a0$@iname.com> Message-ID: <20110209013106.AAA5F9D6947@drugs.dv.isc.org> In message <014d01cbc7cc$226f81e0$674e85a0$@iname.com>, "Frank Bulk" writes: > Due to device (storage) limitations D-Link wasn't able to put a firewall in > many of its IPv-6 capable releases for its different hardware models, but > DIR-655 is supposed to support SPI. > > Frank Also IPv6 equipment should be capable of being put on the net without a seperate firewall. If it isn't then the product really isn't fit for the purpose it was designed for. Its been a hostile net for the entire time IPv6 has existed and that should have been factored into the design. A seperate firewall provides additional isolation but shouldn't be needed. Giving a device a ULA and not a public address if it doesn't need to talk to the world will give you as much protection as a NAT gives. Feature parity should also be there. I've got a Brother network printer that has accept/deny filters for IPv4 but not for IPv6. I don't know what they were thinking. IPv6 doesn't need accept/deny filters but IPv6 does? It would have been less than a days work to add them as they already have them working for IPv4. A bit more for testing and documentation. At least I can set the IPv6 address statically to a ULA. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From spiffnolee at yahoo.com Tue Feb 8 20:46:23 2011 From: spiffnolee at yahoo.com (Lee Howard) Date: Tue, 8 Feb 2011 17:46:23 -0800 (PST) Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> Message-ID: <381659.9803.qm@web63301.mail.re1.yahoo.com> Jason tried to refocus the thread. Forget the past fifteen years. It is past. John, Tony, you are saying, "There is no way to avoid extensive deployment of large-scale NAT44 in ISP networks"? I have a hard time accepting that, since nobody wants it. It runs contrary to everyone's interest. It is a temporary solution at best, so companies have to deal with both LSN and IPv6, instead of just IPv6. Is everyone really resigned to this? Lee ----- Original Message ---- > From: John Curran > To: Tony Hain > Cc: ARIN-PPML List > Sent: Tue, February 8, 2011 6:06:42 PM > Subject: Re: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition > > On Feb 8, 2011, at 6:38 PM, Tony Hain wrote: > > > If the IANA pool had run dry in 2009, the media attention we are seeing this > > past week would have already occurred, and CIOs would have already started > > efforts that are just now getting underway. The point is that dual-stack > > requires sufficient time to keep the old one working, so waiting until that > > is no longer an option as the starting point is guaranteed to create failure > > modes. > > > > There is no one place to assign blame here, and blame was never my intent. > > If I had not put out my graph in 2005, attention on the consumption rate > > from IANA might have been ignored until it was too late to have any > > significant effect on the date, because Geoff's graphs from that time said > > 2019. If the RIR's collectively had not changed the practice of when & how > > much to acquire from IANA at one time, the pool would have clearly burned > > down at least 2 years ago. > > > > The point is simply that an opportunity for a graceful transition was lost > > because high level attention to the issue was deferred to the point where it > > was too late. > > Hah. High-level attention doesn't drive deployment (except in a central- > planning or heavily regulated environment), a successful business case > drives deployment. > > The opportunity for graceful transition was lost when we both failed > to include transparent interoperability and then further provided no > additional functionality to drive deployment. Reference RFC 1669. > > /John > > _______________________________________________ > 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. > ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 From jcurran at arin.net Tue Feb 8 21:04:12 2011 From: jcurran at arin.net (John Curran) Date: Wed, 9 Feb 2011 02:04:12 +0000 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <381659.9803.qm@web63301.mail.re1.yahoo.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n> <"22d101 cbc7dd$a1f021c0$e5d06540$"@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> Message-ID: <8A371C8A-FB55-4590-809F-4D326E5F40A7@arin.net> On Feb 8, 2011, at 9:46 PM, Lee Howard wrote: > Jason tried to refocus the thread. > Forget the past fifteen years. It is past. > > John, Tony, you are saying, "There is no way to avoid extensive deployment of > large-scale NAT44 in ISP networks"? Lee - I believe that transition without NAT44 is still possible; I was simply refuting a theory that raising a louder alarm a few years back would have made a material difference in the present state. As Ted noted, IPv6 lacks customer demand so attempts to "push" it prior to actual depletion (and service provider demand) doesn't yield significant results. As usual, we'll try to overcome the inertia by activities which create a sense of demand (USG IPv6 mandate, World IPv6 Day, etc.) and hope that when combined with enlightened early adopters, specific market real demand (e.g. smartphones), and now actual depletion, we'll actually have enough takeup to build momentum. To the extent that there's a policy proposal that would help this along, this is the right mailing list to discuss. /John John Curran President and CEO ARIN From jbates at brightok.net Tue Feb 8 21:20:52 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Feb 2011 20:20:52 -0600 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <381659.9803.qm@web63301.mail.re1.yahoo.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> Message-ID: <4D51FA04.8080401@brightok.net> On 2/8/2011 7:46 PM, Lee Howard wrote: > Jason tried to refocus the thread. > Forget the past fifteen years. It is past. > > John, Tony, you are saying, "There is no way to avoid extensive deployment of > large-scale NAT44 in ISP networks"? > > I have a hard time accepting that, since nobody wants it. It runs contrary to > everyone's interest. It is a temporary solution at best, so companies have to > deal with both LSN and IPv6, instead of just IPv6. Is everyone really resigned > to this? There are already very large mobile networks (and I'm sure wireline) that already deploy LSN. If they hadn't, anyone want to guess how much sooner we'd have run out? LSN deployment is already past tense. It just hasn't hit critical deployment yet. But since LSN breaks 6to4 direct communications, let me subject you all to complete evil (because it was a fun thought exercise). DNS recursive servers relabel all 2002:: responses as ULA /16 (random 8bit). This forces the client 6to4 to send the packets to the anycast relay (you have 1 internal to each LSN area), the inbound 6to4 does NPTv6 to convert the source 2002:: to your prefix and passes the packet towards the public 6to4 relay (sits outside the LSN for talking to remote 2002:: networks). The ULA /16 is converted back to 2002::/16 via NPTv6 destined outbound. so.... AAAA 2002:1.1.1.1:: becomes fd8f:1.1.1.1:: client sends 2002:2.2.2.2:: to 6to4 anycast to reach fd8f:1.1.1.1:: internal 6to4 anycast relay converts it to 2600:0000:0202:: trying to reach 2002:1.1.1.1:: (nat source and destination appropriately) It routes to your public anycast relay and on to the destination. Coming back, it will have to find a remote relay and come back IPv6 to reach your internal relay, where it passes back through NAT to change the source and destination again. ULA was chosen for remotes as it's possible to use a /16 to handle a 1:1 for the entire Internet. That's not necessary on the inside LSN addressing as we know the addressing ourselves and can hard code appropriately. Jack (finding new ways to have broken 6to4 in broken IPv4 LSN environments) From owen at delong.com Tue Feb 8 21:28:18 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Feb 2011 18:28:18 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <4D51EC2D.5070708@ipinc.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <4D51EC2D.5070708@ip! inc.net> Message-ID: On Feb 8, 2011, at 5:21 PM, Ted Mittelstaedt wrote: > On 2/8/2011 3:06 PM, John Curran wrote: >> On Feb 8, 2011, at 6:38 PM, Tony Hain wrote: >> >>> If the IANA pool had run dry in 2009, the media attention we are seeing this >>> past week would have already occurred, and CIOs would have already started >>> efforts that are just now getting underway. The point is that dual-stack >>> requires sufficient time to keep the old one working, so waiting until that >>> is no longer an option as the starting point is guaranteed to create failure >>> modes. >>> >>> There is no one place to assign blame here, and blame was never my intent. >>> If I had not put out my graph in 2005, attention on the consumption rate >>> from IANA might have been ignored until it was too late to have any >>> significant effect on the date, because Geoff's graphs from that time said >>> 2019. If the RIR's collectively had not changed the practice of when& how >>> much to acquire from IANA at one time, the pool would have clearly burned >>> down at least 2 years ago. >>> >>> The point is simply that an opportunity for a graceful transition was lost >>> because high level attention to the issue was deferred to the point where it >>> was too late. >> >> Hah. High-level attention doesn't drive deployment (except in a central- >> planning or heavily regulated environment), a successful business case >> drives deployment. >> > > No, I have to disagree with this statement. A successful business case > only insures that your going to snare a sucker or two to make an investment. What drives deployment is customer demand. Sure, you can build a business case on customer demand - but the demand comes first, not the business case. > >> The opportunity for graceful transition was lost when we both failed >> to include transparent interoperability and then further provided no >> additional functionality to drive deployment. Reference RFC 1669. >> > > I think you both must have extremely overinflated opinions of your own > importance to assume that anything that you or anyone else would do would have motivated more than a fraction of people to bother with > graceful transition any earlier than they did. ;-) > That wasn't "we both" as in two people. That was "we" as in the collective community and "both failed to include transparent interoperability and then further provided no additional functionality"... The community failed in both actions, not two people failed in particular things. > The situation with IPv4->IPv6 transition is a game of chicken between competing ISPs. Anyone running an ISP knows perfectly well that the ISPs who are later into the IPv6 game will benefit from the burned fingers of the ones earlier into the game. So it is perfectly logical that most ISPs will wait until the very last minute to go to IPv6. > They will wait till the day that they get the first call from a customer saying that they must have IPv6 or they will quit service, then they will think about moving on it. We see Comcast doing trials now, because they are so large that they are probably already getting those calls from at least a few customers. But it is going to take a while for the rest of them to follow along. > I know at least one ISP that is doing quite well having been early to the game with IPv6. Did we burn our fingers a few times? Sure. Did our getting our fingers singed help others? Maybe. It helped us at least as much and we got the lessons first, so, it put us ahead. The last minute is upon us and may have passed. As to the customer calls, well, I'm not at liberty to disclose customer communications, but, I do know we win business because we have IPv6 and other contenders are losing customers to us on that basis. I think Comcast is doing trials, not because customers are demanding it (I know there was customer demand years ago), but, because they aren't spectacularly bad at math and they recognize that there's no way for them to continue to operate and grow an IPv4 network. Anyone who looks at the numbers and isn't spectacularly bad at math can see that an IPv4-only network is simply not sustainable and the practical days of dual-stack without IPv6-only hosts are limited. > How many customers out there are demanding IPv6? Not many. Only the ones who have no IPv4 at all are demanding it. For all the rest of them, IPv6 is still on the "nice to have" list. > Many, actually. Most of the demand we see for IPv6 is from people who also want IPv4. IPv6 came off the nice to have list and moved to the must have soon list over a year ago for most carriers I know. Now, it's starting to move to the don't even bother to submit a bid without IPv6 support list. Owen From owen at delong.com Tue Feb 8 21:32:45 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Feb 2011 18:32:45 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <20110209013106.AAA5F9D6947@drugs.dv.isc.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <014d01c! b c7cc$226f81e0$674e85a0$@iname.com> <20110209013106.AAA5F9D6947@drugs.dv.isc.org> Message-ID: On Feb 8, 2011, at 5:31 PM, Mark Andrews wrote: > > In message <014d01cbc7cc$226f81e0$674e85a0$@iname.com>, "Frank Bulk" writes: >> Due to device (storage) limitations D-Link wasn't able to put a firewall in >> many of its IPv-6 capable releases for its different hardware models, but >> DIR-655 is supposed to support SPI. >> >> Frank > > Also IPv6 equipment should be capable of being put on the net without > a seperate firewall. If it isn't then the product really isn't fit > for the purpose it was designed for. Its been a hostile net for > the entire time IPv6 has existed and that should have been factored > into the design. A seperate firewall provides additional isolation > but shouldn't be needed. > Agreed. > Giving a device a ULA and not a public address if it doesn't need to > talk to the world will give you as much protection as a NAT gives. > Which is to say nearly none at all, with the additional disadvantage that you can't actually talk to the outside world at all, unlike NAT which provides limited broken connectivity to the outside world. > Feature parity should also be there. I've got a Brother network > printer that has accept/deny filters for IPv4 but not for IPv6. I > don't know what they were thinking. IPv6 doesn't need accept/deny > filters but IPv6 does? It would have been less than a days work > to add them as they already have them working for IPv4. A bit more > for testing and documentation. At least I can set the IPv6 address > statically to a ULA. > I think you meant "...but IPv4 does?" I agree that many of the device manufacturers aren't getting it yet. I think there are lots of lessons to be learned in the CE and CPE worlds yet. Unfortunately, many of them are lessons network engineers mostly already learned from IPv4, but, for some reason, the manufacturers are choosing to ignore them in their first rounds of IPv6 devices. Two years ago, it was hard to find IPv6 devices at all. Now we have deficient IPv6 devices. Hopefully by the next round, we'll start to see capable IPv6 devices. At least the situation seems to be moving in the generally correct direction. Owen From frnkblk at iname.com Tue Feb 8 21:43:08 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 8 Feb 2011 20:43:08 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <20110209013106.AAA5F9D6947@drugs.dv.isc.org> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <014d01cb c7cc$226f81e0$674e85 a0$@iname.com> <20110209013106.AAA5F9D6947@drugs.dv.isc.org> Message-ID: <017201cbc803$15a6ef70$40f4ce50$@iname.com> Mark: The hardware came before the implementation of IPv6 support. They tried to fit in existing hardware, but it didn't work. Future hardware revisions of some models will include expanded storage, allowing for SPI support. I suspect that most consumer/SOHO router vendors are in the same predicament at D-Link. We can complain about the past, but that won't change anything. Better to make current and future purchasing decisions about what's out there -- I am. Frank -----Original Message----- From: Mark Andrews [mailto:marka at isc.org] Sent: Tuesday, February 08, 2011 7:31 PM To: frnkblk at iname.com Cc: 'Ted Mittelstaedt'; arin-ppml at arin.net Subject: Re: [arin-ppml] inevitability of NAT? In message <014d01cbc7cc$226f81e0$674e85a0$@iname.com>, "Frank Bulk" writes: > Due to device (storage) limitations D-Link wasn't able to put a firewall in > many of its IPv-6 capable releases for its different hardware models, but > DIR-655 is supposed to support SPI. > > Frank Also IPv6 equipment should be capable of being put on the net without a seperate firewall. If it isn't then the product really isn't fit for the purpose it was designed for. Its been a hostile net for the entire time IPv6 has existed and that should have been factored into the design. A seperate firewall provides additional isolation but shouldn't be needed. Giving a device a ULA and not a public address if it doesn't need to talk to the world will give you as much protection as a NAT gives. Feature parity should also be there. I've got a Brother network printer that has accept/deny filters for IPv4 but not for IPv6. I don't know what they were thinking. IPv6 doesn't need accept/deny filters but IPv6 does? It would have been less than a days work to add them as they already have them working for IPv4. A bit more for testing and documentation. At least I can set the IPv6 address statically to a ULA. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Tue Feb 8 21:44:31 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 09 Feb 2011 13:44:31 +1100 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: Your message of "Tue, 08 Feb 2011 20:20:52 MDT." <4D51FA04.8080401@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D51FA04.8080401@brightok.net> Message-ID: <20110209024431.4FA8F9D79B7@drugs.dv.isc.org> In message <4D51FA04.8080401 at brightok.net>, Jack Bates writes: > On 2/8/2011 7:46 PM, Lee Howard wrote: > > Jason tried to refocus the thread. > > Forget the past fifteen years. It is past. > > > > John, Tony, you are saying, "There is no way to avoid extensive deployment > of > > large-scale NAT44 in ISP networks"? > > > > I have a hard time accepting that, since nobody wants it. It runs contrary > to > > everyone's interest. It is a temporary solution at best, so companies have > to > > deal with both LSN and IPv6, instead of just IPv6. Is everyone really resi > gned > > to this? > > There are already very large mobile networks (and I'm sure wireline) > that already deploy LSN. If they hadn't, anyone want to guess how much > sooner we'd have run out? LSN deployment is already past tense. It just > hasn't hit critical deployment yet. > > But since LSN breaks 6to4 direct communications, let me subject you all > to complete evil (because it was a fun thought exercise). > > DNS recursive servers relabel all 2002:: responses as ULA /16 (random > 8bit). This forces the client 6to4 to send the packets to the anycast > relay (you have 1 internal to each LSN area), the inbound 6to4 does > NPTv6 to convert the source 2002:: to your prefix and passes the packet > towards the public 6to4 relay (sits outside the LSN for talking to > remote 2002:: networks). The ULA /16 is converted back to 2002::/16 via > NPTv6 destined outbound. > > so.... > > AAAA 2002:1.1.1.1:: becomes fd8f:1.1.1.1:: > > client sends 2002:2.2.2.2:: to 6to4 anycast to reach fd8f:1.1.1.1:: > > internal 6to4 anycast relay converts it to 2600:0000:0202:: trying to > reach 2002:1.1.1.1:: (nat source and destination appropriately) > > It routes to your public anycast relay and on to the destination. Coming > back, it will have to find a remote relay and come back IPv6 to reach > your internal relay, where it passes back through NAT to change the > source and destination again. > > ULA was chosen for remotes as it's possible to use a /16 to handle a 1:1 > for the entire Internet. That's not necessary on the inside LSN > addressing as we know the addressing ourselves and can hard code > appropriately. > > Jack (finding new ways to have broken 6to4 in broken IPv4 LSN environments) Is it worth trying to deploy RFC 5969? That would be cleaner. > _______________________________________________ > 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Tue Feb 8 21:58:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Feb 2011 18:58:39 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <8A371C8A-FB55-4590-809F-4D326E5F40A7@arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.! n> <"22d101 cbc7dd$a1f021c0$e5d06540$"@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <8A371C8A-FB55-4590-809F-4D326E5F40A7@arin.net> Message-ID: On Feb 8, 2011, at 6:04 PM, John Curran wrote: > On Feb 8, 2011, at 9:46 PM, Lee Howard wrote: > >> Jason tried to refocus the thread. >> Forget the past fifteen years. It is past. >> >> John, Tony, you are saying, "There is no way to avoid extensive deployment of >> large-scale NAT44 in ISP networks"? > > Lee - I believe that transition without NAT44 is still possible; I was simply > refuting a theory that raising a louder alarm a few years back would have made > a material difference in the present state. As Ted noted, IPv6 lacks customer > demand so attempts to "push" it prior to actual depletion (and service provider > demand) doesn't yield significant results. > Transition without NAT44 is not possible, NAT44 is already widely deployed. Transition without NAT444 is unlikely due to the very large number of completely unprepared consumer electronics devices and vendors out there. > As usual, we'll try to overcome the inertia by activities which create a sense > of demand (USG IPv6 mandate, World IPv6 Day, etc.) and hope that when combined > with enlightened early adopters, specific market real demand (e.g. smartphones), > and now actual depletion, we'll actually have enough takeup to build momentum. > I hope. > To the extent that there's a policy proposal that would help this along, this > is the right mailing list to discuss. > I wish. I think we've done all that can be done in terms of policy in this regard, but, I welcome any ideas others may have. Owen From jbates at brightok.net Tue Feb 8 22:04:14 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Feb 2011 21:04:14 -0600 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <20110209024431.4FA8F9D79B7@drugs.dv.isc.org> References: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D51FA04.8080401@brightok.net> <20110209024431.4FA8F9D79B7@drugs.dv.isc.org> Message-ID: <4D52042E.3090709@brightok.net> On 2/8/2011 8:44 PM, Mark Andrews wrote: > Is it worth trying to deploy RFC 5969? That would be cleaner. I completely agree. of course, you actually have to deploy 6rd. 6to4 is already deployed. It was just a nice exercise of how to make 6to4 work somewhat in LSN environments. I wouldn't use it myself. Jack From joelja at bogus.com Tue Feb 8 22:19:00 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 08 Feb 2011 19:19:00 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <381659.9803.qm@web63301.mail.re1.yahoo.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> Message-ID: <4D5207A4.8060902@bogus.com> On 2/8/11 5:46 PM, Lee Howard wrote: > Jason tried to refocus the thread. > Forget the past fifteen years. It is past. > > John, Tony, you are saying, "There is no way to avoid extensive deployment of > large-scale NAT44 in ISP networks"? > > I have a hard time accepting that, since nobody wants it. It runs contrary to > everyone's interest. It is a temporary solution at best, so companies have to > deal with both LSN and IPv6, instead of just IPv6. Is everyone really resigned > to this? the second you need one ip address you don't have and can't obtain you've got to be ready. one suspects the need for margin of error means you have to be ready rather before that. if new v4 assignments were part of the engine of subscriber growth then you're stuck... given that wireless carrriers are there already it's not really a question of maybe. v6 only deployments will occur but that's not per-say a solution. > Lee > > > ----- Original Message ---- >> From: John Curran >> To: Tony Hain >> Cc: ARIN-PPML List >> Sent: Tue, February 8, 2011 6:06:42 PM >> Subject: Re: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition >> >> On Feb 8, 2011, at 6:38 PM, Tony Hain wrote: >> >>> If the IANA pool had run dry in 2009, the media attention we are seeing > this >>> past week would have already occurred, and CIOs would have already started >>> efforts that are just now getting underway. The point is that dual-stack >>> requires sufficient time to keep the old one working, so waiting until that >>> is no longer an option as the starting point is guaranteed to create > failure >>> modes. >>> >>> There is no one place to assign blame here, and blame was never my intent. >>> If I had not put out my graph in 2005, attention on the consumption rate >>> from IANA might have been ignored until it was too late to have any >>> significant effect on the date, because Geoff's graphs from that time said >>> 2019. If the RIR's collectively had not changed the practice of when & how >>> much to acquire from IANA at one time, the pool would have clearly burned >>> down at least 2 years ago. >>> >>> The point is simply that an opportunity for a graceful transition was lost >>> because high level attention to the issue was deferred to the point where > it >>> was too late. >> >> Hah. High-level attention doesn't drive deployment (except in a central- >> planning or heavily regulated environment), a successful business case >> drives deployment. >> >> The opportunity for graceful transition was lost when we both failed >> to include transparent interoperability and then further provided no >> additional functionality to drive deployment. Reference RFC 1669. >> >> /John >> >> _______________________________________________ >> 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. >> > > > > ____________________________________________________________________________________ > Finding fabulous fares is fun. > Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. > http://farechase.yahoo.com/promo-generic-14795097 > _______________________________________________ > 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 marka at isc.org Tue Feb 8 22:28:36 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 09 Feb 2011 14:28:36 +1100 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: Your message of "Tue, 08 Feb 2011 20:43:08 MDT." <017201cbc803$15a6ef70$40f4ce50$@iname.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <014d01cb c7cc$226f81e0$674e85 a0$@iname.com> <20110209013106.AAA5F9D6947@drugs.dv.isc.org> <017201cbc803$15a6ef70$40f4ce50$@iname.com> Message-ID: <20110209032836.D9A359D7ACE@drugs.dv.isc.org> In message <017201cbc803$15a6ef70$40f4ce50$@iname.com>, "Frank Bulk" writes: > Mark: > > The hardware came before the implementation of IPv6 support. They tried to > fit in existing hardware, but it didn't work. Future hardware revisions of > some models will include expanded storage, allowing for SPI support. I understand that with small routers and I wasn't complaining. I'm just glad that products are starting to appear. > I suspect that most consumer/SOHO router vendors are in the same predicament > at D-Link. > > We can complain about the past, but that won't change anything. Better to > make current and future purchasing decisions about what's out there -- I am. > > Frank -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Tue Feb 8 22:37:38 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Feb 2011 21:37:38 -0600 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <4D5207A4.8060902@bogus.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D5207A4.8060902@bogus.com> Message-ID: <4D520C02.2000709@brightok.net> On 2/8/2011 9:19 PM, Joel Jaeggli wrote: > > given that wireless carrriers are there already it's not really a > question of maybe. v6 only deployments will occur but that's not per-say > a solution. > Even v6 only deployments will need NAT64 or 4rd (not really v6 only) until market demand on IPv4 diminishes enough for us to tell the rest to get over it and buy IPv6 gear or create their own 4 over 6 tunnels. Unlike IPv6, where often you may not have seen an extra charge (some did), you will see increased fees if you want IPv4 on the IPv6 internet before it's all over. This will be the ISP exerting reverse pressure on the market (we switched to IPv6, now you can pay us if you want to use that legacy junk which increases our support costs). That's supposing we don't just get fed up with it and send it to the nearest /dev/null (but hey! We can charge for supporting that old stuff!) Jack From marka at isc.org Tue Feb 8 22:50:06 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 09 Feb 2011 14:50:06 +1100 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: Your message of "Tue, 08 Feb 2011 21:37:38 MDT." <4D520C02.2000709@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D5207A4.8060902@bogus.com> <4D520C02. 2000709@brightok.net> Message-ID: <20110209035006.E63229D7E46@drugs.dv.isc.org> In message <4D520C02.2000709 at brightok.net>, Jack Bates writes: > On 2/8/2011 9:19 PM, Joel Jaeggli wrote: > > > > given that wireless carrriers are there already it's not really a > > question of maybe. v6 only deployments will occur but that's not per-say > > a solution. > > > > Even v6 only deployments will need NAT64 or 4rd (not really v6 only) > until market demand on IPv4 diminishes enough for us to tell the rest to > get over it and buy IPv6 gear or create their own 4 over 6 tunnels. > Unlike IPv6, where often you may not have seen an extra charge (some > did), you will see increased fees if you want IPv4 on the IPv6 internet > before it's all over. This will be the ISP exerting reverse pressure on > the market (we switched to IPv6, now you can pay us if you want to use > that legacy junk which increases our support costs). That's supposing we > don't just get fed up with it and send it to the nearest /dev/null (but > hey! We can charge for supporting that old stuff!) If ISPs had been informing their customers about IPv6 10 years ago then charging extra for IPv4 over IPv6 would have been reasonable. As it is none of them did so I would expect government consumer affairs departments to actually come down hard on ISPs that attempt something like that. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jbates at brightok.net Tue Feb 8 23:03:03 2011 From: jbates at brightok.net (Jack Bates) Date: Tue, 08 Feb 2011 22:03:03 -0600 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <20110209035006.E63229D7E46@drugs.dv.isc.org> References: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D5207A4.8060902@bogus.com> <4D520C02. 2000709@brightok.net> <20110209035006.E63229D7E46@drugs.dv.isc.o! rg> Message-ID: <4D5211F7.7040608@brightok.net> On 2/8/2011 9:50 PM, Mark Andrews wrote: > > If ISPs had been informing their customers about IPv6 10 years ago > then charging extra for IPv4 over IPv6 would have been reasonable. > As it is none of them did so I would expect government consumer > affairs departments to actually come down hard on ISPs that attempt > something like that. > Except many often charge for static IP addressing now. To rule any non-LSN or NAT64 as static assignment and charge extra wouldn't be much different. It won't be immediate, but I'd be surprised if in 2 years ISPs aren't ready to kill IPv4 and start pushing it out the door with rate increases. Let's be honest, the IPv4 network is going to suck. We cannot maintain even the limited hack of end to end connectivity we have now with IPv4 in the long run. The IPv6 network will do its job and in some ways be even better (especially after it's patched up the way operators want). User won't want to use the IPv4 network. Content providers won't want to use the IPv4 network. That old IPv4 PS3 will have problems with hosted games (which are p2p) on the IPv4 network. Supporting old Windows 95/98 boxes (which aren't even supported by M$ anymore) and other obsolete equipment isn't the ISP's job, and the government isn't going to tell them otherwise (not the same government that forced a reclaim on airwaves and forced people into digital tv world, or the same government(s) that wants to ban incandescent light bulbs and force people to buy new fixtures that can hold the alternatives). Jack From joelja at bogus.com Tue Feb 8 23:18:58 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 08 Feb 2011 20:18:58 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <20110209035006.E63229D7E46@drugs.dv.isc.org> References: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D5207A4.8060902@bogus.com> <4D520C02. 2000709@brightok.net> <20110209035006.E63229D7E46@drugs.dv.isc.o! rg> Message-ID: <4D5215B2.8050409@bogus.com> On 2/8/11 7:50 PM, Mark Andrews wrote: > If ISPs had been informing their customers about IPv6 10 years ago > then charging extra for IPv4 over IPv6 would have been reasonable. > As it is none of them did so I would expect government consumer > affairs departments to actually come down hard on ISPs that attempt > something like that. The human capacity for procrastination knows basically no bounds. ten years before that people with vivid imaginations were working on a solution to the problem. a decade before that more or less the question of exhaustion first came up. I've got six years worth of time spent as undergrad to demonstrate my comparable effectiveness at work avoidance, and my time machine is faulty so I prefer to focus on the future. ;) > Mark From frnkblk at iname.com Tue Feb 8 23:59:04 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 8 Feb 2011 22:59:04 -0600 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <4D5211F7.7040608@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D5207A4.8060902@bogus.com> <4D520C02. 2000709@brightok.net> <20110209035006.E63229D7E46@drugs.dv.isc.o! rg> <4D5211F7.7040608 @brightok.net> Message-ID: <017801cbc816$1373c120$3a5b4360$@iname.com> I can see it now on the bill: IPv4 address maintenance . . . . . . . . . $ 1.00 Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jack Bates Sent: Tuesday, February 08, 2011 10:03 PM To: Mark Andrews Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition On 2/8/2011 9:50 PM, Mark Andrews wrote: > > If ISPs had been informing their customers about IPv6 10 years ago > then charging extra for IPv4 over IPv6 would have been reasonable. > As it is none of them did so I would expect government consumer > affairs departments to actually come down hard on ISPs that attempt > something like that. > Except many often charge for static IP addressing now. To rule any non-LSN or NAT64 as static assignment and charge extra wouldn't be much different. It won't be immediate, but I'd be surprised if in 2 years ISPs aren't ready to kill IPv4 and start pushing it out the door with rate increases. Let's be honest, the IPv4 network is going to suck. We cannot maintain even the limited hack of end to end connectivity we have now with IPv4 in the long run. The IPv6 network will do its job and in some ways be even better (especially after it's patched up the way operators want). User won't want to use the IPv4 network. Content providers won't want to use the IPv4 network. That old IPv4 PS3 will have problems with hosted games (which are p2p) on the IPv4 network. Supporting old Windows 95/98 boxes (which aren't even supported by M$ anymore) and other obsolete equipment isn't the ISP's job, and the government isn't going to tell them otherwise (not the same government that forced a reclaim on airwaves and forced people into digital tv world, or the same government(s) that wants to ban incandescent light bulbs and force people to buy new fixtures that can hold the alternatives). Jack _______________________________________________ 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 spiffnolee at yahoo.com Wed Feb 9 07:40:05 2011 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 9 Feb 2011 04:40:05 -0800 (PST) Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <20110209035006.E63229D7E46@drugs.dv.isc.org> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D5207A4.8060902@bogus.com> <4D520C02. 2000709@brightok.net> <20110209035006.E63229D7E46@drugs.dv.isc.org> Message-ID: <780286.93766.qm@web63306.mail.re1.yahoo.com> > > did), you will see increased fees if you want IPv4 on the IPv6 internet > > If ISPs had been informing their customers about IPv6 10 years ago > then charging extra for IPv4 over IPv6 would have been reasonable. Discussion of pricing schemes veers into ugly legal territory (anti-trust). Let's go in a different direction. IANAL, Lee From spiffnolee at yahoo.com Wed Feb 9 07:51:21 2011 From: spiffnolee at yahoo.com (Lee Howard) Date: Wed, 9 Feb 2011 04:51:21 -0800 (PST) Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <4D5211F7.7040608@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> <4D5207A4.8060902@bogus.com> <4D520C02. 2000709@brightok.net> <20110209035006.E63229D7E46@drugs.dv.isc.o! rg> <4D5211F7.7040608@brightok.net> Message-ID: <634253.95490.qm@web63301.mail.re1.yahoo.com> > To: Mark Andrews > > Let's be honest, the IPv4 network is going to suck. We cannot maintain even >the > > limited hack of end to end connectivity we have now with IPv4 in the long run. > > The IPv6 network will do its job and in some ways be even better (especially > after it's patched up the way operators want). User won't want to use the IPv4 > > network. Content providers won't want to use the IPv4 network. That old IPv4 > PS3 will have problems with hosted games (which are p2p) on the IPv4 network. That's exactly what I'm thinking. So why do ISPs have to spend loads of money to provided degraded service? Why don't ISPs *not* do large-scale NAT44 (which is equivalent to NAT444)? I can think of a few reasons: 1. Fear of losing customers to the competition. 2. A moral position that providing connectivity is an ISP's duty. 3. Fear of blame from consumer electronics vendors who aren't ready. 4. Fear of recriminations from government/consumers' groups Is there any reason we can't collectively deprecate NAT444, and decide not to do it? If ISOC can coordinate World IPv6 Day so one major website doesn't lose eyeballs to another when they dual-stack, isn't "No LSN!" the same thing? If this intent, with Tony and Geoff's RIR runout projections, are clear to the consumer electronics industry, where's the harm? The requirement to update existing equipment belongs to the people who made is deficient, and the consumer who bought it. Given the legal complications LSN introduces, I don't think government will go after ISPs. Especially if they're involved in the decision and communication. > Supporting old Windows 95/98 boxes (which aren't even supported by M$ > anymore) and other obsolete equipment isn't the ISP's job, and the government > isn't going to tell them otherwise Exactly. Lee PS: John, I take your point. This doesn't seem to be heading toward an ARIN policy proposal, so I'll take it over to NANOG. From khelms at zcorum.com Wed Feb 9 10:27:10 2011 From: khelms at zcorum.com (Scott Helms) Date: Wed, 09 Feb 2011 10:27:10 -0500 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: <381659.9803.qm@web63301.mail.re1.yahoo.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <381659.9803.qm@web63301.mail.re1.yahoo.com> Message-ID: <4D52B24E.9080301@zcorum.com> On 2/8/2011 8:46 PM, Lee Howard wrote: > John, Tony, you are saying, "There is no way to avoid extensive deployment of > large-scale NAT44 in ISP networks"? > > I have a hard time accepting that, since nobody wants it. It runs contrary to > everyone's interest. It is a temporary solution at best, so companies have to > deal with both LSN and IPv6, instead of just IPv6. Is everyone really resigned > to this? > This isn't universal, but there will be significant amounts of NAT(of various flavors) in ISP networks, especially telco networks. There are as many issues with infrastructure gear as there are with customer side equipment and largely for the exact same reasons (economics). This is especially true of telco based networks since in many cases the equipment has been in place for a decade or so and has been EoL'ed for >=5 years. This _shouldn't_ be a problem but is because someone involved in earlier DSLAM design decided that any IPv6 traffic must be from bogons and decided to drop any frames with IPv6 (0x86DD) in the EtherType field. Whoever first made the decision at this point doesn't matter because that was copied by several different manufacturers so now there a ton of DSLAMs (and I suspect early PON FTTx gear) that simply won't pass layer 2 frames carrying IPv6 traffic unless its tunneled over 4. Whats worse because the gear is so old there isn't a firmware/software fix available and in most cases simply won't be. This doesn't include problems with DSL modems, most of which are routers, which can't be upgraded remotely (if there is an upgrade) unless the telco was very forward thinking and implemented TR-069. This also doesn't include the fact that some of the most common lines of PPoE/oA termination devices (Redback SMS line and AFAIK Nortel Shasta lines) don't have an upgrade path. Redback (now owned by Ericsson) gleefully points providers to their new line of gear (SmartEdge line) if they want IPv6 functionality. The equipment cost for one _small_ telco, ~3,000 DSL ports, can easily exceed $1.75 million and that doesn't count the time and expense (and customer disruption) to actually replace the gear. If they have to replace modems on a large scale the cost will be at least triple that. That means as the squeeze for IPv4 addresses starts to bite the cost for doing CGNAT is far less than trying to actually fix the problem and the vendors at least are claiming that most end users won't notice. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From heather.skanks at gmail.com Wed Feb 9 12:24:30 2011 From: heather.skanks at gmail.com (Heather Schiller) Date: Wed, 9 Feb 2011 12:24:30 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: how about: ".... legacy resources returned to ARIN will be made available for distribution in the ARIN region." --heather On Mon, Jan 31, 2011 at 3:10 PM, cja at daydream.com wrote: > Let's be clear this is not "ARIN speak". ?This is RIR speak. ? ?If you have > a better alternative to distinguish between addresses that are given out to > be further assigned to customers as opposed to blocks given that are > intended not to be further delegated then feel free to make a suggestion. > Most of us would love a workable alternative. > Thanks! > > ----Cathy > > On Mon, Jan 31, 2011 at 12:54 PM, William Herrin wrote: >> >> On Mon, Jan 31, 2011 at 12:02 PM, cja at daydream.com >> wrote: >> > On Mon, Jan 31, 2011 at 9:58 AM, Martin Hannigan >> > wrote: >> >> Do you think that this will suffice? >> >> >> >> "Upon expiration of the hold period and in the absence of a Global >> >> Policy or Globally Coordinated Policy directing otherwise, legacy >> >> resources returned to ARIN will be made available for allocation." >> > >> > I think it should say "made available for allocation or assignment" >> >> Right. Allocation and assignment are loaded words in ARIN-speak. If >> you specify the one but not the other in policy, you restrict the >> usage of those addresses. You could also say something like "made >> available for registration," without using either of the two loaded >> words. >> >> Regards, >> Bill Herrin >> >> p.s. Yes, I'm sad to report there is in fact an ARIN-speak -- words >> and phrases with special meanings overloaded on the plain English, >> meanings that tend to obstruct outsiders' understanding both in the >> debate and the policy documents. This is unfortunate since it harms >> ARIN's accessibility to the public, but that's a crusade for another >> day. >> >> -- >> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From hannigan at gmail.com Wed Feb 9 12:32:41 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 9 Feb 2011 12:32:41 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: Heather, Is this language too specific considering pending transfer proposal(s) or do you think transfer is not relevant? I think the latter myself, but interested in your thought on this. Best, Marty On 2/9/11, Heather Schiller wrote: > how about: > > ".... legacy resources returned to ARIN will be made available for > distribution in the ARIN region." > > --heather > > On Mon, Jan 31, 2011 at 3:10 PM, cja at daydream.com > wrote: >> Let's be clear this is not "ARIN speak". ?This is RIR speak. ? ?If you >> have >> a better alternative to distinguish between addresses that are given out >> to >> be further assigned to customers as opposed to blocks given that are >> intended not to be further delegated then feel free to make a suggestion. >> Most of us would love a workable alternative. >> Thanks! >> >> ----Cathy >> >> On Mon, Jan 31, 2011 at 12:54 PM, William Herrin wrote: >>> >>> On Mon, Jan 31, 2011 at 12:02 PM, cja at daydream.com >>> wrote: >>> > On Mon, Jan 31, 2011 at 9:58 AM, Martin Hannigan >>> > wrote: >>> >> Do you think that this will suffice? >>> >> >>> >> "Upon expiration of the hold period and in the absence of a Global >>> >> Policy or Globally Coordinated Policy directing otherwise, legacy >>> >> resources returned to ARIN will be made available for allocation." >>> > >>> > I think it should say "made available for allocation or assignment" >>> >>> Right. Allocation and assignment are loaded words in ARIN-speak. If >>> you specify the one but not the other in policy, you restrict the >>> usage of those addresses. You could also say something like "made >>> available for registration," without using either of the two loaded >>> words. >>> >>> Regards, >>> Bill Herrin >>> >>> p.s. Yes, I'm sad to report there is in fact an ARIN-speak -- words >>> and phrases with special meanings overloaded on the plain English, >>> meanings that tend to obstruct outsiders' understanding both in the >>> debate and the policy documents. This is unfortunate since it harms >>> ARIN's accessibility to the public, but that's a crusade for another >>> day. >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > 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 leslien at arin.net Wed Feb 9 12:52:13 2011 From: leslien at arin.net (Leslie Nobile) Date: Wed, 9 Feb 2011 17:52:13 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: Message-ID: Hi Marty- In response to your recent inquiry about IPv6 requests to ARIN, staff has produced the following data. Total IPv6 Requests January 2009 through January 2011: ISP requests received ? 748 ISP requests approved - 712 or 96% Generally speaking, for ISPs, there are almost no denials for IPv6 address requests. Anything not approved was likely an end-user who put in an ISP request and needed to resubmit as an end-user. In fact, during this past year, there have been no denials to ISPs/LIRs under the IPv6 allocation policy which seems to indicate that the current policy has been very effective. End-user requests received - 464 End-user requests approved ? 403 or 87% Almost all of the denied end-user requests were to small single-homed networks who were unable to meet any one of the policy criteria: they either (1) weren?t using enough IPv4 address space to qualify under current IPv4 policy, (2) had no legacy space, or (3) didn?t qualify as a community network. I hope this information helps! Regards, Leslie Leslie Nobile, Director, Registration Services American Registry for Internet Numbers On 2/6/11 6:48 PM, "Martin Hannigan" wrote: > Staff et. Al, > > Can we get a recap of activity around resource requests for IPv6 and a > characterization of refusals, if any? If there are none, it would be > interesting to hear a general conclusion as to why. I'm interested to > see if there are any holes here considering all of the work that has > been done to ease access to v6 for transition. > > Best, and go Steelers! > > -M< > _______________________________________________ > 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 alh-ietf at tndh.net Wed Feb 9 13:49:34 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 9 Feb 2011 10:49:34 -0800 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: Message-ID: <24c001cbc88a$1a47db70$4ed79250$@net> Leslie, What is the percentage of ISPs that were denied a reasonable sized block vs. being forced into a /32 because that is the fad? I define 'reasonable' in this context as - existing customer base @ something larger than a /64 per customer -. The point is I am still hearing people say they can't deploy more than a /64 to their customers because that won't fit in the /32 they got from ARIN. I am also hearing that when orgs walk in with documentation showing multiple downstream ISPs they are not getting sufficient space to assign each of those ISPs even a /32, let alone what it would take to meet the above definition of reasonable. Essentially the question becomes 'why doesn't ARIN have any service provider IPv6 allocations of order /20?' The implication is an overly strict interpretation of the policy... Tony From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Leslie Nobile Sent: Wednesday, February 09, 2011 9:52 AM To: Martin Hannigan; arin-ppml at arin.net Subject: Re: [arin-ppml] Application requests for IPv6? Hi Marty- In response to your recent inquiry about IPv6 requests to ARIN, staff has produced the following data. Total IPv6 Requests January 2009 through January 2011: ISP requests received - 748 ISP requests approved - 712 or 96% Generally speaking, for ISPs, there are almost no denials for IPv6 address requests. Anything not approved was likely an end-user who put in an ISP request and needed to resubmit as an end-user. In fact, during this past year, there have been no denials to ISPs/LIRs under the IPv6 allocation policy which seems to indicate that the current policy has been very effective. End-user requests received - 464 End-user requests approved - 403 or 87% Almost all of the denied end-user requests were to small single-homed networks who were unable to meet any one of the policy criteria: they either (1) weren't using enough IPv4 address space to qualify under current IPv4 policy, (2) had no legacy space, or (3) didn't qualify as a community network. I hope this information helps! Regards, Leslie Leslie Nobile, Director, Registration Services American Registry for Internet Numbers On 2/6/11 6:48 PM, "Martin Hannigan" wrote: > Staff et. Al, > > Can we get a recap of activity around resource requests for IPv6 and a > characterization of refusals, if any? If there are none, it would be > interesting to hear a general conclusion as to why. I'm interested to > see if there are any holes here considering all of the work that has > been done to ease access to v6 for transition. > > Best, and go Steelers! > > -M< > _______________________________________________ > 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 jcurran at arin.net Wed Feb 9 14:17:02 2011 From: jcurran at arin.net (John Curran) Date: Wed, 9 Feb 2011 19:17:02 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: <24c001cbc88a$1a47db70$4ed79250$@net> References: <24c001cbc88a$1a47db70$4ed79250$@net> Message-ID: <52B39CF2-113A-48EE-9A14-4A92EF67E5C7@corp.arin.net> On Feb 9, 2011, at 2:49 PM, Tony Hain wrote: Leslie, What is the percentage of ISPs that were denied a reasonable sized block vs. being forced into a /32 because that is the fad? I define ?reasonable? in this context as - existing customer base @ something larger than a /64 per customer -. The point is I am still hearing people say they can?t deploy more than a /64 to their customers because that won?t fit in the /32 they got from ARIN. I am also hearing that when orgs walk in with documentation showing multiple downstream ISPs they are not getting sufficient space to assign each of those ISPs even a /32, let alone what it would take to meet the above definition of reasonable. Essentially the question becomes ?why doesn?t ARIN have any service provider IPv6 allocations of order /20?? The implication is an overly strict interpretation of the policy... Tony - To my knowledge, ARIN hasn't denied any ISPs a reasonable-sized IPv6 block, if you consider it reasonable to issue according to adopted policy. You should make sure that folks coming to you are aware of the 2011-3 draft policy and express support for it on the PPML mailing list (and during the PPM if at all possible), as it makes changes to the allocation policy which would likely address such concerns. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles at office.tcsn.net Wed Feb 9 14:47:31 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 09 Feb 2011 11:47:31 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> Message-ID: <4D52EF53.103@office.tcsn.net> On 2/7/11 1:21 AM, Owen DeLong wrote: > > On Feb 6, 2011, at 10:47 PM, Ted Mittelstaedt wrote: > >> On 2/6/2011 8:36 AM, Lee Howard wrote: >> >> and end users all have an interest in >>> avoiding NAT. >> >> wrong. End users absolutely need inexpensive - and I'm talking $60 and >> under - stateful packet inspection hardware firewalls. >> > Your statement is absolutely correct except for the first word. > Perhaps this is just semantics (and perhaps I'm just in a cynical mood), but I agree with Ted here. "wrong" is the correct term simply because "interest" is the wrong term. End Users all do not have an interest in avoiding NAT. Most end users don't even know what it really does. As long as their stuff works and they have the illusion of security and privacy, they are happy. (or at least less malcontented) End users will benefit from IPv6 with stateful inspection but they have more interest in streaming the superbowl while being contently assured that their MP3 and porn folders are 'safe' from prying eyes. Most end users will have to be coddled or "ninja'd" into IPv6, else the ever present threat of "going to the other provider". Of course at the other provider, they will end up on IPv6 anyways because they'll accept having to buy a new CPE with new service far more often than they will to fix a problem they don't even perceive. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From heather.skanks at gmail.com Wed Feb 9 15:10:01 2011 From: heather.skanks at gmail.com (Heather Schiller) Date: Wed, 9 Feb 2011 15:10:01 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: I had the same thought and looked at 2011-1 before I suggested the text. The pending global transfer proposal text appears to be registrant to registrant. So, if one returns legacy space to ARIN under prop 131, they aren't attempting to transfer it to an organization in a foreign RIR. I guess I see prop 131 as what to do in case 2009-3 doesn't go global. Yes, the ARIN BoT adopted it, but it's contigent on ratification by ICANN. Is 2011-1 the pending transfer proposal you are referring to? --Heather On Wed, Feb 9, 2011 at 12:32 PM, Martin Hannigan wrote: > Heather, > > Is this language too specific considering pending transfer proposal(s) > or do you think transfer is not relevant? I think the latter myself, > but interested in your thought on this. > > Best, > > Marty > > > > On 2/9/11, Heather Schiller wrote: >> how about: >> >> ".... legacy resources returned to ARIN will be made available for >> distribution in the ARIN region." >> >> --heather >> >> On Mon, Jan 31, 2011 at 3:10 PM, cja at daydream.com >> wrote: >>> Let's be clear this is not "ARIN speak". ?This is RIR speak. ? ?If you >>> have >>> a better alternative to distinguish between addresses that are given out >>> to >>> be further assigned to customers as opposed to blocks given that are >>> intended not to be further delegated then feel free to make a suggestion. >>> Most of us would love a workable alternative. >>> Thanks! >>> >>> ----Cathy >>> >>> On Mon, Jan 31, 2011 at 12:54 PM, William Herrin wrote: >>>> >>>> On Mon, Jan 31, 2011 at 12:02 PM, cja at daydream.com >>>> wrote: >>>> > On Mon, Jan 31, 2011 at 9:58 AM, Martin Hannigan >>>> > wrote: >>>> >> Do you think that this will suffice? >>>> >> >>>> >> "Upon expiration of the hold period and in the absence of a Global >>>> >> Policy or Globally Coordinated Policy directing otherwise, legacy >>>> >> resources returned to ARIN will be made available for allocation." >>>> > >>>> > I think it should say "made available for allocation or assignment" >>>> >>>> Right. Allocation and assignment are loaded words in ARIN-speak. If >>>> you specify the one but not the other in policy, you restrict the >>>> usage of those addresses. You could also say something like "made >>>> available for registration," without using either of the two loaded >>>> words. >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> p.s. Yes, I'm sad to report there is in fact an ARIN-speak -- words >>>> and phrases with special meanings overloaded on the plain English, >>>> meanings that tend to obstruct outsiders' understanding both in the >>>> debate and the policy documents. This is unfortunate since it harms >>>> ARIN's accessibility to the public, but that's a crusade for another >>>> day. >>>> >>>> -- >>>> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >>>> 3005 Crane Dr. ...................... Web: >>>> Falls Church, VA 22042-3004 >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> _______________________________________________ >> 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 hannigan at gmail.com Wed Feb 9 15:13:38 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 9 Feb 2011 15:13:38 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: On Wed, Feb 9, 2011 at 3:10 PM, Heather Schiller wrote: > I had the same thought and looked at 2011-1 before I suggested the > text. ?The pending global transfer proposal text appears to be > registrant to registrant. ?So, if one returns legacy space to ARIN > under prop 131, they aren't attempting to transfer it to an > organization in a foreign RIR. > > I guess I see prop 131 as what to do in case 2009-3 doesn't go global. > ?Yes, the ARIN BoT adopted it, but it's contigent on ratification by > ICANN. > > Is 2011-1 the pending transfer proposal you are referring to? > Yes. Best, -M< From charles at office.tcsn.net Wed Feb 9 15:29:02 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Wed, 09 Feb 2011 12:29:02 -0800 Subject: [arin-ppml] Support for 2011-3 (Was: Application requests for IPv6?) In-Reply-To: <52B39CF2-113A-48EE-9A14-4A92EF67E5C7@corp.arin.net> References: <24c001cbc88a$1a47db70$4ed79250$@net> <52B39CF2-113A-48EE-9A14-4A92EF67E5C7@corp.arin.net> Message-ID: <4D52F90E.7040409@office.tcsn.net> On 2/9/11 11:17 AM, John Curran wrote: > You should make sure that folks coming to you are aware of the 2011-3 > draft policy and > express support for it on the PPML mailing list (and during the PPM if at > all possible), as it makes changes to the allocation policy which would > likely address such concerns. > > Thanks! > /John > > John Curran > President and CEO > ARIN On that note, if I haven't already, I'd like to express support for this policy proposal 2011-3. Not only does the proposal change language to be far more definitive, but it also allows for the smallest ISPs to be able to migrate from PI v4 to PI v6, which is currently not available for PI v4 networks smaller than /20. My ISP hasn't submitted a request, and thus contributed to the statistics in Leslie's great summary of ISP requests and refusals, because we can't request a network smaller than /32. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From jcurran at arin.net Wed Feb 9 16:43:02 2011 From: jcurran at arin.net (John Curran) Date: Wed, 9 Feb 2011 21:43:02 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: Message-ID: Folks - We also received an related inquiry regarding legacy IPv4 holders and IPv6 - > Since we?ve been talking about easing access for legacy holders, what > happens when a legacy holder not signed up to an (L)RSA asks for IPv6? NRPM 6.5.8.1 offers several ways for an end user organization to qualify for an IPv6 assignment from ARIN. The criteria that most often applies is when the organization can "qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect". There is no requirement to have a signed RSA/LRSA under this criteria. An organization can qualify for IPv6, regardless of whether they have existing IPv4 space, as long as it can meet the criteria of ANY existing IPv4 policy in effect. Once qualified, if they choose to proceed, they are assigned the IPv6 resources under the standard RSA. FYI, /John John Curran President and CEO ARIN On Feb 9, 2011, at 1:52 PM, Leslie Nobile wrote: Hi Marty- In response to your recent inquiry about IPv6 requests to ARIN, staff has produced the following data. Total IPv6 Requests January 2009 through January 2011: ISP requests received ? 748 ISP requests approved - 712 or 96% Generally speaking, for ISPs, there are almost no denials for IPv6 address requests. Anything not approved was likely an end-user who put in an ISP request and needed to resubmit as an end-user. In fact, during this past year, there have been no denials to ISPs/LIRs under the IPv6 allocation policy which seems to indicate that the current policy has been very effective. End-user requests received - 464 End-user requests approved ? 403 or 87% Almost all of the denied end-user requests were to small single-homed networks who were unable to meet any one of the policy criteria: they either (1) weren?t using enough IPv4 address space to qualify under current IPv4 policy, (2) had no legacy space, or (3) didn?t qualify as a community network. I hope this information helps! Regards, Leslie Leslie Nobile, Director, Registration Services American Registry for Internet Numbers On 2/6/11 6:48 PM, "Martin Hannigan" > wrote: > Staff et. Al, > > Can we get a recap of activity around resource requests for IPv6 and a > characterization of refusals, if any? If there are none, it would be > interesting to hear a general conclusion as to why. I'm interested to > see if there are any holes here considering all of the work that has > been done to ease access to v6 for transition. > > Best, and go Steelers! > > -M< > _______________________________________________ > 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 owen at delong.com Wed Feb 9 17:05:01 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:05:01 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: I still don't understand why we would limit this to legacy resources. Owen On Feb 9, 2011, at 9:24 AM, Heather Schiller wrote: > how about: > > ".... legacy resources returned to ARIN will be made available for > distribution in the ARIN region." > > --heather > > On Mon, Jan 31, 2011 at 3:10 PM, cja at daydream.com wrote: >> Let's be clear this is not "ARIN speak". This is RIR speak. If you have >> a better alternative to distinguish between addresses that are given out to >> be further assigned to customers as opposed to blocks given that are >> intended not to be further delegated then feel free to make a suggestion. >> Most of us would love a workable alternative. >> Thanks! >> >> ----Cathy >> >> On Mon, Jan 31, 2011 at 12:54 PM, William Herrin wrote: >>> >>> On Mon, Jan 31, 2011 at 12:02 PM, cja at daydream.com >>> wrote: >>>> On Mon, Jan 31, 2011 at 9:58 AM, Martin Hannigan >>>> wrote: >>>>> Do you think that this will suffice? >>>>> >>>>> "Upon expiration of the hold period and in the absence of a Global >>>>> Policy or Globally Coordinated Policy directing otherwise, legacy >>>>> resources returned to ARIN will be made available for allocation." >>>> >>>> I think it should say "made available for allocation or assignment" >>> >>> Right. Allocation and assignment are loaded words in ARIN-speak. If >>> you specify the one but not the other in policy, you restrict the >>> usage of those addresses. You could also say something like "made >>> available for registration," without using either of the two loaded >>> words. >>> >>> Regards, >>> Bill Herrin >>> >>> p.s. Yes, I'm sad to report there is in fact an ARIN-speak -- words >>> and phrases with special meanings overloaded on the plain English, >>> meanings that tend to obstruct outsiders' understanding both in the >>> debate and the policy documents. This is unfortunate since it harms >>> ARIN's accessibility to the public, but that's a crusade for another >>> day. >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > 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 hannigan at gmail.com Wed Feb 9 17:14:27 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 9 Feb 2011 17:14:27 -0500 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: Message-ID: On Wed, Feb 9, 2011 at 4:43 PM, John Curran wrote: > Folks - > We also received an related inquiry regarding legacy IPv4 holders and IPv6 > - >>?Since we?ve been talking about easing access for legacy holders,??what >> happens when a legacy holder not signed up to an (L)RSA asks for IPv6? > NRPM 6.5.8.1 offers several ways for an end user organization to > qualify?for > an IPv6 assignment from ARIN. ?The criteria that most often applies is?when > the organization can "qualify for an IPv4 assignment or allocation from ARIN > under the IPv4 policy currently in effect". ?There is no requirement to have > a signed RSA/LRSA under this criteria. ?An organization can qualify for > IPv6, > regardless of whether they have existing IPv4 space, as long as it can meet > the criteria of ANY existing IPv4 policy in effect. ?Once qualified, if they > choose > to proceed, they are assigned the?IPv6 resources under the standard RSA. Can you get IPv6 without including legacy addresses in the requisite RSA? Section b appears to say "no". Best, -M< From owen at delong.com Wed Feb 9 17:46:08 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 14:46:08 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D52EF53.103@office.tcsn.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> Message-ID: On Feb 9, 2011, at 11:47 AM, Charles O'Hern wrote: > On 2/7/11 1:21 AM, Owen DeLong wrote: >> >> On Feb 6, 2011, at 10:47 PM, Ted Mittelstaedt wrote: >> >>> On 2/6/2011 8:36 AM, Lee Howard wrote: >>> >>> and end users all have an interest in >>>> avoiding NAT. >>> >>> wrong. End users absolutely need inexpensive - and I'm talking $60 and >>> under - stateful packet inspection hardware firewalls. >>> >> Your statement is absolutely correct except for the first word. >> > > Perhaps this is just semantics (and perhaps I'm just in a cynical mood), but I agree with Ted here. "wrong" is the correct term simply because "interest" is the wrong term. End > Users all do not have an interest in avoiding NAT. Most end users don't even know what it really does. As long as their stuff works and they have the illusion of security and > privacy, they are happy. (or at least less malcontented) > End users have an interest in avoiding NAT even if they don't know what it is or why they are interested in avoiding it. End users want to be able to do their hosted games on their Playstation. End users want to be able to get to their home networks through services like Go2mypc or whatever it's called (I don't need a service, I don't use NAT, so, I don't pay a lot of attention to the services available). End users want stuff that works today to work tomorrow. All of those things represent a strong interest in avoiding LSN at the carrier level. > End users will benefit from IPv6 with stateful inspection but they have more interest in streaming the superbowl while being contently assured that their MP3 and porn folders are > 'safe' from prying eyes. > An interest in continuing to be able to stream the superbowl _IS_ an interest in avoiding LSN. > Most end users will have to be coddled or "ninja'd" into IPv6, else the ever present threat of "going to the other provider". Of course at the other provider, they will end up on > IPv6 anyways because they'll accept having to buy a new CPE with new service far more often than they will to fix a problem they don't even perceive. > Oh, well, in that case, LSN is the perfect solution. LSN will definitely be a problem they will perceive. Owen From khelms at zcorum.com Wed Feb 9 17:53:09 2011 From: khelms at zcorum.com (Scott Helms) Date: Wed, 09 Feb 2011 17:53:09 -0500 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> Message-ID: <4D531AD5.6060507@zcorum.com> On 2/9/2011 5:46 PM, Owen DeLong wrote: > > End users want to be able to do their hosted games on their Playstation. End users want to be able to get to their home networks through services like Go2mypc or whatever it's called (I don't need a service, I don't use NAT, so, I don't pay a lot of attention to the services available). I can't name a mass market service today that doesn't work through NAT and the ones you point out are certainly do. Playstation Network works, by design, flawlessly through NAT and is _not_ a peer to peer application. All traffic goes to the PSN servers and then to clients. Go2MyPC is designed for NAT and in fact one could argue that it wouldn't exist if NAT weren't wide spread. > End users want stuff that works today to work tomorrow. > > All of those things represent a strong interest in avoiding LSN at the carrier level. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jbates at brightok.net Wed Feb 9 18:02:25 2011 From: jbates at brightok.net (Jack Bates) Date: Wed, 09 Feb 2011 17:02:25 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D531AD5.6060507@zcorum.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> Message-ID: <4D531D01.6080609@brightok.net> On 2/9/2011 4:53 PM, Scott Helms wrote: > Playstation Network works, by design, flawlessly through NAT and is > _not_ a peer to peer application. All traffic goes to the PSN servers > and then to clients. Go2MyPC is designed for NAT and in fact one could > argue that it wouldn't exist if NAT weren't wide spread. Errr, are you sure? http://www.absolute-playstation.com/playstation-network/expert-playstation-3-hardware-accessory-help-playstation3-ps3-console/10976-nat-3-nat-2-a.html "Re: nat 3 to nat 2 I tried all the router suggestions and still got nat 3. after much frustration I called my ISP. Do this. Ask if your IP address is private or public. My ISP sets u up as private. I had them change it to public...BINGO Nat 2. Hope this helps." If you read above, it appears that his ISP ran NAT444 normally, which the PS3 categorizes as nat 3, which means he can't reach COD. Dude, customers MUST reach COD. :) Jack From cgrundemann at gmail.com Wed Feb 9 18:22:13 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 9 Feb 2011 16:22:13 -0700 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: On Wed, Feb 9, 2011 at 15:05, Owen DeLong wrote: > I still don't understand why we would limit this to legacy resources. +1 Marty - Can you shed some light onto why this is (and needs to be) limited to legacy space? I don't see a need for the distinction but could certainly be missing something. ~Chris > Owen > > On Feb 9, 2011, at 9:24 AM, Heather Schiller wrote: > >> how about: >> >> ".... legacy resources returned to ARIN will be made available for >> distribution in the ARIN region." >> >> --heather >> >> On Mon, Jan 31, 2011 at 3:10 PM, cja at daydream.com wrote: >>> Let's be clear this is not "ARIN speak". ?This is RIR speak. ? ?If you have >>> a better alternative to distinguish between addresses that are given out to >>> be further assigned to customers as opposed to blocks given that are >>> intended not to be further delegated then feel free to make a suggestion. >>> Most of us would love a workable alternative. >>> Thanks! >>> >>> ----Cathy >>> >>> On Mon, Jan 31, 2011 at 12:54 PM, William Herrin wrote: >>>> >>>> On Mon, Jan 31, 2011 at 12:02 PM, cja at daydream.com >>>> wrote: >>>>> On Mon, Jan 31, 2011 at 9:58 AM, Martin Hannigan >>>>> wrote: >>>>>> Do you think that this will suffice? >>>>>> >>>>>> "Upon expiration of the hold period and in the absence of a Global >>>>>> Policy or Globally Coordinated Policy directing otherwise, legacy >>>>>> resources returned to ARIN will be made available for allocation." >>>>> >>>>> I think it should say "made available for allocation or assignment" >>>> >>>> Right. Allocation and assignment are loaded words in ARIN-speak. If >>>> you specify the one but not the other in policy, you restrict the >>>> usage of those addresses. You could also say something like "made >>>> available for registration," without using either of the two loaded >>>> words. >>>> >>>> Regards, >>>> Bill Herrin >>>> >>>> p.s. Yes, I'm sad to report there is in fact an ARIN-speak -- words >>>> and phrases with special meanings overloaded on the plain English, >>>> meanings that tend to obstruct outsiders' understanding both in the >>>> debate and the policy documents. This is unfortunate since it harms >>>> ARIN's accessibility to the public, but that's a crusade for another >>>> day. >>>> >>>> -- >>>> William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us >>>> 3005 Crane Dr. ...................... Web: >>>> Falls Church, VA 22042-3004 >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> _______________________________________________ >> 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. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From giesen at snickers.org Wed Feb 9 18:21:01 2011 From: giesen at snickers.org (Gary T. Giesen) Date: Wed, 9 Feb 2011 18:21:01 -0500 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D531AD5.6060507@zcorum.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D531AD5.6060507@zcorum.com> Message-ID: The only thing that speaks to how many billions of dollars have been spent developing products that work around the problems introduced by NAT. There are a great number of products and protocols that either behaviour poorly behind NAT or have had to have some ugly hacks to make them work. We shouldn't simply accept NAT because of inertia from its use in IPv4. ISPs should take a leadership position in actively discouraging its use, as we all win in the end. GG On Wed, Feb 9, 2011 at 5:53 PM, Scott Helms wrote: > On 2/9/2011 5:46 PM, Owen DeLong wrote: >> >> End users want to be able to do their hosted games on their Playstation. >> End users want to be able to get to their home networks through services >> like Go2mypc or whatever it's called (I don't need a service, I don't use >> NAT, so, I don't pay a lot of attention to the services available). > > I can't name a mass market service today that doesn't work through NAT and > the ones you point out are certainly do. > > Playstation Network works, by design, flawlessly through NAT and is _not_ a > peer to peer application. ?All traffic goes to the PSN servers and then to > clients. ?Go2MyPC is designed for NAT and in fact one could argue that it > wouldn't exist if NAT weren't wide spread. >> >> End users want stuff that works today to work tomorrow. >> >> All of those things represent a strong interest in avoiding LSN at ?the >> carrier level. > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > _______________________________________________ > 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 Wed Feb 9 18:54:14 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 15:54:14 -0800 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: Message-ID: <96145660-5099-4423-B7A8-4383DE6CD8E8@delong.com> > Can you get IPv6 without including legacy addresses in the requisite > RSA? Section b appears to say "no". > > Best, > > -M< > ____________________________ From the NRPM: 6.5.8.1. Criteria To qualify for a direct assignment, an organization must: not be an IPv6 LIR; and qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA, or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. So, if you're not already an IPv6 LIR (ISP) then you have to meet ONE of the criteria from section b: + Qualify for IPv4 under existing policy currently in effect or + demonstrate efficient utilization of all IPv4 assignments and allocations with each being covered by an RSA or LRSA. or + Be a qualifying Community Network as defined in Section 2.8. Note that the first one and third one do not require your IPv4 space to be covered by RSA or LRSA. In addition to this, this policy will soon be superseded by 2010-8 which will replace it with the following text: 6.5.8. Direct assignments from ARIN to end-user organizations 6.5.8.1 Initial Assignment Criteria Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to: ? An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc? ? Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 2000 or more individuals either internal or external to the organization. ? An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193). ? An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS. This version will remove the requirement for RSA/LRSA on the IPv4 space altogether. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Feb 9 19:03:20 2011 From: jcurran at arin.net (John Curran) Date: Thu, 10 Feb 2011 00:03:20 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: <96145660-5099-4423-B7A8-4383DE6CD8E8@delong.com> References: <96145660-5099-4423-B7A8-4383DE6CD8E8@delong.com> Message-ID: On Feb 9, 2011, at 7:54 PM, Owen DeLong wrote: > Note that the first one and third one do not require your IPv4 space to be covered by RSA or > LRSA. Correct. Only any IPv6 space received would be covered by an RSA. /John John Curran President and CEO ARIN From owen at delong.com Wed Feb 9 19:01:37 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 16:01:37 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D531AD5.6060507@zcorum.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> Message-ID: <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> On Feb 9, 2011, at 2:53 PM, Scott Helms wrote: > On 2/9/2011 5:46 PM, Owen DeLong wrote: >> >> End users want to be able to do their hosted games on their Playstation. End users want to be able to get to their home networks through services like Go2mypc or whatever it's called (I don't need a service, I don't use NAT, so, I don't pay a lot of attention to the services available). > > I can't name a mass market service today that doesn't work through NAT and the ones you point out are certainly do. > They work through CONSUMER NAT because consumer NAT has nat traversal facilities like uPNP. LSN/CGNAT is a whole different ballgame. > Playstation Network works, by design, flawlessly through NAT and is _not_ a peer to peer application. All traffic goes to the PSN servers and then to clients. Go2MyPC is designed for NAT and in fact one could argue that it wouldn't exist if NAT weren't wide spread. Yes. You entirely missed the point of my statement. These things work today because CONSUMER NAT provides NAT Traversal technologies (NAT-PMP, STUN, uPNP, etc.) that make things work through NAT and which these applications depend on. LSN/CGNAT will not provide these facilities and in many cases will be implemented in a second layer on top of the existing consumer NAT. This combination will break all of those services. >> End users want stuff that works today to work tomorrow. >> >> All of those things represent a strong interest in avoiding LSN at the carrier level. > My statement here stands. Owen From hannigan at gmail.com Wed Feb 9 19:42:22 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 9 Feb 2011 19:42:22 -0500 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: <96145660-5099-4423-B7A8-4383DE6CD8E8@delong.com> Message-ID: On Wed, Feb 9, 2011 at 7:03 PM, John Curran wrote: > >> Note that the first one and third one do not require your IPv4 space to be covered by RSA or >> LRSA. > > Correct. ?Only any IPv6 space received would be covered by an RSA. > /John > Let me see if I can clarify a bit. I'm not talking about qualifying. I'm talking about legacy holders not signed to any agreement receiving IPv6 resources without agreeing to put their legacy resources under agreement with ARIN in order to receive an IPv6 allocation. >From the ARIN website: https://www.arin.net/resources/agreements/index.html "ARIN must receive a signed Registration Services Agreement from organizations and individuals whose resource requests have been approved before any allocation or assignment can be made." Seems to me if a legacy holder without a signed RSA or LRSA applies to ARIN for v6 addresses and is "qualified" and able to "justify" an IPv6 assignment, they will be required to sign an agreement with ARIN to receive the allocation. Question is, will that agreement consider their legacy resources to be included as part of the agreement? Best, -M< From jcurran at arin.net Wed Feb 9 19:51:32 2011 From: jcurran at arin.net (John Curran) Date: Thu, 10 Feb 2011 00:51:32 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: <96145660-5099-4423-B7A8-4383DE6CD8E8@delong.com> Message-ID: <275CCB75-33D7-4E58-9D71-7A0FFEECBB81@arin.net> On Feb 9, 2011, at 8:42 PM, Martin Hannigan wrote: > > Let me see if I can clarify a bit. > > I'm not talking about qualifying. I'm talking about legacy holders not > signed to any agreement receiving IPv6 resources without agreeing to > put their legacy resources under agreement with ARIN in order to > receive an IPv6 allocation. Organization must sign an Registration Service Agreement to receive new resources (e.g. IPv6 assignments) > "ARIN must receive a signed Registration Services Agreement from > organizations and individuals whose resource requests have been > approved before any allocation or assignment can be made." > > Seems to me if a legacy holder without a signed RSA or LRSA applies to > ARIN for v6 addresses and is "qualified" and able to "justify" an IPv6 > assignment, they will be required to sign an agreement with ARIN to > receive the allocation. Question is, will that agreement consider > their legacy resources to be included as part of the agreement? No. Signing an RSA does not imply that any legacy resources are brought under it. You must explicitly bring your legacy resources under an LRSA or RSA (as desired). /John John Curran President and CEO ARIN From owen at delong.com Wed Feb 9 19:50:40 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Feb 2011 16:50:40 -0800 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: <96145660-5099-4423-B7A8-4383DE6CD8E8@delong.com> Message-ID: <8588BF43-0BE7-470E-B7C4-9A3BFCF71213@delong.com> On Feb 9, 2011, at 4:42 PM, Martin Hannigan wrote: > On Wed, Feb 9, 2011 at 7:03 PM, John Curran wrote: > >> >>> Note that the first one and third one do not require your IPv4 space to be covered by RSA or >>> LRSA. >> >> Correct. Only any IPv6 space received would be covered by an RSA. >> /John >> > > Let me see if I can clarify a bit. > > I'm not talking about qualifying. I'm talking about legacy holders not > signed to any agreement receiving IPv6 resources without agreeing to > put their legacy resources under agreement with ARIN in order to > receive an IPv6 allocation. > Right.. That's what we were talking about too. >> From the ARIN website: > > https://www.arin.net/resources/agreements/index.html > > "ARIN must receive a signed Registration Services Agreement from > organizations and individuals whose resource requests have been > approved before any allocation or assignment can be made." > Right... The IPv6 resources have to be covered under an RSA. This does not require them to put their IPv4 resources under LRSA or RSA. > Seems to me if a legacy holder without a signed RSA or LRSA applies to > ARIN for v6 addresses and is "qualified" and able to "justify" an IPv6 > assignment, they will be required to sign an agreement with ARIN to > receive the allocation. Question is, will that agreement consider > their legacy resources to be included as part of the agreement? > No... The agreement would only cover the IPv6 resources unless they expressed a desire otherwise. Owen From hannigan at gmail.com Wed Feb 9 20:03:18 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 9 Feb 2011 20:03:18 -0500 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: <275CCB75-33D7-4E58-9D71-7A0FFEECBB81@arin.net> References: <96145660-5099-4423-B7A8-4383DE6CD8E8@delong.com> <275CCB75-33D7-4E58-9D71-7A0FFEECBB81@arin.net> Message-ID: On Wed, Feb 9, 2011 at 7:51 PM, John Curran wrote: > On Feb 9, 2011, at 8:42 PM, Martin Hannigan wrote: >> >> Let me see if I can clarify a bit. >> >> I'm not talking about qualifying. I'm talking about legacy holders not >> signed to any agreement receiving IPv6 resources without agreeing to >> put their legacy resources under agreement with ARIN in order to >> receive an IPv6 allocation. > > Organization must sign an Registration Service Agreement to receive > new resources (e.g. IPv6 assignments) > >> "ARIN must receive a signed Registration Services Agreement from >> organizations and individuals whose resource requests have been >> approved before any allocation or assignment can be made." >> >> Seems to me if a legacy holder without a signed RSA or LRSA applies to >> ARIN for v6 addresses and is "qualified" and able to "justify" an IPv6 >> assignment, they will be required to sign an agreement with ARIN to >> receive the allocation. Question is, will that agreement consider >> their legacy resources to be included as part of the agreement? > > No. ?Signing an RSA does not imply that any legacy resources are > brought under it. You must explicitly bring your legacy resources > under an LRSA or RSA (as desired). > Thanks! That is clear. I appreciate it. Best, -M< From farmer at umn.edu Wed Feb 9 20:53:06 2011 From: farmer at umn.edu (David Farmer) Date: Wed, 09 Feb 2011 19:53:06 -0600 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: References: Message-ID: <4D534502.3040505@umn.edu> On 2/9/11 16:14 CST, Martin Hannigan wrote: > On Wed, Feb 9, 2011 at 4:43 PM, John Curran wrote: >> Folks - >> We also received an related inquiry regarding legacy IPv4 holders and IPv6 >> - >>> Since we?ve been talking about easing access for legacy holders, what >>> happens when a legacy holder not signed up to an (L)RSA asks for IPv6? >> NRPM 6.5.8.1 offers several ways for an end user organization to >> qualify for >> an IPv6 assignment from ARIN. The criteria that most often applies is when >> the organization can "qualify for an IPv4 assignment or allocation from ARIN >> under the IPv4 policy currently in effect". There is no requirement to have >> a signed RSA/LRSA under this criteria. An organization can qualify for >> IPv6, >> regardless of whether they have existing IPv4 space, as long as it can meet >> the criteria of ANY existing IPv4 policy in effect. Once qualified, if they >> choose >> to proceed, they are assigned the IPv6 resources under the standard RSA. > > > Can you get IPv6 without including legacy addresses in the requisite > RSA? Section b appears to say "no". I lot of people are confused by NRPM 6.5.8.1 (b), the current (soon to be old) language was confusing and misunderstood by many people. This is one of the reasons I proposed what became 2010-8 and should replace this language soon. At the Internet2 Joint Techs meeting last week in Clemson, SC it was a common misconception that in order to get an IPv6 assignment an end-user's Legacy IPv4 assignments would need to be brought under the RSA or LRSA. NRPM 6.5.8.1 (b) was what they sited as there reason for this believe. It might be helpful to directly cover this issue in a FAQ on the web site probably some place under the Number Resources/Request Resources Tab. https://www.arin.net/resources/request.html I've just submitted an ACSP suggestion regarding including this in a FAQ on the ARIN website. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From tedm at ipinc.net Thu Feb 10 02:40:31 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 09 Feb 2011 23:40:31 -0800 Subject: [arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D51B99B.8000202@brightok.n > <22d101 cbc7dd$a1f021c0$e5d06540$@net> <768F49AF-52A5-4DDF-9AC1-B23A0605C00C@corp.arin.net> <22e101cbc7e0$ecaeee00$c60cca00$@net> <140A1F77-A576-43B0-BF55-4ABDE5649B9E@istaff.org> <4D51EC2D.5070708@ip! inc.net> Message-ID: <4D53966F.60100@ipinc.net> On 2/8/2011 6:28 PM, Owen DeLong wrote: > > On Feb 8, 2011, at 5:21 PM, Ted Mittelstaedt wrote: > >> On 2/8/2011 3:06 PM, John Curran wrote: >>> On Feb 8, 2011, at 6:38 PM, Tony Hain wrote: >>> >>>> If the IANA pool had run dry in 2009, the media attention we are seeing this >>>> past week would have already occurred, and CIOs would have already started >>>> efforts that are just now getting underway. The point is that dual-stack >>>> requires sufficient time to keep the old one working, so waiting until that >>>> is no longer an option as the starting point is guaranteed to create failure >>>> modes. >>>> >>>> There is no one place to assign blame here, and blame was never my intent. >>>> If I had not put out my graph in 2005, attention on the consumption rate >>>> from IANA might have been ignored until it was too late to have any >>>> significant effect on the date, because Geoff's graphs from that time said >>>> 2019. If the RIR's collectively had not changed the practice of when& how >>>> much to acquire from IANA at one time, the pool would have clearly burned >>>> down at least 2 years ago. >>>> >>>> The point is simply that an opportunity for a graceful transition was lost >>>> because high level attention to the issue was deferred to the point where it >>>> was too late. >>> >>> Hah. High-level attention doesn't drive deployment (except in a central- >>> planning or heavily regulated environment), a successful business case >>> drives deployment. >>> >> >> No, I have to disagree with this statement. A successful business case >> only insures that your going to snare a sucker or two to make an investment. What drives deployment is customer demand. Sure, you can build a business case on customer demand - but the demand comes first, not the business case. >> >>> The opportunity for graceful transition was lost when we both failed >>> to include transparent interoperability and then further provided no >>> additional functionality to drive deployment. Reference RFC 1669. >>> >> >> I think you both must have extremely overinflated opinions of your own >> importance to assume that anything that you or anyone else would do would have motivated more than a fraction of people to bother with >> graceful transition any earlier than they did. ;-) >> > That wasn't "we both" as in two people. That was "we" as in the collective > community and "both failed to include transparent interoperability and > then further provided no additional functionality"... The community failed > in both actions, not two people failed in particular things. > Then the community has an extremely overinflated opinion of itself if it thinks that anything it could have done would have sped up IPv6 >> The situation with IPv4->IPv6 transition is a game of chicken between competing ISPs. Anyone running an ISP knows perfectly well that the ISPs who are later into the IPv6 game will benefit from the burned fingers of the ones earlier into the game. So it is perfectly logical that most ISPs will wait until the very last minute to go to IPv6. >> They will wait till the day that they get the first call from a customer saying that they must have IPv6 or they will quit service, then they will think about moving on it. We see Comcast doing trials now, because they are so large that they are probably already getting those calls from at least a few customers. But it is going to take a while for the rest of them to follow along. >> > I know at least one ISP that is doing quite well having been early to the > game with IPv6. Did we burn our fingers a few times? Sure. Did our > getting our fingers singed help others? Maybe. It helped us at least > as much and we got the lessons first, so, it put us ahead. > > The last minute is upon us and may have passed. > > As to the customer calls, well, I'm not at liberty to disclose customer > communications, but, I do know we win business because we have > IPv6 and other contenders are losing customers to us on that basis. > > I think Comcast is doing trials, not because customers are demanding > it (I know there was customer demand years ago), but, because they > aren't spectacularly bad at math and they recognize that there's no > way for them to continue to operate and grow an IPv4 network. > > Anyone who looks at the numbers and isn't spectacularly bad at > math can see that an IPv4-only network is simply not sustainable > and the practical days of dual-stack without IPv6-only hosts are > limited. > >> How many customers out there are demanding IPv6? Not many. Only the ones who have no IPv4 at all are demanding it. For all the rest of them, IPv6 is still on the "nice to have" list. >> > Many, actually. Most of the demand we see for IPv6 is from people > who also want IPv4. IPv6 came off the nice to have list and moved > to the must have soon list over a year ago for most carriers I know. > Now, it's starting to move to the don't even bother to submit a bid > without IPv6 support list. > I'm glad your seeing this, we are not. It might be regional, perhaps. Or it may be that your market is large corporations. Ours is small businesses and end users. And less than 1/2 of 1% of them have asked about it. Ted From jcurran at arin.net Thu Feb 10 02:41:21 2011 From: jcurran at arin.net (John Curran) Date: Thu, 10 Feb 2011 07:41:21 +0000 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: <4D534502.3040505@umn.edu> References: <4D534502.3040505@umn.edu> Message-ID: <451BDDB1-7FFA-4084-B9A1-EDEDF9450440@arin.net> On Feb 9, 2011, at 9:53 PM, David Farmer wrote: > > It might be helpful to directly cover this issue in a FAQ on the web site probably some place under the Number Resources/Request Resources Tab. > > https://www.arin.net/resources/request.html > > I've just submitted an ACSP suggestion regarding including this in a FAQ on the ARIN website. The FAQ is in the process of being updated to specifically address this issue, and should be released shortly. FYI, /John John Curran President and CEO ARIN From tedm at ipinc.net Thu Feb 10 04:36:28 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 10 Feb 2011 01:36:28 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <017201cbc803$15a6ef70$40f4ce50$@iname.com> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <014d01cb c7cc$226f81e0$674e85 a0$@iname.com> <20110209013106.AAA5F9D6947@drugs.dv.isc.org> <017201cbc803$15a6ef70$40f4ce50$@iname.com> Message-ID: <4D53B19C.3070305@ipinc.net> On 2/8/2011 6:43 PM, Frank Bulk wrote: > Mark: > > The hardware came before the implementation of IPv6 support. wrong. Most small CPE's are built on Linux and that has IPv6 support for many years. They tried to > fit in existing hardware, but it didn't work. Not true. Quite a lot of existing hardware will fit it. And some existing hardware can be modified very simply to fit it - for example: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=530360 Netgear WGR614 v9 - user soldered on a jtag, and replaced dram chip and is going to be doing the flash chip - that was last week. There is absolutely no need to redesign the entire thing. or http://www.neophob.com/2006/01/wrt54g-ram-upgrade/ that one is a ram update. Or http://www.dd-wrt.com/phpBB2/viewtopic.php?t=43386&postdays=0&postorder=asc&start=0 wrt54g v8 with 2MB flash, was upgraded to 8MB flash by the user. I repeat, NO NEED FOR REDESIGNS!!! Future hardware revisions of > some models will include expanded storage, allowing for SPI support. > It is a lot more accurate to say that future hardware revs will NOT ship with limited flash. The real truth though is in the CPE market there have always been versions that had adequate storage. What happened in the CPE market was the earlier CPE's had more flash. The later versions had less flash. But it has been known since 2008 that you cannot fit a full IPv6 implementation into anything less than 8MB. However, you CAN fit an IPv6 implementation - WITH an IPv6 firewall - into 4MB if you give up dhcpv6. It's been done. The Comcast "IPv6 open-wrt reference implementation" which is a "full" IPv6 implementation on Sourceforge was built to run in 8MB of flash. This is an adequate amount of flash and will serve CPEs for some time. The Comcast load is, IMHO, intended for Comcast to be able to pressure it's CPE vendors to put in IPv6 so that they cannot make ridiculous excuses like they can't do it without making a super expensive CPE. Here is a list of common CPE models with 8MB of flash. Some are older and no longer shipping. Some are new and are currently shipping. D-link has both an older and a newer model with the required 8MB so they cannot make that excuse that they "tried" fitting it in. Baloney. They didn't try at all. They just put out a deficient IPv6 stack in a 4MB router, hoping nobody would notice. ALL of these can have special loads built that run a full IPv6 stack: Accton MR3201A ActionTec MI424WR ASUS RT-N16 WL-500gP WL-500W Buffalo WAPM- HP- AM 54G54 WZR-HP-G300NH WZR-HP-G301NH WZR-RS-G54 Cisco/Linksys WRT54G-RG WRT54GS (version 1 through 3.) WRTSL54GS E2000 E2100L E3000 WRT160NL WRT300N v1.1 WRT320N WRT350N WRT400N WRT600N WRT610N D-link: DIR-330 ver A1 DIR-825 version B1 and B2 Netgear WNDR3700 WNDR3500L US Robotics USR5453 > I suspect that most consumer/SOHO router vendors are in the same predicament > at D-Link. > No, they are not. Most if not all have designs they have shipped or are shipping now that they can come out with newer flash versions that support IPv6 because they ALREADY HAVE the required amount of storage. And of their designs that they have shipping now that don't have adequate storage, it is simplicity to ship those with adequate storage, they just replace one flash chip part number with another - nothing else in the design needs to be changed. Ted > We can complain about the past, but that won't change anything. Better to > make current and future purchasing decisions about what's out there -- I am. > > Frank > > -----Original Message----- > From: Mark Andrews [mailto:marka at isc.org] > Sent: Tuesday, February 08, 2011 7:31 PM > To: frnkblk at iname.com > Cc: 'Ted Mittelstaedt'; arin-ppml at arin.net > Subject: Re: [arin-ppml] inevitability of NAT? > > > In message<014d01cbc7cc$226f81e0$674e85a0$@iname.com>, "Frank Bulk" writes: >> Due to device (storage) limitations D-Link wasn't able to put a firewall > in >> many of its IPv-6 capable releases for its different hardware models, but >> DIR-655 is supposed to support SPI. >> >> Frank > > Also IPv6 equipment should be capable of being put on the net without > a seperate firewall. If it isn't then the product really isn't fit > for the purpose it was designed for. Its been a hostile net for > the entire time IPv6 has existed and that should have been factored > into the design. A seperate firewall provides additional isolation > but shouldn't be needed. > > Giving a device a ULA and not a public address if it doesn't need to > talk to the world will give you as much protection as a NAT gives. > > Feature parity should also be there. I've got a Brother network > printer that has accept/deny filters for IPv4 but not for IPv6. I > don't know what they were thinking. IPv6 doesn't need accept/deny > filters but IPv6 does? It would have been less than a days work > to add them as they already have them working for IPv4. A bit more > for testing and documentation. At least I can set the IPv6 address > statically to a ULA. > > Mark From khelms at zcorum.com Thu Feb 10 09:41:36 2011 From: khelms at zcorum.com (Scott Helms) Date: Thu, 10 Feb 2011 09:41:36 -0500 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> Message-ID: <4D53F920.8040804@zcorum.com> > They work through CONSUMER NAT because consumer NAT has nat traversal facilities like uPNP. > > LSN/CGNAT is a whole different ballgame. > Lets step back a moment. Why is LSN/CGNAT different from consumer NAT? Is it only because of a perceived lack of knobs? If I am going to explain to a CFO that "CGNAT is bad" I have to articulate exactly why its bad. While I don't know if this is the case or not there is no reason that the CGNAT vendors can't expose to end users the ability create forwarding rules based on user profiles (could be stored in TR-069, RADIUS, DHCP, LDAP, or even DDNS). I may be naive here because I haven't actually verified with Cisco and the others that they are planning this but if their product managers missed something that obvious I will be greatly surprised. While UPnP will not be part of that solution for obvious reasons building a web page that works with some sort of storage directory is trivial. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Thu Feb 10 09:47:29 2011 From: khelms at zcorum.com (Scott Helms) Date: Thu, 10 Feb 2011 09:47:29 -0500 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D531D01.6080609@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <4D531D01.6080609@brightok.net> Message-ID: <4D53FA81.4020800@zcorum.com> Jack, If you look further down you'll see that the OP's problem was bad firmware on a $12 router. Having said that there are some ports that are needed for voice chat which does seem to have a peer to peer component. I also run gaming servers for my own enjoyment (TF2 currently and many others in the past) and the days of hosting your own $fps_game server are generally past and very much outside of the public norm even for PC gaming. While you can do that the vast majority of the gaming hours today are spent on servers hosted by companies like Nuclear Fallot, Branzone, and a host of others. I do miss the days of Quake but home hosted game servers are a dying (but not completely dead) breed. On 2/9/2011 6:02 PM, Jack Bates wrote: > On 2/9/2011 4:53 PM, Scott Helms wrote: >> Playstation Network works, by design, flawlessly through NAT and is >> _not_ a peer to peer application. All traffic goes to the PSN servers >> and then to clients. Go2MyPC is designed for NAT and in fact one could >> argue that it wouldn't exist if NAT weren't wide spread. > > Errr, are you sure? > > http://www.absolute-playstation.com/playstation-network/expert-playstation-3-hardware-accessory-help-playstation3-ps3-console/10976-nat-3-nat-2-a.html > > > "Re: nat 3 to nat 2 > > I tried all the router suggestions and still got nat 3. after much > frustration I called my ISP. Do this. Ask if your IP address is > private or public. My ISP sets u up as private. I had them change it > to public...BINGO Nat 2. Hope this helps." > > If you read above, it appears that his ISP ran NAT444 normally, which > the PS3 categorizes as nat 3, which means he can't reach COD. Dude, > customers MUST reach COD. :) > > > Jack > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From info at arin.net Thu Feb 10 10:03:09 2011 From: info at arin.net (ARIN) Date: Thu, 10 Feb 2011 10:03:09 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised Message-ID: <4D53FE2D.7080802@arin.net> The proposal originator submitted revised text. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-131: Section 5.0 Legacy Addresses Proposal Originator: Martin Hannigan Proposal Version: 2.0 Date: 10 February 2011 Proposal type: New Policy term: Permanent Policy statement: Section 5.0 Legacy Addresses 5.1 Returned Legacy Addresses Legacy IPv4 addresses returned to or recovered by ARIN will be made available for registration and distribution in the ARIN region within thirty days of their receipt. Rationale: Adopting this proposal will result in the clarification of the status of returned legacy addresses. IPv4 address resources should not sit idle due to lack of policy clarity. Timetable for implementation: Immediately From bensons at queuefull.net Thu Feb 10 10:42:34 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 09:42:34 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D53F920.8040804@zcorum.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> Message-ID: On Feb 10, 2011, at 8:41 AM, Scott Helms wrote: >> They work through CONSUMER NAT because consumer NAT has nat traversal facilities like uPNP. >> >> LSN/CGNAT is a whole different ballgame. >> > > Lets step back a moment. Why is LSN/CGNAT different from consumer NAT? Is it only because of a perceived lack of knobs? > > If I am going to explain to a CFO that "CGNAT is bad" I have to articulate exactly why its bad. While I don't know if this is the case or not there is no reason that the CGNAT vendors can't expose to end users the ability create forwarding rules based on user profiles (could be stored in TR-069, RADIUS, DHCP, LDAP, or even DDNS). I may be naive here because I haven't actually verified with Cisco and the others that they are planning this but if their product managers missed something that obvious I will be greatly surprised. While UPnP will not be part of that solution for obvious reasons building a web page that works with some sort of storage directory is trivial. CGN is a NAT, and is essentially just a higher-scale implementation of the NAT that we all know and "love". I think you're right to challenge the oft-repeated belief that CGN is somehow fundamentally different. That being said, the deployment model of CGN is significantly different from CPE-based NAT, and that fact does results in some differences in how it can be used. The two fundamental differences are fairly obvious: 1) CGN is run by a carrier, and so the subscriber doesn't necessarily have the same degree of control. 2) CGN allows for greater oversubscription of public IP addresses, and so there is potentially a many-to-one relationship between subscribers and public addresses. The implications of #1 are the things you described above. Static port forwarding is a problem unless the subscriber is given a tool to configure it. And even then, it's something that doesn't scale very well - e.g. static entries for every subscriber rule, managed across a number of redundant CGN nodes, which may each have different public address pools, etc. My personal opinion is that static port forwarding (for running servers at home, let's say) is better served by paying for a static public IP address from the ISP. (Conversely, ISPs should offer static public addresses in order to support "server" users.) In terms of dynamic port forwarding for apps that require that kind of functionality, CGN generally doesn't support UPNP for obvious reasons. But there is work in the IETF to develop a protocol called PCP, that improves on UPNP (and similar protocols) in a number of ways. Generally speaking, PCP will be much better suited for dynamic control of a CGN by clients. In the meantime, until PCP is available, users should consider turning off UPNP support in their gateway to make sure apps don't rely on it when they're behind a CGN. The implications of #2 are typically related to things like dynamic DNS entries. Of course, this is mostly relevant for people doing static port forwarding, which has other complications per my comment above. But to be specific: if you're sharing an IP address, and that address is registered in DNS, then it's possible the DNS entry will actually point to a number of completely different server resources (depending on port number, of course). E.g. webcam.myhouse.whatever might point to an IP address, and listening on port 8080 might be my webcam while listening on port 8081 might be my neighbor's webcam; webcam.neighborshouse.whatever in the DNS might point to the same IP address. By the way, these implications are true for essentially any form of CGN, because the deployment model is the same (deployed in the carrier's network). Arguments about DS-lite versus NAT444 are a bit misleading. And in any case, the right conclusion is to deploy IPv6 (via 6rd if one must, native as soon as one can) to avoid this whole mess.* Cheers, -Benson * - Full Disclosure: I am employed by Cisco Systems, which I assume is happy to sell NAT hardware as well as IPv6-capable routers. However, my statements and opinions are my own and do not represent my employer, fellow employees, friends, family, or any other entity. From jbates at brightok.net Thu Feb 10 10:51:36 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 09:51:36 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D53FA81.4020800@zcorum.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <4D531D01.6080609@brightok.net> <4D53FA81.4020800@zcorum.com> Message-ID: <4D540988.3090705@brightok.net> I don't have to look further down. If port forwarding is required for an application to work (often handled by uPNP), then LSN will break the communication. PS3 has required such functionality right along with the xbox and Steam. There are many games out there that also host on a specific end node automatically. They are able to accomplish this due to uPNP and automated port forwarding. They will break in LSN environments. Jack (not gonna be the one to tell his son that he'll just have to deal with it) On 2/10/2011 8:47 AM, Scott Helms wrote: > Jack, > > If you look further down you'll see that the OP's problem was bad > firmware on a $12 router. Having said that there are some ports that are > needed for voice chat which does seem to have a peer to peer component. > I also run gaming servers for my own enjoyment (TF2 currently and many > others in the past) and the days of hosting your own $fps_game server > are generally past and very much outside of the public norm even for PC > gaming. While you can do that the vast majority of the gaming hours > today are spent on servers hosted by companies like Nuclear Fallot, > Branzone, and a host of others. I do miss the days of Quake but home > hosted game servers are a dying (but not completely dead) breed. > > On 2/9/2011 6:02 PM, Jack Bates wrote: >> On 2/9/2011 4:53 PM, Scott Helms wrote: >>> Playstation Network works, by design, flawlessly through NAT and is >>> _not_ a peer to peer application. All traffic goes to the PSN servers >>> and then to clients. Go2MyPC is designed for NAT and in fact one could >>> argue that it wouldn't exist if NAT weren't wide spread. >> >> Errr, are you sure? >> >> http://www.absolute-playstation.com/playstation-network/expert-playstation-3-hardware-accessory-help-playstation3-ps3-console/10976-nat-3-nat-2-a.html >> >> >> "Re: nat 3 to nat 2 >> >> I tried all the router suggestions and still got nat 3. after much >> frustration I called my ISP. Do this. Ask if your IP address is >> private or public. My ISP sets u up as private. I had them change it >> to public...BINGO Nat 2. Hope this helps." >> >> If you read above, it appears that his ISP ran NAT444 normally, which >> the PS3 categorizes as nat 3, which means he can't reach COD. Dude, >> customers MUST reach COD. :) >> >> >> Jack >> > > From khelms at zcorum.com Thu Feb 10 10:53:33 2011 From: khelms at zcorum.com (Scott Helms) Date: Thu, 10 Feb 2011 10:53:33 -0500 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4D53F920.8040804@zcorum.com> Message-ID: <4D5409FD.6080103@zcorum.com> > CGN is a NAT, and is essentially just a higher-scale implementation of the NAT that we all know and "love". I think you're right to challenge the oft-repeated belief that CGN is somehow fundamentally different. That being said, the deployment model of CGN is significantly different from CPE-based NAT, and that fact does results in some differences in how it can be used. The two fundamental differences are fairly obvious: 1) CGN is run by a carrier, and so the subscriber doesn't necessarily have the same degree of control. 2) CGN allows for greater oversubscription of public IP addresses, and so there is potentially a many-to-one relationship between subscribers and public addresses. Benson, I know the vendors have all thought about the issue of over subscription of IP's and logging of translations so you can go back and identify who was using a specific IP for a LEA request so over subscribing doesn't doesn't bother me as much. The other issue I didn't think of was that the people who are most likely to be attracted to CGNAT/LSN are also the networks that are most likely to have CPE NAT at or near 100% of their end users. That creates the likelihood of double NAT if they don't change their CPE's, which is very problematic. DSL systems aren't like DOCSIS networks where I know I can change the configuration of the premise gear with ease. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at zcorum.com Thu Feb 10 10:57:07 2011 From: khelms at zcorum.com (Scott Helms) Date: Thu, 10 Feb 2011 10:57:07 -0500 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D540988.3090705@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <4D531D01.6080609@brightok.net> <4D53FA81.4020800@zcorum.com> <4D540988.3090705@brightok.net> Message-ID: <4D540AD3.7080307@zcorum.com> Jack, The point was the game does _not_ require UPnP nor any port forwarding. However, that is required for voice communication. I don't personally use PSN for voice communications hence I haven't run into that problem despite being in NAT category 3 by the PSN definition (I have UPnP turned off and no forwarding for my PS3). On 2/10/2011 10:51 AM, Jack Bates wrote: > I don't have to look further down. > > If port forwarding is required for an application to work (often > handled by uPNP), then LSN will break the communication. PS3 has > required such functionality right along with the xbox and Steam. > > There are many games out there that also host on a specific end node > automatically. They are able to accomplish this due to uPNP and > automated port forwarding. They will break in LSN environments. > > > Jack (not gonna be the one to tell his son that he'll just have to > deal with it) > > On 2/10/2011 8:47 AM, Scott Helms wrote: >> Jack, >> >> If you look further down you'll see that the OP's problem was bad >> firmware on a $12 router. Having said that there are some ports that are >> needed for voice chat which does seem to have a peer to peer component. >> I also run gaming servers for my own enjoyment (TF2 currently and many >> others in the past) and the days of hosting your own $fps_game server >> are generally past and very much outside of the public norm even for PC >> gaming. While you can do that the vast majority of the gaming hours >> today are spent on servers hosted by companies like Nuclear Fallot, >> Branzone, and a host of others. I do miss the days of Quake but home >> hosted game servers are a dying (but not completely dead) breed. >> >> On 2/9/2011 6:02 PM, Jack Bates wrote: >>> On 2/9/2011 4:53 PM, Scott Helms wrote: >>>> Playstation Network works, by design, flawlessly through NAT and is >>>> _not_ a peer to peer application. All traffic goes to the PSN servers >>>> and then to clients. Go2MyPC is designed for NAT and in fact one could >>>> argue that it wouldn't exist if NAT weren't wide spread. >>> >>> Errr, are you sure? >>> >>> http://www.absolute-playstation.com/playstation-network/expert-playstation-3-hardware-accessory-help-playstation3-ps3-console/10976-nat-3-nat-2-a.html >>> >>> >>> >>> "Re: nat 3 to nat 2 >>> >>> I tried all the router suggestions and still got nat 3. after much >>> frustration I called my ISP. Do this. Ask if your IP address is >>> private or public. My ISP sets u up as private. I had them change it >>> to public...BINGO Nat 2. Hope this helps." >>> >>> If you read above, it appears that his ISP ran NAT444 normally, which >>> the PS3 categorizes as nat 3, which means he can't reach COD. Dude, >>> customers MUST reach COD. :) >>> >>> >>> Jack >>> >> >> > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jbates at brightok.net Thu Feb 10 11:05:04 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 10:05:04 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> Message-ID: <4D540CB0.2020902@brightok.net> On 2/10/2011 9:42 AM, Benson Schliesser wrote: > In the meantime, until PCP is available, users should consider > turning off UPNP support in their gateway to make sure apps don't > rely on it when they're behind a CGN. User got a faulty DSL modem a few months back. uPNP wasn't enabled per the norm. User was unable to use some xbox functionality. The degree at which things are depending on uPNP has grown to making it almost mandatory. Turning it off is likely to lead to things breaking. In addition, no protocol is going to fix LSN well. I don't think any studies have really been done to see at what scale applications are currently using uPNP to (port forward, open firewall). This places practical limits on the number of people doing a certain thing while behind a single IP. Jack From jbates at brightok.net Thu Feb 10 11:08:43 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 10:08:43 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D540AD3.7080307@zcorum.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <4D531D01.6080609@brightok.net> <4D53FA81.4020800@zcorum.com> <4D540988.3090705@brightok.net> <4D540AD3.7080307@zcorum.com> Message-ID: <4D540D8B.5000504@brightok.net> I'd be curious if that scales to every user in a game being behind NAT category 3, and what effects that would have on gaming performance in the long run. But to be honest, while you may live with substandard gaming (by my users' definition), most won't. Jack On 2/10/2011 9:57 AM, Scott Helms wrote: > Jack, > > The point was the game does _not_ require UPnP nor any port forwarding. > However, that is required for voice communication. I don't personally > use PSN for voice communications hence I haven't run into that problem > despite being in NAT category 3 by the PSN definition (I have UPnP > turned off and no forwarding for my PS3). > > On 2/10/2011 10:51 AM, Jack Bates wrote: >> I don't have to look further down. >> >> If port forwarding is required for an application to work (often >> handled by uPNP), then LSN will break the communication. PS3 has >> required such functionality right along with the xbox and Steam. >> >> There are many games out there that also host on a specific end node >> automatically. They are able to accomplish this due to uPNP and >> automated port forwarding. They will break in LSN environments. >> >> >> Jack (not gonna be the one to tell his son that he'll just have to >> deal with it) >> >> On 2/10/2011 8:47 AM, Scott Helms wrote: >>> Jack, >>> >>> If you look further down you'll see that the OP's problem was bad >>> firmware on a $12 router. Having said that there are some ports that are >>> needed for voice chat which does seem to have a peer to peer component. >>> I also run gaming servers for my own enjoyment (TF2 currently and many >>> others in the past) and the days of hosting your own $fps_game server >>> are generally past and very much outside of the public norm even for PC >>> gaming. While you can do that the vast majority of the gaming hours >>> today are spent on servers hosted by companies like Nuclear Fallot, >>> Branzone, and a host of others. I do miss the days of Quake but home >>> hosted game servers are a dying (but not completely dead) breed. >>> >>> On 2/9/2011 6:02 PM, Jack Bates wrote: >>>> On 2/9/2011 4:53 PM, Scott Helms wrote: >>>>> Playstation Network works, by design, flawlessly through NAT and is >>>>> _not_ a peer to peer application. All traffic goes to the PSN servers >>>>> and then to clients. Go2MyPC is designed for NAT and in fact one could >>>>> argue that it wouldn't exist if NAT weren't wide spread. >>>> >>>> Errr, are you sure? >>>> >>>> http://www.absolute-playstation.com/playstation-network/expert-playstation-3-hardware-accessory-help-playstation3-ps3-console/10976-nat-3-nat-2-a.html >>>> >>>> >>>> >>>> "Re: nat 3 to nat 2 >>>> >>>> I tried all the router suggestions and still got nat 3. after much >>>> frustration I called my ISP. Do this. Ask if your IP address is >>>> private or public. My ISP sets u up as private. I had them change it >>>> to public...BINGO Nat 2. Hope this helps." >>>> >>>> If you read above, it appears that his ISP ran NAT444 normally, which >>>> the PS3 categorizes as nat 3, which means he can't reach COD. Dude, >>>> customers MUST reach COD. :) >>>> >>>> >>>> Jack >>>> >>> >>> >> > > From bensons at queuefull.net Thu Feb 10 11:30:38 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 10:30:38 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D540CB0.2020902@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> <4D540CB0.2020902@brightok.net> Message-ID: <821C9067-1C8C-4453-B9AB-AC14489E2FCE@queuefull.net> On Feb 10, 2011, at 10:05 AM, Jack Bates wrote: > On 2/10/2011 9:42 AM, Benson Schliesser wrote: >> In the meantime, until PCP is available, users should consider >> turning off UPNP support in their gateway to make sure apps don't >> rely on it when they're behind a CGN. > > User got a faulty DSL modem a few months back. uPNP wasn't enabled per the norm. User was unable to use some xbox functionality. > > The degree at which things are depending on uPNP has grown to making it almost mandatory. Turning it off is likely to lead to things breaking. In addition, no protocol is going to fix LSN well. I don't think any studies have really been done to see at what scale applications are currently using uPNP to (port forward, open firewall). This places practical limits on the number of people doing a certain thing while behind a single IP. My opinion, to some extent, is that in the coming years: clients that require IPv4 but don't work well with NAT should expect to break. On the other hand, clients with IPv6 support should experience an improved experience. That said, UPNP (and NAT-PMP etc) just don't scale to the carrier scope. PCP is coming, and clients should expect to migrate if they need IPv4 NAT support. PCP will also support IPv6 pinholes (i.e. control of security in IPv6-enabled CPE), so clients should migrate regardless. By the way, one of the PCP working group chairs is Dave Thaler from Microsoft (maker of Xbox). Cheers, -Benson From jbates at brightok.net Thu Feb 10 11:35:47 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 10:35:47 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <821C9067-1C8C-4453-B9AB-AC14489E2FCE@queuefull.net> References: <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> <4D540CB0.2020902@brightok.net> <821C9067-1C8C-4453-B9AB-AC14489E2FCE@queuefull.net> Message-ID: <4D5413E3.4070003@brightok.net> On 2/10/2011 10:30 AM, Benson Schliesser wrote: > My opinion, to some extent, is that in the coming years: clients that > require IPv4 but don't work well with NAT should expect to break. On > the other hand, clients with IPv6 support should experience an > improved experience. > I agree, and this is the motivation that will push faster IPv6 deployment. > That said, UPNP (and NAT-PMP etc) just don't scale to the carrier > scope. PCP is coming, and clients should expect to migrate if they > need IPv4 NAT support. PCP will also support IPv6 pinholes (i.e. > control of security in IPv6-enabled CPE), so clients should migrate > regardless. > > By the way, one of the PCP working group chairs is Dave Thaler from > Microsoft (maker of Xbox). I hope he remembers that people game with their neighbors and applications behind LSN will have to deal with that extremely difficult problem. I personally don't think you can establish p2p in that scenario at all. Jack From frnkblk at iname.com Thu Feb 10 12:21:44 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 10 Feb 2011 11:21:44 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D53B19C.3070305@ipinc.net> References: <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <014d01cb c7cc$226f81e0$674e85 a0$@iname.com> <20110209013106.AAA5F9D6947@drugs.dv.isc.org> <017201cbc803$15a6ef70$40f4ce50$@iname.com> <4D53B19C.3070305@ipinc.n et> Message-ID: <015f01cbc946$fd0b48e0$f721daa0$@iname.com> CPE vendors have tight margins, so they're the first to cut costs and have a short-term view of things. They figure customers will replace their $30 to $150 hardware in 3 to 5 years. We would all wish CPE vendors had built and sold devices with 8 MB of flash and had software engineering groups to provide new code for 3-year old models that includes IPv6 support, but they haven't done it thus far and I'm not holding my breath to think that they will. And that's where DD-WRT has a role. If customer prefers to upgrade their router with DD-WRT code so that they have IPv6 without spending a dime, that's fine with me, but as a service provider I don't have the resources to support that. Frank -----Original Message----- From: Ted Mittelstaedt [mailto:tedm at ipinc.net] Sent: Thursday, February 10, 2011 3:36 AM To: frnkblk at iname.com Cc: 'Mark Andrews'; arin-ppml at arin.net Subject: Re: [arin-ppml] inevitability of NAT? On 2/8/2011 6:43 PM, Frank Bulk wrote: > Mark: > > The hardware came before the implementation of IPv6 support. wrong. Most small CPE's are built on Linux and that has IPv6 support for many years. They tried to > fit in existing hardware, but it didn't work. Not true. Quite a lot of existing hardware will fit it. And some existing hardware can be modified very simply to fit it - for example: http://www.dd-wrt.com/phpBB2/viewtopic.php?p=530360 Netgear WGR614 v9 - user soldered on a jtag, and replaced dram chip and is going to be doing the flash chip - that was last week. There is absolutely no need to redesign the entire thing. or http://www.neophob.com/2006/01/wrt54g-ram-upgrade/ that one is a ram update. Or http://www.dd-wrt.com/phpBB2/viewtopic.php?t=43386&postdays=0&postorder=asc& start=0 wrt54g v8 with 2MB flash, was upgraded to 8MB flash by the user. I repeat, NO NEED FOR REDESIGNS!!! Future hardware revisions of > some models will include expanded storage, allowing for SPI support. > It is a lot more accurate to say that future hardware revs will NOT ship with limited flash. The real truth though is in the CPE market there have always been versions that had adequate storage. What happened in the CPE market was the earlier CPE's had more flash. The later versions had less flash. But it has been known since 2008 that you cannot fit a full IPv6 implementation into anything less than 8MB. However, you CAN fit an IPv6 implementation - WITH an IPv6 firewall - into 4MB if you give up dhcpv6. It's been done. The Comcast "IPv6 open-wrt reference implementation" which is a "full" IPv6 implementation on Sourceforge was built to run in 8MB of flash. This is an adequate amount of flash and will serve CPEs for some time. The Comcast load is, IMHO, intended for Comcast to be able to pressure it's CPE vendors to put in IPv6 so that they cannot make ridiculous excuses like they can't do it without making a super expensive CPE. Here is a list of common CPE models with 8MB of flash. Some are older and no longer shipping. Some are new and are currently shipping. D-link has both an older and a newer model with the required 8MB so they cannot make that excuse that they "tried" fitting it in. Baloney. They didn't try at all. They just put out a deficient IPv6 stack in a 4MB router, hoping nobody would notice. ALL of these can have special loads built that run a full IPv6 stack: Accton MR3201A ActionTec MI424WR ASUS RT-N16 WL-500gP WL-500W Buffalo WAPM- HP- AM 54G54 WZR-HP-G300NH WZR-HP-G301NH WZR-RS-G54 Cisco/Linksys WRT54G-RG WRT54GS (version 1 through 3.) WRTSL54GS E2000 E2100L E3000 WRT160NL WRT300N v1.1 WRT320N WRT350N WRT400N WRT600N WRT610N D-link: DIR-330 ver A1 DIR-825 version B1 and B2 Netgear WNDR3700 WNDR3500L US Robotics USR5453 > I suspect that most consumer/SOHO router vendors are in the same predicament > at D-Link. > No, they are not. Most if not all have designs they have shipped or are shipping now that they can come out with newer flash versions that support IPv6 because they ALREADY HAVE the required amount of storage. And of their designs that they have shipping now that don't have adequate storage, it is simplicity to ship those with adequate storage, they just replace one flash chip part number with another - nothing else in the design needs to be changed. Ted > We can complain about the past, but that won't change anything. Better to > make current and future purchasing decisions about what's out there -- I am. > > Frank > > -----Original Message----- > From: Mark Andrews [mailto:marka at isc.org] > Sent: Tuesday, February 08, 2011 7:31 PM > To: frnkblk at iname.com > Cc: 'Ted Mittelstaedt'; arin-ppml at arin.net > Subject: Re: [arin-ppml] inevitability of NAT? > > > In message<014d01cbc7cc$226f81e0$674e85a0$@iname.com>, "Frank Bulk" writes: >> Due to device (storage) limitations D-Link wasn't able to put a firewall > in >> many of its IPv-6 capable releases for its different hardware models, but >> DIR-655 is supposed to support SPI. >> >> Frank > > Also IPv6 equipment should be capable of being put on the net without > a seperate firewall. If it isn't then the product really isn't fit > for the purpose it was designed for. Its been a hostile net for > the entire time IPv6 has existed and that should have been factored > into the design. A seperate firewall provides additional isolation > but shouldn't be needed. > > Giving a device a ULA and not a public address if it doesn't need to > talk to the world will give you as much protection as a NAT gives. > > Feature parity should also be there. I've got a Brother network > printer that has accept/deny filters for IPv4 but not for IPv6. I > don't know what they were thinking. IPv6 doesn't need accept/deny > filters but IPv6 does? It would have been less than a days work > to add them as they already have them working for IPv4. A bit more > for testing and documentation. At least I can set the IPv6 address > statically to a ULA. > > Mark From owen at delong.com Thu Feb 10 12:47:00 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 09:47:00 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D53F920.8040804@zcorum.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> Message-ID: On Feb 10, 2011, at 6:41 AM, Scott Helms wrote: > >> They work through CONSUMER NAT because consumer NAT has nat traversal facilities like uPNP. >> >> LSN/CGNAT is a whole different ballgame. >> > > Lets step back a moment. Why is LSN/CGNAT different from consumer NAT? Is it only because of a perceived lack of knobs? > > If I am going to explain to a CFO that "CGNAT is bad" I have to articulate exactly why its bad. While I don't know if this is the case or not there is no reason that the CGNAT vendors can't expose to end users the ability create forwarding rules based on user profiles (could be stored in TR-069, RADIUS, DHCP, LDAP, or even DDNS). I may be naive here because I haven't actually verified with Cisco and the others that they are planning this but if their product managers missed something that obvious I will be greatly surprised. While UPnP will not be part of that solution for obvious reasons building a web page that works with some sort of storage directory is trivial. > It's not just perception. The knobs aren't there, and, even if they were, as you pointed out, they can't/won't be the same knobs that exist in consumer NAT boxes. The problem with this is that many applications depend on the ones that exist and updating them to support different ones is probably at least as much effort as updating them to support IPv6. Further, most LSN/CGN implementations will not be single-layer. Most NAT solutions depend on a Private->Public or Private->Public->Private structure with a rendezvous host in the Public zone to coordinate knowledge of both sides of the translator. In the LSN/CGN scenario, you have Private->Private2->Public- or worse Private->Private2->Public->Private or worse still Private->Private2->Public->Private2->Private. There is no ability to have Rendezvous hosts in all of the Private2 sectors. This makes a huge difference in the way applications currently operate and means that porting to IPv6 is, in most cases, simpler than incorporating sufficient workarounds to cope with LSN/CGN. Owen From owen at delong.com Thu Feb 10 12:50:13 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 09:50:13 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D53FA81.4020800@zcorum.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <4D531D01.6080609@brightok.net> <4D53FA81.4020800@z! corum.com> Message-ID: This is largely the result of damage done by NAT. It's entirely possible that once we are on IPv6 (assuming that the gaming companies ever catch up to this fact), we could see a return to that ability. Owen On Feb 10, 2011, at 6:47 AM, Scott Helms wrote: > Jack, > > If you look further down you'll see that the OP's problem was bad firmware on a $12 router. Having said that there are some ports that are needed for voice chat which does seem to have a peer to peer component. I also run gaming servers for my own enjoyment (TF2 currently and many others in the past) and the days of hosting your own $fps_game server are generally past and very much outside of the public norm even for PC gaming. While you can do that the vast majority of the gaming hours today are spent on servers hosted by companies like Nuclear Fallot, Branzone, and a host of others. I do miss the days of Quake but home hosted game servers are a dying (but not completely dead) breed. > > On 2/9/2011 6:02 PM, Jack Bates wrote: >> On 2/9/2011 4:53 PM, Scott Helms wrote: >>> Playstation Network works, by design, flawlessly through NAT and is >>> _not_ a peer to peer application. All traffic goes to the PSN servers >>> and then to clients. Go2MyPC is designed for NAT and in fact one could >>> argue that it wouldn't exist if NAT weren't wide spread. >> >> Errr, are you sure? >> >> http://www.absolute-playstation.com/playstation-network/expert-playstation-3-hardware-accessory-help-playstation3-ps3-console/10976-nat-3-nat-2-a.html >> >> "Re: nat 3 to nat 2 >> >> I tried all the router suggestions and still got nat 3. after much frustration I called my ISP. Do this. Ask if your IP address is private or public. My ISP sets u up as private. I had them change it to public...BINGO Nat 2. Hope this helps." >> >> If you read above, it appears that his ISP ran NAT444 normally, which the PS3 categorizes as nat 3, which means he can't reach COD. Dude, customers MUST reach COD. :) >> >> >> Jack >> > > > -- > Scott Helms > Vice President of Technology > ISP Alliance, Inc. DBA ZCorum > (678) 507-5000 > -------------------------------- > http://twitter.com/kscotthelms > -------------------------------- > > _______________________________________________ > 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 jbates at brightok.net Thu Feb 10 13:07:25 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 12:07:25 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> Message-ID: <4D54295D.3080504@brightok.net> On 2/10/2011 11:47 AM, Owen DeLong wrote: > There is no ability to have Rendezvous hosts in all of the Private2 sectors. > This makes a huge difference in the way applications currently > operate and means that porting to IPv6 is, in most cases, simpler > than incorporating sufficient workarounds to cope with LSN/CGN. > On the other hand, if all LSN/CGN deployments properly hairpin on the public interface, there is no need for rendezvous hosts in all the Private 2 sectors. That only fixes one of many problems, though. Jack From packetgrrl at gmail.com Thu Feb 10 13:24:26 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Thu, 10 Feb 2011 11:24:26 -0700 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: <4D53FE2D.7080802@arin.net> References: <4D53FE2D.7080802@arin.net> Message-ID: Martin As others have asked I am curious why this applies only to legacy space. If someone gives back to ARIN a block of non-legacy space what should ARIN do with it? If ARIN gives it back to the IANA it's stranded there because IANA only has a policy to give /8s to RIRs. Is it written somewhere that non-legacy space will be made available in the ARIN region? Thanks! ----Cathy On Thu, Feb 10, 2011 at 8:03 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 2.0 > > Date: 10 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region within > thirty days of their receipt. > > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > > Timetable for implementation: Immediately > > > > _______________________________________________ > 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 wireless at starbeam.com Thu Feb 10 13:12:34 2011 From: wireless at starbeam.com (Jerry Bacon) Date: Thu, 10 Feb 2011 10:12:34 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> Message-ID: <4D542A92.7040604@starbeam.com> On 2/10/2011 9:47 AM, Owen DeLong wrote: > > This makes a huge difference in the way applications currently operate and means that porting to IPv6 is, in most cases, simpler than incorporating sufficient workarounds to cope with LSN/CGN. This seems like the best reason that I have heard in favor of deploying LSN/CGN. Maybe it will actually push the demand for IPv6 to the point where it becomes essential and more cost effective. -- Jerry Bacon Senior Network Engineer From tedm at ipinc.net Thu Feb 10 14:08:12 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 10 Feb 2011 11:08:12 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <015f01cbc946$fd0b48e0$f721daa0$@iname.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <014d01cb c7cc$226f81e0$674e85 a0$@iname.com> <20110209013106.AAA5F9D6947@drugs.dv.isc.org> <017201cbc803$15a6ef70$40f4ce50$@iname.com> <4D53B19C.3070305@ipinc.net> <015f01cbc946$fd0b48e0$f721daa0$@iname.com> Message-ID: <4D54379C.4030704@ipinc.net> On 2/10/2011 9:21 AM, Frank Bulk wrote: > CPE vendors have tight margins, so they're the first to cut costs and have a > short-term view of things. They figure customers will replace their $30 to > $150 hardware in 3 to 5 years. > > We would all wish CPE vendors had built and sold devices with 8 MB of flash > and had software engineering groups to provide new code for 3-year old > models that includes IPv6 support, but they haven't done it thus far and I'm > not holding my breath to think that they will. And that's where DD-WRT has > a role. If customer prefers to upgrade their router with DD-WRT code so > that they have IPv6 without spending a dime, that's fine with me, but as a > service provider I don't have the resources to support that. > As a service provider you can certainly put up an unsupported but suggested config for an open-wrt or dd-wrt box. That is the normal way that open source software is "supported" As for doing the actual upgrade itself, (which admittedly for most models can be a bit hairy to the general public who has not done it) Ebay is full of routers that are being sold with open-wrt or dd-wrt on them. The usual practice is for the seller to advertise a new router with a markup on it, then when someone buys it, the seller goes to the store, buys the router, flashes it, and ships it off. A guy can make a nice bit of money on the side doing that if he sold enough of them. A new CPE that had IPv6 support in it would cost the customer at least $60-$100, so there is a market for a guy operating out of his house, advertising on craigslist, to charge $30-$40 to come over to the customers house, upgrade their existing router, and set them up with IPv6 once their ISP of choice starts offering it. But to get those guys to appear as a service provider your going to have to have that "suggested but unsupported" config available, since that shows that you have at least tested with it. That is another reason Comcast did the Sourceforge distribution of a modded linksys 160NL load. The point of the post was to indicate that full IPv6 support has always been an option for CPE vendors, because many of them have already sold (in the past) or are selling today, CPE's that have enough storage. The only thing that has prevented it is the CPE vendors haven't wanted to include additional functionality like IPv6, probably because every time you add more knobs to something it increases support costs. It is not because their products aren't technically possible to do it, since most of them have models that it IS technically possible to do it with. Ted > Frank > > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm at ipinc.net] > Sent: Thursday, February 10, 2011 3:36 AM > To: frnkblk at iname.com > Cc: 'Mark Andrews'; arin-ppml at arin.net > Subject: Re: [arin-ppml] inevitability of NAT? > > On 2/8/2011 6:43 PM, Frank Bulk wrote: >> Mark: >> >> The hardware came before the implementation of IPv6 support. > > wrong. Most small CPE's are built on Linux and that has IPv6 support > for many years. > > They tried to >> fit in existing hardware, but it didn't work. > > Not true. Quite a lot of existing hardware will fit it. And some > existing hardware can be modified very simply to fit it - for example: > > http://www.dd-wrt.com/phpBB2/viewtopic.php?p=530360 > > Netgear WGR614 v9 - user soldered on a jtag, and replaced dram chip and > is going to be doing the flash chip - that was last week. There is > absolutely no need to redesign the entire thing. > > or > > http://www.neophob.com/2006/01/wrt54g-ram-upgrade/ > > that one is a ram update. Or > > http://www.dd-wrt.com/phpBB2/viewtopic.php?t=43386&postdays=0&postorder=asc& > start=0 > > wrt54g v8 with 2MB flash, was upgraded to 8MB flash by the user. > > > I repeat, NO NEED FOR REDESIGNS!!! > > Future hardware revisions of >> some models will include expanded storage, allowing for SPI support. >> > > It is a lot more accurate to say that future hardware revs will > NOT ship with limited flash. The real truth though is in the CPE market > there have always been versions that had adequate storage. > > What happened in the CPE market was the > earlier CPE's had more flash. The later versions had less flash. But > it has been known since 2008 that you cannot fit a full IPv6 > implementation into anything less than 8MB. However, you CAN fit an > IPv6 implementation - WITH an IPv6 firewall - into 4MB if you give up > dhcpv6. It's been done. > > The Comcast "IPv6 open-wrt reference implementation" which is a "full" > IPv6 implementation on Sourceforge was built to run in 8MB of flash. > This is an adequate amount of flash and will serve CPEs for some time. > The Comcast load is, IMHO, intended for Comcast to be able to pressure > it's CPE vendors to put in IPv6 so that they cannot make ridiculous > excuses like they can't do it without making a super expensive CPE. > > Here is a list of common CPE models with 8MB of flash. Some are older > and no longer shipping. Some are new and are currently shipping. > D-link has both an older and a newer model with the required 8MB so they > cannot make that excuse that they "tried" fitting it in. Baloney. They > didn't try at all. They just put out a deficient IPv6 stack in a 4MB > router, hoping nobody would notice. > > ALL of these can have special loads built that run a full IPv6 stack: > > Accton > > MR3201A > > ActionTec > > MI424WR > > ASUS > > RT-N16 > WL-500gP > WL-500W > > Buffalo > > WAPM- HP- AM 54G54 > WZR-HP-G300NH > WZR-HP-G301NH > WZR-RS-G54 > > Cisco/Linksys > > WRT54G-RG > WRT54GS (version 1 through 3.) > WRTSL54GS > E2000 > E2100L > E3000 > WRT160NL > WRT300N v1.1 > WRT320N > WRT350N > WRT400N > WRT600N > WRT610N > > D-link: > > DIR-330 ver A1 > DIR-825 version B1 and B2 > > Netgear > > WNDR3700 > WNDR3500L > > US Robotics > > USR5453 > > >> I suspect that most consumer/SOHO router vendors are in the same > predicament >> at D-Link. >> > > No, they are not. Most if not all have designs they have shipped or are > shipping now that they can come out with newer flash versions that > support IPv6 because they ALREADY HAVE the required amount of storage. > > And of their designs that they have shipping now that don't have > adequate storage, it is simplicity to ship those with adequate storage, > they just replace one flash chip part number with another - nothing else > in the design needs to be changed. > > Ted > >> We can complain about the past, but that won't change anything. Better to >> make current and future purchasing decisions about what's out there -- I > am. >> >> Frank >> >> -----Original Message----- >> From: Mark Andrews [mailto:marka at isc.org] >> Sent: Tuesday, February 08, 2011 7:31 PM >> To: frnkblk at iname.com >> Cc: 'Ted Mittelstaedt'; arin-ppml at arin.net >> Subject: Re: [arin-ppml] inevitability of NAT? >> >> >> In message<014d01cbc7cc$226f81e0$674e85a0$@iname.com>, "Frank Bulk" > writes: >>> Due to device (storage) limitations D-Link wasn't able to put a firewall >> in >>> many of its IPv-6 capable releases for its different hardware models, but >>> DIR-655 is supposed to support SPI. >>> >>> Frank >> >> Also IPv6 equipment should be capable of being put on the net without >> a seperate firewall. If it isn't then the product really isn't fit >> for the purpose it was designed for. Its been a hostile net for >> the entire time IPv6 has existed and that should have been factored >> into the design. A seperate firewall provides additional isolation >> but shouldn't be needed. >> >> Giving a device a ULA and not a public address if it doesn't need to >> talk to the world will give you as much protection as a NAT gives. >> >> Feature parity should also be there. I've got a Brother network >> printer that has accept/deny filters for IPv4 but not for IPv6. I >> don't know what they were thinking. IPv6 doesn't need accept/deny >> filters but IPv6 does? It would have been less than a days work >> to add them as they already have them working for IPv4. A bit more >> for testing and documentation. At least I can set the IPv6 address >> statically to a ULA. >> >> Mark > > From mueller at syr.edu Thu Feb 10 15:41:55 2011 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 10 Feb 2011 15:41:55 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> Bill: for some reason your response ended up in my spam box and languished there for several days. Possibly my School's spam filter is more intelligent than I thought ;-) > -----Original Message----- > > So what? So unless you want to revisit all of the problems with markets > encountered since the feudal era, I don't think it's productive for either of us to get involved in a historical argument about political economy, especially when that topic does not fall within the scope of this group and the expertise of at least one of us, and the rest of the list will simply turn this into an opinion-venting opportunity to tell us whether they are for or against some abstraction called "markets" Let's keep the discussion grounded. The basic, unalterable fact is that we are going to have address transfers. These are - regardless of what ARIN or this list or the community choose to call them - a transfer of a (limited, conditional) property rights when transfers take place. So the only issue we should be debating here is whether the transfers must go through ARIN or can holders lease them out directly without invoking the transfer process. Note Well: either case would be "leaseholds" under your definition!! If we go through ARIN, ARIN is the freeholder and it leases to others. And both cases would be mediated by market prices when there is competition for the resource. The only difference is that the more liberal, direct form of leasing allows buyers of address capacity to bid without going through ARIN's bureaucracy. I think this benefit both the transacting parties and ARIN. I don't think "demonstrated need" is an issue because I don't think many buyers are going to pay some ISP substantial monthly sums for a service that they don't "need". I simply think we can let the market do this for us. > For anyone not familiar with the terms, a freehold is where you buy the > house and the land, while a leasehold is where you buy the house and the > right to use the land for 99 years or some such. Freeholds are The Way > It Is for residential real estate in most of the US and Canada, but > they're very hard to come by in parts of Europe and Asia. > Historically, much of the 19th century immigration to the new world was > driven by the promise of escaping the European landlords. Can't help adding, the European landlord system was more akin to the internet community's classical address allocation policies than to a market. Land ownership was based on status, family ties, and privilege, not markets. > With ownership spread thin enough, you get a free market in which > Freeholds and Leaseholds compete for best value. But even in the US it > takes tax incentives (mortgage interest write off) and other government > interference to prevent that ownership from coalescing with a few > barons, after which the market is closed. Huh? No economist that I know of sees the mortgage interest write off as anything but a government subsidy to middle class home ownership. It has absolutely nothing to do with preserving and open and free market. Indeed, in case you hadn't noticed these kinds of govt interventions in the housing market played a big role in creating the housing bubble that led to the financial crisis. From owen at delong.com Thu Feb 10 15:45:48 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 12:45:48 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> Message-ID: <9EB61C47-C043-4D16-811D-E15C242CD9D2@delong.com> On Feb 10, 2011, at 7:42 AM, Benson Schliesser wrote: > > On Feb 10, 2011, at 8:41 AM, Scott Helms wrote: > >>> They work through CONSUMER NAT because consumer NAT has nat traversal facilities like uPNP. >>> >>> LSN/CGNAT is a whole different ballgame. >>> >> >> Lets step back a moment. Why is LSN/CGNAT different from consumer NAT? Is it only because of a perceived lack of knobs? >> >> If I am going to explain to a CFO that "CGNAT is bad" I have to articulate exactly why its bad. While I don't know if this is the case or not there is no reason that the CGNAT vendors can't expose to end users the ability create forwarding rules based on user profiles (could be stored in TR-069, RADIUS, DHCP, LDAP, or even DDNS). I may be naive here because I haven't actually verified with Cisco and the others that they are planning this but if their product managers missed something that obvious I will be greatly surprised. While UPnP will not be part of that solution for obvious reasons building a web page that works with some sort of storage directory is trivial. > > CGN is a NAT, and is essentially just a higher-scale implementation of the NAT that we all know and "love". I think you're right to challenge the oft-repeated belief that CGN is somehow fundamentally different. That being said, the deployment model of CGN is significantly different from CPE-based NAT, and that fact does results in some differences in how it can be used. The two fundamental differences are fairly obvious: 1) CGN is run by a carrier, and so the subscriber doesn't necessarily have the same degree of control. 2) CGN allows for greater oversubscription of public IP addresses, and so there is potentially a many-to-one relationship between subscribers and public addresses. > You left out 3) Most CGN implementations will be a second layer in front of an existing consumer CPE NAT solution. > The implications of #1 are the things you described above. Static port forwarding is a problem unless the subscriber is given a tool to configure it. And even then, it's something that doesn't scale very well - e.g. static entries for every subscriber rule, managed across a number of redundant CGN nodes, which may each have different public address pools, etc. My personal opinion is that static port forwarding (for running servers at home, let's say) is better served by paying for a static public IP address from the ISP. (Conversely, ISPs should offer static public addresses in order to support "server" users.) In terms of dynamic port forwarding for apps that require that kind of functionality, CGN generally doesn't support UPNP for obvious reasons. But there is work in the IETF to develop a protocol called PCP, that improves on UPNP (and similar protocols) in a number of ways. Generally speaking, PCP will be much better suited for dynamic control of a CGN by clients. > In the meantime, until PCP is available, users should consider turning off UPNP support in their gateway to make sure apps don't rely on it when they're behind a CGN. > > The implications of #2 are typically related to things like dynamic DNS entries. Of course, this is mostly relevant for people doing static port forwarding, which has other complications per my comment above. But to be specific: if you're sharing an IP address, and that address is registered in DNS, then it's possible the DNS entry will actually point to a number of completely different server resources (depending on port number, of course). E.g. webcam.myhouse.whatever might point to an IP address, and listening on port 8080 might be my webcam while listening on port 8081 might be my neighbor's webcam; webcam.neighborshouse.whatever in the DNS might point to the same IP address. > The implications of #3 are that most of the current NAT traversal technologies cannot and will not function. > By the way, these implications are true for essentially any form of CGN, because the deployment model is the same (deployed in the carrier's network). Arguments about DS-lite versus NAT444 are a bit misleading. And in any case, the right conclusion is to deploy IPv6 (via 6rd if one must, native as soon as one can) to avoid this whole mess.* > Not quite. DS-Lite avoids the issues associated with #3 and has the additional advantage that native IPv6 comes along for the ride. > Cheers, > -Benson > > > * - Full Disclosure: I am employed by Cisco Systems, which I assume is happy to sell NAT hardware as well as IPv6-capable routers. However, my statements and opinions are my own and do not represent my employer, fellow employees, friends, family, or any other entity. > > > _______________________________________________ > 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 Feb 10 16:04:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 13:04:25 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <4D540CB0.2020902@brightok.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> <4D540CB0.2020902@brightok.net> Message-ID: On Feb 10, 2011, at 8:05 AM, Jack Bates wrote: > > > On 2/10/2011 9:42 AM, Benson Schliesser wrote: >> In the meantime, until PCP is available, users should consider >> turning off UPNP support in their gateway to make sure apps don't >> rely on it when they're behind a CGN. > > User got a faulty DSL modem a few months back. uPNP wasn't enabled per the norm. User was unable to use some xbox functionality. > > The degree at which things are depending on uPNP has grown to making it almost mandatory. Turning it off is likely to lead to things breaking. In addition, no protocol is going to fix LSN well. I don't think any studies have really been done to see at what scale applications are currently using uPNP to (port forward, open firewall). This places practical limits on the number of people doing a certain thing while behind a single IP. > This is more true than even I would have suspected. Indeed, there are actually applications that break in the absence of uPNP even in a situation where the host doesn't have a stateful firewall or NAT in front of it. Apple's "Back to my Mac" service will not discover or display a workstation to someone if that workstation is not behind a uPNP capable firewall. Yes, I can get to my systems using Apple's VNC client. However, I do find it interesting that I can't use their MobileMe based service with my systems that have public addresses and no stateful firewall in front of them. Owen From bensons at queuefull.net Thu Feb 10 16:17:28 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 15:17:28 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> Message-ID: <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> On Feb 10, 2011, at 2:58 PM, Owen DeLong wrote: >> In terms of CGN44 versus NAT444, I'd like to see evidence of something that breaks in NAT444 but not CGN44. People seem to have a gut expectation that this is the case, and I'm open to the possibility. But testing aimed at demonstrating that breakage hasn't been very scientific, as discussed in the URLs I posted with my previous message. >> > Technologies which depend on a rendezvous host that can know about both sides of both NATs in a private->public->private > scenario will break in a private->private2->public->private2->private scenario. There are technologies and applications which > depend on this. (I believe, among others, that's how many of the p2p systems work, no?) This is an oft-repeated rumor, but as I stated in my recent message: the evidence doesn't support the theory. NAT traversal architectures that leverage "public" rendezvous such as STUN, etc, should continue to work and testing demonstrates this. The tiering of NAT does mean that "neighborhood-local" traffic must traverse the CGN, which is sub-optimal but not broken. Dynamic control protocols like UPNP are the only source of problems I'm aware of. Frequently, the solution for a given app is as simple as turning off UPNP. But in the near future, PCP will replace and/or augment UPNP and is more scalable. If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains. We've known this for a long time. Cheers, -Benson From owen at delong.com Thu Feb 10 16:44:15 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 13:44:15 -0800 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <821C9067-1C8C-4453-B9AB-AC14489E2FCE@queuefull.net> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> <4D540CB0.2020902@brightok.net> <821C9067-1! C8C-4453-B9AB-AC14489E2FCE@queuefull.net> Message-ID: <8C3975B8-3102-48FA-A555-18AE6E428027@delong.com> On Feb 10, 2011, at 8:30 AM, Benson Schliesser wrote: > > On Feb 10, 2011, at 10:05 AM, Jack Bates wrote: > >> On 2/10/2011 9:42 AM, Benson Schliesser wrote: >>> In the meantime, until PCP is available, users should consider >>> turning off UPNP support in their gateway to make sure apps don't >>> rely on it when they're behind a CGN. >> >> User got a faulty DSL modem a few months back. uPNP wasn't enabled per the norm. User was unable to use some xbox functionality. >> >> The degree at which things are depending on uPNP has grown to making it almost mandatory. Turning it off is likely to lead to things breaking. In addition, no protocol is going to fix LSN well. I don't think any studies have really been done to see at what scale applications are currently using uPNP to (port forward, open firewall). This places practical limits on the number of people doing a certain thing while behind a single IP. > > My opinion, to some extent, is that in the coming years: clients that require IPv4 but don't work well with NAT should expect to break. On the other hand, clients with IPv6 support should experience an improved experience. > While I agree, that's very different from saying that "clients that work well with IPv4 NAT today should expect to break tomorrow." > That said, UPNP (and NAT-PMP etc) just don't scale to the carrier scope. PCP is coming, and clients should expect to migrate if they need IPv4 NAT support. PCP will also support IPv6 pinholes (i.e. control of security in IPv6-enabled CPE), so clients should migrate regardless. > Why would anyone bother porting application code to PCP instead of just adding IPv6 capabilities? It seems to me that adding IPv6 is usually much simpler than adding PCP support and yields a much longer lifetime. The point is that we need to continue to support some applications that will not see upgrades. Telling application vendors to add support for two future paths (or worse, having them randomly choose between them) is completely the wrong direction for this. If we're going to attempt to make multi-layer NAT support for legacy applications, we should do what we can to make that support cope with what exists today. Diverting effort from IPv6 porting to backport more hacks to deal with an expanding complexity of the IPv4 NAT environment reminds me of the old joke that starts out "Doctor! Doctor! It hurts when I do this!" Owen From bill at herrin.us Thu Feb 10 16:56:09 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Feb 2011 16:56:09 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Thu, Feb 10, 2011 at 3:41 PM, Milton L Mueller wrote: > Let's keep the discussion grounded. The basic, unalterable fact > is that we are going to have address transfers. These are - > regardless of what ARIN or this list or the community choose > to call them - a transfer of a (limited, conditional) property rights > when transfers take place. > > Note Well: either case would be "leaseholds" under your definition!! > If we go through ARIN, ARIN is the freeholder and it leases to others. Milton, You are mistaken to describe ARIN as a lessor. ARIN holds the sociopolitical role of governing authority. It enforces the general rules for number resource possession in a particular geographic territory. It sets those rules through a formal public policy process. It charges only what money it requires to operate. It is no more correct to compare direct ARIN registrants to lessees than it would be to describe my home as leased from the Commonwealth of Virginia or describe my property taxes as rent. If you insist on viewing ARIN in commercial terms, it's closest analog is a condominium of which the resource holders each own a voting share. That's still equivalent to freehold property, hence my allegory of direct ARIN registrants as freeholders (including those who receive addresses through transfers) while holders of reassignments are effectively lessees. > Huh? No economist that I know of sees the mortgage interest > write off as anything but a government subsidy to middle > class home ownership. And why is that important, Milton? What's so valuable about middle class ownership of property that every US administration in your lifetime, Democrat, Republican, Liberal, Conservative, every single administration has incentivized ownership despite the loss of tax revenue. Why would the governing authority want that? Do you get it? Because the -reasons- are applicable here as well. > So the only issue we should be > debating here is whether the transfers must go through ARIN > or can holders lease them out directly without invoking the > transfer process. > that topic does not fall within [...] the expertise of at least one of us That debate will indeed be difficult if only one of us is capable of offering an educated opinion. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bensons at queuefull.net Thu Feb 10 16:59:10 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 15:59:10 -0600 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: <8C3975B8-3102-48FA-A555-18AE6E428027@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> <4D540CB0.2020902@brightok.net> <821C9067-1! C8C-4453-B9AB-AC14489E2FCE@queuefull.net> <8C3975B8-3102-48FA-A555-18AE6E428027@delong.com> Message-ID: <7F4F5E2E-5BB6-457D-A7A0-192F3BEB8553@queuefull.net> On Feb 10, 2011, at 3:44 PM, Owen DeLong wrote: >> That said, UPNP (and NAT-PMP etc) just don't scale to the carrier scope. PCP is coming, and clients should expect to migrate if they need IPv4 NAT support. PCP will also support IPv6 pinholes (i.e. control of security in IPv6-enabled CPE), so clients should migrate regardless. >> > Why would anyone bother porting application code to PCP instead of just adding IPv6 capabilities? It seems to me that adding IPv6 is usually much simpler than adding PCP support and yields a much longer lifetime. The two (IPv6 and PCP) are complimentary. As I said in my previous message (I've been saying that a lot today...), PCP supports pinhole creation for IPv6. Given that draft-ietf-v6ops-ipv6-cpe-router includes a simple security requirement, as documented in draft-ietf-v6ops-cpe-simple-security, PCP will be useful for the same reasons UPNP has been useful to app developers. Cheers, -Benson From bensons at queuefull.net Thu Feb 10 17:04:09 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 16:04:09 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> On Feb 10, 2011, at 3:56 PM, William Herrin wrote: > You are mistaken to describe ARIN as a lessor. ARIN holds the > sociopolitical role of governing authority. It enforces the general > rules for number resource possession in a particular geographic > territory. It sets those rules through a formal public policy process. > It charges only what money it requires to operate. It is no more > correct to compare direct ARIN registrants to lessees than it would be > to describe my home as leased from the Commonwealth of Virginia or > describe my property taxes as rent. U.S. law starts with the Constitution (and prior traditions), delegates authority to the 3 federal branches and the states, etc, etc. You know all of this. Where does ARIN fit into that governance structure? What legal authority does ARIN have to govern anybody against their will? I'm not talking about appeals to "community" and "consensus", which are fundamentally good things that carry little-to-no legal weight. Cheers, -Benson From bill at herrin.us Thu Feb 10 17:27:40 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Feb 2011 17:27:40 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> Message-ID: On Thu, Feb 10, 2011 at 5:04 PM, Benson Schliesser wrote: > On Feb 10, 2011, at 3:56 PM, William Herrin wrote: >> You are mistaken to describe ARIN as a lessor. ARIN holds the >> sociopolitical role of governing authority. It enforces the general >> rules for number resource possession in a particular geographic >> territory. It sets those rules through a formal public policy process. >> It charges only what money it requires to operate. It is no more >> correct to compare direct ARIN registrants to lessees than it would be >> to describe my home as leased from the Commonwealth of Virginia or >> describe my property taxes as rent. > > U.S. law starts with the Constitution (and prior traditions), delegates > authority to the 3 federal branches and the states, etc, etc. > You know all of this. > > Where does ARIN fit into that governance structure? ?What legal > authority does ARIN have to govern anybody against their will? > I'm not talking about appeals to "community" and "consensus", > which are fundamentally good things that carry little-to-no legal weight. Hi Benson, Where do Canadian laws fit into that structure? And the rules set by your homeowner's association? Did you know that a Board of Directors or a Board of Trustees is often referred to as a Governance Board or Governing Board? Do you know why? What authority does ARIN have? Try announcing a route to addresses ARIN has registered to someone else. See how long it lasts. ARIN has precisely the authority that the folks who operate the Internet choose to give it. They choose to give it the authority to determine who the legitimate user of each North American Internet number resource is. Because the operators choose to give ARIN the authority to govern the assignment of addresses, ARIN has that governing authority. It's not contractual or legal, it's conventional. ARIN's legal framework merely supports and stabilizes the structure. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bensons at queuefull.net Thu Feb 10 17:40:45 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 16:40:45 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> Message-ID: On Feb 10, 2011, at 4:27 PM, William Herrin wrote: > What authority does ARIN have? Try announcing a route to addresses > ARIN has registered to someone else. See how long it lasts. ARIN has > precisely the authority that the folks who operate the Internet choose > to give it. Right - ARIN is a non-profit business league incorporated under U.S. law in Virginia. So, ARIN is hardly comparable to a state government, tax authority, etc. Further, ARIN is subject to the same liability as any other non-governmental actor. (This might include anti-trust, price fixing, etc, but more to the point would also include liability for property theft, fraud, direct and incidental damages, etc.) Don't get me wrong - I support ARIN's role in the community. My argument is that extending that role into behaviors that might be illegal is a dangerous idea. Cheers, -Benson From bill at herrin.us Thu Feb 10 18:00:12 2011 From: bill at herrin.us (William Herrin) Date: Thu, 10 Feb 2011 18:00:12 -0500 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> Message-ID: On Thu, Feb 10, 2011 at 5:40 PM, Benson Schliesser wrote: > My argument is that extending that role into > behaviors that might be illegal is a dangerous idea. Hi Benson, I certainly can't argue with that, but I'm less clear what relationship you think it has with anything I said. I used freehold and leasehold real estate as metaphors for the existing direct ARIN registrations and ISP reassignments respectively because I believe they share similar traits that provide useful perspective on the "address leasing" issue. I absolutely DO NOT propose that ARIN somehow attempt to alter its framework of contract and convention to match the legal operation of leasehold and freehold property. Regards, Bill -- 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 Thu Feb 10 18:11:45 2011 From: jcurran at arin.net (John Curran) Date: Thu, 10 Feb 2011 23:11:45 +0000 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> Message-ID: <69B8C485-CBE2-4212-A64D-3229274F0AEC@corp.arin.net> On Feb 10, 2011, at 6:40 PM, Benson Schliesser wrote: > On Feb 10, 2011, at 4:27 PM, William Herrin wrote: > >> What authority does ARIN have? Try announcing a route to addresses >> ARIN has registered to someone else. See how long it lasts. ARIN has >> precisely the authority that the folks who operate the Internet choose >> to give it. > > Right - ARIN is a non-profit business league incorporated under U.S. law in Virginia. So, ARIN is hardly comparable to a state government, tax authority, etc. Further, ARIN is subject to the same liability as any other non-governmental actor. (This might include anti-trust, price fixing, etc, but more to the point would also include liability for property theft, fraud, direct and incidental damages, etc.) Correct. A good reason for any organization not to engage in such things (in addition to the moral reasons not to :-) > Don't get me wrong - I support ARIN's role in the community. My argument is that extending that role into behaviors that might be illegal is a dangerous idea. Not a problem at all, but the advice is always appreciated. We'd appreciate clarity from the community in how they'd like the subject of "leasing" handled, since we ultimately have to must the resources accordingly to the community- developed policies. Thanks! /John John Curran President and CEO ARIN From marka at isc.org Thu Feb 10 18:19:23 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 11 Feb 2011 10:19:23 +1100 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: Your message of "Thu, 10 Feb 2011 12:45:48 -0800." <9EB61C47-C043-4D16-811D-E15C242CD9D2@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <9EB61C47-C043-4D16-811D-E15C242CD9D2@delong.com> Message-ID: <20110210231924.051A69E3575@drugs.dv.isc.org> In message <9EB61C47-C043-4D16-811D-E15C242CD9D2 at delong.com>, Owen DeLong writes : > Not quite. DS-Lite avoids the issues associated with #3 and has the additional > advantage that native IPv6 comes along for the ride. And you don't even need native IPv6. DS-lite will work on top of 6rd and should give a better "experience" than NAT444. If you can route Class E between the CPE and the 6rd BR you can give your customers stable IPv6 addresses today. It just requires 1 more routing entry in the CPE for the 6rd BR. You can then do 2:1 with DS-Lite and half the address space you were handing to customers is reusable. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From marka at isc.org Thu Feb 10 18:23:44 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 11 Feb 2011 10:23:44 +1100 Subject: [arin-ppml] inevitability of NAT? In-Reply-To: Your message of "Thu, 10 Feb 2011 13:44:15 -0800." <8C3975B8-3102-48FA-A555-18AE6E428027@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC1386B@RWC-EX1.corp.seven.com> <3F9A227C-3461-425D-BBF7-222E8D2E90C1@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13871@RWC-EX1.corp.seven.com> <134A5454-2CE4-48EB-A6BE-5A806DFBEEA3@queuefull.net> <4D4C84DE.1060208@ipinc.net> <839813.74109.qm@web63302.mail.re1.yahoo.com> <4D4F9564.1010500@ipinc.net> <86BED643-5CD9-4BD3-9C74-7E6AA34D8BDD@delong.com> <4D52EF53.! 103@office.tcsn.net> <4D531AD5.6060507@zcorum.com> <5EF8CFBE-F424-44D5-BDFF-6B22C3EA1409@delong.com> <4 D53F920.8040804@zcorum.com> <4D540CB0.2020902@brightok.net> <821C9067-1! C8C-4453-B9AB-AC14489E2FCE@queuefull.net> <8C3975B8-3102-48FA-A555-18AE6E428027@delong.com> Message-ID: <20110210232344.31FF79E38A5@drugs.dv.isc.org> In message <8C3975B8-3102-48FA-A555-18AE6E428027 at delong.com>, Owen DeLong writes : > Why would anyone bother porting application code to PCP instead of just adding > IPv6 capabilities? It seems to me that adding IPv6 is usually much simpler th > an adding PCP support and yields a much longer lifetime. You want PCP to control the firewall so you want to add both IPv6 and PCP. Makk -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jcurran at arin.net Thu Feb 10 18:46:41 2011 From: jcurran at arin.net (John Curran) Date: Thu, 10 Feb 2011 23:46:41 +0000 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <69B8C485-CBE2-4212-A64D-3229274F0AEC@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> <69B8C485-CBE2-4212-A64D-3229274F0AEC@corp.arin.net> Message-ID: <4BDFDB36-AD14-408F-A3F7-3AFFE44E4EAD@corp.arin.net> On Feb 10, 2011, at 7:11 PM, John Curran wrote: > ... > Not a problem at all, but the advice is always appreciated. We'd appreciate > clarity from the community in how they'd like the subject of "leasing" handled, > since we ultimately have to must the resources accordingly to the community- > developed policies. There was almost an entire sentence in there (somewhere); it should read: Not a problem at all, but the advice is always appreciated. We'd appreciate clarity from the community in how they'd like the subject of "leasing" handled, since we ultimately must manage the resources accordingly to the community- developed policies. :-) /John John Curran President and CEO ARIN From bensons at queuefull.net Thu Feb 10 19:27:32 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 10 Feb 2011 18:27:32 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers (was: Re: And so it ends... ) In-Reply-To: <4BDFDB36-AD14-408F-A3F7-3AFFE44E4EAD@corp.arin.net> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> <3D3807F0-C6FB-437C-B2DB-B4355A64AD03@queuefull.net> <69B8C485-CBE2-4212-A64D-3229274F0AEC@corp.arin.net> <4BDFDB36-AD14-408F-A3F7-3AFFE44E4EAD@corp.arin.net> Message-ID: <3BFAED4C-AA21-4D55-9F4F-02319F7E4D0A@queuefull.net> On Feb 10, 2011, at 5:46 PM, John Curran wrote: > Not a problem at all, but the advice is always appreciated. We'd appreciate > clarity from the community in how they'd like the subject of "leasing" handled, > since we ultimately must manage the resources accordingly to the community- > developed policies. I just submitted a policy proposal that should encourage this discussion. Cheers, -Benson From jbates at brightok.net Thu Feb 10 21:19:28 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 20:19:28 -0600 Subject: [arin-ppml] "Leasing" of space via non-connectivity providers In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29B0C@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4D549CB0.4030902@brightok.net> On 2/10/2011 2:41 PM, Milton L Mueller wrote: > The only difference is that the more liberal, direct form of leasing allows buyers of address capacity to bid without going through ARIN's bureaucracy. I think this benefit both the transacting parties and ARIN. I don't think "demonstrated need" is an issue because I don't think many buyers are going to pay some ISP substantial monthly sums for a service that they don't "need". I simply think we can let the market do this for us. It should be noted that ARIN's policy is around transfers. Leasing is a different matter. It should also be noted, that to some degree, all suballocations issued from an ISP downstream is a form of lease. Sometimes there is direct monetary exchange, while often it is conditional lease based on connectivity. However, it is not unheard of for someone to leave an ISP and the ISP allow them to take the address space for a fee. Nor is it unheard of for people to operate as a pure LIR (not an ISP), which while referenced by ARIN is often not assigned any value outside of the term ISP. However, there are LIRs, and they often due charge for the use of address space they are assigned. Jack From Barron.Hulver at oberlin.edu Thu Feb 10 22:47:58 2011 From: Barron.Hulver at oberlin.edu (Barron Hulver) Date: Thu, 10 Feb 2011 22:47:58 -0500 Subject: [arin-ppml] Application requests for IPv6? Message-ID: <4D54B16E.7040607@oberlin.edu> I don't read this list enough to be fully informed on all the issues regarding application requests for IPv6 end-user address space, so please pardon me if my understanding is not correct. We have a medium-sized end-user network and the number of IPs used will continue to grow as more mobile devices support Wi-Fi and other devices connect to the network (e.g. more game systems, printers, TVs, etc.) We have a legacy address space (class B or /16). For historical reasons IPs are assigned throughout the address space (sparsely populated) and it would be quite a bit of work to condense this. We have not signed the legacy resources agreement. I understand the advantage of conserving routing table space due to a hierarchical addressing/routing structure. However, we would like to obtain an IPv6 allocation from ARIN so that in the future we do not have to go through the work of renumbering devices with static IPs (e.g. servers) and reconfiguring security devices (e.g. firewalls) if we decide to switch ISPs. Also, in the future it is likely that we will want to be multihomed because so many of our important services are moving to the cloud (e.g. Google Apps for Edu and Google Marketplace applications). We are probably not alone in our thinking. We started deploying IPv6 about two years ago after we obtained an assignment from our ISP, OARnet (Ohio Academic Resources Network). We have the important services ready (DNS, DHCP, routing, firewalls, NTP, etc) and we have a token web server up (http://www.ipv6.oberlin.edu). From my limited perspective it seems that a request for end-user IPv6 address space from ARIN is tied to IPv4 address space and that may be hindering deployment. An end-user organization should be able to obtain an IPv6 allocation independent of IPv4 allocations. It sounds like 2010-8 will decouple this and is a step in the right direction. Barron Barron Hulver Director of Networking, Operations, and Systems Center for Information Technology Oberlin College 148 West College Street Oberlin, OH 44074 440-775-8798 Barron.J.Hulver at oberlin.edu http://www2.oberlin.edu/staff/bhulver/ NRPM 6.5.8.1 offers several ways for an end user organization to qualify foran IPv6 assignment from ARIN. The criteria that most often applies is when the organization can "qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect". There is no requirement to have a signed RSA/LRSA under this criteria. An organization can qualify for IPv6, regardless of whether they have existing IPv4 space, as long as it can meet the criteria of ANY existing IPv4 policy in effect. Once qualified, if they choose to proceed, they are assigned the IPv6 resources under the standard RSA. FYI, /John John Curran President and CEO ARIN 6.5.8.1. Criteria To qualify for a direct assignment, an organization must: a. not be an IPv6 LIR; and b. qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA, or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. . >From the NRPM: 6.5.8.1. Criteria To qualify for a direct assignment, an organization must: not be an IPv6 LIR; and qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA, or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. So, if you're not already an IPv6 LIR (ISP) then you have to meet ONE of the criteria from section b: + Qualify for IPv4 under existing policy currently in effect or + demonstrate efficient utilization of all IPv4 assignments and allocations with each being covered by an RSA or LRSA. or + Be a qualifying Community Network as defined in Section 2.8. Note that the first one and third one do not require your IPv4 space to be covered by RSA or LRSA. In addition to this, this policy will soon be superseded by 2010-8 which will replace it with the following text: 6.5.8. Direct assignments from ARIN to end-user organizations 6.5.8.1 Initial Assignment Criteria Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to: ? An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc? ? Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 2000 or more individuals either internal or external to the organization. ? An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193). ? An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS. This version will remove the requirement for RSA/LRSA on the IPv4 space altogether. Owen From jbates at brightok.net Thu Feb 10 23:14:49 2011 From: jbates at brightok.net (Jack Bates) Date: Thu, 10 Feb 2011 22:14:49 -0600 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: <4D54B16E.7040607@oberlin.edu> References: <4D54B16E.7040607@oberlin.edu> Message-ID: <4D54B7B9.7070604@brightok.net> On 2/10/2011 9:47 PM, Barron Hulver wrote: > From my limited perspective it seems that a request for end-user IPv6 > address space from ARIN is tied to IPv4 address space and that may be > hindering deployment. An end-user organization should be able to > obtain an IPv6 allocation independent of IPv4 allocations. It sounds > like 2010-8 will decouple this and is a step in the right direction. > Actually, I think you fall under 6.5.8.1b "qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect" Just because you haven't received an IPv4 assignment, if you would qualify for one (can show usage of your legacy IPv4 to meet the IPv4 requirements for obtaining PI), then you would qualify for IPv6. I agree that a decoupling is in order, but I do not believe this precludes you from qualifying. Jack From owen at delong.com Fri Feb 11 02:03:42 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Feb 2011 23:03:42 -0800 Subject: [arin-ppml] Application requests for IPv6? In-Reply-To: <4D54B16E.7040607@oberlin.edu> References: <4D54B16E.7040607@oberlin.edu> Message-ID: Barron, It actually isn't. IPv4 is ONE of many ways you can qualify for IPv6 space from ARIN. There is a transition in end-user policies under way, and, from the sound of what you are describing, you also have the option of applying as an ISP which gives you even more policy options. I would suggest a careful reading of the Number Resource Policy Manual. Specifically, section 6 covers IPv6 allocations (ISPs) and assignments (end users). If you have any questions after reviewing the manual, the ARIN Registration Services Help desk is available to assist you with clarifications and to help you find the best way to match your institution to the appropriate policy. Owen On Feb 10, 2011, at 7:47 PM, Barron Hulver wrote: > > I don't read this list enough to be fully informed on all the issues regarding application requests for IPv6 end-user address space, so please pardon me if my understanding is not correct. We have a medium-sized end-user network and the number of IPs used will continue to grow as more mobile devices support Wi-Fi and other devices connect to the network (e.g. more game systems, printers, TVs, etc.) We have a legacy address space (class B or /16). For historical reasons IPs are assigned throughout the address space (sparsely populated) and it would be quite a bit of work to condense this. We have not signed the legacy resources agreement. > > I understand the advantage of conserving routing table space due to a hierarchical addressing/routing structure. However, we would like to obtain an IPv6 allocation from ARIN so that in the future we do not have to go through the work of renumbering devices with static IPs (e.g. servers) and reconfiguring security devices (e.g. firewalls) if we decide to switch ISPs. Also, in the future it is likely that we will want to be multihomed because so many of our important services are moving to the cloud (e.g. Google Apps for Edu and Google Marketplace applications). We are probably not alone in our thinking. > > We started deploying IPv6 about two years ago after we obtained an assignment from our ISP, OARnet (Ohio Academic Resources Network). We have the important services ready (DNS, DHCP, routing, firewalls, NTP, etc) and we have a token web server up (http://www.ipv6.oberlin.edu). > > From my limited perspective it seems that a request for end-user IPv6 address space from ARIN is tied to IPv4 address space and that may be hindering deployment. An end-user organization should be able to obtain an IPv6 allocation independent of IPv4 allocations. It sounds like 2010-8 will decouple this and is a step in the right direction. > > > Barron > > Barron Hulver > Director of Networking, Operations, and Systems > Center for Information Technology > Oberlin College > 148 West College Street > Oberlin, OH 44074 > 440-775-8798 > Barron.J.Hulver at oberlin.edu > http://www2.oberlin.edu/staff/bhulver/ > > > > > > > NRPM 6.5.8.1 offers several ways for an end user organization to qualify foran IPv6 assignment from ARIN. The criteria that most often applies is when the organization can "qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect". There is no requirement to have a signed RSA/LRSA under this criteria. An organization can qualify for IPv6, regardless of whether they have existing IPv4 space, as long as it can meet the criteria of ANY existing IPv4 policy in effect. Once qualified, if they choose to proceed, they are assigned the IPv6 resources under the standard RSA. > > FYI, > /John > > John Curran > President and CEO > ARIN > > > 6.5.8.1. Criteria > To qualify for a direct assignment, an organization must: > a. not be an IPv6 LIR; and > b. qualify for an IPv4 assignment or allocation from ARIN > under the IPv4 policy currently in effect, or demonstrate > efficient utilization of all direct IPv4 assignments and > allocations, each of which must be covered by any current > ARIN RSA, or be a qualifying Community Network as > defined in Section 2.8, with assignment criteria defined in > section 6.5.9. . > > > > > >From the NRPM: > > 6.5.8.1. Criteria > To qualify for a direct assignment, an organization must: > not be an IPv6 LIR; and > qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA, or be a qualifying Community Network as defined in Section 2.8, with assignment criteria defined in section 6.5.9. > > > So, if you're not already an IPv6 LIR (ISP) then you have to meet ONE of the criteria from section b: > > + Qualify for IPv4 under existing policy currently in effect > or + demonstrate efficient utilization of all IPv4 assignments and allocations with each being > covered by an RSA or LRSA. > or + Be a qualifying Community Network as defined in Section 2.8. > > Note that the first one and third one do not require your IPv4 space to be covered by RSA or > LRSA. > > In addition to this, this policy will soon be superseded by 2010-8 which will replace it with > the following text: > > 6.5.8. Direct assignments from ARIN to end-user organizations > > 6.5.8.1 Initial Assignment Criteria > > Organizations may justify an initial assignment for addressing devices > directly attached to their own network infrastructure, with an intent > for the addresses to begin operational use within 12 months, by meeting > one of the following criteria: > > a. Having a previously justified IPv4 end-user assignment from ARIN or > one of its predecessor registries, or; > > b. Currently being IPv6 Multihomed or immediately becoming IPv6 > Multihomed and using an assigned valid global AS number, or; > > c. By having a network that makes active use of a minimum of 2000 IPv6 > addresses within 12 months, or; > > d. By having a network that makes active use of a minimum of 200 /64 > subnets within 12 months, or; > > e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. > > Examples of justifications for why addresses from an ISP or other LIR > may be unsuitable include, but are not limited to: > > ? An organization that operates infrastructure critical to life safety > or the functioning of society can justify the need for an assignment > based on the fact that renumbering would have a broader than expected > impact than simply the number of hosts directly involved. These would > include: hospitals, fire fighting, police, emergency response, power or > energy distribution, water or waste treatment, traffic management and > control, etc? > ? Regardless of the number of hosts directly involved, an organization > can justify the need for an assignment if renumbering would affect 2000 > or more individuals either internal or external to the organization. > ? An organization with a network not connected to the Internet can > justify the need for an assignment by documenting a need for guaranteed > uniqueness, beyond the statistical uniqueness provided by ULA (see RFC > 4193). > ? An organization with a network not connected to the Internet, such as > a VPN overlay network, can justify the need for an assignment if they > require authoritative delegation of reverse DNS. > > This version will remove the requirement for RSA/LRSA on the IPv4 space > altogether. > > 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 info at arin.net Fri Feb 11 11:27:51 2011 From: info at arin.net (ARIN) Date: Fri, 11 Feb 2011 11:27:51 -0500 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships Message-ID: <4D556387.3000300@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 11 February 2011 Proposal type: modify Policy term: permanent Policy statement: Section 4.2.1.1 of the NRPM shall be modified to read: "ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers. ARIN does not limit reassignment by ISPs to their customers based on any criteria except those that are explicitly described in the NRPM. An ISP is solely responsible for determining whether an organization is a customer for the purposes of reassignment under this policy." Rationale: This policy proposal is intended to permit an ISP to enter into reassignment relationships with anybody they deem to be a customer. Under this proposal, ARIN will not object to reassignment relationships because of their business nature. This specifically permits the reassignment of IPv4 addresses in "lease" relationships between an ISP and its customers, amongst others. Timetable for implementation: immediately From stu at actusa.net Fri Feb 11 11:30:30 2011 From: stu at actusa.net (Stuart Sheldon) Date: Fri, 11 Feb 2011 08:30:30 -0800 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D556387.3000300@arin.net> References: <4D556387.3000300@arin.net> Message-ID: <4D556426.50000@actusa.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Opposed Postpones the adoption of IPv6 and creates IPv4 brokerage companies. Stuart Sheldon On 02/11/2011 08:27 AM, ARIN wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer > Relationships > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 11 February 2011 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Section 4.2.1.1 of the NRPM shall be modified to read: > > "ARIN allocates blocks of IP addresses to ISPs for the purpose of > reassigning that space to their customers. ARIN does not limit > reassignment by ISPs to their customers based on any criteria except > those that are explicitly described in the NRPM. An ISP is solely > responsible for determining whether an organization is a customer for > the purposes of reassignment under this policy." > > Rationale: > > This policy proposal is intended to permit an ISP to enter into > reassignment relationships with anybody they deem to be a customer. > Under this proposal, ARIN will not object to reassignment relationships > because of their business nature. This specifically permits the > reassignment of IPv4 addresses in "lease" relationships between an ISP > and its customers, amongst others. > > Timetable for implementation: immediately > > > _______________________________________________ > 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. > - -- My pockets are empty though my wife has sent me to the store for some cigarettes and bread... I started walkin there, got as far as the square, then the smell of beer went to my head... The thing about beer, it can make a man hear, voices from days long since past, and with every third drink, it will make you think that your youth will always last... -- BR549 - "Lifetime to Prove Lyrics" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBCAAGBQJNVWQmAAoJEFKVLITDJSGSIHwQAK/JOQJiK7BX9cj0Mv4v+NbK l/20RK++J/w9TSZO9qd9D2gjbUubsCHj0ko2h9nUeuUki3tWQF3RFxxQHI3OoJNE KhizkOChJvdzZArjbddBB80Ws8CbZXh57pJRjiBMTgE2cTkJXsN68A3xW0jQ+wVg +luyDGKN9KsvM4SCkAkb0enBOnZiyFc7Zz65oSe4By9Unn2F+7IYDNrjc9vQEsLg +0mzYUhIAnZAFltHgLs2biuqZk/MvQTHdDW6dPdtk8NP9Yl/fVJUmlCgbujxGTJg Fh0bbSQUc1c6RWrlvIYvimGSU6PMyb64qCQLY4xkHElMuX9ZIzEgMaR97KHNQ7HG eDWBB4kyBD+xrm5Ibk2Pmh+efhPi+BzSRBmLNU9PL/FcYqTqtX22Nkwg35/Mekgi l4v1EmKMHUP42eeuZnea0w6BIIDjUMS3gBsLvqkbjcONpW+k2+wqquyMNue53A0y miVV9woqFyq+Ol0dXuGYgxXn9Ftw6J48vSw1Zkv7SxqVfwMheazxb2HCcQ9ukcsA 0R/XgMgk7JgePOGxVlmRBDHmCymokaKqLb2WHJVSpyir+KR9DaJhivYT8OHGhxle 43AnF3uWJbPY7lAM/OBjSgjEzzdXbeid+h+mGg/J/psQ0GWVALs1+XvMGLAJTKGx /OjQYQUzDC/Jw31BPkPu =+1eD -----END PGP SIGNATURE----- From hannigan at gmail.com Fri Feb 11 11:40:41 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 11 Feb 2011 11:40:41 -0500 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D556426.50000@actusa.net> References: <4D556387.3000300@arin.net> <4D556426.50000@actusa.net> Message-ID: There already are v4 brokerage companies. Best, -M< On Fri, Feb 11, 2011 at 11:30 AM, Stuart Sheldon wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Opposed > > Postpones the adoption of IPv6 and creates IPv4 brokerage companies. > > Stuart Sheldon > > > On 02/11/2011 08:27 AM, ARIN wrote: >> ARIN received the following policy proposal and is posting it to the >> Public Policy Mailing List (PPML) in accordance with the Policy >> Development Process. >> >> The ARIN Advisory Council (AC) will review the proposal at their next >> regularly scheduled meeting (if the period before the next regularly >> scheduled meeting is less than 10 days, then the period may be extended >> to the subsequent regularly scheduled meeting). The AC will decide how >> to utilize the proposal and announce the decision to the PPML. >> >> The AC invites everyone to comment on the proposal on the PPML, >> particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their deliberations. >> >> Draft Policies and Proposals under discussion can be found 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 >> >> Mailing list subscription information can be found >> at: https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer >> Relationships >> >> Proposal Originator: Benson Schliesser >> >> Proposal Version: 1 >> >> Date: 11 February 2011 >> >> Proposal type: modify >> >> Policy term: permanent >> >> Policy statement: >> >> Section 4.2.1.1 of the NRPM shall be modified to read: >> >> "ARIN allocates blocks of IP addresses to ISPs for the purpose of >> reassigning that space to their customers. ARIN does not limit >> reassignment by ISPs to their customers based on any criteria except >> those that are explicitly described in the NRPM. An ISP is solely >> responsible for determining whether an organization is a customer for >> the purposes of reassignment under this policy." >> >> Rationale: >> >> This policy proposal is intended to permit an ISP to enter into >> reassignment relationships with anybody they deem to be a customer. >> Under this proposal, ARIN will not object to reassignment relationships >> because of their business nature. This specifically permits the >> reassignment of IPv4 addresses in "lease" relationships between an ISP >> and its customers, amongst others. >> >> Timetable for implementation: immediately >> >> >> _______________________________________________ >> 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. >> > > - -- > My pockets are empty though my wife has sent me to the store for some > cigarettes and bread... I started walkin there, got as far as the > square, then the smell of beer went to my head... The thing about > beer, it can make a man hear, voices from days long since past, and > with every third drink, it will make you think that your youth will > always last... > ? ? ? ? ? ? ? ?-- BR549 - "Lifetime to Prove Lyrics" > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iQIcBAEBCAAGBQJNVWQmAAoJEFKVLITDJSGSIHwQAK/JOQJiK7BX9cj0Mv4v+NbK > l/20RK++J/w9TSZO9qd9D2gjbUubsCHj0ko2h9nUeuUki3tWQF3RFxxQHI3OoJNE > KhizkOChJvdzZArjbddBB80Ws8CbZXh57pJRjiBMTgE2cTkJXsN68A3xW0jQ+wVg > +luyDGKN9KsvM4SCkAkb0enBOnZiyFc7Zz65oSe4By9Unn2F+7IYDNrjc9vQEsLg > +0mzYUhIAnZAFltHgLs2biuqZk/MvQTHdDW6dPdtk8NP9Yl/fVJUmlCgbujxGTJg > Fh0bbSQUc1c6RWrlvIYvimGSU6PMyb64qCQLY4xkHElMuX9ZIzEgMaR97KHNQ7HG > eDWBB4kyBD+xrm5Ibk2Pmh+efhPi+BzSRBmLNU9PL/FcYqTqtX22Nkwg35/Mekgi > l4v1EmKMHUP42eeuZnea0w6BIIDjUMS3gBsLvqkbjcONpW+k2+wqquyMNue53A0y > miVV9woqFyq+Ol0dXuGYgxXn9Ftw6J48vSw1Zkv7SxqVfwMheazxb2HCcQ9ukcsA > 0R/XgMgk7JgePOGxVlmRBDHmCymokaKqLb2WHJVSpyir+KR9DaJhivYT8OHGhxle > 43AnF3uWJbPY7lAM/OBjSgjEzzdXbeid+h+mGg/J/psQ0GWVALs1+XvMGLAJTKGx > /OjQYQUzDC/Jw31BPkPu > =+1eD > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Feb 11 11:42:45 2011 From: bill at herrin.us (William Herrin) Date: Fri, 11 Feb 2011 11:42:45 -0500 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D556387.3000300@arin.net> References: <4D556387.3000300@arin.net> Message-ID: On Fri, Feb 11, 2011 at 11:27 AM, ARIN wrote: > ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer > Relationships > Section 4.2.1.1 of the NRPM shall be modified to read: > > "ARIN allocates blocks of IP addresses to ISPs for the purpose of > reassigning that space to their customers. ARIN does not limit > reassignment by ISPs to their customers based on any criteria except > those that are explicitly described in the NRPM. An ISP is solely > responsible for determining whether an organization is a customer for > the purposes of reassignment under this policy." Opposed. Abdicating responsibility for needs-based assignment on the eve of addressing being fully assigned would make everything ARIN has done the past decade and a half a lie. Nothing in the existing section 4.2 explicitly prohibits address leasing activity. It is not necessary to change ARIN's posture towards favoring it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From kkargel at polartel.com Fri Feb 11 11:46:01 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 11 Feb 2011 10:46:01 -0600 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships] In-Reply-To: <4D556408.80004@arin.net> References: <4D556408.80004@arin.net> Message-ID: <8695009A81378E48879980039EEDAD288C048D76@MAIL1.polartel.local> While I do not know if this proposal is necessary I have to support the spirit of this proposal. Many (not I) fought hard to make sure that an IP address market could exist to make netblocks saleable and policy now supports that attribute. Now that the policy is in place we have to accept the ancillary attributes that come with it. If one can permanently sell something one is also able to temporarily sell (lease or rent) something. In worst case one can sell something with an agreement it will be sold back for a lesser fee after some period of time. I do not feel it is in ARIN's purview to dictate the nature of the relationship between me and my "customers". The effect this has on IPv6 deployment is a side issue. Kevin Kargel > -----Original Message----- > From: arin-announce-bounces at arin.net [mailto:arin-announce- > bounces at arin.net] On Behalf Of ARIN > Sent: Friday, February 11, 2011 10:30 AM > To: arin-announce at arin.net > Subject: [arin-announce] [Fwd: ARIN-prop-132: ISP Sub-assignments Do Not > Require Specific Customer Relationships] > > The following is a new policy proposal that has been posted to the ARIN > Public Policy Mailing List for discussion on that list. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > -------- Original Message -------- > Subject: ARIN-prop-132: ISP Sub-assignments Do Not Require Specific > Customer Relationships > Date: Fri, 11 Feb 2011 11:27:51 -0500 > From: ARIN > To: arin-ppml at arin.net > > > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer > Relationships > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 11 February 2011 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Section 4.2.1.1 of the NRPM shall be modified to read: > > "ARIN allocates blocks of IP addresses to ISPs for the purpose of > reassigning that space to their customers. ARIN does not limit > reassignment by ISPs to their customers based on any criteria except > those that are explicitly described in the NRPM. An ISP is solely > responsible for determining whether an organization is a customer for > the purposes of reassignment under this policy." > > Rationale: > > This policy proposal is intended to permit an ISP to enter into > reassignment relationships with anybody they deem to be a customer. > Under this proposal, ARIN will not object to reassignment relationships > because of their business nature. This specifically permits the > reassignment of IPv4 addresses in "lease" relationships between an ISP > and its customers, amongst others. > > Timetable for implementation: immediately > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. From farmer at umn.edu Fri Feb 11 11:46:38 2011 From: farmer at umn.edu (David Farmer) Date: Fri, 11 Feb 2011 10:46:38 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: <4D53FE2D.7080802@arin.net> References: <4D53FE2D.7080802@arin.net> Message-ID: <4D5567EE.8070300@umn.edu> First Section 5 of the NRPM currently is labeled for dealing with AS Number Policies. I assume you are intending to re-purpose the current Section 5 for policies dealing with Legacy IPv4 addresses. I think I would prefer to keep section 5 for any future AS Number related policies. I think it would be more appropriate for this to be a new sub-section under section 4, since really this is about Legacy IPv4 addresses. I don't think anyone is all that worried about Legacy AS Numbers, and there are no Legacy IPv6 addresses, therefore it seems most appropriate for this to be under section 4 where we deal with IPv4 resources. Other options might be a new sub-section of section 3. Directory Services, or a whole new section. As a number of others have commented, I don't understand why we want to restrict this policy to Legacy Addresses. I am concerned that we could have different hold periods between legacy IPv4 addresses and ARIN allocated IPv4 addresses. This doesn't seem like a good idea to me. It also seems important to more precisely define "IPv4 addresses returned to or recovered by ARIN", ARIN staff has used revoked, returned, reclaimed, all with slightly different meanings I believe. Do you intend to include resources recovered for non-payment in a 30 day hold time, that seems a little short to me, and would be in violation of the LRSA for anyone who has taken up ARIN on the LRSA. (See Section 6b of the LRSA, https://www.arin.net/resources/agreements/legacy_rsa.pdf) Also, Draft Policy ARIN-2011-2 is directing ARIN to proactively recover abandoned resources, if this gains consensus do you intend for these resources to be included in the 30 day hold time too? I'm OK with 30 days or less for voluntarily returned resources and maybe even for resource revoked for fraud or other acts of commission. But, 30 days seems short for resource revoked for acts of omission, like failing to pay a bill or update records. I'm not saying you intend to include the later, but it is not entirely clear you didn't and I think the policy needs to be clear about this one way or the other. And, I prefer that these kind of things got more time. But, this additional time needs to be weighed against the fact we will be out of IPv4 resources soon. So I think something like 60 or 90 days seems to strike the right balance between these two issues. By my interpretation, you seem to clearly be including resource revoked for fraud or other acts of commission. I'm probably OK with that. However, those are the kinds of situations that are likely to lead to law suits and probably someone seeking injunctive relief from the courts anyway. So maybe it is best to not to try to be in to much of a hurry to distribute those resources out again, only to have a court order pull them back again. Finally, it seems to me that if someone voluntarily returns resources they intend for the rest of the community to use them. Therefore, we should honor their wishes and get these freed up resources into active use with someone else as soon a reasonably possible. Since we are approaching IPv4 resource exhaustion both regionally and globally, I think a maximum of 30 day hold time for such voluntarily returned resources is more than sufficiently prudent. Further, I think maybe we should allow 60 or 90 days for all the other situations, expect when otherwise dictated in the RSA or the LRSA, and we should leave the agreements as they are. Additionally, I think the policy should explicitly include, but not be limited to, Legacy IPv4 resources. So, I suggest something like the following; X. Recovered IPv4 Resources X.1 Voluntarily Returned IPv4 Resources All IPv4 resources voluntarily returned to ARIN, including any Legacy IPv4 resources, will be made available for registration and distribution within the ARIN region no more than thirty (30) days following receipt of the resources. X.2 Other Recovered IPv4 Resources All other IPv4 resources recovered by ARIN, including any Legacy IPv4 resources, will be made available for registration and distribution within the ARIN region ninety (90) days following their removal from the registry database (Whois), unless terms of a valid Registry Services Agreement otherwise apply. On 2/10/11 09:03 CST, ARIN wrote: ... > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region within > thirty days of their receipt. > > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > > Timetable for implementation: Immediately -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From scottleibrand at gmail.com Fri Feb 11 12:42:12 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 11 Feb 2011 09:42:12 -0800 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> Message-ID: <5F557BE0-323E-461F-AD4B-341797FA02A3@gmail.com> On Feb 11, 2011, at 8:42 AM, William Herrin wrote: > On Fri, Feb 11, 2011 at 11:27 AM, ARIN wrote: >> ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer >> Relationships >> Section 4.2.1.1 of the NRPM shall be modified to read: >> >> "ARIN allocates blocks of IP addresses to ISPs for the purpose of >> reassigning that space to their customers. ARIN does not limit >> reassignment by ISPs to their customers based on any criteria except >> those that are explicitly described in the NRPM. An ISP is solely >> responsible for determining whether an organization is a customer for >> the purposes of reassignment under this policy." > > Opposed. Abdicating responsibility for needs-based assignment on the > eve of addressing being fully assigned would make everything ARIN has > done the past decade and a half a lie. AFAICT this would leave in place the NRPM's needs-based requirements for reassignment to customers. > Nothing in the existing section 4.2 explicitly prohibits address > leasing activity. It is not necessary to change ARIN's posture towards > favoring it. I would agree that this is less of a policy change and more a clarification of existing practice. Based on John's comments, it sounds like such clarification may be helpful... -Scott From jcurran at arin.net Fri Feb 11 12:52:47 2011 From: jcurran at arin.net (John Curran) Date: Fri, 11 Feb 2011 17:52:47 +0000 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D556387.3000300@arin.net> References: <4D556387.3000300@arin.net> Message-ID: On Feb 11, 2011, at 12:27 PM, ARIN wrote: > Section 4.2.1.1 of the NRPM shall be modified to read: > > "ARIN allocates blocks of IP addresses to ISPs for the purpose of > reassigning that space to their customers. ARIN does not limit > reassignment by ISPs to their customers based on any criteria except > those that are explicitly described in the NRPM. An ISP is solely > responsible for determining whether an organization is a customer for > the purposes of reassignment under this policy." > > Rationale: > > This policy proposal is intended to permit an ISP to enter into > reassignment relationships with anybody they deem to be a customer. > Under this proposal, ARIN will not object to reassignment relationships > because of their business nature. This specifically permits the > reassignment of IPv4 addresses in "lease" relationships between an ISP > and its customers, amongst others. > > Timetable for implementation: immediately Benson - For clarity, could you elaborate some on the nature of these customer suballocations as proposed in this policy (as it might aid in having constructive discussion of the merits.) 1) Will these suballocations be listed via SWIP/rWHOIS per the existing policy for customer assignments? 2) Are there any minimum prefix size restrictions (since there is no routing relationship implied between the customer and the ISP which provides aggregation) 3) Is there any prefix size maximum (e.g. could an organization holding a /8 have one customer receive the entire /8 as their assignment?) Thanks for getting this discussion going! /John John Curran President and CEO ARIN From hannigan at gmail.com Fri Feb 11 13:01:51 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 11 Feb 2011 13:01:51 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: <4D5567EE.8070300@umn.edu> References: <4D53FE2D.7080802@arin.net> <4D5567EE.8070300@umn.edu> Message-ID: On Fri, Feb 11, 2011 at 11:46 AM, David Farmer wrote: > First Section 5 of the NRPM currently is labeled for dealing with AS Number > Policies. Hmm. I'm not sure why I thought that Section 5 was available. I'll fix that. [ snip ] Thanks. If you'd like to target additional non-specific concerns, I'd suggest that you craft a proposal for consideration. I'm targeting a specific, highly charged, global issue and the proposal needs to be crystal clear. Based on preliminary feedback, I believe that it is in it's current state. With respect to administration, I'll wait until the full staff and legal review before I comment, or edit, further. Best, -M< From jbates at brightok.net Fri Feb 11 13:08:20 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 12:08:20 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> Message-ID: <4D557B14.1020404@brightok.net> On 2/11/2011 11:52 AM, John Curran wrote: > 1) Will these suballocations be listed via SWIP/rWHOIS per the existing > policy for customer assignments? > "ARIN does not limit reassignment by ISPs to their customers based on any criteria except those that are explicitly described in the NRPM" To my knowledge, ARIN does not do this now, and it seems as though the policy is a clarification to head off future restrictions such as "You must have a link of X size for a reassignment to be valid." This would assum that SWIP/rWHOIS is still required by existing policy. > 2) Are there any minimum prefix size restrictions (since there is no > routing relationship implied between the customer and the ISP which > provides aggregation) > There currently aren't, and even in cases of direct transit customers, there is no guarantee in the routing table that a prefix size will be maintained. This is seen in the current DFZ in large volumes of deaggregation. > 3) Is there any prefix size maximum (e.g. could an organization holding > a /8 have one customer receive the entire /8 as their assignment?) > Given justified need, does it matter? I believe the NRPM already covers justified need, though it tends to be limited in scope primarily to requesting additional address space. As people will be requesting less address space, this limits the scope and power of ARIN. An ISP hands out space to customers. Not all those customers are directly connected. Some ISPs function solely as an LIR. This traditionally has been accepted and allowed in justification for subsequent requests. I don't see that this policy actually changes that fact, but attempt to clarify it given the current arguments over people selling address space to others who are not directly connected to their network. The question for ARIN and the community becomes, what should be in the NRPM for ARIN to deal with recourse when justification has not been met on reallocations or assignments? This applies both to IPv4 and IPv6, as the recourse of denying subsequent allocations is extremely limited for both (IPv4 will be exhausted, and IPv6 requires much less interaction with ARIN). I believe this last question is the most important, and I think it should fall in lines with the clarification of this proposal (ie, we should not forbid LIRs and ISPs from doing allocations which are needs based regardless of the customer relationship). Jack From gbonser at seven.com Fri Feb 11 13:47:34 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 11 Feb 2011 10:47:34 -0800 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D556387.3000300@arin.net> References: <4D556387.3000300@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> Support. If you consider an LIR as just that, a local internet registry. They are given a block of IP addresses to reassign. As long as the reassignee qualifies for IP addresses and meets the usage requirements, I don't see any issue. The usage of those IPs (or lack thereof) would still count against the LIR in its justification for any additional assignments of IP addresses. I think the notion that someone had to have physical connectivity to the LIR in order to get IPs is a conclusion to which many have jumped simply because that is the usual case, but not necessarily the rule. An LIR could be a consultant to a "customer", could be a professional services vendor, etc. An LIR getting a customer set up with IP addresses even if that customer uses a different connectivity provider shouldn't be a problem. > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Friday, February 11, 2011 8:28 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require > Specific Customer Relationships > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer > Relationships > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 11 February 2011 > > Proposal type: modify > > Policy term: permanent > > Policy statement: > > Section 4.2.1.1 of the NRPM shall be modified to read: > > "ARIN allocates blocks of IP addresses to ISPs for the purpose of > reassigning that space to their customers. ARIN does not limit > reassignment by ISPs to their customers based on any criteria except > those that are explicitly described in the NRPM. An ISP is solely > responsible for determining whether an organization is a customer for > the purposes of reassignment under this policy." > > Rationale: > > This policy proposal is intended to permit an ISP to enter into > reassignment relationships with anybody they deem to be a customer. > Under this proposal, ARIN will not object to reassignment relationships > because of their business nature. This specifically permits the > reassignment of IPv4 addresses in "lease" relationships between an ISP > and its customers, amongst others. > > Timetable for implementation: immediately > > > _______________________________________________ > 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 info at arin.net Fri Feb 11 14:01:27 2011 From: info at arin.net (ARIN) Date: Fri, 11 Feb 2011 14:01:27 -0500 Subject: [arin-ppml] Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria - adopted Message-ID: <4D558787.1000509@arin.net> On 11 January 2011 the ARIN Board of Trustees adopted the following policy: Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria https://www.arin.net/policy/proposals/2010_8.html This policy will be be implemented no later than 30 April 2011. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2010-8 Rework of IPv6 assignment criteria Version/Date: 23 November 2010 Policy statement: Replace section 6.5.8 as follows; 6.5.8. Direct assignments from ARIN to end-user organizations 6.5.8.1 Initial Assignment Criteria Organizations may justify an initial assignment for addressing devices directly attached to their own network infrastructure, with an intent for the addresses to begin operational use within 12 months, by meeting one of the following criteria: a. Having a previously justified IPv4 end-user assignment from ARIN or one of its predecessor registries, or; b. Currently being IPv6 Multihomed or immediately becoming IPv6 Multihomed and using an assigned valid global AS number, or; c. By having a network that makes active use of a minimum of 2000 IPv6 addresses within 12 months, or; d. By having a network that makes active use of a minimum of 200 /64 subnets within 12 months, or; e. By providing a reasonable technical justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable. Examples of justifications for why addresses from an ISP or other LIR may be unsuitable include, but are not limited to: ? An organization that operates infrastructure critical to life safety or the functioning of society can justify the need for an assignment based on the fact that renumbering would have a broader than expected impact than simply the number of hosts directly involved. These would include: hospitals, fire fighting, police, emergency response, power or energy distribution, water or waste treatment, traffic management and control, etc? ? Regardless of the number of hosts directly involved, an organization can justify the need for an assignment if renumbering would affect 2000 or more individuals either internal or external to the organization. ? An organization with a network not connected to the Internet can justify the need for an assignment by documenting a need for guaranteed uniqueness, beyond the statistical uniqueness provided by ULA (see RFC 4193). ? An organization with a network not connected to the Internet, such as a VPN overlay network, can justify the need for an assignment if they require authoritative delegation of reverse DNS. 6.5.8.2 Initial assignment size Organizations that meet at least one of the initial assignment criteria above are eligible to receive an initial assignment of /48. Requests for larger initial assignments, reasonably justified with supporting documentation, will be evaluated based on the number of sites in an organization?s network and the number of subnets needed to support any extra-large sites defined below. The initial assignment size will be determined by the number of sites justified below. An organization qualifies for an assignment on the next larger nibble boundary when their sites exceed 75% of the /48s available in a prefix. For example: More than 1 but less than or equal to 12 sites justified, receives a /44 assignment; More than 12 but less than or equal to 192 sites justified, receives a /40 assignment; More than 192 but less than or equal to 3,072 sites justified, receives a /36 assignment; More than 3,072 but less than or equal to 49,152 sites justified, receives a /32 assignment; etc... 6.5.8.2.1 Standard sites A site is a discrete location that is part of an organization?s network. A campus with multiple buildings may be considered as one or multiple sites, based on the implementation of its network infrastructure. For a campus to be considered as multiple sites, reasonable technical documentation must be submitted describing how the network infrastructure is implemented in a manner equivalent to multiple sites. An organization may request up to a /48 for each site in its network, and any sites that will be operational within 12 months. 6.5.8.2.2 Extra-large sites In rare cases, an organization may request more than a /48 for an extra-large site which requires more than 16,384 /64 subnets. In such a case, a detailed subnet plan must be submitted for each extra-large site in an organization?s network. An extra-large site qualifies for the next larger prefix when the total subnet utilization exceeds 25%. Each extra-large site will be counted as an equivalent number of /48 standard sites. 6.5.8.3 Subsequent assignments Requests for subsequent assignments with supporting documentation will be evaluated based on the same criteria as an initial assignment under 6.5.8.2 with the following modifications: a. A subsequent assignment is justified when the total utilization based on the number of sites justified exceeds 75% across all of an organization?s assignments. If the organization received an assignment per section 6.11 IPv6 Multiple Discrete Networks, such assignments will be evaluated as if they were to a separate organization. b. When possible subsequent assignments will result it the expansion of an existing assignment by one or more nibble boundaries as justified. c. If it is not possible to expand an existing assignment, or to expand it adequately to meet the justified need, then a separate new assignment will be made of the size justified. 6.5.8.4 Consolidation and return of separate assignments Organizations with multiple separate assignments should consolidate into a single aggregate, if feasible. If an organization stops using one or more of its separate assignments, any unused assignments must be returned to ARIN. Rationale: This proposal provides a complete rework of the IPv6 end-user assignment criteria, removing the dependency on IPv4 policy, providing clear guidance in requesting larger initial assignments, and eliminating HD-Ratio as criteria for evaluating end-user assignments. The HD-Ratio is replaced with a simplified 75% utilization threshold based on nibble boundaries for end-user assignments. This threshold is somewhat more restrictive for larger assignments, while slightly less restrictive for the smaller /44 assignments, than the HD-Ratio. However, in both cases it is much easier for an end-user to understand the policy criteria that applies to them. The following general concepts are included: ? Previously justified IPv4 resources may be used to justify the need for IPv6 resources ? Internet multihoming is sufficient justification for an IPv6 end-user assignment in and of itself ? Networks with more than 2000 hosts have a justified need for IPv6 resources; as is the case in current policy, it is just more clearly stated without relying on a reference to, and the consequences of, IPv4 policy ? Networks with more than 200 subnets have a justified need for IPv6 resources, independent of the number of hosts they have ? Other end-users, not meeting one of the previous criteria, must justify why an ISP or LIR assignment is not sufficient for their needs ? Reservations are no longer necessary as ARIN has committed to sparse assignment for IPv6 ? Providing sufficiently large initial assignments based on nibble boundaries along with sparse assignments will reduce route table growth caused solely by subsequent assignments Organizations with multiple sites may receive a /48 for each site in their network. A campus with multiple buildings may be considered as one or multiple sites, based on the implementation of its network infrastructure. When multiple separate organizations have networks in the same building, such as in the case of a multi-tenant building, each organization justifies a separate /48 for its network at the site. The 25% subnet utilization for an extra-large site is proposed as the threshold for a larger prefix in order to allow an extra-large site enough room to create an organized subnet plan. Requiring denser usage would make it almost impossible for an extra-large site to maintain any kind of organized subnet plan. Furthermore, even at 25% utilization, more than 16,384 subnets are required to justify more than a /48 for a site. Few, if any, sites can actually meet or exceed this threshold. Organizations may have multiple separate assignments due to previous subsequent assignments made per clause 6.5.8.3.c or through Mergers and Acquisitions in section 8.2. These multiple separate assignments must be considered in total when making subsequent assignments, unless they are part multiple discrete networks, per section 6.11. The ARIN Board of Trusties should consider incentives that provide additional motivation for end-users to consolidate into a single aggregate per section 6.5.8.4 of this policy. Timetable for implementation: Immediate From owen at delong.com Fri Feb 11 15:32:40 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 12:32:40 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: References: <4D53FE2D.7080802@arin.net> <4D5567EE.8070300@umn.edu> Message-ID: <81B5FFEA-23A4-48F9-89C4-09042EF64FA5@delong.com> Based on this feedback from the author, I oppose proposal 131. Singling out legacy resources to be treated differently in this manner is harmful and contrary to the interests of the community. Owen On Feb 11, 2011, at 10:01 AM, Martin Hannigan wrote: > On Fri, Feb 11, 2011 at 11:46 AM, David Farmer wrote: >> First Section 5 of the NRPM currently is labeled for dealing with AS Number >> Policies. > > Hmm. I'm not sure why I thought that Section 5 was available. I'll fix that. > > [ snip ] > > Thanks. If you'd like to target additional non-specific concerns, I'd > suggest that you craft a proposal for consideration. I'm targeting a > specific, highly charged, global issue and the proposal needs to be > crystal clear. Based on preliminary feedback, I believe that it is in > it's current state. With respect to administration, I'll wait until > the full staff and legal review before I comment, or edit, further. > > > Best, > > -M< > _______________________________________________ > 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 Fri Feb 11 16:07:51 2011 From: farmer at umn.edu (David Farmer) Date: Fri, 11 Feb 2011 15:07:51 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: References: <4D53FE2D.7080802@arin.net> <4D5567EE.8070300@umn.edu> Message-ID: <4D55A527.5060801@umn.edu> On 2/11/11 12:01 CST, Martin Hannigan wrote: .... > Thanks. If you'd like to target additional non-specific concerns, I'd > suggest that you craft a proposal for consideration. I probably will, I've thought of a few ideas subsequent to responding. >I'm targeting a > specific, highly charged, global issue and the proposal needs to be > crystal clear. Yep, I understand. > Based on preliminary feedback, I believe that it is in > it's current state. I disagree, there is one issue that is muddying things for me still. Let me quote the operable part of the policy text and then I'll explain. > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region within > thirty days of their receipt. In the first part you I think you are trying to say "treat any Legacy IPv4 address space returned or recovered the same way any non-legacy IPv4 addresses would be within the ARIN region." It is the last part of the sentence "within thirty days of their receipt." that muddies things for me. It is kind of saying "BUT, now treat it in this different way", which conflict with the intent of the beginning part. Pull out the 30 day clause, then it makes sense to me for this policy to be limited to Legacy IPv4 addresses. However, with the 30 day clause in there I want that clause to apply to both Legacy and non-Legacy address space. I actually think the 30 day clause is a good policy intent, but it needs to apply to both Legacy and non-Legacy IPv4 address space, applying it to Legacy only is bad and broken policy. So, I think it is the 30 day clause that has a number of people asking why should this policy only apply to Legacy IPv4 address space. > With respect to administration, I'll wait until > the full staff and legal review before I comment, or edit, further. Furthermore, I believe that clause without additional clarification creates a conflicts with contractual obligations that ARIN has with any organization that has signed the LRSA. Unless, you believe that once an organization signs a LRSA its resources are no longer Legacy IPv4 addresses. So, if you want to keep this policy crystal clear pull the 30 day clause out, then I could probably support it. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From charles at office.tcsn.net Fri Feb 11 16:18:16 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Fri, 11 Feb 2011 13:18:16 -0800 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> References: <4D556387.3000300@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> Message-ID: <4D55A798.9020401@office.tcsn.net> In regards to both this: On 2/11/11 10:47 AM, George Bonser wrote: > > I think the notion that someone had to have physical connectivity to the > LIR in order to get IPs is a conclusion to which many have jumped simply > because that is the usual case, but not necessarily the rule. An LIR > could be a consultant to a "customer", could be a professional services > vendor, etc. An LIR getting a customer set up with IP addresses even if > that customer uses a different connectivity provider shouldn't be a > problem. > And this: On 2/11/11 10:08 AM, Jack Bates wrote: > On 2/11/2011 11:52 AM, John Curran wrote: >> 2) Are there any minimum prefix size restrictions (since there is no >> routing relationship implied between the customer and the ISP which >> provides aggregation) > > There currently aren't, and even in cases of direct transit customers, there is no guarantee in the routing table that a prefix size will be maintained. > This is seen in the current DFZ in large volumes of deaggregation. This seems to promote disconnecting the concept of LIR from ISP. While there are already LIRs what aren't ISPs, isn't that considered to be the exception? Wouldn't that in turn lead to greater de-aggregation? I'm not opposed, but I am confused. Don't we want to prevent and/or retard de-aggregation? Are the consequences of de-aggregation of less magnitude than the consequences of failing to detach the notion of the LIR from the notion of the ISP? Additionally, if so we'd have to change Draft Policy ARIN-2011-3 as it states that "(a) The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings." I'm assuming that "this document" to infer that it to applies to all sections of the NRPM. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From owen at delong.com Fri Feb 11 16:16:54 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 13:16:54 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: <4D55A527.5060801@umn.edu> References: <4D53FE2D.7080802@arin.net> <4D5567EE.8070300@umn.edu> <4D55A527.5060801@umn.edu> Message-ID: <162B06FA-2323-42F8-A441-E0566A839660@delong.com> David, Legacy space returned to ARIN is treated like any other returned space today to the extent that is specified in this proposal. Without the 30 day clause, this proposal is a no-op. With the word Legacy, the policy is harmful. Owen On Feb 11, 2011, at 1:07 PM, David Farmer wrote: > On 2/11/11 12:01 CST, Martin Hannigan wrote: > .... >> Thanks. If you'd like to target additional non-specific concerns, I'd >> suggest that you craft a proposal for consideration. > > I probably will, I've thought of a few ideas subsequent to responding. > >> I'm targeting a >> specific, highly charged, global issue and the proposal needs to be >> crystal clear. > > Yep, I understand. > >> Based on preliminary feedback, I believe that it is in >> it's current state. > > I disagree, there is one issue that is muddying things for me still. Let me quote the operable part of the policy text and then I'll explain. > >> Legacy IPv4 addresses returned to or recovered by ARIN will be made >> available for registration and distribution in the ARIN region within >> thirty days of their receipt. > > In the first part you I think you are trying to say "treat any Legacy IPv4 address space returned or recovered the same way any non-legacy IPv4 addresses would be within the ARIN region." It is the last part of the sentence "within thirty days of their receipt." that muddies things for me. It is kind of saying "BUT, now treat it in this different way", which conflict with the intent of the beginning part. Pull out the 30 day clause, then it makes sense to me for this policy to be limited to Legacy IPv4 addresses. > > However, with the 30 day clause in there I want that clause to apply to both Legacy and non-Legacy address space. I actually think the 30 day clause is a good policy intent, but it needs to apply to both Legacy and non-Legacy IPv4 address space, applying it to Legacy only is bad and broken policy. > > So, I think it is the 30 day clause that has a number of people asking why should this policy only apply to Legacy IPv4 address space. > >> With respect to administration, I'll wait until >> the full staff and legal review before I comment, or edit, further. > > Furthermore, I believe that clause without additional clarification creates a conflicts with contractual obligations that ARIN has with any organization that has signed the LRSA. > > Unless, you believe that once an organization signs a LRSA its resources are no longer Legacy IPv4 addresses. > > So, if you want to keep this policy crystal clear pull the 30 day clause out, then I could probably support it. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jbates at brightok.net Fri Feb 11 16:40:24 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 15:40:24 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: <162B06FA-2323-42F8-A441-E0566A839660@delong.com> References: <4D53FE2D.7080802@arin.net> <4D5567EE.8070300@umn.edu> <4D55A527.5060801@umn.edu> <162B06FA-2323-42F8-A441-E0566A839660@delong.com> Message-ID: <4D55ACC8.7090106@brightok.net> On 2/11/2011 3:16 PM, Owen DeLong wrote: > Legacy space returned to ARIN is treated like any other returned > space today to the extent that is specified in this proposal. > > Without the 30 day clause, this proposal is a no-op. > > With the word Legacy, the policy is harmful. +1 Opposed From jbates at brightok.net Fri Feb 11 16:51:56 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 15:51:56 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D55A798.9020401@office.tcsn.net> References: <4D556387.3000300@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> <4D55A798.9020401@office.tcsn.net> Message-ID: <4D55AF7C.7040508@brightok.net> On 2/11/2011 3:18 PM, Charles O'Hern wrote: > This seems to promote disconnecting the concept of LIR from ISP. > While there are already LIRs what aren't ISPs, isn't that considered > to be the exception? Wouldn't that in turn lead to greater > de-aggregation? > Not really, I can't believe the level of deaggregation there is currently. entire /16's deaggregated to /24 networks? Really? > I'm not opposed, but I am confused. Don't we want to prevent and/or > retard de-aggregation? Are the consequences of de-aggregation of > less magnitude than the consequences of failing to detach the notion > of the LIR from the notion of the ISP? > If a network justifies their space, then I see no harm in them using a network which has been provided to them. There are cases where people have switched ISPs and not been required to renumber. There are also situations such as mine, where I still hold 2x /20's from one of my transit feeds, and the connectivity I hold with them is minuscule. It's deaggregated because I run BGP with multiple peers. It should be noted that current policy doesn't actually distinguish between them really. There is no connectivity required clause. An LIR must justify allocations the same as an ISP. > Additionally, if so we'd have to change Draft Policy ARIN-2011-3 as > it states that "(a) The terms ISP and LIR are used interchangeably > in this document and any use of either term shall be construed to > include both meanings." I'm assuming that "this document" to infer > that it to applies to all sections of the NRPM. > That doesn't need to change. What it's saying is the policy referring to ISP also includes LIR and using LIR also includes ISP definitions. ie, it doesn't matter if you are an LIR or an ISP, these are the justification rules. The policy doesn't currently mandate any type of connectivity (which is really the largest difference between an LIR and an ISP). 2011-3 doesn't change that. The suggestion on prop-132 is to clarify the point. However, I think all of it misses the bigger problem. How do we handle justification, audit and recourse in an IPv4 depleted market? Jack From hannigan at gmail.com Fri Feb 11 17:00:58 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 11 Feb 2011 17:00:58 -0500 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D55AF7C.7040508@brightok.net> References: <4D556387.3000300@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> <4D55A798.9020401@office.tcsn.net> <4D55AF7C.7040508@brightok.net> Message-ID: Jack, care to elaborate as to why? +1 is meaningless since all that was presented by the previous poster appears to be a straw man. Can you explain 'harm'? Best, -M< On 2/11/11, Jack Bates wrote: > > > On 2/11/2011 3:18 PM, Charles O'Hern wrote: >> This seems to promote disconnecting the concept of LIR from ISP. >> While there are already LIRs what aren't ISPs, isn't that considered >> to be the exception? Wouldn't that in turn lead to greater >> de-aggregation? >> > > Not really, I can't believe the level of deaggregation there is > currently. entire /16's deaggregated to /24 networks? Really? > > >> I'm not opposed, but I am confused. Don't we want to prevent and/or >> retard de-aggregation? Are the consequences of de-aggregation of >> less magnitude than the consequences of failing to detach the notion >> of the LIR from the notion of the ISP? >> > > If a network justifies their space, then I see no harm in them using a > network which has been provided to them. There are cases where people > have switched ISPs and not been required to renumber. There are also > situations such as mine, where I still hold 2x /20's from one of my > transit feeds, and the connectivity I hold with them is minuscule. It's > deaggregated because I run BGP with multiple peers. > > It should be noted that current policy doesn't actually distinguish > between them really. There is no connectivity required clause. An LIR > must justify allocations the same as an ISP. > >> Additionally, if so we'd have to change Draft Policy ARIN-2011-3 as >> it states that "(a) The terms ISP and LIR are used interchangeably >> in this document and any use of either term shall be construed to >> include both meanings." I'm assuming that "this document" to infer >> that it to applies to all sections of the NRPM. >> > > That doesn't need to change. What it's saying is the policy referring to > ISP also includes LIR and using LIR also includes ISP definitions. ie, > it doesn't matter if you are an LIR or an ISP, these are the > justification rules. > > The policy doesn't currently mandate any type of connectivity (which is > really the largest difference between an LIR and an ISP). 2011-3 doesn't > change that. > > The suggestion on prop-132 is to clarify the point. However, I think all > of it misses the bigger problem. How do we handle justification, audit > and recourse in an IPv4 depleted market? > > > Jack > _______________________________________________ > 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 hannigan at gmail.com Fri Feb 11 17:01:47 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 11 Feb 2011 17:01:47 -0500 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> <4D55A798.9020401@office.tcsn.net> <4D55AF7C.7040508@brightok.net> Message-ID: Actually, Jack, apologies, this should be with 131. Long day. Can you reply in that thread? Thanks. On 2/11/11, Martin Hannigan wrote: > Jack, care to elaborate as to why? +1 is meaningless since all that > was presented by the previous poster appears to be a straw man. > > Can you explain 'harm'? > > Best, > > -M< > > > On 2/11/11, Jack Bates wrote: >> >> >> On 2/11/2011 3:18 PM, Charles O'Hern wrote: >>> This seems to promote disconnecting the concept of LIR from ISP. >>> While there are already LIRs what aren't ISPs, isn't that considered >>> to be the exception? Wouldn't that in turn lead to greater >>> de-aggregation? >>> >> >> Not really, I can't believe the level of deaggregation there is >> currently. entire /16's deaggregated to /24 networks? Really? >> >> >>> I'm not opposed, but I am confused. Don't we want to prevent and/or >>> retard de-aggregation? Are the consequences of de-aggregation of >>> less magnitude than the consequences of failing to detach the notion >>> of the LIR from the notion of the ISP? >>> >> >> If a network justifies their space, then I see no harm in them using a >> network which has been provided to them. There are cases where people >> have switched ISPs and not been required to renumber. There are also >> situations such as mine, where I still hold 2x /20's from one of my >> transit feeds, and the connectivity I hold with them is minuscule. It's >> deaggregated because I run BGP with multiple peers. >> >> It should be noted that current policy doesn't actually distinguish >> between them really. There is no connectivity required clause. An LIR >> must justify allocations the same as an ISP. >> >>> Additionally, if so we'd have to change Draft Policy ARIN-2011-3 as >>> it states that "(a) The terms ISP and LIR are used interchangeably >>> in this document and any use of either term shall be construed to >>> include both meanings." I'm assuming that "this document" to infer >>> that it to applies to all sections of the NRPM. >>> >> >> That doesn't need to change. What it's saying is the policy referring to >> ISP also includes LIR and using LIR also includes ISP definitions. ie, >> it doesn't matter if you are an LIR or an ISP, these are the >> justification rules. >> >> The policy doesn't currently mandate any type of connectivity (which is >> really the largest difference between an LIR and an ISP). 2011-3 doesn't >> change that. >> >> The suggestion on prop-132 is to clarify the point. However, I think all >> of it misses the bigger problem. How do we handle justification, audit >> and recourse in an IPv4 depleted market? >> >> >> Jack >> _______________________________________________ >> 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 jbates at brightok.net Fri Feb 11 17:03:34 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 16:03:34 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> <4D55A798.9020401@office.tcsn.net> <4D55AF7C.7040508@brightok.net> Message-ID: <4D55B236.10108@brightok.net> Umm, I think you replied to the wrong email. :) The +1 concerning the other prop was actually summed up nicely in another email Owen wrote right before the one I +1'd. Jack On 2/11/2011 4:00 PM, Martin Hannigan wrote: > Jack, care to elaborate as to why? +1 is meaningless since all that > was presented by the previous poster appears to be a straw man. > > Can you explain 'harm'? > > Best, > > -M< > > > On 2/11/11, Jack Bates wrote: >> >> >> On 2/11/2011 3:18 PM, Charles O'Hern wrote: >>> This seems to promote disconnecting the concept of LIR from ISP. >>> While there are already LIRs what aren't ISPs, isn't that considered >>> to be the exception? Wouldn't that in turn lead to greater >>> de-aggregation? >>> >> >> Not really, I can't believe the level of deaggregation there is >> currently. entire /16's deaggregated to /24 networks? Really? >> >> >>> I'm not opposed, but I am confused. Don't we want to prevent and/or >>> retard de-aggregation? Are the consequences of de-aggregation of >>> less magnitude than the consequences of failing to detach the notion >>> of the LIR from the notion of the ISP? >>> >> >> If a network justifies their space, then I see no harm in them using a >> network which has been provided to them. There are cases where people >> have switched ISPs and not been required to renumber. There are also >> situations such as mine, where I still hold 2x /20's from one of my >> transit feeds, and the connectivity I hold with them is minuscule. It's >> deaggregated because I run BGP with multiple peers. >> >> It should be noted that current policy doesn't actually distinguish >> between them really. There is no connectivity required clause. An LIR >> must justify allocations the same as an ISP. >> >>> Additionally, if so we'd have to change Draft Policy ARIN-2011-3 as >>> it states that "(a) The terms ISP and LIR are used interchangeably >>> in this document and any use of either term shall be construed to >>> include both meanings." I'm assuming that "this document" to infer >>> that it to applies to all sections of the NRPM. >>> >> >> That doesn't need to change. What it's saying is the policy referring to >> ISP also includes LIR and using LIR also includes ISP definitions. ie, >> it doesn't matter if you are an LIR or an ISP, these are the >> justification rules. >> >> The policy doesn't currently mandate any type of connectivity (which is >> really the largest difference between an LIR and an ISP). 2011-3 doesn't >> change that. >> >> The suggestion on prop-132 is to clarify the point. However, I think all >> of it misses the bigger problem. How do we handle justification, audit >> and recourse in an IPv4 depleted market? >> >> >> Jack >> _______________________________________________ >> 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 jbates at brightok.net Fri Feb 11 17:05:29 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 16:05:29 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: <81B5FFEA-23A4-48F9-89C4-09042EF64FA5@delong.com> References: <4D53FE2D.7080802@arin.net> <4D5567EE.8070300@umn.edu> <81B5FFEA-23A4-48F9-89C4-09042EF64FA5@delong.com> Message-ID: <4D55B2A9.70507@brightok.net> On 2/11/2011 2:32 PM, Owen DeLong wrote: > Based on this feedback from the author, I oppose proposal 131. Singling > out legacy resources to be treated differently in this manner is harmful > and contrary to the interests of the community. > +1'ing the more verbose email by Owen that I agree with. Legacy resources should not be singled out in this manner. Jack From hannigan at gmail.com Fri Feb 11 17:07:08 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 11 Feb 2011 17:07:08 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised In-Reply-To: <4D55B2A9.70507@brightok.net> References: <4D53FE2D.7080802@arin.net> <4D5567EE.8070300@umn.edu> <81B5FFEA-23A4-48F9-89C4-09042EF64FA5@delong.com> <4D55B2A9.70507@brightok.net> Message-ID: Ok. Why not? On 2/11/11, Jack Bates wrote: > > > On 2/11/2011 2:32 PM, Owen DeLong wrote: >> Based on this feedback from the author, I oppose proposal 131. Singling >> out legacy resources to be treated differently in this manner is harmful >> and contrary to the interests of the community. >> > > +1'ing the more verbose email by Owen that I agree with. > > Legacy resources should not be singled out in this manner. > > Jack > From bensons at queuefull.net Fri Feb 11 17:18:04 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 11 Feb 2011 16:18:04 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> Message-ID: <290D2C2F-6FAF-4B11-A4D8-01F63546335A@queuefull.net> Hi, John. The goal of ARIN-prop-132 is to clarify the definition of "customer" in 4.2.1.1, leaving the rest of the NRPM unchanged. As written, I do not believe that it impact any other aspects of policy. That said, answering your specific questions: > 1) Will these suballocations be listed via SWIP/rWHOIS per the existing > policy for customer assignments? Yes, based on my understanding of policy elsewhere in the NRPM. > 2) Are there any minimum prefix size restrictions (since there is no > routing relationship implied between the customer and the ISP which > provides aggregation) No, based on my understanding of policy elsewhere in the NRPM. However, it is an interesting question. I would posit that routing table growth is primarily a function of demand for connectivity. ARIN policies limiting the shortest prefixes allocated may have acted as a multiplier against that demand, in terms of table growth. However, if we assume that small reassignments were historically covered under an aggregate prefix advertised by a connectivity provider, then historical reassignment behavior (providing sub-assignments with connectivity services) would have acted to constrain table growth. We might imagine that this policy proposal enables the movement of prefixes out from "underneath" their covering aggregate. If this were unconstrained it might result in additional table growth in the DFZ. Having acknowledged that possibility, my perspective is that ARIN policy does not limit the longest prefix size (smallest block) injected into the routing table. Rather, operators limit longest prefix size in their individual networks. As such, very small reassignments under this proposal might be filtered by various networks and could be unattractive to "customers". Alternatively, if we do see significant table growth then the current practice of filtering, e.g. /24 or longer prefixes, might need to become more aggressive in time. But I don't believe this is an aspect that must be addressed by ARIN policy. As a side note, I think that federations of network providers and/or alternative technology approaches (LISP, etc) might be leveraged to enable further connectivity growth while constraining DFZ routes. This policy opens the door to a number of interesting relationships that ISPs might explore. > 3) Is there any prefix size maximum (e.g. could an organization holding > a /8 have one customer receive the entire /8 as their assignment?) No, based on my understanding of policy elsewhere in the NRPM. Section 4.2.3.5 indicates the maximum block that can be reassigned before ARIN approval is required, and proposal 132 doesn't affect this. Proposal 132 does, however, limit ARIN from denying such reassignments based on the relationship between the customer and the ISP. Per my comment above, it might be prudent to consider a proposal that allows larger blocks to be reassigned in order to encourage aggregation. This is not currently part of proposal 132. Cheers, -Benson From gbonser at seven.com Fri Feb 11 17:32:19 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 11 Feb 2011 14:32:19 -0800 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <4D55A798.9020401@office.tcsn.net> References: <4D556387.3000300@arin.net><5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> <4D55A798.9020401@office.tcsn.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13A5B@RWC-EX1.corp.seven.com> > > I'm not opposed, but I am confused. Don't we want to prevent and/or > retard de-aggregation? Are the consequences of de-aggregation of less > magnitude than the consequences of > failing to detach the notion of the LIR from the notion of the ISP? > Too late for that at this point. V4 is going to shatter into a million tiny pieces now. Where it will make a difference is in v6. Many don't take smaller than a /32 out of PA space but that will change as the pressure from v4 eases up and they aren't trying to run dual-stack. The only thing really pressuring not taking more specific than a /32 out of PA in v6 is v4 bloat and its impact on dual-stack routers. From rcarpen at network1.net Fri Feb 11 17:27:25 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Fri, 11 Feb 2011 17:27:25 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria - adopted In-Reply-To: <4D558787.1000509@arin.net> Message-ID: <83dde713-fb9c-4313-a629-2b22a6e5b1f6@zimbra.network1.net> Does anyone know how the fees will work once this is in place? An example is that we have a /48 at our main site, and have 2 remote sites now, and possibly more in the future. Under this new policy, we would qualify for a /44. We are an end-user, so we paid the fee for the /48 upfront, and just pay the maintenance fee. The initial fee is the same for a /48 or /44. If the policy were in place before, we would have just gotten the /44 to begin with. Do we have to pay the fee again to expand the /48 into a /44 ? thanks, -Randy ----- Original Message ----- > On 11 January 2011 the ARIN Board of Trustees adopted the following > policy: > > Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria > https://www.arin.net/policy/proposals/2010_8.html > > This policy will be be implemented no later than 30 April 2011. > > Board of Trustees Meeting Minutes are available at: > https://www.arin.net/about_us/bot/index.html > > Draft Policy and Policy Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2010-8 > Rework of IPv6 assignment criteria > > Version/Date: 23 November 2010 > > Policy statement: > > Replace section 6.5.8 as follows; > > 6.5.8. Direct assignments from ARIN to end-user organizations > > 6.5.8.1 Initial Assignment Criteria > > Organizations may justify an initial assignment for addressing > devices > directly attached to their own network infrastructure, with an intent > for the addresses to begin operational use within 12 months, by > meeting > one of the following criteria: > > a. Having a previously justified IPv4 end-user assignment from ARIN > or > one of its predecessor registries, or; > > b. Currently being IPv6 Multihomed or immediately becoming IPv6 > Multihomed and using an assigned valid global AS number, or; > > c. By having a network that makes active use of a minimum of 2000 > IPv6 > addresses within 12 months, or; > > d. By having a network that makes active use of a minimum of 200 /64 > subnets within 12 months, or; > > e. By providing a reasonable technical justification indicating why > IPv6 > addresses from an ISP or other LIR are unsuitable. > > Examples of justifications for why addresses from an ISP or other LIR > may be unsuitable include, but are not limited to: > > ? An organization that operates infrastructure critical to life > safety > or the functioning of society can justify the need for an assignment > based on the fact that renumbering would have a broader than expected > impact than simply the number of hosts directly involved. These would > include: hospitals, fire fighting, police, emergency response, power > or > energy distribution, water or waste treatment, traffic management and > control, etc? > ? Regardless of the number of hosts directly involved, an > organization > can justify the need for an assignment if renumbering would affect > 2000 > or more individuals either internal or external to the organization. > ? An organization with a network not connected to the Internet can > justify the need for an assignment by documenting a need for > guaranteed > uniqueness, beyond the statistical uniqueness provided by ULA (see > RFC > 4193). > ? An organization with a network not connected to the Internet, such > as > a VPN overlay network, can justify the need for an assignment if they > require authoritative delegation of reverse DNS. > > 6.5.8.2 Initial assignment size > > Organizations that meet at least one of the initial assignment > criteria > above are eligible to receive an initial assignment of /48. Requests > for > larger initial assignments, reasonably justified with supporting > documentation, will be evaluated based on the number of sites in an > organization?s network and the number of subnets needed to support > any > extra-large sites defined below. > > The initial assignment size will be determined by the number of sites > justified below. An organization qualifies for an assignment on the > next > larger nibble boundary when their sites exceed 75% of the /48s > available > in a prefix. For example: > > More than 1 but less than or equal to 12 sites justified, receives a > /44 > assignment; > More than 12 but less than or equal to 192 sites justified, receives > a > /40 assignment; > More than 192 but less than or equal to 3,072 sites justified, > receives > a /36 assignment; > More than 3,072 but less than or equal to 49,152 sites justified, > receives a /32 assignment; > etc... > > 6.5.8.2.1 Standard sites > > A site is a discrete location that is part of an organization?s > network. > A campus with multiple buildings may be considered as one or multiple > sites, based on the implementation of its network infrastructure. For > a > campus to be considered as multiple sites, reasonable technical > documentation must be submitted describing how the network > infrastructure is implemented in a manner equivalent to multiple > sites. > > An organization may request up to a /48 for each site in its network, > and any sites that will be operational within 12 months. > > 6.5.8.2.2 Extra-large sites > > In rare cases, an organization may request more than a /48 for an > extra-large site which requires more than 16,384 /64 subnets. In such > a > case, a detailed subnet plan must be submitted for each extra-large > site > in an organization?s network. An extra-large site qualifies for the > next > larger prefix when the total subnet utilization exceeds 25%. Each > extra-large site will be counted as an equivalent number of /48 > standard > sites. > > 6.5.8.3 Subsequent assignments > > Requests for subsequent assignments with supporting documentation > will > be evaluated based on the same criteria as an initial assignment > under > 6.5.8.2 with the following modifications: > > a. A subsequent assignment is justified when the total utilization > based > on the number of sites justified exceeds 75% across all of an > organization?s assignments. If the organization received an > assignment > per section 6.11 IPv6 Multiple Discrete Networks, such assignments > will > be evaluated as if they were to a separate organization. > > b. When possible subsequent assignments will result it the expansion > of > an existing assignment by one or more nibble boundaries as justified. > > c. If it is not possible to expand an existing assignment, or to > expand > it adequately to meet the justified need, then a separate new > assignment > will be made of the size justified. > > 6.5.8.4 Consolidation and return of separate assignments > > Organizations with multiple separate assignments should consolidate > into > a single aggregate, if feasible. If an organization stops using one > or > more of its separate assignments, any unused assignments must be > returned to ARIN. > > Rationale: > > This proposal provides a complete rework of the IPv6 end-user > assignment > criteria, removing the dependency on IPv4 policy, providing clear > guidance in requesting larger initial assignments, and eliminating > HD-Ratio as criteria for evaluating end-user assignments. > > The HD-Ratio is replaced with a simplified 75% utilization threshold > based on nibble boundaries for end-user assignments. This threshold > is > somewhat more restrictive for larger assignments, while slightly less > restrictive for the smaller /44 assignments, than the HD-Ratio. > However, > in both cases it is much easier for an end-user to understand the > policy > criteria that applies to them. > > The following general concepts are included: > > ? Previously justified IPv4 resources may be used to justify the need > for IPv6 resources > ? Internet multihoming is sufficient justification for an IPv6 > end-user > assignment in and of itself > ? Networks with more than 2000 hosts have a justified need for IPv6 > resources; as is the case in current policy, it is just more clearly > stated without relying on a reference to, and the consequences of, > IPv4 > policy > ? Networks with more than 200 subnets have a justified need for IPv6 > resources, independent of the number of hosts they have > ? Other end-users, not meeting one of the previous criteria, must > justify why an ISP or LIR assignment is not sufficient for their > needs > ? Reservations are no longer necessary as ARIN has committed to > sparse > assignment for IPv6 > ? Providing sufficiently large initial assignments based on nibble > boundaries along with sparse assignments will reduce route table > growth > caused solely by subsequent assignments > > Organizations with multiple sites may receive a /48 for each site in > their network. A campus with multiple buildings may be considered as > one > or multiple sites, based on the implementation of its network > infrastructure. When multiple separate organizations have networks in > the same building, such as in the case of a multi-tenant building, > each > organization justifies a separate /48 for its network at the site. > > The 25% subnet utilization for an extra-large site is proposed as the > threshold for a larger prefix in order to allow an extra-large site > enough room to create an organized subnet plan. Requiring denser > usage > would make it almost impossible for an extra-large site to maintain > any > kind of organized subnet plan. Furthermore, even at 25% utilization, > more than 16,384 subnets are required to justify more than a /48 for > a > site. Few, if any, sites can actually meet or exceed this threshold. > > Organizations may have multiple separate assignments due to previous > subsequent assignments made per clause 6.5.8.3.c or through Mergers > and > Acquisitions in section 8.2. These multiple separate assignments must > be > considered in total when making subsequent assignments, unless they > are > part multiple discrete networks, per section 6.11. > > The ARIN Board of Trusties should consider incentives that provide > additional motivation for end-users to consolidate into a single > aggregate per section 6.5.8.4 of this policy. > > Timetable for implementation: Immediate From jeffrey.lyon at blacklotus.net Fri Feb 11 18:21:55 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 11 Feb 2011 18:21:55 -0500 Subject: [arin-ppml] Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria - adopted In-Reply-To: <83dde713-fb9c-4313-a629-2b22a6e5b1f6@zimbra.network1.net> References: <4D558787.1000509@arin.net> <83dde713-fb9c-4313-a629-2b22a6e5b1f6@zimbra.network1.net> Message-ID: On Fri, Feb 11, 2011 at 5:27 PM, Randy Carpenter wrote: > > Does anyone know how the fees will work once this is in place? > > An example is that we have a /48 at our main site, and have 2 remote sites now, and possibly more in the future. Under this new policy, we would qualify for a /44. We are an end-user, so we paid the fee for the /48 upfront, and just pay the maintenance fee. The initial fee is the same for a /48 or /44. If the policy were in place before, we would have just gotten the /44 to begin with. Do we have to pay the fee again to expand the /48 into a /44 ? > > thanks, > -Randy > > > ----- Original Message ----- >> On 11 January 2011 the ARIN Board of Trustees adopted the following >> policy: >> >> ? ?Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria >> ? ?https://www.arin.net/policy/proposals/2010_8.html >> >> This policy will be be implemented no later than 30 April 2011. >> >> Board of Trustees Meeting Minutes are available at: >> https://www.arin.net/about_us/bot/index.html >> >> Draft Policy and Policy Proposal texts are available at: >> https://www.arin.net/policy/proposals/index.html >> >> The ARIN Policy Development Process can be found at: >> https://www.arin.net/policy/pdp.html >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> Draft Policy ARIN-2010-8 >> Rework of IPv6 assignment criteria >> >> Version/Date: 23 November 2010 >> >> Policy statement: >> >> Replace section 6.5.8 as follows; >> >> 6.5.8. Direct assignments from ARIN to end-user organizations >> >> 6.5.8.1 Initial Assignment Criteria >> >> Organizations may justify an initial assignment for addressing >> devices >> directly attached to their own network infrastructure, with an intent >> for the addresses to begin operational use within 12 months, by >> meeting >> one of the following criteria: >> >> a. Having a previously justified IPv4 end-user assignment from ARIN >> or >> one of its predecessor registries, or; >> >> b. Currently being IPv6 Multihomed or immediately becoming IPv6 >> Multihomed and using an assigned valid global AS number, or; >> >> c. By having a network that makes active use of a minimum of 2000 >> IPv6 >> addresses within 12 months, or; >> >> d. By having a network that makes active use of a minimum of 200 /64 >> subnets within 12 months, or; >> >> e. By providing a reasonable technical justification indicating why >> IPv6 >> addresses from an ISP or other LIR are unsuitable. >> >> Examples of justifications for why addresses from an ISP or other LIR >> may be unsuitable include, but are not limited to: >> >> ? An organization that operates infrastructure critical to life >> safety >> or the functioning of society can justify the need for an assignment >> based on the fact that renumbering would have a broader than expected >> impact than simply the number of hosts directly involved. These would >> include: hospitals, fire fighting, police, emergency response, power >> or >> energy distribution, water or waste treatment, traffic management and >> control, etc? >> ? Regardless of the number of hosts directly involved, an >> organization >> can justify the need for an assignment if renumbering would affect >> 2000 >> or more individuals either internal or external to the organization. >> ? An organization with a network not connected to the Internet can >> justify the need for an assignment by documenting a need for >> guaranteed >> uniqueness, beyond the statistical uniqueness provided by ULA (see >> RFC >> 4193). >> ? An organization with a network not connected to the Internet, such >> as >> a VPN overlay network, can justify the need for an assignment if they >> require authoritative delegation of reverse DNS. >> >> 6.5.8.2 Initial assignment size >> >> Organizations that meet at least one of the initial assignment >> criteria >> above are eligible to receive an initial assignment of /48. Requests >> for >> larger initial assignments, reasonably justified with supporting >> documentation, will be evaluated based on the number of sites in an >> organization?s network and the number of subnets needed to support >> any >> extra-large sites defined below. >> >> The initial assignment size will be determined by the number of sites >> justified below. An organization qualifies for an assignment on the >> next >> larger nibble boundary when their sites exceed 75% of the /48s >> available >> in a prefix. For example: >> >> More than 1 but less than or equal to 12 sites justified, receives a >> /44 >> assignment; >> More than 12 but less than or equal to 192 sites justified, receives >> a >> /40 assignment; >> More than 192 but less than or equal to 3,072 sites justified, >> receives >> a /36 assignment; >> More than 3,072 but less than or equal to 49,152 sites justified, >> receives a /32 assignment; >> etc... >> >> 6.5.8.2.1 Standard sites >> >> A site is a discrete location that is part of an organization?s >> network. >> A campus with multiple buildings may be considered as one or multiple >> sites, based on the implementation of its network infrastructure. For >> a >> campus to be considered as multiple sites, reasonable technical >> documentation must be submitted describing how the network >> infrastructure is implemented in a manner equivalent to multiple >> sites. >> >> An organization may request up to a /48 for each site in its network, >> and any sites that will be operational within 12 months. >> >> 6.5.8.2.2 Extra-large sites >> >> In rare cases, an organization may request more than a /48 for an >> extra-large site which requires more than 16,384 /64 subnets. In such >> a >> case, a detailed subnet plan must be submitted for each extra-large >> site >> in an organization?s network. An extra-large site qualifies for the >> next >> larger prefix when the total subnet utilization exceeds 25%. Each >> extra-large site will be counted as an equivalent number of /48 >> standard >> sites. >> >> 6.5.8.3 Subsequent assignments >> >> Requests for subsequent assignments with supporting documentation >> will >> be evaluated based on the same criteria as an initial assignment >> under >> 6.5.8.2 with the following modifications: >> >> a. A subsequent assignment is justified when the total utilization >> based >> on the number of sites justified exceeds 75% across all of an >> organization?s assignments. If the organization received an >> assignment >> per section 6.11 IPv6 Multiple Discrete Networks, such assignments >> will >> be evaluated as if they were to a separate organization. >> >> b. When possible subsequent assignments will result it the expansion >> of >> an existing assignment by one or more nibble boundaries as justified. >> >> c. If it is not possible to expand an existing assignment, or to >> expand >> it adequately to meet the justified need, then a separate new >> assignment >> will be made of the size justified. >> >> 6.5.8.4 Consolidation and return of separate assignments >> >> Organizations with multiple separate assignments should consolidate >> into >> a single aggregate, if feasible. If an organization stops using one >> or >> more of its separate assignments, any unused assignments must be >> returned to ARIN. >> >> Rationale: >> >> This proposal provides a complete rework of the IPv6 end-user >> assignment >> criteria, removing the dependency on IPv4 policy, providing clear >> guidance in requesting larger initial assignments, and eliminating >> HD-Ratio as criteria for evaluating end-user assignments. >> >> The HD-Ratio is replaced with a simplified 75% utilization threshold >> based on nibble boundaries for end-user assignments. This threshold >> is >> somewhat more restrictive for larger assignments, while slightly less >> restrictive for the smaller /44 assignments, than the HD-Ratio. >> However, >> in both cases it is much easier for an end-user to understand the >> policy >> criteria that applies to them. >> >> The following general concepts are included: >> >> ? Previously justified IPv4 resources may be used to justify the need >> for IPv6 resources >> ? Internet multihoming is sufficient justification for an IPv6 >> end-user >> assignment in and of itself >> ? Networks with more than 2000 hosts have a justified need for IPv6 >> resources; as is the case in current policy, it is just more clearly >> stated without relying on a reference to, and the consequences of, >> IPv4 >> policy >> ? Networks with more than 200 subnets have a justified need for IPv6 >> resources, independent of the number of hosts they have >> ? Other end-users, not meeting one of the previous criteria, must >> justify why an ISP or LIR assignment is not sufficient for their >> needs >> ? Reservations are no longer necessary as ARIN has committed to >> sparse >> assignment for IPv6 >> ? Providing sufficiently large initial assignments based on nibble >> boundaries along with sparse assignments will reduce route table >> growth >> caused solely by subsequent assignments >> >> Organizations with multiple sites may receive a /48 for each site in >> their network. A campus with multiple buildings may be considered as >> one >> or multiple sites, based on the implementation of its network >> infrastructure. When multiple separate organizations have networks in >> the same building, such as in the case of a multi-tenant building, >> each >> organization justifies a separate /48 for its network at the site. >> >> The 25% subnet utilization for an extra-large site is proposed as the >> threshold for a larger prefix in order to allow an extra-large site >> enough room to create an organized subnet plan. Requiring denser >> usage >> would make it almost impossible for an extra-large site to maintain >> any >> kind of organized subnet plan. Furthermore, even at 25% utilization, >> more than 16,384 subnets are required to justify more than a /48 for >> a >> site. Few, if any, sites can actually meet or exceed this threshold. >> >> Organizations may have multiple separate assignments due to previous >> subsequent assignments made per clause 6.5.8.3.c or through Mergers >> and >> Acquisitions in section 8.2. These multiple separate assignments must >> be >> considered in total when making subsequent assignments, unless they >> are >> part multiple discrete networks, per section 6.11. >> >> The ARIN Board of Trusties should consider incentives that provide >> additional motivation for end-users to consolidate into a single >> aggregate per section 6.5.8.4 of this policy. >> >> Timetable for implementation: Immediate > > _______________________________________________ > 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. ARIN will only charge you once annually for whatever size allocation you have. There is no fee for requesting additional resources until your membership comes up for renewal. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Fri Feb 11 18:29:22 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 11 Feb 2011 18:29:22 -0500 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13A5B@RWC-EX1.corp.seven.com> References: <4D556387.3000300@arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13A4B@RWC-EX1.corp.seven.com> <4D55A798.9020401@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13A5B@RWC-EX1.corp.seven.com> Message-ID: On Fri, Feb 11, 2011 at 5:32 PM, George Bonser wrote: >> >> I'm not opposed, but I am confused. Don't we want to prevent and/or >> retard de-aggregation? ?Are the consequences of de-aggregation of less >> magnitude than the consequences of >> failing to detach the notion of the LIR from the notion of the ISP? >> > > Too late for that at this point. ?V4 is going to shatter into a million > tiny pieces now. Where it will make a difference is in v6. ?Many don't > take smaller than a /32 out of PA space but that will change as the > pressure from v4 eases up and they aren't trying to run dual-stack. ?The > only thing really pressuring not taking more specific than a /32 out of > PA in v6 is v4 bloat and its impact on dual-stack routers. > > > _______________________________________________ > 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. > Certainly this is outside the scope of ARIN-prop-132, but wouldn't we be frying a bigger fish by tackling what qualifies as justification and requiring more efficient use of space? I've seen hosting providers offering some really silly justification to ARIN and giving out one or more /24's with a dedicated server in exchange for a small fee. Perhaps single customers of /24's and shorter should have to remit their justification directly to ARIN on a revolving basis to prevent waste and fraud. If I tell a customer that their justification is poor and refuse to issue space, some other provider will become more creative with the justification and grant them the same. Centralizing the justification of space at a more micro level would certainly have an impact. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From farmer at umn.edu Fri Feb 11 18:30:44 2011 From: farmer at umn.edu (David Farmer) Date: Fri, 11 Feb 2011 17:30:44 -0600 Subject: [arin-ppml] Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria - adopted In-Reply-To: <83dde713-fb9c-4313-a629-2b22a6e5b1f6@zimbra.network1.net> References: <83dde713-fb9c-4313-a629-2b22a6e5b1f6@zimbra.network1.net> Message-ID: <4D55C6A4.9020501@umn.edu> Fees are not directly a policy issue. However, I would hope the Board could find a way to minimize any early adopter tax, as one might refer to this issue if one were so inclined. That said, there still probably needs to be some additional fee, additional work will be done. Here is a simple idea; If an end-user organization that already received an IPv6 assignment and is eligible to receive a larger assignment with this new policy, their fee will be the larger of $500 or the difference between what their new fee would have been and their original fee, if the new assignment is processed before December 31, 2011. Just an idea; We should probably discuss this issue related to Draft Policy 2011-3: Better IPv6 Allocations for ISPs, as well. There is likely to be a similar issue with that policy too. On 2/11/11 16:27 CST, Randy Carpenter wrote: > > Does anyone know how the fees will work once this is in place? > > An example is that we have a /48 at our main site, and have 2 remote sites now, and possibly more in the future. Under this new policy, we would qualify for a /44. We are an end-user, so we paid the fee for the /48 upfront, and just pay the maintenance fee. The initial fee is the same for a /48 or /44. If the policy were in place before, we would have just gotten the /44 to begin with. Do we have to pay the fee again to expand the /48 into a /44 ? > > thanks, > -Randy > > =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From owen at delong.com Fri Feb 11 18:50:46 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Feb 2011 15:50:46 -0800 Subject: [arin-ppml] Draft Policy ARIN-2010-8: Rework of IPv6 assignment criteria - adopted In-Reply-To: References: <4D558787.1000509@arin.net> <83dde713-fb9c-4313-a629-2b22a6e5b1f6@zimbra.network1.net> Message-ID: <4C7AB1D1-DD90-4E2C-A4A0-221695136669@delong.com> Jeffrey, You are confused. This policy is for end-user assignments. They are not charged the same as ISPs. The ISP fees operate as you described below. End user assignments do not. I don't yet know what the board will do with respect to the original question asked. Owen >> > > ARIN will only charge you once annually for whatever size allocation > you have. There is no fee for requesting additional resources until > your membership comes up for renewal. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > _______________________________________________ > 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 Fri Feb 11 20:23:51 2011 From: jcurran at arin.net (John Curran) Date: Sat, 12 Feb 2011 01:23:51 +0000 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <290D2C2F-6FAF-4B11-A4D8-01F63546335A@queuefull.net> References: <4D556387.3000300@arin.net> <290D2C2F-6FAF-4B11-A4D8-01F63546335A@queuefull.net> Message-ID: On Feb 11, 2011, at 5:18 PM, Benson Schliesser wrote: > The goal of ARIN-prop-132 is to clarify the definition of "customer" in 4.2.1.1, leaving the rest of the NRPM unchanged. As written, I do not believe that it impact any other aspects of policy. That would mean all of these assignments would also be (per 4.2.3.4) need-based (requiring 80% utilization for assignments to end-user customers and following the ARIN to ISP utilization requirements for customer ISP allocations) Is that your intent? /John John Curran President and CEO ARIN From jbates at brightok.net Fri Feb 11 20:32:14 2011 From: jbates at brightok.net (Jack Bates) Date: Fri, 11 Feb 2011 19:32:14 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> <290D2C2F-6FAF-4B11-A4D8-01F63546335A@queuefull.net> Message-ID: <4D55E31E.6050301@brightok.net> On 2/11/2011 7:23 PM, John Curran wrote: > That would mean all of these assignments would also be (per 4.2.3.4) need-based > (requiring 80% utilization for assignments to end-user customers and following > the ARIN to ISP utilization requirements for customer ISP allocations) > I believe that's exactly what he meant. I do wonder, though, if this proposal isn't perhaps redundant with prop-121's LIR/ISP interchangeable definitions? Does it actually add clarity with prop-121 as well as current NRPM? Jack From bensons at queuefull.net Fri Feb 11 20:34:04 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 11 Feb 2011 19:34:04 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> <290D2C2F-6FAF-4B11-A4D8-01F63546335A@queuefull.net> Message-ID: On Feb 11, 2011, at 7:23 PM, John Curran wrote: > On Feb 11, 2011, at 5:18 PM, Benson Schliesser wrote: >> The goal of ARIN-prop-132 is to clarify the definition of "customer" in 4.2.1.1, leaving the rest of the NRPM unchanged. As written, I do not believe that it impact any other aspects of policy. > > That would mean all of these assignments would also be (per 4.2.3.4) need-based > (requiring 80% utilization for assignments to end-user customers and following > the ARIN to ISP utilization requirements for customer ISP allocations) > > Is that your intent? Yes, for policy proposal 132, that is my intent. I'm currently drafting another policy proposal that will deal with the topic of need-based justification. But I don't think it's useful to introduce that complexity to prop-132. Cheers, -Benson From hannigan at gmail.com Mon Feb 14 09:55:28 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Feb 2011 09:55:28 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: On Wed, Feb 9, 2011 at 6:22 PM, Chris Grundemann wrote: [ snip ] > Marty - Can you shed some light onto why this is (and needs to be) > limited to legacy space? I don't see a need for the distinction but > could certainly be missing something. Chris, In the past, we've heard numerous ARIN folks talking about "clear instructions from the community". Right now, we have multiple global policies circulating trying to determine what should be done with ipv4 legacy addresses in the ARIN region. ARIN has always treated IPv4 legacy addresses different (LRSA, etc) and our discussions make distinctions between "RSA" and "legacy holders". There is likely some minor, but necessary policy required to make whatever will transpire with legacy addresses acceptable and workable to all. This would be a clear instruction that would leave no ambiguity with respect to what the community wants ARIN to do with legacy addresses. This proposal leaves noone wondering what will happen to addresses returned to ARIN and it codifies the requirement. Is there a problem with resources already in ARIN's possession being returned to "inventory"? If there is, in the interest of clarity, I think it would be better to submit an ASCP item or propose something specific IMHO. I've softened this enough to hopefully clarify it's intent. As a side benefit, it should also encourage people writing global policies to work together. Best, -M< Best, -M< From packetgrrl at gmail.com Mon Feb 14 10:08:06 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 14 Feb 2011 08:08:06 -0700 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: Martin, I thought that one of the purposes for this proposal was to provide specific guidance for returned blocks because of the absence of a policy for the IANA to hand out blocks longer than a /8. There is no policy at IANA for blocks of legacy or non-legacy space longer than a /8. It seems to me that this policy should include both legacy and non-legacy space so that it is clear what ARIN will do with all blocks that are returned. Thanks ----Cathy On Mon, Feb 14, 2011 at 7:55 AM, Martin Hannigan wrote: > On Wed, Feb 9, 2011 at 6:22 PM, Chris Grundemann > wrote: > > [ snip ] > > > Marty - Can you shed some light onto why this is (and needs to be) > > limited to legacy space? I don't see a need for the distinction but > > could certainly be missing something. > > Chris, > > In the past, we've heard numerous ARIN folks talking about "clear > instructions from the community". > > Right now, we have multiple global policies circulating trying to > determine what should be done with ipv4 legacy addresses in the ARIN > region. > > ARIN has always treated IPv4 legacy addresses different (LRSA, etc) > and our discussions make distinctions between "RSA" and "legacy > holders". > > There is likely some minor, but necessary policy required to make > whatever will transpire with legacy addresses acceptable and workable > to all. > > This would be a clear instruction that would leave no ambiguity with > respect to what the community wants ARIN to do with legacy addresses. > This proposal leaves noone wondering what will happen to addresses > returned to ARIN and it codifies the requirement. > > Is there a problem with resources already in ARIN's possession being > returned to "inventory"? If there is, in the interest of clarity, I > think it would be better to submit an ASCP item or propose something > specific IMHO. > > I've softened this enough to hopefully clarify it's intent. As a side > benefit, it should also encourage people writing global policies to > work together. > > Best, > > -M< > > > Best, > > -M< > _______________________________________________ > 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 info at arin.net Mon Feb 14 11:49:22 2011 From: info at arin.net (ARIN) Date: Mon, 14 Feb 2011 11:49:22 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks Message-ID: <4D595D12.4000602@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 13 February 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.1. No Volunteer Services Except in the specific circumstances described by this policy, ARIN will not provide any services for any organization and/or address block. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. 13.1.1. Requested Services In the event that an organization explicitly requests registry services from ARIN for one or more specified address blocks, ARIN may provide the requested services, subsequent to execution of a service contract, for those address blocks. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. All address blocks that are assigned or allocated by ARIN under a valid RSA, as well as specific address blocks that are included under a Legacy RSA with the legitimate validated address holder, are deemed to have services requested for them. An organization requesting registry services for one or more specified address blocks, that also holds additional address blocks not specified in their request, is not obligated to receive registry services for those additional address blocks and those blocks are not deemed to have services requested for them. 13.1.2. Directory Placeholders For any address blocks, for which there are not fully executed ARIN service contracts, ARIN will create generic placeholder entries in the ARIN Whois directory. These placeholder entries will not specify organizational details, but will indicate that the entry represents a non-member resource. When applicable, each non-member resource placeholder will include a reference and/or RWhois referral to the authoritative directory service for that block, or the directory service operated by the IANA, or by another organization in the event that IANA has delegated their directory service responsibility to that organization. This does not apply to placeholders that represent an unassigned and unallocated address block delegated to ARIN by the IANA. 13.2. Recognition of Legitimate Address Holders ARIN will use the following criteria in order to determine whether an organization is the legitimate address holder for a given IP address block. 13.2.1. Original Allocation Record The original allocation records, such as those documented in RFC 1166 issued in July of 1990 or the InterNIC database received by ARIN from Network Solutions in December of 1997, will be used as dispositive proof, absent any contrary documentation such as those specified in section 13.2.4 below, in determining whether an organization is the legitimate address holder. 13.2.2 IANA Records of Legitimate Address Holders In the event that the IANA has historical records, and/or current records, showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as proof, absent any contrary documentation, in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.2.4 below, the evidence from the original allocation record will take precedence. 13.2.3. Records Maintained on Behalf of the IANA In the event that the IANA has delegated responsibility for the management of an address block to another organization, including ARIN or any other RIR, and that organization has historical and/or current records showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as evidence in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.2.4 below, the evidence from the original allocation record will take precedence. 13.2.4. Formal Records Clarifying the Chain of Custody In the event that formal records, such as public records or other formal documents which can be authenticated or verified to include legal, financial, and other organizational documentation, are provided to ARIN by an organization seeking recognition of their status as the legitimate address holder, then ARIN will consider the impact of these records as potentially updating any evidence that may exist. If these records clearly document the assignment or allocation of a given IP address block to a specific organization by direct assignment, and/or organizational transitions such as mergers, acquisitions, business unit restructuring, asset transfers, name changes, and so forth, absent definitive documentation to the contrary, then these records will determine whether an organization is the legitimate address holder. 13.3. Permitted Updates to Directory Services for Unaffiliated Address Blocks Any organization that legitimately holds an address block, as defined by section 13.2 of this policy, may request the removal or modification of existing directory placeholders representing that address block. Valid requests for modification of placeholder entries are limited to references and/or RWhois referrals to authoritative directory services, such as directory services operated by or on behalf of the IANA, another address registry, or the address holder. In the event that such a request is received, ARIN may choose to either remove the placeholder entry or update it per the request. Rationale: Policy Background: This policy attempts to clarify the relationship that ARIN has with legacy address holders. Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical. This policy would require positive affirmation from any legacy address holder that wishes to receive registry services, moving to an "opt-in" approach. In the event that a legacy address holder does not opt-in to receive registry services, ARIN is limited to providing no more than a pointer (such as a RWhois referral) to an authoritative directory service for that holder's legacy address blocks. Pointers to other providers of directory services for addresses managed by those other providers continue to be permitted. Policy Structure: This policy introduces a new section to the NRPM, numbered section 13. Within this new section, there are three sub-sections. Sub-section 13.1 introduces policy that limits ARIN to providing services on an opt-in basis. It does make clear in 13.1.1 that services provided as part of a RSA or LRSA are automatically considered opted-in. With 13.1.2 it allows ARIN to create placeholders in the Whois database for blocks managed by other RIRs as well as for blocks managed (but unassigned/unallocated) by ARIN. Sub-section 13.2 introduces policy that specifies how ARIN will go about determining who a "legitimate" address holder is. It is similar to current procedure with 13.2.2 and 13.2.3, which specify the use of IANA and RIR records. It expands on the current procedures with 13.2.4, allowing organizations to provide legal documentation of organizational changes and/or the transfer of custody of a legacy address block. Sub-section 13.3 introduces policy enabling legitimate address holders to request a very limited update to any Whois placeholders that might exist for their legacy address block, so that the Whois will refer queries to the authoritative directory service. It is expected that ARIN will charge a fee for this update, but not require an ongoing services agreement. ARIN is given the option of deleting placeholders instead. Timetable for implementation: Immediately From info at arin.net Mon Feb 14 12:07:47 2011 From: info at arin.net (ARIN) Date: Mon, 14 Feb 2011 12:07:47 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] Message-ID: <4D596163.7000009@arin.net> ARIN staff has an additional comment to make in our assessment of this draft policy: ? In keeping with the spirit of RFC 2860 with respect to the assignment of specialized address blocks, ARIN Staff will consult with the IANA and the IAB regarding implementation of this draft policy. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) -------- Original Message -------- Subject: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension Date: Thu, 03 Feb 2011 16:49:13 -0500 From: ARIN To: arin-ppml at arin.net Draft Policy ARIN-2011-5 Shared Transition Space for IPv4 Address Extension On 28 January 2011 the ARIN Advisory Council (AC) selected "Shared Transition Space for IPv4 Address Extension" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-127. Shared Transition Space for IPv4 Address Extension". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Draft Policy ARIN-2011-5 is below and can be found at: https://www.arin.net/policy/proposals/2011_5.html You are encouraged to discuss Draft Policy 2011-5 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-5 Shared Transition Space for IPv4 Address Extension Date: 20 January 2011 Policy statement: Updates 4.10 of the NRPM: A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators. Rationale: The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet. Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider. Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed. Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. ?squat?). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs. Timetable for implementation: immediately ##### STAFF ASSESSMENT Proposal: ?Shared Transition Space for IPv4 Address Extension? Policy Version (Date): 20 January 2011 Date of Assessment: 26 January 2011 1. Proposal Summary (Staff Understanding) This proposal asks ARIN to reserve and register a single, contiguous /10 in ARIN's Whois in a fashion similar to blocks reserved by RFCs (like RFC1918 or RFC3068). The block is never to be assigned directly to any organization and is to be shared by anyone who wishes to use it, with no further registration actions required by ARIN. Staff understands that this space is not to be routed on the public Internet and that there will be multiple people using the same address space much like is done with RFC 1918 space today. 2. Comments A. ARIN Staff Comments ? This proposal would have ARIN acting as the registrant for this single IP block and maintaining it without us (or the public) knowing who is actually using it or how they are using it. This will likely generate a great deal of abuse and spam complaints to ARIN. ? It is unclear whether ARIN would need to set up nameservers for this block to provide rDNS. B. ARIN General Counsel No legal comments 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Updated guidelines ? Staff training 4. Proposal Text Policy statement: Updates 4.10 of the NRPM: A second contiguous /10 IPv4 block will be reserved to facilitate IPv4 address extension. This block will not be allocated or assigned to any single organization, but is to be shared by Service Providers for internal use for IPv4 address extension deployments until connected networks fully support IPv6. Examples of such needs include: IPv4 addresses between home gateways and NAT444 translators. Rationale: The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of upgrading to IPv6. Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to reach the IPv4 Internet. Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4 operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the customer contracts for new service with a new provider. Until such customers replace their Home Gateways and all IPv4-only devices with IPv6-capable devices, Service Providers will be required to continue to offer IPv4 services through the use of an IPv4 address sharing technology such as NAT444. A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed. Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use address space allocated to another entity (i.e. ?squat?). Of the three options, option 2 (this proposal) is preferable, as it will minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs. From jcurran at arin.net Mon Feb 14 12:40:31 2011 From: jcurran at arin.net (John Curran) Date: Mon, 14 Feb 2011 17:40:31 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D595D12.4000602@arin.net> References: <4D595D12.4000602@arin.net> Message-ID: <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> On Feb 14, 2011, at 11:49 AM, ARIN wrote: > > 13.2.4. Formal Records Clarifying the Chain of Custody > > ... If these records > clearly document the assignment or allocation of a given IP address > block to a specific organization by direct assignment, and/or > organizational transitions such as mergers, acquisitions, business unit > restructuring, asset transfers, name changes, and so forth, absent > definitive documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. Benson - For clarity, this would result in an "assignment" taking place for an IP address block independent of any other contrary policy developed by the ARIN community, correct? Thanks, /John John Curran President and CEO ARIN From bensons at queuefull.net Mon Feb 14 13:30:33 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 14 Feb 2011 12:30:33 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> References: <4D595D12.4000602@arin.net> <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> Message-ID: <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> Hi, John. On Feb 14, 2011, at 11:40 AM, John Curran wrote: > On Feb 14, 2011, at 11:49 AM, ARIN wrote: >> >> 13.2.4. Formal Records Clarifying the Chain of Custody >> >> ... If these records >> clearly document the assignment or allocation of a given IP address >> block to a specific organization by direct assignment, and/or >> organizational transitions such as mergers, acquisitions, business unit >> restructuring, asset transfers, name changes, and so forth, absent >> definitive documentation to the contrary, then these records will >> determine whether an organization is the legitimate address holder. > > Benson - > > For clarity, this would result in an "assignment" taking place for an > IP address block independent of any other contrary policy developed by > the ARIN community, correct? I think you understand the effect of the text, yes. But my answer is a bit more nuanced: Policy proposal 133, in section 13.2, would have ARIN recognize assignments that take place beyond ARIN's scope. In other words, the act of ARIN recognizing the new legitimate address holder is not what creates the assignment; the assignment would have already taken place and ARIN would simply be recognizing that fact. If the assignment was not legally permitted (e.g. for addresses received under RSA or similar RIR contract, or if the assignment was otherwise prohibited by law) then ARIN should probably not recognize the assignment when considering the impact on existing evidence. Please let me know if I can clarify this point further, or if you have any other questions or comments. Cheers, -Benson From cgrundemann at gmail.com Mon Feb 14 13:44:12 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 14 Feb 2011 11:44:12 -0700 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: On Mon, Feb 14, 2011 at 08:08, cja at daydream.com wrote: > Martin, > I thought that one of the purposes for this proposal was to provide specific > guidance for returned blocks because of the absence of a policy for the IANA > to hand out blocks longer than a /8. ?There is no policy at IANA for blocks > of legacy or non-legacy space longer than a /8. ? It seems to me that this > policy should include both legacy and non-legacy space so that it is clear > what ARIN will do with all blocks that are returned. > Thanks I agree. I see no reason to distinguish in this case. IMHO, this policy should apply to ALL addresses returned to ARIN. > ----Cathy > > On Mon, Feb 14, 2011 at 7:55 AM, Martin Hannigan wrote: >> >> On Wed, Feb 9, 2011 at 6:22 PM, Chris Grundemann >> wrote: >> >> [ snip ] >> >> > Marty - Can you shed some light onto why this is (and needs to be) >> > limited to legacy space? I don't see a need for the distinction but >> > could certainly be missing something. >> >> Chris, >> >> In the past, we've heard numerous ARIN folks talking about "clear >> instructions from the community". >> >> Right now, we have multiple global policies circulating trying to >> determine what should be done with ipv4 legacy addresses in the ARIN >> region. >> >> ARIN has always treated IPv4 legacy addresses different (LRSA, etc) >> and our discussions make distinctions between "RSA" and "legacy >> holders". Understood. >> There is likely some minor, but necessary policy required to make >> whatever will transpire with legacy addresses acceptable and workable >> to all. Possibly. >> This would be a clear instruction that would leave no ambiguity with >> respect to what the community wants ARIN to do with legacy addresses. >> This proposal leaves noone wondering what will happen to addresses >> returned to ARIN and it codifies the requirement. I agree that this provides clear instruction. What I still don't understand is why that instruction should apply only to "legacy" resources. >> Is there a problem with resources already in ARIN's possession being >> returned to "inventory"? If there is, in the interest of clarity, I >> think it would be better to submit an ASCP item or propose something >> specific IMHO. I think it would be much easier to simply remove the word legacy from this text and make it apply to all resources. ~Chris >> I've softened this enough to hopefully clarify it's intent. As a side >> benefit, it should also encourage people writing global policies to >> work together. >> >> Best, >> >> -M< >> >> >> Best, >> >> -M< >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From hannigan at gmail.com Mon Feb 14 13:56:34 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Feb 2011 13:56:34 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: On Mon, Feb 14, 2011 at 1:44 PM, Chris Grundemann > > I agree. I see no reason to distinguish in this case. IMHO, this > policy should apply to ALL addresses returned to ARIN. > I disagree. If some on the AC want to modify this when the AC receives it, that's up to them. I've made the edits that will resolve the issues that I've identified in the most clear and concise way possible. So far, I've heard only straw-men as to why to include any other text. If I read something that is significant and that doesn't seek to lop on complexity and unnecessary actions, I'll be happy to reconsider. Best, -M< From Keith at jcc.com Mon Feb 14 14:03:31 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 14 Feb 2011 14:03:31 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <4D595D34.1090709@arin.net> References: <4D595D34.1090709@arin.net> Message-ID: <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> I am unconvinced that the problem that proposal 113 is attempting to correct is a real problem. It looks a lot like another swipe at legacy resource holders for their perceived sins. I am opposed to proposal 113. Keith Hare ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ -----Original Message----- From: arin-announce-bounces at arin.net [mailto:arin-announce-bounces at arin.net] On Behalf Of ARIN Sent: Monday, February 14, 2011 11:50 AM To: arin-announce at arin.net Subject: [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] The following is a new policy proposal that has been posted to the ARIN Public Policy Mailing List for discussion on that list. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) -------- Original Message -------- Subject: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks Date: Mon, 14 Feb 2011 11:49:22 -0500 From: ARIN To: arin-ppml at arin.net ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 13 February 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.1. No Volunteer Services Except in the specific circumstances described by this policy, ARIN will not provide any services for any organization and/or address block. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. 13.1.1. Requested Services In the event that an organization explicitly requests registry services from ARIN for one or more specified address blocks, ARIN may provide the requested services, subsequent to execution of a service contract, for those address blocks. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. All address blocks that are assigned or allocated by ARIN under a valid RSA, as well as specific address blocks that are included under a Legacy RSA with the legitimate validated address holder, are deemed to have services requested for them. An organization requesting registry services for one or more specified address blocks, that also holds additional address blocks not specified in their request, is not obligated to receive registry services for those additional address blocks and those blocks are not deemed to have services requested for them. 13.1.2. Directory Placeholders For any address blocks, for which there are not fully executed ARIN service contracts, ARIN will create generic placeholder entries in the ARIN Whois directory. These placeholder entries will not specify organizational details, but will indicate that the entry represents a non-member resource. When applicable, each non-member resource placeholder will include a reference and/or RWhois referral to the authoritative directory service for that block, or the directory service operated by the IANA, or by another organization in the event that IANA has delegated their directory service responsibility to that organization. This does not apply to placeholders that represent an unassigned and unallocated address block delegated to ARIN by the IANA. 13.2. Recognition of Legitimate Address Holders ARIN will use the following criteria in order to determine whether an organization is the legitimate address holder for a given IP address block. 13.2.1. Original Allocation Record The original allocation records, such as those documented in RFC 1166 issued in July of 1990 or the InterNIC database received by ARIN from Network Solutions in December of 1997, will be used as dispositive proof, absent any contrary documentation such as those specified in section 13.2.4 below, in determining whether an organization is the legitimate address holder. 13.2.2 IANA Records of Legitimate Address Holders In the event that the IANA has historical records, and/or current records, showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as proof, absent any contrary documentation, in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.2.4 below, the evidence from the original allocation record will take precedence. 13.2.3. Records Maintained on Behalf of the IANA In the event that the IANA has delegated responsibility for the management of an address block to another organization, including ARIN or any other RIR, and that organization has historical and/or current records showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as evidence in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.2.4 below, the evidence from the original allocation record will take precedence. 13.2.4. Formal Records Clarifying the Chain of Custody In the event that formal records, such as public records or other formal documents which can be authenticated or verified to include legal, financial, and other organizational documentation, are provided to ARIN by an organization seeking recognition of their status as the legitimate address holder, then ARIN will consider the impact of these records as potentially updating any evidence that may exist. If these records clearly document the assignment or allocation of a given IP address block to a specific organization by direct assignment, and/or organizational transitions such as mergers, acquisitions, business unit restructuring, asset transfers, name changes, and so forth, absent definitive documentation to the contrary, then these records will determine whether an organization is the legitimate address holder. 13.3. Permitted Updates to Directory Services for Unaffiliated Address Blocks Any organization that legitimately holds an address block, as defined by section 13.2 of this policy, may request the removal or modification of existing directory placeholders representing that address block. Valid requests for modification of placeholder entries are limited to references and/or RWhois referrals to authoritative directory services, such as directory services operated by or on behalf of the IANA, another address registry, or the address holder. In the event that such a request is received, ARIN may choose to either remove the placeholder entry or update it per the request. Rationale: Policy Background: This policy attempts to clarify the relationship that ARIN has with legacy address holders. Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical. This policy would require positive affirmation from any legacy address holder that wishes to receive registry services, moving to an "opt-in" approach. In the event that a legacy address holder does not opt-in to receive registry services, ARIN is limited to providing no more than a pointer (such as a RWhois referral) to an authoritative directory service for that holder's legacy address blocks. Pointers to other providers of directory services for addresses managed by those other providers continue to be permitted. Policy Structure: This policy introduces a new section to the NRPM, numbered section 13. Within this new section, there are three sub-sections. Sub-section 13.1 introduces policy that limits ARIN to providing services on an opt-in basis. It does make clear in 13.1.1 that services provided as part of a RSA or LRSA are automatically considered opted-in. With 13.1.2 it allows ARIN to create placeholders in the Whois database for blocks managed by other RIRs as well as for blocks managed (but unassigned/unallocated) by ARIN. Sub-section 13.2 introduces policy that specifies how ARIN will go about determining who a "legitimate" address holder is. It is similar to current procedure with 13.2.2 and 13.2.3, which specify the use of IANA and RIR records. It expands on the current procedures with 13.2.4, allowing organizations to provide legal documentation of organizational changes and/or the transfer of custody of a legacy address block. Sub-section 13.3 introduces policy enabling legitimate address holders to request a very limited update to any Whois placeholders that might exist for their legacy address block, so that the Whois will refer queries to the authoritative directory service. It is expected that ARIN will charge a fee for this update, but not require an ongoing services agreement. ARIN is given the option of deleting placeholders instead. Timetable for implementation: Immediately _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-announce Please contact info at arin.net if you experience any issues. From bensons at queuefull.net Mon Feb 14 14:17:16 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 14 Feb 2011 13:17:16 -0600 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> Message-ID: Hi, Keith. On Feb 14, 2011, at 1:03 PM, Keith W. Hare wrote: > I am unconvinced that the problem that proposal 113 is attempting to correct is a real problem. It looks a lot like another swipe at legacy resource holders for their perceived sins. > > I am opposed to proposal 113. I assume you mean proposal 133, correct? If that is the case, I'd like to clarify: I intend for prop 133 to be the opposite of a "swipe at legacy resource holders for their perceived sins". Rather, I see legacy address holders currently subjected to ARIN policy despite having no contractual relationship with ARIN. This proposal would make the separation more clear, and restrict the use of Whois as a proxy for regulation/enforcement. Having said that, I can understand that some legacy address holders will want to continue receiving services from ARIN, including Whois and in-addr DNS. The LRSA is one way to facilitate that without an ambiguous relationship. We may also want to propose an alternative mechanism, assuming that the LRSA is unappealing, but I have not included that in prop 133 at this time. Cheers, -Benson > > -----Original Message----- > From: arin-announce-bounces at arin.net [mailto:arin-announce-bounces at arin.net] On Behalf Of ARIN > Sent: Monday, February 14, 2011 11:50 AM > To: arin-announce at arin.net > Subject: [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] > > The following is a new policy proposal that has been posted to the ARIN > Public Policy Mailing List for discussion on that list. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > -------- Original Message -------- > Subject: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated > Address Blocks > Date: Mon, 14 Feb 2011 11:49:22 -0500 > From: ARIN > To: arin-ppml at arin.net > > > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address > Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 13 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.1. No Volunteer Services > > Except in the specific circumstances described by this policy, ARIN will > not provide any services for any organization and/or address block. This > includes without limitation all directory services, reverse mapping > services, and future services that may be provided to the community. > > 13.1.1. Requested Services > > In the event that an organization explicitly requests registry services > from ARIN for one or more specified address blocks, ARIN may provide the > requested services, subsequent to execution of a service contract, for > those address blocks. This includes without limitation all directory > services, reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN under a valid > RSA, as well as specific address blocks that are included under a Legacy > RSA with the legitimate validated address holder, are deemed to have > services requested for them. > > An organization requesting registry services for one or more specified > address blocks, that also holds additional address blocks not specified > in their request, is not obligated to receive registry services for > those additional address blocks and those blocks are not deemed to have > services requested for them. > > 13.1.2. Directory Placeholders > > For any address blocks, for which there are not fully executed ARIN > service contracts, ARIN will create generic placeholder entries in the > ARIN Whois directory. These placeholder entries will not specify > organizational details, but will indicate that the entry represents a > non-member resource. > > When applicable, each non-member resource placeholder will include a > reference and/or RWhois referral to the authoritative directory service > for that block, or the directory service operated by the IANA, or by > another organization in the event that IANA has delegated their > directory service responsibility to that organization. This does not > apply to placeholders that represent an unassigned and unallocated > address block delegated to ARIN by the IANA. > > 13.2. Recognition of Legitimate Address Holders > > ARIN will use the following criteria in order to determine whether an > organization is the legitimate address holder for a given IP address block. > > 13.2.1. Original Allocation Record > > The original allocation records, such as those documented in RFC 1166 > issued in July of 1990 or the InterNIC database received by ARIN from > Network Solutions in December of 1997, will be used as dispositive > proof, absent any contrary documentation such as those specified in > section 13.2.4 below, in determining whether an organization is the > legitimate address holder. > > 13.2.2 IANA Records of Legitimate Address Holders > > In the event that the IANA has historical records, and/or current > records, showing the assignment or allocation of a given IP address > block to a specific organization, those records will be used as proof, > absent any contrary documentation, in determining whether an > organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.2.4 below, the evidence from the > original allocation record will take precedence. > > 13.2.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for the > management of an address block to another organization, including ARIN > or any other RIR, and that organization has historical and/or current > records showing the assignment or allocation of a given IP address block > to a specific organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.2.4 below, the evidence from the > original allocation record will take precedence. > > 13.2.4. Formal Records Clarifying the Chain of Custody > > In the event that formal records, such as public records or other formal > documents which can be authenticated or verified to include legal, > financial, and other organizational documentation, are provided to ARIN > by an organization seeking recognition of their status as the legitimate > address holder, then ARIN will consider the impact of these records as > potentially updating any evidence that may exist. If these records > clearly document the assignment or allocation of a given IP address > block to a specific organization by direct assignment, and/or > organizational transitions such as mergers, acquisitions, business unit > restructuring, asset transfers, name changes, and so forth, absent > definitive documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. > > 13.3. Permitted Updates to Directory Services for Unaffiliated Address > Blocks > > Any organization that legitimately holds an address block, as defined by > section 13.2 of this policy, may request the removal or modification of > existing directory placeholders representing that address block. > > Valid requests for modification of placeholder entries are limited to > references and/or RWhois referrals to authoritative directory services, > such as directory services operated by or on behalf of the IANA, another > address registry, or the address holder. In the event that such a > request is received, ARIN may choose to either remove the placeholder > entry or update it per the request. > > > Rationale: > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy would require positive affirmation from any legacy address > holder that wishes to receive registry services, moving to an "opt-in" > approach. In the event that a legacy address holder does not opt-in to > receive registry services, ARIN is limited to providing no more than a > pointer (such as a RWhois referral) to an authoritative directory > service for that holder's legacy address blocks. Pointers to other > providers of directory services for addresses managed by those > other providers continue to be permitted. > > Policy Structure: > > This policy introduces a new section to the NRPM, numbered section 13. > Within this new section, there are three sub-sections. > > Sub-section 13.1 introduces policy that limits ARIN to providing > services on an opt-in basis. It does make clear in 13.1.1 that services > provided as part of a RSA or LRSA are automatically considered opted-in. > With 13.1.2 it allows ARIN to create placeholders in the Whois > database for blocks managed by other RIRs as well as for blocks managed > (but unassigned/unallocated) by ARIN. > > Sub-section 13.2 introduces policy that specifies how ARIN will go about > determining who a "legitimate" address holder is. It is similar to > current procedure with 13.2.2 and 13.2.3, which specify the use of IANA > and RIR records. It expands on the current procedures with 13.2.4, > allowing organizations to provide legal documentation of organizational > changes and/or the transfer of custody of a legacy address block. > > Sub-section 13.3 introduces policy enabling legitimate address holders > to request a very limited update to any Whois placeholders that might > exist for their legacy address block, so that the Whois will refer > queries to the authoritative directory service. It is expected that > ARIN will charge a fee for this update, but not require an ongoing > services agreement. ARIN is given the option of deleting placeholders > instead. > > Timetable for implementation: Immediately > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From packetgrrl at gmail.com Mon Feb 14 14:18:53 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Mon, 14 Feb 2011 12:18:53 -0700 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: I'd like to understand the argument as to why we should only include legacy space and not non-legacy space? Can someone explain it to me? I really thought this policy was to fill the gap in the IANA policy that only allows /8s to go from IANA to the RIRs and to be specific about what ARIN was going to do with any returned address space post IANA depletion. As shepherd for this proposal I am really trying to understand why it is specifically limited to legacy space? Thanks! On Mon, Feb 14, 2011 at 11:56 AM, Martin Hannigan wrote: > On Mon, Feb 14, 2011 at 1:44 PM, Chris Grundemann > > > > > I agree. I see no reason to distinguish in this case. IMHO, this > > policy should apply to ALL addresses returned to ARIN. > > > > > I disagree. If some on the AC want to modify this when the AC receives > it, that's up to them. I've made the edits that will resolve the > issues that I've identified in the most clear and concise way > possible. So far, I've heard only straw-men as to why to include any > other text. If I read something that is significant and that doesn't > seek to lop on complexity and unnecessary actions, I'll be happy to > reconsider. > > Best, > > -M< > _______________________________________________ > 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 BillD at cait.wustl.edu Mon Feb 14 14:28:54 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Mon, 14 Feb 2011 13:28:54 -0600 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> Message-ID: Did you mean to say you were opposed to proposal 133? bd > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith W. Hare > Sent: Monday, February 14, 2011 1:04 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: > No Volunteer Services on Behalf of Unaffiliated Address Blocks] > > I am unconvinced that the problem that proposal 113 is > attempting to correct is a real problem. It looks a lot like > another swipe at legacy resource holders for their perceived sins. > > I am opposed to proposal 113. > > Keith Hare > > ______________________________________________________________ > > Keith W. Hare JCC Consulting, Inc. > keith at jcc.com 600 Newark Road > Phone: 740-587-0157 P.O. Box 381 > Fax: 740-587-0163 Granville, Ohio 43023 > http://www.jcc.com USA > ______________________________________________________________ > > > > > -----Original Message----- > From: arin-announce-bounces at arin.net > [mailto:arin-announce-bounces at arin.net] On Behalf Of ARIN > Sent: Monday, February 14, 2011 11:50 AM > To: arin-announce at arin.net > Subject: [arin-announce] [Fwd: ARIN-prop-133: No Volunteer > Services on Behalf of Unaffiliated Address Blocks] > > The following is a new policy proposal that has been posted > to the ARIN Public Policy Mailing List for discussion on that list. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > -------- Original Message -------- > Subject: ARIN-prop-133: No Volunteer Services on Behalf > of Unaffiliated > Address Blocks > Date: Mon, 14 Feb 2011 11:49:22 -0500 > From: ARIN > To: arin-ppml at arin.net > > > > ARIN received the following policy proposal and is posting it > to the Public Policy Mailing List (PPML) in accordance with > the Policy Development Process. > > The ARIN Advisory Council (AC) will review the proposal at > their next regularly scheduled meeting (if the period before > the next regularly scheduled meeting is less than 10 days, > then the period may be extended to the subsequent regularly > scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the > PPML, particularly their support or non-support and the > reasoning behind their opinion. Such participation > contributes to a thorough vetting and provides important > guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 13 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.1. No Volunteer Services > > Except in the specific circumstances described by this > policy, ARIN will not provide any services for any > organization and/or address block. This includes without > limitation all directory services, reverse mapping services, > and future services that may be provided to the community. > > 13.1.1. Requested Services > > In the event that an organization explicitly requests > registry services from ARIN for one or more specified address > blocks, ARIN may provide the requested services, subsequent > to execution of a service contract, for those address blocks. > This includes without limitation all directory services, > reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN > under a valid RSA, as well as specific address blocks that > are included under a Legacy RSA with the legitimate validated > address holder, are deemed to have services requested for them. > > An organization requesting registry services for one or more > specified address blocks, that also holds additional address > blocks not specified in their request, is not obligated to > receive registry services for those additional address blocks > and those blocks are not deemed to have services requested for them. > > 13.1.2. Directory Placeholders > > For any address blocks, for which there are not fully > executed ARIN service contracts, ARIN will create generic > placeholder entries in the ARIN Whois directory. These > placeholder entries will not specify organizational details, > but will indicate that the entry represents a non-member resource. > > When applicable, each non-member resource placeholder will > include a reference and/or RWhois referral to the > authoritative directory service for that block, or the > directory service operated by the IANA, or by another > organization in the event that IANA has delegated their > directory service responsibility to that organization. This > does not apply to placeholders that represent an unassigned > and unallocated address block delegated to ARIN by the IANA. > > 13.2. Recognition of Legitimate Address Holders > > ARIN will use the following criteria in order to determine > whether an organization is the legitimate address holder for > a given IP address block. > > 13.2.1. Original Allocation Record > > The original allocation records, such as those documented in > RFC 1166 issued in July of 1990 or the InterNIC database > received by ARIN from Network Solutions in December of 1997, > will be used as dispositive proof, absent any contrary > documentation such as those specified in section 13.2.4 > below, in determining whether an organization is the > legitimate address holder. > > 13.2.2 IANA Records of Legitimate Address Holders > > In the event that the IANA has historical records, and/or > current records, showing the assignment or allocation of a > given IP address block to a specific organization, those > records will be used as proof, absent any contrary > documentation, in determining whether an organization is the > legitimate address holder. > > Further, in the event that this evidence conflicts with any > evidence from the original allocation records, or any > contrary documentation such as those specified in section > 13.2.4 below, the evidence from the original allocation > record will take precedence. > > 13.2.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for > the management of an address block to another organization, > including ARIN or any other RIR, and that organization has > historical and/or current records showing the assignment or > allocation of a given IP address block to a specific > organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any > evidence from the original allocation records, or any > contrary documentation such as those specified in section > 13.2.4 below, the evidence from the original allocation > record will take precedence. > > 13.2.4. Formal Records Clarifying the Chain of Custody > > In the event that formal records, such as public records or > other formal documents which can be authenticated or verified > to include legal, financial, and other organizational > documentation, are provided to ARIN by an organization > seeking recognition of their status as the legitimate address > holder, then ARIN will consider the impact of these records > as potentially updating any evidence that may exist. If > these records clearly document the assignment or allocation > of a given IP address block to a specific organization by > direct assignment, and/or organizational transitions such as > mergers, acquisitions, business unit restructuring, asset > transfers, name changes, and so forth, absent definitive > documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. > > 13.3. Permitted Updates to Directory Services for > Unaffiliated Address Blocks > > Any organization that legitimately holds an address block, as > defined by section 13.2 of this policy, may request the > removal or modification of existing directory placeholders > representing that address block. > > Valid requests for modification of placeholder entries are > limited to references and/or RWhois referrals to > authoritative directory services, such as directory services > operated by or on behalf of the IANA, another address > registry, or the address holder. In the event that such a > request is received, ARIN may choose to either remove the > placeholder entry or update it per the request. > > > Rationale: > > Policy Background: > > This policy attempts to clarify the relationship that ARIN > has with legacy address holders. > > Specifically, this policy recognizes that absent an agreement > such as the RSA or LRSA there is no formal relationship with > legacy address holders. At present, however, ARIN continues > to provide services to these organizations. This is done > without compensation and potentially in opposition to the > legacy address holders' wishes. As a result of this behavior > ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is > hindering the development of an open address market (driving > it "underground"), and is putting the operational stability > of the Internet at risk. As new services such as RPKI are > contemplated this situation becomes even more critical. > > This policy would require positive affirmation from any > legacy address holder that wishes to receive registry > services, moving to an "opt-in" > approach. In the event that a legacy address holder does not > opt-in to receive registry services, ARIN is limited to > providing no more than a pointer (such as a RWhois referral) > to an authoritative directory service for that holder's > legacy address blocks. Pointers to other providers of > directory services for addresses managed by those other > providers continue to be permitted. > > Policy Structure: > > This policy introduces a new section to the NRPM, numbered section 13. > Within this new section, there are three sub-sections. > > Sub-section 13.1 introduces policy that limits ARIN to > providing services on an opt-in basis. It does make clear in > 13.1.1 that services provided as part of a RSA or LRSA are > automatically considered opted-in. > With 13.1.2 it allows ARIN to create placeholders in the > Whois database for blocks managed by other RIRs as well as > for blocks managed (but unassigned/unallocated) by ARIN. > > Sub-section 13.2 introduces policy that specifies how ARIN > will go about determining who a "legitimate" address holder > is. It is similar to current procedure with 13.2.2 and > 13.2.3, which specify the use of IANA and RIR records. It > expands on the current procedures with 13.2.4, allowing > organizations to provide legal documentation of > organizational changes and/or the transfer of custody of a > legacy address block. > > Sub-section 13.3 introduces policy enabling legitimate > address holders to request a very limited update to any Whois > placeholders that might exist for their legacy address block, > so that the Whois will refer queries to the authoritative > directory service. It is expected that ARIN will charge a > fee for this update, but not require an ongoing services > agreement. ARIN is given the option of deleting placeholders instead. > > Timetable for implementation: Immediately > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact 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 Ed.Lewis at neustar.biz Mon Feb 14 14:33:37 2011 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 14 Feb 2011 14:33:37 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> Message-ID: I re-subscribed (after 2 1/2 years) just to say that I am opposed to this proposal. >ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address >Blocks > >Proposal Originator: Benson Schliesser > >Proposal Version: 1 > >Date: 13 February 2011 > >Proposal type: New I don't remember when, but my opposition to this the last time (I remember) this idea came around went something like this: 1. My membership in ARIN is funding my ability to find out who is sending me packets. (Assuming no forging of the header.) 2. My membership in ARIN is ensuring my number resources are uniquely assigned to me. 3. Having to register my contact information is not a privilege or a right but a requirement and a responsibility. 4. I consider it ARIN's responsibility to keep track of "who" is assigned "what" resources (even if that means federating responsibility to other RIRs and NIRs). Removing information about legitimate resource holders that are not paying ARIN (whether legitimately not paying or just behind on their bills) is detrimental to those that are paying. If the effort is to entice legacy space holders into joining ARIN, don't try to penalize them. Give them a positive incentive. At 13:17 -0600 2/14/11, Benson Schliesser wrote: >Having said that, I can understand that some legacy address holders will >want to continue receiving services from ARIN, including Whois and >in-addr DNS. The LRSA is one way to facilitate that without an ambiguous >relationship. We may also want to propose an alternative mechanism, >assuming that the LRSA is unappealing, but I have not included that in >prop 133 at this time. The faulty logic here is in identifying who is "receiving services from ARIN." The relying parties that hit the whois and DNS servers are not only the holders of number resource but anyone that sends a packet in the Internet. The vast majority of these people do not have any number resources registered to them. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From Keith at jcc.com Mon Feb 14 14:37:01 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 14 Feb 2011 14:37:01 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> Message-ID: Yes, I meant Proposal 133 rather than 113. -----Original Message----- From: Bill Darte [mailto:BillD at cait.wustl.edu] Sent: Monday, February 14, 2011 2:29 PM To: Keith W. Hare; arin-ppml at arin.net Subject: RE: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] Did you mean to say you were opposed to proposal 133? bd > -----Original Message----- > From: arin-ppml-bounces at arin.net > [mailto:arin-ppml-bounces at arin.net] On Behalf Of Keith W. Hare > Sent: Monday, February 14, 2011 1:04 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: > No Volunteer Services on Behalf of Unaffiliated Address Blocks] > > I am unconvinced that the problem that proposal 113 is > attempting to correct is a real problem. It looks a lot like > another swipe at legacy resource holders for their perceived sins. > > I am opposed to proposal 113. > > Keith Hare > > ______________________________________________________________ > > Keith W. Hare JCC Consulting, Inc. > keith at jcc.com 600 Newark Road > Phone: 740-587-0157 P.O. Box 381 > Fax: 740-587-0163 Granville, Ohio 43023 > http://www.jcc.com USA > ______________________________________________________________ > > > > > -----Original Message----- > From: arin-announce-bounces at arin.net > [mailto:arin-announce-bounces at arin.net] On Behalf Of ARIN > Sent: Monday, February 14, 2011 11:50 AM > To: arin-announce at arin.net > Subject: [arin-announce] [Fwd: ARIN-prop-133: No Volunteer > Services on Behalf of Unaffiliated Address Blocks] > > The following is a new policy proposal that has been posted > to the ARIN Public Policy Mailing List for discussion on that list. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > -------- Original Message -------- > Subject: ARIN-prop-133: No Volunteer Services on Behalf > of Unaffiliated > Address Blocks > Date: Mon, 14 Feb 2011 11:49:22 -0500 > From: ARIN > To: arin-ppml at arin.net > > > > ARIN received the following policy proposal and is posting it > to the Public Policy Mailing List (PPML) in accordance with > the Policy Development Process. > > The ARIN Advisory Council (AC) will review the proposal at > their next regularly scheduled meeting (if the period before > the next regularly scheduled meeting is less than 10 days, > then the period may be extended to the subsequent regularly > scheduled meeting). The AC will decide how to utilize the > proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the > PPML, particularly their support or non-support and the > reasoning behind their opinion. Such participation > contributes to a thorough vetting and provides important > guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 13 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.1. No Volunteer Services > > Except in the specific circumstances described by this > policy, ARIN will not provide any services for any > organization and/or address block. This includes without > limitation all directory services, reverse mapping services, > and future services that may be provided to the community. > > 13.1.1. Requested Services > > In the event that an organization explicitly requests > registry services from ARIN for one or more specified address > blocks, ARIN may provide the requested services, subsequent > to execution of a service contract, for those address blocks. > This includes without limitation all directory services, > reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN > under a valid RSA, as well as specific address blocks that > are included under a Legacy RSA with the legitimate validated > address holder, are deemed to have services requested for them. > > An organization requesting registry services for one or more > specified address blocks, that also holds additional address > blocks not specified in their request, is not obligated to > receive registry services for those additional address blocks > and those blocks are not deemed to have services requested for them. > > 13.1.2. Directory Placeholders > > For any address blocks, for which there are not fully > executed ARIN service contracts, ARIN will create generic > placeholder entries in the ARIN Whois directory. These > placeholder entries will not specify organizational details, > but will indicate that the entry represents a non-member resource. > > When applicable, each non-member resource placeholder will > include a reference and/or RWhois referral to the > authoritative directory service for that block, or the > directory service operated by the IANA, or by another > organization in the event that IANA has delegated their > directory service responsibility to that organization. This > does not apply to placeholders that represent an unassigned > and unallocated address block delegated to ARIN by the IANA. > > 13.2. Recognition of Legitimate Address Holders > > ARIN will use the following criteria in order to determine > whether an organization is the legitimate address holder for > a given IP address block. > > 13.2.1. Original Allocation Record > > The original allocation records, such as those documented in > RFC 1166 issued in July of 1990 or the InterNIC database > received by ARIN from Network Solutions in December of 1997, > will be used as dispositive proof, absent any contrary > documentation such as those specified in section 13.2.4 > below, in determining whether an organization is the > legitimate address holder. > > 13.2.2 IANA Records of Legitimate Address Holders > > In the event that the IANA has historical records, and/or > current records, showing the assignment or allocation of a > given IP address block to a specific organization, those > records will be used as proof, absent any contrary > documentation, in determining whether an organization is the > legitimate address holder. > > Further, in the event that this evidence conflicts with any > evidence from the original allocation records, or any > contrary documentation such as those specified in section > 13.2.4 below, the evidence from the original allocation > record will take precedence. > > 13.2.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for > the management of an address block to another organization, > including ARIN or any other RIR, and that organization has > historical and/or current records showing the assignment or > allocation of a given IP address block to a specific > organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any > evidence from the original allocation records, or any > contrary documentation such as those specified in section > 13.2.4 below, the evidence from the original allocation > record will take precedence. > > 13.2.4. Formal Records Clarifying the Chain of Custody > > In the event that formal records, such as public records or > other formal documents which can be authenticated or verified > to include legal, financial, and other organizational > documentation, are provided to ARIN by an organization > seeking recognition of their status as the legitimate address > holder, then ARIN will consider the impact of these records > as potentially updating any evidence that may exist. If > these records clearly document the assignment or allocation > of a given IP address block to a specific organization by > direct assignment, and/or organizational transitions such as > mergers, acquisitions, business unit restructuring, asset > transfers, name changes, and so forth, absent definitive > documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. > > 13.3. Permitted Updates to Directory Services for > Unaffiliated Address Blocks > > Any organization that legitimately holds an address block, as > defined by section 13.2 of this policy, may request the > removal or modification of existing directory placeholders > representing that address block. > > Valid requests for modification of placeholder entries are > limited to references and/or RWhois referrals to > authoritative directory services, such as directory services > operated by or on behalf of the IANA, another address > registry, or the address holder. In the event that such a > request is received, ARIN may choose to either remove the > placeholder entry or update it per the request. > > > Rationale: > > Policy Background: > > This policy attempts to clarify the relationship that ARIN > has with legacy address holders. > > Specifically, this policy recognizes that absent an agreement > such as the RSA or LRSA there is no formal relationship with > legacy address holders. At present, however, ARIN continues > to provide services to these organizations. This is done > without compensation and potentially in opposition to the > legacy address holders' wishes. As a result of this behavior > ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is > hindering the development of an open address market (driving > it "underground"), and is putting the operational stability > of the Internet at risk. As new services such as RPKI are > contemplated this situation becomes even more critical. > > This policy would require positive affirmation from any > legacy address holder that wishes to receive registry > services, moving to an "opt-in" > approach. In the event that a legacy address holder does not > opt-in to receive registry services, ARIN is limited to > providing no more than a pointer (such as a RWhois referral) > to an authoritative directory service for that holder's > legacy address blocks. Pointers to other providers of > directory services for addresses managed by those other > providers continue to be permitted. > > Policy Structure: > > This policy introduces a new section to the NRPM, numbered section 13. > Within this new section, there are three sub-sections. > > Sub-section 13.1 introduces policy that limits ARIN to > providing services on an opt-in basis. It does make clear in > 13.1.1 that services provided as part of a RSA or LRSA are > automatically considered opted-in. > With 13.1.2 it allows ARIN to create placeholders in the > Whois database for blocks managed by other RIRs as well as > for blocks managed (but unassigned/unallocated) by ARIN. > > Sub-section 13.2 introduces policy that specifies how ARIN > will go about determining who a "legitimate" address holder > is. It is similar to current procedure with 13.2.2 and > 13.2.3, which specify the use of IANA and RIR records. It > expands on the current procedures with 13.2.4, allowing > organizations to provide legal documentation of > organizational changes and/or the transfer of custody of a > legacy address block. > > Sub-section 13.3 introduces policy enabling legitimate > address holders to request a very limited update to any Whois > placeholders that might exist for their legacy address block, > so that the Whois will refer queries to the authoritative > directory service. It is expected that ARIN will charge a > fee for this update, but not require an ongoing services > agreement. ARIN is given the option of deleting placeholders instead. > > Timetable for implementation: Immediately > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact 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 JOHN at egh.com Mon Feb 14 15:08:11 2011 From: JOHN at egh.com (John Santos) Date: Mon, 14 Feb 2011 15:08:11 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D595D12.4000602@arin.net> Message-ID: <1110214150225.31932B-100000@Ives.egh.com> On Mon, 14 Feb 2011, ARIN wrote: > 13.1. No Volunteer Services > > Except in the specific circumstances described by this policy, ARIN will > not provide any services for any organization and/or address block. This > includes without limitation all directory services, reverse mapping > services, and future services that may be provided to the community. > > 13.1.1. Requested Services > > In the event that an organization explicitly requests registry services > from ARIN for one or more specified address blocks, ARIN may provide the > requested services, subsequent to execution of a service contract, for > those address blocks. This includes without limitation all directory > services, reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN under a valid > RSA, as well as specific address blocks that are included under a Legacy > RSA with the legitimate validated address holder, are deemed to have > services requested for them. > > An organization requesting registry services for one or more specified > address blocks, that also holds additional address blocks not specified > in their request, is not obligated to receive registry services for > those additional address blocks and those blocks are not deemed to have > services requested for them. > 1) This is an opt-in, not an opt-out policy. You might discover that lots of legacy holders will get very pissed off if their reverse DNS suddenly goes away. I know I would. 2) There didn't seem to be any provision for notifying legacy holders of this change in policy. I certainly wouldn't know about it if I didn't subscribe to this mailing list. 3) It isn't clear if legacy holders *MUST* sign an LRSA (or move to a regular RSA) to retain Whois, RDNS, etc. or not. 4) What is the point of this? I'm against. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Mon Feb 14 15:23:12 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Feb 2011 12:23:12 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Legacy and other addresses returned should be treated the same. Once an address is returned to ARIN, it is no longer a legacy address. This policy does not make sense so long as it singles out legacy addresses. Owen On Feb 14, 2011, at 6:55 AM, Martin Hannigan wrote: > On Wed, Feb 9, 2011 at 6:22 PM, Chris Grundemann wrote: > > [ snip ] > >> Marty - Can you shed some light onto why this is (and needs to be) >> limited to legacy space? I don't see a need for the distinction but >> could certainly be missing something. > > Chris, > > In the past, we've heard numerous ARIN folks talking about "clear > instructions from the community". > > Right now, we have multiple global policies circulating trying to > determine what should be done with ipv4 legacy addresses in the ARIN > region. > > ARIN has always treated IPv4 legacy addresses different (LRSA, etc) > and our discussions make distinctions between "RSA" and "legacy > holders". > > There is likely some minor, but necessary policy required to make > whatever will transpire with legacy addresses acceptable and workable > to all. > > This would be a clear instruction that would leave no ambiguity with > respect to what the community wants ARIN to do with legacy addresses. > This proposal leaves noone wondering what will happen to addresses > returned to ARIN and it codifies the requirement. > > Is there a problem with resources already in ARIN's possession being > returned to "inventory"? If there is, in the interest of clarity, I > think it would be better to submit an ASCP item or propose something > specific IMHO. > > I've softened this enough to hopefully clarify it's intent. As a side > benefit, it should also encourage people writing global policies to > work together. > > Best, > > -M< > > > Best, > > -M< > _______________________________________________ > 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 bensons at queuefull.net Mon Feb 14 15:28:45 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 14 Feb 2011 14:28:45 -0600 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> Message-ID: <53916256-7A2A-4B2C-9202-ECB85EC82052@queuefull.net> Hi, Edward. Thanks for your note - my intent in submitting policy proposal 133 was to encourage this very discussion. On Feb 14, 2011, at 1:33 PM, Edward Lewis wrote: > Removing information about legitimate resource holders that are not paying ARIN (whether legitimately not paying or just behind on their bills) is detrimental to those that are paying. > > If the effort is to entice legacy space holders into joining ARIN, don't try to penalize them. Give them a positive incentive. > ... > The faulty logic here is in identifying who is "receiving services from ARIN." The relying parties that hit the whois and DNS servers are not only the holders of number resource but anyone that sends a packet in the Internet. The vast majority of these people do not have any number resources registered to them. For what it's worth, I personally agree with the perspective quoted above. But I don't think it gets at the heart of the issue exposed by prop 133. The question we must ask ourselves is whether ARIN is acting appropriately by listing legacy resources *and extending restrictive policy over the update of those listings*. One way to look at this question is, as you have done, to frame Whois as a service intended to benefit the broader Internet. If we think in these terms, then the impetus is on accuracy of the data. For some of that data, the "authority" to declare accuracy rests with ARIN or another RIR. However, for the legacy Whois data there isn't a clearly delegated "authority". Who is allowed to request updates, and under what circumstances would ARIN be correct to deny them? To give you an example: current policy is a bit like your neighbors deciding who owns your house, and publishing a list of neighborhood homeowners, without your consent. As long as you agree with their published list there is no reason for you to worry. But if they ever decided to "reclaim" your house and/or refuse to acknowledge a "transfer" of your house to a new owner, well, that would be a different story. You might not like the comparison to real property, which we can debate. So take it further, if you want, and imagine this same kind of scenario applied to other forms of property, intellectual property, music rights, etc, and the issues become more complicated (and potential liability becomes more expensive). Another way to look at this question, as I have done with prop 133, is to frame Whois as a service to benefit the address holders listed within it. If we think in these terms, then it becomes clear that "authority" is delegated by the address holder when they request service. There should be no ambiguity about whether ARIN is acting appropriately, because ARIN has a legally valid policy for identifying legitimate address holders, accepting a request to provide services, etc. Now, getting back to my first comment, I agree that there are open issues with prop 133. For instance, who provides in-addr and Whois for legacy holders that don't choose to sign the LRSA? One alternative is competitive post-allocation services such as those mentioned at http://www.circleid.com/posts/competition_to_regional_internet_registries_rir_for_post_allocation_service/ and again this past weekend at http://blog.internetgovernance.org/blog/_archives/2011/2/12/4748945.html. Another alternative might be for ARIN to enable transfers without requiring LRSA. But any approach requires a definition of "legitimate address holder" in order to answer the fundamental question of "authority". Cheers, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bensons at queuefull.net Mon Feb 14 15:32:34 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 14 Feb 2011 14:32:34 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Message-ID: On Feb 14, 2011, at 2:23 PM, Owen DeLong wrote: > Legacy and other addresses returned should be treated the same. > > Once an address is returned to ARIN, it is no longer a legacy address. > > This policy does not make sense so long as it singles out legacy addresses. I agree with Owen on this. ARIN should only accept returned legacy addresses from holders in the ARIN region. But, once accepted, that address space has been effectively transferred to ARIN. It is up to ARIN policy to decide whether to return that block to IANA, reallocate to new requests, etc. And there are no technical reasons to treat address blocks differently, as far as I'm aware. Cheers, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bensons at queuefull.net Mon Feb 14 15:54:00 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 14 Feb 2011 14:54:00 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <1110214150225.31932B-100000@Ives.egh.com> References: <1110214150225.31932B-100000@Ives.egh.com> Message-ID: <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Hi, John. On Feb 14, 2011, at 2:08 PM, John Santos wrote: > 1) This is an opt-in, not an opt-out policy. You might discover that > lots of legacy holders will get very pissed off if their reverse DNS > suddenly goes away. I know I would. > > 2) There didn't seem to be any provision for notifying legacy holders > of this change in policy. I certainly wouldn't know about it if I > didn't subscribe to this mailing list. These are valid concerns. I think it is a good idea to include some additional text, for instance instructing ARIN to contact each organization. I'm not sure I grasp how difficult this would be. I'm also not sure whether this would be policy, meta-policy, rationale, etc. Comments on how specifically to deal with this concern in the proposal would be appreciated. > 3) It isn't clear if legacy holders *MUST* sign an LRSA (or move to a > regular RSA) to retain Whois, RDNS, etc. or not. Hopefully prop 133 is clear that a LRSA will be a valid "request" for services. But it doesn't make any limitations on what other kinds of request might be valid, i.e. it doesn't specify that the legacy holder must sign a LRSA. If ARIN policy permits something other than the LRSA, as a request for services by legacy address holders, that would not be prohibited by prop 133. > 4) What is the point of this? The point of submitting the proposal is to encourage discussion of how ARIN should treat legacy address holders. The point of the policy proposal itself is to make it clear that ARIN won't exercise authority (e.g. policy enforcement via the Whois) over anybody that hasn't requested it. I believe that this is more legally viable than the current approach. One additional comment, to clarify a misconception: The point of this policy is not to "punish" legacy address holders that don't sign the LRSA. It might have that effect for some, but I'm not sure how to avoid it while developing policy that defines the relationship between legacy holders and ARIN. If anybody has suggestions for improving the policy text in this regard, I'm happy to discuss it. Cheers, -Benson From owen at delong.com Mon Feb 14 15:58:28 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Feb 2011 12:58:28 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: <0D09DC79-A916-41D4-B12D-5D0D0AD9044A@delong.com> On Feb 14, 2011, at 10:56 AM, Martin Hannigan wrote: > On Mon, Feb 14, 2011 at 1:44 PM, Chris Grundemann > >> >> I agree. I see no reason to distinguish in this case. IMHO, this >> policy should apply to ALL addresses returned to ARIN. >> > > > I disagree. If some on the AC want to modify this when the AC receives > it, that's up to them. I've made the edits that will resolve the > issues that I've identified in the most clear and concise way > possible. So far, I've heard only straw-men as to why to include any > other text. If I read something that is significant and that doesn't > seek to lop on complexity and unnecessary actions, I'll be happy to > reconsider. > I don't think we are suggesting that you add any other text, so, your statement about straw-men is inapplicable. We are suggesting that you remove a single word. I will make the motion for the AC to make the edit on Thursday if I have to, but, usually we try to work with the author first. Owen From hannigan at gmail.com Mon Feb 14 16:03:12 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Feb 2011 16:03:12 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Message-ID: On Mon, Feb 14, 2011 at 3:32 PM, Benson Schliesser wrote: > [ snip ] > Legacy and other addresses returned should be treated the same. > > Once an address is returned to ARIN, it is no longer a legacy address. > > This policy does not make sense so long as it singles out legacy addresses. > > I agree with Owen on this. > ARIN should only accept returned legacy addresses from holders in the ARIN > region. ?But, once accepted, that address space has been effectively > transferred to ARIN. Here's what the text actually says: "5.1 Returned Legacy Addresses Legacy IPv4 addresses returned to or recovered by ARIN will be made available for registration and distribution in the ARIN region within thirty days of their receipt." There's no argument here that once an address is added to ARIN's inventory it's a done deal. The proposal doesn't seek to do otherwise nor does the language imply that it would. >It is up to ARIN policy to decide whether to return > that block to IANA, reallocate to new requests, etc. ?And there are no > technical reasons to treat address blocks differently, as far as I'm aware. All that this proposal does is codify the instruction to return these addresses to ARIN inventory and use them. The current situation is ambiguous and open to interpretation. This has nothing to do with the IANA at all. In fact, in the absence of a global policy, this simply makes the instruction "use the addresses". With regards to accepting legacy addresses from entities "only" in the ARIN region, I think that's a fair point and will put it on the list of final modifications. Best, -M< From Keith at jcc.com Mon Feb 14 16:10:48 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 14 Feb 2011 16:10:48 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <53916256-7A2A-4B2C-9202-ECB85EC82052@queuefull.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <53916256-7A2A-4B2C-9202-ECB85EC82052@queuefull.net> Message-ID: Benson, The current ARIN approach is a lot more like the allocation of house numbers, not a listing of who owns your house. The fact that my house has a particular house number is for the convenience of those who are trying to find me, not so much for me. >From your discussion and links, it sounds like after fixing the "problem" of ARIN's control of legacy resource holders, you have some thought of creating an alternative service that somehow is more beneficial to legacy resource holders than ARIN is. What benefits would an alternative service provide that ARIN does not currently provide? I still fail to see compelling reason and so am still opposed to Proposition 133 (I got the number right this time. I think.) Keith From: Benson Schliesser [mailto:bensons at queuefull.net] Sent: Monday, February 14, 2011 3:29 PM To: Edward Lewis Cc: Keith W. Hare; arin-ppml at arin.net Subject: Re: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] Hi, Edward. Thanks for your note - my intent in submitting policy proposal 133 was to encourage this very discussion. On Feb 14, 2011, at 1:33 PM, Edward Lewis wrote: Removing information about legitimate resource holders that are not paying ARIN (whether legitimately not paying or just behind on their bills) is detrimental to those that are paying. If the effort is to entice legacy space holders into joining ARIN, don't try to penalize them. Give them a positive incentive. ... The faulty logic here is in identifying who is "receiving services from ARIN." The relying parties that hit the whois and DNS servers are not only the holders of number resource but anyone that sends a packet in the Internet. The vast majority of these people do not have any number resources registered to them. For what it's worth, I personally agree with the perspective quoted above. But I don't think it gets at the heart of the issue exposed by prop 133. The question we must ask ourselves is whether ARIN is acting appropriately by listing legacy resources *and extending restrictive policy over the update of those listings*. One way to look at this question is, as you have done, to frame Whois as a service intended to benefit the broader Internet. If we think in these terms, then the impetus is on accuracy of the data. For some of that data, the "authority" to declare accuracy rests with ARIN or another RIR. However, for the legacy Whois data there isn't a clearly delegated "authority". Who is allowed to request updates, and under what circumstances would ARIN be correct to deny them? To give you an example: current policy is a bit like your neighbors deciding who owns your house, and publishing a list of neighborhood homeowners, without your consent. As long as you agree with their published list there is no reason for you to worry. But if they ever decided to "reclaim" your house and/or refuse to acknowledge a "transfer" of your house to a new owner, well, that would be a different story. You might not like the comparison to real property, which we can debate. So take it further, if you want, and imagine this same kind of scenario applied to other forms of property, intellectual property, music rights, etc, and the issues become more complicated (and potential liability becomes more expensive). Another way to look at this question, as I have done with prop 133, is to frame Whois as a service to benefit the address holders listed within it. If we think in these terms, then it becomes clear that "authority" is delegated by the address holder when they request service. There should be no ambiguity about whether ARIN is acting appropriately, because ARIN has a legally valid policy for identifying legitimate address holders, accepting a request to provide services, etc. Now, getting back to my first comment, I agree that there are open issues with prop 133. For instance, who provides in-addr and Whois for legacy holders that don't choose to sign the LRSA? One alternative is competitive post-allocation services such as those mentioned at http://www.circleid.com/posts/competition_to_regional_internet_registries_rir_for_post_allocation_service/ and again this past weekend at http://blog.internetgovernance.org/blog/_archives/2011/2/12/4748945.html. Another alternative might be for ARIN to enable transfers without requiring LRSA. But any approach requires a definition of "legitimate address holder" in order to answer the fundamental question of "authority". Cheers, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffrey.lyon at blacklotus.net Mon Feb 14 16:10:04 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:10:04 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: On Mon, Feb 14, 2011 at 3:54 PM, Benson Schliesser wrote: > Hi, John. > > On Feb 14, 2011, at 2:08 PM, John Santos wrote: > >> 1) This is an opt-in, not an opt-out policy. ?You might discover that >> lots of legacy holders will get very pissed off if their reverse DNS >> suddenly goes away. ?I know I would. >> >> 2) There didn't seem to be any provision for notifying legacy holders >> of this change in policy. ?I certainly wouldn't know about it if I >> didn't subscribe to this mailing list. > > These are valid concerns. ?I think it is a good idea to include some additional text, for instance instructing ARIN to contact each organization. ?I'm not sure I grasp how difficult this would be. ?I'm also not sure whether this would be policy, meta-policy, rationale, etc. Comments on how specifically to deal with this concern in the proposal would be appreciated. > >> 3) It isn't clear if legacy holders *MUST* sign an LRSA (or move to a >> regular RSA) to retain Whois, RDNS, etc. or not. > > Hopefully prop 133 is clear that a LRSA will be a valid "request" for services. ?But it doesn't make any limitations on what other kinds of request might be valid, i.e. it doesn't specify that the legacy holder must sign a LRSA. ?If ARIN policy permits something other than the LRSA, as a request for services by legacy address holders, that would not be prohibited by prop 133. > >> 4) What is the point of this? > > The point of submitting the proposal is to encourage discussion of how ARIN should treat legacy address holders. ?The point of the policy proposal itself is to make it clear that ARIN won't exercise authority (e.g. policy enforcement via the Whois) over anybody that hasn't requested it. ?I believe that this is more legally viable than the current approach. > > One additional comment, to clarify a misconception: The point of this policy is not to "punish" legacy address holders that don't sign the LRSA. ?It might have that effect for some, but I'm not sure how to avoid it while developing policy that defines the relationship between legacy holders and ARIN. ?If anybody has suggestions for improving the policy text in this regard, I'm happy to discuss it. > > Cheers, > -Benson > > > _______________________________________________ > 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. > Section 13.1 seems to be poorly written. "Except in the specific circumstances described by this policy, ARIN will not provide any services for any organization and/or address block." If ARIN didn't provide any services to any organization I would probably have to stop paying my annual dues. ;) I agree with this proposal on it's own merits and disagree that the intent is to vilify legacy address holders. As a matter of transparency, it would be decent of anyone opposing this and similar proposals to state any interest they may have in maintaining the status quo for legacy space. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Mon Feb 14 16:13:43 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:13:43 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Message-ID: On Mon, Feb 14, 2011 at 3:23 PM, Owen DeLong wrote: > Legacy and other addresses returned should be treated the same. > > Once an address is returned to ARIN, it is no longer a legacy address. > > This policy does not make sense so long as it singles out legacy addresses. > > Owen > > On Feb 14, 2011, at 6:55 AM, Martin Hannigan wrote: > >> On Wed, Feb 9, 2011 at 6:22 PM, Chris Grundemann wrote: >> >> [ snip ] >> >>> Marty - Can you shed some light onto why this is (and needs to be) >>> limited to legacy space? I don't see a need for the distinction but >>> could certainly be missing something. >> >> Chris, >> >> In the past, we've heard numerous ARIN folks talking about "clear >> instructions from the community". >> >> Right now, we have multiple global policies circulating trying to >> determine what should be done with ipv4 legacy addresses in the ARIN >> region. >> >> ARIN has always treated IPv4 legacy addresses different (LRSA, etc) >> and our discussions make distinctions between "RSA" and "legacy >> holders". >> >> There is likely some minor, but necessary policy required to make >> whatever will transpire with legacy addresses acceptable and workable >> to all. >> >> This would be a clear instruction that would leave no ambiguity with >> respect to what the community wants ARIN to do with legacy addresses. >> This proposal leaves noone wondering what will happen to addresses >> returned to ARIN and it codifies the requirement. >> >> Is there a problem with resources already in ARIN's possession being >> returned to "inventory"? If there is, in the interest of clarity, I >> think it would be better to submit an ASCP item or propose something >> specific IMHO. >> >> I've softened this enough to hopefully clarify it's intent. As a side >> benefit, it should also encourage people writing global policies to >> work together. >> >> Best, >> >> -M< >> >> >> Best, >> >> -M< >> _______________________________________________ >> 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. > I also agree with Owen on this point. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From matthew at matthew.at Mon Feb 14 16:15:50 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 14 Feb 2011 13:15:50 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D595D12.4000602@arin.net> References: <4D595D12.4000602@arin.net> Message-ID: <4D599B86.10707@matthew.at> Opposed. Making Whois information about legacy blocks invisible removes the ability for individuals and organizations to continue to "self-police" use of this space. As an example, if I am an ISP with a customer who claims to hold a legacy block and who wants it routed, where do I verify that if not the whois database? It similarly interferes with any future transfer market by making it impossible to do even the most rudimentary check on the seller's claims. Matthew Kaufman From jeffrey.lyon at blacklotus.net Mon Feb 14 16:18:42 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:18:42 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D599B86.10707@matthew.at> References: <4D595D12.4000602@arin.net> <4D599B86.10707@matthew.at> Message-ID: On Mon, Feb 14, 2011 at 4:15 PM, Matthew Kaufman wrote: > Opposed. Making Whois information about legacy blocks invisible removes the > ability for individuals and organizations to continue to "self-police" use > of this space. As an example, if I am an ISP with a customer who claims to > hold a legacy block and who wants it routed, where do I verify that if not > the whois database? It similarly interferes with any future transfer market > by making it impossible to do even the most rudimentary check on the > seller's claims. > > 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. > ARIN would provide referral WHOIS. Couldn't you just use this information? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Mon Feb 14 16:19:18 2011 From: jcurran at arin.net (John Curran) Date: Mon, 14 Feb 2011 21:19:18 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> References: <4D595D12.4000602@arin.net> <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> Message-ID: <784247EC-6BE8-4764-8D7D-49C4E3C9ADB2@arin.net> On Feb 14, 2011, at 1:30 PM, Benson Schliesser wrote: > > I think you understand the effect of the text, yes. But my answer is a bit more nuanced: > > Policy proposal 133, in section 13.2, would have ARIN recognize assignments that take place beyond ARIN's scope. In other words, the act of ARIN recognizing the new legitimate address holder is not what creates the assignment; the assignment would have already taken place and ARIN would simply be recognizing that fact. Interesting conjecture. To the extent that policies of the ICANN and/or IANA were preclude such transfers, do you also propose that these assignments take place beyond their scope? Thanks! /John John Curran President and CEO ARIN From Ed.Lewis at neustar.biz Mon Feb 14 16:19:15 2011 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Mon, 14 Feb 2011 16:19:15 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <53916256-7A2A-4B2C-9202-ECB85EC82052@queuefull.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <53916256-7A2A-4B2C-9202-ECB85EC82052@queuefull.net> Message-ID: At 14:28 -0600 2/14/11, Benson Schliesser wrote: >For what it's worth, I personally agree with the perspective quoted above. >But I don't think it gets at the heart of the issue exposed by prop 133. >The question we must ask ourselves is whether ARIN is acting appropriately >by listing legacy resources *and extending restrictive policy over the >update of those listings*. It's been a while, so I don't know what the reference to "restrictive policy" is. The way I think of this is, if the legacy holders aren't going to participate in ARIN, then you can't force them. If we decide to mess around with the listings or even prevent the legacy holder from updating them, we are only hurting our paying selves. If my neighbor's house was built before my subdivision and he isn't gong to pay the homeowner's ransom to the community, I still want to know what his emergency phone number is. If his house is about to catch on fire and embers will blow towards my shed, I need to call him. >One way to look at this question is, as you have done, to frame Whois as >a service intended to benefit the broader Internet. If we think in >these terms, then the impetus is on accuracy of the data. For some of >that data, the "authority" to declare accuracy rests with ARIN or another RIR. >However, for the legacy Whois data there isn't a clearly delegated >"authority". Who is allowed to request updates, and under what >circumstances would ARIN be correct to deny them? I don't think I want to pay ARIN to go so far as ensuring the data is up todate and accurate. That's a tall order and would be quite expensive. (I used to work at ARIN and for other domain name registries.) Accuracy is nice, but even an stale hint is beneficial, it might lead to the latest information. Besides, I only need to contact my reclusive neighbor when there's a real need to do so. >To give you an example: current policy is a bit like your neighbors >deciding who owns your house, and publishing a list of neighborhood >homeowners, without your consent. As long as you agree with their >published list there is no reason for you to worry. But if they ever >decided to "reclaim" your house and/or refuse to acknowledge a "transfer" >of your house to a new owner, well, that would be a different story. >You might not like the comparison to real property, which we can debate. >So take it further, if you want, and imagine this same kind of scenario >applied to other forms of property, intellectual property, music rights, >etc, and the issues become more complicated (and potential liability >becomes more expensive). The only problem with analogies is that there are limits in their applicability. (When the lines get crossed, discussion gets out of hand.) I was really active in the RIR arena from 2002 to 2008. Admittedly, that's a long time ago now, but "taking away" resources wasn't discussed. When it comes to transfers though I see the dilemma. If my neighbor sells his house and tries to give us the new number of the new owner, we balk saying "no one owns thie land, it's all part of a cooperative." At this point we could stand on principle and see his entry in our ledger go stale or recognize he's not in the tribe and just record the new entry. (You can guess what I'd opt for - the latter, that is.) >Another way to look at this question, as I have done with prop 133, is >to frame Whois as a service to benefit the address holders listed within it. >If we think in these terms, then it becomes clear that "authority" is >delegated by the address holder when they request service. There should be >no ambiguity about whether ARIN is acting appropriately, because ARIN has >a legally valid policy for identifying legitimate address holders, accepting >a request to provide services, etc. I don't think that WhoIs is a benefit to the holders listed in it. The benefit of the registry is the protection of uniqueness. This is why the central database is the most important thing in the ARIN world. Like DNS, WhoIs is just a "report" run from the database for the benefit of relying parties. >Now, getting back to my first comment, I agree that there are open issues >with prop 133. For instance, who provides in-addr and Whois for legacy >holders that don't choose to sign the LRSA? One alternative is >competitive post-allocation services such as those mentioned at > >http://www.circleid.com/posts/competition_to_regional_internet_registries_rir_for_post_allocation_service/ >and again this past weekend at > >http://blog.internetgovernance.org/blog/_archives/2011/2/12/4748945.html. > >Another alternative might be for ARIN to enable transfers without requiring >LRSA. But any approach requires a definition of "legitimate address >holder" in order to answer the fundamental question of "authority". I think tying WhoIs and DNS to "determining the legitimate" holder of a number resource to be too high of a bar. I don't care if the guy next to me is a legit owner or a squatter when he has the ability to get out the fire extinguisher and stop the fire from harming my property. Oops, "property." The bottom line is - DNS and WhoIs hold information that is for the benefit of general users of the Internet, including those funding ARIN. Degrading the quality of information about non-ARIN (and non-RIR) allocated resources in the DNS and WhoIs is just shooting the membership in the foot. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Mon Feb 14 16:21:39 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 14 Feb 2011 13:21:39 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <4D595D12.4000602@arin.net> <4D599B86.10707@matthew.at> Message-ID: <4D599CE3.5080602@matthew.at> On 2/14/2011 1:18 PM, Jeffrey Lyon wrote: > On Mon, Feb 14, 2011 at 4:15 PM, Matthew Kaufman wrote: >> Opposed. Making Whois information about legacy blocks invisible removes the >> ability for individuals and organizations to continue to "self-police" use >> of this space. As an example, if I am an ISP with a customer who claims to >> hold a legacy block and who wants it routed, where do I verify that if not >> the whois database? It similarly interferes with any future transfer market >> by making it impossible to do even the most rudimentary check on the >> seller's claims. >> >> 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. >> > ARIN would provide referral WHOIS. Couldn't you just use this information? > Referral to what? Someone who's had a legacy class C since 1992 comes to you and says "hi, I moved and am now your customer, I'd like you to route this block to me". Who has a listing for that address if this policy takes effect? Note that "tell the customer to go sign an LRSA first" isn't an acceptable answer either, as many holders have many reasons (some no doubt even legitimate) for not signing the LRSA. Matthew Kaufman From hannigan at gmail.com Mon Feb 14 16:28:01 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Feb 2011 16:28:01 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Message-ID: On Mon, Feb 14, 2011 at 4:13 PM, Jeffrey Lyon wrote: [ snip] > > I also agree with Owen on this point. > You're supporting straw man arguments. Do you have anything more substantial? Best, -M< From jeffrey.lyon at blacklotus.net Mon Feb 14 16:32:11 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:32:11 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D599CE3.5080602@matthew.at> References: <4D595D12.4000602@arin.net> <4D599B86.10707@matthew.at> <4D599CE3.5080602@matthew.at> Message-ID: On Mon, Feb 14, 2011 at 4:21 PM, Matthew Kaufman wrote: > On 2/14/2011 1:18 PM, Jeffrey Lyon wrote: >> >> On Mon, Feb 14, 2011 at 4:15 PM, Matthew Kaufman >> ?wrote: >>> >>> Opposed. Making Whois information about legacy blocks invisible removes >>> the >>> ability for individuals and organizations to continue to "self-police" >>> use >>> of this space. As an example, if I am an ISP with a customer who claims >>> to >>> hold a legacy block and who wants it routed, where do I verify that if >>> not >>> the whois database? It similarly interferes with any future transfer >>> market >>> by making it impossible to do even the most rudimentary check on the >>> seller's claims. >>> >>> 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. >>> >> ARIN would provide referral WHOIS. Couldn't you just use this information? >> > > Referral to what? > > Someone who's had a legacy class C since 1992 comes to you and says "hi, I > moved and am now your customer, I'd like you to route this block to me". Who > has a listing for that address if this policy takes effect? > > Note that "tell the customer to go sign an LRSA first" isn't an acceptable > answer either, as many holders have many reasons (some no doubt even > legitimate) for not signing the LRSA. > > 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. > It seems like the intent is that they would create their own RWHOIS? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From dpinkard at accessline.com Mon Feb 14 16:10:52 2011 From: dpinkard at accessline.com (Dan Pinkard) Date: Mon, 14 Feb 2011 13:10:52 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: <4D599A5C.6060807@accessline.com> As I read this, the goal is to defeat using the whois registration as a tool to beat the heads of those who may consider signing the LRSA. I agree with that notion, especially as it makes it clear that forcing people into policy in a heavy-handed way can easily run-afoul of legalities and simple good-will. However, as it has been pointed out, we don't really want to lose that resource for the people who do pay. However unfair of those who don't pay up a little, the larger disservice would be to remove that all together. And what of the gray area for organizations who have some stuff under RSA and some stuff that should be LRSA if anyone were motivated to do it? It seems like taking away the baby's rattle is a good step, but not that way. What other means are available to motivate organizations to bring legacy space under the LRSA that don't cause other problems? If we're loking at the larger picture of parceling out unused or underutilized IPv4 space, is there a way ARIN can ease those needs in trade? (Is there a desire to help or harm that?) Benson Schliesser wrote: > Hi, John. > > On Feb 14, 2011, at 2:08 PM, John Santos wrote: > > >> 1) This is an opt-in, not an opt-out policy. You might discover that >> lots of legacy holders will get very pissed off if their reverse DNS >> suddenly goes away. I know I would. >> >> 2) There didn't seem to be any provision for notifying legacy holders >> of this change in policy. I certainly wouldn't know about it if I >> didn't subscribe to this mailing list. >> > > These are valid concerns. I think it is a good idea to include some additional text, for instance instructing ARIN to contact each organization. I'm not sure I grasp how difficult this would be. I'm also not sure whether this would be policy, meta-policy, rationale, etc. Comments on how specifically to deal with this concern in the proposal would be appreciated. > > >> 3) It isn't clear if legacy holders *MUST* sign an LRSA (or move to a >> regular RSA) to retain Whois, RDNS, etc. or not. >> > > Hopefully prop 133 is clear that a LRSA will be a valid "request" for services. But it doesn't make any limitations on what other kinds of request might be valid, i.e. it doesn't specify that the legacy holder must sign a LRSA. If ARIN policy permits something other than the LRSA, as a request for services by legacy address holders, that would not be prohibited by prop 133. > > >> 4) What is the point of this? >> > > The point of submitting the proposal is to encourage discussion of how ARIN should treat legacy address holders. The point of the policy proposal itself is to make it clear that ARIN won't exercise authority (e.g. policy enforcement via the Whois) over anybody that hasn't requested it. I believe that this is more legally viable than the current approach. > > One additional comment, to clarify a misconception: The point of this policy is not to "punish" legacy address holders that don't sign the LRSA. It might have that effect for some, but I'm not sure how to avoid it while developing policy that defines the relationship between legacy holders and ARIN. If anybody has suggestions for improving the policy text in this regard, I'm happy to discuss it. > > Cheers, > -Benson > > > _______________________________________________ > 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 Keith at jcc.com Mon Feb 14 16:41:28 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 14 Feb 2011 16:41:28 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon Sent: Monday, February 14, 2011 4:10 PM > As a matter of >transparency, it would be decent of anyone opposing this and similar >proposals to state any interest they may have in maintaining the >status quo for legacy space. Jeffrey, My interest in maintaining the status quo for legacy resources is that the system currently works. Unless a change is going to be a large benefit to the internet community, what is the point of changing? My company received a /24 in 1991. We signed an LRSA several years ago because it seemed a reasonable thing to do for the internet community. What is your interest in changing the status quo? Keith ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From jcurran at arin.net Mon Feb 14 16:44:27 2011 From: jcurran at arin.net (John Curran) Date: Mon, 14 Feb 2011 21:44:27 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D599A5C.6060807@accessline.com> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <4D599A5C.6060807@accessline.com> Message-ID: On Feb 14, 2011, at 4:10 PM, Dan Pinkard wrote: > As I read this, the goal is to defeat using the whois registration as a tool to beat the heads of those who may consider signing the LRSA. I agree with that notion, especially as it makes it clear that forcing people into policy in a heavy-handed way can easily run-afoul of legalities and simple good-will. However, as it has been pointed out, we don't really want to lose that resource for the people who do pay. However unfair of those who don't pay up a little, the larger disservice would be to remove that all together. And what of the gray area for organizations who have some stuff under RSA and some stuff that should be LRSA if anyone were motivated to do it? Dan - ARIN has been providing WHOIS and Reverse DNS services to legacy space holders without charge since inception. Aside from this particular policy proposal, I am not aware of any proposal for ARIN cease providing these services. > It seems like taking away the baby's rattle is a good step, but not that way. What other means are available to motivate organizations to bring legacy space under the LRSA that don't cause other problems? If we're loking at the larger picture of parceling out unused or underutilized IPv4 space, is there a way ARIN can ease those needs in trade? (Is there a desire to help or harm that?) I do not believe that the intent of this particular policy proposal is to encourage legacy holders to enter into an LRSA agreement with ARIN, but Benson can better address his actual intent with the policy proposal. /John John Curran President and CEO ARIN From hannigan at gmail.com Mon Feb 14 16:44:44 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Feb 2011 16:44:44 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D599A5C.6060807@accessline.com> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <4D599A5C.6060807@accessline.com> Message-ID: On Mon, Feb 14, 2011 at 4:10 PM, Dan Pinkard wrote: > As I read this, the goal is to defeat using the whois registration as a tool > to beat the heads of those who may consider signing the LRSA. I agree with > that notion, especially as it makes it clear that forcing people into policy > in a heavy-handed way can easily run-afoul of legalities and simple > good-will. However, as it has been pointed out, we don't really want to lose > that resource for the people who do pay. However unfair of those who don't > pay up a little, the larger disservice would be to remove that all together. > And what of the gray area for organizations who have some stuff under RSA > and some stuff that should be LRSA if anyone were motivated to do it? > > It seems like taking away the baby's rattle is a good step, but not that > way. What other means are available to motivate organizations to bring > legacy space under the LRSA that don't cause other problems? http://lists.arin.net/pipermail/arin-ppml/2011-February/019670.html > If we're loking > at the larger picture of parceling out unused or underutilized IPv4 space, > is there a way ARIN can ease those needs in trade? (Is there a desire to > help or harm that?) I think that there are a few (workable) issues. In order for law enforcement not to oppose, there needs to be "a" whois registry. The second is in-addr re delegation. I like Bensons proposal. I think it needs some refining, but count me on the tentative support side. Best, -M< From jeffrey.lyon at blacklotus.net Mon Feb 14 16:45:34 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:45:34 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: On Mon, Feb 14, 2011 at 4:41 PM, Keith W. Hare wrote: > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon > Sent: Monday, February 14, 2011 4:10 PM > > >> As a matter of >>transparency, it would be decent of anyone opposing this and similar >>proposals to state any interest they may have in maintaining the >>status quo for legacy space. > > Jeffrey, > > My interest in maintaining the status quo for legacy resources is that the system currently works. Unless a change is going to be a large benefit to the internet community, what is the point of changing? > > My company received a /24 in 1991. We signed an LRSA several years ago because it seemed a reasonable thing to do for the internet community. > > What is your interest in changing the status quo? > > Keith > > > ______________________________________________________________ > > Keith W. Hare ? ? ? ? ? ? ? ? ? ? JCC Consulting, Inc. > keith at jcc.com ? ? ? ? ? ? ? ? ? ? 600 Newark Road > Phone: 740-587-0157 ? ? ? ? ? ? ? P.O. Box 381 > Fax: 740-587-0163 ? ? ? ? ? ? ? ? Granville, Ohio 43023 > http://www.jcc.com ? ? ? ? ? ? ? ?USA > ______________________________________________________________ > > > > > Keith, In a broad sense, my interest is to promote equality and help ensure that all users of IP resources are bound to the same requirements. Our company received its first directly assigned resources in 2004. Specific to this proposition, I find it fundamentally flawed that I have to pay for something that another receives for free merely because they got in first. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bensons at queuefull.net Mon Feb 14 16:48:27 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 14 Feb 2011 15:48:27 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: On Feb 14, 2011, at 3:41 PM, Keith W. Hare wrote: > My interest in maintaining the status quo for legacy resources is that the system currently works. Unless a change is going to be a large benefit to the internet community, what is the point of changing? IPv4 exhaustion is a change that won't benefit the Internet community*, but it's happening. We really can't expect the status quo to be maintained forever. Cheers, -Benson * - Well, not in the short-term at least. Once we have critical mass of IPv6, I think it will benefit us all... But that's a different discussion. From jeffrey.lyon at blacklotus.net Mon Feb 14 16:48:51 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:48:51 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <4D599A5C.6060807@accessline.com> Message-ID: On Mon, Feb 14, 2011 at 4:44 PM, Martin Hannigan wrote: > On Mon, Feb 14, 2011 at 4:10 PM, Dan Pinkard wrote: >> As I read this, the goal is to defeat using the whois registration as a tool >> to beat the heads of those who may consider signing the LRSA. I agree with >> that notion, especially as it makes it clear that forcing people into policy >> in a heavy-handed way can easily run-afoul of legalities and simple >> good-will. However, as it has been pointed out, we don't really want to lose >> that resource for the people who do pay. However unfair of those who don't >> pay up a little, the larger disservice would be to remove that all together. >> And what of the gray area for organizations who have some stuff under RSA >> and some stuff that should be LRSA if anyone were motivated to do it? >> >> It seems like taking away the baby's rattle is a good step, but not that >> way. What other means are available to motivate organizations to bring >> legacy space under the LRSA that don't cause other problems? > > http://lists.arin.net/pipermail/arin-ppml/2011-February/019670.html > >> If we're loking >> at the larger picture of parceling out unused or underutilized IPv4 space, >> is there a way ARIN can ease those needs in trade? (Is there a desire to >> help or harm that?) > > > I think that there are a few (workable) issues. In order for law > enforcement not to oppose, there needs to be "a" whois registry. The > second is in-addr re delegation. > > > I like Bensons proposal. I think it needs some refining, but count me > on the tentative support side. > > Best, > > -M< > _______________________________________________ > 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. > You bring up a good point about law enforcement, but the lack of a WHOIS entry does not make the assignee untraceable, it merely means that ARIN is not providing it's services. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From Keith at jcc.com Mon Feb 14 16:54:30 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 14 Feb 2011 16:54:30 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: <3b9575377ea06c9d545ae42e7d666ad34d59a3e9@jcc.com> So, how does this change benefit the IPv4 community? -----Original Message----- From: Benson Schliesser [mailto:bensons at queuefull.net] Sent: Monday, February 14, 2011 4:48 PM To: Keith W. Hare Cc: Jeffrey Lyon; arin-ppml at arin.net List Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks On Feb 14, 2011, at 3:41 PM, Keith W. Hare wrote: > My interest in maintaining the status quo for legacy resources is that the system currently works. Unless a change is going to be a large benefit to the internet community, what is the point of changing? IPv4 exhaustion is a change that won't benefit the Internet community*, but it's happening. We really can't expect the status quo to be maintained forever. Cheers, -Benson * - Well, not in the short-term at least. Once we have critical mass of IPv6, I think it will benefit us all... But that's a different discussion. From hannigan at gmail.com Mon Feb 14 16:54:42 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Mon, 14 Feb 2011 16:54:42 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <4D599A5C.6060807@accessline.com> Message-ID: On Mon, Feb 14, 2011 at 4:48 PM, Jeffrey Lyon wrote: > On Mon, Feb 14, 2011 at 4:44 PM, Martin Hannigan wrote: >> On Mon, Feb 14, 2011 at 4:10 PM, Dan Pinkard wrote: >>> As I read this, the goal is to defeat using the whois registration as a tool >>> to beat the heads of those who may consider signing the LRSA. I agree with >>> that notion, especially as it makes it clear that forcing people into policy >>> in a heavy-handed way can easily run-afoul of legalities and simple >>> good-will. However, as it has been pointed out, we don't really want to lose >>> that resource for the people who do pay. However unfair of those who don't >>> pay up a little, the larger disservice would be to remove that all together. >>> And what of the gray area for organizations who have some stuff under RSA >>> and some stuff that should be LRSA if anyone were motivated to do it? >>> >>> It seems like taking away the baby's rattle is a good step, but not that >>> way. What other means are available to motivate organizations to bring >>> legacy space under the LRSA that don't cause other problems? >> >> http://lists.arin.net/pipermail/arin-ppml/2011-February/019670.html >> >>> If we're loking >>> at the larger picture of parceling out unused or underutilized IPv4 space, >>> is there a way ARIN can ease those needs in trade? (Is there a desire to >>> help or harm that?) >> >> >> I think that there are a few (workable) issues. In order for law >> enforcement not to oppose, there needs to be "a" whois registry. The >> second is in-addr re delegation. >> >> >> I like Bensons proposal. I think it needs some refining, but count me >> on the tentative support side. >> >> Best, >> >> -M< [ clip ] > > You bring up a good point about law enforcement, but the lack of a > WHOIS entry does not make the assignee untraceable, it merely means > that ARIN is not providing it's services. I'm not arguing here, but if we have anything less than we have now in terms of whois requirements, they'll line up in opposition. The proposal "could" require a referal to an rwhois server or to another whois service if one exists. But a whois requirement equal to or better than ARIN's is a must for this to pass IMHO. Best, -M, From jeffrey.lyon at blacklotus.net Mon Feb 14 16:57:08 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 16:57:08 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <4D599A5C.6060807@accessline.com> Message-ID: On Mon, Feb 14, 2011 at 4:54 PM, Martin Hannigan wrote: > On Mon, Feb 14, 2011 at 4:48 PM, Jeffrey Lyon > wrote: >> On Mon, Feb 14, 2011 at 4:44 PM, Martin Hannigan wrote: >>> On Mon, Feb 14, 2011 at 4:10 PM, Dan Pinkard wrote: >>>> As I read this, the goal is to defeat using the whois registration as a tool >>>> to beat the heads of those who may consider signing the LRSA. I agree with >>>> that notion, especially as it makes it clear that forcing people into policy >>>> in a heavy-handed way can easily run-afoul of legalities and simple >>>> good-will. However, as it has been pointed out, we don't really want to lose >>>> that resource for the people who do pay. However unfair of those who don't >>>> pay up a little, the larger disservice would be to remove that all together. >>>> And what of the gray area for organizations who have some stuff under RSA >>>> and some stuff that should be LRSA if anyone were motivated to do it? >>>> >>>> It seems like taking away the baby's rattle is a good step, but not that >>>> way. What other means are available to motivate organizations to bring >>>> legacy space under the LRSA that don't cause other problems? >>> >>> http://lists.arin.net/pipermail/arin-ppml/2011-February/019670.html >>> >>>> If we're loking >>>> at the larger picture of parceling out unused or underutilized IPv4 space, >>>> is there a way ARIN can ease those needs in trade? (Is there a desire to >>>> help or harm that?) >>> >>> >>> I think that there are a few (workable) issues. In order for law >>> enforcement not to oppose, there needs to be "a" whois registry. The >>> second is in-addr re delegation. >>> >>> >>> I like Bensons proposal. I think it needs some refining, but count me >>> on the tentative support side. >>> >>> Best, >>> >>> -M< > > [ clip ] > >> >> You bring up a good point about law enforcement, but the lack of a >> WHOIS entry does not make the assignee untraceable, it merely means >> that ARIN is not providing it's services. > > I'm not arguing here, but if we have anything less than we have now in > terms of whois requirements, they'll line up in opposition. The > proposal "could" require a referal to an rwhois server or to another > whois service if one exists. But a whois requirement equal to or > better than ARIN's is a must for this to pass IMHO. > > > > Best, > > -M, > It would indeed be appropriate to publish the last known contacts for records without sufficient RWHOIS. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Mon Feb 14 17:19:32 2011 From: jcurran at arin.net (John Curran) Date: Mon, 14 Feb 2011 22:19:32 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: <2A70055E-90DA-4147-B8A7-113DCC99F234@corp.arin.net> On Feb 14, 2011, at 4:45 PM, Jeffrey Lyon wrote: > In a broad sense, my interest is to promote equality and help ensure > that all users of IP resources are bound to the same requirements. Our > company received its first directly assigned resources in 2004. > > Specific to this proposition, I find it fundamentally flawed that I > have to pay for something that another receives for free merely > because they got in first. Jeffrey - To the extent that you are referring to the Whois and Reverse DNS services provided to legacy holders by ARIN without charge, there was a conscience decision made in the formation of ARIN recognizing that many of the legacy address holders simply wished to be able to make use their assigned space and that the incremental cost to provides such services was relatively modest. Over time, we added the option of entering into a Legacy RSA and paying $100/year to help defray their share of those costs. This policy proposal may not really change offering free services; to the extent that ARIN is still maintaining "references and/or RWhois referral" information, these costs can be comparable. Should ARIN maintain those for free under this policy (for sake of the accuracy of the overall system), or not offer them unless compensated? The tradition of the Internet has been to provide these services because they're necessary to keep things running, but you are expressing concern about the proposal addressing an inequity that I would like to better understand. Thanks! /John John Curran President and CEO ARIN From Keith at jcc.com Mon Feb 14 17:24:11 2011 From: Keith at jcc.com (Keith W. Hare) Date: Mon, 14 Feb 2011 17:24:11 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: <40d20abc721782d45dcaabcafa703b204d59aadc@jcc.com> Jeff, >Specific to this proposition, I find it fundamentally flawed that I >have to pay for something that another receives for free merely >because they got in first. For years, ARIN mostly ignored legacy resource holders so legacy resource holders mostly ignored ARIN. Not long after I joined the ARIN Policy mailing list, there was a big flap about how legacy resource holders were not paying their fair share of the ARIN costs. I went off to the ARIN web site and could not find any way for a legacy resource holder to voluntarily bring their resources under ARIN's control. So I ranted a bit about how the evil legacy resource holders were not taking advantage of some unavailable mechanism to pay their fair share. I think this discussion (about July, 2007) was some of the impetus for the creation of the LRSA. The LRSA was initially released in November, 2007, a bit over three years and three months ago. Since then, ARIN has been working to get legacy resource holders to buy into the LRSA, but this is an ongoing process. How does this proposal benefit you other than somehow sticking it to the legacy resource holders who are receiving services for free? Keith From springer at inlandnet.com Mon Feb 14 17:31:04 2011 From: springer at inlandnet.com (John Springer) Date: Mon, 14 Feb 2011 14:31:04 -0800 (PST) Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: <20110214135500.I94203@mail.inlandnet.com> Hi Benton, 'nother John to confuse things here. I regret to say that I oppose ARIN-prop-133. On Mon, 14 Feb 2011, Benson Schliesser wrote to John Santos: > Hi, John. > > On Feb 14, 2011, at 2:08 PM, John Santos wrote: -elided- >> 4) What is the point of this? I very much appreciate a policy proposer anwering this question (and thanks, Mr. Santos for asking it). I wish all proposers would as explicitly do so in their rationale. > The point of submitting the proposal is to encourage discussion of how ARIN should treat legacy address holders. Many legacy address holders without LRSAs that I have talked to are not much concerned about discussions of how ARIN should treat them, except with a sort of "Don't Tread on Me" sentiment. And while I am not one myself, I have some sympathy with that. I feel that "Leave them alone." is an acceptable policy with valid benefits to the community. > The point of the policy proposal itself is to make it clear that ARIN > won't exercise authority (e.g. policy enforcement via the Whois) over > anybody that hasn't requested it. Er. If I am inverting out the negatives right, you propose that ARIN exercise authority over anybody (in the form of knocking out whois and rdns) who requests it (by not signing an LRSA). > I believe that this is more legally viable than the current approach. I hope you're mistaken. > One additional comment, to clarify a misconception: The point of this > policy is not to "punish" legacy address holders that don't sign the > LRSA. It might have that effect for some, but I'm not sure how to avoid > it while developing policy that defines the relationship between legacy > holders and ARIN. If anybody has suggestions for improving the policy > text in this regard, I'm happy to discuss it. Yikes. I think I would rather it had been less clear. I am not in favor of punishing legacy address holders whether you call it that or pudding and I am not in favor of policy that might have that effect for some. We avoid it by, in particular, opposing this policy and not advancing it. Developing policy that defines the relationship between legacy holders and ARIN will have to be forgone, in my opinion, if a side effect can be in any way construed as resembling a stick. It's just not called for. regards John Springer > > Cheers, > -Benson > > > _______________________________________________ > 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 george.herbert at gmail.com Mon Feb 14 17:40:39 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 14 Feb 2011 14:40:39 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <20110214135500.I94203@mail.inlandnet.com> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <20110214135500.I94203@mail.inlandnet.com> Message-ID: On Mon, Feb 14, 2011 at 2:31 PM, John Springer wrote: > Developing policy that defines the relationship between legacy holders and > ARIN will have to be forgone, in my opinion, if a side effect can be in any > way construed as resembling a stick. It's just not called for. It's clearly a major political negative, in that it antagonizes touchy relationships with legacy holders. If there were clear financial issues for ARIN with supporting services not paid for by IP owners, that would be a valid argument for the proposal, but I've never seen such an argument made. If there were clear operational issues with the legacies that this would address, that would be a valid argument for the proposal, but I've never seen any of those. As pointed out by others, it introduces operational uncertainty if anything, as the legacy WHOIS services are disabled. If your goal is to promote discussion with and engaging with legacies, that's fine, but you haven't justified shaking this big a stick at them It comes down to a policy question and a legal question. And those are touchy in multifaceted ways, that this proposal doesn't help in any way, other than pushing the question forwards more actively and provocatively. I oppose. -- -george william herbert george.herbert at gmail.com From bensons at queuefull.net Mon Feb 14 17:53:56 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Mon, 14 Feb 2011 16:53:56 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <784247EC-6BE8-4764-8D7D-49C4E3C9ADB2@arin.net> References: <4D595D12.4000602@arin.net> <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> <784247EC-6BE8-4764-8D7D-49C4E3C9ADB2@arin.net> Message-ID: <25E5FE8D-E376-497E-AE03-34571B987683@queuefull.net> Hi, John. This is a complicated question. I will offer my personal view* of the current situation, acknowledging that I don' t know everything and that the situation is evolving. Your feedback on this would be appreciated. On Feb 14, 2011, at 3:19 PM, John Curran wrote: > On Feb 14, 2011, at 1:30 PM, Benson Schliesser wrote: >> >> I think you understand the effect of the text, yes. But my answer is a bit more nuanced: >> >> Policy proposal 133, in section 13.2, would have ARIN recognize assignments that take place beyond ARIN's scope. In other words, the act of ARIN recognizing the new legitimate address holder is not what creates the assignment; the assignment would have already taken place and ARIN would simply be recognizing that fact. > > Interesting conjecture. To the extent that policies of the > ICANN and/or IANA were preclude such transfers, do you also > propose that these assignments take place beyond their scope? No, I do not propose that any recognizable Internet address assignments take place beyond the scope of IANA, and I would expect ARIN to comply with IANA policy unless doing so is prohibited by law. (In other words, compliance with the law supersedes compliance with IANA policy, and IANA policy supersedes ARIN policy.) My rationale for this statement is as follows: The IANA function is provided by ICANN under contract with the NTIA/DoC, having taken over responsibility from DoD etc. As such, in the US at least, the IANA has some delegated authority that ARIN does not have. ARIN is subject to that authority, whether or not a formal relationship (i.e. contract) exists between ARIN and IANA. As a side note: I recognize that IANA's standing, described above, has implications for the policy that ARIN implements. As such, for example, removal of a justified need policy might require work in the IETF and IANA before it can be implemented by ARIN. However, this does not imply that ARIN must enforce IANA policy beyond ARIN's own scope of authority. For instance, ARIN doesn't enforce IANA policy in another RIR's region, nor would ARIN be expected to enforce IANA policy for unaffiliated addresses. Cheers, -Benson * - Full Disclosure, which applies to everything I write or say unless indicated otherwise: I am employed by Cisco Systems, but my statements and opinions are mine alone and do not represent my employer or any other entity. From owen at delong.com Mon Feb 14 18:06:55 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Feb 2011 15:06:55 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Message-ID: <338895B9-0BE0-4E05-A333-6A849B9D3BB4@delong.com> On Feb 14, 2011, at 12:32 PM, Benson Schliesser wrote: > > On Feb 14, 2011, at 2:23 PM, Owen DeLong wrote: > >> Legacy and other addresses returned should be treated the same. >> >> Once an address is returned to ARIN, it is no longer a legacy address. >> >> This policy does not make sense so long as it singles out legacy addresses. > > I agree with Owen on this. > > ARIN should only accept returned legacy addresses from holders in the ARIN region. But, once accepted, that address space has been effectively transferred to ARIN. It is up to ARIN policy to decide whether to return that block to IANA, reallocate to new requests, etc. And there are no technical reasons to treat address blocks differently, as far as I'm aware. > > Cheers, > -Benson > > Small nuance here... ARIN should accept return of legacy resources currently served by ARIN (in-addr, whois), regardless of the actual current location of the legacy holder. ARIN probably should not accept return of legacy resources served by the 4 other RIRs unless ARIN coordinates such an acceptance with the applicable RIR. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Feb 14 18:17:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 14 Feb 2011 15:17:31 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Message-ID: <25E7DD1B-6A82-4283-AAB3-811CEE372FC2@delong.com> Marty, According to http://en.wikipedia.org/wiki/Straw_man, you claim my argument that this policy should not apply uniquely to legacy holders is an "informal fallacy based on misrepresentation of the opponent's position". In what way, exactly, have I misrepresented your position? Where is the fallacy in my argument? Do you have anything substantial with which to answer these questions? If you want a policy that says return of legacy resources should be handled identically to the return of any other resource, then I am fine with that. I think that is already the default behavior of ARIN and the policy would be a no-op, but, I wouldn't oppose it as I do the current form of your proposal. If you want a policy that says all returned resources should be rapidly recycled into the free pool in 30 days, I would be OK with that policy as well. I would suggest that such an expedited recycling should probably be limited to resources returned voluntarily as resources reclaimed through other means may cause additional trauma to the future recipients that could be avoided by a slower, more deliberate recycling process. However, the current policy which singles out returned legacy resources for unusually rapid recycling seems ill-advised to me. That's not an informal fallacy. That's my opinion based on observation and experience. It certainly does not misrepresent the content of your policy proposal and if you believe my statements misrepresent your position, then you need to explain how, exactly, that is the case. Owen On Feb 14, 2011, at 1:28 PM, Martin Hannigan wrote: > On Mon, Feb 14, 2011 at 4:13 PM, Jeffrey Lyon > wrote: > > [ snip] > >> >> I also agree with Owen on this point. >> > > You're supporting straw man arguments. Do you have anything more substantial? > > Best, > > -M< > _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Mon Feb 14 19:06:34 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 19:06:34 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <40d20abc721782d45dcaabcafa703b204d59aadf@jcc.com> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <40d20abc721782d45dcaabcafa703b204d59aadf@jcc.com> Message-ID: On Mon, Feb 14, 2011 at 5:24 PM, Keith W. Hare wrote: > Jeff, > >>Specific to this proposition, I find it fundamentally flawed that I >>have to pay for something that another receives for free merely >>because they got in first. > > For years, ARIN mostly ignored legacy resource holders so legacy resource holders mostly ignored ARIN. > > Not long after I joined the ARIN Policy mailing list, there was a big flap about how legacy resource holders were not paying their fair share of the ARIN costs. I went off to the ARIN web site and could not find any way for a legacy resource holder to voluntarily bring their resources under ARIN's control. So I ranted a bit about how the evil legacy resource holders were not taking advantage of some unavailable mechanism to pay their fair share. > > I think this discussion (about July, 2007) was some of the impetus for the creation of the LRSA. The LRSA was initially released in November, 2007, a bit over three years and three months ago. Since then, ARIN has been working to get legacy resource holders to buy into the LRSA, but this is an ongoing process. > > How does this proposal benefit you other than somehow sticking it to the legacy resource holders who are receiving services for free? > > Keith > Keith, John, et al, I have no ill will toward legacy holders and I completely understand that the actual cost of providing free services is negligible. My concern is more principle in nature. If someone is operating IP resources in the ARIN region they should be compelled to pay the same fees that we all must pay and follow the rules that we all must follow. This proposal would begin to achieve that result. With that said, I did not sponsor this proposal nor do I have a significant dog in this fight. I'm merely expressing my point of view that I agree with the proposal for the sake of putting in my two cents. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From springer at inlandnet.com Mon Feb 14 20:08:43 2011 From: springer at inlandnet.com (John Springer) Date: Mon, 14 Feb 2011 17:08:43 -0800 (PST) Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <40d20abc721782d45dcaabcafa703b204d59aadf@jcc.com> Message-ID: <20110214161917.L94203@mail.inlandnet.com> Hi Jeffrey, On the off chance that I'm the John to whom you refer there is an inline comment, if not, please pardon the intrusion. On Mon, 14 Feb 2011, Jeffrey Lyon wrote: > On Mon, Feb 14, 2011 at 5:24 PM, Keith W. Hare wrote: >> Jeff, >> >>> Specific to this proposition, I find it fundamentally flawed that I >>> have to pay for something that another receives for free merely >>> because they got in first. >> >> For years, ARIN mostly ignored legacy resource holders so legacy resource holders mostly ignored ARIN. >> >> Not long after I joined the ARIN Policy mailing list, there was a big flap about how legacy resource holders were not paying their fair share of the ARIN costs. I went off to the ARIN web site and could not find any way for a legacy resource holder to voluntarily bring their resources under ARIN's control. So I ranted a bit about how the evil legacy resource holders were not taking advantage of some unavailable mechanism to pay their fair share. >> >> I think this discussion (about July, 2007) was some of the impetus for the creation of the LRSA. The LRSA was initially released in November, 2007, a bit over three years and three months ago. Since then, ARIN has been working to get legacy resource holders to buy into the LRSA, but this is an ongoing process. >> >> How does this proposal benefit you other than somehow sticking it to the legacy resource holders who are receiving services for free? >> >> Keith >> > > > Keith, John, et al, > > I have no ill will toward legacy holders and I completely understand > that the actual cost of providing free services is negligible. My > concern is more principle in nature. If someone is operating IP > resources in the ARIN region they should be compelled to pay the same > fees that we all must pay and follow the rules that we all must > follow. The difficulty arises in that the legacy allocations under discussion predate ARIN and ARIN does not appear to have ascended to authority over them by its creation. I will be happy to be corrected if this is not the case. I hope that "...they should be..." won't be enough to change that and "they should not be" might be enough to prevent it. I don't have any legacy space. If legacy holders, for what reason seems good to them, don't want to sign an LRSA, I don't think they should have to. > This proposal would begin to achieve that result. I'd rather it wouldn't. About face, forward march, and all that. best regards John Springer > With that said, I did not sponsor this proposal nor do I have a > significant dog in this fight. I'm merely expressing my point of view > that I agree with the proposal for the sake of putting in my two > cents. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > _______________________________________________ > 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 jeffrey.lyon at blacklotus.net Mon Feb 14 20:22:51 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 14 Feb 2011 20:22:51 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <20110214161917.L94203@mail.inlandnet.com> References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <40d20abc721782d45dcaabcafa703b204d59aadf@jcc.com> <20110214161917.L94203@mail.inlandnet.com> Message-ID: On Mon, Feb 14, 2011 at 8:08 PM, John Springer wrote: > Hi Jeffrey, > > On the off chance that I'm the John to whom you refer there is an inline > comment, if not, please pardon the intrusion. > > On Mon, 14 Feb 2011, Jeffrey Lyon wrote: > >> On Mon, Feb 14, 2011 at 5:24 PM, Keith W. Hare wrote: >>> >>> Jeff, >>> >>>> Specific to this proposition, I find it fundamentally flawed that I >>>> have to pay for something that another receives for free merely >>>> because they got in first. >>> >>> For years, ARIN mostly ignored legacy resource holders so legacy resource >>> holders mostly ignored ARIN. >>> >>> Not long after I joined the ARIN Policy mailing list, there was a big >>> flap about how legacy resource holders were not paying their fair share of >>> the ARIN costs. I went off to the ARIN web site and could not find any way >>> for a legacy resource holder to voluntarily bring their resources under >>> ARIN's control. So I ranted a bit about how the evil legacy resource holders >>> were not taking advantage of some unavailable mechanism to pay their fair >>> share. >>> >>> I think this discussion (about July, 2007) was some of the impetus for >>> the creation of the LRSA. The LRSA was initially released in November, 2007, >>> a bit over three years and three months ago. Since then, ARIN has been >>> working to get legacy resource holders to buy into the LRSA, but this is an >>> ongoing process. >>> >>> How does this proposal benefit you other than somehow sticking it to the >>> legacy resource holders who are receiving services for free? >>> >>> Keith >>> >> >> >> Keith, John, et al, >> >> I have no ill will toward legacy holders and I completely understand >> that the actual cost of providing free services is negligible. My >> concern is more principle in nature. If someone is operating IP >> resources in the ARIN region they should be compelled to pay the same >> fees that we all must pay and follow the rules that we all must >> follow. > > The difficulty arises in that the legacy allocations under discussion > predate ARIN and ARIN does not appear to have ascended to authority over > them by its creation. I will be happy to be corrected if this is not the > case. > > I hope that "...they should be..." won't be enough to change that and "they > should not be" might be enough to prevent it. > > I don't have any legacy space. If legacy holders, for what reason seems good > to them, don't want to sign an LRSA, I don't think they should have to. > >> This proposal would begin to achieve that result. > > I'd rather it wouldn't. About face, forward march, and all that. > > best regards > > John Springer > >> With that said, I did not sponsor this proposal nor do I have a >> significant dog in this fight. I'm merely expressing my point of view >> that I agree with the proposal for the sake of putting in my two >> cents. >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions >> _______________________________________________ >> 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. >> >> > John, I don't intend to presume that ARIN has authority over legacy holders, but it does have a certain level of control over what services can or should be provided to those organizations. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From george.herbert at gmail.com Mon Feb 14 20:36:02 2011 From: george.herbert at gmail.com (George Herbert) Date: Mon, 14 Feb 2011 17:36:02 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <40d20abc721782d45dcaabcafa703b204d59aadf@jcc.com> <20110214161917.L94203@mail.inlandnet.com> Message-ID: On Mon, Feb 14, 2011 at 5:22 PM, Jeffrey Lyon wrote: > On Mon, Feb 14, 2011 at 8:08 PM, John Springer wrote: >> Hi Jeffrey, >> >> On the off chance that I'm the John to whom you refer there is an inline >> comment, if not, please pardon the intrusion. >> >> On Mon, 14 Feb 2011, Jeffrey Lyon wrote: >> >>> On Mon, Feb 14, 2011 at 5:24 PM, Keith W. Hare wrote: >>>> >>>> Jeff, >>>> >>>>> Specific to this proposition, I find it fundamentally flawed that I >>>>> have to pay for something that another receives for free merely >>>>> because they got in first. >>>> >>>> For years, ARIN mostly ignored legacy resource holders so legacy resource >>>> holders mostly ignored ARIN. >>>> >>>> Not long after I joined the ARIN Policy mailing list, there was a big >>>> flap about how legacy resource holders were not paying their fair share of >>>> the ARIN costs. I went off to the ARIN web site and could not find any way >>>> for a legacy resource holder to voluntarily bring their resources under >>>> ARIN's control. So I ranted a bit about how the evil legacy resource holders >>>> were not taking advantage of some unavailable mechanism to pay their fair >>>> share. >>>> >>>> I think this discussion (about July, 2007) was some of the impetus for >>>> the creation of the LRSA. The LRSA was initially released in November, 2007, >>>> a bit over three years and three months ago. Since then, ARIN has been >>>> working to get legacy resource holders to buy into the LRSA, but this is an >>>> ongoing process. >>>> >>>> How does this proposal benefit you other than somehow sticking it to the >>>> legacy resource holders who are receiving services for free? >>>> >>>> Keith >>>> >>> >>> >>> Keith, John, et al, >>> >>> I have no ill will toward legacy holders and I completely understand >>> that the actual cost of providing free services is negligible. My >>> concern is more principle in nature. If someone is operating IP >>> resources in the ARIN region they should be compelled to pay the same >>> fees that we all must pay and follow the rules that we all must >>> follow. >> >> The difficulty arises in that the legacy allocations under discussion >> predate ARIN and ARIN does not appear to have ascended to authority over >> them by its creation. I will be happy to be corrected if this is not the >> case. >> >> I hope that "...they should be..." won't be enough to change that and "they >> should not be" might be enough to prevent it. >> >> I don't have any legacy space. If legacy holders, for what reason seems good >> to them, don't want to sign an LRSA, I don't think they should have to. >> >>> This proposal would begin to achieve that result. >> >> I'd rather it wouldn't. About face, forward march, and all that. >> >> best regards >> >> John Springer >> >>> With that said, I did not sponsor this proposal nor do I have a >>> significant dog in this fight. I'm merely expressing my point of view >>> that I agree with the proposal for the sake of putting in my two >>> cents. >>> >>> -- >>> Jeffrey Lyon, Leadership Team >>> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >>> Black Lotus Communications - AS32421 >>> First and Leading in DDoS Protection Solutions >>> _______________________________________________ >>> 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. >>> >>> >> > > John, > > I don't intend to presume that ARIN has authority over legacy holders, > but it does have a certain level of control over what services can or > should be provided to those organizations. It has, however, previously given those services to everyone. If providing those services to legacy holders is not economical, then ARIN should be proposing this, along with a fiscal explanation. That appears not to be the case. -- -george william herbert george.herbert at gmail.com From farmer at umn.edu Mon Feb 14 20:53:58 2011 From: farmer at umn.edu (David Farmer) Date: Mon, 14 Feb 2011 19:53:58 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> Message-ID: <4D59DCB6.3010400@umn.edu> On 2/14/11 15:03 CST, Martin Hannigan wrote: > On Mon, Feb 14, 2011 at 3:32 PM, Benson Schliesser > wrote: >> > > [ snip ] > >> Legacy and other addresses returned should be treated the same. >> >> Once an address is returned to ARIN, it is no longer a legacy address. >> >> This policy does not make sense so long as it singles out legacy addresses. >> >> I agree with Owen on this. >> ARIN should only accept returned legacy addresses from holders in the ARIN >> region. But, once accepted, that address space has been effectively >> transferred to ARIN. > > Here's what the text actually says: > > "5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region within > thirty days of their receipt." > > There's no argument here that once an address is added to ARIN's > inventory it's a done deal. The proposal doesn't seek to do otherwise > nor does the language imply that it would. > >> It is up to ARIN policy to decide whether to return >> that block to IANA, reallocate to new requests, etc. And there are no >> technical reasons to treat address blocks differently, as far as I'm aware. > > All that this proposal does is codify the instruction to return these > addresses to ARIN inventory and use them. The current situation is > ambiguous and open to interpretation. This has nothing to do with the > IANA at all. In fact, in the absence of a global policy, this simply > makes the instruction "use the addresses". > > With regards to accepting legacy addresses from entities "only" in the > ARIN region, I think that's a fair point and will put it on the list > of final modifications. By my interpretation your text does one additional thing than what you state above, it specifics that ARIN does this within 30 days, where I believe the current operational practice is 6 months. Do I interpret your intention correctly? If you believe I'm interpreting that wrong, please explain. It is this apparent change in operational practice that I believe has many people concerned, and asking why this policy should only apply to Legacy space. If you remove the clause "within thirty days of their receipt," then I believe the text only does what you describe above. As I said before, I find the 30 day clause an interesting change in and of itself, but I cannot support that change applied to Legacy address space only. If only because it would seem if someone voluntarily returned non-legacy space one could interpret the policy as intending current operational practice of 6 month be applied in that case, I'd kind of like to see that be 30 days too. So, I believe that leaves two choices; 1. Remove to 30 day clause from this policy text, or; 2. Add text that applies the 30 day clause to all address space returned to ARIN #1 is I believe clean and simple and what you state your intentions are above. #2 is much more complicated, because it will conflict with the RSA and LRSA in some situations, and is probably to short for non-voluntary returns anyway. Therefore, option #2 is probably not a good idea if you want to keep things simple. By the way, I believe the text above, with the 30 day clause only applied to Legacy addresses, conflicts with the LRSA. I believe, the 30 day clause could not be applied to any addresses which ARIN would reclaim for non-payment from anyone who has signed an LRSA, since the clauses in the LRSA would have precedence. Since in the LRSA the LRSA is given legal precedence over policy changes that would conflict with it, the main risk is that this will create confusion and misunderstandings within the community, which it would be nice to avoid. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bill at herrin.us Mon Feb 14 21:24:52 2011 From: bill at herrin.us (William Herrin) Date: Mon, 14 Feb 2011 21:24:52 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D595D12.4000602@arin.net> References: <4D595D12.4000602@arin.net> Message-ID: On Mon, Feb 14, 2011 at 11:49 AM, ARIN wrote: > ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address > Blocks Is it too late to fork the legacy /8's into a sixth registry that exists solely to deal with the disposition of those IPv4 registrations? The legacy registrations are going to be a perennial bone of contention within the ARIN community. The legacy registrants would cough up the money for a registry the same as they do for their respective domain names. That offer isn't on the table and the LR's terms for ARIN during ARIN's creation were that ARIN would leave them the hell alone. Those are still their terms. Regards, Bill Herrin -- 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 Mon Feb 14 21:30:56 2011 From: JOHN at egh.com (John Santos) Date: Mon, 14 Feb 2011 21:30:56 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks (fwd) Message-ID: <1110214210015.4290L-300001@Ives.egh.com> Shortly after I made my initial response to prop 133, I recieved this email. 1) Do I understand it correctly? Are these people offering to sell me the RDNS and WHOIS service I currently receive from ARIN for free? 2) Is this proposal a Trojan Horse for an attempt to unilateraly privitize ARIN? 3) Is it an attempt to get an unregulated (i.e. not need-based) market in under the radar? Is the "illusionary claim" it purports to free me from the prohibition against selling my (unroutable, most likely) Class C to the highest bidder? Not that I would do that in any case, because I'm pretty sure when I obtained it from the InterNIC in 1993, it was clear that the assignment was based on need and if we didn't need it any more, we were supposed to return it. In any case, it would cost in the 5 digits for us to renumber and coordinate with all our network partners (firewalls, VPNs, etc.) not to mention future costs due to no longer having globally unique address space, selling is a definite non-starter even if was otherwise acceptable. 4) Is this email a violation of the ARIN PPML acceptable use policy due to being SPAM? -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- Mr. Santos, Please accept my apologies for the intrusion to your recent posting regarding the proposed new ARIN Policy titled No Volunteer Services on Behalf of Unaffiliated Address Blocks. While on the surface it may appear to be a negative proposal for legacy holders of IPv4 number blocks, I can assure you it is actually quite the opposite for it frees them once and for all from ARIN's illusionary claims. We, as the first commercial IP Address Internet Registry which only provides post-allocation services to legacy block holders, are fully supportive of this proposal. If you have any questions please contact me and we can either discuss this or continue a dialogue. If you are interested, our services are clearly provided for at www.depository.net Best regards, Peter Thimmesch Chairman +1 703.871.4822 (o) +1 202.957.5805 (m) Description: Description: Description: Description: depository_PPTGRPHCLOGO 1775 Wiehle Avenue Suite 400 Reston, VA 20190 USA __________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 4509 bytes Desc: not available URL: From jcurran at arin.net Mon Feb 14 22:40:11 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 03:40:11 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <25E5FE8D-E376-497E-AE03-34571B987683@queuefull.net> References: <4D595D12.4000602@arin.net> <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> <784247EC-6BE8-4764-8D7D-49C4E3C9ADB2@arin.net> <25E5FE8D-E376-497E-AE03-34571B987683@queuefull.net> Message-ID: <79D61AC7-6378-4A58-8272-B18F9F7AA87E@arin.net> On Feb 14, 2011, at 5:53 PM, Benson Schliesser wrote: > No, I do not propose that any recognizable Internet address assignments take place beyond the scope of IANA, and I would expect ARIN to comply with IANA policy unless doing so is prohibited by law. (In other words, compliance with the law supersedes compliance with IANA policy, and IANA policy supersedes ARIN policy.) > > My rationale for this statement is as follows: The IANA function is provided by ICANN under contract with the NTIA/DoC, having taken over responsibility from DoD etc. As such, in the US at least, the IANA has some delegated authority that ARIN does not have. ARIN is subject to that authority, whether or not a formal relationship (i.e. contract) exists between ARIN and IANA. Benson - When ARIN was created, on its first day of operation, it had only "legacy allocations". The Whois database was transferred by NSI (Network Solutions Inc) to ARIN as NSI had been performing these services as part of the InterNIC cooperative agreement up till this point. The transition of these responsibilities to ARIN (and release of NSI from these duties) was done with the consent of the National Science Foundation (which was the contracting agency for these tasks at the time) Jon Postel, the IANA at the time, was part of the team that formed ARIN and was an ex-officio member of the initial Board. After the IANA function was contracted to ICANN by the US Dept of Commerce (the current contracting agency for these tasks), the RIRs and ICANN entered into an agreement whereby the RIRs would serve the function of of ICANN's Address Supporting Organization, responsible for "global number resource policy development". In your proposal, you might consider some way to reconcile acknowledging ICANN/IANA's policy authority while not acknowledging the NRO/RIR policy authority without contradicting the RIRs serving under agreement as ICANN's policy body for Internet number resources. I believe that would significantly strengthen the policy proposal if that is your goal. FYI, /John John Curran President and CEO ARIN From gary.buhrmaster at gmail.com Mon Feb 14 22:41:59 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Mon, 14 Feb 2011 19:41:59 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: On Mon, Feb 14, 2011 at 13:48, Benson Schliesser wrote: > > On Feb 14, 2011, at 3:41 PM, Keith W. Hare wrote: > >> My interest in maintaining the status quo for legacy resources is that the system currently works. Unless a change is going to be a large benefit to the internet community, what is the point of changing? > > IPv4 exhaustion is a change that won't benefit the Internet community*, but it's happening. ?We really can't expect the status quo to be maintained forever. > > Cheers, > -Benson > > * - Well, not in the short-term at least. ?Once we have critical mass of IPv6, I think it will benefit us all... But that's a different discussion. While I am not as optimistic about the dates of critical mass of IPv6 adoption as some in the community, I see little reason to invest efforts in ARIN IPv4 policy at this point unless there is a clear benefit to the community in the migration to IPv6. This policy proposal would seem to result in a distraction for the community and ARIN in dealing with legacy holders of IPv4 space, would seem to have operationally negative consequences, and does nothing to move forward with IPv6. Opposed. Gary From jlewis at lewis.org Mon Feb 14 22:49:52 2011 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 14 Feb 2011 22:49:52 -0500 (EST) Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <79D61AC7-6378-4A58-8272-B18F9F7AA87E@arin.net> References: <4D595D12.4000602@arin.net> <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> <784247EC-6BE8-4764-8D7D-49C4E3C9ADB2@arin.net> <25E5FE8D-E376-497E-AE03-34571B987683@queuefull.net> <79D61AC7-6378-4A58-8272-B18F9F7AA87E@arin.net> Message-ID: ARIN-prop-133 seems like either an attempt to get legacy holders to sign a RSA, or a ploy to create a new business (legacy assignment registrar), or the prelude to an legacy IPv4 "land grab." Either way, it seems like a bad idea and a waste of everyone's time. The last thing we need is whois data ("ownership") of legacy IPv4 space muddied further by ARIN purging their data, and then others scrambling to get their (or someone else's) legacy assignments documented at some other registry. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hannigan at gmail.com Tue Feb 15 00:24:56 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 15 Feb 2011 00:24:56 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: <4D59DCB6.3010400@umn.edu> References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> <412C1E7F-0094-441E-9A1E-0EFBDD1472B2@delong.com> <4D59DCB6.3010400@umn.edu> Message-ID: On Mon, Feb 14, 2011 at 8:53 PM, David Farmer wrote: > On 2/14/11 15:03 CST, Martin Hannigan wrote: >> >> On Mon, Feb 14, 2011 at 3:32 PM, Benson Schliesser [ clip ] >> Here's what the text actually says: >> >> "5.1 Returned Legacy Addresses >> >> Legacy IPv4 addresses returned to or recovered by ARIN will be made >> available for registration and distribution in the ARIN region within >> thirty days of their receipt." >> >> There's no argument here that once an address is added to ARIN's >> inventory it's a done deal. The proposal doesn't seek to do otherwise >> nor does the language imply that it would. >> [ clip ] >> All that this proposal does is codify the instruction to return these >> addresses to ARIN inventory and use them. The current situation is >> ambiguous and open to interpretation. This has nothing to do with the >> IANA at all. In fact, in the absence of a global policy, this simply >> makes the instruction "use the addresses". >> >> With regards to accepting legacy addresses from entities "only" in the >> ARIN region, I think that's a fair point and will put it on the list >> of final modifications. > > By my interpretation your text does one additional thing than what you state > above, it specifics that ARIN does this within 30 days, where I believe the > current operational practice is 6 months. ?Do I interpret your intention > correctly? ?If you believe I'm interpreting that wrong, please explain. David, I think that the text is clear: "within thirty days of their receipt."" > It is this apparent change in operational practice that I believe has many > people concerned, and asking why this policy should only apply to Legacy > space. Who has these concerns and what are their basis? My understanding and experience is that addresses are held for six months for reasons related to filtering. Bogons are less likely a problem with legacy addresses, not more. As exhaustion presses on, filtering (routes, RBL's) will likely become less of an issue. There are going to be much bigger things to be concerned about as exhaustion presses on. Best, -M< From matthew at matthew.at Tue Feb 15 01:30:52 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 14 Feb 2011 22:30:52 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: <4D5A1D9C.3060004@matthew.at> On 2/14/2011 1:45 PM, Jeffrey Lyon wrote: > > Specific to this proposition, I find it fundamentally flawed that I > have to pay for something that another receives for free merely > because they got in first. > You think that's bad... in a few months it will be "fundamentally flawed" that everyone who already has an IPv4 allocation from ARIN has one, and those who didn't get in before they ran out can't get one from ARIN at *any* price. Matthew Kaufman From matthew at matthew.at Tue Feb 15 01:37:33 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Mon, 14 Feb 2011 22:37:33 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <40d20abc721782d45dcaabcafa703b204d59aadf@jcc.com> Message-ID: <4D5A1F2D.70108@matthew.at> On 2/14/2011 4:06 PM, Jeffrey Lyon wrote: > > I have no ill will toward legacy holders and I completely understand > that the actual cost of providing free services is negligible. My > concern is more principle in nature. If someone is operating IP > resources in the ARIN region they should be compelled to pay the same > fees that we all must pay and follow the rules that we all must > follow. This proposal would begin to achieve that result. There's really two classes of legacy holders... The first is entities that have legacy addresses but also have had significant address requirements since the formation of ARIN. Most of them are probably paying as much as they would be if their legacy space was counted towards their total holdings. The second is entities that have legacy addresses and have had no additional requirements for hands-on services from ARIN since the formation of ARIN. Until this proposal there has been no suggestion that these entities should be charged (unless they wish to enter into an LRSA) and no statement from ARIN that the cost of providing the limited services (rdns, whois) justifies trying to change things. Does the existence of the second class really get under your skin so much that all the other negatives of the proposed policy are justified? Matthew Kaufman From dwcarder at wisc.edu Tue Feb 15 00:59:22 2011 From: dwcarder at wisc.edu (Dale W. Carder) Date: Mon, 14 Feb 2011 23:59:22 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <1110214150225.31932B-100000@Ives.egh.com> References: <1110214150225.31932B-100000@Ives.egh.com> Message-ID: <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> On Feb 14, 2011, at 2:08 PM, John Santos wrote: > On Mon, 14 Feb 2011, ARIN wrote: > > 4) What is the point of this? > > I'm against. Also opposed. This proposal does not appear to encourage the proper stewardship of this dataset. Dale From bensons at queuefull.net Tue Feb 15 03:24:58 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 15 Feb 2011 02:24:58 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> Message-ID: <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> On Feb 14, 2011, at 11:59 PM, Dale W. Carder wrote: > Also opposed. This proposal does not appear to encourage the > proper stewardship of this dataset. So, do you believe the current approach is proper stewardship? I rather think that pruning questionable data is a better practice than leaving it in the Whois. We can debate the specifics of implementing such a practice, but I'm interested in whether you (dis)agree fundamentally with that approach to data management. Cheers, -Benson From bensons at queuefull.net Tue Feb 15 03:46:18 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 15 Feb 2011 02:46:18 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> Message-ID: On Feb 14, 2011, at 9:41 PM, Gary Buhrmaster wrote: > On Mon, Feb 14, 2011 at 13:48, Benson Schliesser wrote: >> >> On Feb 14, 2011, at 3:41 PM, Keith W. Hare wrote: >> >>> My interest in maintaining the status quo for legacy resources is that the system currently works. Unless a change is going to be a large benefit to the internet community, what is the point of changing? >> >> IPv4 exhaustion is a change that won't benefit the Internet community*, but it's happening. We really can't expect the status quo to be maintained forever. >> >> Cheers, >> -Benson >> >> * - Well, not in the short-term at least. Once we have critical mass of IPv6, I think it will benefit us all... But that's a different discussion. > > While I am not as optimistic about the dates of critical mass > of IPv6 adoption as some in the community, I see little reason > to invest efforts in ARIN IPv4 policy at this point unless there > is a clear benefit to the community in the migration to IPv6. > This policy proposal would seem to result in a distraction for > the community and ARIN in dealing with legacy holders of > IPv4 space, would seem to have operationally negative > consequences, and does nothing to move forward with IPv6. > Opposed. Thanks for this feedback. It is a sentiment I've heard from others, over the past year or two. And it deserves some credit for emphasizing and promoting IPv6. However, I disagree; I think such a view ignores the present reality, in which IPv4 is the dominant network protocol. I would be shocked to learn of anybody, who is responsible for a production Internet-connected network, that is willing to return all of their IPv4 addresses and rely completely on IPv6 at this time. I hope we get to that point in the near future. But between now and then, we have a need for both protocols. Given that the need currently exists, and given that the RIR supply is almost exhausted, it is my opinion that we should implement policies to more effectively manage IPv4 numbers during the transition period. If we don't, then new networks may find it impossible to acquire needed IPv4 resources, while existing networks hold idle resources with no incentive to share them. Further, the gap between those with excess supply and those with unfulfilled need is ripe for exploitation, and change is happening whether we prepare for it or not. In other words, IPv6 transition will happen for its own reasons; we don't need to further break IPv4 in order to encourage it. Cheers, -Benson From bensons at queuefull.net Tue Feb 15 04:12:02 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 15 Feb 2011 03:12:02 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <79D61AC7-6378-4A58-8272-B18F9F7AA87E@arin.net> References: <4D595D12.4000602@arin.net> <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> <784247EC-6BE8-4764-8D7D-49C4E3C9ADB2@arin.net> <25E5FE8D-E376-497E-AE03-34571B987683@queuefull.net> <79D61AC7-6378-4A58-8272-B18F9F7AA87E@arin.net> Message-ID: Hi, John. On Feb 14, 2011, at 9:40 PM, John Curran wrote: > When ARIN was created, on its first day of operation, it had only > "legacy allocations". > ... > After the IANA function was contracted to ICANN by the US Dept of > Commerce (the current contracting agency for these tasks), the RIRs > and ICANN entered into an agreement whereby the RIRs would serve the > function of of ICANN's Address Supporting Organization, responsible > for "global number resource policy development". Thanks for this feedback. I'm happy to report that my understanding of history is in-line with the events you have described. However, I would be interested in your comments on the current relationship between ARIN and IANA/ICANN. Specifically, I gather that the NRO has proposed a framework that was only partially acknowledged by IANA, and that IANA has asked for a legal contract that has never materialized. Are there any actual commitments in-force? Does anything guarantee that ARIN will continue to have a role in IANA policy creation, or even recognition by IANA? > In your proposal, > you might consider some way to reconcile acknowledging ICANN/IANA's > policy authority while not acknowledging the NRO/RIR policy authority > without contradicting the RIRs serving under agreement as ICANN's > policy body for Internet number resources. I believe that would > significantly strengthen the policy proposal if that is your goal. If I understand the root of your comment, it is that: IANA has delegated responsibility* for IP number policy to the NRO. Effectively this creates a circular dependency in which the IANA is comprised of the RIRs, and the RIRs are subject to IANA, etc. Even if that is the case, I'm not sure I see how proposal 133 needs to be reconciled. IANA still has some authority as an institution, even if the IANA policy is formulated by the RIRs (via NRO/ASO), and the policy proposal recognizes that authority in determining legitimate address holders etc. Granted, we might compare the present situation to one asking themselves for permission... But I don't understand how this leads to your suggestion. Do I misunderstand, and/or can you clarify? Thanks, and Cheers, -Benson * - Who can blame ICANN for delegating IANA responsibility, when they're so busy creating TLDs? How can they possibly have time for IANA? But that is a different topic, I suppose... -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Feb 15 06:30:47 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 11:30:47 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <4D595D12.4000602@arin.net> <2C83E876-EBDD-4E27-9F81-0EF67B39E062@arin.net> <00DE3CA9-308C-44C2-8DE8-06D15441658E@queuefull.net> <784247EC-6BE8-4764-8D7D-49C4E3C9ADB2@arin.net> <25E5FE8D-E376-497E-AE03-34571B987683@queuefull.net> <79D61AC7-6378-4A58-8272-B18F9F7AA87E@arin.net> Message-ID: <94EA2B61-94A6-460E-B435-CBE65DDF99D6@arin.net> On Feb 15, 2011, at 4:12 AM, Benson Schliesser wrote: ... After the IANA function was contracted to ICANN by the US Dept of Commerce (the current contracting agency for these tasks), the RIRs and ICANN entered into an agreement whereby the RIRs would serve the function of of ICANN's Address Supporting Organization, responsible for "global number resource policy development". Thanks for this feedback. I'm happy to report that my understanding of history is in-line with the events you have described. However, I would be interested in your comments on the current relationship between ARIN and IANA/ICANN. Specifically, I gather that the NRO has proposed a framework that was only partially acknowledged by IANA, and that IANA has asked for a legal contract that has never materialized. Are there any actual commitments in-force? Does anything guarantee that ARIN will continue to have a role in IANA policy creation, or even recognition by IANA? The ASO and NRO MOU's are at www.nro.net, and signed by all parties; I am unaware of any requests for changes from IANA/ICANN or the NRO. FYI - RFC 2860 is also applicable, as it notes that the IAB/IESG (of IETF) has significant authority in these matters, but agrees that certain technical IANA tasks regarding operation of registries may be actually be performed by ICANN. Regarding guarantees of the future, there are none, nor should there necessarily be any such guarantees, as the system works because of multiple cooperating entities (IANA/ICANN, IAB/IETF/ISOC, NRO/RIRs) none of which attempt to claim autonomous authority but instead must each cooperate with the others to perform appropriately and confirm its value to the overall ecosystem. It might not be how others would set things up, but we have existence proof in the Internet that the model is rather successful. In your proposal, you might consider some way to reconcile acknowledging ICANN/IANA's policy authority while not acknowledging the NRO/RIR policy authority without contradicting the RIRs serving under agreement as ICANN's policy body for Internet number resources. I believe that would significantly strengthen the policy proposal if that is your goal. If I understand the root of your comment, it is that: IANA has delegated responsibility* for IP number policy to the NRO. Effectively this creates a circular dependency in which the IANA is comprised of the RIRs, and the RIRs are subject to IANA, etc. No, my point is that you indicate that the IANA/ICANN policy should be recognized, that the RIR policy should not, despite the fact that the RIR policy *is* IANA/ICANN policy by ICANN's own bylaws and agreements. You literally have a non-sequiter embedded in the proposal, one that cannot be reconciled without deciding that there is no policy that applicable, including USG/DoC/NTIA, IAB/IESG, IANA/ICANN or the RIRs... FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From JOHN at egh.com Tue Feb 15 08:49:42 2011 From: JOHN at egh.com (John Santos) Date: Tue, 15 Feb 2011 08:49:42 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks Message-ID: <1110215084143.31932G-100000@Ives.egh.com> Resending my whinge because the mailing list software may have eaten it... On Mon, 14 Feb 2011, someone wrote: > The email to which you refer was not included, but I'd be curious to see > it... > It was listed as an attachment when I sent it. Maybe it got filtered by the mailing list software? I'll try to attach it again. Extracted the plain-text version and inserted inline here: -------------------- Mr. Santos, Please accept my apologies for the intrusion to your recent posting regarding the proposed new ARIN Policy titled No Volunteer Services on Behalf of Unaffiliated Address Blocks. While on the surface it may appear to be a negative proposal for legacy holders of IPv4 number blocks, I can assure you it is actually quite the opposite for it frees them once and for all from ARIN's illusionary claims. We, as the first commercial IP Address Internet Registry which only provides post-allocation services to legacy block holders, are fully supportive of this proposal. If you have any questions please contact me and we can either discuss this or continue a dialogue. If you are interested, our services are clearly provided for at www.depository.net Best regards, Peter Thimmesch Chairman +1 703.871.4822 (o) +1 202.957.5805 (m) Description: Description: Description: Description: depository_PPTGRPHCLOGO 1775 Wiehle Avenue Suite 400 Reston, VA 20190 USA __________________________________________________ -------------------- There was also an html version and a graphic which I think was just a logo. > On 2/14/2011 6:30 PM, John Santos wrote: > > Shortly after I made my initial response to prop 133, I recieved this > > email. > > > > 1) Do I understand it correctly? Are these people offering to sell me > > the RDNS and WHOIS service I currently receive from ARIN for free? > > > > 2) Is this proposal a Trojan Horse for an attempt to unilateraly > > privitize ARIN? > > > > 3) Is it an attempt to get an unregulated (i.e. not need-based) market > > in under the radar? > > > > Is the "illusionary claim" it purports to free me from the prohibition > > against selling my (unroutable, most likely) Class C to the highest > > bidder? Not that I would do that in any case, because I'm pretty sure > > when I obtained it from the InterNIC in 1993, it was clear that the > > assignment was based on need and if we didn't need it any more, we > > were supposed to return it. > > > > In any case, it would cost in the 5 digits for us to renumber > > and coordinate with all our network partners (firewalls, VPNs, etc.) > > not to mention future costs due to no longer having globally unique > > address space, selling is a definite non-starter even if was otherwise > > acceptable. > > > > 4) Is this email a violation of the ARIN PPML acceptable use policy > > due to being SPAM? > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at arin.net Tue Feb 15 09:24:19 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 14:24:19 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <1110215084143.31932G-100000@Ives.egh.com> References: <1110215084143.31932G-100000@Ives.egh.com> Message-ID: <0D4E06C1-8D33-4FC9-ABB4-E1DFEB628967@corp.arin.net> John - Despite the solicitation for services, it appears that the principal intent of using your email from the PPML list was discussion of the the policy proposal. I'd prefer you not report this as a violation of the ARIN Mailing List AUP and instead direct Mr. Thimmesch to join in the public discussion of the proposal on the PPML mailing list. Thanks! /John John Curran President and CEO ARIN On Feb 15, 2011, at 8:49 AM, John Santos wrote: > Resending my whinge because the mailing list software may have eaten it... > On Mon, 14 Feb 2011, someone wrote: >> The email to which you refer was not included, but I'd be curious to see it... > > It was listed as an attachment when I sent it. Maybe it got filtered > by the mailing list software? I'll try to attach it again. > > Extracted the plain-text version and inserted inline here: > -------------------- > > Mr. Santos, > > Please accept my apologies for the intrusion to your recent posting > > regarding the proposed new ARIN Policy titled No Volunteer Services on > Behalf of Unaffiliated Address Blocks. While on the surface it may appear to > be a negative proposal for legacy holders of IPv4 number blocks, I can > assure you it is actually quite the opposite for it frees them once and for > all from ARIN's illusionary claims. We, as the first commercial IP Address > Internet Registry which only provides post-allocation services to legacy > block holders, are fully supportive of this proposal. If you have any > questions please contact me and we can either discuss this or continue a > dialogue. > > If you are interested, our services are clearly provided for at > www.depository.net > > Best regards, > Peter Thimmesch > > Chairman > > +1 703.871.4822 (o) > +1 202.957.5805 (m) From farmer at umn.edu Tue Feb 15 09:45:56 2011 From: farmer at umn.edu (David Farmer) Date: Tue, 15 Feb 2011 08:45:56 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: <4D5A91A4.804@umn.edu> On 2/15/11 02:24 CST, Benson Schliesser wrote: > > On Feb 14, 2011, at 11:59 PM, Dale W. Carder wrote: > >> Also opposed. This proposal does not appear to encourage the >> proper stewardship of this dataset. > > > So, do you believe the current approach is proper stewardship? I believe there were definitely issues with the old approach, which I will summarize as "you leave us alone and we'll leave you alone." Note, that was a two way street, I believe it was critically important for the Legacy Holders to leave ARIN more or less alone to form itself, and do the job it has done for more than 10 years and to create the next phase of the Internet. Dealing with the "Legacy Issue" to early in ARIN's history may have not been a good thing for ARIN. There was a lot of contention over the Legacy resources at the creation of ARIN and the old approach was a practical solution that allowed the Internet to move forward and become what it is today. But I say "old approach" because, there has been a number of significant changes made over the past 3 years to modify that old approach; 1. The creation and evolution of the Legacy RSA, this took a year to 18 months to evolve more or less into what we have now. 2. Policy 2007-17: Legacy Outreach and Partial Reclamation 3.. The creation of the transfer policy, as a response to IPv4 exhaustion, 4. Policy 2008-7: Identify Invalid WHOIS POC?s 5. And now Draft Policy 2011-2 Protecting Number Resources, which should reclaim abandoned resources now that we have made a first cut at identifying with 2008-7. Did the ARIN community wait to long to start dealing with the "Legacy Issue"? Probably. Is it taking to long? Probably. But, Legacy resources holders are not to blame for that, the entire ARIN community is. > I rather think that pruning questionable data is a better practice than leaving it in the Whois. I agree, however I believe it is the technical stewardship of the data we are looking to reinforce, not the financial stewardship of the organization. No one seems to think that the later is an issue. Your approach seems to focus on the later and probably damages the former. > We can debate the specifics of implementing such a practice, but I'm interested in whether you (dis)agree fundamentally with that approach to data management. I prefer moving forward along the lines of 2011-2, I'm not sure it is the right policy text yet, but I think it is the right direction. You seem to have an issue with the Legacy resource holders getting a "free ride". Have you ever considered how much many of the Legacy resource holders spent in creating the Internet in the first place? Especially in the early 90s when federal grant dollars were only a fraction of the total dollars spent on the Internet. Who is really getting the free ride? But, the money issue is more or less irrelevant anyway. The issue should be the technical stewardship of the resources. Is more work still needed yes, but I'm not convinced proposal 133 helps the situation more than it hurts it. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From hannigan at gmail.com Tue Feb 15 11:04:20 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 15 Feb 2011 11:04:20 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Tue, Feb 8, 2011 at 2:04 PM, John Curran wrote: > On Feb 8, 2011, at 2:27 PM, Martin Hannigan wrote: >> I think you have it backwards, Bill. Commissions are orthogonal, the >> LRSA is a roadblock. > > Martin - > > The LRSA may be a roadblock depending on your particular goal. From > your prior message, you propose three major areas for change: It's not my goal, it's a goal of the members/community to figure out a better way. From the thread, and now a proposal discussion as well, we have some consensus that what we have now is not optimal. > > ?A. Need for a "mutual termination"/"walk away" option > ?B. Need to be obligated to comply only with WHOIS-related policies > ?B. Need for favorable fees and inclusion of ARIN membership > > ?(My summary, apologizes if I missed anything major...) > > With respect to "B", are you proposing that the currently adopted > transfer policies not apply to legacy holders who enter an LRSA, > or only that the policy set (other than for WHOIS policies) not > change for them once they have entered into agreement? > I didn't answer this question since I wanted to think about it. The unfortunate answer here is that transfer policy already doesn't apply to legacy holders from their perspective so hoping that they will sign an agreement seems less than efficient. I don't think that they should sign an agreement at all if we are able to get some benefits from it hence I think that Benson's proposal is interesting and probably worth further development. Best, -M< From owen at delong.com Tue Feb 15 12:01:13 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Feb 2011 09:01:13 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D5A91A4.804@umn.edu> References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> <4D5A91A4.804@umn.edu> Message-ID: On Feb 15, 2011, at 6:45 AM, David Farmer wrote: > On 2/15/11 02:24 CST, Benson Schliesser wrote: >> >> On Feb 14, 2011, at 11:59 PM, Dale W. Carder wrote: >> >>> Also opposed. This proposal does not appear to encourage the >>> proper stewardship of this dataset. >> >> >> So, do you believe the current approach is proper stewardship? > > I believe there were definitely issues with the old approach, which I will summarize as "you leave us alone and we'll leave you alone." Note, that was a two way street, I believe it was critically important for the Legacy Holders to leave ARIN more or less alone to form itself, and do the job it has done for more than 10 years and to create the next phase of the Internet. Dealing with the "Legacy Issue" to early in ARIN's history may have not been a good thing for ARIN. There was a lot of contention over the Legacy resources at the creation of ARIN and the old approach was a practical solution that allowed the Internet to move forward and become what it is today. > > But I say "old approach" because, there has been a number of significant changes made over the past 3 years to modify that old approach; > > 1. The creation and evolution of the Legacy RSA, this took a year to 18 months to evolve more or less into what we have now. > > 2. Policy 2007-17: Legacy Outreach and Partial Reclamation > > 3.. The creation of the transfer policy, as a response to IPv4 exhaustion, > > 4. Policy 2008-7: Identify Invalid WHOIS POC?s > > 5. And now Draft Policy 2011-2 Protecting Number Resources, which should reclaim abandoned resources now that we have made a first cut at identifying with 2008-7. > > Did the ARIN community wait to long to start dealing with the "Legacy Issue"? Probably. Is it taking to long? Probably. But, Legacy resources holders are not to blame for that, the entire ARIN community is. > Even with those changes, I'm not convinced that the current approach (which I will term "can't we all just get along" rather than "you leave us alone, we'll leave you alone") needs changing. In all reality, the "legacy issue" is really akin to much ado about nothing. First, even if we were to hold legacy users to current policy standards for utilization and reclaim every last drop of IPv4 possible, the process would take longer than IPv4 will probably matter in order to complete and there isn't that much space to be reclaimed compared to current consumption rates. A few months at best. A multi-year effort simply isn't sensible. Second, there are no legacy IPv6 registrations, so, with the transition of IPv4 from active global protocol to islands of antiquated usage, the whole thing becomes moot. That transition will probably happen faster than any major reclamation effort could complete. The highest $/address in the ARIN fee structure works out to roughly $1.22 per registered address. The largest annual fee paid by end-users is less than $0.50 per registered address. Trying to inflict fees onto legacy holders through any involuntary process will easily cost more in legal fees than ARIN has any hope of ever actually collecting from them. Given all of these facts, I'm all for cleaning up the data with effective gentle pruning, but, an all out assault on legacy holders or the fracturing of the registry system is neither good stewardship, nor a good use of time and resources. In short, while this proposal may appear to be a rearranging of the deck chairs at best, in truth, it is more like sabotaging the life boats. Owen From cgrundemann at gmail.com Tue Feb 15 12:50:58 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 15 Feb 2011 10:50:58 -0700 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: On Tue, Feb 15, 2011 at 01:24, Benson Schliesser wrote: > > So, do you believe the current approach is proper stewardship? ?I rather think that pruning questionable data is a better practice than leaving it in the Whois. ?We can debate the specifics of implementing such a practice, but I'm interested in whether you (dis)agree fundamentally with that approach to data management. Updating and verifying Whois data is the best practice. Deleting "questionable" data is a step backwards. Defaulting to not having data is a worst-case scenario. This proposal (specifically section 13.1) is absolutely not going to advance Whois data accuracy and will likely cause serious damage to it. Going a step further, are there really legacy address holders out there who are upset about receiving free services from ARIN? Barring that, I do not understand the problem that section 13.1 is trying to solve. If there are, it would be nice to hear from them here. And, even if there are, the community is best served by accurate Whois data so their argument against participating would have to be compelling indeed to make this idea palatable at all. Once you eliminate 13.1, this proposal reads like an attempt to update the transfer policy. If that is indeed a goal of this proposal; I suggest further review of the current specified transfer policy (https://www.arin.net/policy/nrpm.html#eight3), and a simplification of the current proposal language. Cheers, ~Chris > > Cheers, > -Benson > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From george.herbert at gmail.com Tue Feb 15 13:22:46 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 15 Feb 2011 10:22:46 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: On Tue, Feb 15, 2011 at 12:24 AM, Benson Schliesser wrote: > So, do you believe the current approach is proper stewardship? Perhaps not, but you seem to have started by asserting some things that you haven't provided evidence or supporting arguments for. >I rather think that pruning questionable data is a better practice than leaving it in the Whois. ?We can debate the specifics of implementing such a practice, but I'm interested in whether you (dis)agree fundamentally with that approach to data management. Please start by explaining which data you find to be "questionable" and how. Policy should flow from identified and articulated problems which are commonly agreed to be genuine and significant. -- -george william herbert george.herbert at gmail.com From jcurran at arin.net Tue Feb 15 13:24:07 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 18:24:07 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Feb 15, 2011, at 11:04 AM, Martin Hannigan wrote: > > I didn't answer this question since I wanted to think about it. The > unfortunate answer here is that transfer policy already doesn't apply > to legacy holders from their perspective so hoping that they will sign > an agreement seems less than efficient. The transfer policy applies to all resources in ARIN's Whois Database. If you are aware of an attempt to contravene number resource policy, please submit a fraud report here: and we'll take care of it. Thanks! /John John Curran President and CEO ARIN From bensons at queuefull.net Tue Feb 15 13:28:46 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 15 Feb 2011 12:28:46 -0600 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: <5DDA3B66-9938-4F8F-98B1-B82601078558@queuefull.net> On Feb 15, 2011, at 12:24 PM, John Curran wrote: > On Feb 15, 2011, at 11:04 AM, Martin Hannigan wrote: >> >> I didn't answer this question since I wanted to think about it. The >> unfortunate answer here is that transfer policy already doesn't apply >> to legacy holders from their perspective so hoping that they will sign >> an agreement seems less than efficient. > > The transfer policy applies to all resources in ARIN's Whois Database. > If you are aware of an attempt to contravene number resource policy, > please submit a fraud report here: > and we'll take care of it. In case I haven't been clear about this point: the above statement is my primary motivation for submitting proposal 133. Cheers, -Benson From hannigan at gmail.com Tue Feb 15 13:30:34 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 15 Feb 2011 13:30:34 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Tue, Feb 15, 2011 at 1:24 PM, John Curran wrote: > On Feb 15, 2011, at 11:04 AM, Martin Hannigan wrote: >> >> I didn't answer this question since I wanted to think about it. The >> unfortunate answer here is that transfer policy already doesn't apply >> to legacy holders from their perspective so hoping that they will sign >> an agreement seems less than efficient. > > The transfer policy applies to all resources in ARIN's Whois Database. > If you are aware of an attempt to contravene number resource policy, > please submit a fraud report here: > and we'll take care of it. > I would, but it appears that we're all disconnected as to what fraud with respect to legacy resources actually is: https://www.arin.net/resources/fraud/results/third_quarter_2010.html Best, -M< From bensons at queuefull.net Tue Feb 15 13:34:42 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 15 Feb 2011 12:34:42 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <44A83763-ACAB-4519-846D-5B64E380E7A5@queuefull.net> <4D599A5C.6060807@accessline.com> Message-ID: <940F4655-C528-4827-88D6-1F3B2A22D2E0@queuefull.net> On Feb 14, 2011, at 3:44 PM, John Curran wrote: > On Feb 14, 2011, at 4:10 PM, Dan Pinkard wrote: >> It seems like taking away the baby's rattle is a good step, but not that way. What other means are available to motivate organizations to bring legacy space under the LRSA that don't cause other problems? If we're loking at the larger picture of parceling out unused or underutilized IPv4 space, is there a way ARIN can ease those needs in trade? (Is there a desire to help or harm that?) > > I do not believe that the intent of this particular policy proposal is to > encourage legacy holders to enter into an LRSA agreement with ARIN, but > Benson can better address his actual intent with the policy proposal. John is essentially right: I'm not trying to motivate legacy holders into the LRSA, but I am trying to make it clear that ARIN won't include legacy resources in the Whois database without the holder's consent. Of course, entering into a LRSA is one way to express consent, but ARIN could devise other mechanisms if desired. Cheers, -Benson From jcurran at arin.net Tue Feb 15 13:37:34 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 18:37:34 +0000 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Feb 15, 2011, at 1:30 PM, Martin Hannigan wrote: >> The transfer policy applies to all resources in ARIN's Whois Database. >> If you are aware of an attempt to contravene number resource policy, >> please submit a fraud report here: >> and we'll take care of it. >> > > I would, but it appears that we're all disconnected as to what fraud > with respect to legacy resources actually is: > > https://www.arin.net/resources/fraud/results/third_quarter_2010.html Could you elaborate? We've been improving the reporting, but certainly need additional feedback regarding this process. /John John Curran President and CEO ARIN From tedm at ipinc.net Tue Feb 15 13:55:11 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 15 Feb 2011 10:55:11 -0800 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: <4D5ACC0F.8060600@ipinc.net> John and Martin, John, I think one possible difficulty on the fraud issue is that unlike both the civil and criminal justice system (in the united states, at any rate) none of the fraud proceedings are public. If someone submits fraud evidence or even a strong suspicion based on research in the whois database + direct experience, is there feedback? Are they included in the investigation? If there is wrongdoing discovered are they informed of any punishments meted out? Without this, it is understandable that people would feel fraud reports are going into a black hole - and the lack of publicity also does not create examples of what is and what isn't allowed. Most human beings learn by example. Martin, keep in mind that ARIN has no legal contract between it and a true "Legacy" resource holder as they never signed anything with them, and ARIN is not a governmental body. It thus has little ability to bring proceedings against a legacy holder who is violating ARIN's NRPM Ted On 2/15/2011 10:37 AM, John Curran wrote: > > On Feb 15, 2011, at 1:30 PM, Martin Hannigan wrote: > >>> The transfer policy applies to all resources in ARIN's Whois Database. >>> If you are aware of an attempt to contravene number resource policy, >>> please submit a fraud report here: >>> and we'll take care of it. >>> >> >> I would, but it appears that we're all disconnected as to what fraud >> with respect to legacy resources actually is: >> >> https://www.arin.net/resources/fraud/results/third_quarter_2010.html > > Could you elaborate? We've been improving the reporting, but certainly > need additional feedback regarding this process. > > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bensons at queuefull.net Tue Feb 15 14:18:19 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 15 Feb 2011 13:18:19 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: On Feb 15, 2011, at 11:50 AM, Chris Grundemann wrote: > Going a step further, are there really legacy address holders out > there who are upset about receiving free services from ARIN? Barring > that, I do not understand the problem that section 13.1 is trying to > solve. If there are, it would be nice to hear from them here. And, > even if there are, the community is best served by accurate Whois data > so their argument against participating would have to be compelling > indeed to make this idea palatable at all. There are legacy holders with concern, not because the services are free, but because they are subjected to governance without their consent. It would not be appropriate for me to speak more specifically on their behalf. I, too, would like to see legacy holders communicate their perspective here. But given the legal perspective that some of them have toward ARIN, I unfortunately doubt they will participate in this community. (And I would be glad for somebody to prove me wrong on this point.) > Once you eliminate 13.1, this proposal reads like an attempt to update > the transfer policy. If that is indeed a goal of this proposal; I > suggest further review of the current specified transfer policy > (https://www.arin.net/policy/nrpm.html#eight3), and a simplification > of the current proposal language. In fact, I am currently drafting a proposal to update the specified transfer policy. I think you are correct in seeing the relationship between prop 133 and the transfer policy, because restrictions on transfer is one of the issues faced by legacy holders. But prop 133 deals with the case where legacy holders don't wish to rely on ARIN for transfer at all. We should improve the specified transfer policy to be more accommodating, but even then we have to decide whether ARIN is correct to enforce policy without consent. Cheers, -Benson From owen at delong.com Tue Feb 15 14:16:07 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Feb 2011 13:16:07 -0600 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: John, I suggest that the term fraud is detracting from the purpose of the report. Perhaps an ARIN policy violation report would be more useful. Owen Sent from my iPad On Feb 15, 2011, at 12:30 PM, Martin Hannigan wrote: > On Tue, Feb 15, 2011 at 1:24 PM, John Curran wrote: >> On Feb 15, 2011, at 11:04 AM, Martin Hannigan wrote: >>> >>> I didn't answer this question since I wanted to think about it. The >>> unfortunate answer here is that transfer policy already doesn't apply >>> to legacy holders from their perspective so hoping that they will sign >>> an agreement seems less than efficient. >> >> The transfer policy applies to all resources in ARIN's Whois Database. >> If you are aware of an attempt to contravene number resource policy, >> please submit a fraud report here: >> and we'll take care of it. >> > > I would, but it appears that we're all disconnected as to what fraud > with respect to legacy resources actually is: > > > https://www.arin.net/resources/fraud/results/third_quarter_2010.html > > > Best, > > -M< > _______________________________________________ > 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 Feb 15 14:27:14 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 19:27:14 +0000 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: <4D5ACC0F.8060600@ipinc.net> References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> Message-ID: On Feb 15, 2011, at 1:55 PM, Ted Mittelstaedt wrote: > John, I think one possible difficulty on the fraud issue is that unlike > both the civil and criminal justice system (in the united states, at any > rate) none of the fraud proceedings are public. > > If someone submits fraud evidence or even a strong suspicion based on > research in the whois database + direct experience, is there feedback? A fraud report results in a NRPM 12 resource review, and the address holder is an integral part of the review process. > Are they included in the investigation? If there is wrongdoing discovered > are they informed of any punishments meted out? Without this, it is > understandable that people would feel fraud reports are going into a black > hole - and the lack of publicity also does not create examples of what is > and what isn't allowed. Most human beings learn by example. The resource holder is informed of any action, and we produce summary reports for the community on the fraud reporting page. > Martin, keep in mind that ARIN has no legal contract between it and > a true "Legacy" resource holder as they never signed anything with them, > and ARIN is not a governmental body. It thus has little ability to bring > proceedings against a legacy holder who is violating ARIN's NRPM No proceedings are necessary to correct entries in the ARIN Whois database. /John John Curran President and CEO ARIN From tedm at ipinc.net Tue Feb 15 14:50:02 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 15 Feb 2011 11:50:02 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: <4D5AD8EA.4050001@ipinc.net> On 2/15/2011 11:18 AM, Benson Schliesser wrote: > > On Feb 15, 2011, at 11:50 AM, Chris Grundemann wrote: > >> Going a step further, are there really legacy address holders out >> there who are upset about receiving free services from ARIN? >> Barring that, I do not understand the problem that section 13.1 is >> trying to solve. If there are, it would be nice to hear from them >> here. And, even if there are, the community is best served by >> accurate Whois data so their argument against participating would >> have to be compelling indeed to make this idea palatable at all. > > There are legacy holders with concern, not because the services are > free, but because they are subjected to governance without their > consent. > Baloney. They are consenting to being governed by continuing to use the legacy IPv4 resources to connect to the rest of the Internet. Nobody is holding a gun to their head and telling them that they HAVE to continue to use those IPv4 resources. If they don't like being governed by ARIN without their consent then STOP USING the resources. The only value those resources have for them is to plug in to the rest of us who ARE being governed by ARIN, so to say that the RIR's stewardship of IPv4 could somehow be arranged to NOT affect their use of their IPv4 is pretty ridiculous. Ted > It would not be appropriate for me to speak more specifically on > their behalf. I, too, would like to see legacy holders communicate > their perspective here. But given the legal perspective that some of > them have toward ARIN, I unfortunately doubt they will participate in > this community. (And I would be glad for somebody to prove me wrong > on this point.) > >> Once you eliminate 13.1, this proposal reads like an attempt to >> update the transfer policy. If that is indeed a goal of this >> proposal; I suggest further review of the current specified >> transfer policy (https://www.arin.net/policy/nrpm.html#eight3), and >> a simplification of the current proposal language. > > > In fact, I am currently drafting a proposal to update the specified > transfer policy. > > I think you are correct in seeing the relationship between prop 133 > and the transfer policy, because restrictions on transfer is one of > the issues faced by legacy holders. But prop 133 deals with the case > where legacy holders don't wish to rely on ARIN for transfer at all. > We should improve the specified transfer policy to be more > accommodating, but even then we have to decide whether ARIN is > correct to enforce policy without consent. > > Cheers, -Benson > > > _______________________________________________ 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 Ed.Lewis at neustar.biz Tue Feb 15 15:12:49 2011 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Tue, 15 Feb 2011 15:12:49 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: At 13:18 -0600 2/15/11, Benson Schliesser wrote: >There are legacy holders with concern, not because the services are free, >but because they are subjected to governance without their consent. > >It would not be appropriate for me to speak more specifically on their behalf. Given these lines, I think then the policy proposal has been made for the wrong reasons. For one, there isn't any specific complaint coming from legacy holders, just speculation that they would be impacted. (If a legacy holder came forward and found grounds for a policy to remove their listing, that's another matter.) Thinking that legacy holders are completely free to do as they wish is false. For example, I (can only) believe they had to submit to being in WhoIs from the start. The conditions under which Postel assigned resources are just not well documented, the "strings attached" are unknown. It could be that all of the resources are reclaimable under some obscure interpretation of GFE (government furnished equipment) rules. This was mentioned by ARIN's legal council at a meeting a few years ago. OTOH, if the resources could legally be reclaimed, the disruption to the Internet may not be worth the tussle. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From arin-ppml at westbrook.com Tue Feb 15 15:58:03 2011 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Tue, 15 Feb 2011 13:58:03 -0700 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: On Tue, Feb 15, 2011 at 12:18, Benson Schliesser wrote: > It would not be appropriate for me to speak more specifically on their > behalf. I, too, would like to see legacy holders communicate their > perspective here. But given the legal perspective that some of them have > toward ARIN, I unfortunately doubt they will participate in this community. > (And I would be glad for somebody to prove me wrong on this point.) > That would be me, then, I guess. I have a single legacy /24 without LRSA, and I've piped up in here once or twice before. Happy to oblige. On Tue, Feb 15, 2011 at 13:12, Edward Lewis wrote: > For one, there isn't any specific complaint coming from legacy holders, > just speculation that they would be impacted. (If a legacy holder came > forward and found grounds for a policy to remove their listing, that's > another matter.) > Indeed, I cannot forsee ever making such a complaint. If this proposal intends to solve problems for legacy holders like me, it would seem void, as I also see no real problem to even solve. For example, I (can only) believe they had to submit to being in WhoIs from > the start. > Quite so. I don't recall it being a formal requirement, but it was definitely taken as understood. Happy to follow up further if desired. $0.02, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Tue Feb 15 16:39:08 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 15 Feb 2011 13:39:08 -0800 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: <4D5ACC0F.8060600@ipinc.net> References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> Message-ID: <4D5AF27C.40306@matthew.at> On 2/15/2011 10:55 AM, Ted Mittelstaedt wrote: > John and Martin, > > John, I think one possible difficulty on the fraud issue is that unlike > both the civil and criminal justice system (in the united states, at any > rate) none of the fraud proceedings are public. > > If someone submits fraud evidence or even a strong suspicion based on > research in the whois database + direct experience, is there feedback? The good news is that after pp 133, nobody will be *able* to do research in the whois database. Nor will ARIN be able to remove an entry from it based on the results. But I suppose once ARIN makes the address available for reassignment there can be *two* entities that believe that the address is theirs to use. Matthew Kaufman From marka at isc.org Tue Feb 15 16:43:00 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 16 Feb 2011 08:43:00 +1100 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: Your message of "Tue, 15 Feb 2011 15:12:49 CDT." References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: <20110215214300.71131A247F2@drugs.dv.isc.org> In message , Edward Lewis writes: > At 13:18 -0600 2/15/11, Benson Schliesser wrote: > > >There are legacy holders with concern, not because the services are free, > >but because they are subjected to governance without their consent. > > > >It would not be appropriate for me to speak more specifically on their behal > f. > Given these lines, I think then the policy proposal has been made for > the wrong reasons. For one, there isn't any specific complaint > coming from legacy holders, just speculation that they would be > impacted. (If a legacy holder came forward and found grounds for a > policy to remove their listing, that's another matter.) > > Thinking that legacy holders are completely free to do as they wish > is false. For example, I (can only) believe they had to submit to > being in WhoIs from the start. The conditions under which Postel > assigned resources are just not well documented, the "strings > attached" are unknown. It could be that all of the resources are > reclaimable under some obscure interpretation of GFE (government > furnished equipment) rules. This was mentioned by ARIN's legal > council at a meeting a few years ago. Yes. It was expected that legacy address holders would be listed in whois speaking as someone who got resourses pre-rir. > OTOH, if the resources could legally be reclaimed, the disruption to > the Internet may not be worth the tussle. > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434-5468 > > Me to infant son: "Waah! Waah! Is that all you can say? Waah?" > Son: "Waah!" > _______________________________________________ > 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From packetgrrl at gmail.com Tue Feb 15 16:53:10 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Tue, 15 Feb 2011 14:53:10 -0700 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: Further we have been asked on a number of occasions by law enforcement not to remove questionable data from whois. They insist that it's often better than nothing.. I forget which ARIN meeting it was but there was a presentation by some law enforcement folks regarding this very issue. I am sure the slides are around somewhere on the ARIN site. -----Cathy On Tue, Feb 15, 2011 at 10:50 AM, Chris Grundemann wrote: > On Tue, Feb 15, 2011 at 01:24, Benson Schliesser > wrote: > > > > So, do you believe the current approach is proper stewardship? I rather > think that pruning questionable data is a better practice than leaving it in > the Whois. We can debate the specifics of implementing such a practice, but > I'm interested in whether you (dis)agree fundamentally with that approach to > data management. > > > Updating and verifying Whois data is the best practice. Deleting > "questionable" data is a step backwards. Defaulting to not having data > is a worst-case scenario. This proposal (specifically section 13.1) is > absolutely not going to advance Whois data accuracy and will likely > cause serious damage to it. > > Going a step further, are there really legacy address holders out > there who are upset about receiving free services from ARIN? Barring > that, I do not understand the problem that section 13.1 is trying to > solve. If there are, it would be nice to hear from them here. And, > even if there are, the community is best served by accurate Whois data > so their argument against participating would have to be compelling > indeed to make this idea palatable at all. > > Once you eliminate 13.1, this proposal reads like an attempt to update > the transfer policy. If that is indeed a goal of this proposal; I > suggest further review of the current specified transfer policy > (https://www.arin.net/policy/nrpm.html#eight3), and a simplification > of the current proposal language. > > Cheers, > ~Chris > > > > > Cheers, > > -Benson > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Feb 15 17:13:58 2011 From: info at arin.net (ARIN) Date: Tue, 15 Feb 2011 17:13:58 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised Message-ID: <4D5AFAA6.10300@arin.net> The proposal originator submitted revised text. "Changes from Previous Version: Version 2 of this proposal removed section 13.2 so that it could be considered separately, in a new policy proposal submission. As a result, the remaining sections were renumbered to use an abstract system of "13.x" and "13.y", with the intent that actual sub-section numbers would be assigned later in the policy development process." Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-133: Volunteer Services on Behalf of Unaffiliated Address Blocks Proposal Originator: Benson Schliesser Proposal Version: 2 Date: 15 Feb 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.x. No Volunteer Services Except in the specific circumstances described by this policy, ARIN will not provide any services for any organization and/or address block. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. 13.x.1. Requested Services In the event that an organization explicitly requests registry services from ARIN for one or more specified address blocks, ARIN may provide the requested services, subsequent to execution of a service contract, for those address blocks. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. All address blocks that are assigned or allocated by ARIN under a valid RSA, as well as specific address blocks that are included under a Legacy RSA with the legitimate validated address holder, are deemed to have services requested for them. An organization requesting registry services for one or more specified address blocks, that also holds additional address blocks not specified in their request, is not obligated to receive registry services for those additional address blocks and those blocks are not deemed to have services requested for them. 13.x.2. Directory Placeholders For any address blocks, for which there are not fully executed ARIN service contracts, ARIN will create generic placeholder entries in the ARIN Whois directory. These placeholder entries will not specify organizational details, but will indicate that the entry represents a non-member resource. When applicable, each non-member resource placeholder will include a reference and/or RWhois referral to the authoritative directory service for that block, or the directory service operated by the IANA, or by another organization in the event that IANA has delegated their directory service responsibility to that organization. This does not apply to placeholders that represent an unassigned and unallocated address block delegated to ARIN by the IANA. 13.y. Permitted Updates to Directory Services for Unaffiliated Address Blocks Any organization that legitimately holds an address block, as defined by section 13.2 of this policy, may request the removal or modification of existing directory placeholders representing that address block. Valid requests for modification of placeholder entries are limited to references and/or RWhois referrals to authoritative directory services, such as directory services operated by or on behalf of the IANA, another address registry, or the address holder. In the event that such a request is received, ARIN may choose to either remove the placeholder entry or update it per the request. Rationale: Policy Background: This policy attempts to clarify the relationship that ARIN has with legacy address holders. Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical. This policy would require positive affirmation from any legacy address holder that wishes to receive registry services, moving to an "opt-in" approach. In the event that a legacy address holder does not opt-in to receive registry services, ARIN is limited to providing no more than a pointer (such as a RWhois referral) to an authoritative directory service for that holder's legacy address blocks. Pointers to other providers of directory services for addresses managed by those other providers continue to be permitted. Policy Structure: This policy introduces a new section to the NRPM, numbered section 13. Within this new section, there are two new sub-sections described in this proposal. Sub-section 13.x introduces policy that limits ARIN to providing services on an opt-in basis. It does make clear in 13.x.1 that services provided as part of a RSA or LRSA are automatically considered opted-in. With 13.x.2 it allows ARIN to create placeholders in the Whois database for blocks managed by other RIRs as well as for blocks managed (but unassigned/unallocated) by ARIN. Sub-section 13.y introduces policy enabling legitimate address holders to request a very limited update to any Whois placeholders that might exist for their legacy address block, so that the Whois will refer queries to the authoritative directory service. It is expected that ARIN will charge a fee for this update, but not require an ongoing services agreement. ARIN is given the option of deleting placeholders instead. Changes from Previous Version: Version 2 of this proposal removed section 13.2 so that it could be considered separately, in a new policy proposal submission. As a result, the remaining sections were renumbered to use an abstract system of "13.x" and "13.y", with the intent that actual sub-section numbers would be assigned later in the policy development process. Discussion: This proposal should not be interpreted as a "punishment" of legacy address holders or as an attempt to encourage execution of the LRSA. Rather, the intent of this proposal is to make it clear that ARIN will only provide services for organizations that wish to receive them. Put another way: this proposal would prohibit ARIN from forcing any organization to be listed in the ARIN Whois database without their consent. While it is not anticipated by this proposal's text, alternative forms of "request" are not prohibited by this policy proposal. Indeed, while the RSA and LRSA are recognized as current forms of request for services, the ARIN community may choose to develop additional mechanisms. Prior to implementing this policy, ARIN should attempt to contact the address holders that would have services removed as a result of this policy. Specifically, ARIN should make them aware of the loss of services, explain the potential impact of losing reverse mapping DNS services, etc. If an affected address holder cannot be reached by ARIN, or refuses to communicate with ARIN on this topic, then ARIN may consider their contact attempt to be satisfied. Timetable for implementation: Immediately From info at arin.net Tue Feb 15 17:18:10 2011 From: info at arin.net (ARIN) Date: Tue, 15 Feb 2011 17:18:10 -0500 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders Message-ID: <4D5AFBA2.9070206@arin.net> ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-134: Identification of Legitimate Address Holders Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 15 Feb 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.x. Recognition of Legitimate Address Holders ARIN will use the following criteria in order to determine whether an organization is the legitimate address holder for a given IP address block. 13.x.1. Original Allocation Record The original allocation records, such as those documented in RFC 1166 issued in July of 1990 or the InterNIC database received by ARIN from Network Solutions in December of 1997, will be used as dispositive proof, absent any contrary documentation such as those specified in section 13.x.4 below, in determining whether an organization is the legitimate address holder. 13.x.2 IANA Records of Legitimate Address Holders In the event that the IANA has historical records, and/or current records, showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as proof, absent any contrary documentation, in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.x.4 below, the evidence from the original allocation record will take precedence. 13.x.3. Records Maintained on Behalf of the IANA In the event that the IANA has delegated responsibility for the management of an address block to another organization, including ARIN or any other RIR, and that organization has historical and/or current records showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as evidence in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.x.4 below, the evidence from the original allocation record will take precedence. 13.x.4. Formal Records Clarifying the Chain of Custody In the event that formal records, such as public records or other formal documents which can be authenticated or verified to include legal, financial, and other organizational documentation, are provided to ARIN by an organization seeking recognition of their status as the legitimate address holder, then ARIN will consider the impact of these records as potentially updating any evidence that may exist. If these records clearly document the assignment or allocation of a given IP address block to a specific organization by direct assignment, and/or organizational transitions such as mergers, acquisitions, business unit restructuring, asset transfers, name changes, and so forth, absent definitive documentation to the contrary, then these records will determine whether an organization is the legitimate address holder. Rationale This proposal introduces policy that specifies how ARIN will go about determining who a "legitimate" address holder is. It is similar to current procedure with 13.x.2 and 13.x.3, which specify the use of IANA and RIR records. It expands on the current procedures with 13.x.4, allowing organizations to provide legal documentation of organizational changes and/or the transfer of custody of a legacy address block. Timetable for implementation: Immediately From gary.buhrmaster at gmail.com Tue Feb 15 17:23:41 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Tue, 15 Feb 2011 22:23:41 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: On Tue, Feb 15, 2011 at 20:12, Edward Lewis wrote: .... > Given these lines, I think then the policy proposal has been made for the > wrong reasons. ?For one, there isn't any specific complaint coming from > legacy holders, just speculation that they would be impacted. ?(If a legacy > holder came forward and found grounds for a policy to remove their listing, > that's another matter.) I am not in favor of this proposal as written, but policy proposals do come from people trying to improve the policies who are not directly impacted. I support everyones right to make proposals, in self interest, in altruistic interest, or whatever, no matter what I think of any particular proposal. The ppml participants are certainly special enough to make their opinions known about any particular proposal. From cgrundemann at gmail.com Tue Feb 15 17:25:03 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 15 Feb 2011 15:25:03 -0700 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: On Tue, Feb 15, 2011 at 14:53, cja at daydream.com wrote: > Further we have been asked on a number of occasions by law enforcement not > to remove questionable data from whois. ?They insist that it's often better > than nothing.. ?I forget which ARIN meeting it was but there was a > presentation by some law enforcement folks regarding this very issue. ?I am > sure the slides are around somewhere on the ARIN site. That was in Dearborn, the presentation was titled "Law Enforcement Agencies and ARIN." The slides, transcript and webcast are posted: https://www.arin.net/participate/meetings/reports/ARIN_XXV/ppm.html#day1 ~Chris > -----Cathy -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From jeffrey.lyon at blacklotus.net Tue Feb 15 17:34:54 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 15 Feb 2011 17:34:54 -0500 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> Message-ID: On Tue, Feb 15, 2011 at 2:27 PM, John Curran wrote: > On Feb 15, 2011, at 1:55 PM, Ted Mittelstaedt wrote: >> John, I think one possible difficulty on the fraud issue is that unlike >> both the civil and criminal justice system (in the united states, at any >> rate) none of the fraud proceedings are public. >> >> If someone submits fraud evidence or even a strong suspicion based on >> research in the whois database + direct experience, is there feedback? > > A fraud report results in a NRPM 12 resource review, and the address holder > is an integral part of the review process. > >> Are they included in the investigation? ?If there is wrongdoing discovered >> are they informed of any punishments meted out? ?Without this, it is >> understandable that people would feel fraud reports are going into a black >> hole - and the lack of publicity also does not create examples of what is >> and what isn't allowed. ?Most human beings learn by example. > > The resource holder is informed of any action, and we produce summary > reports for the community on the fraud reporting page. > >> Martin, keep in mind that ARIN has no legal contract between it and >> a true "Legacy" resource holder as they never signed anything with them, >> and ARIN is not a governmental body. ?It thus has little ability to bring >> proceedings against a legacy holder who is violating ARIN's NRPM > > No proceedings are necessary to correct entries in the ARIN Whois database. > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > John, I sent a fraud report late last year. It took weeks to be acknowledged and so far all I know about that report is that you have it. I don't feel like an integral part of the process? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From tedm at ipinc.net Tue Feb 15 17:41:44 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 15 Feb 2011 14:41:44 -0800 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> Message-ID: <4D5B0128.4020307@ipinc.net> On 2/15/2011 11:27 AM, John Curran wrote: > On Feb 15, 2011, at 1:55 PM, Ted Mittelstaedt wrote: >> John, I think one possible difficulty on the fraud issue is that unlike >> both the civil and criminal justice system (in the united states, at any >> rate) none of the fraud proceedings are public. >> >> If someone submits fraud evidence or even a strong suspicion based on >> research in the whois database + direct experience, is there feedback? > > A fraud report results in a NRPM 12 resource review, and the address holder > is an integral part of the review process. > I'm sure the address holder is - but the question was, is the person who submitted the report also involved? That may NOT be an address holder it may just be a guy out on the street there who happens to stumble across something. >> Are they included in the investigation? If there is wrongdoing discovered >> are they informed of any punishments meted out? Without this, it is >> understandable that people would feel fraud reports are going into a black >> hole - and the lack of publicity also does not create examples of what is >> and what isn't allowed. Most human beings learn by example. > > The resource holder is informed of any action, and we produce summary > reports for the community on the fraud reporting page. > But, is the person who filed the report informed of any action? Or do they just have to keep looking at the summary reports and trying to guess if their complaint was acted on or not? The summary reports do not serve as adequate examples. Here are some recent selections: 20100721-F639 ISP assigning IPv4 space without justification Section 12 audit conducted So, what happened? What were the audit results? Was the ISP doing this or not? 20100814-F655 Report that 2 orgs are assigning IP addresses without justification Section 12 audits conducted on both Results???? I also would love a bit more detail on this one: 20100819-F657 Report of spam emanating from org?s /15 Investigated, found justification meets ARIN policy requirements. If that was snowshoe spamming and it fits in the NRPM then we definitely need to modify the NRPM. Ted >> Martin, keep in mind that ARIN has no legal contract between it and >> a true "Legacy" resource holder as they never signed anything with them, >> and ARIN is not a governmental body. It thus has little ability to bring >> proceedings against a legacy holder who is violating ARIN's NRPM > > No proceedings are necessary to correct entries in the ARIN Whois database. > /John > > John Curran > President and CEO > ARIN > > From jcurran at arin.net Tue Feb 15 17:48:30 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 22:48:30 +0000 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> Message-ID: <94651621-0C09-4664-8751-E3C69FA21607@arin.net> On Feb 15, 2011, at 5:34 PM, Jeffrey Lyon wrote: >> A fraud report results in a NRPM 12 resource review, and the address holder >> is an integral part of the review process. > > John, > > I sent a fraud report late last year. It took weeks to be acknowledged > and so far all I know about that report is that you have it. I don't > feel like an integral part of the process? I indicated that the *address holder* is an integral part of the process; you likely did not submit a fraud report against your own address block... (I you send me the acknowledgement, I'll update you on the status, or it may be listed individually on the Fraud Reporting reports page) FYI, /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Tue Feb 15 17:49:18 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 15 Feb 2011 17:49:18 -0500 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: <94651621-0C09-4664-8751-E3C69FA21607@arin.net> References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> <94651621-0C09-4664-8751-E3C69FA21607@arin.net> Message-ID: On Tue, Feb 15, 2011 at 5:48 PM, John Curran wrote: > On Feb 15, 2011, at 5:34 PM, Jeffrey Lyon wrote: > >>> A fraud report results in a NRPM 12 resource review, and the address holder >>> is an integral part of the review process. >> >> John, >> >> I sent a fraud report late last year. It took weeks to be acknowledged >> and so far all I know about that report is that you have it. I don't >> feel like an integral part of the process? > > I indicated that the *address holder* is an integral part of the process; > you likely did not submit a fraud report against your own address block... > (I you send me the acknowledgement, I'll update you on the status, or it > may be listed individually on the Fraud Reporting reports page) > > FYI, > /John > > John Curran > President and CEO > ARIN > > > > My mistake, I must have misunderstood. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From JOHN at egh.com Tue Feb 15 17:50:50 2011 From: JOHN at egh.com (John Santos) Date: Tue, 15 Feb 2011 17:50:50 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: Message-ID: <1110215171828.4290C-100000@Ives.egh.com> I am in the exact same situation as Eric. Legacy /24, no RSA nor LRSA, not really clear on the exact obligations and restrictions on my original assignment, but I have a pretty clear sense of what was expected, including maintaining current POC, WHOIS and RDNS info, and that the assignment was for use, not a windfall that I could just sell to someone else if I didn't need it any more. I was looking for my original letter fron Network Solutions yesterday, couldn't find it. Did find my original application, though, and it was pretty vague. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at arin.net Tue Feb 15 17:55:14 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 22:55:14 +0000 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: <4D5B0128.4020307@ipinc.net> References: <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> <4D5B0128.4020307@ipinc.net> Message-ID: <60B43609-A6F2-4439-BF01-8D415D18C813@arin.net> On Feb 15, 2011, at 5:41 PM, Ted Mittelstaedt wrote: > > I'm sure the address holder is - but the question was, is the person who > submitted the report also involved? That may NOT be an address holder it > may just be a guy out on the street there who happens to stumble across something. They often cannot be involved at the level desired, as the information that we receive is still subject to NDA. > But, is the person who filed the report informed of any action? Or do they just > have to keep looking at the summary reports and trying to guess if their complaint > was acted on or not? We've taken to breaking down each report and any action taken on the reports, but have not been sending updates to the reporter. I will change this; there's no reason for you to have to poll for report changes. > The summary reports do not serve as adequate examples. Here are some > recent selections: > > 20100721-F639 ISP assigning IPv4 space without justification Section 12 audit conducted > > So, what happened? What were the audit results? Was the ISP doing this > or not? > > 20100814-F655 Report that 2 orgs are assigning IP addresses without justification Section 12 audits conducted on both > > Results???? If it does not say revocation, then the audit showed the assignments were warranted. > I also would love a bit more detail on this one: > > 20100819-F657 Report of spam emanating from org?s /15 Investigated, found justification meets ARIN policy requirements. > > If that was snowshoe spamming and it fits in the NRPM then we definitely > need to modify the NRPM. I will look into this and see if there is a generic case to be added to the Policy Experience report for San Juan. Thanks! /John John Curran President and CEO ARIN From jcurran at arin.net Tue Feb 15 18:01:06 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Feb 2011 23:01:06 +0000 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <1110215171828.4290C-100000@Ives.egh.com> References: <1110215171828.4290C-100000@Ives.egh.com> Message-ID: <1D96FE85-BE3D-4E16-A974-A0AA03D8A85A@corp.arin.net> On Feb 15, 2011, at 5:50 PM, John Santos wrote: > I am in the exact same situation as Eric. Legacy /24, no RSA nor LRSA, > not really clear on the exact obligations and restrictions on my > original assignment, but I have a pretty clear sense of what was > expected, including maintaining current POC, WHOIS and RDNS info, > and that the assignment was for use, not a windfall that I could just > sell to someone else if I didn't need it any more. That's a good summary of many legacy holders expectations (at least as I understand it from speaking with just a few of them...), but I should note that in the ARIN region that last line has actually been modified per community-developed policy, in that you may transfer the assignment to another party which qualifies per the current allocation policies. This means, in effect, you could get a "windfall" from the assignment, except it may not be much of a windfall given the work of renumbering that you might have to go through to free up the block. This was seen as a reasonable tradeoff by the community, but is still short of the "you can do anything you like with it, it's yours" policy proposals that are now in vogue. FYI, /John John Curran President and CEO ARIN From tedm at ipinc.net Tue Feb 15 18:24:45 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Tue, 15 Feb 2011 15:24:45 -0800 Subject: [arin-ppml] Use of the specified transfer policy In-Reply-To: <60B43609-A6F2-4439-BF01-8D415D18C813@arin.net> References: <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> <4D5ACC0F.8060600@ipinc.net> <4D5B0128.4020307@ipinc.net> <60B43609-A6F2-4439-BF01-8D415D18C813@arin.net> Message-ID: <4D5B0B3D.9090106@ipinc.net> On 2/15/2011 2:55 PM, John Curran wrote: > On Feb 15, 2011, at 5:41 PM, Ted Mittelstaedt wrote: >> >> I'm sure the address holder is - but the question was, is the >> person who submitted the report also involved? That may NOT be an >> address holder it may just be a guy out on the street there who >> happens to stumble across something. > > They often cannot be involved at the level desired, as the > information that we receive is still subject to NDA. > Jeffrey did not say he wanted to be involved in every step of the report. Just an acknowledgment. >> But, is the person who filed the report informed of any action? Or >> do they just have to keep looking at the summary reports and trying >> to guess if their complaint was acted on or not? > > We've taken to breaking down each report and any action taken on the > reports, but have not been sending updates to the reporter. I will > change this; there's no reason for you to have to poll for report > changes. > An automatic ticketing system can send an acknowledgment and assign a ticket #. Many such ticket systems exist as free open source software on the Internet. fraud report submitters should be periodically e-mailed with status. A simple "fraud report XXXX you submitted on date YYY is still pending" Then, once the matter is resolved, the submitter should either get "the investigation on fraud report XXXX you submitted on date YYY has been completed, and results will be available on the next published Fraud Report Summary page" or they should get "completed and out of scope due to XXXX YYY ZZZ" If the matter is under NDA then simply don't tell the submitter what result on the summary page corresponds with his report. He can probably guess which one it is, but he has no proof and thus nobody has any real knowledge of anything, and the NDA agreement has been preserved. Doesn't the RSA guarantee the signatories that if they are discovered to be engaged in fraud that they lose all confidentiality? If not, it really should! >> The summary reports do not serve as adequate examples. Here are >> some recent selections: >> >> 20100721-F639 ISP assigning IPv4 space without justification >> Section 12 audit conducted >> >> So, what happened? What were the audit results? Was the ISP doing >> this or not? >> > >> 20100814-F655 Report that 2 orgs are assigning IP addresses without >> justification Section 12 audits conducted on both >> >> Results???? > > If it does not say revocation, then the audit showed the assignments > were warranted. > Oh, I didn't realize the report was created on a UNIX system. :-) Ted >> I also would love a bit more detail on this one: >> >> 20100819-F657 Report of spam emanating from org?s /15 Investigated, >> found justification meets ARIN policy requirements. >> >> If that was snowshoe spamming and it fits in the NRPM then we >> definitely need to modify the NRPM. > > I will look into this and see if there is a generic case to be added > to the Policy Experience report for San Juan. > > Thanks! /John > > John Curran President and CEO ARIN > > From cgrundemann at gmail.com Tue Feb 15 18:27:29 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 15 Feb 2011 16:27:29 -0700 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: Although I have not been playing with these reports until just today, I think Owen's suggestion has merit, especially as/if policy is developed which requires ARIN to act in response to more than outright fraud. I would further suggest (assuming I did not just miss it) historical data being included in chart form. I am probably just being lazy, since the data is there already; but a chart showing the total number of reports and the top few actions taken (per quarter) would be handy if it's easy to generate. $0.02 ~Chris On Tue, Feb 15, 2011 at 12:16, Owen DeLong wrote: > John, > > I suggest that the term fraud is detracting from the purpose of the report. > > Perhaps an ARIN policy violation report would be more useful. > > Owen > > > Sent from my iPad > > On Feb 15, 2011, at 12:30 PM, Martin Hannigan wrote: > >> On Tue, Feb 15, 2011 at 1:24 PM, John Curran wrote: >>> On Feb 15, 2011, at 11:04 AM, Martin Hannigan wrote: >>>> >>>> I didn't answer this question since I wanted to think about it. The >>>> unfortunate answer here is that transfer policy already doesn't apply >>>> to legacy holders from their perspective so hoping that they will sign >>>> an agreement seems less than efficient. >>> >>> The transfer policy applies to all resources in ARIN's Whois Database. >>> If you are aware of an attempt to contravene number resource policy, >>> please submit a fraud report here: >>> and we'll take care of it. >>> >> >> I would, but it appears that we're all disconnected as to what fraud >> with respect to legacy resources actually is: >> >> >> https://www.arin.net/resources/fraud/results/third_quarter_2010.html >> >> >> Best, >> >> -M< > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From jeffrey.lyon at blacklotus.net Tue Feb 15 18:59:45 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 15 Feb 2011 18:59:45 -0500 Subject: [arin-ppml] Use of the specified transfer policy (was: "Leasing" of space via non-connectivity providers) In-Reply-To: References: <93CFBE5F-EB2E-4889-B5B4-3056BA7A8A20@ianai.net> <712D59FA-76A9-4FCB-8979-32494C98FF1B@corp.arin.net> <5A6D953473350C4B9995546AFE9939EE0BC13839@RWC-EX1.corp.seven.com> <75822E125BCB994F8446858C4B19F0D7143AF217CD@SUEX07-MBX-04.ad.syr.edu> <1DEEDC4D-7A7F-46D9-B989-E8E407949C15@queuefull.net> <9093B3D5-5298-4996-BB3D-061722CB28A3@arin.net> Message-ID: On Tue, Feb 15, 2011 at 2:16 PM, Owen DeLong wrote: > John, > > I suggest that the term fraud is detracting from the purpose of the report. > > Perhaps an ARIN policy violation report would be more useful. > > Owen > > > Sent from my iPad > > On Feb 15, 2011, at 12:30 PM, Martin Hannigan wrote: > >> On Tue, Feb 15, 2011 at 1:24 PM, John Curran wrote: >>> On Feb 15, 2011, at 11:04 AM, Martin Hannigan wrote: >>>> >>>> I didn't answer this question since I wanted to think about it. The >>>> unfortunate answer here is that transfer policy already doesn't apply >>>> to legacy holders from their perspective so hoping that they will sign >>>> an agreement seems less than efficient. >>> >>> The transfer policy applies to all resources in ARIN's Whois Database. >>> If you are aware of an attempt to contravene number resource policy, >>> please submit a fraud report here: >>> and we'll take care of it. >>> >> >> I would, but it appears that we're all disconnected as to what fraud >> with respect to legacy resources actually is: >> >> >> https://www.arin.net/resources/fraud/results/third_quarter_2010.html >> >> >> Best, >> >> -M< >> _______________________________________________ >> 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. > Owen, I think that would ultimately depend on whether the term "fraud" is being used to refer to deceit (eg. sending false and misleading data to ARIN) or to simple failures to follow prescribed procedure. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From Keith at jcc.com Tue Feb 15 19:42:09 2011 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 15 Feb 2011 19:42:09 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D5AFAA6.10300@arin.net> References: <4D5AFAA6.10300@arin.net> Message-ID: <3f3bf59013fd954ae7483943a818c5e54d5b1ca0@jcc.com> I am opposed to the revised prop-133. Keith Hare ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, February 15, 2011 5:14 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised The proposal originator submitted revised text. "Changes from Previous Version: Version 2 of this proposal removed section 13.2 so that it could be considered separately, in a new policy proposal submission. As a result, the remaining sections were renumbered to use an abstract system of "13.x" and "13.y", with the intent that actual sub-section numbers would be assigned later in the policy development process." Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-133: Volunteer Services on Behalf of Unaffiliated Address Blocks Proposal Originator: Benson Schliesser Proposal Version: 2 Date: 15 Feb 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.x. No Volunteer Services Except in the specific circumstances described by this policy, ARIN will not provide any services for any organization and/or address block. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. 13.x.1. Requested Services In the event that an organization explicitly requests registry services from ARIN for one or more specified address blocks, ARIN may provide the requested services, subsequent to execution of a service contract, for those address blocks. This includes without limitation all directory services, reverse mapping services, and future services that may be provided to the community. All address blocks that are assigned or allocated by ARIN under a valid RSA, as well as specific address blocks that are included under a Legacy RSA with the legitimate validated address holder, are deemed to have services requested for them. An organization requesting registry services for one or more specified address blocks, that also holds additional address blocks not specified in their request, is not obligated to receive registry services for those additional address blocks and those blocks are not deemed to have services requested for them. 13.x.2. Directory Placeholders For any address blocks, for which there are not fully executed ARIN service contracts, ARIN will create generic placeholder entries in the ARIN Whois directory. These placeholder entries will not specify organizational details, but will indicate that the entry represents a non-member resource. When applicable, each non-member resource placeholder will include a reference and/or RWhois referral to the authoritative directory service for that block, or the directory service operated by the IANA, or by another organization in the event that IANA has delegated their directory service responsibility to that organization. This does not apply to placeholders that represent an unassigned and unallocated address block delegated to ARIN by the IANA. 13.y. Permitted Updates to Directory Services for Unaffiliated Address Blocks Any organization that legitimately holds an address block, as defined by section 13.2 of this policy, may request the removal or modification of existing directory placeholders representing that address block. Valid requests for modification of placeholder entries are limited to references and/or RWhois referrals to authoritative directory services, such as directory services operated by or on behalf of the IANA, another address registry, or the address holder. In the event that such a request is received, ARIN may choose to either remove the placeholder entry or update it per the request. Rationale: Policy Background: This policy attempts to clarify the relationship that ARIN has with legacy address holders. Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical. This policy would require positive affirmation from any legacy address holder that wishes to receive registry services, moving to an "opt-in" approach. In the event that a legacy address holder does not opt-in to receive registry services, ARIN is limited to providing no more than a pointer (such as a RWhois referral) to an authoritative directory service for that holder's legacy address blocks. Pointers to other providers of directory services for addresses managed by those other providers continue to be permitted. Policy Structure: This policy introduces a new section to the NRPM, numbered section 13. Within this new section, there are two new sub-sections described in this proposal. Sub-section 13.x introduces policy that limits ARIN to providing services on an opt-in basis. It does make clear in 13.x.1 that services provided as part of a RSA or LRSA are automatically considered opted-in. With 13.x.2 it allows ARIN to create placeholders in the Whois database for blocks managed by other RIRs as well as for blocks managed (but unassigned/unallocated) by ARIN. Sub-section 13.y introduces policy enabling legitimate address holders to request a very limited update to any Whois placeholders that might exist for their legacy address block, so that the Whois will refer queries to the authoritative directory service. It is expected that ARIN will charge a fee for this update, but not require an ongoing services agreement. ARIN is given the option of deleting placeholders instead. Changes from Previous Version: Version 2 of this proposal removed section 13.2 so that it could be considered separately, in a new policy proposal submission. As a result, the remaining sections were renumbered to use an abstract system of "13.x" and "13.y", with the intent that actual sub-section numbers would be assigned later in the policy development process. Discussion: This proposal should not be interpreted as a "punishment" of legacy address holders or as an attempt to encourage execution of the LRSA. Rather, the intent of this proposal is to make it clear that ARIN will only provide services for organizations that wish to receive them. Put another way: this proposal would prohibit ARIN from forcing any organization to be listed in the ARIN Whois database without their consent. While it is not anticipated by this proposal's text, alternative forms of "request" are not prohibited by this policy proposal. Indeed, while the RSA and LRSA are recognized as current forms of request for services, the ARIN community may choose to develop additional mechanisms. Prior to implementing this policy, ARIN should attempt to contact the address holders that would have services removed as a result of this policy. Specifically, ARIN should make them aware of the loss of services, explain the potential impact of losing reverse mapping DNS services, etc. If an affected address holder cannot be reached by ARIN, or refuses to communicate with ARIN on this topic, then ARIN may consider their contact attempt to be satisfied. Timetable for implementation: Immediately _______________________________________________ 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 Keith at jcc.com Tue Feb 15 20:05:37 2011 From: Keith at jcc.com (Keith W. Hare) Date: Tue, 15 Feb 2011 20:05:37 -0500 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <4D5AFBA2.9070206@arin.net> References: <4D5AFBA2.9070206@arin.net> Message-ID: What problem is prop-134 trying to solve? NPRM 8.2 "Mergers and Acquisitions" says "ARIN will maintain an up-to-date list of acceptable types of documentation." How does the codified list in Prop-134 compare to the ARIN list of acceptable types of documentation? Keith -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Tuesday, February 15, 2011 5:18 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders ARIN received the following policy proposal and is posting it to the Public Policy Mailing List (PPML) in accordance with the Policy Development Process. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-134: Identification of Legitimate Address Holders Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 15 Feb 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.x. Recognition of Legitimate Address Holders ARIN will use the following criteria in order to determine whether an organization is the legitimate address holder for a given IP address block. 13.x.1. Original Allocation Record The original allocation records, such as those documented in RFC 1166 issued in July of 1990 or the InterNIC database received by ARIN from Network Solutions in December of 1997, will be used as dispositive proof, absent any contrary documentation such as those specified in section 13.x.4 below, in determining whether an organization is the legitimate address holder. 13.x.2 IANA Records of Legitimate Address Holders In the event that the IANA has historical records, and/or current records, showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as proof, absent any contrary documentation, in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.x.4 below, the evidence from the original allocation record will take precedence. 13.x.3. Records Maintained on Behalf of the IANA In the event that the IANA has delegated responsibility for the management of an address block to another organization, including ARIN or any other RIR, and that organization has historical and/or current records showing the assignment or allocation of a given IP address block to a specific organization, those records will be used as evidence in determining whether an organization is the legitimate address holder. Further, in the event that this evidence conflicts with any evidence from the original allocation records, or any contrary documentation such as those specified in section 13.x.4 below, the evidence from the original allocation record will take precedence. 13.x.4. Formal Records Clarifying the Chain of Custody In the event that formal records, such as public records or other formal documents which can be authenticated or verified to include legal, financial, and other organizational documentation, are provided to ARIN by an organization seeking recognition of their status as the legitimate address holder, then ARIN will consider the impact of these records as potentially updating any evidence that may exist. If these records clearly document the assignment or allocation of a given IP address block to a specific organization by direct assignment, and/or organizational transitions such as mergers, acquisitions, business unit restructuring, asset transfers, name changes, and so forth, absent definitive documentation to the contrary, then these records will determine whether an organization is the legitimate address holder. Rationale This proposal introduces policy that specifies how ARIN will go about determining who a "legitimate" address holder is. It is similar to current procedure with 13.x.2 and 13.x.3, which specify the use of IANA and RIR records. It expands on the current procedures with 13.x.4, allowing organizations to provide legal documentation of organizational changes and/or the transfer of custody of a legacy address block. Timetable for implementation: Immediately _______________________________________________ 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 JOHN at egh.com Tue Feb 15 21:01:08 2011 From: JOHN at egh.com (John Santos) Date: Tue, 15 Feb 2011 21:01:08 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <3f3bf59013fd954ae7483943a818c5e54d5b1ca0@jcc.com> Message-ID: <1110215205949.4290B-100000@Ives.egh.com> Doesn't address my concerns. Still opposed. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From gbonser at seven.com Tue Feb 15 22:25:28 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 15 Feb 2011 19:25:28 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D5AFAA6.10300@arin.net> References: <4D5AFAA6.10300@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13B4E@RWC-EX1.corp.seven.com> Opposed > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Tuesday, February 15, 2011 2:14 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks - revised > > The proposal originator submitted revised text. > > "Changes from Previous Version: > Version 2 of this proposal removed section 13.2 so that it could be > considered separately, in a new policy proposal submission. As a > result, the remaining sections were renumbered to use an abstract > system > of "13.x" and "13.y", with the intent that actual sub-section numbers > would be assigned later in the policy development process." > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-133: Volunteer Services on Behalf of Unaffiliated Address > Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 2 > > Date: 15 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. No Volunteer Services > > Except in the specific circumstances described by this policy, ARIN > will > not provide any services for any organization and/or address block. > This includes without limitation all directory services, reverse > mapping services, and future services that may be provided to the > community. > > 13.x.1. Requested Services > > In the event that an organization explicitly requests registry services > from ARIN for one or more specified address blocks, ARIN may provide > the > requested services, subsequent to execution of a service contract, for > those address blocks. This includes without limitation all directory > services, reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN under a valid > RSA, as well as specific address blocks that are included under a > Legacy RSA with the legitimate validated address holder, are deemed to > have services requested for them. > > An organization requesting registry services for one or more specified > address blocks, that also holds additional address blocks not specified > in their request, is not obligated to receive registry services for > those additional address blocks and those blocks are not deemed to have > services requested for them. > > 13.x.2. Directory Placeholders > > For any address blocks, for which there are not fully executed ARIN > service contracts, ARIN will create generic placeholder entries in the > ARIN Whois directory. These placeholder entries will not specify > organizational details, but will indicate that the entry represents a > non-member resource. > > When applicable, each non-member resource placeholder will include a > reference and/or RWhois referral to the authoritative directory service > for that block, or the directory service operated by the IANA, or by > another organization in the event that IANA has delegated their > directory service responsibility to that organization. This does not > apply to placeholders that represent an unassigned and unallocated > address block delegated to ARIN by the IANA. > > 13.y. Permitted Updates to Directory Services for Unaffiliated Address > Blocks > > Any organization that legitimately holds an address block, as defined > by > section 13.2 of this policy, may request the removal or modification of > existing directory placeholders representing that address block. > > Valid requests for modification of placeholder entries are limited to > references and/or RWhois referrals to authoritative directory services, > such as directory services operated by or on behalf of the IANA, > another > address registry, or the address holder. In the event that such a > request is received, ARIN may choose to either remove the placeholder > entry or update it per the request. > > > Rationale: > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and > is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy would require positive affirmation from any legacy address > holder that wishes to receive registry services, moving to an "opt-in" > approach. In the event that a legacy address holder does not opt-in to > receive registry services, ARIN is limited to providing no more than a > pointer (such as a RWhois referral) to an authoritative directory > service for that holder's legacy address blocks. Pointers to other > providers of directory services for addresses managed by those > other providers continue to be permitted. > > Policy Structure: > > This policy introduces a new section to the NRPM, numbered section 13. > Within this new section, there are two new sub-sections described in > this proposal. > > Sub-section 13.x introduces policy that limits ARIN to providing > services on an opt-in basis. It does make clear in 13.x.1 that > services > provided as part of a RSA or LRSA are automatically considered opted- > in. > With 13.x.2 it allows ARIN to create placeholders in the Whois database > for blocks managed by other RIRs as well as for blocks managed (but > unassigned/unallocated) by ARIN. > > Sub-section 13.y introduces policy enabling legitimate address holders > to request a very limited update to any Whois placeholders that might > exist for their legacy address block, so that the Whois will refer > queries to the authoritative directory service. It is expected that > ARIN will charge a fee for this update, but not require an ongoing > services agreement. ARIN is given the option of deleting placeholders > instead. > > Changes from Previous Version: > > Version 2 of this proposal removed section 13.2 so that it could be > considered separately, in a new policy proposal submission. As a > result, the remaining sections were renumbered to use an abstract > system > of "13.x" and "13.y", with the intent that actual sub-section numbers > would be assigned later in the policy development process. > > Discussion: > > This proposal should not be interpreted as a "punishment" of legacy > address holders or as an attempt to encourage execution of the LRSA. > Rather, the intent of this proposal is to make it clear that ARIN will > only provide services for organizations that wish to receive them. Put > another way: this proposal would prohibit ARIN from forcing any > organization to be listed in the ARIN Whois database without their > consent. > > While it is not anticipated by this proposal's text, alternative forms > of "request" are not prohibited by this policy proposal. Indeed, while > the RSA and LRSA are recognized as current forms of request for > services, the ARIN community may choose to develop additional > mechanisms. > > Prior to implementing this policy, ARIN should attempt to contact the > address holders that would have services removed as a result of this > policy. Specifically, ARIN should make them aware of the loss of > services, explain the potential impact of losing reverse mapping DNS > services, etc. If an affected address holder cannot be reached by ARIN, > or refuses to communicate with ARIN on this topic, then ARIN may > consider their contact attempt to be satisfied. > > Timetable for implementation: Immediately > > > > > > > _______________________________________________ > 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 gbonser at seven.com Tue Feb 15 22:25:55 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 15 Feb 2011 19:25:55 -0800 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate AddressHolders In-Reply-To: <4D5AFBA2.9070206@arin.net> References: <4D5AFBA2.9070206@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13B4F@RWC-EX1.corp.seven.com> Opposed > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Tuesday, February 15, 2011 2:18 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate > AddressHolders > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their > deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-134: Identification of Legitimate Address Holders > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 15 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. Recognition of Legitimate Address Holders > > ARIN will use the following criteria in order to determine whether an > organization is the legitimate address holder for a given IP address > block. > > 13.x.1. Original Allocation Record > > The original allocation records, such as those documented in RFC 1166 > issued in July of 1990 or the InterNIC database received by ARIN from > Network Solutions in December of 1997, will be used as dispositive > proof, absent any contrary documentation such as those specified in > section 13.x.4 below, in determining whether an organization is the > legitimate address holder. > > 13.x.2 IANA Records of Legitimate Address Holders > > In the event that the IANA has historical records, and/or current > records, showing the assignment or allocation of a given IP address > block to a specific organization, those records will be used as proof, > absent any contrary documentation, in determining whether an > organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation > such > as those specified in section 13.x.4 below, the evidence from the > original allocation record will take precedence. > > 13.x.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for the > management of an address block to another organization, including ARIN > or any other RIR, and that organization has historical and/or current > records showing the assignment or allocation of a given IP address > block > to a specific organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation > such > as those specified in section 13.x.4 below, the evidence from the > original allocation record will take precedence. > > 13.x.4. Formal Records Clarifying the Chain of Custody > > In the event that formal records, such as public records or other > formal > documents which can be authenticated or verified to include legal, > financial, and other organizational documentation, are provided to ARIN > by an organization seeking recognition of their status as the > legitimate > address holder, then ARIN will consider the impact of these records as > potentially updating any evidence that may exist. If these records > clearly document the assignment or allocation of a given IP address > block to a specific organization by direct assignment, and/or > organizational transitions such as mergers, acquisitions, business unit > restructuring, asset transfers, name changes, and so forth, absent > definitive documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. > > > Rationale > > This proposal introduces policy that specifies how ARIN will go about > determining who a "legitimate" address holder is. It is similar to > current procedure with 13.x.2 and 13.x.3, which specify the use of IANA > and RIR records. It expands on the current procedures with 13.x.4, > allowing organizations to provide legal documentation of organizational > changes and/or the transfer of custody of a legacy address block. > > Timetable for implementation: Immediately > > > > _______________________________________________ > 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 mueller at syr.edu Tue Feb 15 23:48:01 2011 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 15 Feb 2011 23:48:01 -0500 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF29C58@SUEX07-MBX-04.ad.syr.edu> Prop 132 seems reasonable to me. All I have heard against it are religious arguments. E.g., the statement below > -----Original Message----- > > Abdicating responsibility for needs-based assignment on the eve > of addressing being fully assigned would make everything ARIN has done > the past decade and a half a lie. No, it simply recognizes that things are different now. With a free pool available, making allocations according to technical needs criteria makes some sense. It was really a first-come, first-served rationing system with some rough, onetime assessment of technical need as gating function. Once the free pool is occupied, however, needs-based allocation is impossible, meaningless.* There will be hundreds if not thousands of applicants with the same need for ipv4 addresses, and not enough address blocks to give them all. So post free pool runout, addresses _will_ be allocated via the market primarily and need secondarily. To insist on putting ARIN in the loop to assess "need" just adds needless friction. > Nothing in the existing section 4.2 explicitly prohibits address leasing > activity. And so you are against prop-132 why? * unless, of course, you want ARIN deciding which uses and users are more worthy. From rfg at tristatelogic.com Tue Feb 15 23:48:08 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 15 Feb 2011 20:48:08 -0800 Subject: [arin-ppml] Fraud or not? Message-ID: <38911.1297831688@tristatelogic.com> www.robtex.com says that AS10912 belongs to Internap. whois.arin.net says that there ain't no such AS. So, should I file a formal report charging Internap with fradulent use of resources that are not actually assigned to them? Or is it more likely that ARIN has simply (and entirely) misplaced the WHOIS record for AS10912? Regards, rfg P.S. Since several serious spammers are actively spamming the Universe from that AS, it would, you know, be kinda nice to at least be able to find out who the AS actually belongs to. I understand that whowever that AS is actually assigned to would probably prefer to continue operating it in super double secret stealth spammer mode, but I was kinda under the impression that that was only allowed for domain names, and not also for IP blocks and ASes. From scottleibrand at gmail.com Wed Feb 16 00:03:56 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 15 Feb 2011 21:03:56 -0800 Subject: [arin-ppml] Fraud or not? In-Reply-To: <38911.1297831688@tristatelogic.com> References: <38911.1297831688@tristatelogic.com> Message-ID: On Tue, Feb 15, 2011 at 8:48 PM, Ronald F. Guilmette wrote: > > www.robtex.com says that AS10912 belongs to Internap. > > whois.arin.net says that there ain't no such AS. > > So, should I file a formal report charging Internap with fradulent use > of resources that are not actually assigned to them? Or is it more > likely that ARIN has simply (and entirely) misplaced the WHOIS record > for AS10912? > It looks like it's only the traditional whois tool that is failing. The web tool at arin.net reports it as part of INTERNAP-BLK, which covers ASNs 10910 - 10913. http://whois.arin.net/rest/asn/AS10910/pft I suspect your message will be enough to get ARIN to fix the whois port 43 service shortly. :-) -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Wed Feb 16 00:15:04 2011 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 16 Feb 2011 00:15:04 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D595D12.4000602@arin.net> References: <4D595D12.4000602@arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu> Wow. This is a brilliant proposal that squarely faces problems that are at the core of many institutional issues related to address allocation. It may, however, be a step or two ahead of its time. My concern is that there may need to be preparatory steps taken regarding the exclusivity/shared status of the Whois directory information. See this for more info: http://blog.internetgovernance.org/blog/_archives/2011/2/12/4748945.html But in another sense we are facing a chicken and egg problem; until and unless this kind of a policy passes we may never be able to clarify the status of Whois. Anyway, as a directional indicator of where we need to be headed, I think this statement from prop-133 is one of the wisest, most forward-looking things I have seen in a proposed ARIN policy for a long, long time: "Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical." > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Monday, February 14, 2011 11:49 AM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks > > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning behind their > opinion. Such participation contributes to a thorough vetting and > provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address > Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 13 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.1. No Volunteer Services > > Except in the specific circumstances described by this policy, ARIN will > not provide any services for any organization and/or address block. This > includes without limitation all directory services, reverse mapping > services, and future services that may be provided to the community. > > 13.1.1. Requested Services > > In the event that an organization explicitly requests registry services > from ARIN for one or more specified address blocks, ARIN may provide the > requested services, subsequent to execution of a service contract, for > those address blocks. This includes without limitation all directory > services, reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN under a valid > RSA, as well as specific address blocks that are included under a Legacy > RSA with the legitimate validated address holder, are deemed to have > services requested for them. > > An organization requesting registry services for one or more specified > address blocks, that also holds additional address blocks not specified > in their request, is not obligated to receive registry services for > those additional address blocks and those blocks are not deemed to have > services requested for them. > > 13.1.2. Directory Placeholders > > For any address blocks, for which there are not fully executed ARIN > service contracts, ARIN will create generic placeholder entries in the > ARIN Whois directory. These placeholder entries will not specify > organizational details, but will indicate that the entry represents a > non-member resource. > > When applicable, each non-member resource placeholder will include a > reference and/or RWhois referral to the authoritative directory service > for that block, or the directory service operated by the IANA, or by > another organization in the event that IANA has delegated their > directory service responsibility to that organization. This does not > apply to placeholders that represent an unassigned and unallocated > address block delegated to ARIN by the IANA. > > 13.2. Recognition of Legitimate Address Holders > > ARIN will use the following criteria in order to determine whether an > organization is the legitimate address holder for a given IP address > block. > > 13.2.1. Original Allocation Record > > The original allocation records, such as those documented in RFC 1166 > issued in July of 1990 or the InterNIC database received by ARIN from > Network Solutions in December of 1997, will be used as dispositive > proof, absent any contrary documentation such as those specified in > section 13.2.4 below, in determining whether an organization is the > legitimate address holder. > > 13.2.2 IANA Records of Legitimate Address Holders > > In the event that the IANA has historical records, and/or current > records, showing the assignment or allocation of a given IP address > block to a specific organization, those records will be used as proof, > absent any contrary documentation, in determining whether an > organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.2.4 below, the evidence from the > original allocation record will take precedence. > > 13.2.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for the > management of an address block to another organization, including ARIN > or any other RIR, and that organization has historical and/or current > records showing the assignment or allocation of a given IP address block > to a specific organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.2.4 below, the evidence from the > original allocation record will take precedence. > > 13.2.4. Formal Records Clarifying the Chain of Custody > > In the event that formal records, such as public records or other formal > documents which can be authenticated or verified to include legal, > financial, and other organizational documentation, are provided to ARIN > by an organization seeking recognition of their status as the legitimate > address holder, then ARIN will consider the impact of these records as > potentially updating any evidence that may exist. If these records > clearly document the assignment or allocation of a given IP address > block to a specific organization by direct assignment, and/or > organizational transitions such as mergers, acquisitions, business unit > restructuring, asset transfers, name changes, and so forth, absent > definitive documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. > > 13.3. Permitted Updates to Directory Services for Unaffiliated Address > Blocks > > Any organization that legitimately holds an address block, as defined by > section 13.2 of this policy, may request the removal or modification of > existing directory placeholders representing that address block. > > Valid requests for modification of placeholder entries are limited to > references and/or RWhois referrals to authoritative directory services, > such as directory services operated by or on behalf of the IANA, another > address registry, or the address holder. In the event that such a > request is received, ARIN may choose to either remove the placeholder > entry or update it per the request. > > > Rationale: > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy would require positive affirmation from any legacy address > holder that wishes to receive registry services, moving to an "opt-in" > approach. In the event that a legacy address holder does not opt-in to > receive registry services, ARIN is limited to providing no more than a > pointer (such as a RWhois referral) to an authoritative directory > service for that holder's legacy address blocks. Pointers to other > providers of directory services for addresses managed by those other > providers continue to be permitted. > > Policy Structure: > > This policy introduces a new section to the NRPM, numbered section 13. > Within this new section, there are three sub-sections. > > Sub-section 13.1 introduces policy that limits ARIN to providing > services on an opt-in basis. It does make clear in 13.1.1 that services > provided as part of a RSA or LRSA are automatically considered opted-in. > With 13.1.2 it allows ARIN to create placeholders in the Whois > database for blocks managed by other RIRs as well as for blocks managed > (but unassigned/unallocated) by ARIN. > > Sub-section 13.2 introduces policy that specifies how ARIN will go about > determining who a "legitimate" address holder is. It is similar to > current procedure with 13.2.2 and 13.2.3, which specify the use of IANA > and RIR records. It expands on the current procedures with 13.2.4, > allowing organizations to provide legal documentation of organizational > changes and/or the transfer of custody of a legacy address block. > > Sub-section 13.3 introduces policy enabling legitimate address holders > to request a very limited update to any Whois placeholders that might > exist for their legacy address block, so that the Whois will refer > queries to the authoritative directory service. It is expected that > ARIN will charge a fee for this update, but not require an ongoing > services agreement. ARIN is given the option of deleting placeholders > instead. > > Timetable for implementation: Immediately > > > > _______________________________________________ > 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 mueller at syr.edu Wed Feb 16 00:36:28 2011 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 16 Feb 2011 00:36:28 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > >ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address > >Blocks > > > >Proposal Originator: Benson Schliesser > > > >Proposal Version: 1 > > > >Date: 13 February 2011 > > > >Proposal type: New > > I don't remember when, but my opposition to this the last time (I > remember) this idea came around went something like this: > > 1. My membership in ARIN is funding my ability to find out who is > sending me packets. (Assuming no forging of the header.) > > 2. My membership in ARIN is ensuring my number resources are uniquely > assigned to me. > > 3. Having to register my contact information is not a privilege or a > right but a requirement and a responsibility. > > 4. I consider it ARIN's responsibility to keep track of "who" is > assigned "what" resources (even if that means federating responsibility > to other RIRs and NIRs). > > Removing information about legitimate resource holders that are not > paying ARIN (whether legitimately not paying or just behind on their > bills) is detrimental to those that are paying. [Milton L Mueller] This is an example of what I mean when I say the proposal is ahead of itself a bit, even though a very good initiative. Many people, such as Mr. Lewis of Neustar who commented above, may not fully understand why this is being proposed. The point is not to lose information about who is sending him packets, it is to make it possible for multiple entities to offer some of the services ARIN now offers, while retaining a consistent, integrated Whois. If the idea behind this proposal is fully realized, it would probably greatly enhance functions 1 and 4 without detracting at all from function 3 in his list above. That is why the proposal talks about placeholder entries that refer to other registrars. If we can "federate" that process among regional IRs I don't see why we can't further federate it to multiple registrars in the same region. When Mr. Lewis says that "My membership in ARIN is funding my ability to find out who is sending me packets" he may be overlooking the fact that his membership is also funding that ability for all kinds of other people as well, many of whom are free riders and/or have no contract with ARIN. As the proposal notes, this creates an ambiguous and unstable relationship between address allocation governance and the legacy holders, who account for nearly 40% of the ipv4 address space. I don't see any way to clean up that mess without doing something along the lines of what 133 proposes. > If the effort is to entice legacy space holders into joining ARIN, don't > try to penalize them. Give them a positive incentive. I don't see this proposal as involving any penalties. Indeed, it is the absence of this kind of thinking that consistently leads to proposals to force legacy holders into the ARIN regime. The (implied) incentive in 133 is that legacy holders can go to other service providers - assuming of course, that we retain a consistent and integrated whois that works across multiple service providers. > > At 13:17 -0600 2/14/11, Benson Schliesser wrote: > > >Having said that, I can understand that some legacy address holders > >will want to continue receiving services from ARIN, including Whois and > >in-addr DNS. The LRSA is one way to facilitate that without an > >ambiguous relationship. We may also want to propose an alternative > >mechanism, assuming that the LRSA is unappealing, but I have not > >included that in prop 133 at this time. > > The faulty logic here is in identifying who is "receiving services from > ARIN." The relying parties that hit the whois and DNS servers are not > only the holders of number resource but anyone that sends a packet in > the Internet. The vast majority of these people do not have any number > resources registered to them. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > =-=- > Edward Lewis > NeuStar You can leave a voice message at +1-571-434- > 5468 > > Me to infant son: "Waah! Waah! Is that all you can say? Waah?" > Son: "Waah!" > _______________________________________________ > 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 Feb 16 00:43:47 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 15 Feb 2011 23:43:47 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29C58@SUEX07-MBX-04.ad.syr.edu> References: <4D556387.3000300@arin.net> <75822E125BCB994F8446858C4B19F0D7143AF29C58@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Tue, Feb 15, 2011 at 10:48 PM, Milton L Mueller wrote: > Prop 132 seems reasonable to me. All I have heard against it are religious arguments. E.g., the statement below Too much collateral damage here, with regards to implicit understanding of what an ISP "customer" is. I am opposed to PP132. Clearly the NRPM requires allocations from ISPs be to customers for some good reasons-- there is a need for some contractual arrangement between ISP and address recipient. Otherwise the recipient of IP addresses might refuse to give allocated addresses back to the ISP, when the user no longer has a justified need for the addresses. If the ISP is not actually providing connectivity services, then they will not necessarily be informed when services are being terminated or re-designed so fewer addresses are actually required; this creates problems for keeping allocation based on justified need, and argues strongly for requiring IP addressing to be used with actual ISP connectivity services, as we have under current policy, or at least requiring the ISP collect paperwork on a regular basis to constantly re-validate the continuous need for the allocation. I oppose Prop 132 as unnecessary. We don't need a NRPM policy to say a customer is whatever the ISP defines a customer as. The ISP's ability to define customer should be contingent upon the ISP's definition of "customer" being reasonable. If ARIN is not allowed to reject unreasonable definitions, of "customer"; the applications this would allow may be hard to foresee. An "ISP" whose business is to be a proxy providing service for facilitating spammers aka "people who want to be anonymous", utilizing as many IP addresses as possible to evade RBLs, or whose sole existence is to sell or "lease" IP addresses, should probably not be allowed to force their choice definition of customer, if it conflicts with what the community sees an ISP customer as. I can see it already... "Applicant's Definition of customer: an individual e-mail that has subscribed (or we have subscribed without permission) to our e-mail marketing campaigns." > * unless, of course, you want ARIN deciding which uses and users are more worthy. It is beneficial that ARIN to be prepared to exercise good judgement if an ISP starts making strange claims about what they define their customer to be, or what they define their function as an ISP to be. Such as... "Every single user of the internet is declared to be my customer, therefore I need 3 /8s from you, ARIN, ASAP, because there are more than 3 * 2^24 internet users, and I need to have a host set aside for as many of my customers as possible, so they will be good to go on my proxy-server-for-hire service." There are some implied things about "customers"... such as customers are people who buy services from ISPs, have some form of contract with the ISP for those services, and pay substantially large maintenance/service fees on a frequent basis, and these are some implicit understandings of what a 'customer' is, I view, when I read the NRPM, but which are not recorded on paper. Connectivity, Transit, Hosting are some of the most common types of service a customer buys from an ISP which requires IP addresses for use with the ISP's service. There could be a few others, but not many others really. We do not need the NRPM to _either_ enumerate all possible types of customer or to completely abdicate oversight of "what a customer is" entirely to the ISP, or what all the possible services that require IP addresses might be. -- -JH From mysidia at gmail.com Wed Feb 16 00:58:13 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 15 Feb 2011 23:58:13 -0600 Subject: [arin-ppml] Fraud or not? In-Reply-To: References: <38911.1297831688@tristatelogic.com> Message-ID: On Tue, Feb 15, 2011 at 11:03 PM, Scott Leibrand wrote: > On Tue, Feb 15, 2011 at 8:48 PM, Ronald F. Guilmette > wrote: >> >> www.robtex.com says that AS10912 belongs to Internap. >> >> whois.arin.net says that there ain't no such AS. [snip] > > It looks like it's only the traditional whois tool that is failing.? The web > tool at arin.net reports it as part of INTERNAP-BLK, which covers ASNs 10910 > - 10913. I tried querying whois.arin.net and it shows it as INTERNAP-BLK..... $ telnet whois.arin.net nicname Connected to whois.arin.net. Escape character is '^]'. a 10912 # # The following results may also be obtained via: # http://whois.arin.net/rest/asns;q=10912?showDetails=true # ASNumber: 10910 - 10913 ASName: INTERNAP-BLK ASHandle: AS10910 RegDate: 1998-01-20 Updated: 1998-01-20 Ref: http://whois.arin.net/rest/asn/AS10910 OrgName: Internap Network Services Corporation .... From dogwallah at gmail.com Wed Feb 16 01:09:04 2011 From: dogwallah at gmail.com (McTim) Date: Wed, 16 Feb 2011 09:09:04 +0300 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> Message-ID: Milton, On Wed, Feb 16, 2011 at 8:36 AM, Milton L Mueller wrote: > [Milton L Mueller] > > This is an example of what I mean when I say the proposal is ahead of itself a bit, even though a very good initiative. Many people, such as Mr. Lewis of Neustar who commented above, may not fully understand why this is being proposed. As a former staff member of ARIN, I think Ed fully understands the issues. > > When Mr. Lewis says that "My membership in ARIN is funding my ability to find out who is sending me packets" he may be overlooking the fact that his membership is also funding that ability for all kinds of other people as well, many of whom are free riders and/or have no contract with ARIN. That is the whole point of a Public Network Information Database. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel From arin-ppml at westbrook.com Wed Feb 16 01:21:59 2011 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Tue, 15 Feb 2011 23:21:59 -0700 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Tue, Feb 15, 2011 at 22:36, Milton L Mueller wrote: > > If the effort is to entice legacy space holders into joining ARIN, don't > > try to penalize them. Give them a positive incentive. > > I don't see this proposal as involving any penalties. Indeed, it is the > absence of this kind of thinking that consistently leads to proposals to > force legacy holders into the ARIN regime. The (implied) incentive in 133 is > that legacy holders can go to other service providers - assuming of course, > that we retain a consistent and integrated whois that works across multiple > service providers. > Nothing's broken today with respect to the services in question. I can only envision additional costs, rigmarole, and coordination issues to come with a multiple-provider regime. Perhaps what's broken is that legacy holders like me don't pay -- at least, that seems to be the source of some significant outrage here. Unfortunately, the LRSA is a non-starter (to me and others I know) because of potential dilution of rights to the resource, as I've articulated before. Barring a change to that, and with no other way in, we're stuck. Were that different, I for one would cheerfully sign, pay, and enjoy more formal participation. All I can do today is cooperate by keeping my information current. Carrots and sticks are uncompelling to the legacy holder. $0.02, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From rfg at tristatelogic.com Wed Feb 16 01:47:26 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 15 Feb 2011 22:47:26 -0800 Subject: [arin-ppml] Fraud or not? In-Reply-To: Message-ID: <39779.1297838846@tristatelogic.com> In message , you wrote: >I tried querying whois.arin.net and it shows it as INTERNAP-BLK..... Well, so I guess they only broke the good old fashioned way of doing these things... you know... the way that all of my carefully crafted tools still do it. % whois -h whois.arin.net AS10912 # # Query terms are ambiguous. The query is assumed to be: # "a AS10912" # # Use "?" to get help. # No match found for AS10912. # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # From gbonser at seven.com Wed Feb 16 02:05:47 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 15 Feb 2011 23:05:47 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu> References: <4D595D12.4000602@arin.net> <75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> > "Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and > is putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical." If you think about it for a moment, you will come to realize that it is IPv4 itself that is placing the stability of the Internet at risk, not ARINs services rendered for those legacy assignments. The sooner everyone no longer uses v4 for anything, the sooner this becomes a moot point. The answer is not in a flurry of proposals for v4, the answer is in forgetting about v4 as quickly as possible. From mysidia at gmail.com Wed Feb 16 02:08:37 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 16 Feb 2011 01:08:37 -0600 Subject: [arin-ppml] Fraud or not? In-Reply-To: <39779.1297838846@tristatelogic.com> References: <39779.1297838846@tristatelogic.com> Message-ID: On Wed, Feb 16, 2011 at 12:47 AM, Ronald F. Guilmette wrote: > % whois -h whois.arin.net AS10912 [snip] Interesting... I would suspect that a search formatted like that might only work for an AS lookup by coincidence. if AS10912 happens to be exactly the same string of an AS Handle. Which in this case it's not. 10912 is in a block of AS numbers, and the AS handle's name for the block that shows up in the whois result as ASHandle: AS10910. Many other AS numbers just show ASxxxxxxx as the AS handle string. If the whois match is against the AS Handle string, this fact may lead some whois users making an incorrect assumption "Is WHOIS ASxxx" a reliable way to search for the WHOIS record for AS number xxx ? Apparently not. Perhaps less surprising behavior would be for WHOIS to default to lookup by AS number instead of AS handle string, when the input is 'a ASxxxxxx' > # > # Query terms are ambiguous. ?The query is assumed to be: > # ? ? "a AS10912" > # > # Use "?" to get help. > # > > No match found for AS10912. -- -JH From george.herbert at gmail.com Wed Feb 16 02:18:36 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 15 Feb 2011 23:18:36 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> References: <4D595D12.4000602@arin.net> <75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu> <5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> Message-ID: On Tue, Feb 15, 2011 at 11:05 PM, George Bonser wrote: >> "Specifically, this policy recognizes that absent an agreement such as >> the RSA or LRSA there is no formal relationship with legacy address >> holders. ?At present, however, ARIN continues to provide services to >> these organizations. ?This is done without compensation and > potentially >> in opposition to the legacy address holders' wishes. ?As a result of >> this behavior ARIN has created an illusion of implied authority that >> exposes ARIN to unacceptable levels of liability, is hindering the >> development of an open address market (driving it "underground"), and >> is putting the operational stability of the Internet at risk. ?As new >> services such as RPKI are contemplated this situation becomes even > more >> critical." > > If you think about it for a moment, you will come to realize that it is > IPv4 itself that is placing the stability of the Internet at risk, not > ARINs services rendered for those legacy assignments. ?The sooner > everyone no longer uses v4 for anything, the sooner this becomes a moot > point. > > The answer is not in a flurry of proposals for v4, the answer is in > forgetting about v4 as quickly as possible. The Internet will be Dead -> Kill the Internet ? -- -george william herbert george.herbert at gmail.com From gbonser at seven.com Wed Feb 16 02:32:01 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 15 Feb 2011 23:32:01 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <4D595D12.4000602@arin.net><75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu><5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13B59@RWC-EX1.corp.seven.com> > > The Internet will be Dead -> Kill the Internet ? > I don't think the internet is going to die because of whois entries. At best it is just a distraction. At worst, it is a sort of retroactive changing of the rules that have been in place for a very long time. If it hasn't already destroyed the Internet over the past 20 years of the general public being on it, it isn't going to break anything over the next few years. This almost seems to be like several ways of somehow getting hold of legacy address space or making it easier to hijack it. Forget it. Those addresses were issued in a different time under different rules and you can't just go changing the rules now just because we have run out of them. We have known this time was going to come for a very long time. Here we are. It is what it is. From owen at delong.com Wed Feb 16 02:41:40 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Feb 2011 23:41:40 -0800 Subject: [arin-ppml] Fraud or not? In-Reply-To: References: <38911.1297831688@tristatelogic.com> Message-ID: <643DF814-D2D2-4E91-9114-2FD563CE08BA@delong.com> I really wish ARIN would make the command line whois work as well as it used to instead of focusing all their energy on the (much less convenient much higher overhead from the user perspective) web-based one. Owen On Feb 15, 2011, at 9:03 PM, Scott Leibrand wrote: > On Tue, Feb 15, 2011 at 8:48 PM, Ronald F. Guilmette wrote: > > www.robtex.com says that AS10912 belongs to Internap. > > whois.arin.net says that there ain't no such AS. > > So, should I file a formal report charging Internap with fradulent use > of resources that are not actually assigned to them? Or is it more > likely that ARIN has simply (and entirely) misplaced the WHOIS record > for AS10912? > > It looks like it's only the traditional whois tool that is failing. The web tool at arin.net reports it as part of INTERNAP-BLK, which covers ASNs 10910 - 10913. > > http://whois.arin.net/rest/asn/AS10910/pft > > I suspect your message will be enough to get ARIN to fix the whois port 43 service shortly. :-) > > -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 owen at delong.com Wed Feb 16 02:57:38 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Feb 2011 23:57:38 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <4D595D12.4000602@arin.net> <75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu> <5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> Message-ID: <37C2FAF5-2F20-4EFC-999D-FBD40D359D86@delong.com> On Feb 15, 2011, at 11:18 PM, George Herbert wrote: > On Tue, Feb 15, 2011 at 11:05 PM, George Bonser wrote: >>> "Specifically, this policy recognizes that absent an agreement such as >>> the RSA or LRSA there is no formal relationship with legacy address >>> holders. At present, however, ARIN continues to provide services to >>> these organizations. This is done without compensation and >> potentially >>> in opposition to the legacy address holders' wishes. As a result of >>> this behavior ARIN has created an illusion of implied authority that >>> exposes ARIN to unacceptable levels of liability, is hindering the >>> development of an open address market (driving it "underground"), and >>> is putting the operational stability of the Internet at risk. As new >>> services such as RPKI are contemplated this situation becomes even >> more >>> critical." >> >> If you think about it for a moment, you will come to realize that it is >> IPv4 itself that is placing the stability of the Internet at risk, not >> ARINs services rendered for those legacy assignments. The sooner >> everyone no longer uses v4 for anything, the sooner this becomes a moot >> point. >> >> The answer is not in a flurry of proposals for v4, the answer is in >> forgetting about v4 as quickly as possible. > > The Internet will be Dead -> Kill the Internet ? > The Internet is the collection of independent networks that choose to interconnect. The protocol version number is changing. The legacy internet needs to be killed as quickly as possible, but, first the modern internet needs to be a further along in its construction process. The poster is right. Tampering with IPv4 policies and/or making changes to the situation with legacy holders beyond continuing to offer the LRSA is not especially helpful. Legacy issues become 100% moot when IPv4 is no longer the most common protocol on the internet. Owen > > -- > -george william herbert > george.herbert at gmail.com > _______________________________________________ > 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 Ed.Lewis at neustar.biz Wed Feb 16 08:16:19 2011 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Wed, 16 Feb 2011 08:16:19 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> Message-ID: At 0:36 -0500 2/16/11, Milton L Mueller wrote: >Many people, such as Mr. Lewis of Neustar who commented above, may not >fully understand why this is being proposed. That is likely to be the case. If though, as you say "many people" do not get this, the proposal needs to be edited to make clear the intentions. In the absence of clearly stated goals, many of us with a history in this space will assume the same reasons as the last time we read such a proposal. The words "as it is written" are significant when asked "Do you support this proposal as written." >When Mr. Lewis says that "My membership in ARIN is funding my ability to >find out who is sending me packets" he may be overlooking the fact that his >membership is also funding that ability for all kinds of other people as well, >many of whom are free riders and/or have no contract with ARIN. FWIW, I am aware others are free riders. I don't care, so what? I'm concerned about my access to the data. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!" From cgrundemann at gmail.com Wed Feb 16 10:34:56 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 16 Feb 2011 08:34:56 -0700 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement Message-ID: Hail PPML! I am the primary AC shepherd for ARIN-prop-126: Compliance Requirement and I would like to hear your comments and feedback on this new version of the proposal (included below). If the community is happy with this text; I will take the necessary steps as shepherd to advance it to the next stage of the process, which would be getting the AC to promote it to a draft policy (https://www.arin.net/policy/pdp.html). One thing to note: This proposal updates existing policy and as such not all of the text is new or a change. Please review the current policy language when evaluating this proposal: https://www.arin.net/policy/nrpm.html#twelve. Thanks in advance for your input! Cheers, ~Chris #### ARIN-prop-126: Compliance Requirement Proposal Originator: Marla Azinger Proposal Version: 2 Date: 16 February 2011 Proposal type: new Policy term: permanent Policy statement: Resource Review Update the following NRPM Sections: 12.4 - Update to: Organizations found by ARIN to be out of compliance with current ARIN policy shall be required to update reassignment information or return resources as needed to bring them into (or reasonably close to) compliance. 1. The degree to which an organization may remain out of compliance shall be based on the reasonable judgment of the ARIN staff and shall balance all facts known, including the organization's utilization rate, available address pool, and other factors as appropriate so as to avoid forcing returns which will result in near-term additional requests or unnecessary route de-aggregation. 2. To the extent possible, entire blocks should be returned. Partial address blocks shall be returned in such a way that the portion retained will comprise a single aggregate block. (leave 12.5 as is) 12.6 - Update to: Except in cases of fraud, an organization shall be given a minimum of thirty (30) days to respond. If an organization does not respond within those thirty (30) days, ARIN may cease providing reverse DNS services to that organization. If progress of resource returns or record corrections is not visible within sixty (60) days after correspondence with ARIN began, ARIN will cease providing reverse DNS services for the resources in question. At any time after ninety (90) days have passed, ARIN may initiate resource revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer term with the organization if ARIN believes the organization is working in good faith to substantially restore compliance and has a valid need for additional time to renumber out of the affected blocks. Rationale: Version 2 addresses several staff and legal concerns with the original text of this policy by clarifying the language and making it more concrete. To date the community has not documented or firmly established use of an effective enforcement mechanism. This policy will support current policy and compel those who are allocated ARIN resources to maintain the proper WHOIS records in accordance with ARIN NRPM. While it is recognized this is not an absolute solution to ensure compliance, it is the best method under current ARIN policies. Timetable for implementation: Immediate From mueller at syr.edu Wed Feb 16 10:56:43 2011 From: mueller at syr.edu (Milton L Mueller) Date: Wed, 16 Feb 2011 10:56:43 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF29C80@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > When Mr. Lewis says that "My membership in ARIN is funding my ability > to find out who is sending me packets" he may be overlooking the fact > that his membership is also funding that ability for all kinds of other > people as well, many of whom are free riders and/or have no contract > with ARIN. > > That is the whole point of a Public Network Information Database. > [Milton L Mueller] McTim, The issue is not "Can anyone query the Whois and get information out of it?" The issue is, rather, what makes ARIN's Whois authoritative and what does it mean for it to be authoritative, especially when a large portion of the registrations are not maintained or authorized by the actual ip address block holder? What kinds of obligations do ip address holders incur when they register in ARIN's Whois, as opposed to those who don't? How can an authoritative Whois database be maintained, updated and relied upon for policy purposes when many legacy holders don't even participate in ARIN? That's the issue, and imho prop-133 addresses it (no pun intended) head on and therefore is a good initiative. From dogwallah at gmail.com Wed Feb 16 11:05:31 2011 From: dogwallah at gmail.com (McTim) Date: Wed, 16 Feb 2011 19:05:31 +0300 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: Hail Chris Grundemann! I like this proposal, I support it as written. -- Cheers, McTim "A name indicates what we seek. An address indicates where it is. A route indicates how we get there."? Jon Postel On Wed, Feb 16, 2011 at 6:34 PM, Chris Grundemann wrote: > Hail PPML! > > I am the primary AC shepherd for ARIN-prop-126: Compliance Requirement > and I would like to hear your comments and feedback on this new > version of the proposal (included below). If the community is happy > with this text; I will take the necessary steps as shepherd to advance > it to the next stage of the process, which would be getting the AC to > promote it to a draft policy (https://www.arin.net/policy/pdp.html). > > One thing to note: This proposal updates existing policy and as such > not all of the text is new or a change. Please review the current > policy language when evaluating this proposal: > https://www.arin.net/policy/nrpm.html#twelve. > > Thanks in advance for your input! > > Cheers, > ~Chris > > #### > > ARIN-prop-126: Compliance Requirement > > Proposal Originator: Marla Azinger > > Proposal Version: 2 > > Date: 16 February 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Resource Review > Update the following NRPM Sections: > > 12.4 - Update to: Organizations found by ARIN to be out of compliance > with current ARIN policy shall be required to update reassignment > information or return resources as needed to bring them into (or > reasonably close to) compliance. > > 1. The degree to which an organization may remain out of compliance > shall be based on the reasonable judgment of the ARIN staff and shall > balance all facts known, including the organization's utilization > rate, available address pool, and other factors as appropriate so as > to avoid forcing returns which will result in near-term additional > requests or unnecessary route de-aggregation. > 2. To the extent possible, entire blocks should be returned. Partial > address blocks shall be returned in such a way that the portion > retained will comprise a single aggregate block. > > (leave 12.5 as is) > > 12.6 - Update to: Except in cases of fraud, an organization shall be > given a minimum of thirty (30) days to respond. If an organization > does not respond within those thirty (30) days, ARIN may cease > providing reverse DNS services to that organization. If progress of > resource returns or record corrections is not visible within sixty > (60) days after correspondence with ARIN began, ARIN will cease > providing reverse DNS services for the resources in question. At any > time after ninety (90) days have passed, ARIN may initiate resource > revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer > term with the organization if ARIN believes the organization is > working in good faith to substantially restore compliance and has a > valid need for additional time to renumber out of the affected blocks. > > Rationale: > > Version 2 addresses several staff and legal concerns with the original > text of this policy by clarifying the language and making it more > concrete. > > To date the community has not documented or firmly established use of > an effective enforcement mechanism. This policy will support current > policy and compel those who are allocated ARIN resources to maintain > the proper WHOIS records in accordance with ARIN NRPM. While it is > recognized this is not an absolute solution to ensure compliance, it > is the best method under current ARIN policies. > > Timetable for implementation: Immediate > _______________________________________________ > 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 Wed Feb 16 11:19:35 2011 From: jcurran at arin.net (John Curran) Date: Wed, 16 Feb 2011 16:19:35 +0000 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29C80@SUEX07-MBX-04.ad.syr.edu> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29C80@SUEX07-MBX-04.ad.syr.edu> Message-ID: <464B3435-F206-4E1B-ABE7-551F5D38BCC7@corp.arin.net> On Feb 16, 2011, at 10:56 AM, Milton L Mueller wrote: > The issue is, rather, what makes ARIN's Whois authoritative and what does it mean for it to be authoritative, especially when a large portion of the registrations are not maintained or authorized by the actual ip address block holder? To the contrary, many registrations have been updated by the address holders, even if they do not participate in ARIN policy development (you do not need to have a registration services agreement with ARIN as a legacy holder to update your information - this was a very conscious decision on the part of the community given the importance of having accurate registration data) > What kinds of obligations do ip address holders incur when they register in ARIN's Whois, as opposed to those who don't? How can an authoritative Whois database be maintained, updated and relied upon for policy purposes when many legacy holders don't even participate in ARIN? Legacy address holders are already registered in ARIN's Whois, and are subject to the same policies as any other resource holders. FYI, /John John Curran President and CEO ARIN From farmer at umn.edu Wed Feb 16 11:47:54 2011 From: farmer at umn.edu (David Farmer) Date: Wed, 16 Feb 2011 10:47:54 -0600 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: <4D5BFFBA.7040700@umn.edu> I support the the intended result of this proposal and this is text is an improvement. However, I have a problem with the removal of DNS service without some kind of signal to third parties. As a third party under this proposal all I see is reverse DNS breaking and have no clue why. Is it an action by ARIN, a lame delegation, a temporary problem of some other kind. One option would be some kind of status field associated with the Whois record stating the DNS service is suspended. Another option, could be to change the DNS pointer records in Whois and the production DNS, referring to a DNS service operated by ARIN for suspended DNS. Maybe with a wildcard returning "Suspended.DNS.ARIN.net" as the PTR record for all recursive look-ups for resources that have the DNS suspended. This provides in-band feed back and feedback through Whois in the nameserver field. A final option, ARIN could simply publish a list of resource for which it has suspended DNS. This is my least preferred option, it is out-of band and I have to go look someplace else then Whois. But it might be a good stop-gap solution allowing ARIN time to implement one or both of the above solutions. Breaking DNS in a way that is invisible to third parties is not good operational practice. In this case the cure might be worse then the disease. So find a way to operationally signal that DNS has been suspended then I'll support the proposal. This might not require any change to the policy text itself, this may simply need to be an implementation note in the rationale. On 2/16/11 09:34 CST, Chris Grundemann wrote: > Hail PPML! > > I am the primary AC shepherd for ARIN-prop-126: Compliance Requirement > and I would like to hear your comments and feedback on this new > version of the proposal (included below). If the community is happy > with this text; I will take the necessary steps as shepherd to advance > it to the next stage of the process, which would be getting the AC to > promote it to a draft policy (https://www.arin.net/policy/pdp.html). > > One thing to note: This proposal updates existing policy and as such > not all of the text is new or a change. Please review the current > policy language when evaluating this proposal: > https://www.arin.net/policy/nrpm.html#twelve. > > Thanks in advance for your input! > > Cheers, > ~Chris > > #### > > ARIN-prop-126: Compliance Requirement > > Proposal Originator: Marla Azinger > > Proposal Version: 2 > > Date: 16 February 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Resource Review > Update the following NRPM Sections: > > 12.4 - Update to: Organizations found by ARIN to be out of compliance > with current ARIN policy shall be required to update reassignment > information or return resources as needed to bring them into (or > reasonably close to) compliance. > > 1. The degree to which an organization may remain out of compliance > shall be based on the reasonable judgment of the ARIN staff and shall > balance all facts known, including the organization's utilization > rate, available address pool, and other factors as appropriate so as > to avoid forcing returns which will result in near-term additional > requests or unnecessary route de-aggregation. > 2. To the extent possible, entire blocks should be returned. Partial > address blocks shall be returned in such a way that the portion > retained will comprise a single aggregate block. > > (leave 12.5 as is) > > 12.6 - Update to: Except in cases of fraud, an organization shall be > given a minimum of thirty (30) days to respond. If an organization > does not respond within those thirty (30) days, ARIN may cease > providing reverse DNS services to that organization. If progress of > resource returns or record corrections is not visible within sixty > (60) days after correspondence with ARIN began, ARIN will cease > providing reverse DNS services for the resources in question. At any > time after ninety (90) days have passed, ARIN may initiate resource > revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer > term with the organization if ARIN believes the organization is > working in good faith to substantially restore compliance and has a > valid need for additional time to renumber out of the affected blocks. > > Rationale: > > Version 2 addresses several staff and legal concerns with the original > text of this policy by clarifying the language and making it more > concrete. > > To date the community has not documented or firmly established use of > an effective enforcement mechanism. This policy will support current > policy and compel those who are allocated ARIN resources to maintain > the proper WHOIS records in accordance with ARIN NRPM. While it is > recognized this is not an absolute solution to ensure compliance, it > is the best method under current ARIN policies. > > Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From hannigan at gmail.com Wed Feb 16 11:53:25 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 16 Feb 2011 11:53:25 -0500 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: On Wed, Feb 16, 2011 at 10:34 AM, Chris Grundemann wrote: > Hail PPML! > > I am the primary AC shepherd for ARIN-prop-126: Compliance Requirement > and I would like to hear your comments and feedback on this new > version of the proposal (included below). If the community is happy > with this text; I will take the necessary steps as shepherd to advance > it to the next stage of the process, which would be getting the AC to > promote it to a draft policy (https://www.arin.net/policy/pdp.html). > > One thing to note: This proposal updates existing policy and as such > not all of the text is new or a change. Please review the current > policy language when evaluating this proposal: > https://www.arin.net/policy/nrpm.html#twelve. > > Thanks in advance for your input! > > Cheers, > ~Chris > > #### > > ARIN-prop-126: Compliance Requirement > > Proposal Originator: Marla Azinger > > Proposal Version: 2 > > Date: 16 February 2011 > > Proposal type: new > > Policy term: permanent > > Policy statement: > > Resource Review > Update the following NRPM Sections: > > 12.4 - Update to: Organizations found by ARIN to be out of compliance > with current ARIN policy shall be required to update reassignment > information or return resources as needed to bring them into (or > reasonably close to) compliance. > > 1. The degree to which an organization may remain out of compliance > shall be based on the reasonable judgment of the ARIN staff and shall > balance all facts known, including the organization's utilization > rate, available address pool, and other factors as appropriate so as > to avoid forcing returns which will result in near-term additional > requests or unnecessary route de-aggregation. > 2. To the extent possible, entire blocks should be returned. Partial > address blocks shall be returned in such a way that the portion > retained will comprise a single aggregate block. > > (leave 12.5 as is) > > 12.6 - Update to: Except in cases of fraud, an organization shall be > given a minimum of thirty (30) days to respond. If an organization > does not respond within those thirty (30) days, ARIN may cease So they can take up to a minimum of thirty days to respond, and if they exceed the minimum they get the hammer dropped on them? You mean maximum? > providing reverse DNS services to that organization. If progress of > resource returns or record corrections is not visible within sixty > (60) days after correspondence with ARIN began, ARIN will cease > providing reverse DNS services for the resources in question. At any > time after ninety (90) days have passed, ARIN may initiate resource > revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer > term with the organization if ARIN believes the organization is > working in good faith to substantially restore compliance and has a > valid need for additional time to renumber out of the affected blocks. It's expensive and complex to respond to section 12 audits. This increases that expense for member orgs. It gives the Corporation too much leeway to do harm to its members, more than the substantial amount that we already allow through "discretion". Discretion also results in unpredictability. Policy should be as predictable as possible. That "discretion" could result in significant litigation and additional potentially unnecessary legal expenses. [2] These audits take time and people. Some of these audits also "appear" to be being conducted with what might be questionable[1] "probable cause" as a result of tip-line like fraud reporting activity. A majority of the fraud reports seem to be false positives. Revocation is the ultimate hammer and ARIN already has that power. Not in favor of this proposal. Section 12 is already ripe for abuse. ARIN should never shut off reverse unless a network is revoked since the possible collateral damage is too high and will likely cause problems for many others depending upon who gets crunked with this proposal. I would support a cap on answer-days to the path of revocation, but this proposal appears to be overkill based on the current data points that we have demonstrating a real problem (none). Best, -M< 1. https://www.arin.net/resources/fraud/results/third_quarter_2010.html 2. https://www.arin.net/about_us/corp_docs/budget.html In 2010, ARIN budgeted .5M for legal expenses. ARIN has recently suggested that some proposals may interfere with fee reductions for members. The 2011 budget is not posted and I have no idea what that number will be or what the corporation thinks performance to that number will be). From gbonser at seven.com Wed Feb 16 12:03:01 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 16 Feb 2011 09:03:01 -0800 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13B5E@RWC-EX1.corp.seven.com> > > > > 12.4 - Update to: Organizations found by ARIN to be out of compliance > > with current ARIN policy shall be required to update reassignment > > information or return resources as needed to bring them into (or > > reasonably close to) compliance. > > > > 1. The degree to which an organization may remain out of compliance > > shall be based on the reasonable judgment of the ARIN staff and shall > > balance all facts known, including the organization's utilization > > rate, available address pool, and other factors as appropriate so as > > to avoid forcing returns which will result in near-term additional > > requests or unnecessary route de-aggregation. > > 2. To the extent possible, entire blocks should be returned. Partial > > address blocks shall be returned in such a way that the portion > > retained will comprise a single aggregate block. > > > > (leave 12.5 as is) > > > > 12.6 - Update to: Except in cases of fraud, an organization shall be > > given a minimum of thirty (30) days to respond. If an organization > > does not respond within those thirty (30) days, ARIN may cease > > providing reverse DNS services to that organization. If progress of > > resource returns or record corrections is not visible within sixty > > (60) days after correspondence with ARIN began, ARIN will cease > > providing reverse DNS services for the resources in question. At any > > time after ninety (90) days have passed, ARIN may initiate resource > > revocation as allowed in paragraph 12.5. ARIN shall negotiate a > longer > > term with the organization if ARIN believes the organization is > > working in good faith to substantially restore compliance and has a > > valid need for additional time to renumber out of the affected > blocks. > > > > Rationale: > > > > Version 2 addresses several staff and legal concerns with the > original > > text of this policy by clarifying the language and making it more > > concrete. > > > > To date the community has not documented or firmly established use of > > an effective enforcement mechanism. This policy will support current > > policy and compel those who are allocated ARIN resources to maintain > > the proper WHOIS records in accordance with ARIN NRPM. While it is > > recognized this is not an absolute solution to ensure compliance, it > > is the best method under current ARIN policies. > > > > Timetable for implementation: Immediate So what this seems to be saying is that in addition to the original conditions that existed when address blocks were first issued, some continuing auditing is to be done which continuously audits members to ensure that they constantly meet the issuing requirements of the blocks they hold and if not, they will be revoked? So one must meet the allocation policy in perpetuity? I am not sure this is good policy for a few reasons. The primary reason being that going forward, this policy will apply mostly for IPv6 assignments. Placing this policy in the context of IPv6 seems that is causes a lot of work for very little gain to the community. The only likely result is additional "churn" in v4 assignments which will act to further destabilize things in the v4 space after runout. In addition, reading this portion closely: > > 1. The degree to which an organization may remain out of compliance > > shall be based on the reasonable judgment of the ARIN staff and shall > > balance all facts known, including the organization's utilization > > rate, available address pool, and other factors as appropriate so as > > to avoid forcing returns which will result in near-term additional > > requests or unnecessary route de-aggregation. > > 2. To the extent possible, entire blocks should be returned. Partial > > address blocks shall be returned in such a way that the portion > > retained will comprise a single aggregate block. The available address pool is basically "unlimited" and probably will be for the next several decades. I would sooner favor a resolution that deprecated the issuing of any IPv4 addresses and says that after ARIN runs out of addresses for general issue, they would no longer issue any more for any reason except "critical infrastructure" and ipv6 migration purposes. In other words, after ARIN runout, new v4 addresses allocations will be issued only for v6 migration and those allocations would be temporary (say 2 to 5 years) and would then have to be returned. Any new policy impacting address allocations must, in my opinion, be viewed in the context of IPv6 and I don't see how this policy benefits the community in that context. If it is to apply only to v4 addresses, it must state so else it applies to all address space. And even then I would be more likely to support a proposal that says "once they are gone, they are gone". From jcurran at arin.net Wed Feb 16 12:14:17 2011 From: jcurran at arin.net (John Curran) Date: Wed, 16 Feb 2011 17:14:17 +0000 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: <6109624E-D00E-4AD4-9A5F-7E083B22123F@corp.arin.net> On Feb 16, 2011, at 11:53 AM, Martin Hannigan wrote: > It's expensive and complex to respond to section 12 audits. This > increases that expense for member orgs. This is definitely an accurate statement; we have heard from multiple organizations that responding to an audit can involve quite a significant amount of work. It also requires a similar level on behalf of the ARIN staff to process the information received. > It gives the Corporation too much leeway to do harm to its members, > more than the substantial amount that we already allow through > "discretion". Discretion also results in unpredictability. Policy > should be as predictable as possible. Fully agreed as well. To the extent that policy requires staff discretion, it creates significantly more exposure then those policy statements that do not require staff discretion. > These audits take time and people. Some of these audits also "appear" > to be being conducted with what might be questionable[1] "probable > cause" as a result of tip-line like fraud reporting activity. A > majority of the fraud reports seem to be false positives. Revocation > is the ultimate hammer and ARIN already has that power. The false positive rate is to be expected, as we tend to error on the side of caution given the potential impact, and our standards for clear violations is likely quite higher than many of those reporting issues. I have no view on the policy proposal itself, but wanted to make sure that the PPML community was apprised of the validity and of the above statements. FYI, /John John Curran President and CEO ARIN From hannigan at gmail.com Wed Feb 16 12:16:36 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 16 Feb 2011 12:16:36 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses In-Reply-To: References: <0d3d01cbbe4e$a21c95e0$e655c1a0$@ca> Message-ID: On Mon, Jan 31, 2011 at 8:05 AM, STARNES, CURTIS wrote: > Thanks Bill, > I went back and re-read this section before I received your email and picked your explanation up on the second reading. > It makes sense, from an ISP's stand point, allocating resources rather than my just consuming resources from an end-users perspective and the differences in the yearly fees; $500.00 is not much compared to what ISP's have to pay in yearly recurring costs in ARIN fees. > > Thanks for the explanation. ?As an end-user, the verbage that makes the resources available to members, I would be opposed to. There's been an update which hopefully addresses your concern. But to be more precise as to why this is needed, let's look at quote from John Curran to the press related to 45/8: "ARIN will accept the returned space and not reissue it for a short period, per existing operational procedure. After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need, as appropriate. --John Curran, CEO, ARIN That is clearly not a commitment to take legacy addresses and add them for us to ARIN's inventory. This proposal changes this statement to the positive, and if 131 were policy today John Curran may have said what he did say above sans "as appropriate". Polluting this proposal with linkage to non legacy IPv4 policy seems unwise and business as usual with respect to v4 policy tinkering. This proposal only affects members in that it "may" result in additional addresses being tacked on to the almost ~170M addresses already in inventory and provide additional transition space where needed. It also encourages the multiple parties with competing global policies to work it out and make it happen, or not. Best, -M< From owen at delong.com Wed Feb 16 12:22:46 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 09:22:46 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29C80@SUEX07-MBX-04.ad.syr.edu> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29C80@SUEX07-MBX-04.ad.syr.edu> Message-ID: <6FC41E6A-CF3C-4C9C-A272-53B7E910B631@delong.com> On Feb 16, 2011, at 7:56 AM, Milton L Mueller wrote: > > >> -----Original Message----- >>> When Mr. Lewis says that "My membership in ARIN is funding my ability >> to find out who is sending me packets" he may be overlooking the fact >> that his membership is also funding that ability for all kinds of other >> people as well, many of whom are free riders and/or have no contract >> with ARIN. >> >> That is the whole point of a Public Network Information Database. >> > [Milton L Mueller] > > McTim, > The issue is not "Can anyone query the Whois and get information out of it?" > > The issue is, rather, what makes ARIN's Whois authoritative and what does it mean for it to be authoritative, especially when a large portion of the registrations are not maintained or authorized by the actual ip address block holder? What kinds of obligations do ip address holders incur when they register in ARIN's Whois, as opposed to those who don't? How can an authoritative Whois database be maintained, updated and relied upon for policy purposes when many legacy holders don't even participate in ARIN? That's the issue, and imho prop-133 addresses it (no pun intended) head on and therefore is a good initiative. > Speaking only for myself... Milton, I think McTim actually has the correct issue. However, to address your chosen issue... ARIN's whois is authoritative only for the ARIN service region and only within the context of the cooperating RIRs and IANA system. You are welcome to run an authoritative whois server any time you want and it will be authoritative for the data that it contains. Anyone else can also run an authoritative whois server. I do not think the term authoritative has much meaning in this context. If you are asking, instead, what makes ARIN's Whois meaningful or more valuable than other whois listings, then, the answer is simply the number of constituents that choose to regard the data in ARIN whois as meaningful and legitimate, just as what makes IANA's allocations to RIRs meaningful is that the RIRs and the rest of the industry choose to recognize that as meaningful. The internet is not a single homogeneous entity. It is a collection of independently owned and operated networks that choose to cooperate and exchange packets based on a pre-arranged set of protocols and behaviors. Any of those networks is welcome to adopt its own numbering scheme or system of allocations. However, they do so at the risk that some or all of the networks to which they are connected may choose to no longer connect to them. Quite simply, the internet works because people choose to cooperate. If you don't like the way this internet works, you are welcome to start your own somewhere else. Metcalfe's law says that building value in your internet may initially be difficult, but, if it is truly so much better as you claim it would be, I'm sure you'll have ISPs flocking to it in no time. Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Wed Feb 16 12:38:52 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 09:38:52 -0800 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: <4D5BFFBA.7040700@umn.edu> References: <4D5BFFBA.7040700@umn.edu> Message-ID: <4881F12D-80AA-41BA-A710-9647A3683061@delong.com> On Feb 16, 2011, at 8:47 AM, David Farmer wrote: > I support the the intended result of this proposal and this is text is an improvement. However, I have a problem with the removal of DNS service without some kind of signal to third parties. > > As a third party under this proposal all I see is reverse DNS breaking and have no clue why. Is it an action by ARIN, a lame delegation, a temporary problem of some other kind. > That's true in any resource revocation today, so, I'm not sure what you perceive as different. It isn't a lame delegation because there are no NS records to be lame. You see that there are no NS records, you can be reasonably certain it is action by ARIN, no? > One option would be some kind of status field associated with the Whois record stating the DNS service is suspended. > I wouldn't oppose this, but, that's an operational matter ARIN can choose to implement, not really a policy issue. > Another option, could be to change the DNS pointer records in Whois and the production DNS, referring to a DNS service operated by ARIN for suspended DNS. Maybe with a wildcard returning "Suspended.DNS.ARIN.net" as the PTR record for all recursive look-ups for resources that have the DNS suspended. This provides in-band feed back and feedback through Whois in the nameserver field. > I think this is a very bad idea. Turning off DNS is one thing. Hijacking it is another. A similar tactic was tried by Network Solutions once upon a time to make revenue out of typos. It was not well liked by the community. > A final option, ARIN could simply publish a list of resource for which it has suspended DNS. This is my least preferred option, it is out-of band and I have to go look someplace else then Whois. But it might be a good stop-gap solution allowing ARIN time to implement one or both of the above solutions. > I wouldn't oppose this, but, again, it's an operational matter. > Breaking DNS in a way that is invisible to third parties is not good operational practice. In this case the cure might be worse then the disease. So find a way to operationally signal that DNS has been suspended then I'll support the proposal. This might not require any change to the policy text itself, this may simply need to be an implementation note in the rationale. > How is a lack of NS records invisible to third parties? I must be missing something in your thinking process here. Owen > On 2/16/11 09:34 CST, Chris Grundemann wrote: >> Hail PPML! >> >> I am the primary AC shepherd for ARIN-prop-126: Compliance Requirement >> and I would like to hear your comments and feedback on this new >> version of the proposal (included below). If the community is happy >> with this text; I will take the necessary steps as shepherd to advance >> it to the next stage of the process, which would be getting the AC to >> promote it to a draft policy (https://www.arin.net/policy/pdp.html). >> >> One thing to note: This proposal updates existing policy and as such >> not all of the text is new or a change. Please review the current >> policy language when evaluating this proposal: >> https://www.arin.net/policy/nrpm.html#twelve. >> >> Thanks in advance for your input! >> >> Cheers, >> ~Chris >> >> #### >> >> ARIN-prop-126: Compliance Requirement >> >> Proposal Originator: Marla Azinger >> >> Proposal Version: 2 >> >> Date: 16 February 2011 >> >> Proposal type: new >> >> Policy term: permanent >> >> Policy statement: >> >> Resource Review >> Update the following NRPM Sections: >> >> 12.4 - Update to: Organizations found by ARIN to be out of compliance >> with current ARIN policy shall be required to update reassignment >> information or return resources as needed to bring them into (or >> reasonably close to) compliance. >> >> 1. The degree to which an organization may remain out of compliance >> shall be based on the reasonable judgment of the ARIN staff and shall >> balance all facts known, including the organization's utilization >> rate, available address pool, and other factors as appropriate so as >> to avoid forcing returns which will result in near-term additional >> requests or unnecessary route de-aggregation. >> 2. To the extent possible, entire blocks should be returned. Partial >> address blocks shall be returned in such a way that the portion >> retained will comprise a single aggregate block. >> >> (leave 12.5 as is) >> >> 12.6 - Update to: Except in cases of fraud, an organization shall be >> given a minimum of thirty (30) days to respond. If an organization >> does not respond within those thirty (30) days, ARIN may cease >> providing reverse DNS services to that organization. If progress of >> resource returns or record corrections is not visible within sixty >> (60) days after correspondence with ARIN began, ARIN will cease >> providing reverse DNS services for the resources in question. At any >> time after ninety (90) days have passed, ARIN may initiate resource >> revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer >> term with the organization if ARIN believes the organization is >> working in good faith to substantially restore compliance and has a >> valid need for additional time to renumber out of the affected blocks. >> >> Rationale: >> >> Version 2 addresses several staff and legal concerns with the original >> text of this policy by clarifying the language and making it more >> concrete. >> >> To date the community has not documented or firmly established use of >> an effective enforcement mechanism. This policy will support current >> policy and compel those who are allocated ARIN resources to maintain >> the proper WHOIS records in accordance with ARIN NRPM. While it is >> recognized this is not an absolute solution to ensure compliance, it >> is the best method under current ARIN policies. >> >> Timetable for implementation: Immediate >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 Wed Feb 16 12:49:42 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 09:49:42 -0800 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: References: Message-ID: >> >> 12.6 - Update to: Except in cases of fraud, an organization shall be >> given a minimum of thirty (30) days to respond. If an organization >> does not respond within those thirty (30) days, ARIN may cease > > So they can take up to a minimum of thirty days to respond, and if > they exceed the minimum they get the hammer dropped on them? You mean > maximum? > I agree this needs some wordsmithing. I think the intent is: 1. They get at least 30 days to respond. (ARIN can allow longer). 2. If no response is received after at least 30 days, ARIN can "drop the hammer" as you put it at any time thereafter. >> providing reverse DNS services to that organization. If progress of >> resource returns or record corrections is not visible within sixty >> (60) days after correspondence with ARIN began, ARIN will cease >> providing reverse DNS services for the resources in question. At any >> time after ninety (90) days have passed, ARIN may initiate resource >> revocation as allowed in paragraph 12.5. ARIN shall negotiate a longer >> term with the organization if ARIN believes the organization is >> working in good faith to substantially restore compliance and has a >> valid need for additional time to renumber out of the affected blocks. > > It's expensive and complex to respond to section 12 audits. This > increases that expense for member orgs. It gives the Corporation too > much leeway to do harm to its members, more than the substantial > amount that we already allow through "discretion". Discretion also > results in unpredictability. Policy should be as predictable as > possible. That "discretion" could result in significant litigation and > additional potentially unnecessary legal expenses. [2] > I'm not sure that this term member means what you think it means. The vast majority of resource recipients from ARIN are not ARIN members. This does not increase the expense of a section 12 audit. It might make one more likely, but, it does not increase the cost of performing one. The discretion given here is to allow ARIN to be kinder to an organization that appears to be trying to cooperate with policy. I do not understand how you think that ARIN is more likely to get sued for being more patient with a cooperative organization. > These audits take time and people. Some of these audits also "appear" > to be being conducted with what might be questionable[1] "probable > cause" as a result of tip-line like fraud reporting activity. A > majority of the fraud reports seem to be false positives. Revocation > is the ultimate hammer and ARIN already has that power. > Since the vast majority of fraud reports are dismissed as out of scope without conducting a section 12 audit, your false positive claim is both accurate and meaningless. Of those not out of scope that did result in section 12 actions, I count 6 that resulted in appropriate and necessary policy action (not false positives) and 5 that were found to be false positives. Last time I looked, 5 < 6, so, the majority of the section 12 audits listed in your referenced URL are not false positives. > Not in favor of this proposal. Section 12 is already ripe for abuse. > ARIN should never shut off reverse unless a network is revoked since > the possible collateral damage is too high and will likely cause > problems for many others depending upon who gets crunked with this > proposal. I would support a cap on answer-days to the path of > revocation, but this proposal appears to be overkill based on the > current data points that we have demonstrating a real problem (none). > I have no problem with updating the policy to revoke the resources rather than merely terminate DNS. I think that the author considered suspending DNS as a kinder, gentler first step towards revocation. It sounds like you feel that revocation should be the immediate action, instead. Perhaps this viewpoint explains the idea that ARIN could get sued for being nice as well. Owen > > Best, > > -M< > > 1. https://www.arin.net/resources/fraud/results/third_quarter_2010.html > > 2. https://www.arin.net/about_us/corp_docs/budget.html > > In 2010, ARIN budgeted .5M for legal expenses. ARIN has recently > suggested that some proposals may interfere with fee reductions for > members. The 2011 budget is not posted and I have no idea what that > number will be or what the corporation thinks performance to that > number will be). > _______________________________________________ > 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 Wed Feb 16 12:54:17 2011 From: bill at herrin.us (William Herrin) Date: Wed, 16 Feb 2011 12:54:17 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: References: <1110214150225.31932B-100000@Ives.egh.com> <5A6E3C2D-E60D-4F03-AB81-29046F51945B@wisc.edu> <7BF8BE7E-9A86-40EF-B5B2-E741BC55232E@queuefull.net> Message-ID: On Tue, Feb 15, 2011 at 3:12 PM, Edward Lewis wrote: > Thinking that legacy holders are completely free to do as they wish is > false. ?For example, I (can only) believe they had to submit to being in > WhoIs from the start. ?The conditions under which Postel assigned resources > are just not well documented, the "strings attached" are unknown. ?It could > be that all of the resources are reclaimable under some obscure > interpretation of GFE (government furnished equipment) rules. ?This was > mentioned by ARIN's legal council at a meeting a few years ago. Some counter-arguments include: Laches - by failing to require legacy registrants to enter into a contract (or even make contact) for a decade and a half, ARIN has legally conceded that those registrants' control of their number resources are not governed by ARIN. Tortious interference - canceling an IP address registration is likely to interfere with the registrant's contract with his ISP to connect him to the global Internet including the RDNS that helps specific applications go. Absent clear legal standing for such a change in behavior, ARIN could be liable for direct and indirect monetary damages which occur as a result. There's a murky line here between "failing to proactively provide registration services" that ARIN probably isn't compelled to do and obstructing maintenance of the registration which probably gets ARIN into trouble. If ARIN is asked to explore it in detail (litigiously), they will win some and lose some. The fight alone could consume the annual budget even before paying out on the "some" that they lose. IMHO, better to ask ARIN to retreat a safe distance from that line. Which is basically where things stand now without this proposal and, in part, why I'm opposed to the proposal. If anyone's interested, here are the forms from over the years (the ones I could find) that specified (or failed to) the obligations and expectations placed on the legacy registrants: http://bill.herrin.us/network/templates/ Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Wed Feb 16 13:10:30 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Feb 2011 10:10:30 -0800 Subject: [arin-ppml] Fraud or not? In-Reply-To: <643DF814-D2D2-4E91-9114-2FD563CE08BA@delong.com> References: <38911.1297831688@tristatelogic.com> <643DF814-D2D2-4E91-9114-2FD563CE08BA@delong.com> Message-ID: <4D5C1316.8060604@ipinc.net> So do I - but, I will say that once they finally get their web-based one to work, it should not be too difficult to write a command line Perl script that talks to their web server and outputs like the older command line tool did. Ted On 2/15/2011 11:41 PM, Owen DeLong wrote: > I really wish ARIN would make the command line whois work as well as > it used to instead of focusing all their energy on the (much less convenient > much higher overhead from the user perspective) web-based one. > > Owen > > On Feb 15, 2011, at 9:03 PM, Scott Leibrand wrote: > >> On Tue, Feb 15, 2011 at 8:48 PM, Ronald F. Guilmette >> > wrote: >> >> >> www.robtex.com says that AS10912 belongs >> to Internap. >> >> whois.arin.net says that there ain't no >> such AS. >> >> So, should I file a formal report charging Internap with fradulent use >> of resources that are not actually assigned to them? Or is it more >> likely that ARIN has simply (and entirely) misplaced the WHOIS record >> for AS10912? >> >> >> It looks like it's only the traditional whois tool that is failing. >> The web tool at arin.net reports it as part of >> INTERNAP-BLK, which covers ASNs 10910 - 10913. >> >> http://whois.arin.net/rest/asn/AS10910/pft >> >> I suspect your message will be enough to get ARIN to fix the whois >> port 43 service shortly. :-) >> >> -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 ebw at abenaki.wabanaki.net Wed Feb 16 12:52:39 2011 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Wed, 16 Feb 2011 12:52:39 -0500 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: <4881F12D-80AA-41BA-A710-9647A3683061@delong.com> References: <4D5BFFBA.7040700@umn.edu> <4881F12D-80AA-41BA-A710-9647A3683061@delong.com> Message-ID: <4D5C0EE7.9010607@abenaki.wabanaki.net> On 2/16/11 12:38 PM, Owen DeLong wrote: > ... >> Another option, could be to change the DNS pointer records in Whois and the production DNS, referring to a DNS service operated by ARIN for suspended DNS. Maybe with a wildcard returning "Suspended.DNS.ARIN.net" as the PTR record for all recursive look-ups for resources that have the DNS suspended. This provides in-band feed back and feedback through Whois in the nameserver field. >> > I think this is a very bad idea. > > Turning off DNS is one thing. Hijacking it is another. A similar tactic was tried by Network Solutions > once upon a time to make revenue out of typos. It was not well liked by the community. this is an unusual description of verisign's deployment of "sitefinder", and describing NXDOMAIN re-write as "similar" to a change of an RRSet is also ... an unusual choice of similarity. -e From tedm at ipinc.net Wed Feb 16 13:33:00 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Feb 2011 10:33:00 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4D5C185C.2030509@ipinc.net> On 2/15/2011 10:21 PM, Eric Westbrook wrote: > On Tue, Feb 15, 2011 at 22:36, Milton L Mueller > wrote: > > > If the effort is to entice legacy space holders into joining > ARIN, don't > > try to penalize them. Give them a positive incentive. > > I don't see this proposal as involving any penalties. Indeed, it is > the absence of this kind of thinking that consistently leads to > proposals to force legacy holders into the ARIN regime. The > (implied) incentive in 133 is that legacy holders can go to other > service providers - assuming of course, that we retain a consistent > and integrated whois that works across multiple service providers. > > > Nothing's broken today with respect to the services in question. I can > only envision additional costs, rigmarole, and coordination issues to > come with a multiple-provider regime. > > Perhaps what's broken is that legacy holders like me don't pay -- at > least, that seems to be the source of some significant outrage here. Not to me, and it's never really been that much. What I really resent most of all are the legacy-assigned blocks that are NOT in use. I don't care if you were assigned a legacy block 15 years ago that your paying nothing for - and you have 60% or more utilized. If anything, you have my support to have at it. But I do very much care if you have a legacy block that you got 15 years ago that is at 1% utilization because your too fat, dumb, and lazy to renumber into a /24 within that block and return the rest to the RIR. > Unfortunately, the LRSA is a non-starter (to me and others I know) > because of potential dilution of rights to the resource, as I've > articulated before. Your resource is only good for accessing others resources, and that usefulness is going to go away in the future. 10 years from now nobody will give a rat's ass about your "rights to the resource". So all I can conclude in reading a statement like this from a legacy holder is that either a) your sticking your head in the sand about IPv6 or b) Your an old man who plans on retiring long before IPv4 gets abandoned or c) your just making up excuses to yourself to justify not paying anything because your conscience is bugging you. None of which I or anyone else really gives a hoot about. In other words, we don't give a fig about your precious "rights" to your Legacy resource - as long as your USING it. Because, ultimately, if you ARE using it, then it's YOUR CUSTOMERS THE END USERS who are REALLY the users here. It's THEY I care about reaching, NOT YOU. The rest of us on the Internet have made an exception for your block NOT because of your imaginary "rights" but because we care about the USERS of your block. Barring a change to that, and with no other way in, > we're stuck. Were that different, I for one would cheerfully sign, pay, > and enjoy more formal participation. Baloney. All I can do today is cooperate by > keeping my information current. > > Carrots and sticks are uncompelling to the legacy holder. > Utter rubbish. Either your a legacy holder who is planning on continuing your Internet presense (in which case you have obtained IPv6, and are paying for it, and signed an RSA for it) or your planning on riding off into the sunset once your IPv4 becomes useless. And if it's the latter, then you really have nothing constructive to add, IMHO. Ted > $0.02, > Eric > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Wed Feb 16 13:43:44 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Feb 2011 10:43:44 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13B59@RWC-EX1.corp.seven.com> References: <4D595D12.4000602@arin.net><75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu><5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13B59@RWC-EX1.corp.seven.com> Message-ID: <4D5C1AE0.1030008@ipinc.net> On 2/15/2011 11:32 PM, George Bonser wrote: >> >> The Internet will be Dead -> Kill the Internet ? >> > > I don't think the internet is going to die because of whois entries. At > best it is just a distraction. At worst, it is a sort of retroactive > changing of the rules that have been in place for a very long time. If > it hasn't already destroyed the Internet over the past 20 years of the > general public being on it, it isn't going to break anything over the > next few years. This almost seems to be like several ways of somehow > getting hold of legacy address space or making it easier to hijack it. > Forget it. Those addresses were issued in a different time under > different rules and you can't just go changing the rules now just > because we have run out of them. Yes you can. There is plenty of legal precedent for doing just that in every legal system in the world. And in fact, we HAVE done this. We have done it by setting up a system to make legacy IPv4 obsolete. What I find quite interesting is this concept that legacy holders have special IP addressing "rights" If this is really true, then why aren't the legacy holders arguing that their "rights" are for IP ADDRESSING, not "IPv4 addressing" IPv4 and IPv6 addresses are....drumroll.... "IP addresses" If the legacy holders really and truly have special "ip addressing" rights then by NOT giving them FREE IPv6 assignments we are VIOLATING those rights - and they have a legal claim to go challenge ARIN's decision to NOT extend FREE IPv6 registrations to them. If you peruse the handwritten spiral notebook that the "original" IPv4 addresses were assigned off of, you don't find mention of "IPv4". You just find "IP addresses" If you look into the "deal" that was made when ARIN was created you find this as well. The concept that "Legacy IP Addresses" were specifically IPv4 and not IPv6 is something that has been invented. It has no basis on the original assignment documents that the Legacy holders are pretending their supposed "rights" derive from. And, the Legacy holders know it. They know perfectly well that there isn't any such thing as special rights for them just because they got addresses under different rules. That is why they aren't suing ARIN for free IPv6 assignments. The problem is that too many other people like you have swallowed this "legacy holder rights' baloney and actually believe the lie. Ted We have known this time was going to > come for a very long time. Here we are. It is what it is. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Wed Feb 16 13:47:27 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Feb 2011 10:47:27 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <464B3435-F206-4E1B-ABE7-551F5D38BCC7@corp.arin.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29C80@SUEX07-MBX-04.ad.syr.edu> <464B3435-F206-4E1B-ABE7-551F5D38BCC7@corp.arin.net> Message-ID: <4D5C1BBF.2030405@ipinc.net> On 2/16/2011 8:19 AM, John Curran wrote: > On Feb 16, 2011, at 10:56 AM, Milton L Mueller wrote: > >> The issue is, rather, what makes ARIN's Whois authoritative and what does it mean for it to be authoritative, especially when a large portion of the registrations are not maintained or authorized by the actual ip address block holder? > > To the contrary, many registrations have been updated by the address > holders, even if they do not participate in ARIN policy development > (you do not need to have a registration services agreement with ARIN > as a legacy holder to update your information - this was a very > conscious decision on the part of the community given the importance > of having accurate registration data) > >> What kinds of obligations do ip address holders incur when they register in ARIN's Whois, as opposed to those who don't? How can an authoritative Whois database be maintained, updated and relied upon for policy purposes when many legacy holders don't even participate in ARIN? > > Legacy address holders are already registered in ARIN's Whois, and > are subject to the same policies as any other resource holders. > With the exception of the "fee policy" ;-) Ted > FYI, > /John > > John Curran > President and CEO > ARIN > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From info at arin.net Wed Feb 16 14:00:01 2011 From: info at arin.net (ARIN) Date: Wed, 16 Feb 2011 14:00:01 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 Message-ID: <4D5C1EB1.1020007@arin.net> The proposal originator submitted revised text. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-131: Section 5.0 Legacy Addresses Proposal Originator: Martin Hannigan Proposal Version: 3.0 Date: 16 February 2011 Proposal type: New Policy term: Permanent Policy statement: Section 5.0 Legacy Addresses 5.1 Returned Legacy Addresses Legacy IPv4 addresses returned to or recovered by ARIN will be made available for registration and distribution in the ARIN region. Rationale: Adopting this proposal will result in the clarification of the status of returned legacy addresses. IPv4 address resources should not sit idle due to lack of policy clarity. Timetable for implementation: Immediately From george.herbert at gmail.com Wed Feb 16 14:01:15 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 16 Feb 2011 11:01:15 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <4D5C185C.2030509@ipinc.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> Message-ID: On Wed, Feb 16, 2011 at 10:33 AM, Ted Mittelstaedt wrote: > On 2/15/2011 10:21 PM, Eric Westbrook wrote: >> >> On Tue, Feb 15, 2011 at 22:36, Milton L Mueller > > wrote: >> >> ? ? > If the effort is to entice legacy space holders into joining >> ? ?ARIN, don't >> ? ? > try to penalize them. ?Give them a positive incentive. >> >> ? ?I don't see this proposal as involving any penalties. Indeed, it is >> ? ?the absence of this kind of thinking that consistently leads to >> ? ?proposals to force legacy holders into the ARIN regime. The >> ? ?(implied) incentive in 133 is that legacy holders can go to other >> ? ?service providers - assuming of course, that we retain a consistent >> ? ?and integrated whois that works across multiple service providers. >> >> >> Nothing's broken today with respect to the services in question. ?I can >> only envision additional costs, rigmarole, and coordination issues to >> come with a multiple-provider regime. >> >> Perhaps what's broken is that legacy holders like me don't pay -- at >> least, that seems to be the source of some significant outrage here. > > Not to me, and it's never really been that much. > > What I really resent most of all are the legacy-assigned blocks that > are NOT in use. > > I don't care if you were assigned a legacy block 15 years ago that your > paying nothing for - and you have 60% or more utilized. ?If anything, > you have my support to have at it. > > But I do very much care if you have a legacy block that you got 15 > years ago that is at 1% utilization because your too fat, dumb, and lazy > to renumber into a /24 within that block and return the rest to > the RIR. I oppose this policy proposal. More generally - the number of "large enough to matter" blocks which may be truly badly utilized and therefore highly attractive to encourage legacy holders to renumber and vacate isn't that big in the great scheme of things. It will not save "the end of the world" (IPv6 transition imminence) from happening, given that if they haven't already started, a renumbering effort for a large enterprise will take months to low years to fully develop and implement. I doubt that we could free up IPv4 space at the rate that APNIC needs more. IF this were to be successful, the time to do it was 2-4 years ago. That would at least have allowed time to A) negotiate with those amenable to it in good faith and of charitable intent, B) litigate with those who would, C) allow user network teams time to make changes and give back the addresses. Given the policy / political / legal uncertainty of what the ultimate outcome will be of answering the question: "for values of 'own' that include financial compensation for use of them, who 'owns' legacy IP space?" ... The only part of this that makes sense now is to ask large-enough-to-matter legacy holders what their usage is and to ask them to renumber if the answer is low and the effort reasonable, in the name of the common good. There's no downside to asking for that. Trying to force the issue seems like unnecessary and unproductive strife. -- -george william herbert george.herbert at gmail.com From tedm at ipinc.net Wed Feb 16 14:09:55 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Feb 2011 11:09:55 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> Message-ID: <4D5C2103.5030705@ipinc.net> On 2/16/2011 11:01 AM, George Herbert wrote: > On Wed, Feb 16, 2011 at 10:33 AM, Ted Mittelstaedt wrote: >> On 2/15/2011 10:21 PM, Eric Westbrook wrote: >>> >>> On Tue, Feb 15, 2011 at 22:36, Milton L Mueller>> > wrote: >>> >>> > If the effort is to entice legacy space holders into joining >>> ARIN, don't >>> > try to penalize them. Give them a positive incentive. >>> >>> I don't see this proposal as involving any penalties. Indeed, it is >>> the absence of this kind of thinking that consistently leads to >>> proposals to force legacy holders into the ARIN regime. The >>> (implied) incentive in 133 is that legacy holders can go to other >>> service providers - assuming of course, that we retain a consistent >>> and integrated whois that works across multiple service providers. >>> >>> >>> Nothing's broken today with respect to the services in question. I can >>> only envision additional costs, rigmarole, and coordination issues to >>> come with a multiple-provider regime. >>> >>> Perhaps what's broken is that legacy holders like me don't pay -- at >>> least, that seems to be the source of some significant outrage here. >> >> Not to me, and it's never really been that much. >> >> What I really resent most of all are the legacy-assigned blocks that >> are NOT in use. >> >> I don't care if you were assigned a legacy block 15 years ago that your >> paying nothing for - and you have 60% or more utilized. If anything, >> you have my support to have at it. >> >> But I do very much care if you have a legacy block that you got 15 >> years ago that is at 1% utilization because your too fat, dumb, and lazy >> to renumber into a /24 within that block and return the rest to >> the RIR. > > > I oppose this policy proposal. > > More generally - the number of "large enough to matter" blocks which > may be truly badly utilized and therefore highly attractive to > encourage legacy holders to renumber and vacate isn't that big in the > great scheme of things. It will not save "the end of the world" (IPv6 > transition imminence) from happening, given that if they haven't > already started, a renumbering effort for a large enterprise will take > months to low years to fully develop and implement. I doubt that we > could free up IPv4 space at the rate that APNIC needs more. > > IF this were to be successful, the time to do it was 2-4 years ago. This kind of thing was discussed 2-4 years ago and the math didn't support it then, either. Ted From JOHN at egh.com Wed Feb 16 14:13:06 2011 From: JOHN at egh.com (John Santos) Date: Wed, 16 Feb 2011 14:13:06 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <4D5C185C.2030509@ipinc.net> Message-ID: <1110216135543.31932A-100000@Ives.egh.com> On Wed, 16 Feb 2011, Ted Mittelstaedt wrote: > On 2/15/2011 10:21 PM, Eric Westbrook wrote: > > On Tue, Feb 15, 2011 at 22:36, Milton L Mueller > > wrote: > > > > > If the effort is to entice legacy space holders into joining > > ARIN, don't > > > try to penalize them. Give them a positive incentive. > > > > I don't see this proposal as involving any penalties. Indeed, it is > > the absence of this kind of thinking that consistently leads to > > proposals to force legacy holders into the ARIN regime. The > > (implied) incentive in 133 is that legacy holders can go to other > > service providers - assuming of course, that we retain a consistent > > and integrated whois that works across multiple service providers. > > > > > > Nothing's broken today with respect to the services in question. I can > > only envision additional costs, rigmarole, and coordination issues to > > come with a multiple-provider regime. > > > > Perhaps what's broken is that legacy holders like me don't pay -- at > > least, that seems to be the source of some significant outrage here. > > Not to me, and it's never really been that much. > > What I really resent most of all are the legacy-assigned blocks that > are NOT in use. > > I don't care if you were assigned a legacy block 15 years ago that your > paying nothing for - and you have 60% or more utilized. If anything, > you have my support to have at it. Over 50% but probably not quite 60% > > But I do very much care if you have a legacy block that you got 15 > years ago that is at 1% utilization because your too fat, dumb, and lazy > to renumber into a /24 within that block and return the rest to > the RIR. > Since it's already a /24, this paragraph is meaningless. > > Unfortunately, the LRSA is a non-starter (to me and others I know) > > because of potential dilution of rights to the resource, as I've > > articulated before. > > Your resource is only good for accessing others resources, and that > usefulness is going to go away in the future. 10 years from now nobody > will give a rat's ass about your "rights to the resource". So all I > can conclude in reading a statement like this from a legacy holder is > that either a) your sticking your head in the sand about IPv6 or > b) Your an old man who plans on retiring long before IPv4 gets abandoned > or c) your just making up excuses to yourself to justify not paying > anything because your conscience is bugging you. Try d) Am already implementing IPv6 (despite complete non-cooperation from my ISPs and my network being too small, last time I looked, for an ARIN end-user aIPv6 assignment), but will require IPv4 uniqueness indefinitely. > > None of which I or anyone else really gives a hoot about. In other > words, we don't give a fig about your precious "rights" to your Legacy > resource - as long as your USING it. LRSA, last time I read the fine print, says that I can keep my legacy assignment as long as I meet the minimum requirements for it, but the minimum assignment size is a /20, which I definitely don't qualify for. (I would qualify for a /24, if such were available.) > > Because, ultimately, if you ARE using it, then it's YOUR CUSTOMERS THE > END USERS who are REALLY the users here. It's THEY I care about > reaching, NOT YOU. False premise. I am not an ISP. I am an end user. I'm not providing transit or reallocation to my customers; I am providing services to them which require IP. You aren't reaching my customers via my network and they would scream bloody murder if you could. You might care about reaching them, but they care very much that you can't, at least not by transiting my network. > > The rest of us on the Internet have made an exception for your block NOT > because of your imaginary "rights" but because we care about the USERS > of your block. > What exception? You aren't carrying my block. All my Internet access is NATed through my ISPs. > Barring a change to that, and with no other way in, > > we're stuck. Were that different, I for one would cheerfully sign, pay, > > and enjoy more formal participation. > > Baloney. You presume to read my mind and tell me what I would and would not do? Are you psychic. > > All I can do today is cooperate by > > keeping my information current. > > > > Carrots and sticks are uncompelling to the legacy holder. > > > > Utter rubbish. Either your a legacy holder who is planning on > continuing your Internet presense (in which case you have obtained > IPv6, and are paying for it, and signed an RSA for it) > or your planning on riding off into the sunset once your IPv4 becomes > useless. And if it's the latter, then you really have nothing > constructive to add, IMHO. > > Ted You are assuming a shit-load of facts that are just not true, at least not for me, and since Eric's original post described my situation to a tee, it probably doesn't apply to him either. > > > $0.02, > > Eric -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From woody at pch.net Wed Feb 16 14:22:09 2011 From: woody at pch.net (Bill Woodcock) Date: Wed, 16 Feb 2011 11:22:09 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <1110216135543.31932A-100000@Ives.egh.com> References: <1110216135543.31932A-100000@Ives.egh.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 16, 2011, at 11:13 AM, John Santos wrote: > LRSA, last time I read the fine print, says that I can keep my legacy > assignment as long as I meet the minimum requirements for it, but the > minimum assignment size is a /20, which I definitely don't qualify for. > (I would qualify for a /24, if such were available.) /24s are available, and are the current minimum allocation. It is all but inconceivable that the long-term trend toward decrease in the minimum allocation size will continue, as existing allocations need to be subdivided further, to accommodate new users. In other words, the minimum allocation is /24 today, and it will be even smaller in the future. https://www.arin.net/policy/nrpm.html#four322 "For multihomed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24." -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1cI+EACgkQGvQy4xTRsBGY7gCgqhijWjkm8waf+1/V45jxqfrs 8sgAoKTi9F7qpVNPK35ysY3HJaSSRb2C =WyAA -----END PGP SIGNATURE----- From george.herbert at gmail.com Wed Feb 16 14:24:05 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 16 Feb 2011 11:24:05 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <4D5C2103.5030705@ipinc.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> <4D5C2103.5030705@ipinc.net> Message-ID: On Wed, Feb 16, 2011 at 11:09 AM, Ted Mittelstaedt wrote: > On 2/16/2011 11:01 AM, George Herbert wrote: >> >> On Wed, Feb 16, 2011 at 10:33 AM, Ted Mittelstaedt ?wrote: >>> >>> On 2/15/2011 10:21 PM, Eric Westbrook wrote: >>>> >>>> On Tue, Feb 15, 2011 at 22:36, Milton L Mueller>>> > ?wrote: >>>> >>>> ? ? > ?If the effort is to entice legacy space holders into joining >>>> ? ?ARIN, don't >>>> ? ? > ?try to penalize them. ?Give them a positive incentive. >>>> >>>> ? ?I don't see this proposal as involving any penalties. Indeed, it is >>>> ? ?the absence of this kind of thinking that consistently leads to >>>> ? ?proposals to force legacy holders into the ARIN regime. The >>>> ? ?(implied) incentive in 133 is that legacy holders can go to other >>>> ? ?service providers - assuming of course, that we retain a consistent >>>> ? ?and integrated whois that works across multiple service providers. >>>> >>>> >>>> Nothing's broken today with respect to the services in question. ?I can >>>> only envision additional costs, rigmarole, and coordination issues to >>>> come with a multiple-provider regime. >>>> >>>> Perhaps what's broken is that legacy holders like me don't pay -- at >>>> least, that seems to be the source of some significant outrage here. >>> >>> Not to me, and it's never really been that much. >>> >>> What I really resent most of all are the legacy-assigned blocks that >>> are NOT in use. >>> >>> I don't care if you were assigned a legacy block 15 years ago that your >>> paying nothing for - and you have 60% or more utilized. ?If anything, >>> you have my support to have at it. >>> >>> But I do very much care if you have a legacy block that you got 15 >>> years ago that is at 1% utilization because your too fat, dumb, and lazy >>> to renumber into a /24 within that block and return the rest to >>> the RIR. >> >> >> I oppose this policy proposal. >> >> More generally - the number of "large enough to matter" blocks which >> may be truly badly utilized and therefore highly attractive to >> encourage legacy holders to renumber and vacate isn't that big in the >> great scheme of things. ?It will not save "the end of the world" (IPv6 >> transition imminence) from happening, given that if they haven't >> already started, a renumbering effort for a large enterprise will take >> months to low years to fully develop and implement. ?I doubt that we >> could free up IPv4 space at the rate that APNIC needs more. >> >> IF this were to be successful, the time to do it was 2-4 years ago. > > This kind of thing was discussed 2-4 years ago and the math didn't > support it then, either. It's been discussed since at least 1987, when I started using the Internet. Since exhaustion became a problem on the "planning horizon" it's come up regularly. Why push the issue now, when the math not supporting it is even a worse case? -- -george william herbert george.herbert at gmail.com From JOHN at egh.com Wed Feb 16 14:32:10 2011 From: JOHN at egh.com (John Santos) Date: Wed, 16 Feb 2011 14:32:10 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D5C1AE0.1030008@ipinc.net> Message-ID: <1110216141453.31932B-100000@Ives.egh.com> On Wed, 16 Feb 2011, Ted Mittelstaedt wrote: ... one of the most illogical posts I have ever read on a technical mailing list. > On 2/15/2011 11:32 PM, George Bonser wrote: > >> > >> The Internet will be Dead -> Kill the Internet ? > >> > > > > I don't think the internet is going to die because of whois entries. At > > best it is just a distraction. At worst, it is a sort of retroactive > > changing of the rules that have been in place for a very long time. If > > it hasn't already destroyed the Internet over the past 20 years of the > > general public being on it, it isn't going to break anything over the > > next few years. This almost seems to be like several ways of somehow > > getting hold of legacy address space or making it easier to hijack it. > > Forget it. Those addresses were issued in a different time under > > different rules and you can't just go changing the rules now just > > because we have run out of them. > > Yes you can. There is plenty of legal precedent for doing just that > in every legal system in the world. Ever hear of ex post facto? It's unconstutional in the US. > > And in fact, we HAVE done this. We have done it by setting up a > system to make legacy IPv4 obsolete. > We don't go around seizing buggy whips. Making it obsolete does not deprive holders of the right to use it as they see fit. > What I find quite interesting is this concept that legacy holders have > special IP addressing "rights" Straw man. There's no special right, just the right to use the addresses as they always have, not subject to capricious revokation or random reallocation or reassignment of their addresses by an organization with whom they have no contract or business relationship. > > If this is really true, then why aren't the legacy holders arguing that > their "rights" are for IP ADDRESSING, not "IPv4 addressing" Because we were assigned IPv4 addresses by the legitimate orginization at the time, not IPv6 addresses or DECnet addresses, IPv4 addresses. > > IPv4 and IPv6 addresses are....drumroll.... "IP addresses" False equivalence. No legacy holders were assigned IPv6 addresses. > > If the legacy holders really and truly have special "ip addressing" > rights then by NOT giving them FREE IPv6 assignments we are VIOLATING > those rights - and they have a legal claim to go challenge ARIN's > decision to NOT extend FREE IPv6 registrations to them. Straw man. It is your false equivalence of IPv4 and IPv6 addresses which leads to this claim. No legacy holders are making it. Second straw man in the same paragraph. No legacy holders are claiming any right to additional addresses beyond what they already hold. > > If you peruse the handwritten spiral notebook that the "original" IPv4 > addresses were assigned off of, you don't find mention of "IPv4". You > just find "IP addresses" If you scan the sales logs of any home electronics store in 1955, you won't find any mention of "black and white television set", just "television set". But all the IP addresses were 4 octets and unique within that 32-bit address space and were assigned in conformance with the relevant IPv4 RFCs. > > If you look into the "deal" that was made when ARIN was created you > find this as well. > > The concept that "Legacy IP Addresses" were specifically IPv4 and not > IPv6 is something that has been invented. It has no basis on the > original assignment documents that the Legacy holders are pretending > their supposed "rights" derive from. > Yet another total straw man. No legacy holder is claiming the equivalancy of IPv4 and IPv6. > And, the Legacy holders know it. They know perfectly well that there > isn't any such thing as special rights for them just because they got > addresses under different rules. That is why they aren't suing ARIN for > free IPv6 assignments. No, it's because they received the holdings under one set of rules, and won't accept rule changes without carefully vetting them first, which requires time and money. You are worse then my 6-year-old niece who constantly changed the rules of "Trouble" based on her dice rolls. Grow up! > > The problem is that too many other people like you have swallowed this > "legacy holder rights' baloney and actually believe the lie. > What lie? > Ted > > We have known this time was going to > > come for a very long time. Here we are. It is what it is. > > > > > > _______________________________________________ > > 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. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From JOHN at egh.com Wed Feb 16 14:36:38 2011 From: JOHN at egh.com (John Santos) Date: Wed, 16 Feb 2011 14:36:38 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: Message-ID: <1110216143506.31932A-100000@Ives.egh.com> On Wed, 16 Feb 2011, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Feb 16, 2011, at 11:13 AM, John Santos wrote: > > LRSA, last time I read the fine print, says that I can keep my legacy > > assignment as long as I meet the minimum requirements for it, but the > > minimum assignment size is a /20, which I definitely don't qualify for. > > (I would qualify for a /24, if such were available.) > > /24s are available, and are the current minimum allocation. It is all but inconceivable that the long-term trend toward decrease in the minimum allocation size will continue, as existing allocations need to be subdivided further, to accommodate new users. In other words, the minimum allocation is /24 today, and it will be even smaller in the future. > > https://www.arin.net/policy/nrpm.html#four322 > > "For multihomed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24." > > -Bill That sounds much better. I'll consider running the LRSA by our lawyers. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From Lee at Dilkie.com Wed Feb 16 14:31:42 2011 From: Lee at Dilkie.com (Lee Dilkie) Date: Wed, 16 Feb 2011 14:31:42 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <4D5C185C.2030509@ipinc.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> Message-ID: <4D5C261E.9080109@Dilkie.com> On 2/16/2011 1:33 PM, Ted Mittelstaedt wrote: > > But I do very much care if you have a legacy block that you got 15 > years ago that is at 1% utilization because your too fat, dumb, and lazy > to renumber into a /24 within that block and return the rest to > the RIR. > > wow.. name calling... way to make a compelling argument, Ted. -lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Feb 16 15:28:53 2011 From: jcurran at arin.net (John Curran) Date: Wed, 16 Feb 2011 20:28:53 +0000 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: References: <4D5AFBA2.9070206@arin.net> Message-ID: <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> On Feb 15, 2011, at 8:05 PM, Keith W. Hare wrote: > What problem is prop-134 trying to solve? An excellent question best left to the author to address. > NPRM 8.2 "Mergers and Acquisitions" says "ARIN will maintain an up-to-date list of acceptable types of documentation." How does the codified list in Prop-134 compare to the ARIN list of acceptable types of documentation? The current list of acceptable types of documentation is available here: , if that should help facilitate the discussion of the question. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Wed Feb 16 16:03:34 2011 From: jcurran at arin.net (John Curran) Date: Wed, 16 Feb 2011 21:03:34 +0000 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders - Preemption of changes to date? In-Reply-To: <4D5AFBA2.9070206@arin.net> References: <4D5AFBA2.9070206@arin.net> Message-ID: > ARIN-prop-134: Identification of Legitimate Address Holders > ... > 13.x.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for the > management of an address block to another organization, including ARIN > or any other RIR, and that organization has historical and/or current > records showing the assignment or allocation of a given IP address block > to a specific organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.x.4 below, the evidence from the > original allocation record will take precedence. Benson - Is it your intent via this proposal that all changes to legacy address holder records that have occurred since ARIN's inception be vacated? ARIN has indeed processed many changes since that time, and the hence the records inherently conflict with the original allocation records. Is the intent of the above language to give precedence to original records of address holders despite all changes to date that have already been reflected in the ARIN Whois database? Alternatively, are we to seek documentation anew for all of the transfers accomplished to date, and reprocess according to section 13.x.4? Thanks! /John John Curran President and CEO ARIN From owen at delong.com Wed Feb 16 16:05:14 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 13:05:14 -0800 Subject: [arin-ppml] Fraud or not? In-Reply-To: <4D5C1316.8060604@ipinc.net> References: <38911.1297831688@tristatelogic.com> <643DF814-D2D2-4E91-9114-2FD563CE08BA@delong.com> <4D5C1316.8060604@ipinc.net> Message-ID: <876B0377-1A7B-473D-8C4A-7EA28F1CC63F@delong.com> Output, sure. However, the web-based one is much stricter and less intelligent about parsing queries and THAT is the primary problem I'm having. Instead of realizing that the old "AS10912" query means the same thing to the user as the new arcane syntax "a 10912" (which the old version did just fine), the new version neither fails nor works consistently (or at least the behavior appears very inconsistent until you begin to understand an additional arcane set of rules). The actual result is: 1. Some command line clients do the translation for you. (good for them, but, not universal) 2. If you query ASnnnnn, then, whether you get a good result back or not depends on whether or not ASnnnnn is the handle for the resource. If I were to create an AS Number record, for example, named AS105, but, which was actually AS693, then, I would get the following odd mixture: Query Result AS105 Record for AS693 AS693 Nothing a 105 Record for AS105 a 693 Record for AS693 (Assuming that my client doesn't alter my queries unexpectedly). I shouldn't have to become an expert in whois arcana to survive navigating whois for simple everyday queries. Owen On Feb 16, 2011, at 10:10 AM, Ted Mittelstaedt wrote: > So do I - but, I will say that once they finally get their web-based one > to work, it should not be too difficult to write a command line Perl > script that talks to their web server and outputs like the older command line tool did. > > Ted > > On 2/15/2011 11:41 PM, Owen DeLong wrote: >> I really wish ARIN would make the command line whois work as well as >> it used to instead of focusing all their energy on the (much less convenient >> much higher overhead from the user perspective) web-based one. >> >> Owen >> >> On Feb 15, 2011, at 9:03 PM, Scott Leibrand wrote: >> >>> On Tue, Feb 15, 2011 at 8:48 PM, Ronald F. Guilmette >>> > wrote: >>> >>> >>> www.robtex.com says that AS10912 belongs >>> to Internap. >>> >>> whois.arin.net says that there ain't no >>> such AS. >>> >>> So, should I file a formal report charging Internap with fradulent use >>> of resources that are not actually assigned to them? Or is it more >>> likely that ARIN has simply (and entirely) misplaced the WHOIS record >>> for AS10912? >>> >>> >>> It looks like it's only the traditional whois tool that is failing. >>> The web tool at arin.net reports it as part of >>> INTERNAP-BLK, which covers ASNs 10910 - 10913. >>> >>> http://whois.arin.net/rest/asn/AS10910/pft >>> >>> I suspect your message will be enough to get ARIN to fix the whois >>> port 43 service shortly. :-) >>> >>> -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. From owen at delong.com Wed Feb 16 16:30:46 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 13:30:46 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <4D5C1BBF.2030405@ipinc.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <75822E125BCB994F8446858C4B19F0D7143AF29C80@SUEX07-MBX-04.ad.syr.edu> <464B3435-F206-4E1B-ABE7-551F5D38BCC7@corp.arin.net> <4D5C1BBF.2030405@ipinc.net> Message-ID: <77AE5E81-9F12-413D-8C79-6E84F3D452B0@delong.com> On Feb 16, 2011, at 10:47 AM, Ted Mittelstaedt wrote: > On 2/16/2011 8:19 AM, John Curran wrote: >> On Feb 16, 2011, at 10:56 AM, Milton L Mueller wrote: >> >>> The issue is, rather, what makes ARIN's Whois authoritative and what does it mean for it to be authoritative, especially when a large portion of the registrations are not maintained or authorized by the actual ip address block holder? >> >> To the contrary, many registrations have been updated by the address >> holders, even if they do not participate in ARIN policy development >> (you do not need to have a registration services agreement with ARIN >> as a legacy holder to update your information - this was a very >> conscious decision on the part of the community given the importance >> of having accurate registration data) >> >>> What kinds of obligations do ip address holders incur when they register in ARIN's Whois, as opposed to those who don't? How can an authoritative Whois database be maintained, updated and relied upon for policy purposes when many legacy holders don't even participate in ARIN? >> >> Legacy address holders are already registered in ARIN's Whois, and >> are subject to the same policies as any other resource holders. >> > > With the exception of the "fee policy" ;-) > Fees are NOT policy. Owen From owen at delong.com Wed Feb 16 16:55:40 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 13:55:40 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <1110216141453.31932B-100000@Ives.egh.com> References: <1110216141453.31932B-100000@Ives.egh.com> Message-ID: <30D038C7-9E8C-4FD2-BD51-F536DF571AC9@delong.com> > There's no special right, just the right to use the addresses as > they always have, not subject to capricious revokation or random > reallocation or reassignment of their addresses by an organization > with whom they have no contract or business relationship. > Speaking only for myself... I think it is unfair to characterize any ARIN revocation, reallocation, or reassignment that has taken place as capricious. To the best of my knowledge, ARIN has always had very good reasons supported by policy developed by the community for each and every resource that has been revoked, reallocated, or reassigned with the possible exception of some accidental duplicates, in which case, what was done was an attempt to minimize and disruption to the parties involved, usually with the cooperation and consent of the parties. Owen From Keith at jcc.com Wed Feb 16 17:46:32 2011 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 16 Feb 2011 17:46:32 -0500 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> Message-ID: The list of acceptable documentation in https://www.arin.net/resources/request/transfers.html seems reasonable and complete. Prop-134 says similar things less eloquently but with more words. Prop-134 is attempting (and failing) to fix something that is not broken. Therefore, I oppose Prop-134. Keith Hare -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Wednesday, February 16, 2011 3:29 PM To: Keith W. Hare Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders On Feb 15, 2011, at 8:05 PM, Keith W. Hare wrote: > What problem is prop-134 trying to solve? An excellent question best left to the author to address. > NPRM 8.2 "Mergers and Acquisitions" says "ARIN will maintain an up-to-date list of acceptable types of documentation." How does the codified list in Prop-134 compare to the ARIN list of acceptable types of documentation? The current list of acceptable types of documentation is available here: , if that should help facilitate the discussion of the question. FYI, /John John Curran President and CEO ARIN From tedm at ipinc.net Wed Feb 16 18:13:46 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Feb 2011 15:13:46 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <1110216135543.31932A-100000@Ives.egh.com> References: <1110216135543.31932A-100000@Ives.egh.com> Message-ID: <4D5C5A2A.3000100@ipinc.net> On 2/16/2011 11:13 AM, John Santos wrote: > On Wed, 16 Feb 2011, Ted Mittelstaedt wrote: > >> On 2/15/2011 10:21 PM, Eric Westbrook wrote: >>> On Tue, Feb 15, 2011 at 22:36, Milton L Mueller>> > wrote: >>> >>> > If the effort is to entice legacy space holders into joining >>> ARIN, don't >>> > try to penalize them. Give them a positive incentive. >>> >>> I don't see this proposal as involving any penalties. Indeed, it is >>> the absence of this kind of thinking that consistently leads to >>> proposals to force legacy holders into the ARIN regime. The >>> (implied) incentive in 133 is that legacy holders can go to other >>> service providers - assuming of course, that we retain a consistent >>> and integrated whois that works across multiple service providers. >>> >>> >>> Nothing's broken today with respect to the services in question. I can >>> only envision additional costs, rigmarole, and coordination issues to >>> come with a multiple-provider regime. >>> >>> Perhaps what's broken is that legacy holders like me don't pay -- at >>> least, that seems to be the source of some significant outrage here. >> >> Not to me, and it's never really been that much. >> >> What I really resent most of all are the legacy-assigned blocks that >> are NOT in use. >> >> I don't care if you were assigned a legacy block 15 years ago that your >> paying nothing for - and you have 60% or more utilized. If anything, >> you have my support to have at it. > > Over 50% but probably not quite 60% > > >> >> But I do very much care if you have a legacy block that you got 15 >> years ago that is at 1% utilization because your too fat, dumb, and lazy >> to renumber into a /24 within that block and return the rest to >> the RIR. >> > > Since it's already a /24, this paragraph is meaningless. > > >>> Unfortunately, the LRSA is a non-starter (to me and others I know) >>> because of potential dilution of rights to the resource, as I've >>> articulated before. >> >> Your resource is only good for accessing others resources, and that >> usefulness is going to go away in the future. 10 years from now nobody >> will give a rat's ass about your "rights to the resource". So all I >> can conclude in reading a statement like this from a legacy holder is >> that either a) your sticking your head in the sand about IPv6 or >> b) Your an old man who plans on retiring long before IPv4 gets abandoned >> or c) your just making up excuses to yourself to justify not paying >> anything because your conscience is bugging you. > > Try d) Am already implementing IPv6 (despite complete non-cooperation > from my ISPs and my network being too small, last time I looked, for > an ARIN end-user aIPv6 assignment), but will require IPv4 uniqueness > indefinitely. > >> >> None of which I or anyone else really gives a hoot about. In other >> words, we don't give a fig about your precious "rights" to your Legacy >> resource - as long as your USING it. > > LRSA, last time I read the fine print, says that I can keep my legacy > assignment as long as I meet the minimum requirements for it, but the > minimum assignment size is a /20, which I definitely don't qualify for. > (I would qualify for a /24, if such were available.) > If all Legacy holders out there were /24 holders then nobody would even be discussing this issue at all. Your persistence in this obviously wrong assumption that /24's represent the majority of Legacy holders or even a significant percentage of them is not worthy of further comment. Ted >> >> Because, ultimately, if you ARE using it, then it's YOUR CUSTOMERS THE >> END USERS who are REALLY the users here. It's THEY I care about >> reaching, NOT YOU. > > False premise. I am not an ISP. I am an end user. I'm not providing > transit or reallocation to my customers; I am providing services to > them which require IP. You aren't reaching my customers via my > network and they would scream bloody murder if you could. You might > care about reaching them, but they care very much that you can't, > at least not by transiting my network. > > > >> >> The rest of us on the Internet have made an exception for your block NOT >> because of your imaginary "rights" but because we care about the USERS >> of your block. >> > > What exception? You aren't carrying my block. All my Internet access > is NATed through my ISPs. > >> Barring a change to that, and with no other way in, >>> we're stuck. Were that different, I for one would cheerfully sign, pay, >>> and enjoy more formal participation. >> >> Baloney. > > You presume to read my mind and tell me what I would and would not > do? Are you psychic. > >> >> All I can do today is cooperate by >>> keeping my information current. >>> >>> Carrots and sticks are uncompelling to the legacy holder. >>> >> >> Utter rubbish. Either your a legacy holder who is planning on >> continuing your Internet presense (in which case you have obtained >> IPv6, and are paying for it, and signed an RSA for it) >> or your planning on riding off into the sunset once your IPv4 becomes >> useless. And if it's the latter, then you really have nothing >> constructive to add, IMHO. >> >> Ted > > You are assuming a shit-load of facts that are just not true, at > least not for me, and since Eric's original post described my > situation to a tee, it probably doesn't apply to him either. > >> >>> $0.02, >>> Eric From bill at herrin.us Wed Feb 16 18:47:26 2011 From: bill at herrin.us (William Herrin) Date: Wed, 16 Feb 2011 18:47:26 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: <4D5C1EB1.1020007@arin.net> References: <4D5C1EB1.1020007@arin.net> Message-ID: On Wed, Feb 16, 2011 at 2:00 PM, ARIN wrote: > ARIN-prop-131: Section 5.0 Legacy Addresses > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region. SUPPORT. Per https://www.arin.net/announcements/2010/20101020.html (emphasis mine): "After the hold period, ARIN will follow global policy at that time and ***return it to the global free pool*** or distribute the space to those organizations in the ARIN region with documented need, as appropriate." Allow me to be the "bad guy" here. We don't want addresses ARIN works and spends our money to recover to go in to the global pool. We want them to go in to the ARIN pool for allocation and assignment back to us. That's why we intentionally never set terms under which ARIN could return addresses to IANA during the whole global transfer policy argument last year. This proposal clarifies our community's preference that ARIN-recovered addresses be deployed in the ARIN region. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeffrey.lyon at blacklotus.net Wed Feb 16 18:53:31 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 16 Feb 2011 18:53:31 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: References: <4D5C1EB1.1020007@arin.net> Message-ID: On Wed, Feb 16, 2011 at 6:47 PM, William Herrin wrote: > On Wed, Feb 16, 2011 at 2:00 PM, ARIN wrote: >> ARIN-prop-131: Section 5.0 Legacy Addresses >> Policy statement: >> >> Section 5.0 Legacy Addresses >> >> 5.1 Returned Legacy Addresses >> >> Legacy IPv4 addresses returned to or recovered by ARIN will be made >> available for registration and distribution in the ARIN region. > > SUPPORT. > > Per https://www.arin.net/announcements/2010/20101020.html (emphasis mine): > > "After the hold period, ARIN will follow global policy at that time > and ***return it to the global free pool*** or distribute the space to > those organizations in the ARIN region with documented need, as > appropriate." > > Allow me to be the "bad guy" here. We don't want addresses ARIN works > and spends our money to recover to go in to the global pool. We want > them to go in to the ARIN pool for allocation and assignment back to > us. That's why we intentionally never set terms under which ARIN could > return addresses to IANA during the whole global transfer policy > argument last year. > > This proposal clarifies our community's preference that ARIN-recovered > addresses be deployed in the ARIN region. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > +1 for support. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From hannigan at gmail.com Wed Feb 16 18:57:12 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Wed, 16 Feb 2011 18:57:12 -0500 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: References: <4D5C1EB1.1020007@arin.net> Message-ID: Support, and I'm the author even. ;-) On Wed, Feb 16, 2011 at 6:53 PM, Jeffrey Lyon wrote: > On Wed, Feb 16, 2011 at 6:47 PM, William Herrin wrote: >> On Wed, Feb 16, 2011 at 2:00 PM, ARIN wrote: >>> ARIN-prop-131: Section 5.0 Legacy Addresses >>> Policy statement: >>> >>> Section 5.0 Legacy Addresses >>> >>> 5.1 Returned Legacy Addresses >>> >>> Legacy IPv4 addresses returned to or recovered by ARIN will be made >>> available for registration and distribution in the ARIN region. >> >> SUPPORT. >> >> Per https://www.arin.net/announcements/2010/20101020.html (emphasis mine): >> >> "After the hold period, ARIN will follow global policy at that time >> and ***return it to the global free pool*** or distribute the space to >> those organizations in the ARIN region with documented need, as >> appropriate." >> >> Allow me to be the "bad guy" here. We don't want addresses ARIN works >> and spends our money to recover to go in to the global pool. We want >> them to go in to the ARIN pool for allocation and assignment back to >> us. That's why we intentionally never set terms under which ARIN could >> return addresses to IANA during the whole global transfer policy >> argument last year. >> >> This proposal clarifies our community's preference that ARIN-recovered >> addresses be deployed in the ARIN region. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > +1 for support. > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > _______________________________________________ > 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 Wed Feb 16 18:59:49 2011 From: jcurran at arin.net (John Curran) Date: Wed, 16 Feb 2011 23:59:49 +0000 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <4D5C5A2A.3000100@ipinc.net> References: <1110216135543.31932A-100000@Ives.egh.com> <4D5C5A2A.3000100@ipinc.net> Message-ID: <7B24FD63-C6F0-4F07-8350-83A9B557C1B0@corp.arin.net> On Feb 16, 2011, at 6:13 PM, Ted Mittelstaedt wrote: > > If all Legacy holders out there were /24 holders then nobody would even be discussing this issue at all. For reference: there are approximately 18,995 OrgIDs in ARIN's Whois with IPv4 registrations prior to ARIN's formation. Of those, 11,943 have only a /24, or 62.87%. That is a significant percentage of organizations, but clearly a very small fraction of the address space in question. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Wed Feb 16 19:08:20 2011 From: jcurran at arin.net (John Curran) Date: Thu, 17 Feb 2011 00:08:20 +0000 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: References: <4D5C1EB1.1020007@arin.net> Message-ID: <56BE719C-26FB-49FD-BE08-F28E6FC6CB3C@corp.arin.net> On Feb 16, 2011, at 6:47 PM, William Herrin wrote: > On Wed, Feb 16, 2011 at 2:00 PM, ARIN wrote: > > Per https://www.arin.net/announcements/2010/20101020.html (emphasis mine): > > "After the hold period, ARIN will follow global policy at that time > and ***return it to the global free pool*** or distribute the space to > those organizations in the ARIN region with documented need, as > appropriate." > > Allow me to be the "bad guy" here. We don't want addresses ARIN works > and spends our money to recover to go in to the global pool. We want > them to go in to the ARIN pool for allocation and assignment back to > us. That's why we intentionally never set terms under which ARIN could > return addresses to IANA during the whole global transfer policy > argument last year. To be clear: last year there was a prolonged discussion regarding a global policy for redistribution of returned IPv4 address. In the ARIN region, the original text was changed to make return of address space optional, with two reasons cited: 1) Mandatory return of IPv4 address space is not appropriate if the resources are then being reallocated to RIRs that don't follow the goals of RFC 2050. 2) ARIN has to absorb the costs involved in recovery of address space, and therefore should not have to automatically return the space to the global free (despite this being the historical ARIN practice) So, we never set terms under which ARIN *must* return address space, but did adopt a global policy in this region whereby ARIN could return space. I do not know how this impacts the discussion of the policy, but felt it important that there be clarity on the last year's efforts. FYI, /John John Curran President and CEO ARIN From JOHN at egh.com Wed Feb 16 19:18:15 2011 From: JOHN at egh.com (John Santos) Date: Wed, 16 Feb 2011 19:18:15 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <30D038C7-9E8C-4FD2-BD51-F536DF571AC9@delong.com> Message-ID: <1110216191216.31932D-100000@Ives.egh.com> On Wed, 16 Feb 2011, Owen DeLong wrote: > > There's no special right, just the right to use the addresses as > > they always have, not subject to capricious revokation or random > > reallocation or reassignment of their addresses by an organization > > with whom they have no contract or business relationship. > > > Speaking only for myself... > > I think it is unfair to characterize any ARIN revocation, reallocation, > or reassignment that has taken place as capricious. > > To the best of my knowledge, ARIN has always had very good reasons > supported by policy developed by the community for each and > every resource that has been revoked, reallocated, or reassigned > with the possible exception of some accidental duplicates, in which > case, what was done was an attempt to minimize and disruption > to the parties involved, usually with the cooperation and consent > of the parties. > > Owen I should have been more clear: "Capricious" wasn't meant to be a characterization of ARIN's past actions, but a worst-case fear for the future. Some of the proposals that have been made here in the past would I think qualify, but none has come close to passing. Sanity and fairness always seem to have prevailed at least as long as I've been lurking on PPML, which I think is one of the strongest arguments for preserving ARIN's role. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From Israel at maxsip.com Wed Feb 16 19:22:48 2011 From: Israel at maxsip.com (Israel Max) Date: Wed, 16 Feb 2011 16:22:48 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] Message-ID: <279EA7DD8CA57A49AAE675DBC49353AB833B9482B9@EXVMBX015-1.exch015.msoutlookonline.net> I setup everything you ned to do the connectivity part Sent from my Android phone using TouchDown (www.nitrodesk.com) -----Original Message----- From: John Curran [jcurran at arin.net] Received: Wednesday, 16 Feb 2011, 7:00pm To: Ted Mittelstaedt [tedm at ipinc.net] CC: arin-ppml at arin.net List [arin-ppml at arin.net] Subject: Re: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] On Feb 16, 2011, at 6:13 PM, Ted Mittelstaedt wrote: > > If all Legacy holders out there were /24 holders then nobody would even be discussing this issue at all. For reference: there are approximately 18,995 OrgIDs in ARIN's Whois with IPv4 registrations prior to ARIN's formation. Of those, 11,943 have only a /24, or 62.87%. That is a significant percentage of organizations, but clearly a very small fraction of the address space in question. FYI, /John John Curran President and CEO ARIN _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.449 / Virus Database: 271.1.1/3447 - Release Date: 02/16/11 19:34:00 ________________________________ This message (and any associated files) is intended only for the use of the individual or entity to which it is addressed and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not the intended recipient you are hereby notified that any dissemination, copying, or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Messages sent to and from us may be monitored. Internet communications cannot be guaranteed to be secure or error-free, as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. Therefore, we do not accept responsibility for any errors or omissions that are present in this message, or any attachment, that have arisen as a result of e-mail transmission. If verification is required, please request a hard-copy version. Any views or opinions presented are solely those of the author and do not necessarily represent those of the company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bensons at queuefull.net Wed Feb 16 19:54:18 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 18:54:18 -0600 Subject: [arin-ppml] ARIN-prop-132: ISP Sub-assignments Do Not Require Specific Customer Relationships In-Reply-To: References: <4D556387.3000300@arin.net> <75822E125BCB994F8446858C4B19F0D7143AF29C58@SUEX07-MBX-04.ad.syr.edu> Message-ID: <5D9D4DEA-7BD7-4C42-A55F-F16E30AAFEAE@queuefull.net> Jimmy - I think most of your concerns about prop 132 stem from a misunderstanding. The proposal doesn't change any other policy - it only deals with the definition of "customer". But this issue is worth exploring: On Feb 15, 2011, at 11:43 PM, Jimmy Hess wrote: > The ISP's ability to define customer should be contingent upon the > ISP's definition of "customer" being reasonable. How do you define "reasonable"? Do you feel that your definition is adequately fool-proof, such that it can be applied to the entire ARIN constituency? And does your definition achieve some desired result that prop 132 does not? Cheers, -Benson From bensons at queuefull.net Wed Feb 16 19:59:54 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 18:59:54 -0600 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> Message-ID: <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> On Feb 16, 2011, at 2:28 PM, John Curran wrote: > On Feb 15, 2011, at 8:05 PM, Keith W. Hare wrote: >> What problem is prop-134 trying to solve? > > An excellent question best left to the author to address. Prop 134 makes the definition of "Legitimate Address Holder" a matter of community consensus rather than a staff implementation. I believe this is a good thing in its own right. But it is especially useful if the community wishes to define policy that relies on a common understanding of the term. Prop 133 is an example, as are other draft policy proposals that I'm working on. Cheers, -Benson From woody at pch.net Wed Feb 16 20:13:52 2011 From: woody at pch.net (Bill Woodcock) Date: Wed, 16 Feb 2011 17:13:52 -0800 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> Message-ID: <51BA8288-FC93-461F-879E-508A9C57FC14@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 16, 2011, at 4:59 PM, Benson Schliesser wrote: > Prop 134 makes the definition of "Legitimate Address Holder" a matter of community consensus rather than a staff implementation. And is the community going to hire some other set of analysts than ARIN's, to investigate all the fraudulent claims made by people who try to hijack legacy blocks? Or are you suggesting that the community should, through inaction, handsomely reward hijackers for their ingenuity and gumption? It appears that you're oblivious to the fact that this whole system exists for a reason. If you don't like the fact that regulatory mechanisms and the rule of law exist to protect people from shysters and con-men, perhaps you should try establishing an RIR somewhere that isn't as likely to get in your way? See section 9: http://www.icann.org/en/aso/aso-mou-26aug99.htm http://en.wikipedia.org/wiki/Transnistria -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1cdlEACgkQGvQy4xTRsBEWDwCeIcbIeIxvybEs18q45ZjqTZ9e iIgAnjtXT+5pwjEqH7JqXJVgSsZvn4tU =H4un -----END PGP SIGNATURE----- From bensons at queuefull.net Wed Feb 16 20:16:55 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 19:16:55 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: <56BE719C-26FB-49FD-BE08-F28E6FC6CB3C@corp.arin.net> References: <4D5C1EB1.1020007@arin.net> <56BE719C-26FB-49FD-BE08-F28E6FC6CB3C@corp.arin.net> Message-ID: On Feb 16, 2011, at 6:08 PM, John Curran wrote: > To be clear: last year there was a prolonged discussion regarding a global > policy for redistribution of returned IPv4 address. In the ARIN region, > the original text was changed to make return of address space optional, > with two reasons cited: > > 1) Mandatory return of IPv4 address space is not appropriate if the > resources are then being reallocated to RIRs that don't follow > the goals of RFC 2050. > > 2) ARIN has to absorb the costs involved in recovery of address space, > and therefore should not have to automatically return the space to > the global free (despite this being the historical ARIN practice) > > So, we never set terms under which ARIN *must* return address space, but > did adopt a global policy in this region whereby ARIN could return space. > > I do not know how this impacts the discussion of the policy, but felt it > important that there be clarity on the last year's efforts. Thanks for this commentary, John. I do think it impacts discussion of prop 131. I think it is our responsibility to avoid ambiguity in policy regarding fundamental management issues, such as how we will handle the free pool, transfers, and return of resources. As such, I support the intent of prop 131. However, I would like to see additional policy language added to prop 131, including (a) the definition of who ARIN will accept returned blocks from i.e. only legitimate address holders in the ARIN region, (b) the similar application of policy to non-legacy blocks, and (c) the allowance of inter-region transfer if explicitly called for elsewhere by the NRPM. Cheers, -Benson From farmer at umn.edu Wed Feb 16 20:22:05 2011 From: farmer at umn.edu (David Farmer) Date: Wed, 16 Feb 2011 19:22:05 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: <4D5C1EB1.1020007@arin.net> References: <4D5C1EB1.1020007@arin.net> Message-ID: <4D5C783D.7050805@umn.edu> I support this policy moving forward as a Draft Policy and being discussed at the next PPM. If there is significant movement on the global policy front in some of other regions, I may reconsider my support following the PPM. But, we need to discuss and consider this option for possible adoption at the up coming PPM in San Juan. On 2/16/11 13:00 CST, ARIN wrote: > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > Timetable for implementation: Immediately -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bensons at queuefull.net Wed Feb 16 20:33:49 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 19:33:49 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <4D5C1AE0.1030008@ipinc.net> References: <4D595D12.4000602@arin.net><75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu><5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13B59@RWC-EX1.corp.seven.com> <4D5C1AE0.1030008@ipinc.net> Message-ID: <19E865C3-B0DE-4559-BC0A-D4CC8B37DEC0@queuefull.net> Ted, I'm not sure why I'm responding to this. I think your comments conflate a number of different issues. Nevertheless: On Feb 16, 2011, at 12:43 PM, Ted Mittelstaedt wrote: > If this is really true, then why aren't the legacy holders arguing that > their "rights" are for IP ADDRESSING, not "IPv4 addressing" By definition, a "legacy holder" has resources that were received absent contracts with an RIR. New RIR allocations of IPv4 and IPv6 don't fit into this category. Further, a legacy holder might have different rights associated with different address blocks, e.g. if some of those blocks are legacy, some were received under different contractual relationships over the years, some were received from different RIRs, etc. -Benson From bill at herrin.us Wed Feb 16 20:40:03 2011 From: bill at herrin.us (William Herrin) Date: Wed, 16 Feb 2011 20:40:03 -0500 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> Message-ID: On Wed, Feb 16, 2011 at 7:59 PM, Benson Schliesser wrote: >> On Feb 15, 2011, at 8:05 PM, Keith W. Hare wrote: >>> What problem is prop-134 trying to solve? > > Prop 134 makes the definition of "Legitimate Address Holder" > a matter of community consensus rather than a staff implementation. A. The community doesn't actually have a consensus on this. B. If we did have a consensus, it wouldn't be prop 134. C. Historically speaking, the kinds of documentation you're looking for often isn't there. I was a college junior setting up a two-node isolated TCP/IP network in my apartment when I applied for a class C. Isolated because my college would only give me dialin terminal access (2400 bps!) and slirp (slip emulator for a unix shell) hadn't been invented yet. Ethernet cards were finally cheap enough that I could afford to buy two and Linux was wicked cool. Chapter 4 the 1993 edition Crab Book (O'Reilly & Associates TCP/IP Network Administration, "Getting Started" chapter) told me to get a class C anyway: "Obtaining a network address from the NIC is simple and costs nothing. There are no advantages to choosing your own unofficial network address -- except that you do not have to fill out an application." That's where the thinking was back then. And that kind of thing isn't prone to leaving a strong chain of custody. D. Policy for policy's sake is unhelpful. It merely solidifies bureaucracy and ties folks hands when the odd exceptional case comes along. ARIN today does a fine job sorting out who is the rightful address holder when an update is requested but the POCs are defunct. Let 'em be. For all of these reasons, I OPPOSE prop 134. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bensons at queuefull.net Wed Feb 16 20:56:47 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 19:56:47 -0600 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <51BA8288-FC93-461F-879E-508A9C57FC14@pch.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> <51BA8288-FC93-461F-879E-508A9C57FC14@pch.net> Message-ID: <75E513C2-4A4B-4707-8610-68347788F067@queuefull.net> On Feb 16, 2011, at 7:13 PM, Bill Woodcock wrote: > On Feb 16, 2011, at 4:59 PM, Benson Schliesser wrote: >> Prop 134 makes the definition of "Legitimate Address Holder" a matter of community consensus rather than a staff implementation. > > And is the community going to hire some other set of analysts than ARIN's, to investigate all the fraudulent claims made by people who try to hijack legacy blocks? Or are you suggesting that the community should, through inaction, handsomely reward hijackers for their ingenuity and gumption? You may have overlooked the word "definition" in my comment. The definition of a term doesn't necessarily include responsibility for all subsequent actions - ARIN still has a job to do. > It appears that you're oblivious to the fact that this whole system exists for a reason. If you don't like the fact that regulatory mechanisms and the rule of law exist to protect people from shysters and con-men, perhaps you should try establishing an RIR somewhere that isn't as likely to get in your way? You presume incorrectly to understand my thinking, but the tone of your response doesn't encourage me to explain further. Except to say that the system that exists is imperfect, and "if you don't like it then leave!" responses aren't helpful. If you want more details, feel free to ask me a constructive question or read my other messages to this list. Cheers, -Benson From farmer at umn.edu Wed Feb 16 20:58:58 2011 From: farmer at umn.edu (David Farmer) Date: Wed, 16 Feb 2011 19:58:58 -0600 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: <4881F12D-80AA-41BA-A710-9647A3683061@delong.com> References: <4D5BFFBA.7040700@umn.edu> <4881F12D-80AA-41BA-A710-9647A3683061@delong.com> Message-ID: <4D5C80E2.3040607@umn.edu> On 2/16/11 11:38 CST, Owen DeLong wrote: > > On Feb 16, 2011, at 8:47 AM, David Farmer wrote: > >> I support the the intended result of this proposal and this is text is an improvement. However, I have a problem with the removal of DNS service without some kind of signal to third parties. >> >> As a third party under this proposal all I see is reverse DNS breaking and have no clue why. Is it an action by ARIN, a lame delegation, a temporary problem of some other kind. >> > That's true in any resource revocation today, so, I'm not sure what you perceive as different. The resource is removed from Whois when it is revoked. > It isn't a lame delegation because there are no NS records to be lame. > > You see that there are no NS records, you can be reasonably certain it is action by ARIN, no? OK, when ARIN suspends DNS service it removes the nameserver record in the Whois entry, that works for me. When I read suspend DNS, I was think only breaking the glue records, as long as the Whois nameserver records are removed too, then we are good. >> One option would be some kind of status field associated with the Whois record stating the DNS service is suspended. >> > I wouldn't oppose this, but, that's an operational matter ARIN can choose to implement, not really a policy issue. > >> Another option, could be to change the DNS pointer records in Whois and the production DNS, referring to a DNS service operated by ARIN for suspended DNS. Maybe with a wildcard returning "Suspended.DNS.ARIN.net" as the PTR record for all recursive look-ups for resources that have the DNS suspended. This provides in-band feed back and feedback through Whois in the nameserver field. >> > I think this is a very bad idea. > > Turning off DNS is one thing. Hijacking it is another. A similar tactic was tried by Network Solutions > once upon a time to make revenue out of typos. It was not well liked by the community. Yea, after thinking about it more that's not a good idea at all. >> A final option, ARIN could simply publish a list of resource for which it has suspended DNS. This is my least preferred option, it is out-of band and I have to go look someplace else then Whois. But it might be a good stop-gap solution allowing ARIN time to implement one or both of the above solutions. >> > I wouldn't oppose this, but, again, it's an operational matter. > >> Breaking DNS in a way that is invisible to third parties is not good operational practice. In this case the cure might be worse then the disease. So find a way to operationally signal that DNS has been suspended then I'll support the proposal. This might not require any change to the policy text itself, this may simply need to be an implementation note in the rationale. >> > How is a lack of NS records invisible to third parties? I must be missing something in your thinking process > here. I was missing the idea that the nameserver record would be removed and part of suspending DNS service. And yes it is an operational matter, but it does matter. Maybe that could be noted in the rational that the Whois nameserver record should be cleared as part of suspending DNS service. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From bensons at queuefull.net Wed Feb 16 21:18:56 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 20:18:56 -0600 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> Message-ID: <9631A2CC-DB28-47D3-898A-02B45E05E1CF@queuefull.net> Hi, Bill. On Feb 16, 2011, at 7:40 PM, William Herrin wrote: >> Prop 134 makes the definition of "Legitimate Address Holder" >> a matter of community consensus rather than a staff implementation. > > A. The community doesn't actually have a consensus on this. > > B. If we did have a consensus, it wouldn't be prop 134. If there isn't consensus on this topic, then what does ARIN implement? My understanding is that ARIN staff currently implements something similar to prop 134. If there are differences, I'm hoping to understand and discuss them. > C. Historically speaking, the kinds of documentation you're looking > for often isn't there. This is a challenge, I suppose. I believe that I may need to update the text, based on a comment John Curran made, to reflect the validity of historical whois updates. But we should talk about the implications, in as much as it is possible for ARIN to make a mistake. E.g. Theoretically, if multiple years ago I told ARIN that your block was mine and ARIN accepted that update, could you present yourself now and successfully dispute that change? What policy would you rely upon? > D. Policy for policy's sake is unhelpful. It merely solidifies > bureaucracy and ties folks hands when the odd exceptional case comes > along. ARIN today does a fine job sorting out who is the rightful > address holder when an update is requested but the POCs are defunct. > Let 'em be. I'm sure that is often the case. But I have heard a number of accounts that contradict your statement. Granted, these accounts mostly have to do with application of policy to legacy resources, when the organizations involved didn't expect to be subject to that policy. For example, I don't believe ARIN will update the whois to reflect a transfer of legacy resources to a party that refuses to submit to "justification of need" policy. We can debate whether the recipient is obliged to submit, but that would miss the point. The point is that if ARIN refuses to update whois in any circumstances, then we run the risk of inaccurate data - the more likely those circumstances are, the less accurate the whois will become. And I'd argue that IPv4 exhaustion makes some circumstances (such as the sale of legacy address blocks) even more likely. Cheers, -Benson From bensons at queuefull.net Wed Feb 16 21:40:42 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 20:40:42 -0600 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> Message-ID: <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> On Feb 16, 2011, at 1:01 PM, George Herbert wrote: > > I oppose this policy proposal. > ... > IF this were to be successful, the time to do it was 2-4 years ago. Maybe. But I think IPv4 exhaustion motivates a number of thoughts now that people weren't motivated by 2-4 years ago. > Given the policy / political / legal uncertainty of what the ultimate > outcome will be of answering the question: "for values of 'own' that > include financial compensation for use of them, who 'owns' legacy IP > space?" ... This is a fundamental question, yes. It's not directly dealt with in prop 133, but it is an issue related to 133's motivation. I'd argue that in the near future, some people will need IPv4 addresses less while others will be increasingly willing to pay for IPv4 addresses. It doesn't matter how absurd the notion of addresses as property might appear on the surface (I assume all intellectual property, property rights, etc, feel absurd to some people until they're established by law) the ability to route IP addresses has value. > The only part of this that makes sense now is to ask > large-enough-to-matter legacy holders what their usage is and to ask > them to renumber if the answer is low and the effort reasonable, in > the name of the common good. There's no downside to asking for that. > Trying to force the issue seems like unnecessary and unproductive > strife. I don't think that we can recover enough resources to help the overall community, no matter how we approach the recovery process. But we might be able to find enough resources to help those that are willing to pay for them. And holders might be more willing to provide resources if they're compensated. Admittedly, prop 133 doesn't deal with this topic directly. But it would open the door to allow legacy resources alternative governance, market policy, etc. Cheers, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bensons at queuefull.net Wed Feb 16 21:52:14 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Wed, 16 Feb 2011 20:52:14 -0600 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders - Preemption of changes to date? In-Reply-To: References: <4D5AFBA2.9070206@arin.net> Message-ID: Hi, John. On Feb 16, 2011, at 3:03 PM, John Curran wrote: >> Further, in the event that this evidence conflicts with any evidence >> from the original allocation records, or any contrary documentation such >> as those specified in section 13.x.4 below, the evidence from the >> original allocation record will take precedence. > ... > Is it your intent via this proposal that all changes to legacy address holder > records that have occurred since ARIN's inception be vacated? No, this would be a mistake in the wording. I intend for formal documentation to update RIR data, and RIR data to update legacy data etc. The exception would be if, for whatever reason, IANA has current data that conflicts - this is an artificial example, but for instance if IANA were to reclaim an address block I'd argue this should take precedence. Thanks for catching this. I'll work on revised text and submit an update. Cheers, -Benson From jcurran at arin.net Wed Feb 16 21:54:22 2011 From: jcurran at arin.net (John Curran) Date: Thu, 17 Feb 2011 02:54:22 +0000 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <9631A2CC-DB28-47D3-898A-02B45E05E1CF@queuefull.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> <9631A2CC-DB28-47D3-898A-02B45E05E1CF@queuefull.net> Message-ID: <812BB46F-0782-4753-B9C9-20959318030F@corp.arin.net> On Feb 16, 2011, at 9:18 PM, Benson Schliesser wrote: > For example, I don't believe ARIN will update the whois to reflect a transfer of legacy resources to a party that refuses to submit to "justification of need" policy. ARIN updates the Whois in accordance with the community-developed policy. > We can debate whether the recipient is obliged to submit, but that would miss the point. The point is that if ARIN refuses to update whois in any circumstances, then we run the risk of inaccurate data - the more likely those circumstances are, the less accurate the whois will become. And I'd argue that IPv4 exhaustion makes some circumstances (such as the sale of legacy address blocks) even more likely. The community needs to make policy which balances different needs: conservation, registration, and aggregation. ARIN will update the database in accordance with such policies. It's not up to the staff what the appropriate tradeoffs are in balancing these goals and risks, it's up to the community to set. Note that there are presently transfer policies which cover merger and acquisition (NRPM 8.2), and also specified transfers to another party (NRPM 8.3). To the extent that the proposal affects the processing of these transfers, it would be best if policy proposal specifically augmented or replaced these sections so that there is an unambiguous result. Thanks! /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Wed Feb 16 22:00:37 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 16 Feb 2011 22:00:37 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> Message-ID: On Wed, Feb 16, 2011 at 9:40 PM, Benson Schliesser wrote: > > On Feb 16, 2011, at 1:01 PM, George Herbert wrote: > > I oppose this policy proposal. > ... > IF this were to be successful, the time to do it was 2-4 years ago. > > Maybe. ?But I think IPv4 exhaustion motivates a number of thoughts now that > people weren't motivated by 2-4 years ago. > > Given the policy / political / legal uncertainty of what the ultimate > outcome will be of answering the question: ?"for values of 'own' that > include financial compensation for use of them, who 'owns' legacy IP > space?" ... > > This is a fundamental question, yes. ?It's not directly dealt with in prop > 133, but it is an issue related to 133's motivation. > I'd argue that in the near future, some people will need IPv4 addresses less > while others will be increasingly willing to pay for IPv4 addresses. ?It > doesn't matter how absurd the notion of addresses as property might appear > on the surface (I assume all intellectual property, property rights, etc, > feel absurd to some people until they're established by law) the ability to > route IP addresses has value. > > The only part of this that makes sense now is to ask > large-enough-to-matter legacy holders what their usage is and to ask > them to renumber if the answer is low and the effort reasonable, in > the name of the common good. ?There's no downside to asking for that. > Trying to force the issue seems like unnecessary and unproductive > strife. > > I don't think that we can recover enough resources to help the overall > community, no matter how we approach the recovery process. ?But we might be > able to find enough resources to help those that are willing to pay for > them. ?And holders might be more willing to provide resources if they're > compensated. > Admittedly, prop 133 doesn't deal with this topic directly. ?But it would > open the door to allow legacy resources alternative governance, market > policy, etc. > Cheers, > -Benson > > > _______________________________________________ > 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. > In an earlier comment I stated that I fundamentally disagree with legacy holders receiving free services at the expense of ARIN members, however, it is now clear to me that ARIN members also benefit from this service so perhaps the status quo should be maintained. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jcurran at arin.net Wed Feb 16 22:35:53 2011 From: jcurran at arin.net (John Curran) Date: Thu, 17 Feb 2011 03:35:53 +0000 Subject: [arin-ppml] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> Message-ID: <52368FF6-A10E-4DF1-806D-F96DF05D73BF@corp.arin.net> On Feb 16, 2011, at 9:40 PM, Benson Schliesser wrote: > It doesn't matter how absurd the notion of addresses as property might appear on the surface ... the ability to route IP addresses has value. Please note specifically that entry in ARIN's Whois database does not provide "the ability to route IP addresses" (reference: NRPM 4.1.1) but I believe your point is understood. > I don't think that we can recover enough resources to help the overall community, no matter how we approach the recovery process. But we might be able to find enough resources to help those that are willing to pay for them. And holders might be more willing to provide resources if they're compensated. The ability for address holders to be compensated for providing resources is not precluded by the present specified transfer policy (NRPM 8.3), and there are parties pursuing such. Can you elaborate on how Prop 133 would change this situation? > Admittedly, prop 133 doesn't deal with this topic directly. But it would open > the door to allow legacy resources alternative governance, market policy, etc. That is a interesting theory, particularly in light of the present set of global policies in the Internet number registry system. FYI, /John John Curran President and CEO ARIN From Keith at jcc.com Wed Feb 16 23:17:43 2011 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 16 Feb 2011 23:17:43 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> Message-ID: Benson You said: I don't think that we can recover enough resources to help the overall community, no matter how we approach the recovery process. But we might be able to find enough resources to help those that are willing to pay for them. And holders might be more willing to provide resources if they're compensated. Admittedly, prop 133 doesn't deal with this topic directly. But it would open the door to allow legacy resources alternative governance, market policy, etc. I am missing the big picture here. I don't see how prop 133 opens the door to allow legacy resources alternative governance, market policy, etc. I also don't see what added value would be provided by alternative governance, market policy, etc. As I read the current ARIN transfer policy Section 8.3 "Transfers to Specified Recipients" (https://www.arin.net/policy/nrpm.html#eight3), transfers can be made to specified recipients as long as the recipient can demonstrate need under the current ARIN policies. So, if a recipient can justify need under the current ARIN policies and can find some organization willing to transfer, what is wrong with the ARIN process? And, if a recipient cannot justify need, why is the recipient interested? Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: From woody at pch.net Wed Feb 16 23:42:08 2011 From: woody at pch.net (Bill Woodcock) Date: Wed, 16 Feb 2011 20:42:08 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No.Volunteer.Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> Message-ID: On Feb 16, 2011, at 20:33, "Keith W. Hare" wrote: > if a recipient cannot justify need, why is the recipient interested? > Because the would-be recipient bought a machine-trading algorithm at the Enron bankruptcy sale, and has been looking for an unregulated commodity market ever since. -Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Feb 16 23:50:17 2011 From: bill at herrin.us (William Herrin) Date: Wed, 16 Feb 2011 23:50:17 -0500 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <9631A2CC-DB28-47D3-898A-02B45E05E1CF@queuefull.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> <9631A2CC-DB28-47D3-898A-02B45E05E1CF@queuefull.net> Message-ID: On Wed, Feb 16, 2011 at 9:18 PM, Benson Schliesser wrote: >> C. Historically speaking, the kinds of documentation you're looking >> for often isn't there. > > This is a challenge, I suppose. ?I believe that I may need to update > the text, based on a comment John Curran made, to reflect the > validity of historical whois updates. ?But we should talk about the > implications, in as much as it is possible for ARIN to make a mistake. > ?E.g. Theoretically, if multiple years ago I told ARIN that your block > was mine and ARIN accepted that update, could you present > yourself now and successfully dispute that change? ?What policy > would you rely upon? Hi Benson, As I understand it, it depends on the details. Was the "update" a transfer to a different organization than the original registrant? If so then the new org signed an RSA to get it and is subject to the contractual rules about fraud. That's one of the more or less settled issues -- can't transfer the resources as legacy addresses. The process of transferring them ends the legacy status. For the most part, even the legacy registrants support this one. Was it just a POC update? If so, you can update the POC back to correct values with documentation. And really it's your own fault. Granted email-auth was never stellar but if you kept your POC up to date (like you agreed to do when you submitted the form to the NIC way back when) then no one snuck the addresses out from under you. At the end of the day, though, you don't rely on policy. That's part of the bargain: policy doesn't touch you, for good or for ill. If you want to be able to rely on policy, you sign the RSA or LRSA and accept the strings that come with it. >For example, I don't believe ARIN will update the whois to >reflect a transfer of legacy resources to a party that refuses to >submit to "justification of need" policy. ?We can debate >whether the recipient is obliged to submit, but that would >miss the point. ?The point is that if ARIN refuses to update >whois in any circumstances, then we run the risk of inaccurate >data - the more likely those circumstances are, the less >accurate the whois will become. ?And I'd argue that IPv4 >exhaustion makes some circumstances (such as the sale >of legacy address blocks) even more likely. The two issues are interrelated. ISPs get real leery about announcing addresses whose registration doesn't match a the customer with which they're dealing. Makes transfers without ARIN's blessing quite hard. And ARIN only accepts transfers when the recipient is under a full RSA, ending the legacy status of the transferred addresses. So yeah, I can hand my legacy block to my buddy Joe and write him a letter of authorization for an ISP to route them, but he can't get ARIN to transfer them to someone else (he's not the official registrant) and every time he wants to route them he's going to get grief because, again, he's not the official registrant. Really puts a damper on the whole transfer-outside-the-RIR plan. If I was buying addresses from someone, I'd far prefer to accept the RSA than deal with the fact that the addresses officially remain registered to someone else. They're not really mine until they're registered to me and I'm not going to pay you to keep the addresses registered to you. One key point is this: there's a vast amount of institutional knowledge in ARIN's process for dealing with legacy registrants, techniques and approaches built up as a result of dealing with real situations over a decade and a half. You won't be able to capture it in 5 or 10 paragraphs of policy text; you'll only take a flexible, workable process and make it more rigid. The most it's healthy to do here is tweak it a little and even then only if there's situations you can point to where ARIN obviously did the wrong thing and has vowed to do so again next time. Regards, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Thu Feb 17 00:08:38 2011 From: bill at herrin.us (William Herrin) Date: Thu, 17 Feb 2011 00:08:38 -0500 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: <4D5BFFBA.7040700@umn.edu> References: <4D5BFFBA.7040700@umn.edu> Message-ID: On Wed, Feb 16, 2011 at 11:47 AM, David Farmer wrote: > I support the the intended result of this proposal and this is text is an > improvement. I too like the sentiment behind the proposal but... two thoughts: 1. ARIN should have fairly broad leeway to determine when a registrant just isn't acting in good faith to return to compliance. 30 to 60 days is not very broad. If you want to set a minimum of 30 days before ARIN takes action, that's fine, but don't set a max. Such "zero tolerance" policies have a history of making small problems big. 2. When ARIN determines that an organization isn't acting in good faith to return to compliance, don't pussy-foot around with little escalations like suspending RDNS. Registration revoked. Boom. ARIN will hold the addresses for the normal inactivity period and if you want to give the registrant one final chance, give them first priority to reapply (during that inactivity period) for as much of the revoked address space as they can justify under current policy. 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 Thu Feb 17 00:09:59 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 21:09:59 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <1110216191216.31932D-100000@Ives.egh.com> References: <1110216191216.31932D-100000@Ives.egh.com> Message-ID: On Feb 16, 2011, at 4:18 PM, John Santos wrote: > On Wed, 16 Feb 2011, Owen DeLong wrote: > >>> There's no special right, just the right to use the addresses as >>> they always have, not subject to capricious revokation or random >>> reallocation or reassignment of their addresses by an organization >>> with whom they have no contract or business relationship. >>> >> Speaking only for myself... >> >> I think it is unfair to characterize any ARIN revocation, reallocation, >> or reassignment that has taken place as capricious. >> >> To the best of my knowledge, ARIN has always had very good reasons >> supported by policy developed by the community for each and >> every resource that has been revoked, reallocated, or reassigned >> with the possible exception of some accidental duplicates, in which >> case, what was done was an attempt to minimize and disruption >> to the parties involved, usually with the cooperation and consent >> of the parties. >> >> Owen > > I should have been more clear: "Capricious" wasn't meant to be a > characterization of ARIN's past actions, but a worst-case fear for > the future. Some of the proposals that have been made here in the > past would I think qualify, but none has come close to passing. > I believe that ARIN leadership has a sufficient track record of carefully avoiding arbitrary or capricious action to warrant a certain level of benefit of the doubt. They will, I believe, even in the worst case, cautiously implement policy defined by the community and ratified by the Board of Trustees. I think the fact that no arbitrary or capricious proposal has come close to passing can be viewed as a certain amount of assurance that the process does, indeed, work as intended. It would work better, especially being able to better represent the interests of legacy holders if more of them participated in the process. Unfortunately, while we are discussing (unreasonable) fears, there appears to be a fair amount of fear among some legacy holders that if they participate in the ARIN public policy process, it will somehow weaken their (arbitrary and capricious) position that ARIN has no responsibility for or authority over their registrations and/or what happens to the addresses if they are no longer using them for the purpose under which they were granted. > Sanity and fairness always seem to have prevailed at least as long > as I've been lurking on PPML, which I think is one of the strongest > arguments for preserving ARIN's role. > I completely agree. Owen (who continues to try and keep things sane so long as the members continue to re-elect me) From owen at delong.com Thu Feb 17 00:13:36 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 21:13:36 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: <4D5C783D.7050805@umn.edu> References: <4D5C1EB1.1020007@arin.net> <4D5C783D.7050805@umn.edu> Message-ID: <9EAF6523-36F5-4A9D-936D-E8067119BE2B@delong.com> We do, but, I would still like to see the modifications in my propose motion made to the current text. Owen On Feb 16, 2011, at 5:22 PM, David Farmer wrote: > I support this policy moving forward as a Draft Policy and being discussed at the next PPM. If there is significant movement on the global policy front in some of other regions, I may reconsider my support following the PPM. But, we need to discuss and consider this option for possible adoption at the up coming PPM in San Juan. > > On 2/16/11 13:00 CST, ARIN wrote: > >> Section 5.0 Legacy Addresses >> >> 5.1 Returned Legacy Addresses >> >> Legacy IPv4 addresses returned to or recovered by ARIN will be made >> available for registration and distribution in the ARIN region. >> >> Rationale: >> >> Adopting this proposal will result in the clarification of the status >> of returned legacy addresses. IPv4 address resources should not sit >> idle due to lack of policy clarity. >> >> Timetable for implementation: Immediately > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Feb 17 00:21:29 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 21:21:29 -0800 Subject: [arin-ppml] New Version of ARIN-prop-126: Compliance Requirement In-Reply-To: <4D5C80E2.3040607@umn.edu> References: <4D5BFFBA.7040700@umn.edu> <4881F12D-80AA-41BA-A710-9647A3683061@delong.com> <4D5C80E2.3040607@umn.edu> Message-ID: On Feb 16, 2011, at 5:58 PM, David Farmer wrote: > On 2/16/11 11:38 CST, Owen DeLong wrote: >> >> On Feb 16, 2011, at 8:47 AM, David Farmer wrote: >> >>> I support the the intended result of this proposal and this is text is an improvement. However, I have a problem with the removal of DNS service without some kind of signal to third parties. >>> >>> As a third party under this proposal all I see is reverse DNS breaking and have no clue why. Is it an action by ARIN, a lame delegation, a temporary problem of some other kind. >>> >> That's true in any resource revocation today, so, I'm not sure what you perceive as different. > > The resource is removed from Whois when it is revoked. > >> It isn't a lame delegation because there are no NS records to be lame. >> >> You see that there are no NS records, you can be reasonably certain it is action by ARIN, no? > > OK, when ARIN suspends DNS service it removes the nameserver record in the Whois entry, that works for me. When I read suspend DNS, I was think only breaking the glue records, as long as the Whois nameserver records are removed too, then we are good. > There shouldn't be glue records in in-addr.arpa. I do not believe that any nameservers in in-addr.arpa are known as, for example: 10.159.192.in-addr.arpa. IN NS ns.10.159.192.in-addr.arpa. ns.10.159.192.in-addr.arpa IN A 192.159.10.2 To the best of my knowledge, such a construct is not even permitted in the current in-addr process, so, removing glue would not be possible. Additionally, removing glue wouldn't make sense because it would only affect name-servers whose A/AAAA records are names within the affected in-addr.arpa zone. If you don't remove the NS records, you have not suspended DNS. >>> One option would be some kind of status field associated with the Whois record stating the DNS service is suspended. >>> >> I wouldn't oppose this, but, that's an operational matter ARIN can choose to implement, not really a policy issue. >> >>> Another option, could be to change the DNS pointer records in Whois and the production DNS, referring to a DNS service operated by ARIN for suspended DNS. Maybe with a wildcard returning "Suspended.DNS.ARIN.net" as the PTR record for all recursive look-ups for resources that have the DNS suspended. This provides in-band feed back and feedback through Whois in the nameserver field. >>> >> I think this is a very bad idea. >> >> Turning off DNS is one thing. Hijacking it is another. A similar tactic was tried by Network Solutions >> once upon a time to make revenue out of typos. It was not well liked by the community. > > Yea, after thinking about it more that's not a good idea at all. > :) >>> A final option, ARIN could simply publish a list of resource for which it has suspended DNS. This is my least preferred option, it is out-of band and I have to go look someplace else then Whois. But it might be a good stop-gap solution allowing ARIN time to implement one or both of the above solutions. >>> >> I wouldn't oppose this, but, again, it's an operational matter. >> >>> Breaking DNS in a way that is invisible to third parties is not good operational practice. In this case the cure might be worse then the disease. So find a way to operationally signal that DNS has been suspended then I'll support the proposal. This might not require any change to the policy text itself, this may simply need to be an implementation note in the rationale. >>> >> How is a lack of NS records invisible to third parties? I must be missing something in your thinking process >> here. > > I was missing the idea that the nameserver record would be removed and part of suspending DNS service. And yes it is an operational matter, but it does matter. > Of course it matters. See above. It hadn't occurred to me that there was any other way to discontinue DNS service and I still think there is not. > Maybe that could be noted in the rational that the Whois nameserver record should be cleared as part of suspending DNS service. > Assuming you mean the rationale, I don't think that the WHOIS nameserver record should be modified. I think that the DNS NS record should be temporarily removed until such time as a final resolution is achieved. At that time, either the entire whois record is removed, or, the NS records are restored (based on the whois data) or new NS records are inserted (based on an update which should also be applied to the whois record). Owen > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== From owen at delong.com Thu Feb 17 00:32:25 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 21:32:25 -0800 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <9631A2CC-DB28-47D3-898A-02B45E05E1CF@queuefull.net> References: <4D5AFBA2.9070206@arin.net> <91F559FA-A253-48EE-AA46-E90EB6A9B30C@corp.arin.net> <01828FBF-73F1-4413-909D-3BD5B08693BB@queuefull.net> <9631A2CC-DB28-47D3-898A-02B45E05E1CF@queuefull.net> Message-ID: On Feb 16, 2011, at 6:18 PM, Benson Schliesser wrote: > Hi, Bill. > > On Feb 16, 2011, at 7:40 PM, William Herrin wrote: >>> Prop 134 makes the definition of "Legitimate Address Holder" >>> a matter of community consensus rather than a staff implementation. >> >> A. The community doesn't actually have a consensus on this. >> >> B. If we did have a consensus, it wouldn't be prop 134. > > If there isn't consensus on this topic, then what does ARIN implement? My understanding is that ARIN staff currently implements something similar to prop 134. If there are differences, I'm hoping to understand and discuss them. > Most definitely speaking only for myself and of my own perspective here: John has already pointed you to documentation of ARIN's operational practices (which are not policy and were built more on the experience of ARIN staff and their ability to do the right thing than on community consensus as regards this particular topic). Note, I'm not saying that policy in this area is a good or bad idea, just that policy is a matter of community consensus, whereas operational practices sometimes have to develop in the absence of guiding policy and such has been the case in this area to at least some extent. The current operational practices definitely differ from prop 134 in significant ways and I suggest you review the documents that were linked by John in his earlier messages. >> C. Historically speaking, the kinds of documentation you're looking >> for often isn't there. > > This is a challenge, I suppose. I believe that I may need to update the text, based on a comment John Curran made, to reflect the validity of historical whois updates. But we should talk about the implications, in as much as it is possible for ARIN to make a mistake. E.g. Theoretically, if multiple years ago I told ARIN that your block was mine and ARIN accepted that update, could you present yourself now and successfully dispute that change? What policy would you rely upon? > Yes. I believe that an equivalent situation has come up and the legitimate registrant was able to approach ARIN with appropriate documentation and ARIN was able to resolve the issue in favor of the legitimate block registrant. I do not recall the specifics and I am not sure it is exactly as described above or as I recall it. I am also not sure how much of the details of such a situation ARIN could make public if that were the case. (My knowledge of this event is independent of ARIN). If you are the legitimate resource holder, there is no need to rely solely on policy. Once a block is registered to you, absent revocation or transfer through a legitimate process recognized by ARIN, you remain the legitimate registrant. I believe this is the spirit that runs throughout the entirety of the NRPM and ARIN operational procedures rather than being spelled out in a separate particular policy. >> D. Policy for policy's sake is unhelpful. It merely solidifies >> bureaucracy and ties folks hands when the odd exceptional case comes >> along. ARIN today does a fine job sorting out who is the rightful >> address holder when an update is requested but the POCs are defunct. >> Let 'em be. > > I'm sure that is often the case. But I have heard a number of accounts that contradict your statement. Granted, these accounts mostly have to do with application of policy to legacy resources, when the organizations involved didn't expect to be subject to that policy. For example, I don't believe ARIN will update the whois to reflect a transfer of legacy resources to a party that refuses to submit to "justification of need" policy. We can debate whether the recipient is obliged to submit, but that would miss the point. The point is that if ARIN refuses to update whois in any circumstances, then we run the risk of inaccurate data - the more likely those circumstances are, the less accurate the whois will become. And I'd argue that IPv4 exhaustion makes some circumstances (such as the sale of legacy address blocks) even more likely. > ARIN Should not recognize such a transfer. In the event of such a transfer, ARIN absolutely should remove the registration for those resources and make the addresses available for registry to an organization with proper justified need. There is no precedent anywhere that should lead an organization that is not a legacy holder to believe that their receipt of such a transfer would in some way be exempt from ARIN policy, nor is there any reason for a legacy holder to believe that, either. Address resources were never considered transferrable without permission of the applicable registry, even before the existence of ARIN. Owen > Cheers, > -Benson > > _______________________________________________ > 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 Feb 17 00:47:52 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 16 Feb 2011 21:47:52 -0800 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks] In-Reply-To: <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> References: <4D595D34.1090709@arin.net> <3d11805b613f22f0c7c558edf2024fb84d597bd4@jcc.com> <75822E125BCB994F8446858C4B19F0D7143AF29C5B@SUEX07-MBX-04.ad.syr.edu> <4D5C185C.2030509@ipinc.net> <3781795D-77D3-498C-996C-83E16D5045C1@queuefull.net> Message-ID: On Feb 16, 2011, at 6:40 PM, Benson Schliesser wrote: > > On Feb 16, 2011, at 1:01 PM, George Herbert wrote: >> >> I oppose this policy proposal. >> ... >> IF this were to be successful, the time to do it was 2-4 years ago. > > Maybe. But I think IPv4 exhaustion motivates a number of thoughts now that people weren't motivated by 2-4 years ago. > Panic often provides motivations that don't manifest themselves absent a rush of adrenaline. The USA-PATRIOT act is proof that they do not lead to good policy. >> Given the policy / political / legal uncertainty of what the ultimate >> outcome will be of answering the question: "for values of 'own' that >> include financial compensation for use of them, who 'owns' legacy IP >> space?" ... > > This is a fundamental question, yes. It's not directly dealt with in prop 133, but it is an issue related to 133's motivation. > Well, prop. 133 certainly seeks to (or accidentally) limits the possible answers that ARIN can select in its response to that question. > I'd argue that in the near future, some people will need IPv4 addresses less while others will be increasingly willing to pay for IPv4 addresses. It doesn't matter how absurd the notion of addresses as property might appear on the surface (I assume all intellectual property, property rights, etc, feel absurd to some people until they're established by law) the ability to route IP addresses has value. > The usual disclaimer: Speaking ONLY as and for myself: ARIN has no direct control over the ability to route IP addresses whatsoever. If you want to control that, you should be talking to ISPs. They run routers and configure them. ARIN does not. ARIN policy is about registration of IP numbers to organizations and the integrity and fairness of that registration database. There is specifically no warranty from ARIN that registration of a number has anything to do with the ability to place it in someone else's routing table or not. While, coincidentally, many ISPs choose to recognize the ARIN database as a valuable source of registration information that is used in their decision making process about who to accept or reject a route from, it is only one of many inputs into that process in most cases and the ISP is absolutely free to ignore ARIN and the AIRN database altogether. Even if you somehow manage to establish the idea that prefix routing rights are somehow a form of property, I'm not sure what that set of rights would have to do with the ARIN registration database or registration services. >> The only part of this that makes sense now is to ask >> large-enough-to-matter legacy holders what their usage is and to ask >> them to renumber if the answer is low and the effort reasonable, in >> the name of the common good. There's no downside to asking for that. >> Trying to force the issue seems like unnecessary and unproductive >> strife. > > I don't think that we can recover enough resources to help the overall community, no matter how we approach the recovery process. But we might be able to find enough resources to help those that are willing to pay for them. And holders might be more willing to provide resources if they're compensated. > There is a process available for that today. > Admittedly, prop 133 doesn't deal with this topic directly. But it would open the door to allow legacy resources alternative governance, market policy, etc. > Or not. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Thu Feb 17 01:48:35 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 16 Feb 2011 22:48:35 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <1110216141453.31932B-100000@Ives.egh.com> References: <1110216141453.31932B-100000@Ives.egh.com> Message-ID: <4D5CC4C3.7050202@ipinc.net> On 2/16/2011 11:32 AM, John Santos wrote: > On Wed, 16 Feb 2011, Ted Mittelstaedt wrote: > > ... one of the most illogical posts I have ever read on a technical > mailing list. > > >> On 2/15/2011 11:32 PM, George Bonser wrote: >>>> >>>> The Internet will be Dead -> Kill the Internet ? >>>> >>> >>> I don't think the internet is going to die because of whois entries. At >>> best it is just a distraction. At worst, it is a sort of retroactive >>> changing of the rules that have been in place for a very long time. If >>> it hasn't already destroyed the Internet over the past 20 years of the >>> general public being on it, it isn't going to break anything over the >>> next few years. This almost seems to be like several ways of somehow >>> getting hold of legacy address space or making it easier to hijack it. >>> Forget it. Those addresses were issued in a different time under >>> different rules and you can't just go changing the rules now just >>> because we have run out of them. >> >> Yes you can. There is plenty of legal precedent for doing just that >> in every legal system in the world. > > Ever hear of ex post facto? It's unconstutional in the US. > If the ARIN community says tomorrow that all legacy holdings must be returned that is not violating ex post facto. If they started saying that the use of those assignments for the last 15 years was illegal 15 years ago then yes, that WOULD be ex post facto. >> >> And in fact, we HAVE done this. We have done it by setting up a >> system to make legacy IPv4 obsolete. >> > > We don't go around seizing buggy whips. Making it obsolete does > not deprive holders of the right to use it as they see fit. > This greatly stretches the definition of "use" IMHO. If the rest of the world is no longer using IPv4 then any IPv4 holdings that you have become impossible to use, unless your goal is to run an antique computer museum or something like that which is not connected to the rest of the world. >> What I find quite interesting is this concept that legacy holders have >> special IP addressing "rights" > > Straw man. > > There's no special right, just the right to use the addresses as > they always have, not subject to capricious revokation or random > reallocation or reassignment of their addresses by an organization > with whom they have no contract or business relationship. > But they can't use the addresses "as they always have" because IPv6 will eventually displace the legacy addresses. >> >> If this is really true, then why aren't the legacy holders arguing that >> their "rights" are for IP ADDRESSING, not "IPv4 addressing" > > Because we were assigned IPv4 addresses by the legitimate orginization > at the time, not IPv6 addresses or DECnet addresses, IPv4 addresses. > >> >> IPv4 and IPv6 addresses are....drumroll.... "IP addresses" > > False equivalence. > > No legacy holders were assigned IPv6 addresses. > >> >> If the legacy holders really and truly have special "ip addressing" >> rights then by NOT giving them FREE IPv6 assignments we are VIOLATING >> those rights - and they have a legal claim to go challenge ARIN's >> decision to NOT extend FREE IPv6 registrations to them. > > Straw man. It is your false equivalence of IPv4 and IPv6 addresses > which leads to this claim. No legacy holders are making it. Second > straw man in the same paragraph. No legacy holders are claiming any > right to additional addresses beyond what they already hold. > >> >> If you peruse the handwritten spiral notebook that the "original" IPv4 >> addresses were assigned off of, you don't find mention of "IPv4". You >> just find "IP addresses" > > If you scan the sales logs of any home electronics store in 1955, > you won't find any mention of "black and white television set", just > "television set". But all the IP addresses were 4 octets and unique > within that 32-bit address space and were assigned in conformance with > the relevant IPv4 RFCs. > >> >> If you look into the "deal" that was made when ARIN was created you >> find this as well. >> >> The concept that "Legacy IP Addresses" were specifically IPv4 and not >> IPv6 is something that has been invented. It has no basis on the >> original assignment documents that the Legacy holders are pretending >> their supposed "rights" derive from. >> > > Yet another total straw man. No legacy holder is claiming the equivalancy > of IPv4 and IPv6. > >> And, the Legacy holders know it. They know perfectly well that there >> isn't any such thing as special rights for them just because they got >> addresses under different rules. That is why they aren't suing ARIN for >> free IPv6 assignments. > > No, it's because they received the holdings under one set of rules, > and won't accept rule changes without carefully vetting them first, > which requires time and money. You are worse then my 6-year-old > niece who constantly changed the rules of "Trouble" based on her > dice rolls. Grow up! > The set of rules that existed when they got their addresses were a product of the environment of the time, just as the lack of speed limits on roads 100 years ago were a product of their time. But the rules were changed and the speed limits came. They were applied despite the vehicle owners objections. And the shift to IPv6 was made despite the legacy holders assignments, that is also a rule change. If the original IP assignment scheme did not have the limiting problem that it does, and didn't force a shift to IPv6, then the legacy holders would probably have had the IPv4 rules changed out from under themselves for the simple fact that eventually the community would have lost tolerance for the freeloading, if no other reason. How long does patent law allow an inventor in the US to continue to profit from his invention? How long would it be reasonable to allow the legacy IP holders to profit from being first in the boat? Do you seriously think that legacy addresses would be allowed to be handed down from father to son forever? When your dead of old age then would the argument that your son "spent a lot of money helping with the formation of the Internet and in exchange for doing that he gets a free IP assignment" have any moral validity? Because, that is the primary moral validation for allowing legacy holders to not help underwrite the costs of address assignment maintaining. Ted > >> >> The problem is that too many other people like you have swallowed this >> "legacy holder rights' baloney and actually believe the lie. >> > > What lie? > > > >> Ted >> >> We have known this time was going to >>> come for a very long time. Here we are. It is what it is. >>> >>> >>> _______________________________________________ >>> 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 tedm at ipinc.net Thu Feb 17 03:01:28 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 17 Feb 2011 00:01:28 -0800 Subject: [arin-ppml] Fraud or not? In-Reply-To: <876B0377-1A7B-473D-8C4A-7EA28F1CC63F@delong.com> References: <38911.1297831688@tristatelogic.com> <643DF814-D2D2-4E91-9114-2FD563CE08BA@delong.com> <4D5C1316.8060604@ipinc.net> <876B0377-1A7B-473D-8C4A-7EA28F1CC63F@delong.com> Message-ID: <4D5CD5D8.8020000@ipinc.net> On 2/16/2011 1:05 PM, Owen DeLong wrote: > Output, sure. However, the web-based one is much stricter and less > intelligent about parsing queries and THAT is the primary problem I'm > having. > > Instead of realizing that the old "AS10912" query means the same > thing to the user as the new arcane syntax "a 10912" (which the > old version did just fine), the new version neither fails nor works > consistently (or at least the behavior appears very inconsistent > until you begin to understand an additional arcane set of rules). > > The actual result is: > > 1. Some command line clients do the translation for you. > (good for them, but, not universal) > > 2. If you query ASnnnnn, then, whether you get a good > result back or not depends on whether or not ASnnnnn > is the handle for the resource. If I were to create > an AS Number record, for example, named AS105, > but, which was actually AS693, then, I would get > the following odd mixture: > > Query Result > AS105 Record for AS693 > AS693 Nothing > a 105 Record for AS105 > a 693 Record for AS693 > > (Assuming that my client doesn't alter my queries > unexpectedly). > I've noticed similar silliness, for example it's impossible to use whois to query our org POC because it's so old that it has one of those "shorthand" ID's assigned back in the days where the whois maintainers apparently were having a contest to see how short they could make an ID. You query it and it partial-matches dozens of others so it never comes back with just the record. You can only see it if you query for the AS # and then you get both the org POC and the AS record. > I shouldn't have to become an expert in whois arcana to survive > navigating whois for simple everyday queries. > Sigh. I suspect the only way of ever fixing this is for ARIN to dump the entire DB and have someone spend a couple months going through it hand-verifying all of the data for consistency in presentation. Ted > Owen > > On Feb 16, 2011, at 10:10 AM, Ted Mittelstaedt wrote: > >> So do I - but, I will say that once they finally get their web-based one >> to work, it should not be too difficult to write a command line Perl >> script that talks to their web server and outputs like the older command line tool did. >> >> Ted >> >> On 2/15/2011 11:41 PM, Owen DeLong wrote: >>> I really wish ARIN would make the command line whois work as well as >>> it used to instead of focusing all their energy on the (much less convenient >>> much higher overhead from the user perspective) web-based one. >>> >>> Owen >>> >>> On Feb 15, 2011, at 9:03 PM, Scott Leibrand wrote: >>> >>>> On Tue, Feb 15, 2011 at 8:48 PM, Ronald F. Guilmette >>>> > wrote: >>>> >>>> >>>> www.robtex.com says that AS10912 belongs >>>> to Internap. >>>> >>>> whois.arin.net says that there ain't no >>>> such AS. >>>> >>>> So, should I file a formal report charging Internap with fradulent use >>>> of resources that are not actually assigned to them? Or is it more >>>> likely that ARIN has simply (and entirely) misplaced the WHOIS record >>>> for AS10912? >>>> >>>> >>>> It looks like it's only the traditional whois tool that is failing. >>>> The web tool at arin.net reports it as part of >>>> INTERNAP-BLK, which covers ASNs 10910 - 10913. >>>> >>>> http://whois.arin.net/rest/asn/AS10910/pft >>>> >>>> I suspect your message will be enough to get ARIN to fix the whois >>>> port 43 service shortly. :-) >>>> >>>> -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. > > From tedm at ipinc.net Thu Feb 17 04:14:50 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 17 Feb 2011 01:14:50 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <19E865C3-B0DE-4559-BC0A-D4CC8B37DEC0@queuefull.net> References: <4D595D12.4000602@arin.net><75822E125BCB994F8446858C4B19F0D7143AF29C5A@SUEX07-MBX-04.ad.syr.edu><5A6D953473350C4B9995546AFE9939EE0BC13B57@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13B59@RWC-EX1.corp.seven.com> <4D5C1AE0.1030008@ipinc.net> <19E865C3-B0DE-4559-BC0A-D4CC8B37DEC0@queuefull.net> Message-ID: <4D5CE70A.9010806@ipinc.net> On 2/16/2011 5:33 PM, Benson Schliesser wrote: > Ted, I'm not sure why I'm responding to this. I think your comments > conflate a number of different issues. Nevertheless: > > On Feb 16, 2011, at 12:43 PM, Ted Mittelstaedt wrote: >> If this is really true, then why aren't the legacy holders arguing >> that their "rights" are for IP ADDRESSING, not "IPv4 addressing" > > By definition, a "legacy holder" has resources that were received > absent contracts with an RIR. New RIR allocations of IPv4 and IPv6 > don't fit into this category. Further, a legacy holder might have > different rights associated with different address blocks, e.g. if > some of those blocks are legacy, some were received under different > contractual relationships over the years, some were received from > different RIRs, etc. > > -Benson > > A Legacy that signs an RSA for a new IPv4 block agrees with the current definition of what IPv4 is by signing the RSA. That definition is that IP addresses aren't property and the holder does not own them. Arguing that the legacy IPv4 is somehow different than the new Ipv4 is like arguing that my liter of 100% pure water I got last week for free is different than my liter of 100% pure water I got today and paid $5 for - it's unsupportable. Particularly since to get the new allocation of IPv4 the legacy holder is required by ARIN to include ALL the IPv4 they got - legacy, transfer, contractual relationship, etc - as subject to the utilization minimums before getting a new block. They agree to treat all of their prior IPv4 the same - including the legacy - when they request an additional block. This pretty much undercuts the argument you are making that different blocks are different. Ted From info at arin.net Thu Feb 17 11:06:11 2011 From: info at arin.net (ARIN) Date: Thu, 17 Feb 2011 11:06:11 -0500 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 Message-ID: <4D5D4773.6020706@arin.net> The proposal originator submitted revised text. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-131: Section 5.0 Legacy Addresses Proposal Originator: Martin Hannigan Proposal Version: 4.0 Date: 17 February 2011 Proposal type: New Policy term: Permanent Policy statement: Section X.X Legacy Addresses X.X. Returned Legacy Addresses In the absence of an ICANN ratified Global Policy indicating otherwise, legacy IPv4 addresses returned to or recovered by ARIN will be specifically designated and permanently made available for registration and distribution in the ARIN region. Rationale: Adopting this proposal will result in the clarification of the status of returned legacy addresses. IPv4 address resources should not sit idle due to lack of policy clarity. Timetable for implementation: Immediately -------- Original Message -------- Subject: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 Date: Wed, 16 Feb 2011 14:00:01 -0500 From: ARIN To: arin-ppml at arin.net The proposal originator submitted revised text. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-131: Section 5.0 Legacy Addresses Proposal Originator: Martin Hannigan Proposal Version: 3.0 Date: 16 February 2011 Proposal type: New Policy term: Permanent Policy statement: Section 5.0 Legacy Addresses 5.1 Returned Legacy Addresses Legacy IPv4 addresses returned to or recovered by ARIN will be made available for registration and distribution in the ARIN region. Rationale: Adopting this proposal will result in the clarification of the status of returned legacy addresses. IPv4 address resources should not sit idle due to lack of policy clarity. Timetable for implementation: Immediately From owen at delong.com Thu Feb 17 12:32:11 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 09:32:11 -0800 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: <4D5D4773.6020706@arin.net> References: <4D5D4773.6020706@arin.net> Message-ID: <6E5C5DC6-CA90-4821-8D69-FE0D123135AA@delong.com> "Specifically designated and permanently made available" makes no sense to me. If they are permanently available they cannot be registered or distributed as that would make them no longer available. What problem is this latest language change intended to resolve? In what way are they supposed to be "specifically designated?" Owen On Feb 17, 2011, at 8:06 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 4.0 > > Date: 17 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section X.X Legacy Addresses > > X.X. Returned Legacy Addresses > > In the absence of an ICANN ratified Global Policy indicating otherwise, > legacy IPv4 addresses returned to or recovered by ARIN will be > specifically designated and permanently made available for registration > and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status of > returned legacy addresses. IPv4 address resources should not sit idle > due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > -------- Original Message -------- > Subject: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 > Date: Wed, 16 Feb 2011 14:00:01 -0500 > From: ARIN > To: arin-ppml at arin.net > > > > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 16 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > > > > > _______________________________________________ > 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 hannigan at gmail.com Thu Feb 17 14:07:46 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 17 Feb 2011 14:07:46 -0500 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: <4D5D4773.6020706@arin.net> References: <4D5D4773.6020706@arin.net> Message-ID: Folks, An explanation as to why these changes were incorporated post support yesterday. Part of the process leading up to discussion by the AC requires a staff review for clarity and understanding. The ARIN staff had pointed out that the previous text conflicts with a recently adopted global proposal that is not yet adopted in any other RIR region. That means that it is not yet implemented, but it is staged anticipating that the supporting global policy "might" proceed. In order to insure that there was isn't a conflict between this proposal and the pending global proposal, it was suggested that I add some text to clarify and insure that a collision wouldn't occur. ARIN staff also suggested that the section numbers would differ so I marked them up as placeholders only so that this could be properly fit into the NRPM if it is adopted. Best, -M< On Thu, Feb 17, 2011 at 11:06 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 4.0 > > Date: 17 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section X.X Legacy Addresses > > X.X. Returned Legacy Addresses > > In the absence of an ICANN ratified Global Policy indicating otherwise, > legacy IPv4 addresses returned to or recovered by ARIN will be > specifically designated and permanently made available for registration > and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status of > returned legacy addresses. IPv4 address resources should not sit idle > due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > -------- Original Message -------- > Subject: ? ? ? ?ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 > Date: ? Wed, 16 Feb 2011 14:00:01 -0500 > From: ? ARIN > To: ? ? arin-ppml at arin.net > > > > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 16 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > > > > > _______________________________________________ > 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 Thu Feb 17 14:40:21 2011 From: bill at herrin.us (William Herrin) Date: Thu, 17 Feb 2011 14:40:21 -0500 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Thu, Feb 17, 2011 at 2:07 PM, Martin Hannigan wrote: > The ARIN staff had pointed > out that the previous text conflicts with a recently adopted global > proposal that is not yet adopted in any other RIR region. That means > that it is not yet implemented, but it is staged anticipating that the > supporting global policy "might" proceed. Hi Marty, Can you clarify that? Which global proposal and what was the conflict? Thanks, Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bicknell at ufp.org Thu Feb 17 14:49:10 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 17 Feb 2011 11:49:10 -0800 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: <4D5D4773.6020706@arin.net> References: <4D5D4773.6020706@arin.net> Message-ID: <20110217194910.GA67923@ussenterprise.ufp.org> In a message written on Thu, Feb 17, 2011 at 11:06:11AM -0500, ARIN wrote: > In the absence of an ICANN ratified Global Policy indicating otherwise, > legacy IPv4 addresses returned to or recovered by ARIN will be > specifically designated and permanently made available for registration > and distribution in the ARIN region. I think if a legacy holder returns a block it should be passed back to ICANN. It came from a global pool, it should go back to a global pool. However, I realize I am in the minority with that believe. As written the policy is full of wording issues. "Legacy IPv4" isn't precisely defined anywhere, "permanently made available" is very poor wording as Owen pointed out, etc. If folks really want to do this, it can be done so much simpler and easier, and doesn't need to be Legacy specific. To wit: All number resources returned to ARIN will be added to ARIN's available number resources for allocation in the ARIN region, except where otherwise directed by global policy. The point is, you want to clarify we treat legacy addresses the same way non-legacy addresses are treated. The way to do that is not to have two separate policy sections with different wording, but to actually roll them all up through the same policy. Note, I have not looked to see if this needs to replace some paragraph about returned non-legacy resources, or if it just needs to be inserted. Someone should check that if they want to use text similar to what I wrote above. Maybe this needs a qualifier of "after a waiting period" since ARIN historically holds them for a bit so they time out of RBL's and the like. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jcurran at arin.net Thu Feb 17 14:53:53 2011 From: jcurran at arin.net (John Curran) Date: Thu, 17 Feb 2011 19:53:53 +0000 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Feb 17, 2011, at 2:40 PM, William Herrin wrote: > > Can you clarify that? Which global proposal and what was the conflict? As the ARIN Board has already adopted ARIN-2009-3, we need to make sure that 2009-3 (if/when made global) will not conflict. We can do that by including in pp 131 that no legacy space shall be designated for return to IANA (if that is the intent of the policy proposal). This avoids having 2009-3 somehow become active and we having a conflict in adopted policy in NRPM, and having to establish precedence of various sections, etc. FYI, /John John Curran President and CEO ARIN From jeffrey.lyon at blacklotus.net Thu Feb 17 15:06:24 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 17 Feb 2011 15:06:24 -0500 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Thu, Feb 17, 2011 at 2:53 PM, John Curran wrote: > On Feb 17, 2011, at 2:40 PM, William Herrin wrote: >> >> Can you clarify that? Which global proposal and what was the conflict? > > ?As the ARIN Board has already adopted ARIN-2009-3, we need to make > ?sure that 2009-3 (if/when made global) will not conflict. ?We can do > ?that by including in pp 131 that no legacy space shall be designated > ?for return to IANA (if that is the intent of the policy proposal). > > ?This avoids having 2009-3 somehow become active and we having a conflict > ?in adopted policy in NRPM, and having to establish precedence of various > ?sections, etc. > > > FYI, > /John > > John Curran > President and CEO > ARIN > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > This is a shot in left field, but considering that much of the legacy space is /24 would there be any interest in requiring that legacy space be collected but not reissued until it can be fully or sufficiently aggregated? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From charles at office.tcsn.net Thu Feb 17 15:07:02 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Thu, 17 Feb 2011 12:07:02 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D5AFAA6.10300@arin.net> References: <4D5AFAA6.10300@arin.net> Message-ID: <4D5D7FE6.1030305@office.tcsn.net> Opposed. The stated issue is moot in v6 and not of significant magnitude in v4 to justify any effort or change. On 2/15/11 2:13 PM, ARIN wrote: > The proposal originator submitted revised text. > > "Changes from Previous Version: > Version 2 of this proposal removed section 13.2 so that it could be > considered separately, in a new policy proposal submission. As a > result, the remaining sections were renumbered to use an abstract system > of "13.x" and "13.y", with the intent that actual sub-section numbers > would be assigned later in the policy development process." > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-133: Volunteer Services on Behalf of Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 2 > > Date: 15 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. No Volunteer Services > > Except in the specific circumstances described by this policy, ARIN will > not provide any services for any organization and/or address block. > This includes without limitation all directory services, reverse > mapping services, and future services that may be provided to the community. > > 13.x.1. Requested Services > > In the event that an organization explicitly requests registry services > from ARIN for one or more specified address blocks, ARIN may provide the > requested services, subsequent to execution of a service contract, for > those address blocks. This includes without limitation all directory > services, reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN under a valid > RSA, as well as specific address blocks that are included under a > Legacy RSA with the legitimate validated address holder, are deemed to > have services requested for them. > > An organization requesting registry services for one or more specified > address blocks, that also holds additional address blocks not specified > in their request, is not obligated to receive registry services for > those additional address blocks and those blocks are not deemed to have > services requested for them. > > 13.x.2. Directory Placeholders > > For any address blocks, for which there are not fully executed ARIN > service contracts, ARIN will create generic placeholder entries in the > ARIN Whois directory. These placeholder entries will not specify > organizational details, but will indicate that the entry represents a > non-member resource. > > When applicable, each non-member resource placeholder will include a > reference and/or RWhois referral to the authoritative directory service > for that block, or the directory service operated by the IANA, or by > another organization in the event that IANA has delegated their > directory service responsibility to that organization. This does not > apply to placeholders that represent an unassigned and unallocated > address block delegated to ARIN by the IANA. > > 13.y. Permitted Updates to Directory Services for Unaffiliated Address > Blocks > > Any organization that legitimately holds an address block, as defined by > section 13.2 of this policy, may request the removal or modification of > existing directory placeholders representing that address block. > > Valid requests for modification of placeholder entries are limited to > references and/or RWhois referrals to authoritative directory services, > such as directory services operated by or on behalf of the IANA, another > address registry, or the address holder. In the event that such a > request is received, ARIN may choose to either remove the placeholder > entry or update it per the request. > > > Rationale: > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy would require positive affirmation from any legacy address > holder that wishes to receive registry services, moving to an "opt-in" > approach. In the event that a legacy address holder does not opt-in to > receive registry services, ARIN is limited to providing no more than a > pointer (such as a RWhois referral) to an authoritative directory > service for that holder's legacy address blocks. Pointers to other > providers of directory services for addresses managed by those > other providers continue to be permitted. > > Policy Structure: > > This policy introduces a new section to the NRPM, numbered section 13. > Within this new section, there are two new sub-sections described in > this proposal. > > Sub-section 13.x introduces policy that limits ARIN to providing > services on an opt-in basis. It does make clear in 13.x.1 that services > provided as part of a RSA or LRSA are automatically considered opted-in. > With 13.x.2 it allows ARIN to create placeholders in the Whois database > for blocks managed by other RIRs as well as for blocks managed (but > unassigned/unallocated) by ARIN. > > Sub-section 13.y introduces policy enabling legitimate address holders > to request a very limited update to any Whois placeholders that might > exist for their legacy address block, so that the Whois will refer > queries to the authoritative directory service. It is expected that > ARIN will charge a fee for this update, but not require an ongoing > services agreement. ARIN is given the option of deleting placeholders > instead. > > Changes from Previous Version: > > Version 2 of this proposal removed section 13.2 so that it could be > considered separately, in a new policy proposal submission. As a > result, the remaining sections were renumbered to use an abstract system > of "13.x" and "13.y", with the intent that actual sub-section numbers > would be assigned later in the policy development process. > > Discussion: > > This proposal should not be interpreted as a "punishment" of legacy > address holders or as an attempt to encourage execution of the LRSA. > Rather, the intent of this proposal is to make it clear that ARIN will > only provide services for organizations that wish to receive them. Put > another way: this proposal would prohibit ARIN from forcing any > organization to be listed in the ARIN Whois database without their consent. > > While it is not anticipated by this proposal's text, alternative forms > of "request" are not prohibited by this policy proposal. Indeed, while > the RSA and LRSA are recognized as current forms of request for > services, the ARIN community may choose to develop additional mechanisms. > > Prior to implementing this policy, ARIN should attempt to contact the > address holders that would have services removed as a result of this > policy. Specifically, ARIN should make them aware of the loss of > services, explain the potential impact of losing reverse mapping DNS > services, etc. If an affected address holder cannot be reached by ARIN, > or refuses to communicate with ARIN on this topic, then ARIN may > consider their contact attempt to be satisfied. > > Timetable for implementation: Immediately > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From info at arin.net Thu Feb 17 15:13:26 2011 From: info at arin.net (ARIN) Date: Thu, 17 Feb 2011 15:13:26 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2011 - petition deadline In-Reply-To: <4D4B21C8.9090506@arin.net> References: <4D4B21C8.9090506@arin.net> Message-ID: <4D5D8166.2040500@arin.net> > The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. The minutes from the ARIN Advisory Council's January 28 meeting have been published: https://www.arin.net/about_us/ac/ac2011_0128.html The deadline to begin a petition for proposals 126, 128, 129 and 130 is 25 February 2011. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.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) ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) held a meeting on 28 January 2011 and made > decisions about several draft policies and proposals. > > The AC recommended that the ARIN Board of Trustees adopt the following > draft policy: > > ARIN-2010-14: Standardize IP Reassignment Registration Requirements > > The AC selected the following proposals as draft policies for adoption > discussion online and at the ARIN XXVII Public Policy Meeting in San > Juan, Puerto Rico. Each draft policy will be posted shortly to the PPML. > > ARIN-prop-119. Globally Coordinated Transfer Policy > ARIN-prop-120. Protecting Number Resources > ARIN-prop-121. Better IPv6 Allocation for ISPs > ARIN-prop-123. Reserved Pool for Critical Infrastructure > ARIN-prop-127. Shared Transition Space for IPv4 Address Extension > > The AC added the following proposal to their docket but decided not to > select it as a draft policy at this time: > > ARIN-prop-126. Compliance Requirement > > The AC abandoned the following proposals: > > ARIN-prop-128. Replacement of Section 4.2.4.4 > ARIN-prop-129. IPv4 Addresses for Process Participants > ARIN-prop-130. IPv4 Transition Reservation for Every ASN > > The AC abandoned ARIN-prop-128 due to opposition on the list, and > because there is insufficient time to implement the proposal through the > normal PDP. As a result, the proposal would need to be a Board Emergency > PDP action to have any effect. The AC understands that the use of the > emergency process requires that there be significant risk to ARIN should > the Board allow a situation to continue. This matter does not warrant > the use of the emergency process. > > The AC abandoned ARIN-prop-129 and ARIN-prop-130 because they violate > the community principle of needs-based assignments. > > The PDP states, ?Any member of the community, including a proposal > originator, may initiate a Discussion Petition if they are dissatisfied > with the action taken by the Advisory Council regarding any specific > policy proposal.? Proposals 126, 128, 129 and 130 may be petitioned > (Discussion Petition) to try to change them into draft policies for > adoption discussion on the Public Policy Mailing List and at the April > Public Policy Meeting. 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 Policy Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > > > > > From hannigan at gmail.com Thu Feb 17 15:18:15 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 17 Feb 2011 14:18:15 -0600 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Thu, Feb 17, 2011 at 2:06 PM, Jeffrey Lyon wrote: > > This is a shot in left field, but considering that much of the legacy > space is /24 would there be any interest in requiring that legacy > space be collected but not reissued until it can be fully or > sufficiently aggregated? I don't think so. If I did, I would be happy to include it. My feeling is that there will be demand and a /24 will be more useful immediately than later. We could end up with orphans never able to be rejoined. The proposal to support in that interest, IMHO, would be the globally coordinated transfer proposal. Best, -M< From charles at office.tcsn.net Thu Feb 17 15:20:10 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Thu, 17 Feb 2011 12:20:10 -0800 Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <4D5AFBA2.9070206@arin.net> References: <4D5AFBA2.9070206@arin.net> Message-ID: <4D5D82FA.4080203@office.tcsn.net> Opposed as written. Unsure what issue this is attempting to address and would like to see more discussion on its merits. On 2/15/11 2:18 PM, ARIN wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-134: Identification of Legitimate Address Holders > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 15 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. Recognition of Legitimate Address Holders > > ARIN will use the following criteria in order to determine whether an > organization is the legitimate address holder for a given IP address block. > > 13.x.1. Original Allocation Record > > The original allocation records, such as those documented in RFC 1166 > issued in July of 1990 or the InterNIC database received by ARIN from > Network Solutions in December of 1997, will be used as dispositive > proof, absent any contrary documentation such as those specified in > section 13.x.4 below, in determining whether an organization is the > legitimate address holder. > > 13.x.2 IANA Records of Legitimate Address Holders > > In the event that the IANA has historical records, and/or current > records, showing the assignment or allocation of a given IP address > block to a specific organization, those records will be used as proof, > absent any contrary documentation, in determining whether an > organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.x.4 below, the evidence from the > original allocation record will take precedence. > > 13.x.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for the > management of an address block to another organization, including ARIN > or any other RIR, and that organization has historical and/or current > records showing the assignment or allocation of a given IP address block > to a specific organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.x.4 below, the evidence from the > original allocation record will take precedence. > > 13.x.4. Formal Records Clarifying the Chain of Custody > > In the event that formal records, such as public records or other formal > documents which can be authenticated or verified to include legal, > financial, and other organizational documentation, are provided to ARIN > by an organization seeking recognition of their status as the legitimate > address holder, then ARIN will consider the impact of these records as > potentially updating any evidence that may exist. If these records > clearly document the assignment or allocation of a given IP address > block to a specific organization by direct assignment, and/or > organizational transitions such as mergers, acquisitions, business unit > restructuring, asset transfers, name changes, and so forth, absent > definitive documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. > > > Rationale > > This proposal introduces policy that specifies how ARIN will go about > determining who a "legitimate" address holder is. It is similar to > current procedure with 13.x.2 and 13.x.3, which specify the use of IANA > and RIR records. It expands on the current procedures with 13.x.4, > allowing organizations to provide legal documentation of organizational > changes and/or the transfer of custody of a legacy address block. > > Timetable for implementation: Immediately > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From jeffrey.lyon at blacklotus.net Thu Feb 17 15:20:47 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 17 Feb 2011 15:20:47 -0500 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Thu, Feb 17, 2011 at 3:18 PM, Martin Hannigan wrote: > On Thu, Feb 17, 2011 at 2:06 PM, Jeffrey Lyon > wrote: > >> >> This is a shot in left field, but considering that much of the legacy >> space is /24 would there be any interest in requiring that legacy >> space be collected but not reissued until it can be fully or >> sufficiently aggregated? > > I don't think so. If I did, I would be happy to include it. My feeling > is that there will be demand and a /24 will be more useful immediately > than later. We could end up with orphans never able to be rejoined. > > The proposal to support in that interest, IMHO, would be the globally > coordinated transfer proposal. > > Best, > > -M< > My personal feeling is that the remaining or reclaimed space should be reserved for current ARIN members using IPv4 and in most of those cases a /24 by itself isn't of much use. Does anyone else think that new members should be required to request IPv6 or piggyback off current IPv4 customers? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From owen at delong.com Thu Feb 17 15:23:30 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 17 Feb 2011 12:23:30 -0800 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Feb 17, 2011, at 11:53 AM, John Curran wrote: > On Feb 17, 2011, at 2:40 PM, William Herrin wrote: >> >> Can you clarify that? Which global proposal and what was the conflict? > > As the ARIN Board has already adopted ARIN-2009-3, we need to make > sure that 2009-3 (if/when made global) will not conflict. We can do > that by including in pp 131 that no legacy space shall be designated > for return to IANA (if that is the intent of the policy proposal). > > This avoids having 2009-3 somehow become active and we having a conflict > in adopted policy in NRPM, and having to establish precedence of various > sections, etc. > 2009-3 provided that ARIN could return legacy space according to policies adopted in the ARIN region. Since no such policies exist I don't see a conflict between this policy and 2009-3. I do see a conflict between this policy and traditional operational practice, but, I would say that policy should generally override operational practice if a conflict arises between them. Owen From jeffrey.lyon at blacklotus.net Thu Feb 17 15:32:48 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 17 Feb 2011 15:32:48 -0500 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Thu, Feb 17, 2011 at 3:23 PM, Owen DeLong wrote: > > On Feb 17, 2011, at 11:53 AM, John Curran wrote: > >> On Feb 17, 2011, at 2:40 PM, William Herrin wrote: >>> >>> Can you clarify that? Which global proposal and what was the conflict? >> >> As the ARIN Board has already adopted ARIN-2009-3, we need to make >> sure that 2009-3 (if/when made global) will not conflict. ?We can do >> that by including in pp 131 that no legacy space shall be designated >> for return to IANA (if that is the intent of the policy proposal). >> >> This avoids having 2009-3 somehow become active and we having a conflict >> in adopted policy in NRPM, and having to establish precedence of various >> sections, etc. >> > 2009-3 provided that ARIN could return legacy space according to policies > adopted in the ARIN region. Since no such policies exist I don't see a > conflict between this policy and 2009-3. I do see a conflict between this > policy and traditional operational practice, but, I would say that policy > should generally override operational practice if a conflict arises between > them. > > 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. > An additional comment; I feel that ARIN should act as a steward to networks within its region, not globally. To this goal, returning anything to IANA would not make sense. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bill at herrin.us Thu Feb 17 15:36:57 2011 From: bill at herrin.us (William Herrin) Date: Thu, 17 Feb 2011 15:36:57 -0500 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Thu, Feb 17, 2011 at 3:23 PM, Owen DeLong wrote: > On Feb 17, 2011, at 11:53 AM, John Curran wrote: >> On Feb 17, 2011, at 2:40 PM, William Herrin wrote: >>> >>> Can you clarify that? Which global proposal and what was the conflict? >> >> As the ARIN Board has already adopted ARIN-2009-3, we need to make >> sure that 2009-3 (if/when made global) will not conflict. ?We can do >> that by including in pp 131 that no legacy space shall be designated >> for return to IANA (if that is the intent of the policy proposal). >> >> This avoids having 2009-3 somehow become active and we having a conflict >> in adopted policy in NRPM, and having to establish precedence of various >> sections, etc. >> > 2009-3 provided that ARIN could return legacy space according to policies > adopted in the ARIN region. Since no such policies exist I don't see a > conflict between this policy and 2009-3. I do see a conflict between this > policy and traditional operational practice, but, I would say that policy > should generally override operational practice if a conflict arises between > them. I'm mystified as well. 2009-3 said that ARIN was not authorized to return space to IANA under 2009-3 absent further ARIN-local policy specifying the criteria under which they would be authorized. That couldn't have been clearer. Prop 131 is such an ARIN-local policy, and it specifically excludes returning recovered legacy addresses. Where's the conflict? 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 Thu Feb 17 15:53:57 2011 From: jcurran at arin.net (John Curran) Date: Thu, 17 Feb 2011 20:53:57 +0000 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: References: <4D5D4773.6020706@arin.net> Message-ID: On Feb 17, 2011, at 3:23 PM, Owen DeLong wrote: > On Feb 17, 2011, at 11:53 AM, John Curran wrote: >> >> As the ARIN Board has already adopted ARIN-2009-3, we need to make >> sure that 2009-3 (if/when made global) will not conflict. We can do >> that by including in pp 131 that no legacy space shall be designated >> for return to IANA (if that is the intent of the policy proposal). >> >> This avoids having 2009-3 somehow become active and we having a conflict >> in adopted policy in NRPM, and having to establish precedence of various >> sections, etc. >> > 2009-3 provided that ARIN could return legacy space according to policies > adopted in the ARIN region. Since no such policies exist I don't see a > conflict between this policy and 2009-3. I do see a conflict between this > policy and traditional operational practice, but, I would say that policy > should generally override operational practice if a conflict arises between > them. Owen - It's not just "policies", it's "policies and strategies" in 2009-3: "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA" To the extent that the intent of policy proposal 131 is to specifically prevent returning space to IANA, it should state that very clearly, since it is preempting existing adopted policy language. Otherwise we end up with language in the PPML which specifically allows space to be returned to IANA (according to policies and strategies) and language elsewhere which states that space will be made available for registration and distribution in the ARIN region. /John From charles at office.tcsn.net Thu Feb 17 16:34:34 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Thu, 17 Feb 2011 13:34:34 -0800 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: <4D5C1EB1.1020007@arin.net> References: <4D5C1EB1.1020007@arin.net> Message-ID: <4D5D946A.30008@office.tcsn.net> Support. On 2/16/11 11:00 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 16 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From springer at inlandnet.com Thu Feb 17 16:41:26 2011 From: springer at inlandnet.com (John Springer) Date: Thu, 17 Feb 2011 13:41:26 -0800 (PST) Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D5AFAA6.10300@arin.net> References: <4D5AFAA6.10300@arin.net> Message-ID: <20110217134044.O39884@mail.inlandnet.com> Opposed. On Tue, 15 Feb 2011, ARIN wrote: > The proposal originator submitted revised text. > > "Changes from Previous Version: > Version 2 of this proposal removed section 13.2 so that it could be > considered separately, in a new policy proposal submission. As a > result, the remaining sections were renumbered to use an abstract system > of "13.x" and "13.y", with the intent that actual sub-section numbers > would be assigned later in the policy development process." > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-133: Volunteer Services on Behalf of Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 2 > > Date: 15 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. No Volunteer Services > > Except in the specific circumstances described by this policy, ARIN will > not provide any services for any organization and/or address block. > This includes without limitation all directory services, reverse > mapping services, and future services that may be provided to the community. > > 13.x.1. Requested Services > > In the event that an organization explicitly requests registry services > from ARIN for one or more specified address blocks, ARIN may provide the > requested services, subsequent to execution of a service contract, for > those address blocks. This includes without limitation all directory > services, reverse mapping services, and future services that may be > provided to the community. > > All address blocks that are assigned or allocated by ARIN under a valid > RSA, as well as specific address blocks that are included under a > Legacy RSA with the legitimate validated address holder, are deemed to > have services requested for them. > > An organization requesting registry services for one or more specified > address blocks, that also holds additional address blocks not specified > in their request, is not obligated to receive registry services for > those additional address blocks and those blocks are not deemed to have > services requested for them. > > 13.x.2. Directory Placeholders > > For any address blocks, for which there are not fully executed ARIN > service contracts, ARIN will create generic placeholder entries in the > ARIN Whois directory. These placeholder entries will not specify > organizational details, but will indicate that the entry represents a > non-member resource. > > When applicable, each non-member resource placeholder will include a > reference and/or RWhois referral to the authoritative directory service > for that block, or the directory service operated by the IANA, or by > another organization in the event that IANA has delegated their > directory service responsibility to that organization. This does not > apply to placeholders that represent an unassigned and unallocated > address block delegated to ARIN by the IANA. > > 13.y. Permitted Updates to Directory Services for Unaffiliated Address > Blocks > > Any organization that legitimately holds an address block, as defined by > section 13.2 of this policy, may request the removal or modification of > existing directory placeholders representing that address block. > > Valid requests for modification of placeholder entries are limited to > references and/or RWhois referrals to authoritative directory services, > such as directory services operated by or on behalf of the IANA, another > address registry, or the address holder. In the event that such a > request is received, ARIN may choose to either remove the placeholder > entry or update it per the request. > > > Rationale: > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy would require positive affirmation from any legacy address > holder that wishes to receive registry services, moving to an "opt-in" > approach. In the event that a legacy address holder does not opt-in to > receive registry services, ARIN is limited to providing no more than a > pointer (such as a RWhois referral) to an authoritative directory > service for that holder's legacy address blocks. Pointers to other > providers of directory services for addresses managed by those > other providers continue to be permitted. > > Policy Structure: > > This policy introduces a new section to the NRPM, numbered section 13. > Within this new section, there are two new sub-sections described in > this proposal. > > Sub-section 13.x introduces policy that limits ARIN to providing > services on an opt-in basis. It does make clear in 13.x.1 that services > provided as part of a RSA or LRSA are automatically considered opted-in. > With 13.x.2 it allows ARIN to create placeholders in the Whois database > for blocks managed by other RIRs as well as for blocks managed (but > unassigned/unallocated) by ARIN. > > Sub-section 13.y introduces policy enabling legitimate address holders > to request a very limited update to any Whois placeholders that might > exist for their legacy address block, so that the Whois will refer > queries to the authoritative directory service. It is expected that > ARIN will charge a fee for this update, but not require an ongoing > services agreement. ARIN is given the option of deleting placeholders > instead. > > Changes from Previous Version: > > Version 2 of this proposal removed section 13.2 so that it could be > considered separately, in a new policy proposal submission. As a > result, the remaining sections were renumbered to use an abstract system > of "13.x" and "13.y", with the intent that actual sub-section numbers > would be assigned later in the policy development process. > > Discussion: > > This proposal should not be interpreted as a "punishment" of legacy > address holders or as an attempt to encourage execution of the LRSA. > Rather, the intent of this proposal is to make it clear that ARIN will > only provide services for organizations that wish to receive them. Put > another way: this proposal would prohibit ARIN from forcing any > organization to be listed in the ARIN Whois database without their consent. > > While it is not anticipated by this proposal's text, alternative forms > of "request" are not prohibited by this policy proposal. Indeed, while > the RSA and LRSA are recognized as current forms of request for > services, the ARIN community may choose to develop additional mechanisms. > > Prior to implementing this policy, ARIN should attempt to contact the > address holders that would have services removed as a result of this > policy. Specifically, ARIN should make them aware of the loss of > services, explain the potential impact of losing reverse mapping DNS > services, etc. If an affected address holder cannot be reached by ARIN, > or refuses to communicate with ARIN on this topic, then ARIN may > consider their contact attempt to be satisfied. > > Timetable for implementation: Immediately > > > > > > > _______________________________________________ > 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 springer at inlandnet.com Thu Feb 17 16:55:52 2011 From: springer at inlandnet.com (John Springer) Date: Thu, 17 Feb 2011 13:55:52 -0800 (PST) Subject: [arin-ppml] ARIN-prop-134: Identification of Legitimate Address Holders In-Reply-To: <4D5AFBA2.9070206@arin.net> References: <4D5AFBA2.9070206@arin.net> Message-ID: <20110217135504.C39884@mail.inlandnet.com> Opposed. On Tue, 15 Feb 2011, ARIN wrote: > ARIN received the following policy proposal and is posting it to the > Public Policy Mailing List (PPML) in accordance with the Policy > Development Process. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-134: Identification of Legitimate Address Holders > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 15 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. Recognition of Legitimate Address Holders > > ARIN will use the following criteria in order to determine whether an > organization is the legitimate address holder for a given IP address block. > > 13.x.1. Original Allocation Record > > The original allocation records, such as those documented in RFC 1166 > issued in July of 1990 or the InterNIC database received by ARIN from > Network Solutions in December of 1997, will be used as dispositive > proof, absent any contrary documentation such as those specified in > section 13.x.4 below, in determining whether an organization is the > legitimate address holder. > > 13.x.2 IANA Records of Legitimate Address Holders > > In the event that the IANA has historical records, and/or current > records, showing the assignment or allocation of a given IP address > block to a specific organization, those records will be used as proof, > absent any contrary documentation, in determining whether an > organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.x.4 below, the evidence from the > original allocation record will take precedence. > > 13.x.3. Records Maintained on Behalf of the IANA > > In the event that the IANA has delegated responsibility for the > management of an address block to another organization, including ARIN > or any other RIR, and that organization has historical and/or current > records showing the assignment or allocation of a given IP address block > to a specific organization, those records will be used as evidence in > determining whether an organization is the legitimate address holder. > > Further, in the event that this evidence conflicts with any evidence > from the original allocation records, or any contrary documentation such > as those specified in section 13.x.4 below, the evidence from the > original allocation record will take precedence. > > 13.x.4. Formal Records Clarifying the Chain of Custody > > In the event that formal records, such as public records or other formal > documents which can be authenticated or verified to include legal, > financial, and other organizational documentation, are provided to ARIN > by an organization seeking recognition of their status as the legitimate > address holder, then ARIN will consider the impact of these records as > potentially updating any evidence that may exist. If these records > clearly document the assignment or allocation of a given IP address > block to a specific organization by direct assignment, and/or > organizational transitions such as mergers, acquisitions, business unit > restructuring, asset transfers, name changes, and so forth, absent > definitive documentation to the contrary, then these records will > determine whether an organization is the legitimate address holder. > > > Rationale > > This proposal introduces policy that specifies how ARIN will go about > determining who a "legitimate" address holder is. It is similar to > current procedure with 13.x.2 and 13.x.3, which specify the use of IANA > and RIR records. It expands on the current procedures with 13.x.4, > allowing organizations to provide legal documentation of organizational > changes and/or the transfer of custody of a legacy address block. > > Timetable for implementation: Immediately > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From charles at office.tcsn.net Thu Feb 17 17:02:04 2011 From: charles at office.tcsn.net (Charles O'Hern) Date: Thu, 17 Feb 2011 14:02:04 -0800 Subject: [arin-ppml] [Fwd: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3] revised ver. 4 In-Reply-To: <4D5D4773.6020706@arin.net> References: <4D5D4773.6020706@arin.net> Message-ID: <4D5D9ADC.4080705@office.tcsn.net> Wait... I just supported version 3. Can't support this one as written though. The addition of the first sentence seems a good idea. (isn't there an earlier section of NRPM recognizing ICANN Global Policy already?) Why add the word 'permanently'? It reads as a conflicting statement. Simply dropping that word would fix the issue IMO. On 2/17/11 8:06 AM, ARIN wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 4.0 > > Date: 17 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section X.X Legacy Addresses > > X.X. Returned Legacy Addresses > > In the absence of an ICANN ratified Global Policy indicating otherwise, > legacy IPv4 addresses returned to or recovered by ARIN will be > specifically designated and permanently made available for registration > and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status of > returned legacy addresses. IPv4 address resources should not sit idle > due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > -------- Original Message -------- > Subject: ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 > Date: Wed, 16 Feb 2011 14:00:01 -0500 > From: ARIN > To: arin-ppml at arin.net > > > > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 16 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- Charles O'Hern Network Operations TCSN - The Computer Shop Netlink 1306 Pine St. Paso Robles CA 93446 1-(805) 227-7000 1-(800) 974-DISK http://www.tcsn.net abuse at tcsn.net From z0ink at yahoo.com Thu Feb 17 16:59:53 2011 From: z0ink at yahoo.com (lucas karisny) Date: Thu, 17 Feb 2011 13:59:53 -0800 (PST) Subject: [arin-ppml] Fw: Message-ID: <801366.42446.qm@web111115.mail.gq1.yahoo.com> ----- Forwarded Message ---- From: lucas karisny To: Vembu Subramanian ; Dave Summitt ; F/OSS Overseas ; F/OSS United States ; Moonlight DISTRICT ; Editor ; SK#NKW#RKS ; LEGAL ; LEGAL COPY ; CW3 Michael J. Danberry ; TAX ATTORNEY ; San Jose Sent: Thu, February 17, 2011 1:58:25 PM Subject: ALL - Proof of concept. Confirmed. All NONDISCLOSURE and GENERAL ASSIGNMENT OF INVENTIONS AND RIGHTS returned. Also inclueded: http://www.linkedin.com/pub/richard-celeste/5/23/177 http://antrat.net/ http://en.wikipedia.org/wiki/NebuAd http://www.isoc.org/ http://www.ietf.org/ A & A Distributors Joyce Ellington Branch Library - IRS AUDIT From bill at herrin.us Thu Feb 17 17:06:46 2011 From: bill at herrin.us (William Herrin) Date: Thu, 17 Feb 2011 17:06:46 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D5AFAA6.10300@arin.net> References: <4D5AFAA6.10300@arin.net> Message-ID: On Tue, Feb 15, 2011 at 5:13 PM, ARIN wrote: > ARIN-prop-133: Volunteer Services on Behalf of Unaffiliated Address Blocks Opposed. -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Thu Feb 17 17:29:02 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 17 Feb 2011 14:29:02 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks In-Reply-To: <0f1f01cbcebf$c22c9c50$4685d4f0$@net> References: <1110216141453.31932B-100000@Ives.egh.com> <4D5CC4C3.7050202@ipinc.net> <0f1f01cbcebf$c22c9c50$4685d4f0$@net> Message-ID: <4D5DA12E.8000105@ipinc.net> On 2/17/2011 8:28 AM, Warren Johnson wrote: > >> >> Ever hear of ex post facto? It's unconstutional in the US. >> > > If the ARIN community says tomorrow that all legacy holdings must be > returned that is not violating ex post facto. If they started saying > that the use of those assignments for the last 15 years was illegal 15 > years ago then yes, that WOULD be ex post facto. > > > > > ===================== > Agreed, but that doesn't prevent the ensuing litigation. > ===================== > > >>> >>> And in fact, we HAVE done this. We have done it by setting up a >>> system to make legacy IPv4 obsolete. >>> >> >> We don't go around seizing buggy whips. Making it obsolete does >> not deprive holders of the right to use it as they see fit. >> > > This greatly stretches the definition of "use" IMHO. > > If the rest of the world is no longer using IPv4 then any IPv4 holdings > that you have become impossible to use, unless your goal is to run an > antique computer museum or something like that which is not connected to > the rest of the world. > > > ===================== > It seems to me that your posts have this tone implying that v4 demand will > dwindle significantly in the next year or two. Maybe I'm wrong but it seems > like there's > 4 billion addresses currently out there (who knows how many being used) and > a multi-million monthly demand (that will soon be shut off). Really? Some > legacy block's IPs are going to be worthless that fast? > ===================== > I think you will be surprised. I have posted before that I believe that once the major networks - like the mobile phone networks - switch over to IPv6 (and they will HAVE to do so - their addressing consumption is so great that there is no other answer) that huge chunks of IPv4 that they are currently using will be thrown onto the transfer market. When a network like Verizon Mobile and ATT Mobile and so on decides to switch to IPv6 they can switch their entire network over very fast. Think of how many times the average person drops their cell phone down the crapper or otherwise destroys it and replaces it. Those networks probably can cycle all existing phones out of service within 5 years if they really wanted to. And once they dump their old IPv4 it floods the transfer market, killing speculation. Speculators who thought they would make money in the transfer market get discouraged and abandon it. And once IPv4 is PERCEIVED as old hat, it will die quickly. Do not underestimate the power of obsolete technology perception, or suffer your Betamax father's fate you will! > > How long does patent law allow an inventor in the US to continue to > profit from his invention? How long would it be reasonable to allow the > legacy IP holders to profit from being first in the boat? Do you > seriously think that legacy addresses would be allowed to be handed down > from father to son forever? When your dead of old age then would the > argument that your son "spent a lot of money helping with the formation > of the Internet and in exchange for doing that he gets a free IP > assignment" have any moral validity? Because, that is the primary moral > validation for allowing legacy holders to not help underwrite the costs > of address assignment maintaining. > > ===================== > I think patents are a hundred years? Is that right? I'm not sure where you > get the idea that people who managed to "be there when it was free" and then > profit for centuries from that doesn't happen. That can happen with property and IP addresses are not property. Profiting from being first > in the boat, as you say, is common. Anyone who's family managed to grab up > land on uninhabited areas of Manhattan island are not stripped of that land > just because it's not fair to people now. > Of course they are. All they have to do is stop paying their property taxes and that's the end of it. You cannot own land almost anywhere unless you have income to maintain your ownership over it. > I think legacy groups would be more than happy to pay fees each year. The > point of contention is no doubt the fact that they hold a large swath of > valuable property IP addresses aren't property. and right now they have no contractual limitations on its > use and would like to keep it that way. Actually yes they do - if they want MORE of it, they have to abide by utilization requirements that count their existing addressing. Ted Provide an LSRA that providers for > a payment structure, and that's about it, and you'd probably get people > signing it. > ===================== From marquis at roble.com Thu Feb 17 19:06:56 2011 From: marquis at roble.com (Roger Marquis) Date: Thu, 17 Feb 2011 16:06:56 -0800 (PST) Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: References: Message-ID: <20110218001245.2741D213651@smtp2.arin.net> Support. On 2/16/11 arin-ppml wrote: > The proposal originator submitted revised text. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-131: Section 5.0 Legacy Addresses > > Proposal Originator: Martin Hannigan > > Proposal Version: 3.0 > > Date: 16 February 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Section 5.0 Legacy Addresses > > 5.1 Returned Legacy Addresses > > Legacy IPv4 addresses returned to or recovered by ARIN will be made > available for registration and distribution in the ARIN region. > > Rationale: > > Adopting this proposal will result in the clarification of the status > of returned legacy addresses. IPv4 address resources should not sit > idle due to lack of policy clarity. > > Timetable for implementation: Immediately > > > > > _______________________________________________ > 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 hannigan at gmail.com Thu Feb 17 19:26:51 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 17 Feb 2011 18:26:51 -0600 Subject: [arin-ppml] ARIN-prop-131: Section 5.0 Legacy Addresses - revised ver. 3 In-Reply-To: <20110218001245.2741D213651@smtp2.arin.net> References: <20110218001245.2741D213651@smtp2.arin.net> Message-ID: There seems to be quite a bit of support on this proposal. Is the context because people want returned or recovered legacy addresses used here or is it because you want to encourage the multiple global policy authors to work together and find a way for ARIN to return addresses to the global pool? Best, Marty On 2/17/11, Roger Marquis wrote: > Support. > > On 2/16/11 arin-ppml wrote: >> The proposal originator submitted revised text. >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-131: Section 5.0 Legacy Addresses >> >> Proposal Originator: Martin Hannigan >> >> Proposal Version: 3.0 >> >> Date: 16 February 2011 >> >> Proposal type: New >> >> Policy term: Permanent >> >> Policy statement: >> >> Section 5.0 Legacy Addresses >> >> 5.1 Returned Legacy Addresses >> >> Legacy IPv4 addresses returned to or recovered by ARIN will be made >> available for registration and distribution in the ARIN region. >> >> Rationale: >> >> Adopting this proposal will result in the clarification of the status >> of returned legacy addresses. IPv4 address resources should not sit >> idle due to lack of policy clarity. >> >> Timetable for implementation: Immediately >> >> >> >> >> _______________________________________________ >> 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 cgrundemann at gmail.com Thu Feb 17 20:54:30 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 17 Feb 2011 18:54:30 -0700 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> Message-ID: On Thu, Feb 10, 2011 at 14:17, Benson Schliesser wrote: > If you have more experience (not including rumors) that suggests otherwise, I'd very much like to hear about it. ?I'm open to the possibility that NAT444 breaks stuff - that feels right in my gut - but I haven't found any valid evidence of this. In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 Cheers, ~Chris > > Regardless, I think we can agree that IPv6 is the way to avoid NAT-related growing pains. ?We've known this for a long time. > > Cheers, > -Benson > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From gbonser at seven.com Fri Feb 18 12:51:53 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 09:51:53 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D5D7FE6.1030305@office.tcsn.net> References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> > Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf > of Unaffiliated Address Blocks - revised > > Opposed. The stated issue is moot in v6 and not of significant > magnitude in v4 to justify any effort or change. I tend to concur with that. I don't see what train is bearing down on us if we don't pass 133. In other words, what problem do we have right now that this is trying to solve (ignoring v4 runout which isn't so much a train hurtling at us as it is a slow lava flow that has been making its way toward us for decades). Many of these proposals are sort of like people living in Kalapana Gardens suddenly realizing there is a lava flow 20 feet from their house and demanding "somebody do something" so they can continue to live there another 10 years. Personally, I am going to look at all proposals in the light of "how does this make IPv6 better" and not really going waste a lot of time with proposals designed to focus on v4 unless they have to do with v6 migration. This proposal doesn't seem to have any impact on v6 that makes the internet "better" so I oppose. From jeffrey.lyon at blacklotus.net Fri Feb 18 12:54:13 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 18 Feb 2011 12:54:13 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> Message-ID: On Fri, Feb 18, 2011 at 12:51 PM, George Bonser wrote: > >> Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on > Behalf >> of Unaffiliated Address Blocks - revised >> >> Opposed. ?The stated issue is moot in v6 and not of significant >> magnitude in v4 to justify any effort or change. > > > I tend to concur with that. ?I don't see what train is bearing down on > us if we don't pass 133. ?In other words, what problem do we have right > now that this is trying to solve (ignoring v4 runout which isn't so much > a train hurtling at us as it is a slow lava flow that has been making > its way toward us for decades). > > Many of these proposals are sort of like people living in Kalapana > Gardens suddenly realizing there is a lava flow 20 feet from their house > and demanding "somebody do something" so they can continue to live there > another 10 years. > > Personally, I am going to look at all proposals in the light of "how > does this make IPv6 better" and not really going waste a lot of time > with proposals designed to focus on v4 unless they have to do with v6 > migration. > > This proposal doesn't seem to have any impact on v6 that makes the > internet "better" so I oppose. > > > _______________________________________________ > 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. > Keep in mind that many of us still live on that volcano. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From gbonser at seven.com Fri Feb 18 13:01:13 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 10:01:13 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: References: <4D5AFAA6.10300@arin.net><4D5D7FE6.1030305@office.tcsn.net><5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C24@RWC-EX1.corp.seven.com> > > Keep in mind that many of us still live on that volcano. I understand that and am willing to do whatever I can in order to help you move off of it. Just not sure how much effort is worthwhile spent allowing you to live there longer. Sometimes doing nothing at all is a viable option. George From markk at arin.net Fri Feb 18 13:09:35 2011 From: markk at arin.net (Mark Kosters) Date: Fri, 18 Feb 2011 18:09:35 +0000 Subject: [arin-ppml] Fraud or not? In-Reply-To: <876B0377-1A7B-473D-8C4A-7EA28F1CC63F@delong.com> Message-ID: On 2/16/11 4:05 PM, "Owen DeLong" wrote: >Output, sure. However, the web-based one is much stricter and less >intelligent about parsing queries and THAT is the primary problem I'm >having. > >Instead of realizing that the old "AS10912" query means the same >thing to the user as the new arcane syntax "a 10912" (which the >old version did just fine), the new version neither fails nor works >consistently (or at least the behavior appears very inconsistent >until you begin to understand an additional arcane set of rules). Owen Legacy whois service has had a very interesting search properties. It depends on clients if you have a hit or miss depending on the format of another field or how "smart" the whois client tries to be. The directory service works consistently if do the "A " => matches on As number. The directory service works consistently doing "AS" if "AS" is the handle. Both will come back with hits. Here is an example for querying an AS number registered as a range (701-705). Whois -h whois.arin.net "AS701" works (matches the handle) Whois ?h whois.arin.net "a 701" works ? matches the as number Whois ?h whois.arin.net "AS702" fails (no handle). Whois ?h whois.arin.net "a 702" works ? matches on the as number. ARIN was very careful to replicate most of the functionality in the legacy whois service ? including some of the oddities. Differences were documented and placed on the website at https://www.arin.net/resources/whoisrws/whois_diff.html. If you prefer to move away from that, you are welcome to use the RESTful interface. In this case, the answer would be (using xmllint to create a nice output): xmllint --format http://whois.arin.net/rest/asn/ . For example, finding the AS 694 would be: xmllint --format http://whois.arin.net/rest/asn/693 Feel free to ask additional questions to arin-tech-discuss at arin.net. Regards, Mark Kosters ARIN CTO > >The actual result is: > > 1. Some command line clients do the translation for you. > (good for them, but, not universal) > > 2. If you query ASnnnnn, then, whether you get a good > result back or not depends on whether or not ASnnnnn > is the handle for the resource. If I were to create > an AS Number record, for example, named AS105, > but, which was actually AS693, then, I would get > the following odd mixture: > > Query Result > AS105 Record for AS693 > AS693 Nothing > a 105 Record for AS105 > a 693 Record for AS693 > > (Assuming that my client doesn't alter my queries > unexpectedly). > >I shouldn't have to become an expert in whois arcana to survive >navigating whois for simple everyday queries. > >Owen > >On Feb 16, 2011, at 10:10 AM, Ted Mittelstaedt wrote: > >> So do I - but, I will say that once they finally get their web-based one >> to work, it should not be too difficult to write a command line Perl >> script that talks to their web server and outputs like the older >>command line tool did. >> >> Ted >> >> On 2/15/2011 11:41 PM, Owen DeLong wrote: >>> I really wish ARIN would make the command line whois work as well as >>> it used to instead of focusing all their energy on the (much less >>>convenient >>> much higher overhead from the user perspective) web-based one. >>> >>> Owen >>> >>> On Feb 15, 2011, at 9:03 PM, Scott Leibrand wrote: >>> >>>> On Tue, Feb 15, 2011 at 8:48 PM, Ronald F. Guilmette >>>> > wrote: >>>> >>>> >>>> www.robtex.com says that AS10912 belongs >>>> to Internap. >>>> >>>> whois.arin.net says that there ain't no >>>> such AS. >>>> >>>> So, should I file a formal report charging Internap with fradulent >>>>use >>>> of resources that are not actually assigned to them? Or is it more >>>> likely that ARIN has simply (and entirely) misplaced the WHOIS >>>>record >>>> for AS10912? >>>> >>>> >>>> It looks like it's only the traditional whois tool that is failing. >>>> The web tool at arin.net reports it as part of >>>> INTERNAP-BLK, which covers ASNs 10910 - 10913. >>>> >>>> http://whois.arin.net/rest/asn/AS10910/pft >>>> >>>> I suspect your message will be enough to get ARIN to fix the whois >>>> port 43 service shortly. :-) >>>> >>>> -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. > >_______________________________________________ >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 Feb 18 13:13:20 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 10:13:20 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> Message-ID: <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> >> > > Keep in mind that many of us still live on that volcano. Sure... It's time to move. We cannot change the direction of the lava flow. It will destroy your house. If you don't move, the results are your responsibility. Owen From jeffrey.lyon at blacklotus.net Fri Feb 18 13:58:19 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 18 Feb 2011 13:58:19 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> Message-ID: On Fri, Feb 18, 2011 at 1:13 PM, Owen DeLong wrote: >>> >> >> Keep in mind that many of us still live on that volcano. > > Sure... It's time to move. We cannot change the direction of the lava flow. > It will destroy your house. > > If you don't move, the results are your responsibility. > > Owen > > We'd be happy to, as soon as we gain universal vendor support. As i've mentioned in NANOG, we're not going to flame specific vendors but more often than not there are serious issues with native IPv6 adoption (at least at this point). -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From Keith at jcc.com Fri Feb 18 14:08:21 2011 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 18 Feb 2011 14:08:21 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> Message-ID: <4ab52a59df65f8d56210957a0332e8ab4d5ec2e5@jcc.com> Jeffrey, >From your point of view then, the question is does Prop-133 do anything to support IPv4 longer in order to give enough vendors enough time to support IPv6? >From my point of view, Prop-133 would only serve to confuse the IPv4 space and would not extend IPv4 viability at all. Keith -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon Sent: Friday, February 18, 2011 1:58 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised On Fri, Feb 18, 2011 at 1:13 PM, Owen DeLong wrote: >>> >> >> Keep in mind that many of us still live on that volcano. > > Sure... It's time to move. We cannot change the direction of the lava flow. > It will destroy your house. > > If you don't move, the results are your responsibility. > > Owen > > We'd be happy to, as soon as we gain universal vendor support. As i've mentioned in NANOG, we're not going to flame specific vendors but more often than not there are serious issues with native IPv6 adoption (at least at this point). -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions _______________________________________________ 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 Feb 18 14:06:55 2011 From: bill at herrin.us (William Herrin) Date: Fri, 18 Feb 2011 14:06:55 -0500 Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 Message-ID: Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 1. Policy Proposal Name: Clarification of draft policy 2009-3 2. Proposal Originator 1. name: William Herrin 2. email: bill at herrin.us 3. telephone: 703-534-2652 4. organization: self 3. Proposal Version: 1.0 4. Date: 2/18/2011 5. Proposal type: new 6. Policy term: permanent 7. Policy statement: ARIN participants intended and ARIN shall understand the sentence "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA." in draft policy 2009-3 to mean two distinct and independent actions: may recover and may (separately) designate for return to IANA. ARIN shall complete the second action (designate) only as directed to do so by other ARIN-local policy. 8. Rationale: The author's recollection of the debate surrounding proposal 2009-3 was that it diverged from the outregion proposal that was it's genesis because ARIN public policy participants wished to enable a global policy for returning address space to IANA but wished to retain local control of what addresses were returned. Staff comments on proposal 131 suggest that they interpret the language differently than the community which consented to it -- that upon ratification, ARNI is required to return recovered legacy addresses to IANA. This proposal attempts to clarify the intent behind the community's language for draft policy 2009-3. 9. Timetable for implementation: immediate END OF TEMPLATE -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From info at arin.net Fri Feb 18 15:38:15 2011 From: info at arin.net (ARIN) Date: Fri, 18 Feb 2011 15:38:15 -0500 Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) Message-ID: <4D5ED8B7.6080405@arin.net> ARIN-prop-135: Clarification of draft policy 2009-3 ARIN acknowledges receipt of the policy proposal that can be found below. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-135: Clarification of draft policy 2009-3 > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of William Herrin > Sent: Friday, February 18, 2011 2:07 PM > To: policy at arin.net; arin-ppml at arin.net > Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 > > Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > > 1. Policy Proposal Name: Clarification of draft policy 2009-3 > 2. Proposal Originator > 1. name: William Herrin > 2. email: bill at herrin.us > 3. telephone: 703-534-2652 > 4. organization: self > 3. Proposal Version: 1.0 > 4. Date: 2/18/2011 > 5. Proposal type: new > 6. Policy term: permanent > 7. Policy statement: > > ARIN participants intended and ARIN shall understand the sentence > "Each RIR through their respective chosen policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA." in draft policy > 2009-3 to mean two distinct and independent actions: may recover and > may (separately) designate for return to IANA. ARIN shall complete the > second action (designate) only as directed to do so by other > ARIN-local policy. > > 8. Rationale: > > The author's recollection of the debate surrounding proposal 2009-3 > was that it diverged from the outregion proposal that was it's genesis > because ARIN public policy participants wished to enable a global > policy for returning address space to IANA but wished to retain local > control of what addresses were returned. Staff comments on proposal > 131 suggest that they interpret the language differently than the > community which consented to it -- that upon ratification, ARNI is > required to return recovered legacy addresses to IANA. This proposal > attempts to clarify the intent behind the community's language for > draft policy 2009-3. > > 9. Timetable for implementation: immediate > > END OF TEMPLATE > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jeffrey.lyon at blacklotus.net Fri Feb 18 16:07:17 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 18 Feb 2011 16:07:17 -0500 Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <4D5ED8B7.6080405@arin.net> References: <4D5ED8B7.6080405@arin.net> Message-ID: I'm opposed to any policy that even comes close to allowing ARIN to give resources back to IANA. Jeff On Feb 18, 2011 3:39 PM, "ARIN" wrote: > ARIN-prop-135: Clarification of draft policy 2009-3 > > ARIN acknowledges receipt of the policy proposal that can be found below. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-135: Clarification of draft policy 2009-3 > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > >> Behalf Of William Herrin > >> Sent: Friday, February 18, 2011 2:07 PM > >> To: policy at arin.net; arin-ppml at arin.net > >> Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 > >> > >> Template: ARIN-POLICY-PROPOSAL-TEMPLATE-2.0 > >> > >> 1. Policy Proposal Name: Clarification of draft policy 2009-3 > >> 2. Proposal Originator > >> 1. name: William Herrin > >> 2. email: bill at herrin.us > >> 3. telephone: 703-534-2652 > >> 4. organization: self > >> 3. Proposal Version: 1.0 > >> 4. Date: 2/18/2011 > >> 5. Proposal type: new > >> 6. Policy term: permanent > >> 7. Policy statement: > >> > >> ARIN participants intended and ARIN shall understand the sentence > >> "Each RIR through their respective chosen policies and strategies may > >> recover IPv4 address space which is under their administration and > >> designate any such space for return to the IANA." in draft policy > >> 2009-3 to mean two distinct and independent actions: may recover and > >> may (separately) designate for return to IANA. ARIN shall complete the > >> second action (designate) only as directed to do so by other > >> ARIN-local policy. > >> > >> 8. Rationale: > >> > >> The author's recollection of the debate surrounding proposal 2009-3 > >> was that it diverged from the outregion proposal that was it's genesis > >> because ARIN public policy participants wished to enable a global > >> policy for returning address space to IANA but wished to retain local > >> control of what addresses were returned. Staff comments on proposal > >> 131 suggest that they interpret the language differently than the > >> community which consented to it -- that upon ratification, ARNI is > >> required to return recovered legacy addresses to IANA. This proposal > >> attempts to clarify the intent behind the community's language for > >> draft policy 2009-3. > >> > >> 9. Timetable for implementation: immediate > >> > >> END OF TEMPLATE > >> > >> -- > >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us > >> 3005 Crane Dr. ...................... Web: > >> Falls Church, VA 22042-3004 > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > > > _______________________________________________ > 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 Fri Feb 18 16:50:11 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 13:50:11 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> Message-ID: <29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> On Feb 18, 2011, at 10:58 AM, Jeffrey Lyon wrote: > On Fri, Feb 18, 2011 at 1:13 PM, Owen DeLong wrote: >>>> >>> >>> Keep in mind that many of us still live on that volcano. >> >> Sure... It's time to move. We cannot change the direction of the lava flow. >> It will destroy your house. >> >> If you don't move, the results are your responsibility. >> >> Owen >> >> > > We'd be happy to, as soon as we gain universal vendor support. As i've > mentioned in NANOG, we're not going to flame specific vendors but more > often than not there are serious issues with native IPv6 adoption (at > least at this point). > Those vendors are about to burn down your house. It's time they felt the heat. If you aren't getting a good story from them that includes a near-term delivery date, I say "flame on". However, we have gone 100% dual stack in our environment. Were there issues at first? Yes, but, we started several years ago. Did we change some of our vendor choices along the way? You bet! If they don't support IPv6, we don't buy it and haven't for years. Turns out this is a very good way to motivate vendors. As such, I have no sympathy if you aren't moving off the mountain. I'm happy to help you relocate if you choose to, but, if you refuse to evacuate, I'm not going to have a lot of sympathy. The lava continues to advance and there is no stopping it. Owen From bensons at queuefull.net Fri Feb 18 17:07:48 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 18 Feb 2011 16:07:48 -0600 Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <4D5ED8B7.6080405@arin.net> Message-ID: <0EBD437F-39E0-4662-A7AA-01717C808B2B@queuefull.net> On Feb 18, 2011, at 3:07 PM, Jeffrey Lyon wrote: > I'm opposed to any policy that even comes close to allowing ARIN to give resources back to IANA > I don't believe IANA wants the resources, per se. But I am in favor of a policy that transfers excess resources to other regions if there is a demand. Of the various ways this could be done, I primarily support a market approach (including specified transfer). But it appears that prop 135 (and 131) deals with addresses that are reclaimed/returned to the ARIN pool, and it's not clear how ARIN would participate as a marketplace participant. With some exceptions, the availability of low-cost addresses from ARIN would preempt the emergence of a widespread marketplace approach. But once the ARIN pool is empty, a marketplace approach may emerge and address prices will rise/fall with demand/supply. Thus, the question becomes, what should ARIN do with additional supply that becomes available after the ARIN pool is exhausted and a marketplace approach has emerged? I.e. What happens when the ARIN supply that is currently dwindling begins to grow again? I do not think ARIN should dump these back into the market at low prices, because of the potential market volatility and because of "fairness" questions that might emerge (i.e. who gets to buy these cheap addresses?). Instead, ARIN should offer them at market prices, provide them charitably (to non-profits in ARIN region), or transfer them to regions for use in developing economies. Of course, by the time the ARIN pool begins to grow again, it might be because we've transitioned to IPv6 and nobody wants these IPv4 things. We only need to worry about the possibility of an event in the interim. Cheers, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Feb 18 17:14:38 2011 From: bill at herrin.us (William Herrin) Date: Fri, 18 Feb 2011 17:14:38 -0500 Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <4D5ED8B7.6080405@arin.net> Message-ID: On Fri, Feb 18, 2011 at 4:07 PM, Jeffrey Lyon wrote: > I'm opposed to any policy that even comes close to allowing ARIN to give > resources back to IANA. Hi Jeffrey, Draft policy 2009-3 has already passed. Do you support clarifying that ARIN is not to return addresses to IANA under 2009-3 unless the community specifically directs them to (which you would presumably not do)? On Fri, Feb 18, 2011 at 5:07 PM, Benson Schliesser wrote: > I do not think ARIN should dump these back into the market at low prices, > because of the potential market volatility and because of "fairness" > questions that might emerge (i.e. who gets to buy these cheap addresses?). Hi Benson, That's actually already been hashed out in the waiting list policy (draft policy 2010-1, adopted last month). Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeffrey.lyon at blacklotus.net Fri Feb 18 17:22:57 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 18 Feb 2011 17:22:57 -0500 Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <4D5ED8B7.6080405@arin.net> Message-ID: On Fri, Feb 18, 2011 at 5:14 PM, William Herrin wrote: > On Fri, Feb 18, 2011 at 4:07 PM, Jeffrey Lyon > wrote: >> I'm opposed to any policy that even comes close to allowing ARIN to give >> resources back to IANA. > > Hi Jeffrey, > > Draft policy 2009-3 has already passed. Do you support clarifying that > ARIN is not to return addresses to IANA under 2009-3 unless the > community specifically directs them to (which you would presumably not > do)? > > > On Fri, Feb 18, 2011 at 5:07 PM, Benson Schliesser > wrote: >> I do not think ARIN should dump these back into the market at low prices, >> because of the potential market volatility and because of "fairness" >> questions that might emerge (i.e. who gets to buy these cheap addresses?). > > Hi Benson, > > That's actually already been hashed out in the waiting list policy > (draft policy 2010-1, adopted last month). > > Regards, > Bill Herrin > > > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > Yes, I would support that. Regarding the comment about transferring if there is a demand, there is excess demand in all regions so by that logic there is never a reason to transfer resources out of ARIN. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jeffrey.lyon at blacklotus.net Fri Feb 18 17:28:03 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 18 Feb 2011 17:28:03 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> <29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> Message-ID: On Fri, Feb 18, 2011 at 4:50 PM, Owen DeLong wrote: > > On Feb 18, 2011, at 10:58 AM, Jeffrey Lyon wrote: > >> On Fri, Feb 18, 2011 at 1:13 PM, Owen DeLong wrote: >>>>> >>>> >>>> Keep in mind that many of us still live on that volcano. >>> >>> Sure... It's time to move. We cannot change the direction of the lava flow. >>> It will destroy your house. >>> >>> If you don't move, the results are your responsibility. >>> >>> Owen >>> >>> >> >> We'd be happy to, as soon as we gain universal vendor support. As i've >> mentioned in NANOG, we're not going to flame specific vendors but more >> often than not there are serious issues with native IPv6 adoption (at >> least at this point). >> > Those vendors are about to burn down your house. It's time they felt > the heat. If you aren't getting a good story from them that includes a > near-term delivery date, I say "flame on". > > However, we have gone 100% dual stack in our environment. Were > there issues at first? Yes, but, we started several years ago. Did we > change some of our vendor choices along the way? You bet! If they > don't support IPv6, we don't buy it and haven't for years. Turns out > this is a very good way to motivate vendors. > > As such, I have no sympathy if you aren't moving off the mountain. > I'm happy to help you relocate if you choose to, but, if you refuse > to evacuate, I'm not going to have a lot of sympathy. > > The lava continues to advance and there is no stopping it. > > Owen > > We'll still get it done before most companies, so i'm not too worried. One small concern I have is that i'm going to have to pay ARIN fees on IPv4 and IPv6 at a time when most of my customers won't be requesting the IPv6 resources. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From kkargel at polartel.com Fri Feb 18 17:29:52 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 18 Feb 2011 16:29:52 -0600 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) Message-ID: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> ________________________________________ From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon Sent: Friday, February 18, 2011 3:07 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) >I'm opposed to any policy that even comes close to allowing ARIN to give >resources back to IANA. >Jeff IMHO a policy that *allows* return of blocks to IANA upon request by IANA would be ok. I am not in favor of policy that *requires* return of blocks whether IANA wants them or not. Having said that consider that a "MAY" in absence of "MAY NOT" is a no-op. The policy may be specious. If there is no law prohibiting me from wearing red socks then while it sounds good a permit to wear red socks is rather meaningless and wasteful. Kevin From gbonser at seven.com Fri Feb 18 17:32:33 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 14:32:33 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> <29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C3C@RWC-EX1.corp.seven.com> > Sent: Friday, February 18, 2011 1:50 PM > To: Jeffrey Lyon > Cc: George Bonser; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf > of Unaffiliated Address Blocks - revised > > > On Feb 18, 2011, at 10:58 AM, Jeffrey Lyon wrote: > > > On Fri, Feb 18, 2011 at 1:13 PM, Owen DeLong wrote: > >>>> > >>> > >>> Keep in mind that many of us still live on that volcano. > >> > >> Sure... It's time to move. We cannot change the direction of the > lava flow. > >> It will destroy your house. > >> > >> If you don't move, the results are your responsibility. > >> > >> Owen > >> > >> > > > > We'd be happy to, as soon as we gain universal vendor support. As > i've > > mentioned in NANOG, we're not going to flame specific vendors but > more > > often than not there are serious issues with native IPv6 adoption (at > > least at this point). > > > Those vendors are about to burn down your house. It's time they felt > the heat. If you aren't getting a good story from them that includes a > near-term delivery date, I say "flame on". > Chicken, meet egg. Nobody is going to move until there is "universal vendor support" and no vendor is going to support it until people move. But is there any gear being sold today that doesn't support v6? I know two vendors that can't do dynamic routing protocols on v6 yet but their gear is more aimed at the layer2 switching market anyway and do support v6 switching, addressing, and static routes which probably covers the vast majority of their use cases. All of the stuff I have in the layer3 area of the network supports v6 and that is four different vendors. At this stage finding vendors who don't support v6 is more difficult than finding the ones that do. The one problem area is xDSL CPE. Everything else is pretty much there in one form or another and simply takes more usage in order to shake the cobwebs out of it. From gbonser at seven.com Fri Feb 18 17:35:33 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 14:35:33 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: References: <4D5AFAA6.10300@arin.net><4D5D7FE6.1030305@office.tcsn.net><5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com><58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com><29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C3D@RWC-EX1.corp.seven.com> > We'll still get it done before most companies, so i'm not too worried. > One small concern I have is that i'm going to have to pay ARIN fees on > IPv4 and IPv6 at a time when most of my customers won't be requesting > the IPv6 resources. I would think you should be assigning those resources now, even before they ask for them. So when they do ask, you have it already worked out. Maybe even proactively sending them a "your IPv6 address space is ... X:X:X::/48" note could go a long way toward them getting that ball rolling. From gbonser at seven.com Fri Feb 18 17:38:27 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 18 Feb 2011 14:38:27 -0800 Subject: [arin-ppml] Proposal: Clarification of draft policy 2009-3(ARIN-prop-135) In-Reply-To: References: <4D5ED8B7.6080405@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C3E@RWC-EX1.corp.seven.com> I would hope that at some point *all* v4 space will be given back to IANA. From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jeffrey Lyon Sent: Friday, February 18, 2011 1:07 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Proposal: Clarification of draft policy 2009-3(ARIN-prop-135) I'm opposed to any policy that even comes close to allowing ARIN to give resources back to IANA. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Feb 18 17:42:27 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 14:42:27 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> <29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> Message-ID: <9E91CBA8-174A-4D4C-8E21-96E0D919BF8C@delong.com> On Feb 18, 2011, at 2:28 PM, Jeffrey Lyon wrote: > On Fri, Feb 18, 2011 at 4:50 PM, Owen DeLong wrote: >> >> On Feb 18, 2011, at 10:58 AM, Jeffrey Lyon wrote: >> >>> On Fri, Feb 18, 2011 at 1:13 PM, Owen DeLong wrote: >>>>>> >>>>> >>>>> Keep in mind that many of us still live on that volcano. >>>> >>>> Sure... It's time to move. We cannot change the direction of the lava flow. >>>> It will destroy your house. >>>> >>>> If you don't move, the results are your responsibility. >>>> >>>> Owen >>>> >>>> >>> >>> We'd be happy to, as soon as we gain universal vendor support. As i've >>> mentioned in NANOG, we're not going to flame specific vendors but more >>> often than not there are serious issues with native IPv6 adoption (at >>> least at this point). >>> >> Those vendors are about to burn down your house. It's time they felt >> the heat. If you aren't getting a good story from them that includes a >> near-term delivery date, I say "flame on". >> >> However, we have gone 100% dual stack in our environment. Were >> there issues at first? Yes, but, we started several years ago. Did we >> change some of our vendor choices along the way? You bet! If they >> don't support IPv6, we don't buy it and haven't for years. Turns out >> this is a very good way to motivate vendors. >> >> As such, I have no sympathy if you aren't moving off the mountain. >> I'm happy to help you relocate if you choose to, but, if you refuse >> to evacuate, I'm not going to have a lot of sympathy. >> >> The lava continues to advance and there is no stopping it. >> >> Owen >> >> > > We'll still get it done before most companies, so i'm not too worried. > One small concern I have is that i'm going to have to pay ARIN fees on > IPv4 and IPv6 at a time when most of my customers won't be requesting > the IPv6 resources. > You are misinformed. You pay the max(IPv4,IPv6), not sum(IPv4,IPv6) to ARIN. In mist cases, this means you pay (IPv4). In a few cases, it means you pay about $1,000 more total per year at the rate of (IPv6). Owen From bill at herrin.us Fri Feb 18 17:46:20 2011 From: bill at herrin.us (William Herrin) Date: Fri, 18 Feb 2011 17:46:20 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Fri, Feb 18, 2011 at 5:29 PM, Kevin Kargel wrote: > IMHO a policy that *allows* return of blocks to IANA upon > request by IANA would be ok. ?I am not in favor of policy > that *requires* return of blocks whether IANA wants them or not. Hi Kevin, That matches my understanding of the already-board-approved draft policy 2009-3. However, when evaluating proposal 131, ARIN staff offered a radically different interpretation of 2009-3. Their interpretation is that an ARIN policy which prevents the return of legacy addresses to IANA (prop 131 version 3) conflicts with the mandatory returns to IANA in draft policy 2009-3. Hence proposal 135 which, in my opinion, does not alter 2009-3 in any way. It merely clarifies the intended interpretation of 2009-3's language. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeffrey.lyon at blacklotus.net Fri Feb 18 17:46:52 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 18 Feb 2011 17:46:52 -0500 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <9E91CBA8-174A-4D4C-8E21-96E0D919BF8C@delong.com> References: <4D5AFAA6.10300@arin.net> <4D5D7FE6.1030305@office.tcsn.net> <5A6D953473350C4B9995546AFE9939EE0BC13C23@RWC-EX1.corp.seven.com> <58D7428A-F75C-4C21-BF6B-C754C28067AB@delong.com> <29F822A5-5BEB-4975-A877-DEB8DEF34AB3@delong.com> <9E91CBA8-174A-4D4C-8E21-96E0D919BF8C@delong.com> Message-ID: On Fri, Feb 18, 2011 at 5:42 PM, Owen DeLong wrote: > > On Feb 18, 2011, at 2:28 PM, Jeffrey Lyon wrote: > >> On Fri, Feb 18, 2011 at 4:50 PM, Owen DeLong wrote: >>> >>> On Feb 18, 2011, at 10:58 AM, Jeffrey Lyon wrote: >>> >>>> On Fri, Feb 18, 2011 at 1:13 PM, Owen DeLong wrote: >>>>>>> >>>>>> >>>>>> Keep in mind that many of us still live on that volcano. >>>>> >>>>> Sure... It's time to move. We cannot change the direction of the lava flow. >>>>> It will destroy your house. >>>>> >>>>> If you don't move, the results are your responsibility. >>>>> >>>>> Owen >>>>> >>>>> >>>> >>>> We'd be happy to, as soon as we gain universal vendor support. As i've >>>> mentioned in NANOG, we're not going to flame specific vendors but more >>>> often than not there are serious issues with native IPv6 adoption (at >>>> least at this point). >>>> >>> Those vendors are about to burn down your house. It's time they felt >>> the heat. If you aren't getting a good story from them that includes a >>> near-term delivery date, I say "flame on". >>> >>> However, we have gone 100% dual stack in our environment. Were >>> there issues at first? Yes, but, we started several years ago. Did we >>> change some of our vendor choices along the way? You bet! If they >>> don't support IPv6, we don't buy it and haven't for years. Turns out >>> this is a very good way to motivate vendors. >>> >>> As such, I have no sympathy if you aren't moving off the mountain. >>> I'm happy to help you relocate if you choose to, but, if you refuse >>> to evacuate, I'm not going to have a lot of sympathy. >>> >>> The lava continues to advance and there is no stopping it. >>> >>> Owen >>> >>> >> >> We'll still get it done before most companies, so i'm not too worried. >> One small concern I have is that i'm going to have to pay ARIN fees on >> IPv4 and IPv6 at a time when most of my customers won't be requesting >> the IPv6 resources. >> > You are misinformed. You pay the max(IPv4,IPv6), not sum(IPv4,IPv6) > to ARIN. In mist cases, this means you pay (IPv4). In a few cases, it > means you pay about $1,000 more total per year at the rate of (IPv6). > > > Owen > > Owen, You're right, if thats the case than I am indeed misinformed. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From packetgrrl at gmail.com Fri Feb 18 17:59:57 2011 From: packetgrrl at gmail.com (cja@daydream.com) Date: Fri, 18 Feb 2011 15:59:57 -0700 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: Bill, I think what the ARIN staff was saying was not that prop 131 conflicts with the "mandatory returns" in 2009-3 because there are no mandatory returns in 2009-3 but 131 makes it so there are no blocks to be voluntarily returned in 2009-3. 2009-3 specifically states, "Each RIR through their respective chosen policies and strategies may recover IPv4 address space which is under their administration and designate any such space for return to the IANA. Each RIR shall at quarterly intervals return any such designated address space to the IANA in aggregated blocks of /24 or larger, for inclusion in the recovered IPv4 pool." This is not mandatory return. 131 specifically says that ARIN will make recovered legacy space available for distribution within the ARIN region. If it passes then it conflicts with 2009-3 because there would be no blocks that could be designated for return to IANA. 131 also conflicts with current ARIN operational practice. That practice has been that ARIN does give back any /8s that it recovers or that are returned. This is not mandated this is just operational practice as far as I know. I hope this helps. Thanks! ----Cathy On Fri, Feb 18, 2011 at 3:46 PM, William Herrin wrote: > On Fri, Feb 18, 2011 at 5:29 PM, Kevin Kargel > wrote: > > IMHO a policy that *allows* return of blocks to IANA upon > > request by IANA would be ok. I am not in favor of policy > > that *requires* return of blocks whether IANA wants them or not. > > Hi Kevin, > > That matches my understanding of the already-board-approved draft > policy 2009-3. However, when evaluating proposal 131, ARIN staff > offered a radically different interpretation of 2009-3. Their > interpretation is that an ARIN policy which prevents the return of > legacy addresses to IANA (prop 131 version 3) conflicts with the > mandatory returns to IANA in draft policy 2009-3. > > Hence proposal 135 which, in my opinion, does not alter 2009-3 in any > way. It merely clarifies the intended interpretation of 2009-3's > language. > > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Feb 18 18:36:54 2011 From: bill at herrin.us (William Herrin) Date: Fri, 18 Feb 2011 18:36:54 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Fri, Feb 18, 2011 at 5:59 PM, cja at daydream.com wrote: > I think what the ARIN staff was saying was ?not that prop 131 conflicts with > the "mandatory returns" in 2009-3 because there are no mandatory returns in > 2009-3 but 131 makes it so there are no blocks to be voluntarily returned in > 2009-3. > 2009-3 specifically states, "Each RIR through their respective chosen > policies and strategies may > recover IPv4 address space which is under their administration and > designate any such space for return to the IANA. Each RIR shall at > quarterly intervals return any such designated address space to the IANA > in aggregated blocks of /24 or larger, for inclusion in the recovered > IPv4 pool." > > This is not mandatory return. ?131 specifically says that ARIN will make > recovered legacy space available for distribution within the ARIN region. > ?If it passes then it conflicts with 2009-3 because there would be no blocks > that could be designated for return to IANA. Hi Cathy, Conflict is an action word. It means "you may not do X because." "We designate the null set for return to IANA" does not conflict with 2009-3. It renders 2009-3 functionally inert but it does not "conflict." If there is any doubt about that, then it is appropriate for us to clear up that doubt. "We designate the null set for return to IANA" does not conflict with ARIN practice either. It _changes_ ARIN practice. Generally speaking, that's what policy is for. If this is a case of poorly chosen words, I'll be pleased to withdraw prop 135 once staff updates it's guidance to reflect that while 131 designates a null set for return under 2009-3, it does not _conflict_ with any active or tentative obligations under 2009-3 or any other policy. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From john.sweeting at gmail.com Fri Feb 18 19:38:13 2011 From: john.sweeting at gmail.com (John Sweeting) Date: Fri, 18 Feb 2011 19:38:13 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Fri, Feb 18, 2011 at 5:46 PM, William Herrin wrote: > On Fri, Feb 18, 2011 at 5:29 PM, Kevin Kargel > wrote: > >> IMHO a policy that *allows* return of blocks to IANA upon > >> request by IANA would be ok. I am not in favor of policy > >> that *requires* return of blocks whether IANA wants them or not. > > >Hi Kevin, > > >That matches my understanding of the already-board-approved draft > >policy 2009-3. However, when evaluating proposal 131, ARIN staff > >offered a radically different interpretation of 2009-3. Their > >interpretation is that an ARIN policy which prevents the return of > >legacy addresses to IANA (prop 131 version 3) conflicts with the > >mandatory returns to IANA in draft policy 2009-3. > > I do not remember ever seeing that stated, would you please reference the email you read this in? It is the timing of PP131 that is wrong, not the intent. In fact in all my conversations with any of ARIN staff I have not heard that stated. I believe your use of the word "mandatory" is not correct. > >Hence proposal 135 which, in my opinion, does not alter 2009-3 in any > >way. It merely clarifies the intended interpretation of 2009-3's > >language. > A proposal that changes nothing is a non op. > >Regards, > >Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hannigan at gmail.com Fri Feb 18 20:05:23 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 18 Feb 2011 19:05:23 -0600 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Fri, Feb 18, 2011 at 6:38 PM, John Sweeting wrote: > > > On Fri, Feb 18, 2011 at 5:46 PM, William Herrin wrote: >> >> On Fri, Feb 18, 2011 at 5:29 PM, Kevin Kargel >> wrote: >> >> IMHO a policy that *allows* return of blocks to IANA upon >> >> request by IANA would be ok. ?I am not in favor of policy >> >> that *requires* return of blocks whether IANA wants them or not. >> >> >Hi Kevin, >> >> >That matches my understanding of the already-board-approved draft >> >policy 2009-3. However, when evaluating proposal 131, ARIN staff >> >offered a radically different interpretation of 2009-3. Their >> >interpretation is that an ARIN policy which prevents the return of >> >legacy addresses to IANA (prop 131 version 3) conflicts with the >> >mandatory returns to IANA in draft policy 2009-3. >> > ?I do not remember ever seeing that stated, would you please reference the > email you read this in? It is the timing of PP131 that is wrong, not the I don't understand. What's wrong with the timing? [ snip ] >> >Hence proposal 135 which, in my opinion, does not alter 2009-3 in any >> >way. It merely clarifies the intended interpretation of 2009-3's >> >language. > > ?A proposal that changes nothing is a non op. Not always, sometimes the obvious needs to be stated. Best, -M< From bill at herrin.us Fri Feb 18 20:26:38 2011 From: bill at herrin.us (William Herrin) Date: Fri, 18 Feb 2011 20:26:38 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Fri, Feb 18, 2011 at 7:38 PM, John Sweeting wrote: >> when evaluating proposal 131, ARIN staff >> >offered a radically different interpretation of 2009-3. Their >> >interpretation is that an ARIN policy which prevents the return of >> >legacy addresses to IANA (prop 131 version 3) conflicts with the >> >mandatory returns to IANA in draft policy 2009-3. > > ?I do not remember ever seeing that stated, would you please reference the > email you read this in? It is the timing of PP131 that is wrong, not the > intent. In fact in all my conversations with any of ARIN staff I have not > heard that stated. I believe your use of the word "mandatory" is not > correct. Hi John, As someone who grew up in and around Washington DC, let me tell you something about the anatomy of political dirty tricks. The essence of a dirty trick is that you pick words and phrases which imply something blatantly false. In fact, any reasonable person without competing knowledge would understand you to be stating the falsehood plainly. Yet if pressed, you can deny ever meaning such a thing. After all, your words -could- have meant the truthful version too. Thus you escape being called a bald faced liar while widely planting the falsehood in voter's minds. What I saw happen to prop 131 yesterday stinks! The proposal's author was led to believe that ARIN had approved a global policy proposal which his proposal would violate. That couldn't be further from the truth! The global proposal in question, 2009-3, was worded the way it was worded because as a community we anticipated doing exactly what prop 131v3 calls for: giving IANA bupkis. Indeed, our purpose in advancing 2009-3 was little more than extending an olive branch towards the other regions: if we changed our minds about "no inter-region redistribution," no one would have to wait for a global policy before we could disgorge our generosity. And we wouldn't block the other regions from redistributing amongst themselves if they wanted to. I don't like the smell of the process that tricked the proposal's author. If 131 is opposed, let it be opposed in open debate. Don't try to kill it by implying the existence of competing obligations where there are none. And if I'm just jaded and I've misinterpreted honest confusion and poorly chosen words, let's bring that out into the light of day and then proceed with 131v3 without the "misunderstanding" about its relationship with 2009-3. 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 Fri Feb 18 20:36:22 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 18 Feb 2011 17:36:22 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: <3172306647367331538@unknownmsgid> As I understand it, if we do nothing policy-wise, and a legacy /8 comes free, ARIN staff's current procedure is to give it back to IANA. (The other RIRs would need to pass 2009-3 for IANA to give it out, though.) Scott On Feb 18, 2011, at 5:27 PM, William Herrin wrote: > On Fri, Feb 18, 2011 at 7:38 PM, John Sweeting wrote: >>> when evaluating proposal 131, ARIN staff >>>> offered a radically different interpretation of 2009-3. Their >>>> interpretation is that an ARIN policy which prevents the return of >>>> legacy addresses to IANA (prop 131 version 3) conflicts with the >>>> mandatory returns to IANA in draft policy 2009-3. >> >> I do not remember ever seeing that stated, would you please reference the >> email you read this in? It is the timing of PP131 that is wrong, not the >> intent. In fact in all my conversations with any of ARIN staff I have not >> heard that stated. I believe your use of the word "mandatory" is not >> correct. > > Hi John, > > As someone who grew up in and around Washington DC, let me tell you > something about the anatomy of political dirty tricks. The essence of > a dirty trick is that you pick words and phrases which imply something > blatantly false. In fact, any reasonable person without competing > knowledge would understand you to be stating the falsehood plainly. > Yet if pressed, you can deny ever meaning such a thing. After all, > your words -could- have meant the truthful version too. Thus you > escape being called a bald faced liar while widely planting the > falsehood in voter's minds. > > What I saw happen to prop 131 yesterday stinks! The proposal's author > was led to believe that ARIN had approved a global policy proposal > which his proposal would violate. > > That couldn't be further from the truth! > > The global proposal in question, 2009-3, was worded the way it was > worded because as a community we anticipated doing exactly what prop > 131v3 calls for: giving IANA bupkis. Indeed, our purpose in advancing > 2009-3 was little more than extending an olive branch towards the > other regions: if we changed our minds about "no inter-region > redistribution," no one would have to wait for a global policy before > we could disgorge our generosity. And we wouldn't block the other > regions from redistributing amongst themselves if they wanted to. > > I don't like the smell of the process that tricked the proposal's > author. If 131 is opposed, let it be opposed in open debate. Don't try > to kill it by implying the existence of competing obligations where > there are none. > > And if I'm just jaded and I've misinterpreted honest confusion and > poorly chosen words, let's bring that out into the light of day and > then proceed with 131v3 without the "misunderstanding" about its > relationship with 2009-3. > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From hannigan at gmail.com Fri Feb 18 22:14:47 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Fri, 18 Feb 2011 21:14:47 -0600 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Fri, Feb 18, 2011 at 7:26 PM, William Herrin wrote: [ snip ] > I don't like the smell of the process that tricked the proposal's > author. If 131 is opposed, let it be opposed in open debate. Don't try > to kill it by implying the existence of competing obligations where > there are none. > > And if I'm just jaded and I've misinterpreted honest confusion and > poorly chosen words, let's bring that out into the light of day and > then proceed with 131v3 without the "misunderstanding" about its > relationship with 2009-3. Folks, Let's dial this back a bit. The AC meeting results will be coming out shortly and you will see, formally, what transpired. I'm sure that if there are still gaps at that point, we can discuss how to fill them and how to move forward in the way that the community would like to. Best, Marty From owen at delong.com Sat Feb 19 00:55:07 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Feb 2011 21:55:07 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <3172306647367331538@unknownmsgid> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <3172306647367331538@unknownmsgid> Message-ID: <1E07019E-4D05-4162-8D94-FB623C836894@delong.com> I don't believe that is the case... If it's a /8 or larger, then IANA will give it out to whichever RIR asks for it first. 2009-3 is necessary if IANA is to parcel out chunks smaller than /8 to RIRs. There are no dirty tricks here, Bill. I think there are multiple layers of misunderstanding and different interpretations of: Current policy Staff understanding of current policy Staff implementation of current policy Staff understanding and impending implementation of 2009-3 We didn't oppose 131, we moved it forward for discussion at the Puerto Rico meeting. The AC did make some changes to the policy text in that process and we will probably continue to improve it between now and the March 7 text freeze. Doing so is within the purview of the AC and is in our job description. It's what we are expected to do. Owen Speaking for myself about my impression of the AC's actions and not acting as a spokesman for the AC. On Feb 18, 2011, at 5:36 PM, Scott Leibrand wrote: > As I understand it, if we do nothing policy-wise, and a legacy /8 > comes free, ARIN staff's current procedure is to give it back to IANA. > (The other RIRs would need to pass 2009-3 for IANA to give it out, > though.) > > Scott > > On Feb 18, 2011, at 5:27 PM, William Herrin wrote: > >> On Fri, Feb 18, 2011 at 7:38 PM, John Sweeting wrote: >>>> when evaluating proposal 131, ARIN staff >>>>> offered a radically different interpretation of 2009-3. Their >>>>> interpretation is that an ARIN policy which prevents the return of >>>>> legacy addresses to IANA (prop 131 version 3) conflicts with the >>>>> mandatory returns to IANA in draft policy 2009-3. >>> >>> I do not remember ever seeing that stated, would you please reference the >>> email you read this in? It is the timing of PP131 that is wrong, not the >>> intent. In fact in all my conversations with any of ARIN staff I have not >>> heard that stated. I believe your use of the word "mandatory" is not >>> correct. >> >> Hi John, >> >> As someone who grew up in and around Washington DC, let me tell you >> something about the anatomy of political dirty tricks. The essence of >> a dirty trick is that you pick words and phrases which imply something >> blatantly false. In fact, any reasonable person without competing >> knowledge would understand you to be stating the falsehood plainly. >> Yet if pressed, you can deny ever meaning such a thing. After all, >> your words -could- have meant the truthful version too. Thus you >> escape being called a bald faced liar while widely planting the >> falsehood in voter's minds. >> >> What I saw happen to prop 131 yesterday stinks! The proposal's author >> was led to believe that ARIN had approved a global policy proposal >> which his proposal would violate. >> >> That couldn't be further from the truth! >> >> The global proposal in question, 2009-3, was worded the way it was >> worded because as a community we anticipated doing exactly what prop >> 131v3 calls for: giving IANA bupkis. Indeed, our purpose in advancing >> 2009-3 was little more than extending an olive branch towards the >> other regions: if we changed our minds about "no inter-region >> redistribution," no one would have to wait for a global policy before >> we could disgorge our generosity. And we wouldn't block the other >> regions from redistributing amongst themselves if they wanted to. >> >> I don't like the smell of the process that tricked the proposal's >> author. If 131 is opposed, let it be opposed in open debate. Don't try >> to kill it by implying the existence of competing obligations where >> there are none. >> >> And if I'm just jaded and I've misinterpreted honest confusion and >> poorly chosen words, let's bring that out into the light of day and >> then proceed with 131v3 without the "misunderstanding" about its >> relationship with 2009-3. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > 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 john.sweeting at twcable.com Sat Feb 19 05:30:55 2011 From: john.sweeting at twcable.com (Sweeting, John) Date: Sat, 19 Feb 2011 05:30:55 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) Message-ID: Speaking for the AC both Marty and Owen have it right. Sorry Bill, no beltway conspiracy here but thank you for your perspective. We truly value the input and view points of the community. It is very apparent that you are interested in helping to see the right things get done. Thanks again. John ----- Reply message ----- From: "Owen DeLong" Date: Sat, Feb 19, 2011 1:00 am Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) To: "Scott Leibrand" Cc: "arin-ppml at arin.net" I don't believe that is the case... If it's a /8 or larger, then IANA will give it out to whichever RIR asks for it first. 2009-3 is necessary if IANA is to parcel out chunks smaller than /8 to RIRs. There are no dirty tricks here, Bill. I think there are multiple layers of misunderstanding and different interpretations of: Current policy Staff understanding of current policy Staff implementation of current policy Staff understanding and impending implementation of 2009-3 We didn't oppose 131, we moved it forward for discussion at the Puerto Rico meeting. The AC did make some changes to the policy text in that process and we will probably continue to improve it between now and the March 7 text freeze. Doing so is within the purview of the AC and is in our job description. It's what we are expected to do. Owen Speaking for myself about my impression of the AC's actions and not acting as a spokesman for the AC. On Feb 18, 2011, at 5:36 PM, Scott Leibrand wrote: > As I understand it, if we do nothing policy-wise, and a legacy /8 > comes free, ARIN staff's current procedure is to give it back to IANA. > (The other RIRs would need to pass 2009-3 for IANA to give it out, > though.) > > Scott > > On Feb 18, 2011, at 5:27 PM, William Herrin wrote: > >> On Fri, Feb 18, 2011 at 7:38 PM, John Sweeting wrote: >>>> when evaluating proposal 131, ARIN staff >>>>> offered a radically different interpretation of 2009-3. Their >>>>> interpretation is that an ARIN policy which prevents the return of >>>>> legacy addresses to IANA (prop 131 version 3) conflicts with the >>>>> mandatory returns to IANA in draft policy 2009-3. >>> >>> I do not remember ever seeing that stated, would you please reference the >>> email you read this in? It is the timing of PP131 that is wrong, not the >>> intent. In fact in all my conversations with any of ARIN staff I have not >>> heard that stated. I believe your use of the word "mandatory" is not >>> correct. >> >> Hi John, >> >> As someone who grew up in and around Washington DC, let me tell you >> something about the anatomy of political dirty tricks. The essence of >> a dirty trick is that you pick words and phrases which imply something >> blatantly false. In fact, any reasonable person without competing >> knowledge would understand you to be stating the falsehood plainly. >> Yet if pressed, you can deny ever meaning such a thing. After all, >> your words -could- have meant the truthful version too. Thus you >> escape being called a bald faced liar while widely planting the >> falsehood in voter's minds. >> >> What I saw happen to prop 131 yesterday stinks! The proposal's author >> was led to believe that ARIN had approved a global policy proposal >> which his proposal would violate. >> >> That couldn't be further from the truth! >> >> The global proposal in question, 2009-3, was worded the way it was >> worded because as a community we anticipated doing exactly what prop >> 131v3 calls for: giving IANA bupkis. Indeed, our purpose in advancing >> 2009-3 was little more than extending an olive branch towards the >> other regions: if we changed our minds about "no inter-region >> redistribution," no one would have to wait for a global policy before >> we could disgorge our generosity. And we wouldn't block the other >> regions from redistributing amongst themselves if they wanted to. >> >> I don't like the smell of the process that tricked the proposal's >> author. If 131 is opposed, let it be opposed in open debate. Don't try >> to kill it by implying the existence of competing obligations where >> there are none. >> >> And if I'm just jaded and I've misinterpreted honest confusion and >> poorly chosen words, let's bring that out into the light of day and >> then proceed with 131v3 without the "misunderstanding" about its >> relationship with 2009-3. >> >> Regards, >> Bill Herrin >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > _______________________________________________ > 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. ________________________________ 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. From jcurran at arin.net Sat Feb 19 11:55:21 2011 From: jcurran at arin.net (John Curran) Date: Sat, 19 Feb 2011 16:55:21 +0000 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Feb 19, 2011, at 9:26 AM, William Herrin wrote: > The global proposal in question, 2009-3, was worded the way it was > worded because as a community we anticipated doing exactly what prop > 131v3 calls for: giving IANA bupkis. ... Bill - That might be your reasoning for why global policy needed to be changed from requiring return to IANA of recovered blocks to optionally designating blocks for return to IANA, but I know that is not a universally held view. I'd point to the staff review and note that the original proposal was identified as fatally flawed not because ARIN would be returning space to the IANA, but when ARIN might have to return space to IANA for redistribution when other regions had departed from the overall community goals in RFC2050. (i.e. sharing things based on common principles and goals can readily be explained to the community in this region, it is much more challenging to do so in the absence of any shared set of goals) > I don't like the smell of the process that tricked the proposal's > author. If 131 is opposed, let it be opposed in open debate. Don't try > to kill it by implying the existence of competing obligations where > there are none. Here's the message that I sent to the AC regarding the interaction of 2009-3 and policy proposal 131 - > Team - > > If the AC intent is that this take effect until "otherwise directed by global > policy" then it would be best to say that in Policy Proposal 131. If the > intent is this policy proposal is intended to permanently pre-empt global > policy (even once passed) then state something to that effect. There is > a fairly large difference between those two positions. >... As always, the goal is simply to have a compendium of understandable policy. > And if I'm just jaded and I've misinterpreted honest confusion and > poorly chosen words, let's bring that out into the light of day and > then proceed with 131v3 without the "misunderstanding" about its > relationship with 2009-3. The misunderstanding will remain under the policy proposal text is made explicit one way or the other. For many, the optionality added to 2009-3 was to address a specific fiduciary requirement, not to signal that space was never to be returned, and it is that difference in view which might be underlying some of the confusion here. Hope this helps, /John John Curran President and CEO ARIN From hannigan at gmail.com Sat Feb 19 13:00:16 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Sat, 19 Feb 2011 12:00:16 -0600 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: Message-ID: I prefer to speak for myself on this. My comment about dialing things back was intended to be considered by all and not as judgment on any participants viewpoint. The process needs to play out to see what will happen and if any of the differing view points on this ring true. Differing opinions are a valuable and welcome input that should, when properly analyzed for root cause, help us to "do better". Best Regards, -M< On Sat, Feb 19, 2011 at 4:30 AM, Sweeting, John wrote: > Speaking for the AC both Marty and Owen have it right. > > Sorry Bill, no beltway conspiracy here but thank you for your perspective. We truly value the input and view points of the community. It is very apparent that you are interested in helping to see the right things get done. Thanks again. > > John > > > > ----- Reply message ----- > From: "Owen DeLong" > Date: Sat, Feb 19, 2011 1:00 am > Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) > To: "Scott Leibrand" > Cc: "arin-ppml at arin.net" > > I don't believe that is the case... > > If it's a /8 or larger, then IANA will give it out to whichever RIR > asks for it first. > > 2009-3 is necessary if IANA is to parcel out chunks smaller than /8 > to RIRs. > > There are no dirty tricks here, Bill. > > I think there are multiple layers of misunderstanding and different > interpretations of: > ? ? ? ?Current policy > ? ? ? ?Staff understanding of current policy > ? ? ? ?Staff implementation of current policy > ? ? ? ?Staff understanding and impending implementation of 2009-3 > > We didn't oppose 131, we moved it forward for discussion at the > Puerto Rico meeting. The AC did make some changes to the > policy text in that process and we will probably continue to > improve it between now and the March 7 text freeze. Doing so > is within the purview of the AC and is in our job description. It's > what we are expected to do. > > Owen > > Speaking for myself about my impression of the AC's actions > and not acting as a spokesman for the AC. > > On Feb 18, 2011, at 5:36 PM, Scott Leibrand wrote: > >> As I understand it, if we do nothing policy-wise, and a legacy /8 >> comes free, ARIN staff's current procedure is to give it back to IANA. >> (The other RIRs would need to pass 2009-3 for IANA to give it out, >> though.) >> >> Scott >> >> On Feb 18, 2011, at 5:27 PM, William Herrin wrote: >> >>> On Fri, Feb 18, 2011 at 7:38 PM, John Sweeting wrote: >>>>> when evaluating proposal 131, ARIN staff >>>>>> offered a radically different interpretation of 2009-3. Their >>>>>> interpretation is that an ARIN policy which prevents the return of >>>>>> legacy addresses to IANA (prop 131 version 3) conflicts with the >>>>>> mandatory returns to IANA in draft policy 2009-3. >>>> >>>> I do not remember ever seeing that stated, would you please reference the >>>> email you read this in? It is the timing of PP131 that is wrong, not the >>>> intent. In fact in all my conversations with any of ARIN staff I have not >>>> heard that stated. I believe your use of the word "mandatory" is not >>>> correct. >>> >>> Hi John, >>> >>> As someone who grew up in and around Washington DC, let me tell you >>> something about the anatomy of political dirty tricks. The essence of >>> a dirty trick is that you pick words and phrases which imply something >>> blatantly false. In fact, any reasonable person without competing >>> knowledge would understand you to be stating the falsehood plainly. >>> Yet if pressed, you can deny ever meaning such a thing. After all, >>> your words -could- have meant the truthful version too. Thus you >>> escape being called a bald faced liar while widely planting the >>> falsehood in voter's minds. >>> >>> What I saw happen to prop 131 yesterday stinks! The proposal's author >>> was led to believe that ARIN had approved a global policy proposal >>> which his proposal would violate. >>> >>> That couldn't be further from the truth! >>> >>> The global proposal in question, 2009-3, was worded the way it was >>> worded because as a community we anticipated doing exactly what prop >>> 131v3 calls for: giving IANA bupkis. Indeed, our purpose in advancing >>> 2009-3 was little more than extending an olive branch towards the >>> other regions: if we changed our minds about "no inter-region >>> redistribution," no one would have to wait for a global policy before >>> we could disgorge our generosity. And we wouldn't block the other >>> regions from redistributing amongst themselves if they wanted to. >>> >>> I don't like the smell of the process that tricked the proposal's >>> author. If 131 is opposed, let it be opposed in open debate. Don't try >>> to kill it by implying the existence of competing obligations where >>> there are none. >>> >>> And if I'm just jaded and I've misinterpreted honest confusion and >>> poorly chosen words, let's bring that out into the light of day and >>> then proceed with 131v3 without the "misunderstanding" about its >>> relationship with 2009-3. >>> >>> Regards, >>> Bill Herrin >>> >>> >>> -- >>> William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us >>> 3005 Crane Dr. ...................... Web: >>> Falls Church, VA 22042-3004 >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> _______________________________________________ >> 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. > > ________________________________ > 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. > _______________________________________________ > 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 Sat Feb 19 20:11:26 2011 From: bill at herrin.us (William Herrin) Date: Sat, 19 Feb 2011 20:11:26 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: On Sat, Feb 19, 2011 at 11:55 AM, John Curran wrote: > On Feb 19, 2011, at 9:26 AM, William Herrin wrote: >> The global proposal in question, 2009-3, was worded the way it was >> worded because as a community we anticipated doing exactly what prop >> 131v3 calls for: giving IANA bupkis. ... > > ?That might be your reasoning for why global policy needed to > ?be changed from requiring return to IANA of recovered blocks to > ?optionally designating blocks for return to IANA, but I know > ?that is not a universally held view. [...] I'd point to the staff > review Hi John, Here's what I found at that URL: "[I]t became clear that one of the reasons 2009-3 is such a difficult policy to get consensus on is that the original policy, as proposed, requires each RIR to return reclaimed space." Became CLEAR. Not my words. This is what the author wrote about draft policy 2009-3 at the time. It goes on: "[U]nder the revised version of 2009-3, recovered space is returned after it is designated for return under local policies and strategies. The original text dictated the terms of what must be returned (everything /24 or larger) as part of the global policy." So I'm still UNCLEAR what conflict arises if local policies and strategies designate -nothing- for return. >> If the AC intent is that this take effect until "otherwise directed by global >> policy" then it would be best to say that in Policy Proposal 131. ?If the >> intent is this policy proposal is intended to permanently pre-empt global >> policy (even once passed) then state something to that effect. ? There is >> a fairly large difference between those two positions. This is what's really confusing me. Global policy, when it takes effect, overrides and replaces contrary local policy. Without exception. The contracts between ARIN, IANA and the other registries are set up that way and when the BoT ratifies a global policy ARIN accepts that its local policy options will be bound by it. I've been repeatedly assured that no pending or active global policy requires ARIN to return addresses to IANA. So no conflict arises from stating in local policy that we won't return addresses to IANA. What's more, we supersede local policy with new global and local policy all the time. It's inherent in the process that any policy can be replaced if we think of something better and build a consensus around it. Why, then, has prop 131 been singled out to do what no other proposal has been asked to do nor in fact can do: specify whether it should override global policy? That makes no sense to me John. None. I dislike the role of conspiracy theorist, but something smells fishy. As if someone is lying or there's a hidden piece to the puzzle. What's the story? Why has prop 131 been singled out for this bizarre requirement that it state whether it intends to preempt global policy? -Bill -- 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 Sat Feb 19 20:18:11 2011 From: jcurran at arin.net (John Curran) Date: Sun, 20 Feb 2011 01:18:11 +0000 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> Message-ID: <37059055-9123-426E-B466-03F1792247EF@arin.net> On Feb 20, 2011, at 9:11 AM, William Herrin wrote: > So I'm still UNCLEAR what conflict arises if local policies and > strategies designate -nothing- for return. Bill - If local policies specifically designate that nothing should be returned under any circumstance, there is no confusion. Given that the language is policies and strategies, and the existing practice is to return space to the IANA, a policy proposal which is not explicit in this area is indeed unclear. /John From bill at herrin.us Sat Feb 19 20:51:22 2011 From: bill at herrin.us (William Herrin) Date: Sat, 19 Feb 2011 20:51:22 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <37059055-9123-426E-B466-03F1792247EF@arin.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> Message-ID: On Sat, Feb 19, 2011 at 8:18 PM, John Curran wrote: > On Feb 20, 2011, at 9:11 AM, William Herrin wrote: >> So I'm still UNCLEAR what conflict arises if local policies and >> strategies designate -nothing- for return. > > ?If local policies specifically designate that nothing should > ?be returned under any circumstance, there is no confusion. > ?Given that the language is policies and strategies, and the > ?existing practice is to return space to the IANA, a policy > ?proposal which is not explicit in this area is indeed unclear. John, Then to clarify the staff guidance, staff would like prop 131 to indicate whether or not it intends to specify what addresses should be returned to IANA under pending global policy 2009-3 (yes) and if so, what addresses those are (none). This has nothing to do with preempting or not preempting global policy, something an ARIN-local policy like 131 can't do anyway. Yes? -Bill -- 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 Sat Feb 19 21:02:19 2011 From: jcurran at arin.net (John Curran) Date: Sun, 20 Feb 2011 02:02:19 +0000 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net>, Message-ID: <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> Correct. Make the intent of the policy clear and unambiguous. I believe the AC is working on that presently. /John On Feb 20, 2011, at 9:52 AM, "William Herrin" wrote: > On Sat, Feb 19, 2011 at 8:18 PM, John Curran wrote: >> On Feb 20, 2011, at 9:11 AM, William Herrin wrote: >>> So I'm still UNCLEAR what conflict arises if local policies and >>> strategies designate -nothing- for return. >> >> If local policies specifically designate that nothing should >> be returned under any circumstance, there is no confusion. >> Given that the language is policies and strategies, and the >> existing practice is to return space to the IANA, a policy >> proposal which is not explicit in this area is indeed unclear. > > John, > > Then to clarify the staff guidance, staff would like prop 131 to > indicate whether or not it intends to specify what addresses should be > returned to IANA under pending global policy 2009-3 (yes) and if so, > what addresses those are (none). This has nothing to do with > preempting or not preempting global policy, something an ARIN-local > policy like 131 can't do anyway. > > Yes? > > -Bill > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From bill at herrin.us Sat Feb 19 21:05:41 2011 From: bill at herrin.us (William Herrin) Date: Sat, 19 Feb 2011 21:05:41 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> Message-ID: On Sat, Feb 19, 2011 at 9:02 PM, John Curran wrote: > On Feb 20, 2011, at 9:52 AM, "William Herrin" wrote: >> Then to clarify the staff guidance, staff would like prop 131 to >> indicate whether or not it intends to specify what addresses should be >> returned to IANA under pending global policy 2009-3 (yes) and if so, >> what addresses those are (none). This has nothing to do with >> preempting or not preempting global policy, something an ARIN-local >> policy like 131 can't do anyway. >> >> Yes? > > Correct. Make the intent of the policy clear and unambiguous. I believe the AC is working on that presently. Excellent. I look forward to reading what they come up with. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From scottleibrand at gmail.com Sat Feb 19 22:11:21 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 19 Feb 2011 19:11:21 -0800 Subject: [arin-ppml] Draft Policy 2011-4: Reserved Pool for Critical Infrastructure In-Reply-To: <4D4B22CB.4090007@arin.net> References: <4D4B22CB.4090007@arin.net> Message-ID: In light of ARIN's recent receipt of the last /8 from IANA, we have updated ARIN-2011-4 to remove the "Upon receipt of the last /8 ..." clause. The updated policy statement now reads: ARIN will place an equivalent of a /16 of IPv4 address space in a reserve for Critical Infrastructure, as defined in section 4.4. If at the end of the policy term there is unused address space remaining in this pool, ARIN staff is authorized to utilize this space in a manner consistent with community expectations. If anyone has any opinions on this draft policy, I would encourage you to share them here on the list, and at the upcoming Public Policy Meeting in San Juan, Puerto Rico in April. -Scott On Thu, Feb 3, 2011 at 1:48 PM, ARIN wrote: > Draft Policy ARIN-2011-4 > Reserved Pool for Critical Infrastructure > > On 28 January 2011 the ARIN Advisory Council (AC) selected "Reserved > Pool for Critical Infrastructure" as a draft policy for adoption > discussion on the PPML and at the Public Policy Meeting in San Juan, > Puerto Rico in April. > > The draft was developed by the AC from policy proposal "ARIN-prop-123. > Reserved Pool for Critical Infrastructure". Per the Policy Development > Process the AC submitted text to ARIN for a staff and legal assessment > prior to its selection as a draft policy. Below the draft policy is the > ARIN staff and legal assessment, followed by the text that was submitted > by the AC. > > Draft Policy ARIN-2011-4 is below and can be found at: > https://www.arin.net/policy/proposals/2011_4.html > > You are encouraged to discuss Draft Policy 2011-4 on the PPML prior to > the April Public Policy Meeting. Both the discussion on the list and > at the meeting will be used by the ARIN Advisory Council to determine > the community consensus for adopting this as policy. > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Draft Policy ARIN-2011-4 > Reserved Pool for Critical Infrastructure > > Version/Date: 23 November 2010 > > Policy term: 36 Months following implementation > > Policy statement: > > Upon receipt of the last /8 that the IANA will allocate to ARIN per the > Global Policy for the Allocation of the Remaining IPv4 Address Space, > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure, as defined in section 4.4. If at > the end of the policy term there is unused address space remaining in > this pool, ARIN staff is authorized to utilize this space in a manner > consistent with community expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > > This proposal should be considered an emergency proposal. IANA > exhaustion is likely to occur prior to the next ARIN meeting. > > Timetable for implementation: Immediate > > > ##### > > > STAFF ASSESSMENT > > Proposal: ?Reserved Pool for Critical Infrastructure? (pp 123) > Policy Version (Date): 23 November 2010 > Date of Assessment: 27 January 2011 > > 1. Proposal Summary (Staff Understanding) > > This policy would set aside a /16 equivalent when the IANA issues its > last /8 to ARIN. These addresses would be reserved for issuing under the > IPv4 micro-allocations for critical infrastructure policy (NRPM 4.4). If > any of the reserved addresses are unused 36 months after implementation, > ARIN may begin using the addresses for other purposes. > > 2. Comments > > A. ARIN Staff Comments > > ? The proposal says, ?reserve for critical infrastructure? but > doesn?t elaborate on what critical infrastructure actually is. NRPM > 4.4. ("Micro-allocation") defines a specific list of uses that qualifies > as critical infrastructure. For coherency, perhaps this policy should > specifically state that ?critical infrastructure? as defined in NRPM > 4.4. That way, there can be no misinterpretation of its meaning. > > B. ARIN General Counsel > > No comments > > 3. Resource Impact > > This policy would have minimal resource impact from an implementation > aspect. It is estimated that implementation would occur within 3 months > after ratification by the ARIN Board of Trustees. > > The following would be needed in order to implement: > ? Updated documentation on the ARIN website > > > 4. Proposal Text > > Policy statement: > > Upon receipt of the last /8 that the IANA will allocate to ARIN per the > Global Policy for the Allocation of the Remaining IPv4 Address Space, > ARIN will place an equivalent of a /16 of IPv4 address space in a > reserve for Critical Infrastructure. If at the end of the policy term > there is unused address space remaining in this pool, ARIN staff is > authorized to utilize this space in a manner consistent with community > expectations. > > Rationale: > > Section 4.10 of the NRPM is insufficient with respect to insuring the > continued operation of critical infrastructure. This proposal, if > adopted, will protect those resources with a reasonable amount of > reserved v4 address space and prevent an overrun of CI needs by NRPM > Section 4.10 or any successor. The intent is to separate CI needs and > make a distinct pool available to insure the continuity of CI > allocations per NRPM Section 4.4 for at least 36 months. > This proposal should be considered an emergency proposal. IANA > exhaustion is likely to occur prior to the next ARIN meeting. > > > _______________________________________________ > 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 frnkblk at iname.com Sun Feb 20 19:11:01 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 20 Feb 2011 18:11:01 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised Message-ID: <011e01cbd15b$d28594f0$7790bed0$@iname.com> Yes -- without naming names, one of the three leading CMTS vendors has no IPv6 support (Q3 at the earliest). In regards to CPE, the D-Link DIR-655 with the latest firmware is pretty IPv6 ready. It sells for $70 at Amazon.com, probably a bit more at your local electronics retailer. See http://www.getipv6.info/index.php/Broadband_CPE for more info (most don't have an SPI firewall). Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of George Bonser Sent: Friday, February 18, 2011 4:33 PM To: Owen DeLong; Jeffrey Lyon Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised But is there any gear being sold today that doesn't support v6? I know two vendors that can't do dynamic routing protocols on v6 yet but their gear is more aimed at the layer2 switching market anyway and do support v6 switching, addressing, and static routes which probably covers the vast majority of their use cases. All of the stuff I have in the layer3 area of the network supports v6 and that is four different vendors. At this stage finding vendors who don't support v6 is more difficult than finding the ones that do. The one problem area is xDSL CPE. Everything else is pretty much there in one form or another and simply takes more usage in order to shake the cobwebs out of it. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From tedm at ipinc.net Sun Feb 20 20:43:44 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sun, 20 Feb 2011 17:43:44 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <011e01cbd15b$d28594f0$7790bed0$@iname.com> References: <011e01cbd15b$d28594f0$7790bed0$@iname.com> Message-ID: <4D61C350.9@ipinc.net> A better choice than the D-link DIR-655 is the D-link DIR-825 The DIR-655 uses the Ubicom CPU/Chipset the DIR-825 uses the Atheros AR7161 chipset Until recently Ubicom did not release programming info so there is NO support for this router beyond that provided from D-link. If the D-link firmware doesn't do it for you or has a bug, you are SOL. The problem with all Ubicom CPU-based stuff is that Ubicom has not supplied docs about their CPU microcode and so until recently no backend existed for GCC that would allow you to compile code for it. This originally didn't matter (to them) but recently they have seen sales drop off as more and more router vendors have gone to Linux, and so they released this thing they call GNUPro which appears to be a proprietary IDE that is a mashup of GNU code and their own proprietary code. Since it's incompatible with the build environments used by both OpenWRT and DDwrt, it's sole purpose appears to be to allow Ubicom to run around claiming that their stuff is now "OpenWRT compliant" when in reality nobody has been willing yet to rewrite all of the build scripts and makefiles and such to actually compile openwrt on their stuff. Now, you may be thinking if your large and putting out an RFP that this doesn't matter because I'm big and this is the vendor's problem, but the fact is that when you send money to vendors for models that use the Ubicom stuff your ultimately retarding the rollout of IPv6, since year later when the vendor has stopped supporting these devices they cannot then be repurposed on the secondary market to fully support IPv6. The DIR-825 has a full 8MB of flash and in addition to the factory firmware, it runs both OpenWRT and DD-WRT. Note that Comcast's default IPv6 firmware for their IPv6 trial is a modified version of OpenWRT that is built for the Linksys WRT160NL which also has 8MB of flash and uses an Atheros chipset (the AR9130) It would be trivial to build their load for the DIR-655 and it might even run unmodified. The factory load on the DIR-615/655/825 series does not support dhcpv6-pd from what I have read, nor does it support ANY firewalling for IPv6. That is the primary difference in functionality from the Comcast build for the 160NL that is on Sourceforge. Note that there is not enough space on the 4MB flash routers (like the DIR-615) to run dhcpv6-pd & ipv6tables (needed for the SPI stuff for IPv6) One last thing too - if you have any of those older "turbo boost 108Mbt" 802.11g cards in older laptops/etc. note that these are all Atheros-based and only run the turbo mode when the base unit is also an Atheros-based radio. Otherwise they switch down to the normal 54Mbt "g" mode. Ted On 2/20/2011 4:11 PM, Frank Bulk wrote: > Yes -- without naming names, one of the three leading CMTS vendors has no > IPv6 support (Q3 at the earliest). > > In regards to CPE, the D-Link DIR-655 with the latest firmware is pretty > IPv6 ready. It sells for $70 at Amazon.com, probably a bit more at your > local electronics retailer. See > http://www.getipv6.info/index.php/Broadband_CPE for more info (most don't > have an SPI firewall). > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of George Bonser > Sent: Friday, February 18, 2011 4:33 PM > To: Owen DeLong; Jeffrey Lyon > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks - revised > > > But is there any gear being sold today that doesn't support v6? I know > two vendors that can't do dynamic routing protocols on v6 yet but their > gear is more aimed at the layer2 switching market anyway and do support > v6 switching, addressing, and static routes which probably covers the > vast majority of their use cases. All of the stuff I have in the layer3 > area of the network supports v6 and that is four different vendors. > > At this stage finding vendors who don't support v6 is more difficult > than finding the ones that do. The one problem area is xDSL CPE. > Everything else is pretty much there in one form or another and simply > takes more usage in order to shake the cobwebs out of it. > > _______________________________________________ > 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 matthew at matthew.at Sun Feb 20 20:47:01 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 20 Feb 2011 17:47:01 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <011e01cbd15b$d28594f0$7790bed0$@iname.com> References: <011e01cbd15b$d28594f0$7790bed0$@iname.com> Message-ID: <4D61C415.5080202@matthew.at> On 2/20/2011 4:11 PM, Frank Bulk wrote: > Yes -- without naming names, one of the three leading CMTS vendors has no > IPv6 support (Q3 at the earliest). And how could not naming names benefit anyone in this discussion? Matthew Kaufman From frnkblk at iname.com Sun Feb 20 20:53:23 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 20 Feb 2011 19:53:23 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D61C415.5080202@matthew.at> References: <011e01cbd15b$d28594f0$7790bed0$@iname.com> <4D61C415.5080202@matthew.at> Message-ID: <013401cbd16a$1fd3e4b0$5f7bae10$@iname.com> I really don't like to "name and shame" in public. If it's a feature gap/snafu I don't mind point it out. Another service provider already did the naming for us, though -- just go to Comcast's IPv6 blog and you'll figure it out. Frank -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Sunday, February 20, 2011 7:47 PM To: frnkblk at iname.com Cc: 'George Bonser'; Owen DeLong; Jeffrey Lyon; arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised On 2/20/2011 4:11 PM, Frank Bulk wrote: > Yes -- without naming names, one of the three leading CMTS vendors has no > IPv6 support (Q3 at the earliest). And how could not naming names benefit anyone in this discussion? Matthew Kaufman From tedm at ipinc.net Sun Feb 20 21:27:58 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sun, 20 Feb 2011 18:27:58 -0800 Subject: [arin-ppml] Name and Shame in public - was Re: ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <013401cbd16a$1fd3e4b0$5f7bae10$@iname.com> References: <011e01cbd15b$d28594f0$7790bed0$@iname.com> <4D61C415.5080202@matthew.at> <013401cbd16a$1fd3e4b0$5f7bae10$@iname.com> Message-ID: <4D61CDAE.6000909@ipinc.net> I do not consider that they are planning on it in Q3 to be a "name and shame" A "name and shame" would be if a vendor had NO plans on supporting IPv6 at this time. After all I doubt any RIR will be out of IPv4 by the end of 2011. Getting IPv6 out by then is cutting it close - but arguably the CPE market isn't going to be IPv6 ready by 2012 anyway so what good is a Redback or a cable head that's IPv6-compliant when none of the CPE's can talk to it? Ted On 2/20/2011 5:53 PM, Frank Bulk wrote: > I really don't like to "name and shame" in public. If it's a feature > gap/snafu I don't mind point it out. > > Another service provider already did the naming for us, though -- just go to > Comcast's IPv6 blog and you'll figure it out. > > Frank > > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Sunday, February 20, 2011 7:47 PM > To: frnkblk at iname.com > Cc: 'George Bonser'; Owen DeLong; Jeffrey Lyon; arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks - revised > > On 2/20/2011 4:11 PM, Frank Bulk wrote: >> Yes -- without naming names, one of the three leading CMTS vendors has no >> IPv6 support (Q3 at the earliest). > > And how could not naming names benefit anyone in this discussion? > > 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 mpetach at netflight.com Sun Feb 20 21:42:01 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 20 Feb 2011 18:42:01 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> Message-ID: On Sat, Feb 19, 2011 at 6:02 PM, John Curran wrote: > Correct. ?Make the intent of the policy clear and unambiguous. ?I believe the AC is working on that presently. > > /John I'd like to raise my voice in SUPPORT of the policy proposal to render explicit the set of IPv4 addresses being returned to IANA as "{}". Matt > On Feb 20, 2011, at 9:52 AM, "William Herrin" wrote: > >> On Sat, Feb 19, 2011 at 8:18 PM, John Curran wrote: >>> On Feb 20, 2011, at 9:11 AM, William Herrin wrote: >>>> So I'm still UNCLEAR what conflict arises if local policies and >>>> strategies designate -nothing- for return. >>> >>> ?If local policies specifically designate that nothing should >>> ?be returned under any circumstance, there is no confusion. >>> ?Given that the language is policies and strategies, and the >>> ?existing practice is to return space to the IANA, a policy >>> ?proposal which is not explicit in this area is indeed unclear. >> >> John, >> >> Then to clarify the staff guidance, staff would like prop 131 to >> indicate whether or not it intends to specify what addresses should be >> returned to IANA under pending global policy 2009-3 (yes) and if so, >> what addresses those are (none). This has nothing to do with >> preempting or not preempting global policy, something an ARIN-local >> policy like 131 can't do anyway. >> >> Yes? >> >> -Bill >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > From mpetach at netflight.com Sun Feb 20 21:45:10 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 20 Feb 2011 18:45:10 -0800 Subject: [arin-ppml] Draft Policy 2011-4: Reserved Pool for Critical Infrastructure In-Reply-To: References: <4D4B22CB.4090007@arin.net> Message-ID: On Sat, Feb 19, 2011 at 7:11 PM, Scott Leibrand wrote: > In light of ARIN's recent receipt of the last /8 from IANA, we have updated > ARIN-2011-4 to remove the "Upon receipt of the last /8 ..." clause. > > The updated policy statement now reads: > > ARIN will place an equivalent of a /16 of IPv4 address space in a reserve > for Critical Infrastructure, as defined in section 4.4. If at the end of the > policy term there is unused address space remaining in this pool, ARIN staff > is authorized to utilize this space in a manner consistent with community > expectations. > > If anyone has any opinions on this draft policy, I would encourage you to > share them here on the list, and at the upcoming Public Policy Meeting in > San Juan, Puerto Rico in April. > > -Scott sounds reasonable to me--let's make it so. Matt From frnkblk at iname.com Sun Feb 20 23:05:41 2011 From: frnkblk at iname.com (Frank Bulk) Date: Sun, 20 Feb 2011 22:05:41 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D61C350.9@ipinc.net> References: <011e01cbd15b$d28594f0$7790bed0$@iname.com> <4D61C350.9@ipinc.net> Message-ID: <013701cbd17c$9ae09330$d0a1b990$@iname.com> While the factory load may not support it, there is downloadable software that has pretty complete IPv6 support (including DHCPv6-PD) and privately available that's even more complete . The DIR-655 support an IPv6 firewall, but the 615 and 825 currently do not. Look at ARIN' IPv6 wiki for more detail, as there are different hardware models with varying levels of capabilities. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Sunday, February 20, 2011 7:44 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised The factory load on the DIR-615/655/825 series does not support dhcpv6-pd from what I have read, nor does it support ANY firewalling for IPv6. That is the primary difference in functionality from the Comcast build for the 160NL that is on Sourceforge. Note that there is not enough space on the 4MB flash routers (like the DIR-615) to run dhcpv6-pd & ipv6tables (needed for the SPI stuff for IPv6) Ted On 2/20/2011 4:11 PM, Frank Bulk wrote: > Yes -- without naming names, one of the three leading CMTS vendors has no > IPv6 support (Q3 at the earliest). > > In regards to CPE, the D-Link DIR-655 with the latest firmware is pretty > IPv6 ready. It sells for $70 at Amazon.com, probably a bit more at your > local electronics retailer. See > http://www.getipv6.info/index.php/Broadband_CPE for more info (most don't > have an SPI firewall). > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of George Bonser > Sent: Friday, February 18, 2011 4:33 PM > To: Owen DeLong; Jeffrey Lyon > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks - revised > > > But is there any gear being sold today that doesn't support v6? I know > two vendors that can't do dynamic routing protocols on v6 yet but their > gear is more aimed at the layer2 switching market anyway and do support > v6 switching, addressing, and static routes which probably covers the > vast majority of their use cases. All of the stuff I have in the layer3 > area of the network supports v6 and that is four different vendors. > > At this stage finding vendors who don't support v6 is more difficult > than finding the ones that do. The one problem area is xDSL CPE. > Everything else is pretty much there in one form or another and simply > takes more usage in order to shake the cobwebs out of it. > > _______________________________________________ > 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. From mysidia at gmail.com Mon Feb 21 00:39:04 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sun, 20 Feb 2011 23:39:04 -0600 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <4D5AFAA6.10300@arin.net> References: <4D5AFAA6.10300@arin.net> Message-ID: On Tue, Feb 15, 2011 at 4:13 PM, ARIN wrote: > I oppose PP133 as written. Opposed on count 1: "Unaffiliated address blocks" These address blocks are legacy blocks which are within ARIN's responsibility for maintaining services and setting number resource policy. Unless ARIN chose to abdicate the responsibility, these blocks are not "unaffiliated"; RSA or not, service contract or not. WHOIS "Placeholders" indicating non-responsibility would be technically inaccurate, because ARIN is the RIR whom responsibility for the legacy allocations were conferred to. Opposed on count 2: It's not right for a number resources policy action to make ARIN abandon providing essential services to legacy holders that ARIN already took responsibility for and has a duty to provide, in a manner that may threaten stability of legacy resource holders' networks, or ability for them to be contacted about abuse or technical matters using information in WHOIS. If ARIN wants to totally abandon the responsibility for legacy allocations' services, then ARIN should find a suitable third party, such as another RIR, capable, willing, and prepared for ARIN to properly hand off legacy address space services and policy responsibility to. Absent that, These services are valuable to the entire RIR community, not just the resource holder. ARIN already agreed to be responsible for WHOIS and rDNS for the legacy registrations. I Might not be so opposed, if legacy holders could in some way pay ARIN a reasonable amount to support the maintenance of their rDNS service, without signing any RSA or contract, as an alternative to signing an elaborate LRSA agreement / joining ARIN. If ARIN is supposed to be maintaining the legacy allocations, then services should be offered for those allocations without ARIN dissuading resource holders from buying services by making them sign RSAs guaranteed to surrender any special rights they might think they have. Opposed on count 3: Removal of information from WHOIS. ARIN already agreed to be responsible for WHOIS for the legacy allocations. Stripping out information and just creating a stub won't do. ARIN needs to keep that information available in some form, even if it is believed to no longer be accurate, or is suspected to be updated; even if they choose to make that only available to members, via login, or some other method -- WHOIS data should not be destroyed for legacy resources that do not complete some "RSA signing process". There is a less harmful way of doing that.... insert a _banner_ in the WHOIS record to the effect that the resource is not subject to a proper RSA / payment for service. Or let ARIN itself run a separate WHOIS server for the "archived" legacy registrations, referred by lookup on the primary WHOIS server. With appropriate huge banners indicating the allocation is historical or not in good standing with the RIR. Opposed on count 4: All this proposal would really seem to accomplish would be to disrupt legacy networks, make some legacy resource holders angry, renig on agreed upon responsibilities, and create confusion for users of WHOIS. This is not the first step towards getting legacy resource holders to do what would be preferable (sign the RSA, and fully subject their resources to ARIN policies); it might be a step in the future.. But the PP could have at least had some teeth, such as revokation and reassignment of legacy resources after X months of remaining in that status, then there might be some meaningful amount of address space to free up. -- -JH From tedm at ipinc.net Mon Feb 21 02:19:19 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sun, 20 Feb 2011 23:19:19 -0800 Subject: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of Unaffiliated Address Blocks - revised In-Reply-To: <013701cbd17c$9ae09330$d0a1b990$@iname.com> References: <011e01cbd15b$d28594f0$7790bed0$@iname.com> <4D61C350.9@ipinc.net> <013701cbd17c$9ae09330$d0a1b990$@iname.com> Message-ID: <4D6211F7.3090407@ipinc.net> On 2/20/2011 8:05 PM, Frank Bulk wrote: > While the factory load may not support it, there is downloadable software > that has pretty complete IPv6 support (including DHCPv6-PD) and privately > available that's even more complete . > > The DIR-655 support an IPv6 firewall, but the 615 and 825 currently do not. According to the ARIN wiki, the 825 version C1 supports the identical set of features as the DIR-655 including the firewall. The 825 B version omits the firewall. The 615 does not support a firewall. And due to the amount of flash in it, it probably never will. > Look at ARIN' IPv6 wiki for more detail, as there are different hardware > models with varying levels of capabilities. > Thanks for the reminder, I went ahead and made a few minor updates to that CPE page. The DIR-615 firmware link on it was to the 3.12 version, there is a newer one out now, 3.13, and I removed the prerelease comment since that version is on the main dlink support webinterface now. (it is obviously not prerelease) I also cleaned up a bit the links for openwrt and dd-wrt IPv6 info. I probably should load up the current factory firmware for the DIR-615 and make some screenshots of the IPv6 interface and link them up on the wiki. Ted > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Sunday, February 20, 2011 7:44 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of > Unaffiliated Address Blocks - revised > > > > The factory load on the DIR-615/655/825 series does not support > dhcpv6-pd from what I have read, nor does it support ANY firewalling > for IPv6. That is the primary difference > in functionality from the Comcast build for the 160NL that is > on Sourceforge. Note that there is not enough space on the 4MB > flash routers (like the DIR-615) to run dhcpv6-pd& ipv6tables (needed > for the SPI stuff for IPv6) > > > > Ted > > On 2/20/2011 4:11 PM, Frank Bulk wrote: >> Yes -- without naming names, one of the three leading CMTS vendors has no >> IPv6 support (Q3 at the earliest). >> >> In regards to CPE, the D-Link DIR-655 with the latest firmware is pretty >> IPv6 ready. It sells for $70 at Amazon.com, probably a bit more at your >> local electronics retailer. See >> http://www.getipv6.info/index.php/Broadband_CPE for more info (most don't >> have an SPI firewall). >> >> Frank >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of George Bonser >> Sent: Friday, February 18, 2011 4:33 PM >> To: Owen DeLong; Jeffrey Lyon >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-prop-133: No Volunteer Services on Behalf of >> Unaffiliated Address Blocks - revised >> >> >> But is there any gear being sold today that doesn't support v6? I know >> two vendors that can't do dynamic routing protocols on v6 yet but their >> gear is more aimed at the layer2 switching market anyway and do support >> v6 switching, addressing, and static routes which probably covers the >> vast majority of their use cases. All of the stuff I have in the layer3 >> area of the network supports v6 and that is four different vendors. >> >> At this stage finding vendors who don't support v6 is more difficult >> than finding the ones that do. The one problem area is xDSL CPE. >> Everything else is pretty much there in one form or another and simply >> takes more usage in order to shake the cobwebs out of it. >> >> _______________________________________________ >> 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. > From vixie at vix.com Mon Feb 21 09:33:10 2011 From: vixie at vix.com (Paul Vixie) Date: Mon, 21 Feb 2011 14:33:10 +0000 Subject: [arin-ppml] NAT444 rumors In-Reply-To: (Matthew Petach's message of "Sun, 20 Feb 2011 19:01:06 -0800") References: <480805.6221.qm@web114707.mail.gq1.yahoo.com> <0DFFE3D3-17D6-4D89-B493-620646B954C1@ukbroadband.com> Message-ID: Matthew Petach writes: > Would be nice to see if someone was willing to host some v6-only content, > and see what level of penetration was achieved... I think that any content that would be wide and compelling interest thus offering a good basis for measuring such penetration would also be too expensive to produce unless it was intended to be universally available. -- Paul Vixie KI6YSY From dwing at cisco.com Mon Feb 21 15:37:50 2011 From: dwing at cisco.com (Dan Wing) Date: Mon, 21 Feb 2011 12:37:50 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> Message-ID: <117f01cbd207$34f42290$9edc67b0$@com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Chris Grundemann > Sent: Thursday, February 17, 2011 5:55 PM > To: Benson Schliesser > Cc: NANOG list; ARIN-PPML List > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > On Thu, Feb 10, 2011 at 14:17, Benson Schliesser > wrote: > > > If you have more experience (not including rumors) that suggests > otherwise, I'd very much like to hear about it. ?I'm open to the > possibility that NAT444 breaks stuff - that feels right in my gut - but > I haven't found any valid evidence of this. > > In case you have not already found this: > http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. For details, see my comments at http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and see Reinaldo Penno's comments at http://www.ietf.org/mail-archive/web/behave/current/msg09030.html -d > Cheers, > ~Chris > > > > > Regardless, I think we can agree that IPv6 is the way to avoid NAT- > related growing pains. ?We've known this for a long time. > > > > Cheers, > > -Benson > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Mon Feb 21 15:58:45 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 21 Feb 2011 12:58:45 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <117f01cbd207$34f42290$9edc67b0$@com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> Message-ID: <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Chris Grundemann >> Sent: Thursday, February 17, 2011 5:55 PM >> To: Benson Schliesser >> Cc: NANOG list; ARIN-PPML List >> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 >> naysayer...) >> >> On Thu, Feb 10, 2011 at 14:17, Benson Schliesser >> wrote: >> >>> If you have more experience (not including rumors) that suggests >> otherwise, I'd very much like to hear about it. I'm open to the >> possibility that NAT444 breaks stuff - that feels right in my gut - but >> I haven't found any valid evidence of this. >> >> In case you have not already found this: >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > That document conflates problems of NAT444 with problems of NAT44 > with problems of bandwidth starvation with problems of CGN. > > For details, see my comments at > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > and see Reinaldo Penno's comments at > http://www.ietf.org/mail-archive/web/behave/current/msg09030.html > > -d > The document describes problems that will exist in NAT444 environments. It does not state that these problems would be specific to NAT444, but, NAT444 will cause or exacerbate each of the problems described. Yes, the problems may have other underlying root causes, but, they will all be present in a NAT444 environment, even if they were not present in the same environment prior to deployment of NAT444. Let me put it this way... IPv4 has a TITANIC lack of numeric addresses and has been stretched beyond its limits for some time now. IPv6 is a life boat. NAT is a seat cushion used for floatation. NAT444 (and other NAT-based extensions) are deck chairs. Attempting to improve them beyond their current states is an effort to rearrange the deck chairs. Owen From alh-ietf at tndh.net Mon Feb 21 17:52:14 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 21 Feb 2011 14:52:14 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter Message-ID: <15dc01cbd219$fe9c69b0$fbd53d10$@net> 30,000 ft. summary of prop's 126, 129-131, 133-135 Open letter to Legacy IPv4 resource holders that have not signed the LRSA: We, the self-designated illuminati, hereby declare your use of IPv4 resources as fraudulent since your lack of attention to the LRSA makes you clearly out of compliance with this-week's version of ARIN policy (never mind that some of us were not even born when you received your allocation and couldn't possibly know if you have ever violated the terms of the original agreement). We demand you cease using IPv4, so that this eminent-domain action will allow us to continue to sit on our collective a$$ (as we have for over a decade) and do nothing about moving past the need for IPv4. We are hereby notifying you that the record in the whois database for your resource will be changed to those of us with 'legitimate' need, as our lethargy makes our use of the resource much more important than your dubious historical efforts at fostering the nascent Internet. Besides you have a history of going first, so give us your IPv4 resources and move straight to IPv6-only now (we may even allow you to become a member of our exclusive club ... just pay the -p-h-e-n-o-m-e-n-a-l- nominal dues). Also, don't pay attention to the fact that while we refuse to recognize any historical rights you may claim to use of the IPv4 addressing resource, we are informing the rest of the world that since you happened to exist in our region we have *EXCLUSIVE* rights to any and all resources reclaimed from legacy assignments. It is very simple, we are greedy and lazy, and really don't want to be bothered doing the real work that deploying IPv6 would require. You should also recognize that while we repeatedly chant the official mantra 'ARIN says nothing about the routability of a given allocation', this eminent-domain action explicitly guarantees that your attempts at continued use of the resource will be blocked from global routing (don't ask us how because we can't tell anyone what routes to carry). We are simply putting you on a blacklist as non-compliant, and taking what we want, because we declared we can. Next week we will dream up something new to keep us busy with endless email threads so we can further delay that real work over in the corner. ARIN policy mafia Seriously, it is long past time to stop playing games and refusing to recognize reality. This region has no more rights to any returned resource than any other, and arguably has less given the consumption rate here is not on the growth path that other regions show. 'Legitimate use' can't be subject to the whims of the week, and many truly legitimate use cases have been denied over the last decade as this community refused to allow the smaller players access to the resources. Get over your self-aggrandizement and recognize that there are unmet needs in the system, and those needs will be dealt with now that 'legitimate need' becomes measured by the market value rather than the whims of an exclusive club. The one thing that is clear is that the IPv4 resources in the ARIN region will become the most untraceable mess possible because the continued arrogance about 'need' will drive most market participants to avoid letting ARIN in on the activities. This alone should cause the DoJ to jump on the heads of the DoC in a vain attempt at sanity injection. At this point I doubt anyone has a large enough clue-bat to deal with the swelled head that the ARIN illuminati portrays. Tony FWIW: opposed to all listed proposals From tedm at ipinc.net Mon Feb 21 18:14:08 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 21 Feb 2011 15:14:08 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <15dc01cbd219$fe9c69b0$fbd53d10$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> Message-ID: <4D62F1C0.4020104@ipinc.net> "The one thing that is clear is that the IPv4 resources in the ARIN region will become the most untraceable mess possible because the continued arrogance about 'need' will drive most market participants to avoid letting ARIN in on the activities." Please quit revealing our secret plans for getting everyone on IPv6!!!!!! On 2/21/2011 2:52 PM, Tony Hain wrote: > > 30,000 ft. summary of prop's 126, 129-131, 133-135 > > Open letter to Legacy IPv4 resource holders that have not signed the LRSA: > > We, the self-designated illuminati, hereby declare your use of IPv4 > resources as fraudulent since your lack of attention to the LRSA makes you > clearly out of compliance with this-week's version of ARIN policy (never > mind that some of us were not even born when you received your allocation > and couldn't possibly know if you have ever violated the terms of the > original agreement). We demand you cease using IPv4, so that this > eminent-domain action will allow us to continue to sit on our collective a$$ > (as we have for over a decade) and do nothing about moving past the need for > IPv4. We are hereby notifying you that the record in the whois database for > your resource will be changed to those of us with 'legitimate' need, as our > lethargy makes our use of the resource much more important than your dubious > historical efforts at fostering the nascent Internet. Besides you have a > history of going first, so give us your IPv4 resources and move straight to > IPv6-only now (we may even allow you to become a member of our exclusive > club ... just pay the -p-h-e-n-o-m-e-n-a-l- nominal dues). > > Also, don't pay attention to the fact that while we refuse to recognize any > historical rights you may claim to use of the IPv4 addressing resource, we > are informing the rest of the world that since you happened to exist in our > region we have *EXCLUSIVE* rights to any and all resources reclaimed from > legacy assignments. It is very simple, we are greedy and lazy, and really > don't want to be bothered doing the real work that deploying IPv6 would > require. You should also recognize that while we repeatedly chant the > official mantra 'ARIN says nothing about the routability of a given > allocation', this eminent-domain action explicitly guarantees that your > attempts at continued use of the resource will be blocked from global > routing (don't ask us how because we can't tell anyone what routes to > carry). We are simply putting you on a blacklist as non-compliant, and > taking what we want, because we declared we can. Next week we will dream up > something new to keep us busy with endless email threads so we can further > delay that real work over in the corner. > > ARIN policy mafia > > > > > Seriously, it is long past time to stop playing games and refusing to > recognize reality. This region has no more rights to any returned resource > than any other, and arguably has less given the consumption rate here is not > on the growth path that other regions show. 'Legitimate use' can't be > subject to the whims of the week, and many truly legitimate use cases have > been denied over the last decade as this community refused to allow the > smaller players access to the resources. Get over your self-aggrandizement > and recognize that there are unmet needs in the system, and those needs will > be dealt with now that 'legitimate need' becomes measured by the market > value rather than the whims of an exclusive club. > > The one thing that is clear is that the IPv4 resources in the ARIN region > will become the most untraceable mess possible because the continued > arrogance about 'need' will drive most market participants to avoid letting > ARIN in on the activities. This alone should cause the DoJ to jump on the > heads of the DoC in a vain attempt at sanity injection. At this point I > doubt anyone has a large enough clue-bat to deal with the swelled head that > the ARIN illuminati portrays. > > Tony > > FWIW: opposed to all listed proposals > > > _______________________________________________ > 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 Feb 21 18:23:51 2011 From: jcurran at arin.net (John Curran) Date: Mon, 21 Feb 2011 23:23:51 +0000 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <15dc01cbd219$fe9c69b0$fbd53d10$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> Message-ID: <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> On Feb 22, 2011, at 6:52 AM, Tony Hain wrote: > 30,000 ft. summary of prop's 126, 129-131, 133-135 > ... > FWIW: opposed to all listed proposals Tony - Thanks for the thought-provoking input, as well as the succinct summary of opposition to all the listed proposals... The one surprising element is that several of the policy proposals you list express similar concerns to those that were alluded to in your soliloquy; are you certain that none of the policy proposals would improve the situation from your perspective? (I ask only because it is predominantly via the policy development process that changes in ARIN's address management practices occurs) Thanks, /John John Curran President and CEO ARIN From alh-ietf at tndh.net Mon Feb 21 18:57:10 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 21 Feb 2011 15:57:10 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> Message-ID: <160101cbd223$10121560$30364020$@net> John Curran wrote: > Tony - > > Thanks for the thought-provoking input, as well as the > succinct summary of opposition to all the listed proposals... > The one surprising element is that several of the policy > proposals you list express similar concerns to those that > were alluded to in your soliloquy; are you certain that > none of the policy proposals would improve the situation > from your perspective? (I ask only because it is > predominantly via the policy development process that > changes in ARIN's address management practices occurs) Yes we need an active policy development process, but IPv4 is baked and it is time to stop stirring that dough ball. There might be improvements in the proposal set, but the amount of effort needed to refine them and highlight the value is time distracted from real work. At the end of the day they make no difference in the outcome other than to delay its inevitable conclusion. In case it wasn't clear, my comments were directed at the set of proposals and the never ending discussion threads. They explicitly do not assume any positions are being taken by ARIN staff or AC members. The point being that if that set of proposals passed as a collective, the outcome would be as described. Tony > > Thanks, > /John > > John Curran > President and CEO > ARIN From joelja at bogus.com Mon Feb 21 19:58:16 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 21 Feb 2011 16:58:16 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D596163.7000009@arin.net> References: <4D596163.7000009@arin.net> Message-ID: <4D630A28.3010206@bogus.com> The following statement from 2011-5 is incorrect or at a minimum chooses to deliberately rule out one option. > Service providers are currently presented with three options for > obtaining sufficient IPv4 address space for NAT444/IPv4 extension > deployments: (1) Request allocations under the NRPM; (2) share address > space with other providers (this proposal); or (3) use address space > allocated to another entity (i.e. ?squat?). Of the three options, > option 2 (this proposal) is preferable, as it will minimize the number > of addresses used for IPv4 extension deployments while preserving the > authority of IANA and RIRs. Which is use RFC 1918 space. The fact that there are conflicts with addresses used in gateways in no way invalidates the suitability of private scope ip addresses for use in a private scope. Creating new private scope ranges which gateways do not treat as such has it's own liabilities and at a minimum that needs to be acknowledged and balanced against threat of collisions. joel From bill at herrin.us Mon Feb 21 20:08:24 2011 From: bill at herrin.us (William Herrin) Date: Mon, 21 Feb 2011 20:08:24 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D630A28.3010206@bogus.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> Message-ID: On Mon, Feb 21, 2011 at 7:58 PM, Joel Jaeggli wrote: > The following statement from 2011-5 is incorrect or at a minimum chooses > to deliberately rule out one option. > >> Service providers are currently presented with three options for >> obtaining sufficient IPv4 address space for NAT444/IPv4 extension >> deployments: (1) Request allocations under the NRPM; (2) share address >> space with other providers (this proposal); or (3) use address space >> allocated to another entity (i.e. ?squat?). ?Of the three options, >> option 2 (this proposal) is preferable, as it will minimize the number >> of addresses used for IPv4 extension deployments while preserving the >> authority of IANA and RIRs. > > Which is use RFC 1918 space. The fact that there are conflicts with > addresses used in gateways in no way invalidates the suitability of > private scope ip addresses for use in a private scope. Creating new > private scope ranges which gateways do not treat as such has it's own > liabilities and at a minimum that needs to be acknowledged and balanced > against threat of collisions. Hi Joel, The sentence which preceded your quote addressed your issue: "A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed." The three options apply to solutions which prevent address conflicts: RIR allocations, the ISP-shared address space in this proposal and squatting space unlikely to become routed on the public Internet (e.g. space used by the US DoD SIPR and JWICS networks). Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tedm at ipinc.net Mon Feb 21 20:23:33 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 21 Feb 2011 17:23:33 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <160101cbd223$10121560$30364020$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <160101cbd223$10121560$30364020$@net> Message-ID: <4D631015.1040006@ipinc.net> On 2/21/2011 3:57 PM, Tony Hain wrote: > John Curran wrote: >> Tony - >> >> Thanks for the thought-provoking input, as well as the >> succinct summary of opposition to all the listed proposals... >> The one surprising element is that several of the policy >> proposals you list express similar concerns to those that >> were alluded to in your soliloquy; are you certain that >> none of the policy proposals would improve the situation >> from your perspective? (I ask only because it is >> predominantly via the policy development process that >> changes in ARIN's address management practices occurs) > > Yes we need an active policy development process, but IPv4 is baked and it > is time to stop stirring that dough ball. John, Tony, Owen and All, We don't know this. Yes, it would be best for all concerned if that was the case. But it IS important to keep in mind that there's a heck of a lot of IPv4 out there already and assigned. And there is the potential for proposals like NAT64 (which has WORKING code from the Ecdysis project) that, IF adopted by a large number of ISPs, could seriously muck up the IPv6 changeover pot. I am only half-joking when I said Tony that your disrupting the secret plans to get IPv6 deployed. I know all the arguments that the big carriers are going to force IPv6 and all of that. Fantastic! We are IPv6 capable RIGHT NOW our "big carrier" competitors (in our market) are NOT. I'd love for them to start forcing IPv6. The day they start telling new users that they can't use their Windows XP on their Internet connection is the day those users slam down the phone and call us for service. We may tell them the same thing but at least they have called us. And, we can tell them the same thing and have coverage because they can't then run to our competitor. They HAVE to upgrade. But, I'm not subscribing to the Pollyanna principle today. If you think for one moment that I believe my big competitors are going to allow those customers to slip away, your a fool. The fact is that stacked NAT works with a lot of CPE's. One big assumption a lot of people seem to be making is that a CPE like a DSL modem that does NAT will not work if the outside IP address on the WAN interface is a private IP address. That is flat out wrong. I've seem them work. Granted the throughput often stinks but they work. And the same goes for MANY of the SOHO "modemless" NAT routers. An ISP that is in danger of running out of IPv4 can simply start delivering connectivity via private numbers. Most of their Ma and Pa Kettle users won't even notice. And for the few smart enough to come in out of the rain and notice, the ISP can move them to their pool of remaining IPv4 public numbers. And there are other tricks too. For example an ISP can duplicate public IP's and NAT them in the router. An ISP can put the same subnet in 3 different POP's and just translate. The end user won't get a private IP on their WAN interface they will get a public number - it's just a public number that isn't reachable from the Internet. The ISP can just tell the user that their TOS prohibits the user from running servers and hide the public network behind a NAT. As long as the user can load web pages, most of them won't care, they will think things are just peachy. Yeah, I know it's not scalable. But since when in the computer industry has a BAD, unscalable piece of dung idea that was popular with the customers ever been abandoned? No, the usual practice is to shovel tons of money at it until it kina-sorta-works. If that wasn't SOP then we'd all be running Xenix. Just remember that it is human nature to choose a small, immediate, short term gain that carries a long term loss over a large, long term gain that carries a small, immediate, short term loss. Don't assume that IPv4 will go quietly into the sunset, is all I'm saying. Ted There might be improvements in the > proposal set, but the amount of effort needed to refine them and highlight > the value is time distracted from real work. At the end of the day they make > no difference in the outcome other than to delay its inevitable conclusion. > > In case it wasn't clear, my comments were directed at the set of proposals > and the never ending discussion threads. They explicitly do not assume any > positions are being taken by ARIN staff or AC members. The point being that > if that set of proposals passed as a collective, the outcome would be as > described. > > Tony > >> >> Thanks, >> /John >> >> John Curran >> President and CEO >> ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Mon Feb 21 20:37:28 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 21 Feb 2011 17:37:28 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D630A28.3010206@bogus.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> Message-ID: <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> RFC-1918 is not an option because it overlaps space in use by the end users for their local area networks. It may not invalidate their use, but, it does make it impracticable from a service provider perspective. Definitely much better to look for an un-advertised range and squat there from a pragmatic perspective. This is explained if you read the proposal in its entirety. Owen On Feb 21, 2011, at 4:58 PM, Joel Jaeggli wrote: > The following statement from 2011-5 is incorrect or at a minimum chooses > to deliberately rule out one option. > >> Service providers are currently presented with three options for >> obtaining sufficient IPv4 address space for NAT444/IPv4 extension >> deployments: (1) Request allocations under the NRPM; (2) share address >> space with other providers (this proposal); or (3) use address space >> allocated to another entity (i.e. ?squat?). Of the three options, >> option 2 (this proposal) is preferable, as it will minimize the number >> of addresses used for IPv4 extension deployments while preserving the >> authority of IANA and RIRs. > > Which is use RFC 1918 space. The fact that there are conflicts with > addresses used in gateways in no way invalidates the suitability of > private scope ip addresses for use in a private scope. Creating new > private scope ranges which gateways do not treat as such has it's own > liabilities and at a minimum that needs to be acknowledged and balanced > against threat of collisions. > > joel > _______________________________________________ > 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 alh-ietf at tndh.net Mon Feb 21 21:11:37 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 21 Feb 2011 18:11:37 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <4D631015.1040006@ipinc.net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <160101cbd223$10121560$30364020$@net> <4D631015.1040006@ipinc.net> Message-ID: <160901cbd235$f1610c80$d4232580$@net> Ted, I don't assume IPv4 will go out quietly. It will be more like the 'big bang'. For a quiet departure, isp's and app developers would have needed to start 10 years ago. Consumers should never have noticed this, and carriers can't force it no matter how hard they try. IT IS NOT A NETWORK DRIVEN TRANSITION, it is a network stalled one. The applications have to be updated, and every org has its own business timeframes when it is willing to touch/revalidate them. Even consumers won't upgrade unless they see a business value in the update app. Until the apps get there the best IPv6 network in the world will sit idle. That said, the network did stall the effort by proceeding along as if nothing was going to change, therefore not providing a visible utility for app developers to test against, and at the same time sinking capex into boat-anchor access technologies that have to amortize their way out of the system before capex will be queued again. People will always take the local economic min, therefore there will be lots of man-in-the-middle attack boxes deployed. Some will try their best to avoid overlapping 1918 while others will reuse public space. When the only apps are web browsing and pop/imap, you are correct the consumer won't notice, unfortunately there are many other apps. For those that are getting used to location-aware apps though, that reuse will be more than a problem, particularly for orgs that are paying for high rankings in location based adverts. Add in the calls you will get because enterprise-X just blackholed one of their employees vpn connection because they are being spammed or ddos'd by the same IP address (doesn't become a problem until the public address is shared...) There are costs to every path chosen. Starting 10 years ago would have created a set of costs then that have been deferred to now. Delaying has not made those costs go away, and has added in the set of nonsense that will be deployed to further extend IPv4 until the apps get fixed. Making it unclear when that needs to be done by continually tweaking the IPv4 policy is not going to get the app developers motivated, resulting in even more tweaks and nonsense technologies 5 years from now. It is time to stop wasting energy on IPv4 policy. It is what it is, and there is nothing that will substantially change the outcome. Tony > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Ted Mittelstaedt > Sent: Monday, February 21, 2011 5:24 PM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Proposal insanity --- an open letter > > On 2/21/2011 3:57 PM, Tony Hain wrote: > > John Curran wrote: > >> Tony - > >> > >> Thanks for the thought-provoking input, as well as the > >> succinct summary of opposition to all the listed proposals... > >> The one surprising element is that several of the policy > >> proposals you list express similar concerns to those that > >> were alluded to in your soliloquy; are you certain that > >> none of the policy proposals would improve the situation > >> from your perspective? (I ask only because it is > >> predominantly via the policy development process that > >> changes in ARIN's address management practices occurs) > > > > Yes we need an active policy development process, but IPv4 is baked > and it > > is time to stop stirring that dough ball. > > John, Tony, Owen and All, > > We don't know this. Yes, it would be best for all concerned if that > was the case. > > But it IS important to keep in mind that there's a heck of a lot > of IPv4 out there already and assigned. And there is the potential > for proposals like NAT64 (which has WORKING code from the Ecdysis > project) that, IF adopted by a large number of ISPs, could seriously > muck up the IPv6 changeover pot. > > I am only half-joking when I said Tony that your disrupting the > secret plans to get IPv6 deployed. > > I know all the arguments that the big carriers are going to force > IPv6 > and all of that. Fantastic! We are IPv6 capable RIGHT NOW our "big > carrier" competitors (in our market) are NOT. I'd love for them to > start forcing IPv6. The day they start telling new users that they > can't use their Windows XP on their Internet connection is the day > those > users slam down the phone and call us for service. We may tell them > the > same thing but at least they have called us. And, we can tell them the > same thing and have coverage because they can't then run to our > competitor. They HAVE to upgrade. But, I'm not subscribing to the > Pollyanna principle today. If you think for one moment that I believe > my big competitors are going to allow those customers to slip away, > your > a fool. > > The fact is that stacked NAT works with a lot of CPE's. One big > assumption a lot of people seem to be making is that a CPE like a DSL > modem that does NAT will not work if the outside IP address on the > WAN interface is a private IP address. That is flat out wrong. I've > seem them work. Granted the throughput often stinks but they work. > And > the same goes for MANY of the SOHO "modemless" NAT routers. > > An ISP that is in danger of running out of IPv4 can simply start > delivering connectivity via private numbers. Most of their Ma and Pa > Kettle users won't even notice. And for the few smart enough to come > in > out of the rain and notice, the ISP can move them to their pool of > remaining IPv4 public numbers. And there are other tricks too. For > example an ISP can duplicate public IP's and NAT them in the router. > An ISP can put the same subnet in 3 different POP's and just translate. > The end user won't get a private IP on their WAN interface they will > get a public number - it's just a public number that isn't reachable > from the Internet. The ISP can just tell the user that their TOS > prohibits the user from running servers and hide the public network > behind a NAT. As long as the user can load web pages, most of them > won't care, they will think things are just peachy. > > Yeah, I know it's not scalable. But since when in the computer > industry has a BAD, unscalable piece of dung idea that was popular with > the customers ever been abandoned? No, the usual practice is to shovel > tons of money at it until it kina-sorta-works. If that wasn't SOP then > we'd all be running Xenix. > > Just remember that it is human nature to choose a small, immediate, > short term gain that carries a long term loss over a large, long term > gain that carries a small, immediate, short term loss. > > Don't assume that IPv4 will go quietly into the sunset, is all I'm > saying. > > Ted > > There might be improvements in the > > proposal set, but the amount of effort needed to refine them and > highlight > > the value is time distracted from real work. At the end of the day > they make > > no difference in the outcome other than to delay its inevitable > conclusion. > > > > In case it wasn't clear, my comments were directed at the set of > proposals > > and the never ending discussion threads. They explicitly do not > assume any > > positions are being taken by ARIN staff or AC members. The point > being that > > if that set of proposals passed as a collective, the outcome would be > as > > described. > > > > Tony > > > >> > >> Thanks, > >> /John > >> > >> John Curran > >> President and CEO > >> ARIN > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > 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 dwing at cisco.com Mon Feb 21 21:17:04 2011 From: dwing at cisco.com (Dan Wing) Date: Mon, 21 Feb 2011 18:17:04 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> Message-ID: <133301cbd236$9910c0b0$cb324210$@com> > >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > That document conflates problems of NAT444 with problems of NAT44 > > with problems of bandwidth starvation with problems of CGN. > > it may require a delicate palate to differentiate the different flavors > of Running out of bandwidth for Netflix is pretty distinct from the flavor of fried gNAT. -d From dwing at cisco.com Mon Feb 21 21:08:34 2011 From: dwing at cisco.com (Dan Wing) Date: Mon, 21 Feb 2011 18:08:34 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> Message-ID: <132601cbd235$69298720$3b7c9560$@com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, February 21, 2011 12:59 PM > To: Dan Wing > Cc: 'Chris Grundemann'; 'Benson Schliesser'; 'NANOG list'; 'ARIN-PPML > List' > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > > On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: > > >> -----Original Message----- > >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > >> Behalf Of Chris Grundemann > >> Sent: Thursday, February 17, 2011 5:55 PM > >> To: Benson Schliesser > >> Cc: NANOG list; ARIN-PPML List > >> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > >> naysayer...) > >> > >> On Thu, Feb 10, 2011 at 14:17, Benson Schliesser > >> wrote: > >> > >>> If you have more experience (not including rumors) that suggests > >> otherwise, I'd very much like to hear about it. I'm open to the > >> possibility that NAT444 breaks stuff - that feels right in my gut - > but > >> I haven't found any valid evidence of this. > >> > >> In case you have not already found this: > >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > > > That document conflates problems of NAT444 with problems of NAT44 > > with problems of bandwidth starvation with problems of CGN. > > > > For details, see my comments at > > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > > and see Reinaldo Penno's comments at > > http://www.ietf.org/mail-archive/web/behave/current/msg09030.html > > > > -d > > The document describes problems that will exist in NAT444 environments. > It does not state that these problems would be specific to NAT444, but, > NAT444 will cause or exacerbate each of the problems described. To the contrary. Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. > Yes, the problems may have other underlying root causes, but, they > will all be present in a NAT444 environment, even if they were not > present in the same environment prior to deployment of NAT444. > > > Let me put it this way... > > IPv4 has a TITANIC lack of numeric addresses and has been > stretched beyond its limits for some time now. > > IPv6 is a life boat. > > NAT is a seat cushion used for floatation. > > NAT444 (and other NAT-based extensions) are deck chairs. > > Attempting to improve them beyond their current states is > an effort to rearrange the deck chairs. -d From joelja at bogus.com Mon Feb 21 21:24:10 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 21 Feb 2011 18:24:10 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> Message-ID: <4D631E4A.7070102@bogus.com> On 2/21/11 5:37 PM, Owen DeLong wrote: > RFC-1918 is not an option because it overlaps space in use by the end > users for their local area networks. So you say, I say you have the choice between two support problems, one which you don't have presently but many isps the wold over contend with every day. > It may not invalidate their use, but, it > does make it impracticable from a service provider perspective. This is an opinion, not a fact. It is a fact that collisions between the external address assigned and the internal addresses utilized will render some percentage of cpe inoperable. By some accounts the amount of cpe that both have that problem, and will be numbered in such a fashion thereby forming the union that causes that problem is a fraction of the total population. > Definitely > much better to look for an un-advertised range and squat there from a > pragmatic perspective. Not if an application, be it reliant on upnp, 6to4 or some other mechanism for leveraging the external address assumes the external address on the cpe is global in scope. The assumption that an unadvertised range will in fact remain so, has been repeatedly and routinely proven to be false and ISPs that have done that do so at their peril... > This is explained if you read the proposal in its entirety. I have, I also have read previous iterations of the proposal, both here, in the APNIC region and in internet draft form at the IETF. As a network operator I opposed the 127, not because because I believe that there isn't a problem but because I believe that the proposed cure is worse than the disease... If you must hand out private scope addresses do so. triage small percentage of cpe that can't reach your gateways and move on. At a minimum the proposal should acknowledge that we're trading one kind of breakage (private scope v4 address) for another (presumed to be public scope v4 address but actually private) and that alternative 4 is in fact the thing that you don't want to do which is just use rfc 1918 and deal with those consequnces which are well understood... > Owen > > On Feb 21, 2011, at 4:58 PM, Joel Jaeggli wrote: > >> The following statement from 2011-5 is incorrect or at a minimum chooses >> to deliberately rule out one option. >> >>> Service providers are currently presented with three options for >>> obtaining sufficient IPv4 address space for NAT444/IPv4 extension >>> deployments: (1) Request allocations under the NRPM; (2) share address >>> space with other providers (this proposal); or (3) use address space >>> allocated to another entity (i.e. ?squat?). Of the three options, >>> option 2 (this proposal) is preferable, as it will minimize the number >>> of addresses used for IPv4 extension deployments while preserving the >>> authority of IANA and RIRs. >> >> Which is use RFC 1918 space. The fact that there are conflicts with >> addresses used in gateways in no way invalidates the suitability of >> private scope ip addresses for use in a private scope. Creating new >> private scope ranges which gateways do not treat as such has it's own >> liabilities and at a minimum that needs to be acknowledged and balanced >> against threat of collisions. >> >> joel >> _______________________________________________ >> 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 info at arin.net Mon Feb 21 21:26:28 2011 From: info at arin.net (ARIN) Date: Mon, 21 Feb 2011 21:26:28 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - February 2011 Message-ID: <4D631ED4.6030406@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) held a meeting on 17 February 2011 in order to make decisions about draft policies and proposals. The AC added the following proposal to their docket: ARIN-prop-131. Section 5.0 Legacy Addresses The AC also developed ARIN-prop-131 into a draft policy for adoption discussion online and at the ARIN XXVII Public Policy Meeting in San Juan, Puerto Rico. The draft policy "ARIN-2011-6: Returned IPv4 Addresses" will be posted shortly to the PPML. The PDP states, ?Any member of the community, including a proposal originator, may initiate a Discussion Petition if they are dissatisfied with the action taken by the Advisory Council regarding any specific policy proposal.? The AC used proposal 131 to generate a draft policy, the text of which is different from the original proposal. Proposal 131 may be petitioned (Discussion Petition) to try to advance the original version as a draft policy for adoption discussion on the Public Policy Mailing List and at a Public Policy Meeting. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. However, in order for a petition of proposal 131 to be considered successful for the ARIN XXVII meeting, the entire petition must be concluded by 7 March 2011 in order to meet the requirement of posting as draft policy at least 35 days prior to the meeting. The Advisory Council appreciates the involvement of all community members who provide input toward a complete discussion of policy proposals. The AC especially wishes to thank those authors of policy proposals for their efforts in helping the community address possible improvements. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Feb 21 21:28:31 2011 From: info at arin.net (ARIN) Date: Mon, 21 Feb 2011 21:28:31 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses Message-ID: <4D631F4F.80408@arin.net> Draft Policy ARIN-2011-6 Returned IPv4 Addresses On 17 February 2011 the ARIN Advisory Council (AC) selected "Returned IPv4 Addresses" as a draft policy for adoption discussion on the PPML and at the Public Policy Meeting in San Juan, Puerto Rico in April. The draft was developed by the AC from policy proposal "ARIN-prop-131. Section 5.0 Legacy Addresses". Per the Policy Development Process the AC submitted text to ARIN for a staff and legal assessment prior to its selection as a draft policy. Below the draft policy is the ARIN staff and legal assessment, followed by the text that was submitted by the AC. Note that the AC revised the draft policy text after they received the assessment from staff. Draft Policy ARIN-2011-6 is below and can be found at: https://www.arin.net/policy/proposals/2011_6.html You are encouraged to discuss Draft Policy 2011-6 on the PPML prior to the April Public Policy Meeting. Both the discussion on the list and at the meeting will be used by the ARIN Advisory Council to determine the community consensus for adopting this as policy. The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Member Services American Registry for Internet Numbers (ARIN) ## * ## Draft Policy ARIN-2011-6 Returned IPv4 Addresses Date: 17 February 2011 Policy statement: 4.1.9 Returned IPv4 Addresses All IPv4 addresses returned to, recovered, or revoked by ARIN will be made available for registration and distribution in the ARIN region within 30 days. Rationale: Adopting this proposal will result in the clarification of the status of returned IPv4 addresses. IPv4 address resources should not sit idle due to lack of policy clarity. Timetable for implementation: Immediately ##### STAFF ASSESSMENT Proposal: "Section 5.0 Legacy Addresses" (pp 131) Policy Version (Date): 16 Feb 2011 Date of Assessment: 15 Feb 2011 1. Proposal Summary (Staff Understanding): This policy proposal would require all legacy IPv4 address space returned to ARIN to be added to the available inventory for redistribution. 2. Comments A. Staff Comments: 1. The wording of the proposal seems to indicate that any legacy space, including a /8, that gets returned to ARIN gets added into ARIN?s inventory and made available for redistribution within 30 days. In all other instances where a legacy /8 has been returned to ARIN, ARIN has returned that space to IANA. This proposal would change that standard practice. 2. This policy would conflict with existing ARIN-2009-3 (Global Proposal): Allocation of IPv4 Blocks to Regional Internet Registries, which was adopted by the ARIN Board in January 2010, and allows for designation of legacy space to be returned to IANA. This policy proposal should specifically indicate whether legacy space should not be designated for return to IANA if that is its intent. 3. This policy would be become section 4.1.9 in the NRPM if adopted. This may require the title of the policy to be modified. B. Legal Comments Pending 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur within 3 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ? Updated guidelines ? Staff training 4. Proposal Text: Section 5.0 Legacy Addresses 5.1 Returned Legacy Addresses Legacy IPv4 addresses returned to or recovered by ARIN will be made available for registration and distribution in the ARIN region. Rationale: Adopting this proposal will result in the clarification of the status of returned legacy addresses. IPv4 address resources should not sit idle due to lack of policy clarity. From cgrundemann at gmail.com Mon Feb 21 23:16:34 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Mon, 21 Feb 2011 21:16:34 -0700 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <132601cbd235$69298720$3b7c9560$@com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> Message-ID: On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > Its title, filename, abstract, and introduction all say the problems > are specific to NAT444. ?Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). Cheers, ~Chris > -d > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From bill at herrin.us Mon Feb 21 23:16:19 2011 From: bill at herrin.us (William Herrin) Date: Mon, 21 Feb 2011 23:16:19 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: <4D631F4F.80408@arin.net> References: <4D631F4F.80408@arin.net> Message-ID: On Mon, Feb 21, 2011 at 9:28 PM, ARIN wrote: > Draft Policy ARIN-2011-6 > Returned IPv4 Addresses > > Policy statement: > > 4.1.9 Returned IPv4 Addresses > > All IPv4 addresses returned to, recovered, or revoked by ARIN will be > made available for registration and distribution in the ARIN region > within 30 days. Greetings, Three suggestions: 1. Drop "within 30 days." Let ARIN staff determine the appropriate hold time for returned addresses, both for recovered legacy and non-legacy addresses. Staff are bright and highly competent; they won't unreasonably sit on addresses while there's a waiting list and need. > A. Staff Comments: >?This policy > proposal should specifically indicate whether legacy space should not be > designated for return to IANA if that is its intent. 2. Specify that "No such space shall be designated for return to IANA," solving ARIN staff's issue. 3. Specify that while this policy is in effect, ARIN shall neither request nor accept IPv4 addresses allocations from IANA under global policy 2009-3. Why do #3? As written, this policy proposal obstructs other regions from ratifying and using global policy 2009-3. In theory, they could decide they're more generous than we are, return addresses and allow their redistribution to areas with need. But they can't do that while we hover ready to gobble and hold those addresses without giving anything back. Realistically there's no chance the other regions would return addresses to IANA for the same reasons we won't. But this isn't about reality, it's about politics. Call the bluff. We want to make sure ARIN isn't "the reason" they can't ratify and use 2009-3 themselves. Besides, it's only fair. If we won't contribute, we shouldn't take either. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Mon Feb 21 23:23:21 2011 From: bill at herrin.us (William Herrin) Date: Mon, 21 Feb 2011 23:23:21 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> Message-ID: On Mon, Feb 21, 2011 at 11:16 PM, William Herrin wrote: > On Mon, Feb 21, 2011 at 9:28 PM, ARIN wrote: >> Draft Policy ARIN-2011-6 >> Returned IPv4 Addresses >> >> Policy statement: >> >> 4.1.9 Returned IPv4 Addresses >> >> All IPv4 addresses returned to, recovered, or revoked by ARIN will be >> made available for registration and distribution in the ARIN region >> within 30 days. > > Greetings, > > Three suggestions: Four suggestions: 4) Put "legacy" back in. RSA-covered address recovery already operates by recyling the addresses into ARIN's pool and assigning or allocating them to ARIN registrants. Codifying it in policy is redundant and serves to muddy the issue this proposal attempts to address: that we want ARIN to apply the same process to recovered legacy addresses. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mueller at syr.edu Mon Feb 21 23:24:23 2011 From: mueller at syr.edu (Milton L Mueller) Date: Mon, 21 Feb 2011 23:24:23 -0500 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <15dc01cbd219$fe9c69b0$fbd53d10$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> Message-ID: <75822E125BCB994F8446858C4B19F0D7143AF29D7E@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > > The one thing that is clear is that the IPv4 resources in the ARIN > region will become the most untraceable mess possible because the > continued arrogance about 'need' will drive most market participants to > avoid letting ARIN in on the activities. Couldn't have said it better myself. However, you seem to misinterpret both the intent and the effect of 133, which as I understand it is a big step away from the arrogance you decry. The point of that proposal is not to force anyone to give up resources but to make room for the changes that need to happen to avoid the "untraceable mess" Also, to say that ipv4 is "baked" and therefore we should stop talking about it or developing policies for it misses the crucial fact that no one can jump to pure ipv6 without cutting themselves off from most of the internet. "Implementing ipv6" in reality means "implementing dual stack" - now and for the next ten years at least. How do you do dual stack without any ipv4, do tell? --MM From mpetach at netflight.com Tue Feb 22 00:00:33 2011 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 21 Feb 2011 21:00:33 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> Message-ID: On Sun, Feb 20, 2011 at 6:42 PM, Matthew Petach wrote: > On Sat, Feb 19, 2011 at 6:02 PM, John Curran wrote: >> Correct. ?Make the intent of the policy clear and unambiguous. ?I believe the AC is working on that presently. >> >> /John > > I'd like to raise my voice in SUPPORT of the policy proposal to render explicit > the set of IPv4 addresses being returned to IANA as "{}". > > Matt To clarify, as I've gotten some questions about my stance; those addresses which were allocated by IANA to ARIN for the region, I believe should stay within the region. Address blocks *not* allocated by IANA to ARIN, namely address blocks assigned to "legacy" holders should be returned whence they came, if they are freed up, namely to IANA, as those never passed through ARIN's hands in the first place. Matt From pwilson at apnic.net Tue Feb 22 00:00:54 2011 From: pwilson at apnic.net (Paul Wilson) Date: Tue, 22 Feb 2011 15:00:54 +1000 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <75822E125BCB994F8446858C4B19F0D7143AF29D7E@SUEX07-MBX-04.ad.syr.edu> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <75822E125BCB994F8446858C4B19F0D7143AF29D7E@SUEX07-MBX-04.ad.syr.edu> Message-ID: I don't often post to PPML, but here goes. --On 21 February 2011 11:24:23 PM -0500 Milton L Mueller wrote: > ... > Also, to say that ipv4 is "baked" and therefore we should stop talking > about it or developing policies for it misses the crucial fact that no > one can jump to pure ipv6 without cutting themselves off from most of the > internet. "Implementing ipv6" in reality means "implementing dual stack" > - now and for the next ten years at least. How do you do dual stack > without any ipv4, do tell? First: In this context, "dual stack" is defined as including IPv4, of course. And the IPv4 addresses which are used can be public or private, of course. Milton, I guess you understand private addressing and NATs. Dual stack during the transition will involve mostly private IPv4 addresses, and NAT of various kinds between those private addresses and the public; along with public IPv6 addresses of course. The more that this NATing goes on, as the Internet grows, the less efficient that IPv4-based connectivity will become, to the point of being less preferred than IPv6. At the same time, IPv6 connectivity steadily improves in terms of services accessible, routing efficiency, and general reliability; starting with today's relatively meagre coverage, until it is preferred, first in some, then in most, and then in all, places. As for the public addresses needed by ISPs for their gateway into the IPv4 Internet, some RIRs already have a policy which will make this available in the long term, effectively rationing some proportion of their remaining IPv4 address pools. APNIC has such a policy in place, currently reserving most of a /8 for allocations in /22 blocks; and this supply of addresses is projected to last for many years, beyond the point where they are actually needed. That's the model in a nutshell. Crack away at it by all means, but it is pretty straightforward. Paul Wilson APNIC ________________________________________________________________________ Paul Wilson, Director-General, APNIC http://www.apnic.net +61 7 3858 3100 From tedm at ipinc.net Tue Feb 22 00:03:40 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 21 Feb 2011 21:03:40 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <160901cbd235$f1610c80$d4232580$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <160101cbd223$10121560$30364020$@net> <4D631015.1040006@ipinc.net> <160901cbd235$f1610c80$d4232580$@net> Message-ID: <4D6343AC.3020505@ipinc.net> On 2/21/2011 6:11 PM, Tony Hain wrote: > Ted, > > I don't assume IPv4 will go out quietly. good. IMHO if Cisco had honored it's original commitment on IPv6 and put it into IOS 12.1 then a lot of this problem would have been moot. But that's just me. Delaying has not > made those costs go away, and has added in the set of nonsense that will be > deployed to further extend IPv4 until the apps get fixed. Making it unclear > when that needs to be done by continually tweaking the IPv4 policy is not > going to get the app developers motivated, resulting in even more tweaks and > nonsense technologies 5 years from now. It is time to stop wasting energy on > IPv4 policy. It is what it is, and there is nothing that will substantially > change the outcome. > If the neighbor's dog poops in your yard, you can't ignore it if you want it to go away. There are only 2 sides to the issue now. Side 1 is the RIR becomes activist and does whatever possible to eliminate IPv4 as quick as possible. The theory being that this is the best stewardship to get rid of a mess by cutting it out. Side 2 is the RIR stays neutral in this and concentrates on doing the best job stewarding what it's charged to steward, which is both IPv4 and IPv6. The theory being that stewards are supposed to be neutrals. If we want to get rid of IPv4 quickly then tweaking and making IPv4 as unclear as possible is exactly what we need to be doing. Unclarity means a lot of uncertainty on costs and so it forces orgs to budget even high than they would normally do so to continue to support it. That is a stronger incentive to get rid of it. So in that case it really makes no difference what we do with proposal 133 and the like, we can vote them all down. It is the fact that they continually get introduced - and "son of prop 133" gets introduced again, is what keeps the pot boiling. By contrast if we want to reduce the mess to hold costs in line then it is imperative that we adjust the stewardship of IPv4 so as to reduce costs for everyone as much as possible. That means continuing to do new IPv4 policy proposals and making reasonable decisions on them. So that really is the two approaches that are opposite sides of the debate. But the debate isn't going away just because we don't like it and want to ignore it. Ted > Tony > > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Ted Mittelstaedt >> Sent: Monday, February 21, 2011 5:24 PM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Proposal insanity --- an open letter >> >> On 2/21/2011 3:57 PM, Tony Hain wrote: >>> John Curran wrote: >>>> Tony - >>>> >>>> Thanks for the thought-provoking input, as well as the >>>> succinct summary of opposition to all the listed proposals... >>>> The one surprising element is that several of the policy >>>> proposals you list express similar concerns to those that >>>> were alluded to in your soliloquy; are you certain that >>>> none of the policy proposals would improve the situation >>>> from your perspective? (I ask only because it is >>>> predominantly via the policy development process that >>>> changes in ARIN's address management practices occurs) >>> >>> Yes we need an active policy development process, but IPv4 is baked >> and it >>> is time to stop stirring that dough ball. >> >> John, Tony, Owen and All, >> >> We don't know this. Yes, it would be best for all concerned if that >> was the case. >> >> But it IS important to keep in mind that there's a heck of a lot >> of IPv4 out there already and assigned. And there is the potential >> for proposals like NAT64 (which has WORKING code from the Ecdysis >> project) that, IF adopted by a large number of ISPs, could seriously >> muck up the IPv6 changeover pot. >> >> I am only half-joking when I said Tony that your disrupting the >> secret plans to get IPv6 deployed. >> >> I know all the arguments that the big carriers are going to force >> IPv6 >> and all of that. Fantastic! We are IPv6 capable RIGHT NOW our "big >> carrier" competitors (in our market) are NOT. I'd love for them to >> start forcing IPv6. The day they start telling new users that they >> can't use their Windows XP on their Internet connection is the day >> those >> users slam down the phone and call us for service. We may tell them >> the >> same thing but at least they have called us. And, we can tell them the >> same thing and have coverage because they can't then run to our >> competitor. They HAVE to upgrade. But, I'm not subscribing to the >> Pollyanna principle today. If you think for one moment that I believe >> my big competitors are going to allow those customers to slip away, >> your >> a fool. >> >> The fact is that stacked NAT works with a lot of CPE's. One big >> assumption a lot of people seem to be making is that a CPE like a DSL >> modem that does NAT will not work if the outside IP address on the >> WAN interface is a private IP address. That is flat out wrong. I've >> seem them work. Granted the throughput often stinks but they work. >> And >> the same goes for MANY of the SOHO "modemless" NAT routers. >> >> An ISP that is in danger of running out of IPv4 can simply start >> delivering connectivity via private numbers. Most of their Ma and Pa >> Kettle users won't even notice. And for the few smart enough to come >> in >> out of the rain and notice, the ISP can move them to their pool of >> remaining IPv4 public numbers. And there are other tricks too. For >> example an ISP can duplicate public IP's and NAT them in the router. >> An ISP can put the same subnet in 3 different POP's and just translate. >> The end user won't get a private IP on their WAN interface they will >> get a public number - it's just a public number that isn't reachable >> from the Internet. The ISP can just tell the user that their TOS >> prohibits the user from running servers and hide the public network >> behind a NAT. As long as the user can load web pages, most of them >> won't care, they will think things are just peachy. >> >> Yeah, I know it's not scalable. But since when in the computer >> industry has a BAD, unscalable piece of dung idea that was popular with >> the customers ever been abandoned? No, the usual practice is to shovel >> tons of money at it until it kina-sorta-works. If that wasn't SOP then >> we'd all be running Xenix. >> >> Just remember that it is human nature to choose a small, immediate, >> short term gain that carries a long term loss over a large, long term >> gain that carries a small, immediate, short term loss. >> >> Don't assume that IPv4 will go quietly into the sunset, is all I'm >> saying. >> >> Ted >> >> There might be improvements in the >>> proposal set, but the amount of effort needed to refine them and >> highlight >>> the value is time distracted from real work. At the end of the day >> they make >>> no difference in the outcome other than to delay its inevitable >> conclusion. >>> >>> In case it wasn't clear, my comments were directed at the set of >> proposals >>> and the never ending discussion threads. They explicitly do not >> assume any >>> positions are being taken by ARIN staff or AC members. The point >> being that >>> if that set of proposals passed as a collective, the outcome would be >> as >>> described. >>> >>> Tony >>> >>>> >>>> Thanks, >>>> /John >>>> >>>> John Curran >>>> President and CEO >>>> ARIN >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > From tedm at ipinc.net Tue Feb 22 00:10:13 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Mon, 21 Feb 2011 21:10:13 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <75822E125BCB994F8446858C4B19F0D7143AF29D7E@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4D634535.40608@ipinc.net> On 2/21/2011 9:00 PM, Paul Wilson wrote: > I don't often post to PPML, but here goes. > > --On 21 February 2011 11:24:23 PM -0500 Milton L Mueller > wrote: >> > ... >> Also, to say that ipv4 is "baked" and therefore we should stop talking >> about it or developing policies for it misses the crucial fact that no >> one can jump to pure ipv6 without cutting themselves off from most of the >> internet. "Implementing ipv6" in reality means "implementing dual stack" >> - now and for the next ten years at least. How do you do dual stack >> without any ipv4, do tell? > > First: In this context, "dual stack" is defined as including IPv4, of > course. And the IPv4 addresses which are used can be public or private, > of course. > > Milton, I guess you understand private addressing and NATs. Dual stack > during the transition will involve mostly private IPv4 addresses, and > NAT of various kinds between those private addresses and the public; > along with public IPv6 addresses of course. The more that this NATing > goes on, as the Internet grows, the less efficient that IPv4-based > connectivity will become, to the point of being less preferred than > IPv6. At the same time, IPv6 connectivity steadily improves in terms of > services accessible, routing efficiency, and general reliability; > starting with today's relatively meagre coverage, until it is preferred, > first in some, then in most, and then in all, places. > > As for the public addresses needed by ISPs for their gateway into the > IPv4 Internet, some RIRs already have a policy which will make this > available in the long term, effectively rationing some proportion of > their remaining IPv4 address pools. APNIC has such a policy in place, > currently reserving most of a /8 for allocations in /22 blocks; and this > supply of addresses is projected to last for many years, beyond the > point where they are actually needed. > > That's the model in a nutshell. Crack away at it by all means, but it is > pretty straightforward. > My cracks are: s/as the Internet grows/as parts of the Internet grows/g s/IPv6 connectivity steadily improves/IPv6 connectivity improves in fits and starts/g Imagine a drunk staggering from IPv4 to IPv6 and you got it. Ted > Paul Wilson > APNIC > > > ________________________________________________________________________ > Paul Wilson, Director-General, APNIC > http://www.apnic.net +61 7 3858 3100 > > > > _______________________________________________ > 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 frnkblk at iname.com Tue Feb 22 00:11:14 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 21 Feb 2011 23:11:14 -0600 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> Message-ID: <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> Does the existing "RSA-covered address recovery" include the 30-day window? In your previous comment I know you wanted to leave that timeframe to the discretion of ARIN staff, but the timeframe is one reason why we may want to include RSA-covered addresses in 2011-6. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Monday, February 21, 2011 10:23 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses On Mon, Feb 21, 2011 at 11:16 PM, William Herrin wrote: > On Mon, Feb 21, 2011 at 9:28 PM, ARIN wrote: >> Draft Policy ARIN-2011-6 >> Returned IPv4 Addresses >> >> Policy statement: >> >> 4.1.9 Returned IPv4 Addresses >> >> All IPv4 addresses returned to, recovered, or revoked by ARIN will be >> made available for registration and distribution in the ARIN region >> within 30 days. > > Greetings, > > Three suggestions: Four suggestions: 4) Put "legacy" back in. RSA-covered address recovery already operates by recyling the addresses into ARIN's pool and assigning or allocating them to ARIN registrants. Codifying it in policy is redundant and serves to muddy the issue this proposal attempts to address: that we want ARIN to apply the same process to recovered legacy addresses. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bill at herrin.us Tue Feb 22 00:14:25 2011 From: bill at herrin.us (William Herrin) Date: Tue, 22 Feb 2011 00:14:25 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> Message-ID: On Tue, Feb 22, 2011 at 12:11 AM, Frank Bulk wrote: > Does the existing "RSA-covered address recovery" include the 30-day window? > In your previous comment I know you wanted to leave that timeframe to the > discretion of ARIN staff, but the timeframe is one reason why we may want to > include RSA-covered addresses in 2011-6. Hi Frank, I believe the recycle period is currently much longer, but then we haven't run out of addresses yet. If we don't set it in policy, ARIN staff is free to set a then-optimal recycle period. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From frnkblk at iname.com Tue Feb 22 00:37:46 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 21 Feb 2011 23:37:46 -0600 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> Message-ID: <014401cbd252$a2c371e0$e84a55a0$@iname.com> Thanks, Bill, for clarifying. If I make the assumption that legacy and non-legacy space are almost equivalent in terms of their reusability after their return, for simplicity's sake it would be easier to keep the recycle times in sync, either: a) keep the verbiage of 2011-6 so that it includes all space and specify a time b) exclude legacy space in 2011-6 and leave recycle time to the discretion of ARIN staff. In both cases, the recycle time would be effectively the same. If we don't specify a time period in policy 2011-6, I'm not sure if author's concern regarding "sit[ting] idle" would be met. Perhaps min/max time would give the ARIN staff the flexibility but also address the author's concern. Frank -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Monday, February 21, 2011 11:14 PM To: frnkblk at iname.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses On Tue, Feb 22, 2011 at 12:11 AM, Frank Bulk wrote: > Does the existing "RSA-covered address recovery" include the 30-day window? > In your previous comment I know you wanted to leave that timeframe to the > discretion of ARIN staff, but the timeframe is one reason why we may want to > include RSA-covered addresses in 2011-6. Hi Frank, I believe the recycle period is currently much longer, but then we haven't run out of addresses yet. If we don't set it in policy, ARIN staff is free to set a then-optimal recycle period. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mysidia at gmail.com Tue Feb 22 01:41:23 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Tue, 22 Feb 2011 00:41:23 -0600 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <4D62F1C0.4020104@ipinc.net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <4D62F1C0.4020104@ipinc.net> Message-ID: On Mon, Feb 21, 2011 at 5:14 PM, Ted Mittelstaedt wrote: > "The one thing that is clear is that the IPv4 resources in the ARIN region > will become the most untraceable mess possible because the continued > arrogance about 'need' will drive most market participants to avoid letting > ARIN in on the activities." Chances are that will happen even under current policy. But need is not some form of 'arrogance'; justified need is the basis of reasonable allocation policies. > Please quit revealing our secret plans for getting everyone on IPv6!!!!!! "Gee, Brain, what do you want to do tonight?" "The same thing we do every night, IPngy---try to take over the internet!" ... -- -J From bensons at queuefull.net Tue Feb 22 03:29:23 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 02:29:23 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> Message-ID: <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: > On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > >> Its title, filename, abstract, and introduction all say the problems >> are specific to NAT444. Which is untrue. > > I just re-read the filename, abstract and introduction, and I disagree > that any of those say that the problems are specific to NAT444. They > all do state that these problems are present in NAT444, but not that > it's the only technology/scenario/configuration where you might find > them. Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). > More importantly, I am unsure the point of this argument. Are you > trying to say that the items listed as broken in the draft are not > actually broken? Because in my experience they are. IMHO, the fact > that they are also broken in other (similar) scenarios is not evidence > that they are not broken in this one. On the contrary, this scenario > seems to be evidence to the brokenness in the others (until we get a > chance to test and document them all - are you volunteering? ;). There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as "broken" as others have claimed, and sub-optimal might be acceptable if it's the only alternative. Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. Cheers, -Benson From bensons at queuefull.net Tue Feb 22 03:44:32 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 02:44:32 -0600 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> Message-ID: On Feb 21, 2011, at 5:23 PM, John Curran wrote: > On Feb 22, 2011, at 6:52 AM, Tony Hain wrote: > >> 30,000 ft. summary of prop's 126, 129-131, 133-135 >> ... >> FWIW: opposed to all listed proposals > > Tony - > > Thanks for the thought-provoking input, as well as the > succinct summary of opposition to all the listed proposals... > The one surprising element is that several of the policy > proposals you list express similar concerns to those that > were alluded to in your soliloquy; are you certain that > none of the policy proposals would improve the situation > from your perspective? (I ask only because it is > predominantly via the policy development process that > changes in ARIN's address management practices occurs) Indeed, prop 133 (along with 134) is intended to address exactly the notions Tony espoused. Specifically, it leads to a system of overt consent by the governed - leaving non-consenters to find alternatives of their own to ARIN's registry services. It's not clear to me how the content of Tony's message leads to opposition to prop 133. Cheers, -Benson From owen at delong.com Tue Feb 22 03:58:11 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 00:58:11 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D631E4A.7070102@bogus.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> Message-ID: <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> On Feb 21, 2011, at 6:24 PM, Joel Jaeggli wrote: > On 2/21/11 5:37 PM, Owen DeLong wrote: >> RFC-1918 is not an option because it overlaps space in use by the end >> users for their local area networks. > > So you say, I say you have the choice between two support problems, one > which you don't have presently but many isps the wold over contend with > every day. > Care to explain what these are? >> It may not invalidate their use, but, it >> does make it impracticable from a service provider perspective. > > This is an opinion, not a fact. It is a fact that collisions between the > external address assigned and the internal addresses utilized will > render some percentage of cpe inoperable. By some accounts the amount of > cpe that both have that problem, and will be numbered in such a fashion > thereby forming the union that causes that problem is a fraction of the > total population. > That union in a very large user population (such as faced by many of the large residential ISPs in the ARIN region) is large enough to be potentially quite costly to support. >> Definitely >> much better to look for an un-advertised range and squat there from a >> pragmatic perspective. > > Not if an application, be it reliant on upnp, 6to4 or some other > mechanism for leveraging the external address assumes the external > address on the cpe is global in scope. > That application will break in this scenario anyway, regardless. That assumption is going to end up being false in the near future no matter what. > The assumption that an unadvertised range will in fact remain so, has > been repeatedly and routinely proven to be false and ISPs that have done > that do so at their peril... > Only if they think some percentage of their customers might want to reach that specific part of DoD when/if they start advertising it. I would say at this point, for the likely lifetime of IPv4 and especially NAT444, that's reasonably low risk compared to the support costs inherent in using RFC-1918 in this situation. However, you are correct that it isn't the best solution. What I expect will happen is that they will, instead, each seek large allocations from ARIN to support their NAT444 intermediary addresses and get them under current policies, thus accelerating IPv4 exhaustion. >> This is explained if you read the proposal in its entirety. > > I have, I also have read previous iterations of the proposal, both here, > in the APNIC region and in internet draft form at the IETF. > > As a network operator I opposed the 127, not because because I believe > that there isn't a problem but because I believe that the proposed cure > is worse than the disease... > > If you must hand out private scope addresses do so. triage small > percentage of cpe that can't reach your gateways and move on. > Triaging small percentage when you have 20 million subscribers may be a rather large triage process. > At a minimum the proposal should acknowledge that we're trading one kind > of breakage (private scope v4 address) for another (presumed to be > public scope v4 address but actually private) and that alternative 4 is > in fact the thing that you don't want to do which is just use rfc 1918 > and deal with those consequnces which are well understood... > A provider that considers it practical to do so is certainly welcome to use RFC-1918 and there is nothing in this proposal that precludes that. However, for a certain percentage of providers, that is not practicable in their environments due to rather enormous support costs that would result. In those environments, the likely choices the provider will make will be between getting this policy so they can all share the same semi-private /10, or, each getting their own separate allocations which may be as much as a /10 in some cases and will almost certainly add up to way more than a /10 in toto. Owen >> Owen >> >> On Feb 21, 2011, at 4:58 PM, Joel Jaeggli wrote: >> >>> The following statement from 2011-5 is incorrect or at a minimum chooses >>> to deliberately rule out one option. >>> >>>> Service providers are currently presented with three options for >>>> obtaining sufficient IPv4 address space for NAT444/IPv4 extension >>>> deployments: (1) Request allocations under the NRPM; (2) share address >>>> space with other providers (this proposal); or (3) use address space >>>> allocated to another entity (i.e. ?squat?). Of the three options, >>>> option 2 (this proposal) is preferable, as it will minimize the number >>>> of addresses used for IPv4 extension deployments while preserving the >>>> authority of IANA and RIRs. >>> >>> Which is use RFC 1918 space. The fact that there are conflicts with >>> addresses used in gateways in no way invalidates the suitability of >>> private scope ip addresses for use in a private scope. Creating new >>> private scope ranges which gateways do not treat as such has it's own >>> liabilities and at a minimum that needs to be acknowledged and balanced >>> against threat of collisions. >>> >>> joel >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> From owen at delong.com Tue Feb 22 04:13:49 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 01:13:49 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> Message-ID: <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> On Feb 21, 2011, at 9:00 PM, Matthew Petach wrote: > On Sun, Feb 20, 2011 at 6:42 PM, Matthew Petach wrote: >> On Sat, Feb 19, 2011 at 6:02 PM, John Curran wrote: >>> Correct. Make the intent of the policy clear and unambiguous. I believe the AC is working on that presently. >>> >>> /John >> >> I'd like to raise my voice in SUPPORT of the policy proposal to render explicit >> the set of IPv4 addresses being returned to IANA as "{}". >> >> Matt > > To clarify, as I've gotten some questions about my stance; > those addresses which were allocated by IANA to ARIN for > the region, I believe should stay within the region. > > Address blocks *not* allocated by IANA to ARIN, namely > address blocks assigned to "legacy" holders should be returned > whence they came, if they are freed up, namely to IANA, as those > never passed through ARIN's hands in the first place. > Most blocks you describe were not allocated by IANA to their current holders, but, rather by ARIN's predecessors, the SRI Internic and the NSI Internic, neither of which exists for those blocks to be returned to. Care to clarify your stance in light of those facts? Owen From owen at delong.com Tue Feb 22 04:40:59 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 01:40:59 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> Message-ID: <7277A6F9-C21C-4EF0-8220-A3F3A707A836@delong.com> On Feb 22, 2011, at 12:29 AM, Benson Schliesser wrote: > > On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: > >> On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: >> >>> Its title, filename, abstract, and introduction all say the problems >>> are specific to NAT444. Which is untrue. >> >> I just re-read the filename, abstract and introduction, and I disagree >> that any of those say that the problems are specific to NAT444. They >> all do state that these problems are present in NAT444, but not that >> it's the only technology/scenario/configuration where you might find >> them. > > Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). > I would point out to them that the fact that their technology choice isn't NAT 444 does not mean that they don't have the same problems, merely that their technology wasn't part of the testing documented in the draft. I think the draft is perfectly clear and that humans, even intelligent humans often have problems with this level of logic. If A is a subset of B, it does not mean that A is not a subset of C. Therefore, a draft that states that technology B has problem A is not and cannot be logically construed as a statement that technology C does not have problem A, no matter how common it is for seemingly intelligent humans to make the mistake of doing so. >> More importantly, I am unsure the point of this argument. Are you >> trying to say that the items listed as broken in the draft are not >> actually broken? Because in my experience they are. IMHO, the fact >> that they are also broken in other (similar) scenarios is not evidence >> that they are not broken in this one. On the contrary, this scenario >> seems to be evidence to the brokenness in the others (until we get a >> chance to test and document them all - are you volunteering? ;). > > There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. > I don't think anyone has said that IPv6 is the only address family that matters. What I think people, myself included, have been saying is that IPv6 is the only way forward that does not involve many of these problems. (See my earlier Titanic post). As to whether or not it matters that people misinterpred draft-donly..., I'm not sure whether it actually does or not. There is no flavor of NAT that is particularly desirable. It's a matter of choosing the one that is least damaging to your environment where least damage may boil down to a choice between 5% and 3% remaining functionality. > On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as "broken" as others have claimed, and sub-optimal might be acceptable if it's the only alternative. > I don't think anyone is saying IPv4 no longer matters. I think we are saying that effort spent attempting to make the deteriorating IPv4 situation deteriorate less is both futile and better spent on making the IPv6 deployment situation better. > Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. > Only if you expect that you can rely on a supply side in such a market. I am unconvinced that such will be reliable, especially after about 6 months of trading. This also presumes that more sensitive users can be defined in terms of what those users are willing (or able) to pay. Owen (who is very glad he has provider-independent addresses in both families as we approach this iceberg) From Wesley.E.George at sprint.com Tue Feb 22 09:48:53 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 22 Feb 2011 14:48:53 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E370C81@PDAWM12B.ad.sprint.com> -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Monday, February 21, 2011 8:08 PM To: Joel Jaeggli Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] The sentence which preceded your quote addressed your issue: "A recent study showed that there is no part of RFC1918 space which would not overlap with some IPv4 gateways, and therefore to prevent address conflicts, new address space is needed." [WEG] Citing this study is really taking things out of context in order to help justify a fairly tenuous assumption. I was part of the discussion that led to that study being shared, and it is a study of CPE within the JDM, which is quite different from the US market, both in equipment available, size and scope. It also does not consider whether this is the default config or whether the user purposely changed the address block being used, which I believe are significantly different issues. Because the policy authors insisted on making what is basically a global issue specific to the ARIN region, I don't think it's unreasonable to expect a study *from* the ARIN region as justification that this is anything more than a minor issue. As Joel says, this is a long-tail problem - you have the majority of devices using a certain part of 1918 due to their default config. The assertion that the presence of even one device with a default config using a particular part of 1918 space invalidates use of that space because of the support difficulties in getting that device reconfigured is being overly rigid in order to justify your chosen solution. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From Wesley.E.George at sprint.com Tue Feb 22 10:19:17 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 22 Feb 2011 15:19:17 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Tuesday, February 22, 2011 3:58 AM To: Joel Jaeggli Cc: ARIN-PPML List Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] What I expect will happen is that they will, instead, each seek large allocations from ARIN to support their NAT444 intermediary addresses and get them under current policies, thus accelerating IPv4 exhaustion. [WEG] We're going around in circles again. If they were able to justify this allocation, they would have already requested it (prior to IANA exhaust) in an effort to reduce or eliminate the need for NAT in the first place. The problem is that we're trying to insulate against something that may or may not happen based on expectation of future growth. Assuming that the same ISP already has enough addresses for their current customers, it is perfectly legitimate to expect them to transition some of those existing customers to CGN so that they have address space available for NAT pools, outside AND inside. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From dwing at cisco.com Tue Feb 22 11:00:37 2011 From: dwing at cisco.com (Dan Wing) Date: Tue, 22 Feb 2011 08:00:37 -0800 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> Message-ID: <14a601cbd2a9$a6d47ac0$f47d7040$@com> > -----Original Message----- > From: Chris Grundemann [mailto:cgrundemann at gmail.com] > Sent: Monday, February 21, 2011 8:17 PM > To: Dan Wing > Cc: Owen DeLong; Benson Schliesser; NANOG list; ARIN-PPML List > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > > > Its title, filename, abstract, and introduction all say the problems > > are specific to NAT444. ?Which is untrue. > > I just re-read the filename, abstract and introduction, and I disagree > that any of those say that the problems are specific to NAT444. They > all do state that these problems are present in NAT444, but not that > it's the only technology/scenario/configuration where you might find > them. > > More importantly, I am unsure the point of this argument. My point is that: NAT breaks things, but NAT444 is /not/ the only case where breakage occurs. > Are you > trying to say that the items listed as broken in the draft are not > actually broken? Because in my experience they are. IMHO, the fact > that they are also broken in other (similar) scenarios is not evidence > that they are not broken in this one. On the contrary, this scenario > seems to be evidence to the brokenness in the others (until we get a > chance to test and document them all - are you volunteering? ;). Vendor test results don't carry much value. The authors of draft-donley-nat444-impacts did testing, and I sincerely hope will publish results that split the impacts of access bandwidth starvation from home NAT from CGN from NAT444. -d > Cheers, > ~Chris > > > > -d > > > > > > > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org From bill at herrin.us Tue Feb 22 11:08:41 2011 From: bill at herrin.us (William Herrin) Date: Tue, 22 Feb 2011 11:08:41 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> Message-ID: On Tue, Feb 22, 2011 at 10:19 AM, George, Wes E [NTK] wrote: >> What I expect will happen is that they will, instead, each seek large allocations from ARIN to >> support their NAT444 intermediary addresses and get them under current policies, thus accelerating >> IPv4 exhaustion. > > [WEG] We're going around in circles again. If they were able to justify this allocation, they would > have already requested it (prior to IANA exhaust) in an effort to reduce or eliminate the need for > NAT in the first place. Wes, What makes you think they haven't? Have you looked at Verizon Wireless' holdings lately? I'd like to see those addresses come on the market. If they're tied up doing NAT444, they can't. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joelja at bogus.com Tue Feb 22 11:39:49 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 22 Feb 2011 08:39:49 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] Message-ID: How many parallel rfc 1918 adressing domains does vzw have? Hint, they have 100 million customers. The answer is around 40... That actually is an explict demonstration of the 4th option. William Herrin wrote: >On Tue, Feb 22, 2011 at 10:19 AM, George, Wes E [NTK] > wrote: >>> What I expect will happen is that they will, instead, each seek large allocations from ARIN to >>> support their NAT444 intermediary addresses and get them under current policies, thus accelerating >>> IPv4 exhaustion. >> >> [WEG] We're going around in circles again. If they were able to justify this allocation, they would >> have already requested it (prior to IANA exhaust) in an effort to reduce or eliminate the need for >> NAT in the first place. > >Wes, > >What makes you think they haven't? Have you looked at Verizon >Wireless' holdings lately? > >I'd like to see those addresses come on the market. If they're tied up >doing NAT444, they can't. > >-Bill > > >-- >William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >3005 Crane Dr. ...................... Web: >Falls Church, VA 22042-3004 > From alh-ietf at tndh.net Tue Feb 22 11:48:45 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 22 Feb 2011 08:48:45 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> Message-ID: <16dd01cbd2b0$613ac670$23b05350$@net> In isolation individual tiny incremental tweaks may seem harmless, but when viewed as a set the changes result in a drastic departure from the past. 133 in particular looks like it just sends those who have not signed the lrsa packing, but given the many times that John has specifically noted on this list that he views and promotes the ARIN whois database as a routing registry, removing those entries is effectively stating "we don't consider your use of the address blocks as legitimate, so we are removing them from the 'legitimate' route list". Call it consent of the self governed if you want, but the overall tone of this list has turned very isolationist and elitist, simultaneously refusing to recognize non-lrsa legacy while insisting that because those entities happened to have existed in the ARIN region that ARIN has exclusive rights to their resources. Removing them from the legitimate route list is the first step to declaring them fraudulent and available for reclamation and reassignment within 30 days. Is there a process within 131 for appeals? Of course not because that would preclude the mob from taking what it demands. I almost left 134 out because it seems to simply codify existing practice, but included it on principle that an unnecessary flurry of policy changes at the last minute is doing nothing to further the stewardship of the resource. My overall point was that redefining 'legitimate' to suite the whims of those who happen to be at the table at the moment is not stewardship, it is greed and hoarding. True stewardship requires a long term perspective, and the flurry of last minute policy modification proposals shows the perspective is anything but long term. Tony > -----Original Message----- > From: Benson Schliesser [mailto:bensons at queuefull.net] > Sent: Tuesday, February 22, 2011 12:45 AM > To: John Curran > Cc: Tony Hain; ARIN-PPML List > Subject: Re: [arin-ppml] Proposal insanity --- an open letter > > > On Feb 21, 2011, at 5:23 PM, John Curran wrote: > > > On Feb 22, 2011, at 6:52 AM, Tony Hain wrote: > > > >> 30,000 ft. summary of prop's 126, 129-131, 133-135 > >> ... > >> FWIW: opposed to all listed proposals > > > > Tony - > > > > Thanks for the thought-provoking input, as well as the > > succinct summary of opposition to all the listed proposals... > > The one surprising element is that several of the policy > > proposals you list express similar concerns to those that > > were alluded to in your soliloquy; are you certain that > > none of the policy proposals would improve the situation > > from your perspective? (I ask only because it is > > predominantly via the policy development process that > > changes in ARIN's address management practices occurs) > > Indeed, prop 133 (along with 134) is intended to address exactly the > notions Tony espoused. Specifically, it leads to a system of overt > consent by the governed - leaving non-consenters to find alternatives > of their own to ARIN's registry services. It's not clear to me how the > content of Tony's message leads to opposition to prop 133. > > Cheers, > -Benson From Wesley.E.George at sprint.com Tue Feb 22 11:54:05 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 22 Feb 2011 16:54:05 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E370F3C@PDAWM12B.ad.sprint.com> -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Tuesday, February 22, 2011 11:09 AM Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] On Tue, Feb 22, 2011 at 10:19 AM, George, Wes E [NTK] wrote: >> What I expect will happen is that they will, instead, each seek large >> allocations from ARIN to support their NAT444 intermediary addresses >> and get them under current policies, thus accelerating >> IPv4 exhaustion. > > [WEG] We're going around in circles again. If they were able to > justify this allocation, they would have already requested it (prior > to IANA exhaust) in an effort to reduce or eliminate the need for NAT in the first place. >Wes, >What makes you think they haven't? Have you looked at Verizon Wireless' holdings lately? [WEG] Well, let's refrain from calling out specific companies and making conjecture as to what they are or are not doing with their address resources unless you have facts to back up your accusations. However, generically you make a fair point that this is at least possible, and I never said otherwise. But this policy does nothing for anything already allocated unless it is changed to *require* use of the shared space for certain applications, thereby invalidating those as justification for even existing resources. I'm specifically responding to the recurring scare tactic that if $ISP doesn't get this shared space, they're going to go decimate the remaining RIR free pool with a big request. >I'd like to see those addresses come on the market. If they're tied up doing NAT444, they can't. [WEG] I think you're being overly optimistic if you believe that the simple presence of a /10 of shared space for NAT pool inside addresses is magically going to shake loose addresses on the open market, especially in the context of mobile networks which number their users in the multiple tens of millions (for whom a /10 isn't nearly enough space unless used multiple times). Also, people are fond of accusing carriers with large NAT implementations of using NAT as a crutch to continue doing IPv4 and delay IPv6. This discussion has been derailed several times on several lists by folks saying "I'm opposed because you shouldn't do NAT or anything that will delay IPv6 adoption." If you think about it, anything that generates a bunch of additional IPv4 address availability early in the exhaust cycle is actually MORE likely to cause this problem, because it potentially extends carriers' abilities to deploy real IPv4 service (no degradation due to NAT in the middle) by continuing to justify new allocations with BAU usage. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From jcurran at arin.net Tue Feb 22 12:04:23 2011 From: jcurran at arin.net (John Curran) Date: Tue, 22 Feb 2011 17:04:23 +0000 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <16dd01cbd2b0$613ac670$23b05350$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <16dd01cbd2b0$613ac670$23b05350$@net> Message-ID: <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> On Feb 23, 2011, at 12:48 AM, Tony Hain wrote: > ... given the many times that John has specifically noted on this > list that he views and promotes the ARIN whois database as a routing > registry, Tony - We go at length to point out that the ARIN Whois database is not routing registry and does not control routing (reference: NRPM 4.1.1), so please cite some of these "many times" or correct yourself asap. We run the ARIN Whois according to the community-developed policy, and it's quite possible that ISPs find it useful for configuration as a result, but ultimately ISPs decide what to route or not route on their own. /John John Curran President and CEO ARIN From mueller at syr.edu Tue Feb 22 12:12:13 2011 From: mueller at syr.edu (Milton L Mueller) Date: Tue, 22 Feb 2011 12:12:13 -0500 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <75822E125BCB994F8446858C4B19F0D7143AF29D7E@SUEX07-MBX-04.ad.syr.edu> Message-ID: <75822E125BCB994F8446858C4B19F0D714409798C6@SUEX07-MBX-04.ad.syr.edu> Thanks, Paul, for weighing in in support of my point. I am not sure I would call heavy reliance on NAT "pretty straightforward", but it does mean that operators can minimize or avoid NAT by acquiring more ipv4 blocks in the near-intermediate time frames. Hence the importance of transfers and other policies, such as the rationing one you mention, in the ipv4 space. So we are agreed, don't tell people we can ignore or stop talking about ipv4 address policies. > -----Original Message----- > From: Paul Wilson [mailto:pwilson at apnic.net] > Sent: Tuesday, February 22, 2011 12:01 AM > To: Milton L Mueller; arin-ppml at arin.net > Subject: Re: [arin-ppml] Proposal insanity --- an open letter > > I don't often post to PPML, but here goes. > > --On 21 February 2011 11:24:23 PM -0500 Milton L Mueller > > wrote: > > > ... > > Also, to say that ipv4 is "baked" and therefore we should stop talking > > about it or developing policies for it misses the crucial fact that no > > one can jump to pure ipv6 without cutting themselves off from most of the > > internet. "Implementing ipv6" in reality means "implementing dual stack" > > - now and for the next ten years at least. How do you do dual stack > > without any ipv4, do tell? > > First: In this context, "dual stack" is defined as including IPv4, of > course. And the IPv4 addresses which are used can be public or private, of > course. > > Milton, I guess you understand private addressing and NATs. Dual stack > during the transition will involve mostly private IPv4 addresses, and NAT > of various kinds between those private addresses and the public; along with > public IPv6 addresses of course. The more that this NATing goes on, as the > Internet grows, the less efficient that IPv4-based connectivity will > become, to the point of being less preferred than IPv6. At the same time, > IPv6 connectivity steadily improves in terms of services accessible, > routing efficiency, and general reliability; starting with today's > relatively meagre coverage, until it is preferred, first in some, then in > most, and then in all, places. > > As for the public addresses needed by ISPs for their gateway into the IPv4 > Internet, some RIRs already have a policy which will make this available in > the long term, effectively rationing some proportion of their remaining > IPv4 address pools. APNIC has such a policy in place, currently reserving > most of a /8 for allocations in /22 blocks; and this supply of addresses is > projected to last for many years, beyond the point where they are actually > needed. > > That's the model in a nutshell. Crack away at it by all means, but it is > pretty straightforward. > > Paul Wilson > APNIC > > > __________________________________________________________ > ______________ > Paul Wilson, Director-General, APNIC > http://www.apnic.net +61 7 3858 3100 > > From owen at delong.com Tue Feb 22 13:08:10 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 10:08:10 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> Message-ID: <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> On Feb 22, 2011, at 7:19 AM, George, Wes E [NTK] wrote: > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong > Sent: Tuesday, February 22, 2011 3:58 AM > To: Joel Jaeggli > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address > Extension] > > What I expect will happen is that they will, instead, each seek large allocations from ARIN to > support their NAT444 intermediary addresses and get them under current policies, thus accelerating > IPv4 exhaustion. > > [WEG] We're going around in circles again. If they were able to justify this allocation, they would > have already requested it (prior to IANA exhaust) in an effort to reduce or eliminate the need for > NAT in the first place. The problem is that we're trying to insulate against something that may or > may not happen based on expectation of future growth. Assuming that the same ISP already has enough > addresses for their current customers, it is perfectly legitimate to expect them to transition some > of those existing customers to CGN so that they have address space available for NAT pools, outside > AND inside. > > Wes George Your logic here is flawed. It's entirely possible that they would first attempt to do the right thing and request a shared block through the policy process falling back to these requests while they are still possible, but, after exhausting the policy option. You criticize them from bringing a study that is not ARIN-specific to the ARIN region for what is a global issue, but, they tried to address this globally and it failed to achieve resolution. Owen From owen at delong.com Tue Feb 22 13:12:50 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 10:12:50 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: Message-ID: <97409F22-7524-433B-A952-99EFA53C08AA@delong.com> No, it really isn't. Their 40 parallel RFC-1918 addressing domains are all under their control and can easily be coordinated by VZW. You're option 4 expands that to 100 million parallel addressing domains not managed by VZW + 40 that are + some additional number that are, but, by definition likely overlap the existing 40. Owen On Feb 22, 2011, at 8:39 AM, Joel Jaeggli wrote: > How many parallel rfc 1918 adressing domains does vzw have? Hint, they have 100 million customers. The answer is around 40... That actually is an explict demonstration of the 4th option. > > William Herrin wrote: > >> On Tue, Feb 22, 2011 at 10:19 AM, George, Wes E [NTK] >> wrote: >>>> What I expect will happen is that they will, instead, each seek large allocations from ARIN to >>>> support their NAT444 intermediary addresses and get them under current policies, thus accelerating >>>> IPv4 exhaustion. >>> >>> [WEG] We're going around in circles again. If they were able to justify this allocation, they would >>> have already requested it (prior to IANA exhaust) in an effort to reduce or eliminate the need for >>> NAT in the first place. >> >> Wes, >> >> What makes you think they haven't? Have you looked at Verizon >> Wireless' holdings lately? >> >> I'd like to see those addresses come on the market. If they're tied up >> doing NAT444, they can't. >> >> -Bill >> >> >> -- >> 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 Tue Feb 22 13:18:09 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 10:18:09 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <16dd01cbd2b0$613ac670$23b05350$@net> <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> Message-ID: <61E7ECF8-7690-4FAE-A79F-06ABDA3D9AED@delong.com> http://www.theipv6experts.net/2011/cooperation-remains-key-future-internetworking/ Owen On Feb 22, 2011, at 9:04 AM, John Curran wrote: > On Feb 23, 2011, at 12:48 AM, Tony Hain wrote: >> ... given the many times that John has specifically noted on this >> list that he views and promotes the ARIN whois database as a routing >> registry, > > Tony - > > We go at length to point out that the ARIN Whois database is not > routing registry and does not control routing (reference: NRPM 4.1.1), > so please cite some of these "many times" or correct yourself asap. > > We run the ARIN Whois according to the community-developed policy, > and it's quite possible that ISPs find it useful for configuration > as a result, but ultimately ISPs decide what to route or not route > on their own. > > /John > > John Curran > President and CEO > ARIN > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From joelja at bogus.com Tue Feb 22 13:28:54 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 22 Feb 2011 10:28:54 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] Message-ID: You don't have a mifi, a 3g router, or a handset with tethering do you. They may not have to problem to the same scale as a some existing providers but to pretend that there aren't cpe nats is is error. Owen DeLong wrote: >No, it really isn't. > >Their 40 parallel RFC-1918 addressing domains are all under their control and >can easily be coordinated by VZW. > >You're option 4 expands that to 100 million parallel addressing domains not >managed by VZW + 40 that are + some additional number that are, but, by >definition likely overlap the existing 40. > >Owen > >On Feb 22, 2011, at 8:39 AM, Joel Jaeggli wrote: > >> How many parallel rfc 1918 adressing domains does vzw have? Hint, they have 100 million customers. The answer is around 40... That actually is an explict demonstration of the 4th option. >> >> William Herrin wrote: >> >>> On Tue, Feb 22, 2011 at 10:19 AM, George, Wes E [NTK] >>> wrote: >>>>> What I expect will happen is that they will, instead, each seek large allocations from ARIN to >>>>> support their NAT444 intermediary addresses and get them under current policies, thus accelerating >>>>> IPv4 exhaustion. >>>> >>>> [WEG] We're going around in circles again. If they were able to justify this allocation, they would >>>> have already requested it (prior to IANA exhaust) in an effort to reduce or eliminate the need for >>>> NAT in the first place. >>> >>> Wes, >>> >>> What makes you think they haven't? Have you looked at Verizon >>> Wireless' holdings lately? >>> >>> I'd like to see those addresses come on the market. If they're tied up >>> doing NAT444, they can't. >>> >>> -Bill >>> >>> >>> -- >>> 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 Tue Feb 22 13:42:33 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 10:42:33 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: Message-ID: Huh? I'm not pretending that there aren't CPE NATs. If anything, yours is the position that fails to recognize the meaning and result of CPE NATs. If you're talking about the fact that these exist in the VZW world, yes, I'm aware of that, but, each of those units was: 1. Preconfigured by VZW 2. Deployed in an environment where the expected external address is RFC-1918 and this was coordinated up front. That's a very different scenario from an ISP that needs to deploy another layer of NAT onto an existing subscriber infrastructure where their current expected external addresses are not RFC-1918 and there was no provider input or coordination into the CPE interior addressing scheme(s). Owen On Feb 22, 2011, at 10:28 AM, Joel Jaeggli wrote: > You don't have a mifi, a 3g router, or a handset with tethering do you. They may not have to problem to the same scale as a some existing providers but to pretend that there aren't cpe nats is is error. > > Owen DeLong wrote: > >> No, it really isn't. >> >> Their 40 parallel RFC-1918 addressing domains are all under their control and >> can easily be coordinated by VZW. >> >> You're option 4 expands that to 100 million parallel addressing domains not >> managed by VZW + 40 that are + some additional number that are, but, by >> definition likely overlap the existing 40. >> >> Owen >> >> On Feb 22, 2011, at 8:39 AM, Joel Jaeggli wrote: >> >>> How many parallel rfc 1918 adressing domains does vzw have? Hint, they have 100 million customers. The answer is around 40... That actually is an explict demonstration of the 4th option. >>> >>> William Herrin wrote: >>> >>>> On Tue, Feb 22, 2011 at 10:19 AM, George, Wes E [NTK] >>>> wrote: >>>>>> What I expect will happen is that they will, instead, each seek large allocations from ARIN to >>>>>> support their NAT444 intermediary addresses and get them under current policies, thus accelerating >>>>>> IPv4 exhaustion. >>>>> >>>>> [WEG] We're going around in circles again. If they were able to justify this allocation, they would >>>>> have already requested it (prior to IANA exhaust) in an effort to reduce or eliminate the need for >>>>> NAT in the first place. >>>> >>>> Wes, >>>> >>>> What makes you think they haven't? Have you looked at Verizon >>>> Wireless' holdings lately? >>>> >>>> I'd like to see those addresses come on the market. If they're tied up >>>> doing NAT444, they can't. >>>> >>>> -Bill >>>> >>>> >>>> -- >>>> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >>>> 3005 Crane Dr. ...................... Web: >>>> Falls Church, VA 22042-3004 >>>> >> >> From alh-ietf at tndh.net Tue Feb 22 14:18:17 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 22 Feb 2011 11:18:17 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <16dd01cbd2b0$613ac670$23b05350$@net> <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> Message-ID: <173301cbd2c5$4ad870c0$e0895240$@net> John Curran wrote: > On Feb 23, 2011, at 12:48 AM, Tony Hain wrote: > > ... given the many times that John has specifically noted on this > > list that he views and promotes the ARIN whois database as a routing > > registry, > > Tony - > > We go at length to point out that the ARIN Whois database is not > routing registry and does not control routing (reference: NRPM 4.1.1), > so please cite some of these "many times" or correct yourself asap. > > We run the ARIN Whois according to the community-developed policy, > and it's quite possible that ISPs find it useful for configuration > as a result, but ultimately ISPs decide what to route or not route > on their own. > This note is a prime example. Rather than simply and clearly stating that the ARIN whois database is not and "MUST NOT BE USED FOR A ROUTING REGISTRY", there is a backhanded promotion that we recognize the 'presumably smart people' use it as one because it is constructed with exactly the data they have told us to put in for that use. The implication being that if you don't use it as one you are not part of the 'smart' group because all the data is there and ready to go. So it becomes the defacto registry. If it is a defacto routing registry, then policy proposals need to recognize the implications of that. Continuing the two-faced 'we say nothing about routing' while at the same time all policy proposals are judged by 'the impact on routing will be ...' is not helping promote the perception that the RIRs are independent. Playing the 'we tell you it isn't a registry' while simultaneously recognizing it is 'the defacto routing registry for the region' is not helping either. At the end of the day, the inherent conflict of interest between 'those that have and want to keep others out, and those that want in' has been placed squarely in ARIN's lap. While resources were abundant it was not too hard to get community agreement on who would be denied a seat at the table, though arguably there probably was never a valid reason to have a minimum size allocation. While I can hear the screams about routing table size, the intentional deaggregation by those who got the resources exposes the fallacy in the argument. In any case, ARIN is in the position where 'legally' there has to be a disconnect between resource management and operational practice, but 'practically' they are tied at the hip because the members who pay the most insist on getting the results that favor them. Tony > /John > > John Curran > President and CEO > ARIN > From jcurran at arin.net Tue Feb 22 14:36:17 2011 From: jcurran at arin.net (John Curran) Date: Tue, 22 Feb 2011 19:36:17 +0000 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <173301cbd2c5$4ad870c0$e0895240$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <16dd01cbd2b0$613ac670$23b05350$@net> <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> <173301cbd2c5$4ad870c0$e0895240$@net> Message-ID: <45034E1B-E546-4282-852D-322A1797BC6C@arin.net> On Feb 23, 2011, at 3:18 AM, Tony Hain wrote: > > If it is a defacto routing registry, then policy proposals need to recognize > the implications of that. Continuing the two-faced 'we say nothing about > routing' while at the same time all policy proposals are judged by 'the > impact on routing will be ...' is not helping promote the perception that > the RIRs are independent. Playing the 'we tell you it isn't a registry' > while simultaneously recognizing it is 'the defacto routing registry for the > region' is not helping either. Tony - Some ISPs pay attention to what is registered in Whois and some don't. Some also pay attention to actual routing registries and some don't. Some filter out bogon routes and/or traffic, and some don't. Some do a form of RPF for routing protection, and some don't... This is just reality. Shortly, we'll be able to add "Some do route preferences based on the RPKI, and some don't". Welcome to the private-sector led Internet operational model. > At the end of the day, the inherent conflict of interest between 'those that > have and want to keep others out, and those that want in' has been placed > squarely in ARIN's lap. While resources were abundant it was not too hard to > get community agreement on who would be denied a seat at the table, though > arguably there probably was never a valid reason to have a minimum size > allocation. While I can hear the screams about routing table size, the > intentional deaggregation by those who got the resources exposes the fallacy > in the argument. In any case, ARIN is in the position where 'legally' there > has to be a disconnect between resource management and operational practice, > but 'practically' they are tied at the hip because the members who pay the > most insist on getting the results that favor them. "The members who pay the most?" Actually, the largest ARIN members have the same voice as the smallest in the policy development process and the Board & AC elections. In fact, the policy development is open to anyone with an interest in the policies in this region, via PPML and both onsite and remote during the Public Policy Meeting. This is a process that favors quantity of folks with similar beliefs, not size. /John John Curran President and CEO ARIN From kkargel at polartel.com Tue Feb 22 14:34:54 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Tue, 22 Feb 2011 13:34:54 -0600 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <173301cbd2c5$4ad870c0$e0895240$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <16dd01cbd2b0$613ac670$23b05350$@net> <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> <173301cbd2c5$4ad870c0$e0895240$@net> Message-ID: <8695009A81378E48879980039EEDAD288C048DC1@MAIL1.polartel.local> To my understanding ARIN is an IP registry. Nothing more and nothing less. If we want ARIN to become a routing (or any other standards) authority I would think we need to make some adjustments to the mission statement at the very least. Then comes the problem of getting the world to recognize ARIN as a routing authority. I don't think that's as simple as announcing "because we say so". If you want ARIN records to be authoritative for routing perhaps the proper venue for enacting that would be the IETF and changes to the various routing protocol RFC's. IMHO one of the best ways to get people to stop taking ARIN seriously will be to get too big for our britches and start trying to make unenforceable rules in areas where we have no authority. I am sure wiser people than myself will chime in and let me know where my thinking is flawed. Kevin > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Tony Hain > Sent: Tuesday, February 22, 2011 1:18 PM > To: 'John Curran' > Cc: 'ARIN-PPML List' > Subject: Re: [arin-ppml] Proposal insanity --- an open letter > > John Curran wrote: > > On Feb 23, 2011, at 12:48 AM, Tony Hain wrote: > > > ... given the many times that John has specifically noted on this > > > list that he views and promotes the ARIN whois database as a routing > > > registry, > > > > Tony - > > > > We go at length to point out that the ARIN Whois database is not > > routing registry and does not control routing (reference: NRPM 4.1.1), > > so please cite some of these "many times" or correct yourself asap. > > > > We run the ARIN Whois according to the community-developed policy, > > and it's quite possible that ISPs find it useful for configuration > > as a result, but ultimately ISPs decide what to route or not route > > on their own. > > > > This note is a prime example. Rather than simply and clearly stating that > the ARIN whois database is not and "MUST NOT BE USED FOR A ROUTING > REGISTRY", there is a backhanded promotion that we recognize the > 'presumably > smart people' use it as one because it is constructed with exactly the > data > they have told us to put in for that use. The implication being that if > you > don't use it as one you are not part of the 'smart' group because all the > data is there and ready to go. So it becomes the defacto registry. > > If it is a defacto routing registry, then policy proposals need to > recognize > the implications of that. Continuing the two-faced 'we say nothing about > routing' while at the same time all policy proposals are judged by 'the > impact on routing will be ...' is not helping promote the perception that > the RIRs are independent. Playing the 'we tell you it isn't a registry' > while simultaneously recognizing it is 'the defacto routing registry for > the > region' is not helping either. > > At the end of the day, the inherent conflict of interest between 'those > that > have and want to keep others out, and those that want in' has been placed > squarely in ARIN's lap. While resources were abundant it was not too hard > to > get community agreement on who would be denied a seat at the table, though > arguably there probably was never a valid reason to have a minimum size > allocation. While I can hear the screams about routing table size, the > intentional deaggregation by those who got the resources exposes the > fallacy > in the argument. In any case, ARIN is in the position where 'legally' > there > has to be a disconnect between resource management and operational > practice, > but 'practically' they are tied at the hip because the members who pay the > most insist on getting the results that favor them. > > Tony > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bensons at queuefull.net Tue Feb 22 15:10:01 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 14:10:01 -0600 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> Message-ID: <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> On Feb 22, 2011, at 3:13 AM, Owen DeLong wrote: > On Feb 21, 2011, at 9:00 PM, Matthew Petach wrote: >> To clarify, as I've gotten some questions about my stance; >> those addresses which were allocated by IANA to ARIN for >> the region, I believe should stay within the region. >> >> Address blocks *not* allocated by IANA to ARIN, namely >> address blocks assigned to "legacy" holders should be returned >> whence they came, if they are freed up, namely to IANA, as those >> never passed through ARIN's hands in the first place. >> > Most blocks you describe were not allocated by IANA to their > current holders, but, rather by ARIN's predecessors, the SRI > Internic and the NSI Internic, neither of which exists for those > blocks to be returned to. > > Care to clarify your stance in light of those facts? I can't speak for Matthew. But my understanding is: ARIN's Internic "predecessors"* were contracted by the US Govt to perform the IANA function, and ICANN is currently contracted by the US Govt to perform the IANA function. As such, returning legacy addresses to the IANA/ICANN seems to make sense unless IANA/ICANN would prefer otherwise. Cheers, -Benson * - To my knowledge, while ARIN made it possible for NSF to release NSI from their IANA responsibilities, the contract was not novated to ARIN and ARIN has never held a contract for the IANA function. If my understanding is incorrect, I would appreciate pointers to correct background. If my understanding is correct, then claims that ARIN is the "successor" are fairly hollow. From jcurran at arin.net Tue Feb 22 15:46:00 2011 From: jcurran at arin.net (John Curran) Date: Tue, 22 Feb 2011 20:46:00 +0000 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> Message-ID: <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> On Feb 23, 2011, at 4:10 AM, Benson Schliesser wrote: > I can't speak for Matthew. But my understanding is: ARIN's Internic "predecessors"* were contracted by the US Govt to perform the IANA function, and ICANN is currently contracted by the US Govt to perform the IANA function. As such, returning legacy addresses to the IANA/ICANN seems to make sense unless IANA/ICANN would prefer otherwise. The InterNIC registry function, including personal, systems and records were transferred by NSI to ARIN at ARIN's inception. ARIN is operates the registry in question. > * - To my knowledge, while ARIN made it possible for NSF to release NSI from their IANA responsibilities, the contract was not novated to ARIN and ARIN has never held a contract for the IANA function. If my understanding is incorrect, I would appreciate pointers to correct background. If my understanding is correct, then claims that ARIN is the "successor" are fairly hollow. No contract is needed, anymore than RIPE NCC or APNIC needing a contract, nor LACNIC and AfriNIC needing one on their formation. Collectively, the RIRs participate jointly as the NRO in ICANN, serving as the ASO (Address Supporting Organization). This is covered in the ASO and NRO MOU's with ICANN. In each case, the registrations which from that region prior to the RIR formation ("legacy registrations") where transferred under that RIR. This shouldn't be surprising given the non-for-profit, non-overlapping service regions. That's not to say that address space can't be returned to IANA or ARIN as the community decides and in compliance with ARIN's mission. IANA has indicated their ability to provide stewardship for number resources even prior to any global policy providing for reallocation, so there is no difficultly there. FYI, /John John Curran President and CEO ARIN From mpetach at netflight.com Tue Feb 22 16:06:51 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 22 Feb 2011 13:06:51 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> Message-ID: On Tue, Feb 22, 2011 at 1:13 AM, Owen DeLong wrote: > > On Feb 21, 2011, at 9:00 PM, Matthew Petach wrote: > >> On Sun, Feb 20, 2011 at 6:42 PM, Matthew Petach wrote: >>> On Sat, Feb 19, 2011 at 6:02 PM, John Curran wrote: >>>> Correct. ?Make the intent of the policy clear and unambiguous. ?I believe the AC is working on that presently. >>>> >>>> /John >>> >>> I'd like to raise my voice in SUPPORT of the policy proposal to render explicit >>> the set of IPv4 addresses being returned to IANA as "{}". >>> >>> Matt >> >> To clarify, as I've gotten some questions about my stance; >> those addresses which were allocated by IANA to ARIN for >> the region, I believe should stay within the region. >> >> Address blocks *not* allocated by IANA to ARIN, namely >> address blocks assigned to "legacy" holders should be returned >> whence they came, if they are freed up, namely to IANA, as those >> never passed through ARIN's hands in the first place. >> > Most blocks you describe were not allocated by IANA to their > current holders, but, rather by ARIN's predecessors, the SRI > Internic and the NSI Internic, neither of which exists for those > blocks to be returned to. > > Care to clarify your stance in light of those facts? > > Owen SRI Internic and NSI Internic were both global organizations, not regional, correct? In that sense, they filled a similar role as IANA, serving as a global allocation point, rather than a regional allocation point. Fundamentally, I think if resources were allocated from the global pool to a regional registry, they become the responsibility of that region. If they were assigned from the global pool directly to an entity, upon return, they should go back into the global pool. Seems pretty straightforward that way. Matt From mpetach at netflight.com Tue Feb 22 16:16:14 2011 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 22 Feb 2011 13:16:14 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> Message-ID: On Tue, Feb 22, 2011 at 12:46 PM, John Curran wrote: ... > In each case, the registrations which from that region prior to > the RIR formation ("legacy registrations") where transferred > under that RIR. If that's truly the case, that the registrations were actually transferred to be under the control of the RIR as part of the transition, then isn't the whole RSA/LRSA/non-signing legacyholder debate totally moot? If their address blocks really *were* transferred under ARIN, explicitly, as part of the formation of the RIR, then they fall under the policies and auspices of that RIR. However, currently we're treating them as though they're outside the RIR system, where policies don't apply to them, they don't have to pay for resources the same way, and don't have to sign the same agreement documents. To me, that says that their resources were *NOT* transferred under the RIR at the time of the transition, and instead fall under some other global umbrella. So. Once and for all, can we please have it stated clearly, and for the record: Under whose auspices do the current legacy holders hold their space? Under whose stewardship do those blocks exist? If they were assigned under SRI or NSI, did they transfer to ARIN at the time of the RIR creation, or did they revert back to the parent of SRI/NSI, which at this point would be IANA? Once we know the authoritative answer to that question, I think my stance on the matter will become abundantly clear. Thanks! Matt From jcurran at arin.net Tue Feb 22 16:18:42 2011 From: jcurran at arin.net (John Curran) Date: Tue, 22 Feb 2011 21:18:42 +0000 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> Message-ID: <83374D77-392F-41D4-BFF7-CEAE30CC8230@corp.arin.net> On Feb 23, 2011, at 5:06 AM, Matthew Petach wrote: > SRI Internic and NSI Internic were both global organizations, not > regional, correct? Not correct, as with successive formation of RIPE NCC and APNIC, their service area was correspondingly reduced for managing ISP and end-user allocations. They did provide some global services such as in-addr.arpa zone generation for the entire address space (as did ARIN for the last 12 years...) Again, this shouldn't preclude any particular return policy that people want, it's just that the history of the evolution of the number registry system doesn't match a lot of expectations. /John John Curran President and CEO ARIN From jcurran at arin.net Tue Feb 22 16:52:41 2011 From: jcurran at arin.net (John Curran) Date: Tue, 22 Feb 2011 21:52:41 +0000 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> Message-ID: <591196A0-57B3-4494-952F-798918D2F711@corp.arin.net> On Feb 23, 2011, at 5:16 AM, Matthew Petach wrote: > On Tue, Feb 22, 2011 at 12:46 PM, John Curran wrote: > ... >> In each case, the registrations which from that region prior to >> the RIR formation ("legacy registrations") where transferred >> under that RIR. > > If that's truly the case, that the registrations were actually > transferred to be under the control of the RIR as part of the > transition, then isn't the whole RSA/LRSA/non-signing > legacyholder debate totally moot? If their address blocks > really *were* transferred under ARIN, explicitly, as part of > the formation of the RIR, then they fall under the policies > and auspices of that RIR. In the case of the other regions, we're talking about dozens or hundreds of "historic" allocations. In the case of ARIN, it was more than ten thousand. > However, currently we're treating them as though they're > outside the RIR system, where policies don't apply to them, > they don't have to pay for resources the same way, and > don't have to sign the same agreement documents. To me, > that says that their resources were *NOT* transferred under > the RIR at the time of the transition, and instead fall under > some other global umbrella. At ARIN's formation, we indicated that we'd maintain the existing base of registrations in the region. At the time, there was no push to bring the thousands of assignments under an RSA, as it was felt that ARIN could be well supported by the active and growing ISP community. We have basically maintained that status quo ever since, adding the option of the LRSA for those who want a formal contractual basis for the registry services. > So. Once and for all, can we please have it stated clearly, > and for the record: > > Under whose auspices do the current legacy holders hold > their space? Under whose stewardship do those blocks > exist? If they were assigned under SRI or NSI, did they > transfer to ARIN at the time of the RIR creation, or did > they revert back to the parent of SRI/NSI, which at this > point would be IANA? They transferred to ARIN at the time of the RIR creation. ARIN's original service region was "rest of world" (all of the registrations not managed by RIPE NCC and APNIC). There's even an old logo for ARIN which had that as its geographic outline (pre-LACNIC and AfriNIC formation) When those new RIRs formed, we again transferred the registrations, only the vast majority of them were post ARIN formation and had a standard RSA which was assigned when the service regions changed. > Once we know the authoritative answer to that question, > I think my stance on the matter will become abundantly > clear. Hope this helps, /John John Curran President and CEO ARIN From bensons at queuefull.net Tue Feb 22 17:08:23 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 16:08:23 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <34623.1298411682@localhost> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> <34623.1298411682@localhost> Message-ID: On Feb 22, 2011, at 3:54 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: >> There seems to be a position, taken by others on these lists, that IPv6 >> is the only address family that matters. Interestingly, this position >> seems to be most pronounced from people not involved in operating >> production networks. > > "most pronounced from people not involved in operating production networks > that are way behind the planning curve for IPv6 deployment". > > There, fixed that for you. My original text remains true, because I tend to hear IPv6-only advocacy from vendors and policy folks more than operators - even more so versus operators of commercial ISP networks. But I take your point, that operators ahead of the IPv6 deployment curve are most likely to stand up with that opinion. Of course, the "network effect" being what it is... Your network being 100% IPv6 doesn't solve the overall problem of reachability. I think your example of 4% traffic from VT is applicable - you will have to worry about IPv4 connectivity, in one form or another, until it diminishes significantly. It's a bit like a tragedy of the commons. Cheers, -Benson From jcurran at arin.net Tue Feb 22 17:11:18 2011 From: jcurran at arin.net (John Curran) Date: Tue, 22 Feb 2011 22:11:18 +0000 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <055d01cbd2db$e7ea8bd0$b7bfa370$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <16dd01cbd2b0$613ac670$23b05350$@net> <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> <055d01cbd2db$e7ea8bd0$b7bfa370$@net> Message-ID: On Feb 23, 2011, at 6:00 AM, Warren Johnson wrote: > Jon, > > That's all well and good in theory but I think we all know that being removed from the whois database and reassigned by ARIN will take down an organization. It's not what ARIN has built, rather it's the result of a community that regards ARIN as the authority and we govern based on that mutual consensus. Like it or not, ARIN is in that position and has no realistic choice but to govern from that ground. Warren - Full agreement; this is why the policy process is so important. It was simply necessary to be clear for Mr. Hain that ARIN does not control routing; the community hopefully participates in the policy development process, and may make use of registry because we manage it as directed, but that's not the same as directing the configuration of ISPs routers... /John John Curran President and CEO ARIN From bensons at queuefull.net Tue Feb 22 17:16:11 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 16:16:11 -0600 Subject: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...) In-Reply-To: <7277A6F9-C21C-4EF0-8220-A3F3A707A836@delong.com> References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <4D52E942.5000607@ispalliance.net> <86lj1ohie8.fsf@seastrom.com> <4D532AEA.2090505@brightok.net> <4D5409F4.4070907@brightok.net> <837D4625-3E75-4664-A68A-ED3427AD9831@delong.com> <4C060A07-4FA7-467B-8BA8-8D4D04A0BA9A@queuefull.net> <117f01cbd207$34f42290$9edc67b0$@com> <41EE506B-D6BA-4AB5-A211-41BFE114F70E@delong.com> <132601cbd235$69298720$3b7c9560$@com> <41DC9C32-7902-459E-A4FA-8A70EED53AB4@queuefull.net> <7277A6F9-C21C-4EF0-8220-A3F3A707A836@delong.com> Message-ID: <31BBAC11-53B0-49A9-80AA-94AE1CD9BDF3@queuefull.net> On Feb 22, 2011, at 3:40 AM, Owen DeLong wrote: >> There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. >> > I don't think anyone has said that IPv6 is the only address family > that matters. What I think people, myself included, have been saying > is that IPv6 is the only way forward that does not involve many of these > problems. (See my earlier Titanic post). I agree completely: IPv6 is the only way forward that avoids these problems. In fact, an understanding of CGN impacts should be enough motivation for operators and users to start deploying IPv6 immediately. > As to whether or not it matters that people misinterpred draft-donly..., > I'm not sure whether it actually does or not. There is no flavor of NAT > that is particularly desirable. It's a matter of choosing the one that is > least damaging to your environment where least damage may > boil down to a choice between 5% and 3% remaining functionality. I agree with your sentiment, that we should choose the least damaging solutions. Call it the "lesser evil" if you'd like. However, I think your estimates (5% vs 3%) are backwards. CGN-based solutions work for the vast majority of network traffic today - it's the stuff in the margin that breaks, according to all test reports I've seen. > I don't think anyone is saying IPv4 no longer matters. I think we are > saying that effort spent attempting to make the deteriorating IPv4 > situation deteriorate less is both futile and better spent on making > the IPv6 deployment situation better. It's not an exclusive situation - we can roll out IPv6 while continuing to maintain our existing IPv4 connectivity, support new customers with IPv4 needs, etc. As I mentioned before, we have to support the bridge we're crossing (crumbling IPv4 infrastructure) until we're on the other side (fertile IPv6 farmland). >> Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. >> > Only if you expect that you can rely on a supply side in such a market. > I am unconvinced that such will be reliable, especially after about 6 > months of trading. This also presumes that more sensitive users can > be defined in terms of what those users are willing (or able) to pay. This is an interesting discussion, because the timeframe is central to everything I've commented above. Considering RIR exhaustion (4-12 months) plus ISP exhaustion (TBD, but let's say anywhere from 1 month to 5+ years after RIR exhaustion), I expect some network providers to struggle with IPv4 address exhaustion before the 3rd quarter of 2011. On the other hand, other network providers will have enough resources to last for years - let's call that "excess supply". By all realistic estimates, any network provider that hasn't deployed IPv6 support into their infrastructure will need anywhere from 3 months to 3 years or more - let's generously say around 18 months to the point where 60% - 80% of hosts have reached IPv6 connectivity. Just considering these facts, I think we can see why some ISPs might be interested in acquiring more addresses through 2012. And those with excess supply might be motivated (financially) by a marketplace to share their resources, to meet this need. Further, let's consider that some network services (such as content / hosting) will need IPv4 connectivity longer than others, in order to reach the long-tail. For this category, I can see why some networks might be interested in acquiring more addresses through 2013 - 2016. Fortunately, on the other side of 2012 prices should decrease because supply goes up (as some people give up IPv4). Thus the market value of an address probably can be represented by a curve peaking in a couple years and then declining to zero a few years after that. Feedback on this would be appreciated - but my current belief is that it's realistic to plan for a couple years of trading rather than "about 6 months". (Side note: If we really wanted people to move to IPv6 before now, we should have instituted increasing prices for RIR-provided addresses. I posit that we just didn't have the collective balls to do this.) Cheers, -Benson From bensons at queuefull.net Tue Feb 22 17:48:44 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Tue, 22 Feb 2011 16:48:44 -0600 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> Message-ID: <0235341E-7E46-4B26-8FAB-F8A063932148@queuefull.net> On Feb 22, 2011, at 2:46 PM, John Curran wrote: > On Feb 23, 2011, at 4:10 AM, Benson Schliesser wrote: > >> I can't speak for Matthew. But my understanding is: ARIN's Internic "predecessors"* were contracted by the US Govt to perform the IANA function, and ICANN is currently contracted by the US Govt to perform the IANA function. As such, returning legacy addresses to the IANA/ICANN seems to make sense unless IANA/ICANN would prefer otherwise. > > The InterNIC registry function, including personal, systems > and records were transferred by NSI to ARIN at ARIN's inception. > ARIN is operates the registry in question. This may be true, but it doesn't address the question of IANA. Even if ARIN was acting as the "successor registry" for global address allocation during the period prior to ICANN, the US Govt clearly chose to recognize ICANN as the IANA. The IANA contract with ICANN explicitly includes oversight of address allocations. Delegation of registry responsibilities doesn't change that situation. >> * - To my knowledge, while ARIN made it possible for NSF to release NSI from their IANA responsibilities, the contract was not novated to ARIN and ARIN has never held a contract for the IANA function. If my understanding is incorrect, I would appreciate pointers to correct background. If my understanding is correct, then claims that ARIN is the "successor" are fairly hollow. > > No contract is needed, anymore than RIPE NCC or APNIC needing a > contract, nor LACNIC and AfriNIC needing one on their formation. I agree. Each RIR represents a constituency, and in as much as this is true each RIR also has authority inherent to the consent of the governed. > Collectively, the RIRs participate jointly as the NRO in ICANN, > serving as the ASO (Address Supporting Organization). This is > covered in the ASO and NRO MOU's with ICANN. (Understood - thanks also for the background you provided in your previous message on this topic.) Through contract with NTIA/DoC, ICANN has been delegated a governmental responsibility which we call the IANA. The acronym literally includes the word "authority", so I'll posit that IANA has the US Government's delegated authority*. However, each RIR represents a constituency as I've outlined above. My view is that constituency and authority meet at the NRO-ASO interface, and I think this is an elegant system.** However, the recognition of ASO-NRO by ICANN does not diminish the role and responsibility of IANA. > In each case, the > registrations which from that region prior to the RIR formation > ("legacy registrations") where transferred under that RIR. This > shouldn't be surprising given the non-for-profit, non-overlapping > service regions. This is a fair argument, but it's one that needs to be formalized. As Matthew pointed out in a parallel message, the historical distinction of legacy holders doesn't seem to reinforce their inclusion in ARIN's constituency. And while it might never have mattered before, it does matter now that IPv4 addresses are a scarce resource - because people may be motivated to behave differently now, and legacy holders may wish to act outside the regulation of ARIN policy. To this end, I think IANA should be called upon to clarify the relationship of legacy holders. Until this is done, I think the most responsible approach for ARIN to take is deference to IANA on legacy resource issues. > That's not to say that address space can't be returned to IANA or > ARIN as the community decides and in compliance with ARIN's mission. > IANA has indicated their ability to provide stewardship for number > resources even prior to any global policy providing for reallocation, > so there is no difficultly there. I agree with your statement - in fact, I was encouraged by you previously to get involved in this policy discussion. For what it's worth, I think that whatever we come up with (i.e. whether ARIN has legacy authority or IANA does), we should advocate for an international system that allows address resources to reach those that need them without minimizing the freedom of constituents. Cheers, -Benson * - International authority is more complex, and I cannot even pretend to know how we can improve that situation... without taking a big step backwards. ** - I would like to see ICANN ASO/NRO be more democratic than it currently is, but that's a separate criticism. From alh-ietf at tndh.net Tue Feb 22 17:49:25 2011 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 22 Feb 2011 14:49:25 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: References: <15dc01cbd219$fe9c69b0$fbd53d10$@net> <9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net> <16dd01cbd2b0$613ac670$23b05350$@net> <891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net> <055d01cbd2db$e7ea8bd0$b7bfa370$@net> Message-ID: <179c01cbd2e2$c3432330$49c96990$@net> John, I never said ARIN directed the configuration of ISP routers. The point of a routing registry is to be the source of truth about a resource, the holder of that resource, and thereby the valid originator of routing entries related to that resource. Whatever you want to call it, ARIN does exactly that. The dynamics of routing protocols are subject to the whims and business relationships that evolve between operators, but the source of validity in registration is held by IANA and the set of RIRs. Tony > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Tuesday, February 22, 2011 2:11 PM > To: Warren Johnson > Cc: Tony Hain; ARIN-PPML List > Subject: Re: [arin-ppml] Proposal insanity --- an open letter > > On Feb 23, 2011, at 6:00 AM, Warren Johnson wrote: > > > Jon, > > > > That's all well and good in theory but I think we all know that being > removed from the whois database and reassigned by ARIN will take down > an organization. It's not what ARIN has built, rather it's the result > of a community that regards ARIN as the authority and we govern based > on that mutual consensus. Like it or not, ARIN is in that position and > has no realistic choice but to govern from that ground. > > Warren - > > Full agreement; this is why the policy process is so important. > It was simply necessary to be clear for Mr. Hain that ARIN does > not control routing; the community hopefully participates in the > policy development process, and may make use of registry because > we manage it as directed, but that's not the same as directing > the configuration of ISPs routers... > > /John > > John Curran > President and CEO > ARIN From jcurran at arin.net Tue Feb 22 18:16:26 2011 From: jcurran at arin.net (John Curran) Date: Tue, 22 Feb 2011 23:16:26 +0000 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <0235341E-7E46-4B26-8FAB-F8A063932148@queuefull.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> <0235341E-7E46-4B26-8FAB-F8A063932148@queuefull.net> Message-ID: <1328F1B4-2D58-44D6-A4AE-6127989529C0@arin.net> On Feb 23, 2011, at 6:48 AM, Benson Schliesser wrote: > On Feb 22, 2011, at 2:46 PM, John Curran wrote: >> The InterNIC registry function, including personal, systems >> and records were transferred by NSI to ARIN at ARIN's inception. >> ARIN is operates the registry in question. > > This may be true, but it doesn't address the question of IANA. Even if ARIN was acting as the "successor registry" for global address allocation during the period prior to ICANN, the US Govt clearly chose to recognize ICANN as the IANA. The IANA contract with ICANN explicitly includes oversight of address allocations. Delegation of registry responsibilities doesn't change that situation. Agreed. >> Collectively, the RIRs participate jointly as the NRO in ICANN, >> serving as the ASO (Address Supporting Organization). This is >> covered in the ASO and NRO MOU's with ICANN. > > (Understood - thanks also for the background you provided in your previous message on this topic.) > > Through contract with NTIA/DoC, ICANN has been delegated a governmental responsibility which we call the IANA. The acronym literally includes the word "authority", so I'll posit that IANA has the US Government's delegated authority*. However, each RIR represents a constituency as I've outlined above. My view is that constituency and authority meet at the NRO-ASO interface, and I think this is an elegant system.** However, the recognition of ASO-NRO by ICANN does not diminish the role and responsibility of IANA. Correct. >> In each case, the >> registrations which from that region prior to the RIR formation >> ("legacy registrations") where transferred under that RIR. This >> shouldn't be surprising given the non-for-profit, non-overlapping >> service regions. > > This is a fair argument, but it's one that needs to be formalized. As Matthew pointed out in a parallel message, the historical distinction of legacy holders doesn't seem to reinforce their inclusion in ARIN's constituency. And while it might never have mattered before, it does matter now that IPv4 addresses are a scarce resource - because people may be motivated to behave differently now, and legacy holders may wish to act outside the regulation of ARIN policy. > > To this end, I think IANA should be called upon to clarify the relationship of legacy holders. Until this is done, I think the most responsible approach for ARIN to take is deference to IANA on legacy resource issues. Interesting assertion. In any event, to the extent that there has been IANA guidance regarding legacy allocations, ARIN has complied: FYI, /John John Curran President and CEO ARIN From Wesley.E.George at sprint.com Tue Feb 22 18:17:45 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 22 Feb 2011 23:17:45 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, February 22, 2011 1:08 PM Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] On Feb 22, 2011, at 7:19 AM, George, Wes E [NTK] wrote: > > [WEG] We're going around in circles again. If they were able to > justify this allocation, they would have already requested it (prior > to IANA exhaust) in an effort to reduce or eliminate the need for NAT > in the first place. The problem is that we're trying to insulate > against something that may or may not happen based on expectation of > future growth. Assuming that the same ISP already has enough addresses > for their current customers, it is perfectly legitimate to expect them to transition some of those existing customers to CGN so that they have address space available for NAT pools, outside AND inside. > > Wes George Your logic here is flawed. It's entirely possible that they would first attempt to do the right thing and request a shared block through the policy process falling back to these requests while they are still possible, but, after exhausting the policy option. [WEG] No, that's not flawed logic, it just doesn't agree with your view. Possible != only course of action. No matter how good of citizens they're trying to be, if the two are in conflict, "right thing for the Internet and the world" loses vs. "right thing the company what signs the paycheck" most of the time. You criticize them from bringing a study that is not ARIN-specific to the ARIN region for what is a global issue, but, they tried to address this globally and it failed to achieve resolution. [WEG] It failed because people were unconvinced by the same arguments that are being used here, but that's not why I brought regional relevance into the discussion. I gave some of the same criticism before too. The study is not representative of the pool of devices available outside of the JDM and so is too narrow in focus for anywhere except Japan. I think it's pretty simple to provide real evidence to support your point: Take each of the "usual suspect" manufacturers of CPE gear, and plot out the default block that they use - look for commonalities (eg do DLink and Linksys use the same default?) as well as what space is not in conflict with any of them. Compare against what you know about your personal network's installed base (or failing that, a rough estimate of installed base that is derived from market share of each manufacturer * your customer size), and characterize the order of magnitude of risk for each block within 1918, either by /24 or by larger block. If you can show that there's more than a trivial number of devices populating each block, then that will be good evidence that 1918 isn't workable. Otherwise we're left with comments like, "well X% of 20M users is still a huge number to have to reconfigure" without knowing what the value of X actually is. Wes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From Wesley.E.George at sprint.com Tue Feb 22 18:19:14 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Tue, 22 Feb 2011 23:19:14 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <97409F22-7524-433B-A952-99EFA53C08AA@delong.com> References: <97409F22-7524-433B-A952-99EFA53C08AA@delong.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E3715E6@PDAWM12B.ad.sprint.com> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, February 22, 2011 1:13 PM Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] >Their 40 parallel RFC-1918 addressing domains are all under their control and can easily be coordinated by VZW. >You're option 4 expands that to 100 million parallel addressing domains not managed by VZW + 40 that are + some additional >number that are, but, by definition likely overlap the existing 40. [WEG] Owen, this statement is mostly FUD, and I'll thank you to stop confusing the issue. The original problem was "we don't want to use 1918 for outside CPE NAT interface because we're worried that it'll conflict with the address space assigned on the inside NAT by default". Somehow that has now morphed into 100 million parallel addressing domains and a concern about overlap between them because they're not all managed by the same entity. So now it's my turn to say, "Huh?" You're right that it's not a perfect justification for expecting to use 1918 space in a NAT without conflicting with CPE default config, because this CPE is centrally managed by the ISP, but that has nothing to do with how many places it is being used. It actually provides an excellent proof that RFC 1918 can be used in a Carrier NAT without conflicting with other networks' NAT and internal use of RFC1918 space, because it's not possible to route directly from your internal address behind $ISP's CGN to another company's internal address behind their NAT without traversing the externally routed public IPs between destinations, meaning that each sees a unique address that doesn't conflict. Address collision between NAT domains within a company that is repeatedly using the same block of addresses is a problem regardless of if you use 1918 or an ARIN-designated /10, assuming you need more than a /10 of addresses, so I don't see that as a valid justification for ignoring 1918 as a possible solution. The point of contention that remains is exactly how much of a problem managing some minority of CPE devices that are configured to use the "wrong" portion of 1918 and have to be reconfigured (or better still, replaced with something that supports IPv6) to prevent that conflict. I maintain that CGN is going to cause enough support calls that it's overly simplistic to assume that just because you're not using 1918 it'll be orders of magnitude easier. But without real evidence, it's just one set of conjecture against another, and we're really not getting anywhere. Wes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From hannigan at gmail.com Tue Feb 22 18:21:53 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 22 Feb 2011 18:21:53 -0500 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> Message-ID: On Tue, Feb 22, 2011 at 12:00 AM, Matthew Petach wrote: > On Sun, Feb 20, 2011 at 6:42 PM, Matthew Petach wrote: >> On Sat, Feb 19, 2011 at 6:02 PM, John Curran wrote: >>> Correct. ?Make the intent of the policy clear and unambiguous. ?I believe the AC is working on that presently. >>> >>> /John >> >> I'd like to raise my voice in SUPPORT of the policy proposal to render explicit >> the set of IPv4 addresses being returned to IANA as "{}". >> >> Matt > > To clarify, as I've gotten some questions about my stance; > those addresses which were allocated by IANA to ARIN for > the region, I believe should stay within the region. > > Address blocks *not* allocated by IANA to ARIN, namely > address blocks assigned to "legacy" holders should be returned > whence they came, if they are freed up, namely to IANA, as those > never passed through ARIN's hands in the first place. > But if the IANA has no procedure for openly and transparently delivering the addresses back to the community, what should happen? Part of what 131 is about is insuring that if this is the case as it is now, that those addresses are not going to sit idle if there is need. Best, -M< From owen at delong.com Tue Feb 22 18:24:34 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 15:24:34 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> Message-ID: On Feb 22, 2011, at 12:10 PM, Benson Schliesser wrote: > > On Feb 22, 2011, at 3:13 AM, Owen DeLong wrote: >> On Feb 21, 2011, at 9:00 PM, Matthew Petach wrote: >>> To clarify, as I've gotten some questions about my stance; >>> those addresses which were allocated by IANA to ARIN for >>> the region, I believe should stay within the region. >>> >>> Address blocks *not* allocated by IANA to ARIN, namely >>> address blocks assigned to "legacy" holders should be returned >>> whence they came, if they are freed up, namely to IANA, as those >>> never passed through ARIN's hands in the first place. >>> >> Most blocks you describe were not allocated by IANA to their >> current holders, but, rather by ARIN's predecessors, the SRI >> Internic and the NSI Internic, neither of which exists for those >> blocks to be returned to. >> >> Care to clarify your stance in light of those facts? > > I can't speak for Matthew. But my understanding is: ARIN's Internic "predecessors"* were contracted by the US Govt to perform the IANA function, and ICANN is currently contracted by the US Govt to perform the IANA function. As such, returning legacy addresses to the IANA/ICANN seems to make sense unless IANA/ICANN would prefer otherwise. > I believe the IANA function was always separate from the InterNIC from the beginning of the InterNIC. Yes, the IANA was contracted by USG and originally managed the InterNIC contract. However, this is different from what you state above. Owen > Cheers, > -Benson > > * - To my knowledge, while ARIN made it possible for NSF to release NSI from their IANA responsibilities, the contract was not novated to ARIN and ARIN has never held a contract for the IANA function. If my understanding is incorrect, I would appreciate pointers to correct background. If my understanding is correct, then claims that ARIN is the "successor" are fairly hollow. I don't think that is entirely accurate, either. https://www.arin.net/about_us/history.html Owen From owen at delong.com Tue Feb 22 18:37:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 15:37:39 -0800 Subject: [arin-ppml] FW: Proposal: Clarification of draft policy 2009-3 (ARIN-prop-135) In-Reply-To: References: <8695009A81378E48879980039EEDAD288C048DA1@MAIL1.polartel.local> <37059055-9123-426E-B466-03F1792247EF@arin.net> <496D2E48-343E-409D-AFD6-DBD3466B1CD6@arin.net> <0AE81F3A-277B-47D8-A166-6A1692F5BAB7@delong.com> <706BB5DD-7E90-4387-B006-6E0E4C7FD177@queuefull.net> <99AAFC3F-2A9E-4CD8-A1CC-ED67FF2C4B01@corp.arin.net> Message-ID: <6C397072-3065-4A18-AC8C-F8CEDDCC33B4@delong.com> On Feb 22, 2011, at 1:16 PM, Matthew Petach wrote: > On Tue, Feb 22, 2011 at 12:46 PM, John Curran wrote: > ... >> In each case, the registrations which from that region prior to >> the RIR formation ("legacy registrations") where transferred >> under that RIR. > > If that's truly the case, that the registrations were actually > transferred to be under the control of the RIR as part of the > transition, then isn't the whole RSA/LRSA/non-signing > legacyholder debate totally moot? If their address blocks > really *were* transferred under ARIN, explicitly, as part of > the formation of the RIR, then they fall under the policies > and auspices of that RIR. > Exactly correct. Sort of. > However, currently we're treating them as though they're > outside the RIR system, where policies don't apply to them, > they don't have to pay for resources the same way, and > don't have to sign the same agreement documents. To me, > that says that their resources were *NOT* transferred under > the RIR at the time of the transition, and instead fall under > some other global umbrella. > Just my opinion (not speaking for ARIN or the AC): The difficulty comes in the fact that without a specific contract (there wasn't such a contract used in the predecessor registries), retroactive application of policy is difficult at best. It would be a disservice to the ARIN community as a whole to do a blanket termination of services for legacy registrants. In other words, while ARIN probably has the ability to subject legacy holders to ARIN policy, whether or not doing so is a good idea is an entirely different question. Yes, there are those that want to argue ARIN has no such ability. I don't think they are entirely correct, but, the lack of a contract means that the winner of such an argument is very uncertain, at best. However, the entire internet will most assuredly lose if such an argument goes to full possible scale or even a significant fraction. > So. Once and for all, can we please have it stated clearly, > and for the record: > > Under whose auspices do the current legacy holders hold > their space? Under whose stewardship do those blocks > exist? If they were assigned under SRI or NSI, did they > transfer to ARIN at the time of the RIR creation, or did > they revert back to the parent of SRI/NSI, which at this > point would be IANA? > The were transferred to the RIRs as the RIRs were formed. Owen > From hannigan at gmail.com Tue Feb 22 19:38:51 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 22 Feb 2011 19:38:51 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: <014401cbd252$a2c371e0$e84a55a0$@iname.com> References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: The recycle times are most likely not relevant since legacy addrs are not generally filtered like IANA addrs that were unallocated were. I'm opposed to the language in the 'update' and you should be as well. Adding in the link to the RSA creates a hole that will likely result in unpredictability of the performance of this policy. We have lots of policy breakage like this; too much room for interpretation. In this case, a narrow, succinct and predictable policy is required so that proper expectations are set regionally and globally. What we have here in this version is not what the intent was when I wrote it. Best, Marty On 2/22/11, Frank Bulk wrote: > Thanks, Bill, for clarifying. > > If I make the assumption that legacy and non-legacy space are almost > equivalent in terms of their reusability after their return, for > simplicity's sake it would be easier to keep the recycle times in sync, > either: > a) keep the verbiage of 2011-6 so that it includes all space and specify a > time > b) exclude legacy space in 2011-6 and leave recycle time to the discretion > of ARIN staff. > In both cases, the recycle time would be effectively the same. > > If we don't specify a time period in policy 2011-6, I'm not sure if author's > concern regarding "sit[ting] idle" would be met. Perhaps min/max time would > give the ARIN staff the flexibility but also address the author's concern. > > Frank > > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William > Herrin > Sent: Monday, February 21, 2011 11:14 PM > To: frnkblk at iname.com > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses > > On Tue, Feb 22, 2011 at 12:11 AM, Frank Bulk wrote: >> Does the existing "RSA-covered address recovery" include the 30-day > window? >> In your previous comment I know you wanted to leave that timeframe to the >> discretion of ARIN staff, but the timeframe is one reason why we may want > to >> include RSA-covered addresses in 2011-6. > > Hi Frank, > > I believe the recycle period is currently much longer, but then we > haven't run out of addresses yet. If we don't set it in policy, ARIN > staff is free to set a then-optimal recycle period. > > -Bill > > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From owen at delong.com Tue Feb 22 20:37:17 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 17:37:17 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> Message-ID: <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> On Feb 22, 2011, at 3:17 PM, George, Wes E [NTK] wrote: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, February 22, 2011 1:08 PM > Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address > Extension] > > > On Feb 22, 2011, at 7:19 AM, George, Wes E [NTK] wrote: >> >> [WEG] We're going around in circles again. If they were able to >> justify this allocation, they would have already requested it (prior >> to IANA exhaust) in an effort to reduce or eliminate the need for NAT >> in the first place. The problem is that we're trying to insulate >> against something that may or may not happen based on expectation of >> future growth. Assuming that the same ISP already has enough addresses >> for their current customers, it is perfectly legitimate to expect them to transition some of those > existing customers to CGN so that they have address space available for NAT pools, outside AND > inside. >> >> Wes George > > Your logic here is flawed. It's entirely possible that they would first attempt to do the right > thing and request a shared block through the policy process falling back to these requests while > they are still possible, but, after exhausting the policy option. > [WEG] No, that's not flawed logic, it just doesn't agree with your view. Possible != only course of > action. No matter how good of citizens they're trying to be, if the two are in conflict, "right > thing for the Internet and the world" loses vs. "right thing the company what signs the paycheck" > most of the time. > > You criticize them from bringing a study that is not ARIN-specific to the ARIN region for what is a > global issue, but, they tried to address this globally and it failed to achieve resolution. > [WEG] It failed because people were unconvinced by the same arguments that are being used here, but > that's not why I brought regional relevance into the discussion. I gave some of the same criticism > before too. The study is not representative of the pool of devices available outside of the JDM and > so is too narrow in focus for anywhere except Japan. > I think it's pretty simple to provide real evidence to support your point: > Take each of the "usual suspect" manufacturers of CPE gear, and plot out the default block that they > use - look for commonalities (eg do DLink and Linksys use the same default?) as well as what space > is not in conflict with any of them. Compare against what you know about your personal network's > installed base (or failing that, a rough estimate of installed base that is derived from market > share of each manufacturer * your customer size), and characterize the order of magnitude of risk > for each block within 1918, either by /24 or by larger block. If you can show that there's more than > a trivial number of devices populating each block, then that will be good evidence that 1918 isn't > workable. Otherwise we're left with comments like, "well X% of 20M users is still a huge number to > have to reconfigure" without knowing what the value of X actually is. > > Wes > > I don't have the time or resources to provide you with a scientific study, but, my rough experience encountering those devices across a wide range of SMB and SOHO environments where I have done consulting is that there is no safe haven within RFC-1918 where some significant proportion of these devices are not deployed. I have encountered boxes which default to: 1. Random 10.x.x.x subnet 2. 10/8 (literally assigning randomly from the /8) 3. 172.16.0.0/12 4. 172.16.0.0/16 5. 172.16.0.0/24 6. 192.168.x.0/24 (Where X= {0,1,5,10,12,17,22,54,79,100,128, 172,192,224,245}) 7. 192.168.0.0/16 8. Completely random subnet picked from entire RFC-1918 range (As in when you factory-refresh the device, it picks some random 10, 172.x, or 192.168 /24 at random. Kid you not.) In addition to this, I've seen more than a handful of situations where someone chose to reconfigure the default to some other arbitrary RFC-1918 range. I've encountered this in a sufficiently high incidence to believe that depending on the defaults to save you is unlikely to create a positive outcome. When this was brought before the IETF, I was also unconvinced. After discussing the matter in person with several affected providers at the Cable Labs meeting, I became convinced of the problem. It's not like I didn't bring up all the things you are saying during that discussion. Owen From gbonser at seven.com Tue Feb 22 20:46:51 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 22 Feb 2011 17:46:51 -0800 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <179c01cbd2e2$c3432330$49c96990$@net> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net><9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net><16dd01cbd2b0$613ac670$23b05350$@net><891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net><055d01cbd2db$e7ea8bd0$b7bfa370$@net> <179c01cbd2e2$c3432330$49c96990$@net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13C9F@RWC-EX1.corp.seven.com> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Tony Hain > Sent: Tuesday, February 22, 2011 2:49 PM > To: 'John Curran'; 'Warren Johnson' > Cc: 'ARIN-PPML List' > Subject: Re: [arin-ppml] Proposal insanity --- an open letter > > John, > > I never said ARIN directed the configuration of ISP routers. The point > of a > routing registry is to be the source of truth about a resource, the > holder > of that resource, and thereby the valid originator of routing entries > related to that resource. Whatever you want to call it, ARIN does > exactly > that. The dynamics of routing protocols are subject to the whims and > business relationships that evolve between operators, but the source of > validity in registration is held by IANA and the set of RIRs. > > Tony Well, this is actually the source of an earlier comment I made about the proposals making legacy blocks "easier to hijack". That seems to be what this is facilitating, in practice. If you remove them from whois, one of two things (or both) happen. Either people start hijacking parts of that space and there is no way to verify the real owner of it and/or it gets put in the "full bogons" database and people who use that for their own routing filters find the traffic blocked. There is absolutely no way I am ever going to favor anything that changes the rules for the legacy networks or attempts to coerce them into doing anything. The purpose here seems to be a round-about way to enable the eventual confiscation and re-issuing of space. So you have network space that was granted under one set of rules but now you must comply with a different set of rules to keep it. Forget it. Stop having dreams of taking other people's address allocations even if they aren't using it. This entire exercise stinks to high heaven. From marka at isc.org Tue Feb 22 20:52:39 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 23 Feb 2011 12:52:39 +1100 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: Your message of "Tue, 22 Feb 2011 17:46:51 -0800." <5A6D953473350C4B9995546AFE9939EE0BC13C9F@RWC-EX1.corp.seven.com> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net><9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net><16dd01cbd2b0$613ac670$23b05350$@net><891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net><055d01cbd2db$e7ea8bd0$b7bfa370$@net> <179c01cbd2e2$c3432330$49c96990$@net> <5A6D953473350C4B9995546AFE9939EE0BC13C9F@RWC-EX1.corp.seven.com> Message-ID: <20110223015239.1A912AA5046@drugs.dv.isc.org> In message <5A6D953473350C4B9995546AFE9939EE0BC13C9F at RWC-EX1.corp.seven.com>, "George Bonser" writes: > > > > -----Original Message----- > > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] > On > > Behalf Of Tony Hain > > Sent: Tuesday, February 22, 2011 2:49 PM > > To: 'John Curran'; 'Warren Johnson' > > Cc: 'ARIN-PPML List' > > Subject: Re: [arin-ppml] Proposal insanity --- an open letter > > > > John, > > > > I never said ARIN directed the configuration of ISP routers. The point > > of a > > routing registry is to be the source of truth about a resource, the > > holder > > of that resource, and thereby the valid originator of routing entries > > related to that resource. Whatever you want to call it, ARIN does > > exactly > > that. The dynamics of routing protocols are subject to the whims and > > business relationships that evolve between operators, but the source > of > > validity in registration is held by IANA and the set of RIRs. > > > > Tony > > > Well, this is actually the source of an earlier comment I made about the > proposals making legacy blocks "easier to hijack". That seems to be > what this is facilitating, in practice. If you remove them from whois, > one of two things (or both) happen. Either people start hijacking parts > of that space and there is no way to verify the real owner of it and/or > it gets put in the "full bogons" database and people who use that for > their own routing filters find the traffic blocked. > > There is absolutely no way I am ever going to favor anything that > changes the rules for the legacy networks or attempts to coerce them > into doing anything. The purpose here seems to be a round-about way to > enable the eventual confiscation and re-issuing of space. So you have > network space that was granted under one set of rules but now you must > comply with a different set of rules to keep it. Forget it. Stop > having dreams of taking other people's address allocations even if they > aren't using it. > > This entire exercise stinks to high heaven. +1 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Tue Feb 22 20:52:03 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 17:52:03 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E3715E6@PDAWM12B.ad.sprint.com> References: <97409F22-7524-433B-A952-99EFA53C08AA@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715E6@PDAWM12B.ad.sprint.com> Message-ID: On Feb 22, 2011, at 3:19 PM, George, Wes E [NTK] wrote: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, February 22, 2011 1:13 PM > Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address > Extension] > >> Their 40 parallel RFC-1918 addressing domains are all under their control and can easily be > coordinated by VZW. > >> You're option 4 expands that to 100 million parallel addressing domains not managed by VZW + 40 > that are + some additional >number that are, but, by definition likely overlap the existing 40. > > [WEG] Owen, this statement is mostly FUD, and I'll thank you to stop confusing the issue. > The original problem was "we don't want to use 1918 for outside CPE NAT interface because we're > worried that it'll conflict with the address space assigned on the inside NAT by default". Somehow > that has now morphed into 100 million parallel addressing domains and a concern about overlap > between them because they're not all managed by the same entity. So now it's my turn to say, "Huh?" He was positing that because VZW is able to maintain 40 parallel instances of 1918 space under their control that it was the same problem as maintaining a CGN Intermediary address space that overlapped the customer address spaces. My statement wasn't FUD, it was taking his example to its logical conclusion when scaled to the environment HE described. He is the one that came up with 100 million subscribers as a number for the environment. He is the one that stated parallel instances of RFC-1918 were OK in the situation. I merely pointed out the difference between what he was saying and what he was proposing as a viable solution. > You're right that it's not a perfect justification for expecting to use 1918 space in a NAT without > conflicting with CPE default config, because this CPE is centrally managed by the ISP, but that has > nothing to do with how many places it is being used. Again, I was using his numbers to counter his example. If there's FUD here, it's his. > It actually provides an excellent proof that RFC 1918 can be used in a Carrier NAT without > conflicting with other networks' NAT and internal use of RFC1918 space, because it's not possible to > route directly from your internal address behind $ISP's CGN to another company's internal address > behind their NAT without traversing the externally routed public IPs between destinations, meaning > that each sees a unique address that doesn't conflict. > Let me try to explain the problem you seem to be missing here... First, you have the following network zones: {A}, {B}, and {C}. {A} is the public internet with globally unique addressing. {B} is the NAT444 intermediary zone that would be addressed with the proposed numbers. {C} is the networks behind each customer's NAT. If addresses conflict between {B} and {C}, the consumer's NAT box may send traffic destined to its default gateway in zone {B} back into zone {C} because it may see the gateway address as being within zone {C}. This would have the effect of taking the user effectively off of the internet and moving them, instead, to the providers support queue. Worse, it will be the telephone support queue because their unable to reach their internet self-service options to resolve the problem. > Address collision between NAT domains within a company that is repeatedly using the same block of > addresses is a problem regardless of if you use 1918 or an ARIN-designated /10, assuming you need > more than a /10 of addresses, so I don't see that as a valid justification for ignoring 1918 as a > possible solution. > Nobody is ignoring 1918 as a possible solution. They are considering the scale of the difficulties created by specific types of colliding address ranges and realizing that the scope of the problem exceeds practicability if the coordination of the intermediary addressing has to include coordination with their customers LAN side addressing. If you have separate intermediary zones that contain the same sets of NAT addresses and don't talk directly to each other, that's not a problem. The problem occurs when you have address collisions on opposite sides of the same NAT box without an additional NAT in between. This would be the case encountered by large providers deploying LSN using RFC-1918 to number the intermediary zone between the Consumer and Carrier NATs. > The point of contention that remains is exactly how much of a problem managing some minority of CPE > devices that are configured to use the "wrong" portion of 1918 and have to be reconfigured (or > better still, replaced with something that supports IPv6) to prevent that conflict. I maintain that > CGN is going to cause enough support calls that it's overly simplistic to assume that just because > you're not using 1918 it'll be orders of magnitude easier. But without real evidence, it's just one > set of conjecture against another, and we're really not getting anywhere. > No question that CGN will raise the support call level. That increase is acceptable because the alternative is the even larger increase created by turning off IPv4 support altogether for at least some fraction of customers. Nonetheless, that call volume is independent of and cumulative to the call volume created by colliding address spaces. I would anticipate that you would be hard pressed to find a sufficiently large RFC-1918 range to be practical (since your choices in many cases are limited to 10.0/10, 10.4/10, 10.8/10, and 10.12/10) that will not conflict with at least 1% of the subscriber configurations. Yes, this is conjecture, but, given my experience dealing with various SOHO and SMB configurations over the years, I think it's pretty reasonable conjecture. Owen From Wesley.E.George at sprint.com Tue Feb 22 21:04:21 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 23 Feb 2011 02:04:21 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, February 22, 2011 8:37 PM I don't have the time or resources to provide you with a scientific study, but, my rough experience encountering those devices across a wide range of SMB and SOHO environments where I have done consulting is that there is no safe haven within RFC-1918 where some significant proportion of these devices are not deployed. I have encountered boxes which default to: 1. Random 10.x.x.x subnet 2. 10/8 (literally assigning randomly from the /8) 3. 172.16.0.0/12 4. 172.16.0.0/16 5. 172.16.0.0/24 6. 192.168.x.0/24 (Where X= {0,1,5,10,12,17,22,54,79,100,128, 172,192,224,245}) 7. 192.168.0.0/16 8. Completely random subnet picked from entire RFC-1918 range (As in when you factory-refresh the device, it picks some random 10, 172.x, or 192.168 /24 at random. Kid you not.) [WEG] Appreciate the other anecdotal evidence. I never doubted that there were defaults that did strange things. I think that the important point is the statistical distribution to characterize how much of a risk these assorted "weird" implementations may be, rather than the examples themselves. In addition to this, I've seen more than a handful of situations where someone chose to reconfigure the default to some other arbitrary RFC-1918 range. I've encountered this in a sufficiently high incidence to believe that depending on the defaults to save you is unlikely to create a positive outcome. [WEG] If someone changed it from the default, it's perfectly acceptable to say "sorry, that configuration is not supported, please restore the defaults and let us know if that resolves the problem" There are far more frustrating things in most ISP's support scripts when you call them for troubleshooting assistance than a request to restore the default config. I simply don't buy the argument "we can't do that on the off chance that someone might have changed their config from the default in a way that might break things" -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From jhg at omsys.com Tue Feb 22 21:16:47 2011 From: jhg at omsys.com (Jeremy H. Griffith) Date: Tue, 22 Feb 2011 21:16:47 -0500 Subject: [arin-ppml] Proposal insanity --- an open letter In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13C9F@RWC-EX1.corp.seven.com> References: <15dc01cbd219$fe9c69b0$fbd53d10$@net><9A0C32AE-42CA-4F16-BE0C-5988826DA7D1@corp.arin.net><16dd01cbd2b0$613ac670$23b05350$@net><891D0DC3-C80E-46C8-9226-EBB0E8F8CDB2@arin.net><055d01cbd2db$e7ea8bd0$b7bfa370$@net> <179c01cbd2e2$c3432330$49c96990$@net> <5A6D953473350C4B9995546AFE9939EE0BC13C9F@RWC-EX1.corp.seven.com> Message-ID: On Tue, 22 Feb 2011 17:46:51 -0800, "George Bonser" wrote: >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >On >> Behalf Of Tony Hain >> Sent: Tuesday, February 22, 2011 2:49 PM >> To: 'John Curran'; 'Warren Johnson' >> Cc: 'ARIN-PPML List' >> Subject: Re: [arin-ppml] Proposal insanity --- an open letter >> >> John, >> >> I never said ARIN directed the configuration of ISP routers. The point >> of a >> routing registry is to be the source of truth about a resource, the >> holder >> of that resource, and thereby the valid originator of routing entries >> related to that resource. Whatever you want to call it, ARIN does >> exactly >> that. The dynamics of routing protocols are subject to the whims and >> business relationships that evolve between operators, but the source >of >> validity in registration is held by IANA and the set of RIRs. >> >> Tony > > >Well, this is actually the source of an earlier comment I made about the >proposals making legacy blocks "easier to hijack". That seems to be >what this is facilitating, in practice. If you remove them from whois, >one of two things (or both) happen. Either people start hijacking parts >of that space and there is no way to verify the real owner of it and/or >it gets put in the "full bogons" database and people who use that for >their own routing filters find the traffic blocked. > >There is absolutely no way I am ever going to favor anything that >changes the rules for the legacy networks or attempts to coerce them >into doing anything. The purpose here seems to be a round-about way to >enable the eventual confiscation and re-issuing of space. So you have >network space that was granted under one set of rules but now you must >comply with a different set of rules to keep it. Forget it. Stop >having dreams of taking other people's address allocations even if they >aren't using it. > >This entire exercise stinks to high heaven. Yes indeed. +1 I totally fail to see how making legacy space unroutable serves any sensible purpose at all post-runout. Seems like it would increase, nor decrease, the address shortage. I also don't think it's a great idea to expose ARIN to the RICO suits that would surely follow any attempt to exercise such a policy, considering that the sole benefit appears to be more revenue for ARIN. --JHG From Wesley.E.George at sprint.com Tue Feb 22 21:52:29 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 23 Feb 2011 02:52:29 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <97409F22-7524-433B-A952-99EFA53C08AA@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715E6@PDAWM12B.ad.sprint.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E371796@PDAWM12B.ad.sprint.com> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Tuesday, February 22, 2011 8:52 PM Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] He was positing that because VZW is able to maintain 40 parallel instances of 1918 space under their control that it was the same problem as maintaining a CGN Intermediary address space that overlapped the customer address spaces. My statement wasn't FUD, it was taking his example to its logical conclusion when scaled to the environment HE described. He is the one that came up with 100 million subscribers as a number for the environment. He is the one that stated parallel instances of RFC-1918 were OK in the situation. I merely pointed out the difference between what he was saying and what he was proposing as a viable solution. [WEG] I'm not going to debate what Joel meant on his behalf. However, I'll tell you what I understood it to mean - that VZW has 100M customers, and they are already using 1918 as an inside CGN pool, assumedly including devices that do their own NAT, therefore proving that at least in some cases it is a perfectly viable application as an alternative to a dedicated shared address pool. Your interpretation of that meaning that all 100M entities represented a NAT444 instance and therefore an opportunity for conflicting address space is what I believed moved towards FUD. Let me try to explain the problem you seem to be missing here... [WEG] Yes, I'm not a moron, thanks. We're not going to agree about this, so I think perhaps we should stop clogging the list with what has become largely a 2-person debate. Wes -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From owen at delong.com Tue Feb 22 22:00:39 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Feb 2011 19:00:39 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> Message-ID: On Feb 22, 2011, at 6:04 PM, George, Wes E [NTK] wrote: > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, February 22, 2011 8:37 PM > > I don't have the time or resources to provide you with a scientific study, but, my rough experience > encountering those devices across a wide range of SMB and SOHO environments where I have done > consulting is that there is no safe haven within > RFC-1918 where some significant proportion of these devices are not deployed. > I have encountered boxes which default to: > > 1. Random 10.x.x.x subnet > 2. 10/8 (literally assigning randomly from the /8) > 3. 172.16.0.0/12 > 4. 172.16.0.0/16 > 5. 172.16.0.0/24 > 6. 192.168.x.0/24 (Where X= {0,1,5,10,12,17,22,54,79,100,128, 172,192,224,245}) > 7. 192.168.0.0/16 > 8. Completely random subnet picked from entire RFC-1918 range > (As in when you factory-refresh the device, it picks some random > 10, 172.x, or 192.168 /24 at random. Kid you not.) > [WEG] Appreciate the other anecdotal evidence. I never doubted that there were defaults that did > strange things. I think that the important point is the statistical distribution to characterize how > much of a risk these assorted "weird" implementations may be, rather than the examples themselves. > > In addition to this, I've seen more than a handful of situations where someone chose to reconfigure > the default to some other arbitrary RFC-1918 range. I've encountered this in a sufficiently high > incidence to believe that depending on the defaults to save you is unlikely to create a positive > outcome. > As I said, I have neither time nor resources to conduct such a study, nor do I think that one could be meaningfully conducted in the time remaining before the proposal will be overtaken by events. > [WEG] If someone changed it from the default, it's perfectly acceptable to say "sorry, that > configuration is not supported, please restore the defaults and let us know if that resolves the > problem" > There are far more frustrating things in most ISP's support scripts when you call them for > troubleshooting assistance than a request to restore the default config. I simply don't buy the > argument "we can't do that on the off chance that someone might have changed their config from the > default in a way that might break things" This may be true, but, what happens when the default configuration ALSO doesn't work due to the fact that some of the modifications to the default were done for a reason other than just randomly changing the address? What about the situation where there are multiple hosts that have static addresses configured on them behind said CPE in the same network range, but, outside of the DHCP scope? What about the scenarios where the people on site don't even really know how to recognize the router. Some consultant set it up years ago and nobody has touched it since. These aren't just residential customers that will be effected. They'll be the majority, but, you also have to include many SMB and SOHO customers as well. Owen From bill at herrin.us Tue Feb 22 22:05:49 2011 From: bill at herrin.us (William Herrin) Date: Tue, 22 Feb 2011 22:05:49 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> Message-ID: Wes, It seems to me there are only two deciding questions for this proposal. 1. Should ARIN go counter to the IETF's determination not to create an ISP-local address space? 2. Is an ISP-local address space a better use of a /10 _for ARIN-region registrants_ than giving that /10 exclusively to whichever of the mega-ISPs happens to get to it first? I understand your view that ARIN should not buck the IETF, but I respectfully disagree. ARIN's responsibility is to the address users in its region, not the IETF. Many address users in the ARIN region have expressed an interest in any ISP-local address block for use with technologies like NAT444. The IETF's advice is always welcome and frequently relied upon, but with respect to addressing, the RIR's is and should be the final word. As far as I can tell, your response to the second question was "I don't think anything bucking the IETF can be a good use, therefore it can't be a better use than something else." If you made other points to the effect that assigning that /10 to whichever single registrant managed to get it is a better use than allocating it as ISP-local address space usable by everybody, I missed those points amid the rest of your argument. Would you mind summarizing them? Thanks, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From hannigan at gmail.com Tue Feb 22 22:14:12 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 22 Feb 2011 22:14:12 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: So let's try this again. I have multiple version from AC discussions and PPML discussions related to 131, 2009-3 which is formally abandoned and not relevant to this discussion and...and... -- it certainly is confusing as some have noted. The RSA component is not currently part of the discussion. We need to wait out the process to see what is going to transpire. I'm still opposing the proposal since the language that was submitted was changed before it was even placed on the docket and merging legacy considerations with address space that is clearly controlled by ARIN is likely to result in confusion. I think that as long as it makes it to Puerto Rico it doesn't really matter so it's probably worthwhile to wait it out untl then and stop polluting Tony's mailbox. :) Best, -M< On Tue, Feb 22, 2011 at 7:38 PM, Martin Hannigan wrote: > The recycle times are most likely not relevant since legacy addrs are > not generally filtered like IANA addrs that were unallocated were. > > I'm opposed to the language in the 'update' and you should be as well. > > Adding in the link to the RSA creates a hole that will likely result > in unpredictability of the performance of this policy. We have lots of > policy breakage like this; too much room for interpretation. > > In this case, a narrow, succinct and predictable policy is required so > that proper expectations are set regionally and globally. ?What we > have here in this version is not what the intent was when I wrote it. > > > Best, > > Marty > > > On 2/22/11, Frank Bulk wrote: >> Thanks, Bill, for clarifying. >> >> If I make the assumption that legacy and non-legacy space are almost >> equivalent in terms of their reusability after their return, for >> simplicity's sake it would be easier to keep the recycle times in sync, >> either: >> a) keep the verbiage of 2011-6 so that it includes all space and specify a >> time >> b) exclude legacy space in 2011-6 and leave recycle time to the discretion >> of ARIN staff. >> In both cases, the recycle time would be effectively the same. >> >> If we don't specify a time period in policy 2011-6, I'm not sure if author's >> concern regarding "sit[ting] idle" would be met. ?Perhaps min/max time would >> give the ARIN staff the flexibility but also address the author's concern. >> >> Frank >> >> -----Original Message----- >> From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William >> Herrin >> Sent: Monday, February 21, 2011 11:14 PM >> To: frnkblk at iname.com >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses >> >> On Tue, Feb 22, 2011 at 12:11 AM, Frank Bulk wrote: >>> Does the existing "RSA-covered address recovery" include the 30-day >> window? >>> In your previous comment I know you wanted to leave that timeframe to the >>> discretion of ARIN staff, but the timeframe is one reason why we may want >> to >>> include RSA-covered addresses in 2011-6. >> >> Hi Frank, >> >> I believe the recycle period is currently much longer, but then we >> haven't run out of addresses yet. If we don't set it in policy, ARIN >> staff is free to set a then-optimal recycle period. >> >> -Bill >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com? bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > From cgrundemann at gmail.com Tue Feb 22 22:33:32 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 22 Feb 2011 20:33:32 -0700 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: > merging legacy > considerations with address space that is clearly controlled by ARIN > is likely to result in confusion. Actually the opposite is true. Separating IPv4 address space along substantially arbitrary lines is likely to cause much more confusion than making clear policy that applies to all IPv4 addresses. ~Chris > Best, > > -M< > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From hannigan at gmail.com Tue Feb 22 22:34:29 2011 From: hannigan at gmail.com (Martin Hannigan) Date: Tue, 22 Feb 2011 22:34:29 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: On Tue, Feb 22, 2011 at 10:33 PM, Chris Grundemann wrote: >> merging legacy >> considerations with address space that is clearly controlled by ARIN >> is likely to result in confusion. > > Actually the opposite is true. Separating IPv4 address space along > substantially arbitrary lines is likely to cause much more confusion > than making clear policy that applies to all IPv4 addresses. > That wouldn't be a fact, it would be an opinion. Best, -M< From bill at herrin.us Tue Feb 22 22:41:55 2011 From: bill at herrin.us (William Herrin) Date: Tue, 22 Feb 2011 22:41:55 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: On Tue, Feb 22, 2011 at 10:33 PM, Chris Grundemann wrote: >> merging legacy >> considerations with address space that is clearly controlled by ARIN >> is likely to result in confusion. > > Actually the opposite is true. Separating IPv4 address space along > substantially arbitrary lines is likely to cause much more confusion > than making clear policy that applies to all IPv4 addresses. You're both right, but in different contexts. Chris, a policy without a list of exceptions is clearer than a policy with exceptions. Calling out legacy addresses specifically makes them an exception. But here's the context: legacy addresses are an exception. Even before a proposal author writes the first word, legacy addresses were an exception to ARIN's normal rules. So if he intends a policy to impact them, it is appropriate to call that out... lest folks (reasonably) assume that legacy addresses are an exception to his new policy as well. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cgrundemann at gmail.com Tue Feb 22 23:01:01 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 22 Feb 2011 21:01:01 -0700 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: On Tue, Feb 22, 2011 at 20:41, William Herrin wrote: > On Tue, Feb 22, 2011 at 10:33 PM, Chris Grundemann > wrote: >>> merging legacy >>> considerations with address space that is clearly controlled by ARIN >>> is likely to result in confusion. >> >> Actually the opposite is true. Separating IPv4 address space along >> substantially arbitrary lines is likely to cause much more confusion >> than making clear policy that applies to all IPv4 addresses. > > You're both right, but in different contexts. > > Chris, a policy without a list of exceptions is clearer than a policy > with exceptions. Calling out legacy addresses specifically makes them > an exception. This I agree with. > But here's the context: legacy addresses are an exception. Even before > a proposal author writes the first word, legacy addresses were an > exception to ARIN's normal rules. So if he intends a policy to impact > them, it is appropriate to call that out... lest folks (reasonably) > assume that legacy addresses are an exception to his new policy as > well. This I do not. There is no such thing as "legacy" addresses. ARIN policy covers all resources in this region, any exception that could possibly be argued for is temporal. So, in the strongest case, "legacy" is a historical status that can not be renewed (hence the name, I guess). Cheers, ~Chris > Regards, > Bill Herrin > > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From BillD at cait.wustl.edu Wed Feb 23 09:31:23 2011 From: BillD at cait.wustl.edu (Bill Darte) Date: Wed, 23 Feb 2011 08:31:23 -0600 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses References: <4D631F4F.80408@arin.net><014301cbd24e$edd9ff40$c98dfdc0$@iname.com><014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: Marty, Your statement of "is likely to result in confusion" is no less an opinion that Chris' counter assessment. I don't see the merit of the point? bd -----Original Message----- From: arin-ppml-bounces at arin.net on behalf of Martin Hannigan Sent: Tue 2/22/2011 9:34 PM To: Chris Grundemann Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses On Tue, Feb 22, 2011 at 10:33 PM, Chris Grundemann wrote: >> merging legacy >> considerations with address space that is clearly controlled by ARIN >> is likely to result in confusion. > > Actually the opposite is true. Separating IPv4 address space along > substantially arbitrary lines is likely to cause much more confusion > than making clear policy that applies to all IPv4 addresses. > That wouldn't be a fact, it would be an opinion. Best, -M< _______________________________________________ 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 Wed Feb 23 09:51:28 2011 From: bill at herrin.us (William Herrin) Date: Wed, 23 Feb 2011 09:51:28 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: On Tue, Feb 22, 2011 at 11:01 PM, Chris Grundemann wrote: > On Tue, Feb 22, 2011 at 20:41, William Herrin wrote: >> On Tue, Feb 22, 2011 at 10:33 PM, Chris Grundemann >> wrote: >>>> merging legacy >>>> considerations with address space that is clearly controlled by ARIN >>>> is likely to result in confusion. >>> >>> Actually the opposite is true. Separating IPv4 address space along >>> substantially arbitrary lines is likely to cause much more confusion >>> than making clear policy that applies to all IPv4 addresses. >> >> You're both right, but in different contexts. >> But here's the context: legacy addresses are an exception. > There is no such thing as "legacy" addresses. Chris, I stand corrected. Marty had the right of it: you're denying the facts on the ground. It's not unreasonable to write policy which changes those facts but if the changes are to be clear, they must reference the facts as they are both before and after the change. The facts today are: there IS such a thing as legacy addresses and they're presently immune to most ARIN-region policy. Moreover, that policy rarely says so explicitly. Hence policy which should impact legacy addresses will be more clearly understood if it explicitly says so. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Wesley.E.George at sprint.com Wed Feb 23 10:42:49 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 23 Feb 2011 15:42:49 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> -----Original Message----- From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin Sent: Tuesday, February 22, 2011 10:06 PM Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] It seems to me there are only two deciding questions for this proposal. 1. Should ARIN go counter to the IETF's determination not to create an ISP-local address space? [WEG] Well, technically reserved address space is the purview of the IETF directing IANA (or all RIRs agreeing to a global policy to direct IANA to do something). However, given that IANA no longer has any address space to reserve for this purpose, it really doesn't matter anymore. ARIN should do whatever its members direct it to do. That doesn't change the fact that I still think it's a bad idea regardless of where it's implemented, but I'm not opposed to it simply on procedural grounds as you implied. 2. Is an ISP-local address space a better use of a /10 _for ARIN-region registrants_ than giving that /10 exclusively to whichever of the mega-ISPs happens to get to it first? [WEG] No, I don' t think that it is, even when you phrase it like that. * I reject the argument that we have one or more "mega-ISPs" waiting for this policy to die so that they can make that final large allocation request (or to live so that they don't have to). It's simply na?ve to think that "the common good" is the only thing preventing them from doing what's right for their business. They haven't because they can't justify the space. * The Policy as written does not make inside NAT pool addresses an invalid use of current or newly-allocated space (aka, it doesn't *require* the use of shared space for an inside NAT pool), meaning that the same mega-ISPs we seem to be trying to prevent from decimating the free pool could simply say, "I don't want to have to use that /10 10 different times in my network, or use shared space at all, so I'm going to request my own block" or, keep justifying addresses BAU until exhaustion. * While neither IETF nor ARIN can exactly condone squatting on allocated but unrouted space, I believe this to be an acceptable alternative should RFC1918 be found unsuitable as an inside NAT pool. Doing nothing would be implicitly acknowledging the fact that it's *already being done*. * If neither of the above are viable for some reason, we are within our rights to expect ISPs to carve out a block of their existing space for this use - CGN applied to their existing deployment would allow them to reclaim addresses by sharing them among more than one customer, freeing addresses to be used as an internal NAT pool. Nevermind the idea of creating an incentive for more efficient use of IPv4 in infrastructure (1918, moving to IPv6, etc) * I believe that at this point it is simply better to let the IPv4 address exhaustion happen without any significant fiddling with it so that it is more deterministic. Hopefully that summarizes more succinctly Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From owen at delong.com Wed Feb 23 11:05:53 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Feb 2011 08:05:53 -0800 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: On Feb 23, 2011, at 6:51 AM, William Herrin wrote: > On Tue, Feb 22, 2011 at 11:01 PM, Chris Grundemann > wrote: >> On Tue, Feb 22, 2011 at 20:41, William Herrin wrote: >>> On Tue, Feb 22, 2011 at 10:33 PM, Chris Grundemann >>> wrote: >>>>> merging legacy >>>>> considerations with address space that is clearly controlled by ARIN >>>>> is likely to result in confusion. >>>> >>>> Actually the opposite is true. Separating IPv4 address space along >>>> substantially arbitrary lines is likely to cause much more confusion >>>> than making clear policy that applies to all IPv4 addresses. >>> >>> You're both right, but in different contexts. >>> But here's the context: legacy addresses are an exception. > >> There is no such thing as "legacy" addresses. > > Chris, > > I stand corrected. Marty had the right of it: you're denying the facts > on the ground. > No, Chris has it right.... There is no such thing as legacy addresses. There are addresses which currently have legacy status, but, if those resources are returned, transfered, or otherwise reregistered or freed, they are no longer in a legacy status. > It's not unreasonable to write policy which changes those facts but if > the changes are to be clear, they must reference the facts as they are > both before and after the change. The facts today are: there IS such a > thing as legacy addresses and they're presently immune to most > ARIN-region policy. Moreover, that policy rarely says so explicitly. > Hence policy which should impact legacy addresses will be more clearly > understood if it explicitly says so. > The part I think you are missing from Chris's point is that these are legacy registrations. The resources themselves are only in a legacy status so long as the current registration remains in effect. Owen From owen at delong.com Wed Feb 23 11:16:06 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Feb 2011 08:16:06 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> Message-ID: <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> On Feb 23, 2011, at 7:42 AM, George, Wes E [NTK] wrote: > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin > Sent: Tuesday, February 22, 2011 10:06 PM > Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address > Extension] > > It seems to me there are only two deciding questions for this proposal. > 1. Should ARIN go counter to the IETF's determination not to create an ISP-local address space? > > [WEG] Well, technically reserved address space is the purview of the IETF directing IANA (or all > RIRs agreeing to a global policy to direct IANA to do something). However, given that IANA no longer > has any address space to reserve for this purpose, it really doesn't matter anymore. ARIN should do > whatever its members direct it to do. That doesn't change the fact that I still think it's a bad > idea regardless of where it's implemented, but I'm not opposed to it simply on procedural grounds as > you implied. > > 2. Is an ISP-local address space a better use of a /10 _for ARIN-region registrants_ than giving > that /10 exclusively to whichever of the mega-ISPs happens to get to it first? > > [WEG] No, I don' t think that it is, even when you phrase it like that. > * I reject the argument that we have one or more "mega-ISPs" waiting for this policy to die so that > they can make that final large allocation request (or to live so that they don't have to). It's > simply na?ve to think that "the common good" is the only thing preventing them from doing what's > right for their business. They haven't because they can't justify the space. I think that isn't the argument. I think the argument is we have one or more mega-ISPs wanting this policy to pass, but if it does not, will be forced to apply for resources for this purpose. Current policy allows for them to number the necessary hosts accordingly, so, if this policy does not pass, there is nothing at all that would prevent them from each obtaining large blocks of addresses for this purpose. I don't know if any one of them could justify a /10 individually, but, I am quite certain that they can collectively easily exceed a /10. I'd estimate that they can probably come close to a /7, collectively. > * The Policy as written does not make inside NAT pool addresses an invalid use of current or > newly-allocated space (aka, it doesn't *require* the use of shared space for an inside NAT pool), > meaning that the same mega-ISPs we seem to be trying to prevent from decimating the free pool could > simply say, "I don't want to have to use that /10 10 different times in my network, or use shared > space at all, so I'm going to request my own block" or, keep justifying addresses BAU until > exhaustion. I think this is a legitimate criticism and would favor adding language to this effect to the draft policy. Would you support it with that change? > * While neither IETF nor ARIN can exactly condone squatting on allocated but unrouted space, I > believe this to be an acceptable alternative should RFC1918 be found unsuitable as an inside NAT > pool. Doing nothing would be implicitly acknowledging the fact that it's *already being done*. Whether you consider it acceptable or not, it comes with greater risks than simply gobbling up significant resources from the free pool, so, I suspect the less risky behavior is more likely. > * If neither of the above are viable for some reason, we are within our rights to expect ISPs to > carve out a block of their existing space for this use - CGN applied to their existing deployment > would allow them to reclaim addresses by sharing them among more than one customer, freeing > addresses to be used as an internal NAT pool. Nevermind the idea of creating an incentive for more > efficient use of IPv4 in infrastructure (1918, moving to IPv6, etc) But current policy doesn't require this, so, I'm not sure why you think it would magically happen. > * I believe that at this point it is simply better to let the IPv4 address exhaustion happen without > any significant fiddling with it so that it is more deterministic. > I don't think this proposal changes that determinism other than to make it deterministically slightly later than without it. Owen From bill at herrin.us Wed Feb 23 12:17:12 2011 From: bill at herrin.us (William Herrin) Date: Wed, 23 Feb 2011 12:17:12 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: References: <4D631F4F.80408@arin.net> <014301cbd24e$edd9ff40$c98dfdc0$@iname.com> <014401cbd252$a2c371e0$e84a55a0$@iname.com> Message-ID: On Wed, Feb 23, 2011 at 11:05 AM, Owen DeLong wrote: > There is no such thing as legacy addresses. There are addresses which > currently have legacy status, but, if those resources are returned, > transfered, or otherwise reregistered or freed, Hi Owen, If you want to pick that particular nit, it makes no difference to me and IMHO would not harm the proposal's clarify if you said "addresses recovered from legacy registrations" or "addresses recovered from within legacy /8's" instead of "recovered legacy addresses." > they are no longer in a legacy status. The /8 blocks of which they are a part are marked differently in the IANA records, have to some extent been managed differently by ARIN in the past and were to have been treated differently under 2009-3 both with our verbiage and the language chosen by the other regions. Where the intention is for a policy to treat them the same as the rest of ARIN's /8's, it is appropriate to say so. Moreover, ARIN staff _has asked you to say so_, with their request that the proposal clarify if it intends to specify whether recovered addresses from legacy registrations should be returned to IANA. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Wesley.E.George at sprint.com Wed Feb 23 12:32:20 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Wed, 23 Feb 2011 17:32:20 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E371E06@PDAWM12B.ad.sprint.com> -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Wednesday, February 23, 2011 11:16 AM Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] I think that isn't the argument. I think the argument is we have one or more mega-ISPs wanting this policy to pass, but if it does not, will be forced to apply for resources for this purpose. Current policy allows for them to number the necessary hosts accordingly, so, if this policy does not pass, there is nothing at all that would prevent them from each obtaining large blocks of addresses for this purpose. [WEG] I maintain that if this policy *passes* the same is true. Really, I think your argument is based on a fundamentally flawed assumption - that there is a huge group of hosts in one or more mega-ISPs that don't *already* have IPv4 addresses and the requests for resources to address them are being held back pending the decision on this policy. People aren't going to stake their jobs on policy happening in the IETF or ARIN especially on a timeline that is advantageous to their business needs. The mega-ISPs we keep talking about already have enough addresses for their current customers, so any application of CGN is to manage new growth once it is no longer possible to satisfy it with BAU IP requests. Growth takes the form of either additional customers (above churn rate) or (in the case of mobile operators) more simultaneous users that limit your ability to oversubscribe your DHCP address pools as heavily. So assuming that this policy gets implemented, you're basically hoping that people accelerate their plans for CGN instead of just using addresses BAU, and I think that's unlikely, meaning that this /10 is ultimately wasted. > * The Policy as written does not make inside NAT pool addresses an > invalid use of current or newly-allocated space (aka, it doesn't > *require* the use of shared space for an inside NAT pool), I think this is a legitimate criticism and would favor adding language to this effect to the draft policy. Would you support it with that change? [WEG] If you think it's a legitimate concern, I'd recommend making the change, but that change by itself doesn't address all of my concerns. > * While neither IETF nor ARIN can exactly condone squatting on > allocated but unrouted space, I believe this to be an acceptable > alternative should RFC1918 be found unsuitable as an inside NAT pool. Whether you consider it acceptable or not, it comes with greater risks than simply gobbling up significant resources from the free pool, so, I suspect the less risky behavior is more likely. [WEG] I agree, which is why I made the comments I made above. I'm just apparently more cynical about the potential course of action this policy generates within said mega-ISPs. Consider this: CGN sucks, I don't want to do it unless I absolutely have to, so why should I give up my place in line for some of the last remaining resources and do it earlier, especially if I *know* it's going to break things and potentially make me lose some of my customers? That's competitive advantage if I don't have to do it as soon as one of my rivals (or at all). Is that so far-fetched of an argument? Why would the presence of a shared block alter that? It just removes one risk associated with which address range to use. That's it. > * If neither of the above are viable for some reason, we are within > our rights to expect ISPs to carve out a block of their existing space > for this use - CGN applied to their existing deployment would allow > them to reclaim addresses by sharing them among more than one > customer, freeing addresses to be used as an internal NAT pool. > Nevermind the idea of creating an incentive for more efficient use of > IPv4 in infrastructure (1918, moving to IPv6, etc) But current policy doesn't require this, so, I'm not sure why you think it would magically happen. [WEG] I'm not expecting magic. However, if current policy is not changed, (and likely even if it is) ISPs will continue using addresses BAU until they can't get any more. At that time, and IMO *only* at that time, they will seriously implement CGN to manage new growth. Those who aren't planning to wait for that trigger point to be at least close have already implemented it, meaning that they've already found an acceptable (to them) solution to this problem that you're convinced has only one good solution. If there is no reserved pool of addresses, what choice do those who haven't implemented CGN yet have but to figure something else out like I list above? There's no need for policy to enforce it unless you want to try to legislate this behavior *prior* to ARIN's exhaustion making it necessary. Wes George -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From info at arin.net Wed Feb 23 20:47:30 2011 From: info at arin.net (ARIN) Date: Wed, 23 Feb 2011 20:47:30 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks Message-ID: <4D65B8B2.9070702@arin.net> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks ARIN acknowledges receipt of the policy proposal that can be found below. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 23 Feb 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.x. Opt-out Allowed ARIN provides IP address registry services to all IP address holders in the ARIN region, for all IP address resources that are not registered by another RIR, regardless of whether any given address holder has entered into a services agreement. However, ARIN will cease providing any registry services for specific IP address resources in the event that the legitimate address holder of an unaffiliated address block, that is an address block that is not covered by an ongoing services agreement, chooses to opt-out of receiving any or all registry services from ARIN. 13.x.1. Requirements for Whois Opt-out In order for an opt-out request for Whois directory services to be valid, the legitimate address holder must agree to provide a replacement directory service reflecting operationally accurate allocation and assignment information for the specified IP number resources. ARIN will create generic placeholder entries in the ARIN Whois directory for all IP number resources that are removed due to opt-out, and each placeholder entry will include a reference and/or RWhois referral to the replacement directory service. Rationale: This proposal does not seek to replace ARIN-prop-133 but is offered as an exclusive alternative for consideration by the ARIN community, in order to address concerns that it would unfairly harm legacy address holders and/or cause unnecessary damage to the Whois database. Policy Background: This policy attempts to clarify the relationship that ARIN has with legacy address holders. Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical. This policy assumes the tacit consent of all address holders in the ARIN region, to receive ARIN registry services and to be governed by ARIN policy, but allows for legitimate address holders of unaffiliated address blocks to explicitly opt-out of any and/or all services. This approach would allow ARIN to continue providing volunteer services to any member of the legacy community as long as this service was not contrary to their wishes. Further, it would allow legacy address holders to opt-out of some services such as Whois while continuing to receive other services such as in-addr DNS reverse mapping. In the event that a legacy address holder does opt-out of Whois directory services under this policy, ARIN would require the address holder to provide a replacement directory service and would continue to provide a Whois pointer (such as a RWhois referral) to that service. As a result, the integrity of the distributed Whois database would remain intact and be improved. Timetable for implementation: Immediately From jmaimon at chl.com Wed Feb 23 22:24:38 2011 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 23 Feb 2011 22:24:38 -0500 Subject: [arin-ppml] Draft Policy 2011-6: Returned IPv4 Addresses In-Reply-To: <4D631F4F.80408@arin.net> References: <4D631F4F.80408@arin.net> Message-ID: <4D65CF76.1020203@chl.com> ARIN wrote: > Draft Policy ARIN-2011-6 > Returned IPv4 Addresses Without indication of it being a problem, either currently or in the near future, I dont support dictating schedules to ARIN staff where they already have existing practices that appear to serve quite well. If all this proposal is saying is that ARIN will not return space from its region to IANA under any form and for any reason, let it just say so. I dont support return to IANA because that causes negative competition and incentive for global conservation, unless some binding common denominator can be reached, much the same way I would not support intra-rir transfers unless the recipient would qualify under policy of both. I suppose this issue could be solved much the same way that intra-region transfers were. Let the RiR's negotiate for space between themselves and then pass it through IANA earmarked to the agreed upon destination, passing muster with IANA policy along the way. Schedules and timelines for recycled resources may very well be an issue. As it stands these two issues are conflated and I cant support the draft as written. Joe From jmaimon at chl.com Wed Feb 23 22:07:47 2011 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 23 Feb 2011 22:07:47 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> Message-ID: <4D65CB83.6050303@chl.com> George, Wes E [NTK] wrote: > -----Original Message----- > [WEG] No, I don' t think that it is, even when you phrase it like that. > * I reject the argument that we have one or more "mega-ISPs" waiting for this policy to die so that > they can make that final large allocation request (or to live so that they don't have to). Fully agree. Any entity that wants this /10 for their own projected use wants it for when there is no ARIN /10 available to anyone. Until that point they will continue to make and justify requests just like always. This draft has zero conservation effect. I dont support it. On the contrary, it is throwing a quarter of the last IANA allocation away and it will never be coming back, ever. I should hope much better uses for it could be found if carving that size chunk off is back on the table. How about guaranteeing new entrants? Or those with only a thimbleful compared to those with buckets? Options for these folks will be a whole lot more limited. I submit that it is a much larger problem for these folks to deploy LSN and whatever else will continue to be required until it truly is the year of IPv6. Yes, let us sit idly by while a tier-1 monopoly on identifiers forms. Aside from that, I would support a proposal that reserves a /10 or larger for future general unicast uses, including a possible shared pool, to be determined only after ARIN exhausts. I would consider that to be a much wiser course of action. > * The Policy as written does not make inside NAT pool addresses an invalid use of current or > newly-allocated space "Invalid use" season open already? Plenty of targets in that direction if we want to go there. I dont. > CGN applied to their existing deployment > would allow them to reclaim addresses by sharing them among more than one customer, freeing > addresses to be used as an internal NAT pool. If CGN actually solves the problem well enough to be in real use for new users, what leads you to believe that only there it will be used? I dont. I expect it will be used to downgrade a significant portion of users to a new lower tier service and to monetize the resulting available resources. All in the name of equality. They will even have enough addresses on hand at that point to easily solve the problems of any annoying or troublesome pesky users. For a few dollars more MRC naturally. Let these now rich in resources create their own pool from the glut they will then have available. Betcha there is another less publicized flag day coming. How about give something back to the rest of us and at least make an attempt to rehabilitate E. Past procrastination is not a legitimate justification for its continuance. I wonder what is considered to be in the better interests of subscriber providers, to have users noticing that their wan address is a well known non-unique/cgn address or to muddy the waters a bit? That may have something to do with the apparent distaste for RFC1918, perhaps even more so than a problem that appears to be blown well out of proportion, even accepting on its face the position that it is a problem that the community as a whole should be addressing. I dont. I actually have a small teeny weeny suggestion to these providers. Modify your DHCP servers so that DHCP clients that consistently refuse your addresses are offered from a different scope that may be more acceptable to them. Problem solved. There is no CPE that uses ranges from 10/8 172.16/12 and 192.168/16 simultaneously by default. Joe From jeffrey.lyon at blacklotus.net Wed Feb 23 22:33:05 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 23 Feb 2011 22:33:05 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D65CB83.6050303@chl.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <4D65CB83.6050303@chl.com> Message-ID: > How about guaranteeing new entrants? Or those with only a thimbleful > compared to those with buckets? Options for these folks will be a whole lot > more limited. I submit that it is a much larger problem for these folks to > deploy LSN and whatever else will continue to be required until it truly is > the year of IPv6. This interests me. Are you saying that IPv4 space should be limited to small allocations in order to ensure that IPv4 stays open to new organizations while encouraging the migration to IPv6 for current heavy users? -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From jmaimon at chl.com Wed Feb 23 22:42:21 2011 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 23 Feb 2011 22:42:21 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D65B8B2.9070702@arin.net> References: <4D65B8B2.9070702@arin.net> Message-ID: <4D65D39D.8020401@chl.com> ARIN wrote: > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > ARIN members wish ARIN to strive for uniqueness. That is its raison detre. Excluding numbers from the database of unique numbers is impossible. It is either unique or it is not and it must be recorded as such. Encouraging fragmentation is a trojan horse that will serve to undermine credibility and faith in ARIN. I dont support any proposals that may cause that, much the same way that I dont support proposals that serve merely to escalate tensions between ARIN and its members, in the most expansive form of the term. > 13.x.1. Requirements for Whois Opt-out > Lets not forget RWHOIS - but I presume you are not referring to that. Whois is not just a service provided to the holder of the block. It is a service provided to the world for various good reasons. But more importantly, it is a service to the ARIN members reflecting the values of the database of uniqueness. This database of uniqueness is what ARIN members value about ARIN. The more complete it is, the better. The holders of the resources presumably have no need of the Whois entry to support their hold on the resources. If they do, then if and when ARIN revokes resources not held by a contracted member, they may lose uniqueness value with little recourse. I suggest they sign a contract sooner than that. Intentionally degrading whois relation to reality for no other purpose serves no one. The LRSA is already a form of opt-in, allowing for a continued implicit opt-out. Joe From jmaimon at chl.com Wed Feb 23 22:45:44 2011 From: jmaimon at chl.com (Joe Maimon) Date: Wed, 23 Feb 2011 22:45:44 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <4D65CB83.6050303@chl.com> Message-ID: <4D65D468.4080000@chl.com> Jeffrey Lyon wrote: >> How about guaranteeing new entrants? Or those with only a thimbleful >> compared to those with buckets? Options for these folks will be a whole lot >> more limited. I submit that it is a much larger problem for these folks to >> deploy LSN and whatever else will continue to be required until it truly is >> the year of IPv6. >> > > This interests me. Are you saying that IPv4 space should be limited to > small allocations in order to ensure that IPv4 stays open to new > organizations while encouraging the migration to IPv6 for current > heavy users? > > Yes, there should be IPv4 space set aside available to those who have none. I also believe there should be IPv4 space set aside available to those who have next to none. http://lists.arin.net/pipermail/arin-ppml/2010-April/017321.html http://lists.arin.net/pipermail/arin-ppml/2010-May/017523.html Apparently it is not a popular idea here. Joe From Keith at jcc.com Wed Feb 23 23:29:00 2011 From: Keith at jcc.com (Keith W. Hare) Date: Wed, 23 Feb 2011 23:29:00 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D65B8B2.9070702@arin.net> References: <4D65B8B2.9070702@arin.net> Message-ID: <8d75e1781ebad5a4f4f1e11c0a039a314d65ddbd@jcc.com> I am opposed to prop-136. Prop-136 is dancing around the edges of the real question of whether the ARIN community wants to give up on participant-driven policies and needs-based resource allocations in favor of money-based allocations and for-profit corporate policies. If Mr. Schliesser really thinks that some number of for-profit registry services are a better way to handle IPv4 address allocations (or assignments) then he should write a proposal to do that. Such a proposal would allow the ARIN community to discuss the merits of such a change, rather than spending time on intermediate steps and side issues. Keith Hare ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, February 23, 2011 8:48 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks if you experience any issues. From frnkblk at iname.com Thu Feb 24 00:37:53 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 23 Feb 2011 23:37:53 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks Message-ID: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> Unless someone demonstrates that there is a pressing issue or problem, I am opposed to this proposal. I understand that legacy address holders may be unrepresented in the policy development process, so others will have to pipe up if they can help clarifiy. This is not the first proposal by Mr. Schliesser where the cart seems to be before the horse. Let's not create or modify policies unless there's a real problem to solve or a great opportunity. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, February 23, 2011 7:48 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks ARIN acknowledges receipt of the policy proposal that can be found below. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 23 Feb 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.x. Opt-out Allowed ARIN provides IP address registry services to all IP address holders in the ARIN region, for all IP address resources that are not registered by another RIR, regardless of whether any given address holder has entered into a services agreement. However, ARIN will cease providing any registry services for specific IP address resources in the event that the legitimate address holder of an unaffiliated address block, that is an address block that is not covered by an ongoing services agreement, chooses to opt-out of receiving any or all registry services from ARIN. 13.x.1. Requirements for Whois Opt-out In order for an opt-out request for Whois directory services to be valid, the legitimate address holder must agree to provide a replacement directory service reflecting operationally accurate allocation and assignment information for the specified IP number resources. ARIN will create generic placeholder entries in the ARIN Whois directory for all IP number resources that are removed due to opt-out, and each placeholder entry will include a reference and/or RWhois referral to the replacement directory service. Rationale: This proposal does not seek to replace ARIN-prop-133 but is offered as an exclusive alternative for consideration by the ARIN community, in order to address concerns that it would unfairly harm legacy address holders and/or cause unnecessary damage to the Whois database. Policy Background: This policy attempts to clarify the relationship that ARIN has with legacy address holders. Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical. This policy assumes the tacit consent of all address holders in the ARIN region, to receive ARIN registry services and to be governed by ARIN policy, but allows for legitimate address holders of unaffiliated address blocks to explicitly opt-out of any and/or all services. This approach would allow ARIN to continue providing volunteer services to any member of the legacy community as long as this service was not contrary to their wishes. Further, it would allow legacy address holders to opt-out of some services such as Whois while continuing to receive other services such as in-addr DNS reverse mapping. In the event that a legacy address holder does opt-out of Whois directory services under this policy, ARIN would require the address holder to provide a replacement directory service and would continue to provide a Whois pointer (such as a RWhois referral) to that service. As a result, the integrity of the distributed Whois database would remain intact and be improved. Timetable for implementation: Immediately _______________________________________________ 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 frnkblk at iname.com Thu Feb 24 00:37:51 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 23 Feb 2011 23:37:51 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks Message-ID: <015801cbd3e4$faafcaa0$f00f5fe0$@iname.com> Unless someone demonstrates that there is a pressing issue or problem, I am opposed to this proposal. I understand that legacy address holders may be unrepresented in the policy development process, so others will have to pipe up if they can help clarifiy. This is not the first proposal by Mr. Schliesser where the cart seems to be before the horse. Let's not create or modify policies unless there's a real problem to solve or a great opportunity. Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, February 23, 2011 7:48 PM To: arin-ppml at arin.net Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks ARIN acknowledges receipt of the policy proposal that can be found below. The ARIN Advisory Council (AC) will review the proposal at their next regularly scheduled meeting (if the period before the next regularly scheduled meeting is less than 10 days, then the period may be extended to the subsequent regularly scheduled meeting). The AC will decide how to utilize the proposal and announce the decision to the PPML. The AC invites everyone to comment on the proposal on the PPML, particularly their support or non-support and the reasoning behind their opinion. Such participation contributes to a thorough vetting and provides important guidance to the AC in their deliberations. Draft Policies and Proposals under discussion can be found 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 Mailing list subscription information can be found at: https://www.arin.net/mailing_lists/ Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks Proposal Originator: Benson Schliesser Proposal Version: 1 Date: 23 Feb 2011 Proposal type: New Policy term: Permanent Policy statement: Add the following to the NRPM: 13. Unaffiliated Address Blocks 13.x. Opt-out Allowed ARIN provides IP address registry services to all IP address holders in the ARIN region, for all IP address resources that are not registered by another RIR, regardless of whether any given address holder has entered into a services agreement. However, ARIN will cease providing any registry services for specific IP address resources in the event that the legitimate address holder of an unaffiliated address block, that is an address block that is not covered by an ongoing services agreement, chooses to opt-out of receiving any or all registry services from ARIN. 13.x.1. Requirements for Whois Opt-out In order for an opt-out request for Whois directory services to be valid, the legitimate address holder must agree to provide a replacement directory service reflecting operationally accurate allocation and assignment information for the specified IP number resources. ARIN will create generic placeholder entries in the ARIN Whois directory for all IP number resources that are removed due to opt-out, and each placeholder entry will include a reference and/or RWhois referral to the replacement directory service. Rationale: This proposal does not seek to replace ARIN-prop-133 but is offered as an exclusive alternative for consideration by the ARIN community, in order to address concerns that it would unfairly harm legacy address holders and/or cause unnecessary damage to the Whois database. Policy Background: This policy attempts to clarify the relationship that ARIN has with legacy address holders. Specifically, this policy recognizes that absent an agreement such as the RSA or LRSA there is no formal relationship with legacy address holders. At present, however, ARIN continues to provide services to these organizations. This is done without compensation and potentially in opposition to the legacy address holders' wishes. As a result of this behavior ARIN has created an illusion of implied authority that exposes ARIN to unacceptable levels of liability, is hindering the development of an open address market (driving it "underground"), and is putting the operational stability of the Internet at risk. As new services such as RPKI are contemplated this situation becomes even more critical. This policy assumes the tacit consent of all address holders in the ARIN region, to receive ARIN registry services and to be governed by ARIN policy, but allows for legitimate address holders of unaffiliated address blocks to explicitly opt-out of any and/or all services. This approach would allow ARIN to continue providing volunteer services to any member of the legacy community as long as this service was not contrary to their wishes. Further, it would allow legacy address holders to opt-out of some services such as Whois while continuing to receive other services such as in-addr DNS reverse mapping. In the event that a legacy address holder does opt-out of Whois directory services under this policy, ARIN would require the address holder to provide a replacement directory service and would continue to provide a Whois pointer (such as a RWhois referral) to that service. As a result, the integrity of the distributed Whois database would remain intact and be improved. Timetable for implementation: Immediately _______________________________________________ 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 Feb 24 02:28:41 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Feb 2011 23:28:41 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> Message-ID: <0B91AA25-7F0D-4A63-A348-C7CCE92B86FC@delong.com> On Feb 23, 2011, at 9:37 PM, Frank Bulk wrote: > Unless someone demonstrates that there is a pressing issue or problem, I am > opposed to this proposal. I understand that legacy address holders may be > unrepresented in the policy development process, so others will have to pipe > up if they can help clarifiy. > If they are unrepresented, it is because they choose not to represent themselves. The policy process is completely open to them. Owen From jeffrey.lyon at blacklotus.net Thu Feb 24 05:37:49 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 24 Feb 2011 05:37:49 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D65D468.4080000@chl.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <4D65CB83.6050303@chl.com> <4D65D468.4080000@chl.com> Message-ID: On Wed, Feb 23, 2011 at 10:45 PM, Joe Maimon wrote: > > > Jeffrey Lyon wrote: >>> >>> How about guaranteeing new entrants? Or those with only a thimbleful >>> compared to those with buckets? Options for these folks will be a whole >>> lot >>> more limited. I submit that it is a much larger problem for these folks >>> to >>> deploy LSN and whatever else will continue to be required until it truly >>> is >>> the year of IPv6. >>> >> >> This interests me. Are you saying that IPv4 space should be limited to >> small allocations in order to ensure that IPv4 stays open to new >> organizations while encouraging the migration to IPv6 for current >> heavy users? >> >> > > Yes, there should be IPv4 space set aside available to those who have none. > > I also believe there should be IPv4 space set aside available to those who > have next to none. > > http://lists.arin.net/pipermail/arin-ppml/2010-April/017321.html > > http://lists.arin.net/pipermail/arin-ppml/2010-May/017523.html > > Apparently it is not a popular idea here. > > Joe > I like the idea, at least on its surface. Would the reversed IP's be for new organizations only or merely reserved for small allocations? What do you consider small? /21, /20, /19 etc? Perhaps you could propose a policy that would set a maximum size for a IPv4 request and require those with needs in excess to migrate to IPv6. The questions becomes whether the maximum size would be per request or aggregate? As I understand it now, IPv4 will always be available in some form but the new entrants will have to get in line to wait for the space to become available or grease the palms of another company wanting to "sell" their allocation. A policy like this could keep the door open for those who need to get in the door with IPv4 before they're able to move on to IPv6. Personally, I would like to see a policy like this extended to those who are technically inhibited from adopting IPv6 who have an interim need for small IPv4 allocations and perhaps add the following to IPv4 justification requirements: - Why IPv4 is needed vs. IPv6. - When does the organization intend to renumber and return the IPv4 space. - What technical limitations are preventing adoption of IPv6 between now and the aforementioned date. Lastly, ARIN could create a financial incentive for those who opt to return IPv4 space or move from IPv4 to IPv6 in an expeditious fashion which would further support a policy like the one stated above. This could be a fee waiver credit or permanently reduced fees for those organizations meeting certain criteria and quickly returning unneeded IPv4 space. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From kkargel at polartel.com Thu Feb 24 11:09:31 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Thu, 24 Feb 2011 10:09:31 -0600 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks] In-Reply-To: <4D65B8D8.7010204@arin.net> References: <4D65B8D8.7010204@arin.net> Message-ID: <8695009A81378E48879980039EEDAD288C048DC8@MAIL1.polartel.local> Opposed. I see this as just another attack trying to intimidate legacy users in to an LRSA. I am not a legacy user and I have no dog in this fight, but strong arm tactics against the pioneers of the internet are just wrong. Kevin > -----Original Message----- > From: arin-announce-bounces at arin.net [mailto:arin-announce- > bounces at arin.net] On Behalf Of ARIN > Sent: Wednesday, February 23, 2011 7:48 PM > To: arin-announce at arin.net > Subject: [arin-announce] [Fwd: ARIN-prop-136 Services Opt-out Allowed for > Unaffiliated Address Blocks] > > The following is a new policy proposal that has been posted to the ARIN > Public Policy Mailing List for discussion on that list. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > -------- Original Message -------- > Subject: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated > Address Blocks > Date: Wed, 23 Feb 2011 20:47:30 -0500 > From: ARIN > To: arin-ppml at arin.net > > > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > ARIN acknowledges receipt of the policy proposal that can be found below. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning > behind their opinion. Such participation contributes to a thorough > vetting and provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 23 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. Opt-out Allowed > > ARIN provides IP address registry services to all IP address holders in > the ARIN region, for all IP address resources that are not registered by > another RIR, regardless of whether any given address holder has entered > into a services agreement. However, ARIN will cease providing any > registry services for specific IP address resources in the event that > the legitimate address holder of an unaffiliated address block, that is > an address block that is not covered by an ongoing services agreement, > chooses to opt-out of receiving any or all registry services from ARIN. > > 13.x.1. Requirements for Whois Opt-out > > In order for an opt-out request for Whois directory services to be > valid, the legitimate address holder must agree to provide a replacement > directory service reflecting operationally accurate allocation and > assignment information for the specified IP number resources. ARIN will > create generic placeholder entries in the ARIN Whois directory for all > IP number resources that are removed due to opt-out, and each > placeholder entry will include a reference and/or RWhois referral to the > replacement directory service. > > > Rationale: > > This proposal does not seek to replace ARIN-prop-133 but is offered as > an exclusive alternative for consideration by the ARIN community, in > order to address concerns that it would unfairly harm legacy address > holders and/or cause unnecessary damage to the Whois database. > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy assumes the tacit consent of all address holders in the ARIN > region, to receive ARIN registry services and to be governed by ARIN > policy, but allows for legitimate address holders of unaffiliated > address blocks to explicitly opt-out of any and/or all services. This > approach would allow ARIN to continue providing volunteer services to > any member of the legacy community as long as this service was not > contrary to their wishes. Further, it would allow legacy address > holders to opt-out of some services such as Whois while continuing to > receive other services such as in-addr DNS reverse mapping. > > In the event that a legacy address holder does opt-out of Whois > directory services under this policy, ARIN would require the address > holder to provide a replacement directory service and would continue to > provide a Whois pointer (such as a RWhois referral) to that service. As > a result, the integrity of the distributed Whois database would remain > intact and be improved. > > Timetable for implementation: Immediately > > > > > > _______________________________________________ > ARIN-Announce > You are receiving this message because you are subscribed to > the ARIN Announce Mailing List (ARIN-announce at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-announce > Please contact info at arin.net if you experience any issues. From bill at herrin.us Thu Feb 24 11:27:55 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Feb 2011 11:27:55 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> Message-ID: On Wed, Feb 23, 2011 at 11:16 AM, Owen DeLong wrote: > I think that isn't the argument. I think the argument is we have one or more mega-ISPs wanting > this policy to pass, but if it does not, will be forced to apply for resources for [NAT444]. > Current policy allows for them to number the necessary hosts accordingly, so, if this policy > does not pass, there is nothing at all that would prevent them from each obtaining large > blocks of addresses for this purpose. I don't know if any one of them could justify a /10 > individually, but, I am quite certain that they can collectively easily exceed a /10. I'd estimate > that they can probably come close to a /7, collectively. s/forced/choose/ They -could- choose to use RFC1918 addresses. They won't for all the reasons you've said. But they could. Otherwise, agree with everything above. So, Wes, Owen: Let's put our money where our mouths are so to speak. If these addresses won't be wasted, let's require the policy to prove it. Adjust the policy so that: 1) Within 6 months of ratification at least 10 ARIN allocation holders must register with ARIN an intent to use addresses within the /10 in their network within 24 months. If fewer than 10 register that intent then the policy is void and the /10 is returned to the ARIN pool. 2) After the first 24 months and every 24 months thereafter ARIN must review the use of the /10 and make a positive determination that at least 10 ARIN allocation holders are actually using it. If fewer than 10 are using it and ARIN does not otherwise have at least a /8-equivalent available for allocation (i.e. IPv4 isn't yet on the decline), the whole pool is recycled into ARIN's free pool with a 12 month delay for the 9 or fewer folks using it to renumber. Owen, if we can't find 10 ISPs who are willing to step up and say they'll use these addresses then Wes will have made his point: this won't be a good use of a /10. Can you accept that result? Wes, if a non-trivial number of ISPs actually use the addresses in parallel then plainly this was a better use than assigning the addresses to ISPs individually. Can you accept that result? I hear a lot of ideology in this debate. Are either/both of you willing to measure and follow the data instead? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From arin-ppml at westbrook.com Thu Feb 24 11:32:56 2011 From: arin-ppml at westbrook.com (Eric Westbrook) Date: Thu, 24 Feb 2011 09:32:56 -0700 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <0B91AA25-7F0D-4A63-A348-C7CCE92B86FC@delong.com> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> <0B91AA25-7F0D-4A63-A348-C7CCE92B86FC@delong.com> Message-ID: On Thu, Feb 24, 2011 at 00:28, Owen DeLong wrote: > On Wed, Feb 23, 2011 at 22:37, Frank Bulk wrote: > > Unless someone demonstrates that there is a pressing issue or problem, I > am > > opposed to this proposal. I understand that legacy address holders may > be > > unrepresented in the policy development process, so others will have to > pipe > > up if they can help clarifiy. > If they are unrepresented, it is because they choose not to represent > themselves. > The policy process is completely open to them. > Not completely unrepresented. I am such, and I do represent myself here when time permits. I know that some other legacy holders have views similar to mine, but certainly not all, so you should be your own judge of how "representative" I am. Nevertheless, I'm happy for the chance to offer my US$0.02 on the topic. As I mentioned in the prop 133 discussion, as a non-LRSA legacy holder, I can imagine no present or forseeable "problem" that these alternative registries would serve to fix. Indeed, I cannot posit any situation in which it would be of any appreciable benefit to me ever, full stop. I'm left to wildly speculate that it would only really benefit someone looking to carve out a new registry business model for themselves. $0.02 as advertised, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 24 11:43:25 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 08:43:25 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> Message-ID: <8DEB5B81-B275-4822-8C78-E0AFE39E5198@delong.com> I would support change number 1. I would argue that change number 2 is unnecessary and potentially harmful. Why should 9 ISPs who have made very large use of this space suddenly have it revoked simply because they are the last 9 to deprecate its use? Owen On Feb 24, 2011, at 8:27 AM, William Herrin wrote: > On Wed, Feb 23, 2011 at 11:16 AM, Owen DeLong wrote: >> I think that isn't the argument. I think the argument is we have one or more mega-ISPs wanting >> this policy to pass, but if it does not, will be forced to apply for resources for [NAT444]. >> Current policy allows for them to number the necessary hosts accordingly, so, if this policy >> does not pass, there is nothing at all that would prevent them from each obtaining large >> blocks of addresses for this purpose. I don't know if any one of them could justify a /10 >> individually, but, I am quite certain that they can collectively easily exceed a /10. I'd estimate >> that they can probably come close to a /7, collectively. > > s/forced/choose/ > > They -could- choose to use RFC1918 addresses. They won't for all the > reasons you've said. But they could. > > Otherwise, agree with everything above. > > > So, Wes, Owen: Let's put our money where our mouths are so to speak. > If these addresses won't be wasted, let's require the policy to prove > it. Adjust the policy so that: > > 1) Within 6 months of ratification at least 10 ARIN allocation holders > must register with ARIN an intent to use addresses within the /10 in > their network within 24 months. If fewer than 10 register that intent > then the policy is void and the /10 is returned to the ARIN pool. > > 2) After the first 24 months and every 24 months thereafter ARIN must > review the use of the /10 and make a positive determination that at > least 10 ARIN allocation holders are actually using it. If fewer than > 10 are using it and ARIN does not otherwise have at least a > /8-equivalent available for allocation (i.e. IPv4 isn't yet on the > decline), the whole pool is recycled into ARIN's free pool with a 12 > month delay for the 9 or fewer folks using it to renumber. > > > Owen, if we can't find 10 ISPs who are willing to step up and say > they'll use these addresses then Wes will have made his point: this > won't be a good use of a /10. Can you accept that result? > > Wes, if a non-trivial number of ISPs actually use the addresses in > parallel then plainly this was a better use than assigning the > addresses to ISPs individually. Can you accept that result? > > > I hear a lot of ideology in this debate. Are either/both of you > willing to measure and follow the data instead? > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 From bensons at queuefull.net Thu Feb 24 12:26:30 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Feb 2011 11:26:30 -0600 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks] In-Reply-To: <8695009A81378E48879980039EEDAD288C048DC8@MAIL1.polartel.local> References: <4D65B8D8.7010204@arin.net> <8695009A81378E48879980039EEDAD288C048DC8@MAIL1.polartel.local> Message-ID: <42B3DDD0-A209-472F-9B92-FE56ECC87A60@queuefull.net> Hi, Kevin. On Feb 24, 2011, at 10:09 AM, Kevin Kargel wrote: > Opposed. I see this as just another attack trying to intimidate legacy users in to an LRSA. I am not a legacy user and I have no dog in this fight, but strong arm tactics against the pioneers of the internet are just wrong. Although it is not my intent, I can see how prop-133 might receive this criticism. However, I don't see how your comment applies to this proposal (prop-136). Can you point to any text in the policy statement that leads you to your conclusion? I would like to understand how you reached it. Cheers, -Benson >> -----Original Message----- >> From: arin-announce-bounces at arin.net [mailto:arin-announce- >> bounces at arin.net] On Behalf Of ARIN >> Sent: Wednesday, February 23, 2011 7:48 PM >> To: arin-announce at arin.net >> Subject: [arin-announce] [Fwd: ARIN-prop-136 Services Opt-out Allowed for >> Unaffiliated Address Blocks] >> >> The following is a new policy proposal that has been posted to the ARIN >> Public Policy Mailing List for discussion on that list. >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> -------- Original Message -------- >> Subject: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated >> Address Blocks >> Date: Wed, 23 Feb 2011 20:47:30 -0500 >> From: ARIN >> To: arin-ppml at arin.net >> >> >> >> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks >> >> ARIN acknowledges receipt of the policy proposal that can be found below. >> >> The ARIN Advisory Council (AC) will review the proposal at their next >> regularly scheduled meeting (if the period before the next regularly >> scheduled meeting is less than 10 days, then the period may be extended >> to the subsequent regularly scheduled meeting). The AC will decide how >> to utilize the proposal and announce the decision to the PPML. >> >> The AC invites everyone to comment on the proposal on the PPML, >> particularly their support or non-support and the reasoning >> behind their opinion. Such participation contributes to a thorough >> vetting and provides important guidance to the AC in their deliberations. >> >> Draft Policies and Proposals under discussion can be found 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 >> >> Mailing list subscription information can be found >> at: https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks >> >> Proposal Originator: Benson Schliesser >> >> Proposal Version: 1 >> >> Date: 23 Feb 2011 >> >> Proposal type: New >> >> Policy term: Permanent >> >> Policy statement: >> >> Add the following to the NRPM: >> >> 13. Unaffiliated Address Blocks >> >> 13.x. Opt-out Allowed >> >> ARIN provides IP address registry services to all IP address holders in >> the ARIN region, for all IP address resources that are not registered by >> another RIR, regardless of whether any given address holder has entered >> into a services agreement. However, ARIN will cease providing any >> registry services for specific IP address resources in the event that >> the legitimate address holder of an unaffiliated address block, that is >> an address block that is not covered by an ongoing services agreement, >> chooses to opt-out of receiving any or all registry services from ARIN. >> >> 13.x.1. Requirements for Whois Opt-out >> >> In order for an opt-out request for Whois directory services to be >> valid, the legitimate address holder must agree to provide a replacement >> directory service reflecting operationally accurate allocation and >> assignment information for the specified IP number resources. ARIN will >> create generic placeholder entries in the ARIN Whois directory for all >> IP number resources that are removed due to opt-out, and each >> placeholder entry will include a reference and/or RWhois referral to the >> replacement directory service. >> >> >> Rationale: >> >> This proposal does not seek to replace ARIN-prop-133 but is offered as >> an exclusive alternative for consideration by the ARIN community, in >> order to address concerns that it would unfairly harm legacy address >> holders and/or cause unnecessary damage to the Whois database. >> >> Policy Background: >> >> This policy attempts to clarify the relationship that ARIN has with >> legacy address holders. >> >> Specifically, this policy recognizes that absent an agreement such as >> the RSA or LRSA there is no formal relationship with legacy address >> holders. At present, however, ARIN continues to provide services to >> these organizations. This is done without compensation and potentially >> in opposition to the legacy address holders' wishes. As a result of >> this behavior ARIN has created an illusion of implied authority that >> exposes ARIN to unacceptable levels of liability, is hindering the >> development of an open address market (driving it "underground"), and is >> putting the operational stability of the Internet at risk. As new >> services such as RPKI are contemplated this situation becomes even more >> critical. >> >> This policy assumes the tacit consent of all address holders in the ARIN >> region, to receive ARIN registry services and to be governed by ARIN >> policy, but allows for legitimate address holders of unaffiliated >> address blocks to explicitly opt-out of any and/or all services. This >> approach would allow ARIN to continue providing volunteer services to >> any member of the legacy community as long as this service was not >> contrary to their wishes. Further, it would allow legacy address >> holders to opt-out of some services such as Whois while continuing to >> receive other services such as in-addr DNS reverse mapping. >> >> In the event that a legacy address holder does opt-out of Whois >> directory services under this policy, ARIN would require the address >> holder to provide a replacement directory service and would continue to >> provide a Whois pointer (such as a RWhois referral) to that service. As >> a result, the integrity of the distributed Whois database would remain >> intact and be improved. >> >> Timetable for implementation: Immediately >> >> >> >> >> >> _______________________________________________ >> ARIN-Announce >> You are receiving this message because you are subscribed to >> the ARIN Announce Mailing List (ARIN-announce at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-announce >> Please contact 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 bensons at queuefull.net Thu Feb 24 12:35:56 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Feb 2011 11:35:56 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D65D39D.8020401@chl.com> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> Message-ID: Hi, Joe. On Feb 23, 2011, at 9:42 PM, Joe Maimon wrote: > ARIN wrote: >> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks >> > > ARIN members wish ARIN to strive for uniqueness. That is its raison detre. Excluding numbers from the database of unique numbers is impossible. It is either unique or it is not and it must be recorded as such. I understand your point of view, and in fact I was motivated to create prop-136 in order to deal with this issue. To be clear: prop-136 doesn't remove anything from the Whois, unless requested by a legacy holder, and then only if the legacy holder is providing a rWhois service. > Encouraging fragmentation is a trojan horse that will serve to undermine credibility and faith in ARIN. I dont support any proposals that may cause that, much the same way that I dont support proposals that serve merely to escalate tensions between ARIN and its members, in the most expansive form of the term. I actually intend prop-136 as a tool for avoiding escalating tensions. Where prop-133 would require legacy holders to "opt-in", instead prop-136 allows legacy holders to "opt-out". If the ARIN community rejects them both, we're essentially saying that legacy holders have "no option" in being regulated by ARIN. This may or may not be the wish of the community. But I hardly think that such a statement would result in relaxed tensions. Thus prop-136 offers a compromise. Cheers, -Benson From gbonser at seven.com Thu Feb 24 12:45:43 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Feb 2011 09:45:43 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for UnaffiliatedAddress Blocks In-Reply-To: <4D65B8B2.9070702@arin.net> References: <4D65B8B2.9070702@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D22@RWC-EX1.corp.seven.com> Opposed > Behalf Of ARIN > Sent: Wednesday, February 23, 2011 5:48 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for > UnaffiliatedAddress Blocks > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks From bensons at queuefull.net Thu Feb 24 12:52:03 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Feb 2011 11:52:03 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <8d75e1781ebad5a4f4f1e11c0a039a314d65ddbd@jcc.com> References: <4D65B8B2.9070702@arin.net> <8d75e1781ebad5a4f4f1e11c0a039a314d65ddbd@jcc.com> Message-ID: <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> Hi, Keith. On Feb 23, 2011, at 10:29 PM, Keith W. Hare wrote: > I am opposed to prop-136. > > Prop-136 is dancing around the edges of the real question of whether the ARIN community wants to give up on participant-driven policies and needs-based resource allocations in favor of money-based allocations and for-profit corporate policies. I don't think prop-136 dances around the issue: it deals with it directly, for legacy holders in the ARIN region, by allowing them to opt-out of ARIN regulation. > If Mr. Schliesser really thinks that some number of for-profit registry services are a better way to handle IPv4 address allocations (or assignments) then he should write a proposal to do that. Such a proposal would allow the ARIN community to discuss the merits of such a change, rather than spending time on intermediate steps and side issues. I agree that we need a discussion of the for-profit registry question. And I don't expect it to be an easy one, similar to how unfriendly at times the debate over domain names monetization was. However, I think it's perfectly reasonable to answer the question of regulatory authority first. If the ARIN community rejects both prop-133 and prop-136 then we are effectively saying that legacy holders have "no option" but to submit to ARIN regulation. In either event, a discussion of for-profit registry services would have a different foundation and tone. Moreover, while the question of regulatory authority will impact a discussion of for-profit registry services, address trading markets, etc, it is actually a larger fundamental question. I agree that we should discuss the issues you raise, but please don't lose sight of the actual policy text and meaning. Cheers, -Benson From bensons at queuefull.net Thu Feb 24 13:22:26 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Feb 2011 12:22:26 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <015801cbd3e4$faafcaa0$f00f5fe0$@iname.com> References: <015801cbd3e4$faafcaa0$f00f5fe0$@iname.com> Message-ID: Hi, Frank. On Feb 23, 2011, at 11:37 PM, Frank Bulk wrote: > Unless someone demonstrates that there is a pressing issue or problem, I am > opposed to this proposal. Until recently there was no "pressing" need for IPv6, and yet it has been and remains prudent to develop and deploy. Preparing for a situation in advance is not a bad thing. Further, the situation that prop-136 deals with is one of governance. Your argument is akin to "nobody does X, so who cares if X is illegal?" But the fact of illegality drives action underground, and clear insight into the desire / demand is difficult at best in such a situation. In other words, we're talking about a strategic opportunity here rather than a tactical question. Cheers, -Benson From JOHN at egh.com Thu Feb 24 13:23:49 2011 From: JOHN at egh.com (John Santos) Date: Thu, 24 Feb 2011 13:23:49 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: Message-ID: <1110224132339.854B-400000@Ives.egh.com> +1 -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- On Thu, Feb 24, 2011 at 00:28, Owen DeLong wrote: > On Wed, Feb 23, 2011 at 22:37, Frank Bulk wrote: > > Unless someone demonstrates that there is a pressing issue or problem, I > am > > opposed to this proposal. I understand that legacy address holders may > be > > unrepresented in the policy development process, so others will have to > pipe > > up if they can help clarifiy. > If they are unrepresented, it is because they choose not to represent > themselves. > The policy process is completely open to them. > Not completely unrepresented. I am such, and I do represent myself here when time permits. I know that some other legacy holders have views similar to mine, but certainly not all, so you should be your own judge of how "representative" I am. Nevertheless, I'm happy for the chance to offer my US$0.02 on the topic. As I mentioned in the prop 133 discussion, as a non-LRSA legacy holder, I can imagine no present or forseeable "problem" that these alternative registries would serve to fix. Indeed, I cannot posit any situation in which it would be of any appreciable benefit to me ever, full stop. I'm left to wildly speculate that it would only really benefit someone looking to carve out a new registry business model for themselves. $0.02 as advertised, Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jcurran at arin.net Thu Feb 24 13:35:55 2011 From: jcurran at arin.net (John Curran) Date: Thu, 24 Feb 2011 18:35:55 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> References: <4D65B8B2.9070702@arin.net> <8d75e1781ebad5a4f4f1e11c0a039a314d65ddbd@jcc.com> <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> Message-ID: <137033E0-E21F-449A-AA68-7F60D9E28A98@corp.arin.net> On Feb 25, 2011, at 1:52 AM, Benson Schliesser wrote: > On Feb 23, 2011, at 10:29 PM, Keith W. Hare wrote: > >> I am opposed to prop-136. >> >> Prop-136 is dancing around the edges of the real question of whether the ARIN community wants to give up on participant-driven policies and needs-based resource allocations in favor of money-based allocations and for-profit corporate policies. > > I don't think prop-136 dances around the issue: it deals with it directly, for legacy holders in the ARIN region, by allowing them to opt-out of ARIN regulation. > ... > I agree that we should discuss the issues you raise, but please don't lose sight of the actual policy text and meaning. Focusing on the actual policy text and meaning is best. If your goal is to "allow legacy holders in the ARIN region to opt-out of ARIN regulation", then it might be necessary to make the explicit in the policy proposal text, as policy text presently simply makes clear the availability of the option of legacy address to deploy their own distributed Whois services (e.g. rWHois or similar per NRPM 3.2). An address holder who "opts-out" still receives a Whois pointer from ARIN to their local directory service, just as an ISP running their own local directory service. It also appears from legacy holders may or may not still be receiving other services (such as reverse DNS services.) Such service changes would not change the address block being subject to community policies that have been established in the ARIN region, so if changing that fact is the intent of the policy it would be best to be explicit in the actual policy text. I do not know offhand where such a declaration would occur in the ARIN Number Resource Policy Manual since it covers the policies for number resources in the region, and you might need to instead need to propose changing at least the first sentence of ICANN ICP-2 to define new types of entities, as it is quite clear that Regional Internet Registries are"delegated responsibility for management of Internet resources within a given region of the globe." FYI, /John John Curran President and CEO ARIN p.s. Details on revising global policies may be found here: From frnkblk at iname.com Thu Feb 24 13:37:28 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 24 Feb 2011 12:37:28 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <015801cbd3e4$faafcaa0$f00f5fe0$@iname.com> Message-ID: <005d01cbd451$e3c06f30$ab414d90$@iname.com> What is the anticipated situation or strategic opportunity? Frank -----Original Message----- From: Benson Schliesser [mailto:bensons at queuefull.net] Sent: Thursday, February 24, 2011 12:22 PM To: frnkblk at iname.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks Hi, Frank. On Feb 23, 2011, at 11:37 PM, Frank Bulk wrote: > Unless someone demonstrates that there is a pressing issue or problem, I am > opposed to this proposal. Until recently there was no "pressing" need for IPv6, and yet it has been and remains prudent to develop and deploy. Preparing for a situation in advance is not a bad thing. Further, the situation that prop-136 deals with is one of governance. Your argument is akin to "nobody does X, so who cares if X is illegal?" But the fact of illegality drives action underground, and clear insight into the desire / demand is difficult at best in such a situation. In other words, we're talking about a strategic opportunity here rather than a tactical question. Cheers, -Benson From bensons at queuefull.net Thu Feb 24 13:39:48 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Feb 2011 12:39:48 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <1110224132339.854B-400000@Ives.egh.com> References: <1110224132339.854B-400000@Ives.egh.com> Message-ID: <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> > Indeed, I cannot posit any situation in which it would be of any appreciable benefit to me ever, full stop. As a small block holder (/24 IIRC?) that is involved in ARIN policy discussion, you may be correct. > I'm left to wildly speculate that it would only really benefit someone looking to carve out a new registry business model for themselves. The immediate benefit would be for large block holders (with excess resources) to monetize their addresses, and for buyers and/or lessors who need these excess addresses. In the near future there may be benefits in terms of RPKI services, Loc/ID split services (routing facilitation), and other advanced services that could be developed by a commercial routing registry. Prop 136 would open up these opportunities for legacy holders. Subsequent policy would be needed to apply the opportunity to the rest of ARIN (RSA-covered) community. Cheers, -Benson From matthew at matthew.at Thu Feb 24 13:47:28 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 10:47:28 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> Message-ID: <4D66A7C0.4000803@matthew.at> I don't understand the proposal. Are you trying to: A) Keep the registration (uniqueness), whois (at least pointers), and reverse DNS (again, at least pointers) for the legacy address blocks in the ARIN region under ARIN control? (In which case I don't see what anyone would be "opting out" of) B) Remove the legacy address blocks from ARIN control and transfer them to a new entity? (In which case I think you need to be operating under ICANN ICP-2 with regard to the formation of this new entity, and it isn't appropriate for the ARIN PDP) C) Remove the legacy address blocks from ARIN control and NOT transfer them to a new entity? (In which case I'm not sure where you'd go, because ICANN clearly has the assumption that a single RIR will have responsibility for the block(s)) Matthew Kaufman From jcurran at arin.net Thu Feb 24 13:51:05 2011 From: jcurran at arin.net (John Curran) Date: Thu, 24 Feb 2011 18:51:05 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> Message-ID: On Feb 25, 2011, at 2:39 AM, Benson Schliesser wrote: > ... > The immediate benefit would be for large block holders (with excess resources) to monetize their addresses, and for buyers and/or lessors who need these excess addresses. I believe that issue was discussed at length in the ARIN community, and resulted in the specified transfer policy (NRPM 8.3) which provides for precisely that: the ability of any resource holder with excess resources to make them available for transfer and be compensated by the recipient as desired. If the intended benefit of ARIN-prop-136 is to actually to propose alternative transfer policies, it would be best to propose the specific changes to the transfer policy section of NRPM. Thanks! /John John Curran President and CEO ARIN From gbonser at seven.com Thu Feb 24 14:16:56 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Feb 2011 11:16:56 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> References: <4D65B8B2.9070702@arin.net><8d75e1781ebad5a4f4f1e11c0a039a314d65ddbd@jcc.com> <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D2C@RWC-EX1.corp.seven.com> > Behalf Of Benson Schliesser > Sent: Thursday, February 24, 2011 9:52 AM > To: Keith W. Hare > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed > forUnaffiliated Address Blocks > > Hi, Keith. > > On Feb 23, 2011, at 10:29 PM, Keith W. Hare wrote: > > > I am opposed to prop-136. > > > > Prop-136 is dancing around the edges of the real question of whether > the ARIN community wants to give up on participant-driven policies and > needs-based resource allocations in favor of money-based allocations > and for-profit corporate policies. > > I don't think prop-136 dances around the issue: it deals with it > directly, for legacy holders in the ARIN region, by allowing them to > opt-out of ARIN regulation. > What clear and compelling problem is this attempting to solve? This seems like a solution in search of a problem that could likely create more problems than it solves. From owen at delong.com Thu Feb 24 16:58:18 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 13:58:18 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <015801cbd3e4$faafcaa0$f00f5fe0$@iname.com> Message-ID: Sent from my iPad On Feb 24, 2011, at 10:22 AM, Benson Schliesser wrote: > Hi, Frank. > > On Feb 23, 2011, at 11:37 PM, Frank Bulk wrote: >> Unless someone demonstrates that there is a pressing issue or problem, I am >> opposed to this proposal. > > > Until recently there was no "pressing" need for IPv6, and yet it has been and remains prudent to develop and deploy. Preparing for a situation in advance is not a bad thing. > There is a difference between prudent preparation for a known future event (y2k, ipv4 exhaustion), vs. FUD around a conjured or speculative problem that is largely artificial in nature. > Further, the situation that prop-136 deals with is one of governance. Your argument is akin to "nobody does X, so who cares if X is illegal?" But the fact of illegality drives action underground, and clear insight into the desire / demand is difficult at best in such a situation. > ARIN, through the policy development process, governs policy for what is contained in ARINs database of unique numbers. Nothing more, nothing less. if legacy holders do not want a place in that database, current policy allows them to opt out and I'm sure ARIN will be happy to register those numbers to others who prefer to work within the RiR framework. If they want to continue using resources as they have, there is no apparent problem with that and I would not expect one to spring into existence. > In other words, we're talking about a strategic opportunity here rather than a tactical question. > It's a bad strategy designed to resolve a non-existent problem by creating a much worse situation. Owen > Cheers, > -Benson > > _______________________________________________ > 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 Feb 24 17:09:53 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 14:09:53 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> Message-ID: <2151CB44-6849-4FBE-87E1-DB99CF97F8A2@delong.com> On Feb 24, 2011, at 10:39 AM, Benson Schliesser wrote: > >> Indeed, I cannot posit any situation in which it would be of any appreciable benefit to me ever, full stop. > > As a small block holder (/24 IIRC?) that is involved in ARIN policy discussion, you may be correct. > >> I'm left to wildly speculate that it would only really benefit someone looking to carve out a new registry business model for themselves. > > The immediate benefit would be for large block holders (with excess resources) to monetize their addresses, and for buyers and/or lessors who need these excess addresses. > There is a framework for them to do that in the current policy, so, I do not understand why you think this would change that situation in any meaningful way. > In the near future there may be benefits in terms of RPKI services, Loc/ID split services (routing facilitation), and other advanced services that could be developed by a commercial routing registry. > Nothing in ARIN policy or practice prevents those things today. While ARIN runs a routing registry (ARIN IRRDB), that is not particularly coupled with the ARIN PDP or with address registrations in the ARIN databases for uniqueness. I am unsure as to whether the ARIN routing registry is subject to the ARIN Policy process, but, in any case, there are already many routing registries operated independent of ARIN. > Prop 136 would open up these opportunities for legacy holders. Subsequent policy would be needed to apply the opportunity to the rest of ARIN (RSA-covered) community. > So far you haven't stated any opportunities that don't exist in current policy, so, perhaps this is more a case of misunderstanding the current policy framework than of proposing a solution? Owen From springer at inlandnet.com Thu Feb 24 17:56:33 2011 From: springer at inlandnet.com (John Springer) Date: Thu, 24 Feb 2011 14:56:33 -0800 (PST) Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <2151CB44-6849-4FBE-87E1-DB99CF97F8A2@delong.com> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <2151CB44-6849-4FBE-87E1-DB99CF97F8A2@delong.com> Message-ID: <20110224143459.Y46851@mail.inlandnet.com> Hi Owen, Benton On Thu, 24 Feb 2011, Owen DeLong wrote: > > On Feb 24, 2011, at 10:39 AM, Benson Schliesser wrote: > >> The immediate benefit would be for large block holders (with excess resources) to monetize their addresses, and for buyers and/or lessors who need these excess addresses. >> > There is a framework for them to do that in the current policy, so, I do not understand why you think > this would change that situation in any meaningful way. > >> In the near future there may be benefits in terms of RPKI services, Loc/ID split services (routing facilitation), and other advanced services that could be developed by a commercial routing registry. >> > Nothing in ARIN policy or practice prevents those things today. > Thanks for pointing this out, Owen. It seems to be the heart of this particular matter, but also, perhaps coincidentally, several other recent proposals, as well. Anyway, AFA prop-138 IC, I am opposed to it on the grounds that it is apparently redundant. The same observation would seem to serve for proposed rationales advocating governance criteria, too, I think. John Springer From mueller at syr.edu Thu Feb 24 18:04:00 2011 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 24 Feb 2011 18:04:00 -0500 Subject: [arin-ppml] [arin-announce] [Fwd: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks] In-Reply-To: <42B3DDD0-A209-472F-9B92-FE56ECC87A60@queuefull.net> References: <4D65B8D8.7010204@arin.net> <8695009A81378E48879980039EEDAD288C048DC8@MAIL1.polartel.local> <42B3DDD0-A209-472F-9B92-FE56ECC87A60@queuefull.net> Message-ID: <75822E125BCB994F8446858C4B19F0D714409179F6@SUEX07-MBX-04.ad.syr.edu> Correct, Benson. Offering legacy holders a chance to opt out is the opposite of attempting to force them into an LRSA. It actually provides them a viable option to the LRSA. Anyone who sees either 133 or 136 as an attack on legacy holders is not listening to or reading what Benson is proposing. > -----Original Message----- > Hi, Kevin. > > On Feb 24, 2011, at 10:09 AM, Kevin Kargel wrote: > > Opposed. I see this as just another attack trying to intimidate > legacy users in to an LRSA. I am not a legacy user and I have no dog in > this fight, but strong arm tactics against the pioneers of the internet > are just wrong. > > Although it is not my intent, I can see how prop-133 might receive this > criticism. However, I don't see how your comment applies to this > proposal (prop-136). > > Can you point to any text in the policy statement that leads you to your > conclusion? I would like to understand how you reached it. > > Cheers, > -Benson > > > > > >> -----Original Message----- > >> From: arin-announce-bounces at arin.net [mailto:arin-announce- > >> bounces at arin.net] On Behalf Of ARIN > >> Sent: Wednesday, February 23, 2011 7:48 PM > >> To: arin-announce at arin.net > >> Subject: [arin-announce] [Fwd: ARIN-prop-136 Services Opt-out Allowed > >> for Unaffiliated Address Blocks] > >> > >> The following is a new policy proposal that has been posted to the > >> ARIN Public Policy Mailing List for discussion on that list. > >> > >> Regards, > >> > >> Communications and Member Services > >> American Registry for Internet Numbers (ARIN) > >> > >> -------- Original Message -------- > >> Subject: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated > >> Address Blocks > >> Date: Wed, 23 Feb 2011 20:47:30 -0500 > >> From: ARIN > >> To: arin-ppml at arin.net > >> > >> > >> > >> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address > >> Blocks > >> > >> ARIN acknowledges receipt of the policy proposal that can be found > below. > >> > >> The ARIN Advisory Council (AC) will review the proposal at their next > >> regularly scheduled meeting (if the period before the next regularly > >> scheduled meeting is less than 10 days, then the period may be > >> extended to the subsequent regularly scheduled meeting). The AC will > >> decide how to utilize the proposal and announce the decision to the > PPML. > >> > >> The AC invites everyone to comment on the proposal on the PPML, > >> particularly their support or non-support and the reasoning behind > >> their opinion. Such participation contributes to a thorough vetting > >> and provides important guidance to the AC in their deliberations. > >> > >> Draft Policies and Proposals under discussion can be found 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 > >> > >> Mailing list subscription information can be found > >> at: https://www.arin.net/mailing_lists/ > >> > >> Regards, > >> > >> Communications and Member Services > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> ## * ## > >> > >> > >> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address > >> Blocks > >> > >> Proposal Originator: Benson Schliesser > >> > >> Proposal Version: 1 > >> > >> Date: 23 Feb 2011 > >> > >> Proposal type: New > >> > >> Policy term: Permanent > >> > >> Policy statement: > >> > >> Add the following to the NRPM: > >> > >> 13. Unaffiliated Address Blocks > >> > >> 13.x. Opt-out Allowed > >> > >> ARIN provides IP address registry services to all IP address holders > >> in the ARIN region, for all IP address resources that are not > >> registered by another RIR, regardless of whether any given address > >> holder has entered into a services agreement. However, ARIN will > >> cease providing any registry services for specific IP address > >> resources in the event that the legitimate address holder of an > >> unaffiliated address block, that is an address block that is not > >> covered by an ongoing services agreement, chooses to opt-out of > receiving any or all registry services from ARIN. > >> > >> 13.x.1. Requirements for Whois Opt-out > >> > >> In order for an opt-out request for Whois directory services to be > >> valid, the legitimate address holder must agree to provide a > >> replacement directory service reflecting operationally accurate > >> allocation and assignment information for the specified IP number > >> resources. ARIN will create generic placeholder entries in the ARIN > >> Whois directory for all IP number resources that are removed due to > >> opt-out, and each placeholder entry will include a reference and/or > >> RWhois referral to the replacement directory service. > >> > >> > >> Rationale: > >> > >> This proposal does not seek to replace ARIN-prop-133 but is offered > >> as an exclusive alternative for consideration by the ARIN community, > >> in order to address concerns that it would unfairly harm legacy > >> address holders and/or cause unnecessary damage to the Whois > database. > >> > >> Policy Background: > >> > >> This policy attempts to clarify the relationship that ARIN has with > >> legacy address holders. > >> > >> Specifically, this policy recognizes that absent an agreement such as > >> the RSA or LRSA there is no formal relationship with legacy address > >> holders. At present, however, ARIN continues to provide services to > >> these organizations. This is done without compensation and > >> potentially in opposition to the legacy address holders' wishes. As > >> a result of this behavior ARIN has created an illusion of implied > >> authority that exposes ARIN to unacceptable levels of liability, is > >> hindering the development of an open address market (driving it > >> "underground"), and is putting the operational stability of the > >> Internet at risk. As new services such as RPKI are contemplated this > >> situation becomes even more critical. > >> > >> This policy assumes the tacit consent of all address holders in the > >> ARIN region, to receive ARIN registry services and to be governed by > >> ARIN policy, but allows for legitimate address holders of > >> unaffiliated address blocks to explicitly opt-out of any and/or all > >> services. This approach would allow ARIN to continue providing > >> volunteer services to any member of the legacy community as long as > >> this service was not contrary to their wishes. Further, it would > >> allow legacy address holders to opt-out of some services such as > >> Whois while continuing to receive other services such as in-addr DNS > reverse mapping. > >> > >> In the event that a legacy address holder does opt-out of Whois > >> directory services under this policy, ARIN would require the address > >> holder to provide a replacement directory service and would continue > >> to provide a Whois pointer (such as a RWhois referral) to that > >> service. As a result, the integrity of the distributed Whois > >> database would remain intact and be improved. > >> > >> Timetable for implementation: Immediately > >> > >> > >> > >> > >> > >> _______________________________________________ > >> ARIN-Announce > >> You are receiving this message because you are subscribed to the ARIN > >> Announce Mailing List (ARIN-announce at arin.net). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-announce > >> Please contact 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. From mueller at syr.edu Thu Feb 24 18:16:24 2011 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 24 Feb 2011 18:16:24 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D65D39D.8020401@chl.com> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> Message-ID: <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > ARIN members wish ARIN to strive for uniqueness. That is its raison > detre. Excluding numbers from the database of unique numbers [Milton L Mueller] False assumption #1: opting out of ARIN services means no Whois record. Fact: Some people are so stuck in the mindset that ARIN and only ARIN can offer a Whois service that they are missing the point of this proposal. Are you aware of the request by a prospective competitor for bulk access to Whois so that it can be reconciled with an alternate provider and maintain a globally consistent directory? > Encouraging fragmentation is a trojan horse that will serve to undermine > credibility and faith in ARIN.[Milton L Mueller] [Milton L Mueller] False assumption #2: formalizing the opt out means "fragmentation." AFAICT, the fragmentation is already here. There are many legacy holders, including my university, who haven't updated their ARIN whois records since the 1990s. > But more importantly, it is a service to the ARIN members reflecting the > values of the database of uniqueness. [Milton L Mueller] False assumption #3: unique allocations are threatened by competitive whois. Fact: the allocation function, which maintains uniqueness, is functionally and operationally separate from the Whois service. > The LRSA is already a form of opt-in, allowing for a continued implicit opt-out. [Milton L Mueller] Joe, an explicit opt-out is far more constructive and manageable than an "implicit" one. Suggest you read once more Benson's elegant characterization of that "illusion of implied authority." From gbonser at seven.com Thu Feb 24 18:22:51 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Feb 2011 15:22:51 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D48@RWC-EX1.corp.seven.com> > False assumption #1: opting out of ARIN services means no Whois record. > Fact: Some people are so stuck in the mindset that ARIN and only ARIN > can offer a Whois service that they are missing the point of this > proposal. Are you aware of the request by a prospective competitor for > bulk access to Whois so that it can be reconciled with an alternate > provider and maintain a globally consistent directory? > That is not the issue. The issue is knowing where the heck to FIND that alternative whois. Everyone knows where to find ARIN. So if you are looking for the owner of a net block and come up empty at ARIN, do you just start probing whois.every-domain-on-the-planet.$TLD ?? From mueller at syr.edu Thu Feb 24 18:25:26 2011 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 24 Feb 2011 18:25:26 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> Message-ID: <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> There is a real problem to solve. I am surprised you cannot see it. As ipv4 addresses become scarcer and more valuable while the need for them continues for at least a decade, and a transfer market develops, the economic stakes associated with legacy holdings and transfers rise considerably. It's quite likely that many of these transfers will take place outside of ARIN's framework due to the unwillingness of market participants to subject themselves to ARIN's peculiar methods. If legacy holders don't have an explicit right to opt out, and use alternative, compatible registration services, then the "untraceable mess" Tony Hain warned us about will develop. {Reference: "Proposal insanity"] --MM > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Frank Bulk > Sent: Thursday, February 24, 2011 12:38 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for > Unaffiliated Address Blocks > > Unless someone demonstrates that there is a pressing issue or problem, I > am opposed to this proposal. I understand that legacy address holders > may be unrepresented in the policy development process, so others will > have to pipe up if they can help clarifiy. > > This is not the first proposal by Mr. Schliesser where the cart seems to > be before the horse. Let's not create or modify policies unless there's > a real problem to solve or a great opportunity. > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Wednesday, February 23, 2011 7:48 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for > Unaffiliated Address Blocks > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > ARIN acknowledges receipt of the policy proposal that can be found > below. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning behind their > opinion. Such participation contributes to a thorough vetting and > provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 23 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. Opt-out Allowed > > ARIN provides IP address registry services to all IP address holders in > the ARIN region, for all IP address resources that are not registered by > another RIR, regardless of whether any given address holder has entered > into a services agreement. However, ARIN will cease providing any > registry services for specific IP address resources in the event that > the legitimate address holder of an unaffiliated address block, that is > an address block that is not covered by an ongoing services agreement, > chooses to opt-out of receiving any or all registry services from ARIN. > > 13.x.1. Requirements for Whois Opt-out > > In order for an opt-out request for Whois directory services to be > valid, the legitimate address holder must agree to provide a replacement > directory service reflecting operationally accurate allocation and > assignment information for the specified IP number resources. ARIN will > create generic placeholder entries in the ARIN Whois directory for all > IP number resources that are removed due to opt-out, and each > placeholder entry will include a reference and/or RWhois referral to the > replacement directory service. > > > Rationale: > > This proposal does not seek to replace ARIN-prop-133 but is offered as > an exclusive alternative for consideration by the ARIN community, in > order to address concerns that it would unfairly harm legacy address > holders and/or cause unnecessary damage to the Whois database. > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy assumes the tacit consent of all address holders in the ARIN > region, to receive ARIN registry services and to be governed by ARIN > policy, but allows for legitimate address holders of unaffiliated > address blocks to explicitly opt-out of any and/or all services. This > approach would allow ARIN to continue providing volunteer services to > any member of the legacy community as long as this service was not > contrary to their wishes. Further, it would allow legacy address > holders to opt-out of some services such as Whois while continuing to > receive other services such as in-addr DNS reverse mapping. > > In the event that a legacy address holder does opt-out of Whois > directory services under this policy, ARIN would require the address > holder to provide a replacement directory service and would continue to > provide a Whois pointer (such as a RWhois referral) to that service. As > a result, the integrity of the distributed Whois database would remain > intact and be improved. > > Timetable for implementation: Immediately > > > > _______________________________________________ > 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 Thu Feb 24 18:36:38 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 15:36:38 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> Message-ID: <39B7057F-F9D7-4E41-8E71-6850C5EC4A93@delong.com> I keep hearing this, but, it remains to be seen whether that is actually true or mere fantasy. Fact: transfers which take place outside of the ARIN policy framework, there are a number of risks: 1. ARIN will likely de-register any space transferred outside of policy as this is a clear violation of the terms under which the space was registered (even if it is legacy space) and the registration is, thus, void. 2. Once ARIN has deregistered such space, it will likely be registered to another organization within the ARIN policy framework and under RSA. 3. Many ISPs will likely be unwilling to route addresses which are not listed in the ARIN database as belonging to the entity requesting the route. This is not under the direct control of ARIN or the policy process, so, the extent of this is unknown and unpredictable, but, it is most certainly a risk being taken by any business transferring resources outside of policy. Milton is right... Prop 136 is not an attack on legacy holders. It is an attack on the ARIN community and our bottom up consensus driven policy process purporting to be conducted on behalf of legacy holders. Owen On Feb 24, 2011, at 3:25 PM, Milton L Mueller wrote: > There is a real problem to solve. I am surprised you cannot see it. As ipv4 addresses become scarcer and more valuable while the need for them continues for at least a decade, and a transfer market develops, the economic stakes associated with legacy holdings and transfers rise considerably. It's quite likely that many of these transfers will take place outside of ARIN's framework due to the unwillingness of market participants to subject themselves to ARIN's peculiar methods. If legacy holders don't have an explicit right to opt out, and use alternative, compatible registration services, then the "untraceable mess" Tony Hain warned us about will develop. {Reference: "Proposal insanity"] > > --MM > >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of Frank Bulk >> Sent: Thursday, February 24, 2011 12:38 AM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for >> Unaffiliated Address Blocks >> >> Unless someone demonstrates that there is a pressing issue or problem, I >> am opposed to this proposal. I understand that legacy address holders >> may be unrepresented in the policy development process, so others will >> have to pipe up if they can help clarifiy. >> >> This is not the first proposal by Mr. Schliesser where the cart seems to >> be before the horse. Let's not create or modify policies unless there's >> a real problem to solve or a great opportunity. >> >> Frank >> >> -----Original Message----- >> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On >> Behalf Of ARIN >> Sent: Wednesday, February 23, 2011 7:48 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for >> Unaffiliated Address Blocks >> >> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks >> >> ARIN acknowledges receipt of the policy proposal that can be found >> below. >> >> The ARIN Advisory Council (AC) will review the proposal at their next >> regularly scheduled meeting (if the period before the next regularly >> scheduled meeting is less than 10 days, then the period may be extended >> to the subsequent regularly scheduled meeting). The AC will decide how >> to utilize the proposal and announce the decision to the PPML. >> >> The AC invites everyone to comment on the proposal on the PPML, >> particularly their support or non-support and the reasoning behind their >> opinion. Such participation contributes to a thorough vetting and >> provides important guidance to the AC in their deliberations. >> >> Draft Policies and Proposals under discussion can be found 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 >> >> Mailing list subscription information can be found >> at: https://www.arin.net/mailing_lists/ >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers (ARIN) >> >> >> ## * ## >> >> >> ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks >> >> Proposal Originator: Benson Schliesser >> >> Proposal Version: 1 >> >> Date: 23 Feb 2011 >> >> Proposal type: New >> >> Policy term: Permanent >> >> Policy statement: >> >> Add the following to the NRPM: >> >> 13. Unaffiliated Address Blocks >> >> 13.x. Opt-out Allowed >> >> ARIN provides IP address registry services to all IP address holders in >> the ARIN region, for all IP address resources that are not registered by >> another RIR, regardless of whether any given address holder has entered >> into a services agreement. However, ARIN will cease providing any >> registry services for specific IP address resources in the event that >> the legitimate address holder of an unaffiliated address block, that is >> an address block that is not covered by an ongoing services agreement, >> chooses to opt-out of receiving any or all registry services from ARIN. >> >> 13.x.1. Requirements for Whois Opt-out >> >> In order for an opt-out request for Whois directory services to be >> valid, the legitimate address holder must agree to provide a replacement >> directory service reflecting operationally accurate allocation and >> assignment information for the specified IP number resources. ARIN will >> create generic placeholder entries in the ARIN Whois directory for all >> IP number resources that are removed due to opt-out, and each >> placeholder entry will include a reference and/or RWhois referral to the >> replacement directory service. >> >> >> Rationale: >> >> This proposal does not seek to replace ARIN-prop-133 but is offered as >> an exclusive alternative for consideration by the ARIN community, in >> order to address concerns that it would unfairly harm legacy address >> holders and/or cause unnecessary damage to the Whois database. >> >> Policy Background: >> >> This policy attempts to clarify the relationship that ARIN has with >> legacy address holders. >> >> Specifically, this policy recognizes that absent an agreement such as >> the RSA or LRSA there is no formal relationship with legacy address >> holders. At present, however, ARIN continues to provide services to >> these organizations. This is done without compensation and potentially >> in opposition to the legacy address holders' wishes. As a result of >> this behavior ARIN has created an illusion of implied authority that >> exposes ARIN to unacceptable levels of liability, is hindering the >> development of an open address market (driving it "underground"), and is >> putting the operational stability of the Internet at risk. As new >> services such as RPKI are contemplated this situation becomes even more >> critical. >> >> This policy assumes the tacit consent of all address holders in the ARIN >> region, to receive ARIN registry services and to be governed by ARIN >> policy, but allows for legitimate address holders of unaffiliated >> address blocks to explicitly opt-out of any and/or all services. This >> approach would allow ARIN to continue providing volunteer services to >> any member of the legacy community as long as this service was not >> contrary to their wishes. Further, it would allow legacy address >> holders to opt-out of some services such as Whois while continuing to >> receive other services such as in-addr DNS reverse mapping. >> >> In the event that a legacy address holder does opt-out of Whois >> directory services under this policy, ARIN would require the address >> holder to provide a replacement directory service and would continue to >> provide a Whois pointer (such as a RWhois referral) to that service. As >> a result, the integrity of the distributed Whois database would remain >> intact and be improved. >> >> Timetable for implementation: Immediately >> >> >> >> _______________________________________________ >> 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. From jcurran at arin.net Thu Feb 24 18:41:09 2011 From: jcurran at arin.net (John Curran) Date: Thu, 24 Feb 2011 23:41:09 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4656BFD9-8C81-4A67-9A7D-17E19D52B2DE@corp.arin.net> On Feb 25, 2011, at 7:16 AM, Milton L Mueller wrote: > False assumption #1: opting out of ARIN services means no Whois record. > Fact: Some people are so stuck in the mindset that ARIN and only ARIN can offer a Whois service that they are missing the point of this proposal. Are you aware of the request by a prospective competitor for bulk access to Whois so that it can be reconciled with an alternate provider and maintain a globally consistent directory? Milton - We don't seem to have any actual details regarding how such registries might interact with the existing system, what common goals would still exist (if any), or even what authority and policies they'd operate under. Such details are essential to understanding what exactly is being proposed when you reference "alternative providers", and as you are well-aware, these are the sort of issues that took years to work out in the DNS registry system and (to some extent) even now are still evolving under guidance from an entire ecosystem of constituencies within ICANN. Perhaps addressing those some of these questions via in an actual proposal to change ICP-2 could result in a revised framework for handling global number resource management? That certainly would make evaluating policy proposals such as ARIN-prop-136 much more straightforward. If such a change is desired, the most appropriate first step would be those who want it to work on a concrete proposal that addresses the material issues of introducing a new (non-geographic) competitive registry framework. That would allow consideration by the global community of the potential issues and benefits from introducing commercial registries, and furthermore could be actually discussed in open manner which includes governments, business, standards organizations and civil society. I presume that you are familiar with this sort of process, and hopefully can see how the ARIN region considering it independently from the current global policy for number resource management would be contrary to actually having open and transparent governance for these the global number resources? /John John Curran President and CEO ARIN From jcurran at arin.net Thu Feb 24 19:01:23 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 00:01:23 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Feb 25, 2011, at 7:25 AM, Milton L Mueller wrote: > It's quite likely that many of these transfers will take place outside of ARIN's framework due to the unwillingness of market participants to subject themselves to ARIN's peculiar methods. You omitted out one little detail: those "peculiar methods" are actually the policy that the community wants in this region, and so we follow the policy because that's what keeps the Whois database useful for their purposes. This is called community-developed policy, and it is not developed in vacuum, but within the established global policies for number resource management. If it turns out there are parties who neither like the policy nor are willing to participate in getting it changed to meet their needs, then ARIN probably can't help them, because we bound by existing agreements to manage the resources accordingly and to maintaining an open and transparent process for policy change. /John John Curran President and CEO ARIN From jcurran at istaff.org Thu Feb 24 18:46:48 2011 From: jcurran at istaff.org (John Curran) Date: Fri, 25 Feb 2011 07:46:48 +0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> Message-ID: <746B4F72-C1CA-43C1-BD01-B226A31F276D@istaff.org> On Feb 25, 2011, at 7:25 AM, Milton L Mueller wrote: > It's quite likely that many of these transfers will take place outside of ARIN's framework due to the unwillingness of market participants to subject themselves to ARIN's peculiar methods. You omitted out one little detail: those "peculiar methods" are actually the policy that the community wants in this region, and so we follow the policy because that's what the operators feel keeps the Whois database useful for their purposes. /John John Curran President and CEO ARIN From cgrundemann at gmail.com Thu Feb 24 19:25:08 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 24 Feb 2011 17:25:08 -0700 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Thu, Feb 24, 2011 at 16:16, Milton L Mueller wrote: > Fact: Some people are so stuck in the mindset that ARIN and only ARIN can offer a Whois service that they are missing the point of this proposal. Most people (particularly those who operate networks) understand that ARIN does an adequate (and improving) job of providing the Whois service for this region and see no reason to 'fix what aint broken.' > Are you aware of the request by a prospective competitor for bulk access to Whois so that it can be reconciled with an alternate provider and maintain a globally consistent directory? Yep. > AFAICT, the fragmentation is already here. There are many legacy holders, including my university, who haven't updated their ARIN whois records since the 1990s. OK, what should lead any of us to believe that organizations who have not bothered to update records for free for over two decades would jump up and start paying to do it with someone other than ARIN? (As a bit of an aside, SYR-UNIV-NET was updated in 2009, the affiliated org was updated in 2004 and two of the four POCs were updated just last year: http://whois.arin.net/rest/net/NET-128-230-0-0-1/pft) More to the point, this is an issue that ARIN is actively addressing, under guidance from the community. See: http://weblog.chrisgrundemann.com/index.php/2010/annual-whois-poc-validation-emails-arin/. Cheers, ~Chris > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From owen at delong.com Thu Feb 24 19:36:22 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 16:36:22 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4656BFD9-8C81-4A67-9A7D-17E19D52B2DE@corp.arin.net> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4656BFD9-8C81-4A67-9A7D-17E19D52B2DE@corp.arin.net> Message-ID: On Feb 24, 2011, at 3:41 PM, John Curran wrote: > On Feb 25, 2011, at 7:16 AM, Milton L Mueller wrote: > >> False assumption #1: opting out of ARIN services means no Whois record. >> Fact: Some people are so stuck in the mindset that ARIN and only ARIN can offer a Whois service that they are missing the point of this proposal. Are you aware of the request by a prospective competitor for bulk access to Whois so that it can be reconciled with an alternate provider and maintain a globally consistent directory? > > Milton - > > We don't seem to have any actual details regarding how such registries > might interact with the existing system, what common goals would still > exist (if any), or even what authority and policies they'd operate under. > Such details are essential to understanding what exactly is being proposed > when you reference "alternative providers", and as you are well-aware, > these are the sort of issues that took years to work out in the DNS > registry system and (to some extent) even now are still evolving under > guidance from an entire ecosystem of constituencies within ICANN. > FWIW I choose not to participate in the domain policy process, not because I think it is fine as is, but, because I think it is a quagmire that is broken beyond all possibility of useful repair. I have given up on domain policy as a useless waste. The facilitation of squatters, domain tasting, and the exorbitant profiteering by organizations glomming onto any name they can think of and holding them hostage until they get a sufficient ransom is completely contrary to the public interest and the goals of good internet governance. The mistake of affiliating domain names with trademarks has only further clouded the issue of domain policy. I suspect that Milton views most of these things as a feature, rather than a bug. As such, I suspect he wants to encumber the IP addressing process with a similar construct. Personally, I think we have a system that works well and is serving the community. The policy process is open to any willing participant (which as near as I can tell is significantly less true of the domain policy process). > > I presume that you are familiar with this sort of process, and hopefully > can see how the ARIN region considering it independently from the current > global policy for number resource management would be contrary to actually > having open and transparent governance for these the global number resources? > +1 Owen From mueller at syr.edu Thu Feb 24 19:39:25 2011 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 24 Feb 2011 19:39:25 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4656BFD9-8C81-4A67-9A7D-17E19D52B2DE@corp.arin.net> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4656BFD9-8C81-4A67-9A7D-17E19D52B2DE@corp.arin.net> Message-ID: <75822E125BCB994F8446858C4B19F0D714409179FA@SUEX07-MBX-04.ad.syr.edu> Good points, John. In terms of details, I don't think it's all that complicated for ARIN to start the process by making it clear that bulk access to its Whois data could be provided on request to other organizations that abide by the restrictions of the bulk access agreement (e.g., no use for marketing/spam). Other RIRs could easily make the same commitment. Frankly, I think providing bulk access to the party who has requested it is not prevented and may be required by current policy. In theory, you are correct that the broader contours of policy regarding competitive registries should be developed globally. I'd support that. As a matter of historical fact, however, most such policy innovations don't follow prescribed channels, they tend to be provoked by some disruption that originates opportunistically in one location and then spreads to another.* Nevertheless, ICANN and its ASO could and should initiate a process to deal with it. I'd help with such an effort though don't have the cycles or resources to take responsibility for it, and am not well positioned as the ASO is at present representative of no one by the RIRs. One obstacle to a global policy develop process using ICANN as a venue is that ICANN's legitimacy and authority are constantly undermined by the USG and GAC, which compete with it for policy authority. This encourages parties to run to governments when they don't get the results they want from the ICANN process. Given the increasingly high stakes in address policy, I can only imagine how such a scenario might play out in address policy. --MM * think IAHC, > -----Original Message----- > From: John Curran [mailto:jcurran at arin.net] > Sent: Thursday, February 24, 2011 6:41 PM > To: Milton L Mueller > Cc: ARIN Member Services; arin-ppml at arin.net List > Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for > Unaffiliated Address Blocks > > On Feb 25, 2011, at 7:16 AM, Milton L Mueller wrote: > > > False assumption #1: opting out of ARIN services means no Whois > record. > > Fact: Some people are so stuck in the mindset that ARIN and only ARIN > can offer a Whois service that they are missing the point of this > proposal. Are you aware of the request by a prospective competitor for > bulk access to Whois so that it can be reconciled with an alternate > provider and maintain a globally consistent directory? > > Milton - > > We don't seem to have any actual details regarding how such registries > might interact with the existing system, what common goals would still > exist (if any), or even what authority and policies they'd operate > under. > Such details are essential to understanding what exactly is being > proposed when you reference "alternative providers", and as you are > well-aware, these are the sort of issues that took years to work out in > the DNS registry system and (to some extent) even now are still evolving > under guidance from an entire ecosystem of constituencies within ICANN. > > Perhaps addressing those some of these questions via in an actual > proposal to change ICP-2 could result in a revised framework for > handling global number resource management? That certainly would make > evaluating policy proposals such as ARIN-prop-136 much more > straightforward. > > If such a change is desired, the most appropriate first step would be > those who want it to work on a concrete proposal that addresses the > material issues of introducing a new (non-geographic) competitive > registry framework. That would allow consideration by the global > community of the potential issues and benefits from introducing > commercial registries, and furthermore could be actually discussed in > open manner which includes governments, business, standards > organizations and civil society. > > I presume that you are familiar with this sort of process, and hopefully > can see how the ARIN region considering it independently from the > current global policy for number resource management would be contrary > to actually having open and transparent governance for these the global > number resources? > > /John > > John Curran > President and CEO > ARIN From matthew at matthew.at Thu Feb 24 19:53:52 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 16:53:52 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4D66FDA0.3050009@matthew.at> On 2/24/2011 3:16 PM, Milton L Mueller wrote: > > False assumption #1: opting out of ARIN services means no Whois record. > Fact: Some people are so stuck in the mindset that ARIN and only ARIN can offer a Whois service that they are missing the point of this proposal. Are you aware of the request by a prospective competitor for bulk access to Whois so that it can be reconciled with an alternate provider and maintain a globally consistent directory? Please address the question I raised earlier today. Either ARIN is still the registry of uniqueness for this block and this part of the globe and will have a pointer to whatever whois provider there is, or ARIN is *not* the registry of uniqueness for the block in which case they must either be transferred to another RIR (which requires ICANN to do something) or transferred nowhere (which doesn't seem feasible). In the first of those three cases, one hasn't "opted-out" of anything. ARIN is still the ICANN-recognized holder of the record of unique registration, even if it is simply a pointer to a more-easily-changeable thing. (Why ARIN would want to point to (or ARIN's members would want ARIN to point to) something which could be changed outside of community-developed policy, I don't know) Matthew Kaufman From cgrundemann at gmail.com Thu Feb 24 19:55:53 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Thu, 24 Feb 2011 17:55:53 -0700 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Thu, Feb 24, 2011 at 16:25, Milton L Mueller wrote: > There is a real problem to solve. I am surprised you cannot see it. As ipv4 addresses become scarcer and more valuable while the need for them continues for at least a decade, and a transfer market develops, the economic stakes associated with legacy holdings and transfers rise considerably. It's quite likely that many of these transfers will take place outside of ARIN's framework due to the unwillingness of market participants to subject themselves to ARIN's peculiar methods. If legacy holders don't have an explicit right to opt out, and use alternative, compatible registration services, then the "untraceable mess" Tony Hain warned us about will develop. {Reference: "Proposal insanity"] I do not make the same correlation you seem to be. We have a non-profit organization operating a registry openly governed by community driven policy, and we have a potential problem. Your proposed solution appears to be to encourage folks to opt-out of the system entirely and turn instead to for-profit companies who will very likely have no need to (and likely a fiduciary responsibility not to) have their operational policy directly controlled directly by their customers. I would propose working within the existing, open and transparent, system to solve any potential problems. $0.02 ~Chris > --MM > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From matthew at matthew.at Thu Feb 24 19:58:06 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 16:58:06 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D66FDA0.3050009@matthew.at> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4D66FDA0.3050009@matthew.at> Message-ID: <4D66FE9E.2060606@matthew.at> And note, by the way, that I am currently OPPOSED to this policy proposal. But also believe we need a way to allow transfers to happen without risk to the seller in the case where the seller hasn't signed the LRSA. (Specifically, the case where one starts a transfer, signs the LRSA only because it is required for the transfer, and then the transfer fails to happen for external reasons... how can one un-sign the LRSA at that point?) Matthew Kaufman From mueller at syr.edu Thu Feb 24 19:58:32 2011 From: mueller at syr.edu (Milton L Mueller) Date: Thu, 24 Feb 2011 19:58:32 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D66FDA0.3050009@matthew.at> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4D66FDA0.3050009@matthew.at> Message-ID: <75822E125BCB994F8446858C4B19F0D714409179FC@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > Please address the question I raised earlier today. Either ARIN is still > the registry of uniqueness for this block and this part of the globe and > will have a pointer to whatever whois provider there is, or ARIN is > *not* the registry of uniqueness for the block in which case they must > either be transferred to another RIR (which requires ICANN to do > something) or transferred nowhere (which doesn't seem feasible). [Milton L Mueller] See false assumption #3. The allocation function, which maintains uniqueness, is functionally separate from the Whois service. One could, therefore, opt out of ARIN-provided Whois and continue to use ARIN as the unique registry. See: registrar-registry split in DNS. > In the first of those three cases, one hasn't "opted-out" of anything. > ARIN is still the ICANN-recognized holder of the record of unique > registration, even if it is simply a pointer to a more-easily-changeable > thing. (Why ARIN would want to point to (or ARIN's members would want > ARIN to point to) something which could be changed outside of community- > developed policy, I don't know) > > Matthew Kaufman From matthew at matthew.at Thu Feb 24 20:02:53 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 17:02:53 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179FC@SUEX07-MBX-04.ad.syr.edu> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4D66FDA0.3050009@matthew.at> <75822E125BCB994F8446858C4B19F0D714409179FC@SUEX07-MBX-04.ad.syr.edu> Message-ID: <4D66FFBD.40909@matthew.at> On 2/24/2011 4:58 PM, Milton L Mueller wrote: >> -----Original Message----- >> Please address the question I raised earlier today. Either ARIN is still >> the registry of uniqueness for this block and this part of the globe and >> will have a pointer to whatever whois provider there is, or ARIN is >> *not* the registry of uniqueness for the block in which case they must >> either be transferred to another RIR (which requires ICANN to do >> something) or transferred nowhere (which doesn't seem feasible). > [Milton L Mueller] > > See false assumption #3. How about "see the second half of what I wrote"? > The allocation function, which maintains uniqueness, is functionally separate from the Whois service. > One could, therefore, opt out of ARIN-provided Whois and continue to use ARIN as the unique registry. See: registrar-registry split in DNS. Right, so one has "half" opted out, but is still entirely "opted in" for the purpose of uniqueness (and reverse DNS service and who knows what else). This helps me how? >> In the first of those three cases, one hasn't "opted-out" of anything. >> ARIN is still the ICANN-recognized holder of the record of unique >> registration, even if it is simply a pointer to a more-easily-changeable >> thing. (Why ARIN would want to point to (or ARIN's members would want >> ARIN to point to) something which could be changed outside of community- >> developed policy, I don't know) I'll repeat. Why would ARIN or ARIN's membership want to have the whois function now be a pointer to an entity that doesn't follow community-developed policy for the records changes? And if the third party *will* follow the community-developed policy then how is it any better than having ARIN provide the function? Matthew Kaufman From scottleibrand at gmail.com Thu Feb 24 20:13:21 2011 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 24 Feb 2011 17:13:21 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks Message-ID: On Thu, Feb 24, 2011 at 4:58 PM, Matthew Kaufman wrote: > And note, by the way, that I am currently OPPOSED to this policy proposal. > > But also believe we need a way to allow transfers to happen without risk to > the seller in the case where the seller hasn't signed the LRSA. > (Specifically, the case where one starts a transfer, signs the LRSA only > because it is required for the transfer, and then the transfer fails to > happen for external reasons... how can one un-sign the LRSA at that point?) > I think this may indeed be the crux of the issue at least in many cases. I'm not sure it should even be necessary for a seller to have an LRSA to release resources under NRPM 8.3: there's nothing in the text of 8.3 that says they need to sign one: it just says " IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder, in whole or in part, for transfer to another specified organizational recipient." Reading over ARIN's transfer instructions at https://www.arin.net/resources/request/transfers.html, I do see that "The number resources being transferred must be covered under either a standard ARIN RSA or a Legacy RSA" though. I'm guessing that the only reason for getting the LRSA signed before releasing the resource is to establish some sort of contractual relationship: perhaps per your suggestion, we should have some additional language at the top of such LRSAs that makes them take effect only contingent upon successful transfer of the resource? John, is there anything else we should know about why ARIN's transfer procedures require an RSA covering number resources being transferred? Thanks, Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 24 20:11:46 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 17:11:46 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D66FE9E.2060606@matthew.at> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4D66FDA0.3050009@matthew.at> <4D66FE9E.2060606@matthew.at> Message-ID: <0F65BA20-1719-4382-BC1F-07E6618B0AAC@delong.com> I believe one can currently get the transfer to the point where the LRSA is the final step to completing the transfer. I believe that provides adequate protection. I could be mistaken and would welcome staff clarification on this point. Owen On Feb 24, 2011, at 4:58 PM, Matthew Kaufman wrote: > And note, by the way, that I am currently OPPOSED to this policy proposal. > > But also believe we need a way to allow transfers to happen without risk to the seller in the case where the seller hasn't signed the LRSA. (Specifically, the case where one starts a transfer, signs the LRSA only because it is required for the transfer, and then the transfer fails to happen for external reasons... how can one un-sign the LRSA at that point?) > > 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 matthew at matthew.at Thu Feb 24 20:17:03 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 17:17:03 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: Message-ID: <4D67030F.6000600@matthew.at> On 2/24/2011 5:13 PM, Scott Leibrand wrote: > On Thu, Feb 24, 2011 at 4:58 PM, Matthew Kaufman > wrote: > > And note, by the way, that I am currently OPPOSED to this policy > proposal. > > But also believe we need a way to allow transfers to happen > without risk to the seller in the case where the seller hasn't > signed the LRSA. (Specifically, the case where one starts a > transfer, signs the LRSA only because it is required for the > transfer, and then the transfer fails to happen for external > reasons... how can one un-sign the LRSA at that point?) > > I think this may indeed be the crux of the issue at least in many cases This is half the issue. The second is a perception that if one could transfer legacy non-LRSA resources to another party without that party having to sign the LRSA, those might in fact be slightly more valuable to said third party (and thus command a higher price). It isn't necessarily of benefit to ARIN to further this dichotomy, so this is a harder one to solve.. but the first one is probably more important (and easier) to solve if we want to. Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew at matthew.at Thu Feb 24 20:18:55 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 17:18:55 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <0F65BA20-1719-4382-BC1F-07E6618B0AAC@delong.com> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4D66FDA0.3050009@matthew.at> <4D66FE9E.2060606@matthew.at> <0F65BA20-1719-4382-BC1F-07E6618B0AAC@delong.com> Message-ID: <4D67037F.5040906@matthew.at> On 2/24/2011 5:11 PM, Owen DeLong wrote: > I believe one can currently get the transfer to the point where the LRSA is the final > step to completing the transfer. > > I believe that provides adequate protection. How does that protect a seller if, for instance, the check bounces and they initiate proceedings to reclaim the space back from the buyer? Best case, they get the space but now they've signed the LRSA for it. Do they also need to sue ARIN to get the LRSA unwound in the same action? Wouldn't it be easier for everyone if this could all be avoided? Matthew Kaufman From woody at pch.net Thu Feb 24 20:22:58 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 24 Feb 2011 17:22:58 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: Message-ID: <5651702C-CCDE-4A69-A381-62A73E09B1B9@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 24, 2011, at 5:13 PM, Scott Leibrand wrote: > I'm not sure it should even be necessary for a seller to have an LRSA to release resources under NRPM 8.3: there's nothing in the text of 8.3 that says they need to sign one: it just says " IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder... That is correct. The 8.3 transfer policy specifically places no burden on the seller. The seller need not be an RSA or LRSA signatory, and presumably in most cases will not be. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1nBHIACgkQGvQy4xTRsBETFwCgtrvB2KymIHMFMEVqg+tlR77G 19IAnR+CQrSUYNLRKtLx/Yjek8oPIHm0 =2zTy -----END PGP SIGNATURE----- From jcurran at arin.net Thu Feb 24 20:25:43 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 01:25:43 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179FA@SUEX07-MBX-04.ad.syr.edu> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4656BFD9-8C81-4A67-9A7D-17E19D52B2DE@corp.arin.net> <75822E125BCB994F8446858C4B19F0D714409179FA@SUEX07-MBX-04.ad.syr.edu> Message-ID: On Feb 25, 2011, at 8:39 AM, Milton L Mueller wrote: > Good points, John. In terms of details, I don't think it's all that complicated for ARIN to start the process by making it clear that bulk access to its Whois data could be provided on request to other organizations that abide by the restrictions of the bulk access agreement I hereby state that ARIN provides bulk access to its Whois data per the bulk access agreement. > (e.g., no use for marketing/spam). Other RIRs could easily make the same commitment. Frankly, I think providing bulk access to the party who has requested it is not prevented and may be required by current policy. ] You'd be incorrect, but you do have a right to such a view. > In theory, you are correct that the broader contours of policy regarding competitive registries should be developed globally. I'd support that. As a matter of historical fact, however, most such policy innovations don't follow prescribed channels, they tend to be provoked by some disruption that originates opportunistically in one location and then spreads to another.* Nevertheless, ICANN and its ASO could and should initiate a process to deal with it. I'd help with such an effort though don't have the cycles or resources to take responsibility for it, and am not well positioned as the ASO is at present representative of no one by the RIRs. I imagine if a material proposal was made on how to address this matter globally, then it would enjoy ample discussion in many forums. That certainly has been the case with other significant changes in Internet resource management. > One obstacle to a global policy develop process using ICANN as a venue is that ICANN's legitimacy and authority are constantly undermined by the USG and GAC, which compete with it for policy authority. This encourages parties to run to governments when they don't get the results they want from the ICANN process. Given the increasingly high stakes in address policy, I can only imagine how such a scenario might play out in address policy. That has not historically been an impediment with respect to global number resource policy, but then again, such global policy proposals have not been brought into the ICANN process until they've been thoroughly discussed and achieved consensus in the regions. FYI, /John John Curran President and CEO ARIN From owen at delong.com Thu Feb 24 20:36:35 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 17:36:35 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67030F.6000600@matthew.at> References: <4D67030F.6000600@matthew.at> Message-ID: <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> On Feb 24, 2011, at 5:17 PM, Matthew Kaufman wrote: > On 2/24/2011 5:13 PM, Scott Leibrand wrote: >> >> On Thu, Feb 24, 2011 at 4:58 PM, Matthew Kaufman wrote: >> And note, by the way, that I am currently OPPOSED to this policy proposal. >> >> But also believe we need a way to allow transfers to happen without risk to the seller in the case where the seller hasn't signed the LRSA. (Specifically, the case where one starts a transfer, signs the LRSA only because it is required for the transfer, and then the transfer fails to happen for external reasons... how can one un-sign the LRSA at that point?) >> >> I think this may indeed be the crux of the issue at least in many cases > > This is half the issue. The second is a perception that if one could transfer legacy non-LRSA resources to another party without that party having to sign the LRSA, those might in fact be slightly more valuable to said third party (and thus command a higher price). > The recipient of legitimately transferred resources must sign the RSA, not the LRSA. There is no ability to legitimately transfer resources without the recipient signing an RSA. This is true even in the merger and acquisition policy. Resources transferred outside of policy without the recipient signing an RSA can, and should, at least in most cases, be de-registered and registered to other parties operating within the ARIN policy framework. While I support the idea that ARIN should continue to provide services to legacy holders on the original terms whether or not they sign an LRSA, as far as I know, those terms do not include any transferability (other than M&A as covered in NRPM 8.2). As such, I do not believe that there exists benefit to the community in ARIN extending the kindness they grant to legacy holders to third-party recipients of space from legacy holders through an unauthorized transfer process. > It isn't necessarily of benefit to ARIN to further this dichotomy, so this is a harder one to solve.. but the first one is probably more important (and easier) to solve if we want to. > The fact that legacy holders received their addresses through an undocumented and informal community process rather than under the contracted structure we have in place today is an accident of history. It should not be extended to new recipients of addresses. Legacy or not, ARIN registrations are not transferrable other than as expressed in NRPM 8. This requires that the recipient sign an RSA. There is no problem there. That is to the benefit of the community and is the correct course for ARIN to take. Promulgating the contractless registrations to additional third parties is unfair to existing resource holders under RSA and to the ARIN community. Legacy holders are grandfathered under current operating practice. New parties are not entitled to and should not receive such special dispensation. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Feb 24 20:40:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 17:40:05 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67037F.5040906@matthew.at> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4D66FDA0.3050009@matthew.at> <4D66FE9E.2060606@matthew.at> <0F65BA20-1719-4382-BC1F-07E6618B0AAC@delong.com> <4D67037F.5040906@matthew.at> Message-ID: On Feb 24, 2011, at 5:18 PM, Matthew Kaufman wrote: > On 2/24/2011 5:11 PM, Owen DeLong wrote: >> I believe one can currently get the transfer to the point where the LRSA is the final >> step to completing the transfer. >> >> I believe that provides adequate protection. > > How does that protect a seller if, for instance, the check bounces and they initiate proceedings to reclaim the space back from the buyer? Best case, they get the space but now they've signed the LRSA for it. Do they also need to sue ARIN to get the LRSA unwound in the same action? Wouldn't it be easier for everyone if this could all be avoided? > The seller can insist that the check clears before they sign the LRSA. To my knowledge, the transaction between the transferor and the recipient is independent of ARIN and the transfer process makes no provision for the transferor to initiate proceedings with ARIN to reclaim the space, so, I don't see how your scenario applies. Owen From gary.buhrmaster at gmail.com Thu Feb 24 21:12:06 2011 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Fri, 25 Feb 2011 02:12:06 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67037F.5040906@matthew.at> References: <4D65B8B2.9070702@arin.net> <4D65D39D.8020401@chl.com> <75822E125BCB994F8446858C4B19F0D714409179F7@SUEX07-MBX-04.ad.syr.edu> <4D66FDA0.3050009@matthew.at> <4D66FE9E.2060606@matthew.at> <0F65BA20-1719-4382-BC1F-07E6618B0AAC@delong.com> <4D67037F.5040906@matthew.at> Message-ID: On Fri, Feb 25, 2011 at 01:18, Matthew Kaufman wrote: .... > How does that protect a seller if, for instance, the check bounces and they > initiate proceedings to reclaim the space back from the buyer? Best case, > they get the space but now they've signed the LRSA for it. Do they also need > to sue ARIN to get the LRSA unwound in the same action? Wouldn't it be > easier for everyone if this could all be avoided? I trust that most of the sources of space to be transfered will have good enough lawyers to insure that the costs for making that space available will be appropriately compensated (and protected against failures to execute). And if they did not hire good enough lawyers, well, no policy is going to be able to adequately protect them. Gary From frnkblk at iname.com Fri Feb 25 00:08:25 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 24 Feb 2011 23:08:25 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> Message-ID: <000d01cbd4aa$08228540$18678fc0$@iname.com> Does the community want "alternative, compatible registration services"? Frank -----Original Message----- From: Milton L Mueller [mailto:mueller at syr.edu] Sent: Thursday, February 24, 2011 5:25 PM To: frnkblk at iname.com; arin-ppml at arin.net Subject: RE: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks There is a real problem to solve. I am surprised you cannot see it. As ipv4 addresses become scarcer and more valuable while the need for them continues for at least a decade, and a transfer market develops, the economic stakes associated with legacy holdings and transfers rise considerably. It's quite likely that many of these transfers will take place outside of ARIN's framework due to the unwillingness of market participants to subject themselves to ARIN's peculiar methods. If legacy holders don't have an explicit right to opt out, and use alternative, compatible registration services, then the "untraceable mess" Tony Hain warned us about will develop. {Reference: "Proposal insanity"] --MM > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Frank Bulk > Sent: Thursday, February 24, 2011 12:38 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for > Unaffiliated Address Blocks > > Unless someone demonstrates that there is a pressing issue or problem, I > am opposed to this proposal. I understand that legacy address holders > may be unrepresented in the policy development process, so others will > have to pipe up if they can help clarifiy. > > This is not the first proposal by Mr. Schliesser where the cart seems to > be before the horse. Let's not create or modify policies unless there's > a real problem to solve or a great opportunity. > > Frank > > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of ARIN > Sent: Wednesday, February 23, 2011 7:48 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for > Unaffiliated Address Blocks > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > ARIN acknowledges receipt of the policy proposal that can be found > below. > > The ARIN Advisory Council (AC) will review the proposal at their next > regularly scheduled meeting (if the period before the next regularly > scheduled meeting is less than 10 days, then the period may be extended > to the subsequent regularly scheduled meeting). The AC will decide how > to utilize the proposal and announce the decision to the PPML. > > The AC invites everyone to comment on the proposal on the PPML, > particularly their support or non-support and the reasoning behind their > opinion. Such participation contributes to a thorough vetting and > provides important guidance to the AC in their deliberations. > > Draft Policies and Proposals under discussion can be found 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 > > Mailing list subscription information can be found > at: https://www.arin.net/mailing_lists/ > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > > Proposal Originator: Benson Schliesser > > Proposal Version: 1 > > Date: 23 Feb 2011 > > Proposal type: New > > Policy term: Permanent > > Policy statement: > > Add the following to the NRPM: > > 13. Unaffiliated Address Blocks > > 13.x. Opt-out Allowed > > ARIN provides IP address registry services to all IP address holders in > the ARIN region, for all IP address resources that are not registered by > another RIR, regardless of whether any given address holder has entered > into a services agreement. However, ARIN will cease providing any > registry services for specific IP address resources in the event that > the legitimate address holder of an unaffiliated address block, that is > an address block that is not covered by an ongoing services agreement, > chooses to opt-out of receiving any or all registry services from ARIN. > > 13.x.1. Requirements for Whois Opt-out > > In order for an opt-out request for Whois directory services to be > valid, the legitimate address holder must agree to provide a replacement > directory service reflecting operationally accurate allocation and > assignment information for the specified IP number resources. ARIN will > create generic placeholder entries in the ARIN Whois directory for all > IP number resources that are removed due to opt-out, and each > placeholder entry will include a reference and/or RWhois referral to the > replacement directory service. > > > Rationale: > > This proposal does not seek to replace ARIN-prop-133 but is offered as > an exclusive alternative for consideration by the ARIN community, in > order to address concerns that it would unfairly harm legacy address > holders and/or cause unnecessary damage to the Whois database. > > Policy Background: > > This policy attempts to clarify the relationship that ARIN has with > legacy address holders. > > Specifically, this policy recognizes that absent an agreement such as > the RSA or LRSA there is no formal relationship with legacy address > holders. At present, however, ARIN continues to provide services to > these organizations. This is done without compensation and potentially > in opposition to the legacy address holders' wishes. As a result of > this behavior ARIN has created an illusion of implied authority that > exposes ARIN to unacceptable levels of liability, is hindering the > development of an open address market (driving it "underground"), and is > putting the operational stability of the Internet at risk. As new > services such as RPKI are contemplated this situation becomes even more > critical. > > This policy assumes the tacit consent of all address holders in the ARIN > region, to receive ARIN registry services and to be governed by ARIN > policy, but allows for legitimate address holders of unaffiliated > address blocks to explicitly opt-out of any and/or all services. This > approach would allow ARIN to continue providing volunteer services to > any member of the legacy community as long as this service was not > contrary to their wishes. Further, it would allow legacy address > holders to opt-out of some services such as Whois while continuing to > receive other services such as in-addr DNS reverse mapping. > > In the event that a legacy address holder does opt-out of Whois > directory services under this policy, ARIN would require the address > holder to provide a replacement directory service and would continue to > provide a Whois pointer (such as a RWhois referral) to that service. As > a result, the integrity of the distributed Whois database would remain > intact and be improved. > > Timetable for implementation: Immediately > > > > _______________________________________________ > 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 matthew at matthew.at Fri Feb 25 00:10:57 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 21:10:57 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <5651702C-CCDE-4A69-A381-62A73E09B1B9@pch.net> References: <5651702C-CCDE-4A69-A381-62A73E09B1B9@pch.net> Message-ID: <4D6739E1.9000800@matthew.at> On 2/24/2011 5:22 PM, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Feb 24, 2011, at 5:13 PM, Scott Leibrand wrote: >> I'm not sure it should even be necessary for a seller to have an LRSA to release resources under NRPM 8.3: there's nothing in the text of 8.3 that says they need to sign one: it just says " IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder... > > That is correct. The 8.3 transfer policy specifically places no burden on the seller. The seller need not be an RSA or LRSA signatory, and presumably in most cases will not be. Yes, this appears to be correct, even though a cursory reading of the transfer section suggests otherwise (one needs to remember what "received" means in order to parse it correctly) However, it *is* the case that one must have signed the LRSA to list legacy resources in the STLS. Why is that? Matthew Kaufman From matthew at matthew.at Fri Feb 25 00:19:20 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Feb 2011 21:19:20 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> Message-ID: <4D673BD8.6040003@matthew.at> On 2/24/2011 5:36 PM, Owen DeLong wrote: > > On Feb 24, 2011, at 5:17 PM, Matthew Kaufman wrote: > >> On 2/24/2011 5:13 PM, Scott Leibrand wrote: >>> On Thu, Feb 24, 2011 at 4:58 PM, Matthew Kaufman >> > wrote: >>> >>> And note, by the way, that I am currently OPPOSED to this policy >>> proposal. >>> >>> But also believe we need a way to allow transfers to happen >>> without risk to the seller in the case where the seller hasn't >>> signed the LRSA. (Specifically, the case where one starts a >>> transfer, signs the LRSA only because it is required for the >>> transfer, and then the transfer fails to happen for external >>> reasons... how can one un-sign the LRSA at that point?) >>> >>> I think this may indeed be the crux of the issue at least in many cases >> >> This is half the issue. The second is a perception that if one could >> transfer legacy non-LRSA resources to another party without that >> party having to sign the LRSA, those might in fact be slightly more >> valuable to said third party (and thus command a higher price). >> > The recipient of legitimately transferred resources must sign the RSA, > not the LRSA. Yes, I mis-typed. If it were possible to transfer legacy non-LRSA resources to a new holder that themselves could avoid signing the RSA, those addresses *might* be perceived as having more value. (I'm not sure that's true, but it might be.) > > There is no ability to legitimately transfer resources without the > recipient signing an RSA. This is true > even in the merger and acquisition policy. > > Resources transferred outside of policy without the recipient signing > an RSA can, and should, at least > in most cases, be de-registered and registered to other parties > operating within the ARIN policy > framework. While I support the idea that ARIN should continue to > provide services to legacy holders > on the original terms whether or not they sign an LRSA, as far as I > know, those terms do not include > any transferability (other than M&A as covered in NRPM 8.2). I'm not sure I follow the reasoning. Resources that are not under RSA or LRSA may or may not be transferable without following the terms outlined in the NRPM. We don't really know the answer to that question. > As such, I do not believe that there > exists benefit to the community in ARIN extending the kindness they > grant to legacy holders > to third-party recipients of space from legacy holders through an > unauthorized transfer process. So the issue is that if ARIN believes that legacy non-LRSA resources are not transferable and yet the transferer and the transferee believe they are, we have a problem. There's two courses of actions for the transfering parties to take in this case: not tell ARIN (which is bad for the database quality), or sue ARIN (which is bad for ARIN in other ways). Or we could change the policy to make it more appealing. > >> It isn't necessarily of benefit to ARIN to further this dichotomy, so >> this is a harder one to solve.. but the first one is probably more >> important (and easier) to solve if we want to. >> > The fact that legacy holders received their addresses through an > undocumented and informal > community process rather than under the contracted structure we have > in place today is > an accident of history. It should not be extended to new recipients of > addresses. > > Legacy or not, ARIN registrations are not transferrable other than as > expressed in NRPM 8. Prove this. I'm with you for the non-legacy, and for legacy with a signed LRSA, but I'm not sure how you'd prove it for legacy non-LRSA. > This requires that the recipient sign an RSA. Right now that's the case, which may drive these transfers outside of ARIN's view. > > There is no problem there. That is to the benefit of the community and > is the correct > course for ARIN to take. Promulgating the contractless registrations > to additional > third parties is unfair to existing resource holders under RSA and to > the ARIN community. Everything about IPv4 addressing is unfair, and it is going to be a whole lot less fair really soon. > Legacy holders are grandfathered under current operating practice. New > parties > are not entitled to and should not receive such special dispensation. That's an opinion that seems to be fairly widely held, certainly. Legacy holders may resort to other means, given this stance, however. (Transfers that ARIN can't see and/or transit arrangements that look a whole lot like address leasing) Matthew Kaufman -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Feb 25 00:59:38 2011 From: bill at herrin.us (William Herrin) Date: Fri, 25 Feb 2011 00:59:38 -0500 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D673BD8.6040003@matthew.at> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> Message-ID: On Fri, Feb 25, 2011 at 12:19 AM, Matthew Kaufman wrote: > So the issue is that if ARIN believes that legacy non-LRSA resources are not > transferable and yet the transferer and the transferee believe they are, we > have a problem. > > There's two courses of actions for the transfering parties to take in this > case: not tell ARIN (which is bad for the database quality), or sue ARIN > (which is bad for ARIN in other ways). Don't tell ARIN = okay, but your records look fishy, are fishy, and are viewed with suspicion by your vendors. And they're always the old registrant plus a chain of messy looking signed letters leading to you. Sue = Kremen. IIRC, the legal precedent was set. No transfer of legacy addresses without them coming under RSA. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Daniel_Alexander at Cable.Comcast.com Fri Feb 25 01:02:12 2011 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 25 Feb 2011 06:02:12 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> Message-ID: Benson, One thing that strikes me about many proposals is that they are valid ideas, but are often dependent on everyone acting appropriately. The problem is that this rarely matches reality. Putting aside the "why" of prop-136, I would be interested in reading your thoughts on how the community would deal with, or benefit from, an environment that included this change, when things go wrong? Everyone likes to talk about the benefits of a market and efficiencies that may or may not be provided. While this model is possible, I'm trying to understand how this change would benefit all involved more than the current model. On the surface, it looks like the only ones that would benefit from a change like this would be those who hope to profit from brokering transfers. While we could open the door to opt out of services, this genie cannot be put back in the bottle if it's let out. While a resource holder could be given the opportunity to opt out of services provided by ARIN, there is no recourse in this proposal for those who are unable to maintain the pointers. There are also no restrictions on how many levels this could go if blocks were transferred repeatedly. There are also no obligations placed on resource holders should transfers go more than one level deep. And there is no way to ensure that pointers would remain relevant once blocks get transferred multiple times. Law enforcement agencies, service providers, and end users already have a difficult time trying to track down the users of a resource in WHOIS. What recourse is there when broken chains are formed through opt out transfers? At least in the current model, the community can point to ARIN as a forum to direct these issues. ARIN also provides the forum for everyone on this list to voice issues, concerns, and suggestions for improvement. If a large percentage of IPv4 resource holders can opt out of ARIN registry services, where can one go to have their issues addressed? Sincerely, Dan Alexander On 2/24/11 12:52 PM, "Benson Schliesser" wrote: >Hi, Keith. > >On Feb 23, 2011, at 10:29 PM, Keith W. Hare wrote: > >> I am opposed to prop-136. >> >> Prop-136 is dancing around the edges of the real question of whether >>the ARIN community wants to give up on participant-driven policies and >>needs-based resource allocations in favor of money-based allocations and >>for-profit corporate policies. > >I don't think prop-136 dances around the issue: it deals with it >directly, for legacy holders in the ARIN region, by allowing them to >opt-out of ARIN regulation. > >> If Mr. Schliesser really thinks that some number of for-profit registry >>services are a better way to handle IPv4 address allocations (or >>assignments) then he should write a proposal to do that. Such a proposal >>would allow the ARIN community to discuss the merits of such a change, >>rather than spending time on intermediate steps and side issues. > >I agree that we need a discussion of the for-profit registry question. >And I don't expect it to be an easy one, similar to how unfriendly at >times the debate over domain names monetization was. > >However, I think it's perfectly reasonable to answer the question of >regulatory authority first. If the ARIN community rejects both prop-133 >and prop-136 then we are effectively saying that legacy holders have "no >option" but to submit to ARIN regulation. In either event, a discussion >of for-profit registry services would have a different foundation and >tone. > >Moreover, while the question of regulatory authority will impact a >discussion of for-profit registry services, address trading markets, etc, >it is actually a larger fundamental question. I agree that we should >discuss the issues you raise, but please don't lose sight of the actual >policy text and meaning. > >Cheers, >-Benson > >_______________________________________________ >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 Feb 25 01:11:39 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Feb 2011 22:11:39 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D6739E1.9000800@matthew.at> References: <5651702C-CCDE-4A69-A381-62A73E09B1B9@pch.net> <4D6739E1.9000800@matthew.at> Message-ID: <08BB4BF1-2B7E-45E1-928A-7BD602A33F81@delong.com> On Feb 24, 2011, at 9:10 PM, Matthew Kaufman wrote: > On 2/24/2011 5:22 PM, Bill Woodcock wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On Feb 24, 2011, at 5:13 PM, Scott Leibrand wrote: >>> I'm not sure it should even be necessary for a seller to have an LRSA to release resources under NRPM 8.3: there's nothing in the text of 8.3 that says they need to sign one: it just says " IPv4 number resources within the ARIN region may be released to ARIN by the authorized resource holder... >> >> That is correct. The 8.3 transfer policy specifically places no burden on the seller. The seller need not be an RSA or LRSA signatory, and presumably in most cases will not be. > > Yes, this appears to be correct, even though a cursory reading of the transfer section suggests otherwise (one needs to remember what "received" means in order to parse it correctly) > > However, it *is* the case that one must have signed the LRSA to list legacy resources in the STLS. Why is that? > While there are those that disagree with me (on the board and likely on the AC too), I believe that the lack of that requirement in 8.3 was an oversight and not the other way around. I think that if ARIN is going to facilitate transfers between organizations, it is only prudent to require a contractual relationship between ARIN and both organizations involved in the process that prevents (and/or indemnifies) ARIN in the event a dispute between the organizations later arises. Owen From woody at pch.net Fri Feb 25 01:35:09 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 24 Feb 2011 22:35:09 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D673BD8.6040003@matthew.at> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> Message-ID: <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 24, 2011, at 9:19 PM, Matthew Kaufman wrote: > So the issue is that if ARIN believes that legacy non-LRSA resources are not transferable and yet the transferer and the transferee believe they are, we have a problem. Then there's no problem, because there's no resource that's not transferrable. Qualifications attach to the recipient of a resource, not to the donor or the resource itself. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1nTZ0ACgkQGvQy4xTRsBEGwACffvmV4B+xOH1ml/S/TTFnZjgC Q7cAoMxKZw1mWhWwNjbjBCKWkcGZNWkD =HTCb -----END PGP SIGNATURE----- From bensons at queuefull.net Fri Feb 25 02:30:07 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 01:30:07 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> Message-ID: <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> Hi, John. On Feb 24, 2011, at 12:51 PM, John Curran wrote: > If the intended benefit of ARIN-prop-136 is to actually to > propose alternative transfer policies, it would be best to > propose the specific changes to the transfer policy section > of NRPM. The intended benefit of ARIN-prop-136 is to accommodate organizations that do not consent to be regulated by ARIN policy. Secondary benefits may accrue to organizations that opt-out, presumably motivating them to do so. There may be any number of benefits, including alternative approaches to transfers. It is my belief that ARIN doesn't have any fundamental authority to prevent an opt-out, and that prop-136 would reconcile policy with reality in order to avoid unnecessary damages (to the address holders and the community). On Feb 24, 2011, at 6:01 PM, John Curran wrote: > If it turns out there are parties who neither like the policy nor are willing to > participate in getting it changed to meet their needs, then ARIN probably > can't help them, because we bound by existing agreements to manage the > resources accordingly and to maintaining an open and transparent process > for policy change. While I do have an open mind on the topic, I don't currently accept the premise that ARIN has the authority to force any legacy holders to submit to regulation or participate in its development. Threats of reclamation are an attempt to enforce policy on an organization that does not submit, in a manner that may cause legal liability to ARIN if acted upon, and I anticipate that such activity would violate US anti-trust laws. In that light, I'm motivated to help ARIN avoid improper behavior by personally participating in the development of policy. By submitting ARIN-prop-136 I am doing exactly that. I am not a legacy address holder, nor do I have any vested interest in any registry or related organization. I'm simply concerned about the future of ARIN, the rights of legacy holders, and the needs of the global Internet community. The constituents directly affected by this proposal may or may not participate in policy discussion, but that has never stopped ARIN from developing policy. As to the specific point about "existing agreements to manage the resources", and your comments elsewhere about the need for a global policy discussion, can you please clarify? I may be overlooking something, but I cannot find anything that prohibits ARIN from allowing organizations to opt-out of receiving ARIN services. Nor have I found anything prohibiting a registry/registrar system, liberal post-allocation transfers, etc. It would seem to be within ARIN's scope to define policy and implementation within the ARIN region. Cheers, -Benson From bensons at queuefull.net Fri Feb 25 02:35:15 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 01:35:15 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <005c01cbd3e4$fbabdde0$f30399a0$@iname.com> <75822E125BCB994F8446858C4B19F0D714409179F8@SUEX07-MBX-04.ad.syr.edu> Message-ID: Hi, Chris. On Feb 24, 2011, at 6:55 PM, Chris Grundemann wrote: > I would propose working within the existing, open and transparent, > system to solve any potential problems. I agree, and I think that a number of policy proposals might improve the existing system. However, I don't think that we can force an organization to this same conclusion. If somebody dislikes the existing system, we cannot make them use it. One approach to this dilemma is the pursuit of official authority, so that ARIN can enforce policy on everybody in the region. The alternative approach, which I have taken with prop-136, is to reconcile policy with the current reality. Cheers, -Benson From gbonser at seven.com Fri Feb 25 02:41:28 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Feb 2011 23:41:28 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com><6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Benson Schliesser > Sent: Thursday, February 24, 2011 11:30 PM > To: John Curran > Cc: arin-ppml at arin.net List > Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed > forUnaffiliated Address Blocks > > Hi, John. > > On Feb 24, 2011, at 12:51 PM, John Curran wrote: > > If the intended benefit of ARIN-prop-136 is to actually to > > propose alternative transfer policies, it would be best to > > propose the specific changes to the transfer policy section > > of NRPM. > > The intended benefit of ARIN-prop-136 is to accommodate organizations > that do not consent to be regulated by ARIN policy. > > Secondary benefits may accrue to organizations that opt-out, presumably > motivating them to do so. There may be any number of benefits, > including alternative approaches to transfers. Actually, it might hasten the demise of IPv4 so it might not be a bad thing in the broad view. It would result in more networks being blocked, more segments being hijacked, all sorts of nefarious hijinks. This would probably speed up people shutting access to more v4 space. Go for it. From bensons at queuefull.net Fri Feb 25 02:42:19 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 01:42:19 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D66A7C0.4000803@matthew.at> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <4D66A7C0.4000803@matthew.at> Message-ID: <290C4A3C-DBC1-46C3-88EA-62D547631122@queuefull.net> Hi, Matthew. On Feb 24, 2011, at 12:47 PM, Matthew Kaufman wrote: > I don't understand the proposal. Are you trying to: > > A) Keep the registration (uniqueness), whois (at least pointers), and reverse DNS (again, at least pointers) for the legacy address blocks in the ARIN region under ARIN control? (In which case I don't see what anyone would be "opting out" of) > > B) Remove the legacy address blocks from ARIN control and transfer them to a new entity? (In which case I think you need to be operating under ICANN ICP-2 with regard to the formation of this new entity, and it isn't appropriate for the ARIN PDP) > > C) Remove the legacy address blocks from ARIN control and NOT transfer them to a new entity? (In which case I'm not sure where you'd go, because ICANN clearly has the assumption that a single RIR will have responsibility for the block(s)) I'm not pre-supposing any one approach. I think approach A above is the status quo, and (as you say) it wouldn't be an opt-out. However, approach B or C make sense - an organization might opt-out of ARIN whois in order to run their own whois server or ask somebody else to do it on their behalf. Note that, regarding approach B, the entity doesn't necessarily have to be a RIR within the meaning of ICP-2. ARIN could, for instance, allow a registry/registrar approach, allow a post-allocation service provider approach, etc - wherein the ARIN whois remains the common fabric that connects the distributed system. This is something that would have to emerge. Cheers, -Benson From bensons at queuefull.net Fri Feb 25 02:45:56 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 01:45:56 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> References: <1110224132339.854B-400000@Ives.egh.com><6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> Message-ID: <74882908-7A57-4643-910F-D31D4FA98882@queuefull.net> On Feb 25, 2011, at 1:41 AM, George Bonser wrote: >> The intended benefit of ARIN-prop-136 is to accommodate organizations >> that do not consent to be regulated by ARIN policy. >> >> Secondary benefits may accrue to organizations that opt-out, > presumably >> motivating them to do so. There may be any number of benefits, >> including alternative approaches to transfers. > > Actually, it might hasten the demise of IPv4 so it might not be a bad > thing in the broad view. It would result in more networks being > blocked, more segments being hijacked, all sorts of nefarious hijinks. > This would probably speed up people shutting access to more v4 space. > Go for it. If organizations that opt-out fail to maintain operationally accurate whois data, then you may be correct. Prop 136 makes operationally accurate data a requirement. Whether this is a good or bad thing, in the context of v6 transition, is a valid thing to disagree about. :) Cheers, -Benson From gbonser at seven.com Fri Feb 25 02:48:53 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 24 Feb 2011 23:48:53 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <74882908-7A57-4643-910F-D31D4FA98882@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com><6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> <74882908-7A57-4643-910F-D31D4FA98882@queuefull.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D83@RWC-EX1.corp.seven.com> > > If organizations that opt-out fail to maintain operationally accurate > whois data, then you may be correct. Prop 136 makes operationally > accurate data a requirement. > > Whether this is a good or bad thing, in the context of v6 transition, > is a valid thing to disagree about. :) > > Cheers, > -Benson > How would one locate this accurate data if it isn't at ARIN? How is one supposed to know where it is? From bensons at queuefull.net Fri Feb 25 03:02:15 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 02:02:15 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13D83@RWC-EX1.corp.seven.com> References: <1110224132339.854B-400000@Ives.egh.com><6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> <74882908-7A57-4643-910F-D31D4FA98882@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D83@RWC-EX1.corp.seven.com> Message-ID: <999F1CE6-5724-41D2-AE9F-A19F35619421@queuefull.net> On Feb 25, 2011, at 1:48 AM, George Bonser wrote: > > How would one locate this accurate data if it isn't at ARIN? How is one > supposed to know where it is? How do you know anything about data maintained by other RIRs, or organizations that use distributed whois (rwhois), today? I expect prop 136 to be comparable. Cheers, -Benson From jcurran at arin.net Fri Feb 25 03:02:34 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 08:02:34 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> Message-ID: <59300825-6E20-4B2D-B701-B9D096787014@arin.net> On Feb 25, 2011, at 3:30 PM, Benson Schliesser wrote: > It is my belief that ARIN doesn't have any fundamental authority to prevent an opt-out, and that prop-136 would reconcile policy with reality in order to avoid unnecessary damages (to the address holders and the community). Interesting belief system, but incorrect. It's actually the other way around, in that ARIN is obligated to adhere to global number resource policy, and this specifies that a single RIR shall serve a given geography. > ... > In that light, I'm motivated to help ARIN avoid improper behavior by personally participating in the development of policy. Your concern for the organization's performance (while misplaced in this particular case) is so noted. The good news is that we have competent staff and counsel to assist ARIN performing in accordance with mission and law, with such guidance is ultimately subject to the judgement of the elected Board. > As to the specific point about "existing agreements to manage the resources", and your comments elsewhere about the need for a global policy discussion, can you please clarify? I may be overlooking something, but I cannot find anything that prohibits ARIN from allowing organizations to opt-out of receiving ARIN services. The very first principle of ICANN ICP-2 states: "Each region should be served by a single RIR, established under one management and in one location. The establishment of multiple RIRs in one region is likely to lead to: ? fragmentation of address space allocated to the region; ? difficulty for co-ordination and co-operation between the RIRs; ? confusion for the community within the region. " Not surprisingly, those very concerns seem to echo what many have said on this list regarding "alternative" registries. FYI, /John John Curran President and CEO ARIN From gbonser at seven.com Fri Feb 25 03:09:48 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Feb 2011 00:09:48 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <999F1CE6-5724-41D2-AE9F-A19F35619421@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com><6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> <74882908-7A57-4643-910F-D31D4FA98882@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D83@RWC-EX1.corp.seven.com> <999F1CE6-5724-41D2-AE9F-A19F35619421@queuefull.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D84@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Benson Schliesser [mailto:bensons at queuefull.net] > Sent: Friday, February 25, 2011 12:02 AM > To: George Bonser > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed > forUnaffiliated Address Blocks > > > On Feb 25, 2011, at 1:48 AM, George Bonser wrote: > > > > How would one locate this accurate data if it isn't at ARIN? How is > one > > supposed to know where it is? > > How do you know anything about data maintained by other RIRs, or > organizations that use distributed whois (rwhois), today? I expect > prop 136 to be comparable. > > Cheers, > -Benson If people can't find it, it is useless. If you have a pointer from ARIN to it, and then if you move it again when the organization you have it with goes broke, and you have to keep going back to ARIN to update the record pointing at the information, then you might as well have used ARIN in the first place. In any case, the amount of space we are talking about that doesn't belong to the US Government or other large corporations that aren't likely to change what they are doing now is pretty small. This stands to benefit only a tiny number of people. How does it benefit me, my neighbor, and the community in general? It potentially increases the headaches associated with tracking down owners of addresses to troubleshoot problems or stop nefarious activity. I see it as somewhat nihilistic. It has the potential to do more damage than benefit. The addresses belong to the community, not to the assignee. This does not help the community. Still opposed. From bensons at queuefull.net Fri Feb 25 03:12:25 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 02:12:25 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: Message-ID: <82AD97AC-AD1B-4B68-B9A3-CFD3040A5316@queuefull.net> Hi, Dan. Thanks for your thoughtful questions. On Feb 25, 2011, at 12:02 AM, Alexander, Daniel wrote: > Everyone likes to talk about the benefits of a market and efficiencies > that may or may not be provided. While this model is possible, I'm trying > to understand how this change would benefit all involved more than the > current model. On the surface, it looks like the only ones that would > benefit from a change like this would be those who hope to profit from > brokering transfers. While we could open the door to opt out of services, > this genie cannot be put back in the bottle if it's let out. To some extent, I'm not sure the genie is under our control in the first place. But focusing on your question of "who benefits"... Prop 136 doesn't deal directly with address markets, but may help a legacy market emerge. You mentioned brokers as benefiting, which is probably true. But I would suggest that buyers and sellers would be the primary beneficiaries of a market. Consider for example: regulated industries like health care that may need access to IPv4 addresses, developing economies around the world including those in regions with fewer addresses than the ARIN region, etc. A market certainly brings with it a number of new fears, but would also have much benefit. > While a resource holder could be given the opportunity to opt out of > services provided by ARIN, there is no recourse in this proposal for those > who are unable to maintain the pointers. There are also no restrictions on > how many levels this could go if blocks were transferred repeatedly. There > are also no obligations placed on resource holders should transfers go > more than one level deep. And there is no way to ensure that pointers > would remain relevant once blocks get transferred multiple times. This is a valid point. I see two questions that need to be considered. First, I agree that the proposal would be improved by dealing with the possibility of future non-performance of the whois requirement. I'm not sure what to do about that specifically, and would welcome input. Second, I think we need to have a discussion about deaggregation. Topmost blocks being transferred repeatedly might create a transaction cost for ARIN, but is otherwise minimal impact on the community. However, if a topmost block is parceled then there may be an undesirable effect on the routing table. My personal opinion is that this is unavoidable - new routes show up every time a new network is created or multi-homes. In fact, ARIN policy of "needs-based justification" amplifies this effect by causing networks to announce multiple smaller blocks (rather than one very large block). Nevertheless anything we can do to prevent table growth, as a result of people buying lots of small address blocks, would be good. Perhaps this could be another requirement for opt-out, such as an agreement to not deaggregate faster than 2 bits per year. Do you have any thoughts on how to deal with this? > Law enforcement agencies, service providers, and end users already have a > difficult time trying to track down the users of a resource in WHOIS. What > recourse is there when broken chains are formed through opt out transfers? > At least in the current model, the community can point to ARIN as a forum > to direct these issues. ARIN also provides the forum for everyone on this > list to voice issues, concerns, and suggestions for improvement. If a > large percentage of IPv4 resource holders can opt out of ARIN registry > services, where can one go to have their issues addressed? If an organization were to opt-out, the goal would be for them to continue maintaining their own whois records and have ARIN point to them. Under those circumstances I think the model works. But I agree, if somebody fails to maintain their delegated whois records then we have an undesired outcome. As I mentioned above, I'm interested in feedback on how to solve this. Revoking the opt-out seems awkward, but I'm not sure what else is possible. Cheers, -Benson From andrew.koch at gawul.net Fri Feb 25 03:15:54 2011 From: andrew.koch at gawul.net (Andrew Koch) Date: Fri, 25 Feb 2011 02:15:54 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <999F1CE6-5724-41D2-AE9F-A19F35619421@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> <74882908-7A57-4643-910F-D31D4FA98882@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D83@RWC-EX1.corp.seven.com> <999F1CE6-5724-41D2-AE9F-A19F35619421@queuefull.net> Message-ID: On Fri, Feb 25, 2011 at 02:02, Benson Schliesser wrote: > > On Feb 25, 2011, at 1:48 AM, George Bonser wrote: >> >> How would one locate this accurate data if it isn't at ARIN? ?How is one >> supposed to know where it is? > > How do you know anything about data maintained by other RIRs, or organizations that use distributed whois (rwhois), today? ?I expect prop 136 to be comparable. I go to IANA to provide information on which RIR maintains registry data for specific /8 blocks. From there, I am able to go to the specified RIR. There may be further referrals from the RIR downward, but only for registered blocks. In your proposal, this linkage breaks. Andy From bensons at queuefull.net Fri Feb 25 03:31:23 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 02:31:23 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <59300825-6E20-4B2D-B701-B9D096787014@arin.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> Message-ID: On Feb 25, 2011, at 2:02 AM, John Curran wrote: > On Feb 25, 2011, at 3:30 PM, Benson Schliesser wrote: > >> It is my belief that ARIN doesn't have any fundamental authority to prevent an opt-out, and that prop-136 would reconcile policy with reality in order to avoid unnecessary damages (to the address holders and the community). > > Interesting belief system, but incorrect. It's actually the other > way around, in that ARIN is obligated to adhere to global number > resource policy, and this specifies that a single RIR shall serve > a given geography. I have no argument opposing that ARIN is obligated to perform according to its own bylaws and agreements (with ICANN, RSA holders, etc). My statement is that ARIN lacks authority to exert regulation over unaffiliated organizations, such as legacy holders that haven't signed a LRSA. If such an organization decides to transfer addresses without consulting ARIN, and ARIN enforces policy over that organization as a result of their actions, then ARIN has exerted authority. Where does such authority come from? >> ... >> In that light, I'm motivated to help ARIN avoid improper behavior by personally participating in the development of policy. > > Your concern for the organization's performance (while misplaced > in this particular case) is so noted. > > The good news is that we have competent staff and counsel to > assist ARIN performing in accordance with mission and law, > with such guidance is ultimately subject to the judgement of > the elected Board. I'm glad to hear that. On the other hand, this statement doesn't exactly reinforce your previous comments about community driven policy development. Is it really board-driven and/or staff-driven policy development? >> As to the specific point about "existing agreements to manage the resources", and your comments elsewhere about the need for a global policy discussion, can you please clarify? I may be overlooking something, but I cannot find anything that prohibits ARIN from allowing organizations to opt-out of receiving ARIN services. > > The very first principle of ICANN ICP-2 states: > > "Each region should be served by a single RIR, established under > one management and in one location. The establishment of multiple > RIRs in one region is likely to lead to: > > ? fragmentation of address space allocated to the region; > ? difficulty for co-ordination and co-operation between the RIRs; > ? confusion for the community within the region. " > > Not surprisingly, those very concerns seem to echo what many have > said on this list regarding "alternative" registries. Yes, I read ICP-2 before asking the question. It appears to prefer ("should") a single RIR per region, and gives reasons for a centralized management structure. However I don't see where ICP-2 limits the ability of an RIR to choose the specific implementation details of that management structure. Can you clarify further? Cheers, -Benson From owen at delong.com Fri Feb 25 03:29:33 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 00:29:33 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed forUnaffiliated Address Blocks In-Reply-To: <999F1CE6-5724-41D2-AE9F-A19F35619421@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com><6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D82@RWC-EX1.corp.seven.com> <74882908-7A57-4643-910F-D31D4FA98882@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D83@RWC-EX1.corp.seven.com> <999F1CE6-5724-41D2-AE9F-A19F35619421@queuefull.net> Message-ID: <2BFCD29F-7234-4B2F-8190-14AD68EB0A3E@delong.com> On Feb 25, 2011, at 12:02 AM, Benson Schliesser wrote: > > On Feb 25, 2011, at 1:48 AM, George Bonser wrote: >> >> How would one locate this accurate data if it isn't at ARIN? How is one >> supposed to know where it is? > > How do you know anything about data maintained by other RIRs, or organizations that use distributed whois (rwhois), today? I expect prop 136 to be comparable. > Today, there is a well known set of 5 cooperating RIRs. You are proposing a not well known set of an indeterminate number of registries. Try again. Owen From woody at pch.net Fri Feb 25 03:36:11 2011 From: woody at pch.net (Bill Woodcock) Date: Fri, 25 Feb 2011 00:36:11 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> Message-ID: <76157739-84F5-4F06-B395-252F672DC816@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2011, at 12:31 AM, Benson Schliesser wrote: > Where does such authority come from? - From the same government that allocated the addresses to the legacy holder in the first place. You can't have it both ways. Either: 1) The USG had the authority to allocate addresses to legacy holders, and still has the authority to delegate management of those address to ICANN -> NRO -> ARIN, or 2) The USG has no authority in the matter, and thus legacy holders have no claim in the first place. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1nafsACgkQGvQy4xTRsBEgJwCdFw1fWhBW+LXa55Xqw+C0Pf6o T0YAoLMFLiVY2urlMGdy/pj75kwBnhsk =nkTe -----END PGP SIGNATURE----- From jcurran at arin.net Fri Feb 25 03:46:45 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 08:46:45 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> Message-ID: On Feb 25, 2011, at 4:31 PM, Benson Schliesser wrote: > I have no argument opposing that ARIN is obligated to perform according to its own bylaws and agreements (with ICANN, RSA holders, etc). My statement is that ARIN lacks authority to exert regulation over unaffiliated organizations, such as legacy holders that haven't signed a LRSA. If such an organization decides to transfer addresses without consulting ARIN, and ARIN enforces policy over that organization as a result of their actions, then ARIN has exerted authority. Where does such authority come from? ARIN has full authority to manage entries in the ARIN Whois database. > ... > I'm glad to hear that. On the other hand, this statement doesn't exactly reinforce your previous comments about community driven policy development. Is it really board-driven and/or staff-driven policy development? The policy is community-developed, per the Policy Development Process (PDP) The PDP was adopted by the Board as part of ARIN's performance of its mission. > Yes, I read ICP-2 before asking the question. It appears to prefer ("should") a single RIR per region, and gives reasons for a centralized management structure. However I don't see where ICP-2 limits the ability of an RIR to choose the specific implementation details of that management structure. Can you clarify further? Please ask your question in the context of your policy proposal 136 so that I may address the question. As it is, I am unable to determine if you are suggesting that alternative registries would be an "implementation detail of that management structure" within the ARIN region. Thanks! /John John Curran President and CEO ARIN From bensons at queuefull.net Fri Feb 25 04:00:36 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 03:00:36 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> Message-ID: On Feb 25, 2011, at 2:46 AM, John Curran wrote: > On Feb 25, 2011, at 4:31 PM, Benson Schliesser wrote: >> I have no argument opposing that ARIN is obligated to perform according to its own bylaws and agreements (with ICANN, RSA holders, etc). My statement is that ARIN lacks authority to exert regulation over unaffiliated organizations, such as legacy holders that haven't signed a LRSA. If such an organization decides to transfer addresses without consulting ARIN, and ARIN enforces policy over that organization as a result of their actions, then ARIN has exerted authority. Where does such authority come from? > > ARIN has full authority to manage entries in the > ARIN Whois database. And no responsibility for the impact? This facile answer is tiring - I've heard it many times, and it is a word game. Actions have consequences, and enforcing policy over the "ARIN Whois" will effect the community. Specifically, the manner in which ARIN manages the Whois database may lead to different routing behavior, with a number of possible business and legal ramifications. Word games don't change that fact. >> Yes, I read ICP-2 before asking the question. It appears to prefer ("should") a single RIR per region, and gives reasons for a centralized management structure. However I don't see where ICP-2 limits the ability of an RIR to choose the specific implementation details of that management structure. Can you clarify further? > > Please ask your question in the context of your policy proposal > 136 so that I may address the question. As it is, I am unable > to determine if you are suggesting that alternative registries > would be an "implementation detail of that management structure" > within the ARIN region. In the context of proposal 136, as well as 133 and 134, you have suggested the need for a global policy discussion. My question is a result of your suggestion. Why specifically, in the context of global policy, is this not a matter for ARIN to decide? As I outlined in my quoted text above, I don't think ICP-2 limits ARIN's ability to decide this issue. But this is an honest question - if I'm overlooking something I'd like to know. Thanks, -Benson From owen at delong.com Fri Feb 25 04:11:07 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 01:11:07 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> Message-ID: <0D47568D-A16C-4A90-96E1-EB373871A572@delong.com> On Feb 25, 2011, at 1:00 AM, Benson Schliesser wrote: > > On Feb 25, 2011, at 2:46 AM, John Curran wrote: > >> On Feb 25, 2011, at 4:31 PM, Benson Schliesser wrote: >>> I have no argument opposing that ARIN is obligated to perform according to its own bylaws and agreements (with ICANN, RSA holders, etc). My statement is that ARIN lacks authority to exert regulation over unaffiliated organizations, such as legacy holders that haven't signed a LRSA. If such an organization decides to transfer addresses without consulting ARIN, and ARIN enforces policy over that organization as a result of their actions, then ARIN has exerted authority. Where does such authority come from? >> >> ARIN has full authority to manage entries in the >> ARIN Whois database. > > And no responsibility for the impact? > > This facile answer is tiring - I've heard it many times, and it is a word game. Actions have consequences, and enforcing policy over the "ARIN Whois" will effect the community. Specifically, the manner in which ARIN manages the Whois database may lead to different routing behavior, with a number of possible business and legal ramifications. Word games don't change that fact. > Neither does ARIN policy. ARIN policy does not affect router configurations directly. If you want to talk to people that run routers, nanog at nanog.org is -> that way, cisco-nsp is <- that way. You talk about word games, but, you are the one proposing to create ARIN policy to define a set of people you claim are not subject to ARIN policy which will create requirements on their behavior in being exempt from ARIN policy. If that isn't a word game (or at least a good example of cognitive dissonance combined with sophistry), it's certainly dysfunctional at best. > >>> Yes, I read ICP-2 before asking the question. It appears to prefer ("should") a single RIR per region, and gives reasons for a centralized management structure. However I don't see where ICP-2 limits the ability of an RIR to choose the specific implementation details of that management structure. Can you clarify further? >> >> Please ask your question in the context of your policy proposal >> 136 so that I may address the question. As it is, I am unable >> to determine if you are suggesting that alternative registries >> would be an "implementation detail of that management structure" >> within the ARIN region. > > In the context of proposal 136, as well as 133 and 134, you have suggested the need for a global policy discussion. My question is a result of your suggestion. Why specifically, in the context of global policy, is this not a matter for ARIN to decide? As I outlined in my quoted text above, I don't think ICP-2 limits ARIN's ability to decide this issue. But this is an honest question - if I'm overlooking something I'd like to know. > John quoted specifically the section of ICP-2 that specifies that there shall be one registry per geographic region. I think that makes it pretty clear that ICP-2 prohibits ARIN from recognizing additional registries much like the constitution limits the powers of congress. Owen > Thanks, > -Benson > > _______________________________________________ > 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 bensons at queuefull.net Fri Feb 25 04:27:37 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 03:27:37 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <76157739-84F5-4F06-B395-252F672DC816@pch.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> Message-ID: <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> On Feb 25, 2011, at 2:36 AM, Bill Woodcock wrote: > > On Feb 25, 2011, at 12:31 AM, Benson Schliesser wrote: >> Where does such authority come from? > > - From the same government that allocated the addresses to the legacy holder in the first place. > > You can't have it both ways. That seems fair - I agree. > Either: > > 1) The USG had the authority to allocate addresses to legacy holders, and still has the authority to delegate management of those address to ICANN -> NRO -> ARIN, or > > 2) The USG has no authority in the matter, and thus legacy holders have no claim in the first place. Option #1 above is perfectly reasonable. There is a DoC contract with ICANN for the IANA function. In the Joint Project Agreement related to that IANA contract, the DoC instructs ICANN to maintain legal agreements with the RIRs. A review of the NRO history reveals only a non-binding letter of affirmation with the NRO, but let's just assume that is adequate. In the affirmation letter, ICANN delegates responsibility for allocating addresses and "facilitating" development of policies. I do not see the delegation of other powers such as "reclamation" authority etc. Maybe I'm missing something? Cheers, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Feb 25 04:37:11 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 09:37:11 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> Message-ID: <7F766473-07DB-4BCC-AF96-7A6F83CF5E6C@arin.net> On Feb 25, 2011, at 5:00 PM, Benson Schliesser wrote: >>> I have no argument opposing that ARIN is obligated to perform according to its own bylaws and agreements (with ICANN, RSA holders, etc). My statement is that ARIN lacks authority to exert regulation over unaffiliated organizations, such as legacy holders that haven't signed a LRSA. If such an organization decides to transfer addresses without consulting ARIN, and ARIN enforces policy over that organization as a result of their actions, then ARIN has exerted authority. Where does such authority come from? >> >> ARIN has full authority to manage entries in the >> ARIN Whois database. > > And no responsibility for the impact? > > This facile answer is tiring - I've heard it many times, and it is a word game. Actions have consequences, and enforcing policy over the "ARIN Whois" will effect the community. Specifically, the manner in which ARIN manages the Whois database may lead to different routing behavior, with a number of possible business and legal ramifications. Word games don't change that fact. ARIN accepts responsibility for its actions, including management of entries in the ARIN Whois database. You have implied otherwise several times, and I've informed you that we do not see any issue. Regardless of the number of times that you ask the question, the answer does not change. >> Please ask your question in the context of your policy proposal >> 136 so that I may address the question. As it is, I am unable >> to determine if you are suggesting that alternative registries >> would be an "implementation detail of that management structure" >> within the ARIN region. > > In the context of proposal 136, as well as 133 and 134, you have suggested the need for a global policy discussion. My question is a result of your suggestion. Why specifically, in the context of global policy, is this not a matter for ARIN to decide? As I outlined in my quoted text above, I don't think ICP-2 limits ARIN's ability to decide this issue. But this is an honest question - if I'm overlooking something I'd like to know. My apologies for being unclear - In the policy proposal, you reference hypothetical "replacement directory services". If these entities are allowed under ARIN's local policy framework, then ICP-2 states that ARIN's policies would need to apply in a fair and equitable manner these entities just as they apply to ISP's in the region. Does that actually meet your requirements? I expected otherwise from the policy background statement. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Fri Feb 25 05:00:26 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 10:00:26 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> Message-ID: On Feb 25, 2011, at 5:27 PM, Benson Schliesser wrote: Option #1 above is perfectly reasonable. There is a DoC contract with ICANN for the IANA function. Correct. In the Joint Project Agreement related to that IANA contract, the DoC instructs ICANN to maintain legal agreements with the RIRs. The JPA has expired. A review of the NRO history reveals only a non-binding letter of affirmation with the NRO, but let's just assume that is adequate. In the affirmation letter, ICANN delegates responsibility for allocating addresses and "facilitating" development of policies. I do not see the delegation of other powers such as "reclamation" authority etc. Maybe I'm missing something? Perhaps the first sentence? "The NRO shall fulfill the role, responsibilities and functions of the ASO as defined within the ICANN Bylaws." Per the ICANN Bylaws, this includes advising the Board "with respect to policy issues relating to the operation, assignment, and management of Internet addresses." The Board accepted ICP-2 < http://www.icann.org/en/icp/icp-2.htm> as a statement of policy, with the NRO fulfilling ICANN's duties of coordination of number resources and in particular the stable and secure operation of the Internet's number identifier systems. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mysidia at gmail.com Fri Feb 25 08:41:47 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 25 Feb 2011 07:41:47 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D65B8B2.9070702@arin.net> References: <4D65B8B2.9070702@arin.net> Message-ID: On Wed, Feb 23, 2011 at 7:47 PM, ARIN wrote: > ARIN-prop-136: Services Opt-out Allowed for Unaffiliated Address Blocks > I oppose PP136. All ISP/end user resources are supposed to be subject to the policies and services of the regional registry responsible for those blocks. ARIN is the one and only registry responsible for providing the WHOIS and RDNS service for address blocks under its stewardship, including legacy assignments. There is no such thing as an unaffiliated block; they all became affiliated with ARIN a long time ago. WHOIS is not an optional service. Resources under an RSA cannot be opted out. All ARIN placing a "RWHOIS" referral or other stub entry in its WHOIS database amounts to is another way of ARIN providing WHOIS service for the 'stubbed' prefix. If ARIN provides a referral to a RWHOIS service of any type to the resource holder's whois server of choice, then that is providing WHOIS service to the block. I see no adequate justification to marginilize "legacy" resources further than they already are. -- -JH From cgrundemann at gmail.com Fri Feb 25 08:50:06 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 25 Feb 2011 06:50:06 -0700 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <82AD97AC-AD1B-4B68-B9A3-CFD3040A5316@queuefull.net> References: <82AD97AC-AD1B-4B68-B9A3-CFD3040A5316@queuefull.net> Message-ID: On Fri, Feb 25, 2011 at 01:12, Benson Schliesser wrote: > But focusing on your question of "who benefits"... ?Prop 136 doesn't deal directly with address markets, but may help a legacy market emerge. ?You mentioned brokers as benefiting, which is probably true. ?But I would suggest that buyers and sellers would be the primary beneficiaries of a market. ?Consider for example: regulated industries like health care that may need access to IPv4 addresses, developing economies around the world including those in regions with fewer addresses than the ARIN region, etc. ?A market certainly brings with it a number of new fears, but would also have much benefit. Transfer of space is already allowed in the ARIN region, and there are discussions going on now which may lead to them being allowed inter-RIR as well. So, all of the benefits to those with "extra" IPv4 addresses and those who need them are already built into the existing system. The only thing missing today is the ability for "address brokers" to get rich in the process. Cheers, ~Chris > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From Wesley.E.George at sprint.com Fri Feb 25 09:35:33 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 25 Feb 2011 14:35:33 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <8DEB5B81-B275-4822-8C78-E0AFE39E5198@delong.com> References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> <8DEB5B81-B275-4822-8C78-E0AFE39E5198@delong.com> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E3740B8@PDAWM12B.ad.sprint.com> Top-posting because I can't figure out a good place to insert into the thread below. I'm still not necessarily in support of this policy, but I think Bill's suggestions move it in a more sane direction. Definitely support #1. Honestly, I'd prefer that some of the folks who are supposedly waiting for this policy to pass would declare their intent to use it, or at least vocal in their support *on PPML* prior to the policy's passage so that we had a better sense of what the correct interpretation is, instead of a set of educated conjecture for and against. I had a quick scroll through the messages on this policy and the PP before it, so I may have missed some, but I see precious few ISP representatives commenting. Owen has been representing "their" interests by proxy in this most recent thread. But I understand that perhaps that's a combination of one's day job impeding on PPML timeslices and not wanting to publicly express private plans, so if the best we can do is to ask for registration (that may remain private) after the fact, so be it. And I think I like #2 as well, at least in spirit. I understand the reason that CGN needs to be deployed, but that doesn't mean I have to like it or by policy enable it to stick around longer than absolutely necessary. The idea behind this whole CGN debacle is that it's supposed to be a temporary measure to compensate for the fact that we (collectively) are not to a point where expecting some majority of users to be able to survive without IPv4 is even plausible for most ISPs, and that event horizon is probably at least 2 years out. I think it's reasonable to expect at some point that this needs to sunset in order to ensure that ISPs don't start to use it as a crutch to delay IPv6 support or lessen the pressure on content providers and equipment manufacturers to support IPv6 fully. Perhaps to address Owen's concern we could update it so that if only 9 are left, one can request/justify that it become an allocation for them, and they continue sharing it amongst themselves? My only concern would be enforcement. How does ARIN determine conclusively who is using it? It's not like it'll show up in the routing table... While you might get the first 10 to register so as to ensure the policy doesn't void out, there stops being an incentive for subsequent parties to register after that. I could see this being one of those things where the ISPs using it don't see fit to update ARIN when they stop, and even if ARIN asks, they might not get an answer. Also, what happens if it gets used outside of the ARIN region? That's been discussed on and off as an expected side effect, but if the users have no business relationship with ARIN, should they still register? What if no one is using it in ARIN region, but it's still in heavy use elsewhere? Do we still put it back in the free pool? Thanks, Wes George -----Original Message----- From: Owen DeLong [mailto:owen at delong.com] Sent: Thursday, February 24, 2011 11:43 AM To: William Herrin Cc: George, Wes E [NTK]; ARIN-PPML List Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] I would support change number 1. I would argue that change number 2 is unnecessary and potentially harmful. Why should 9 ISPs who have made very large use of this space suddenly have it revoked simply because they are the last 9 to deprecate its use? Owen On Feb 24, 2011, at 8:27 AM, William Herrin wrote: > On Wed, Feb 23, 2011 at 11:16 AM, Owen DeLong wrote: >> I think that isn't the argument. I think the argument is we have one >> or more mega-ISPs wanting this policy to pass, but if it does not, will be forced to apply for resources for [NAT444]. >> Current policy allows for them to number the necessary hosts >> accordingly, so, if this policy does not pass, there is nothing at >> all that would prevent them from each obtaining large blocks of >> addresses for this purpose. I don't know if any one of them could >> justify a /10 individually, but, I am quite certain that they can collectively easily exceed a /10. I'd estimate that they can probably come close to a /7, collectively. > > s/forced/choose/ > > They -could- choose to use RFC1918 addresses. They won't for all the > reasons you've said. But they could. > > Otherwise, agree with everything above. > > > So, Wes, Owen: Let's put our money where our mouths are so to speak. > If these addresses won't be wasted, let's require the policy to prove > it. Adjust the policy so that: > > 1) Within 6 months of ratification at least 10 ARIN allocation holders > must register with ARIN an intent to use addresses within the /10 in > their network within 24 months. If fewer than 10 register that intent > then the policy is void and the /10 is returned to the ARIN pool. > > 2) After the first 24 months and every 24 months thereafter ARIN must > review the use of the /10 and make a positive determination that at > least 10 ARIN allocation holders are actually using it. If fewer than > 10 are using it and ARIN does not otherwise have at least a > /8-equivalent available for allocation (i.e. IPv4 isn't yet on the > decline), the whole pool is recycled into ARIN's free pool with a 12 > month delay for the 9 or fewer folks using it to renumber. > > > Owen, if we can't find 10 ISPs who are willing to step up and say > they'll use these addresses then Wes will have made his point: this > won't be a good use of a /10. Can you accept that result? > > Wes, if a non-trivial number of ISPs actually use the addresses in > parallel then plainly this was a better use than assigning the > addresses to ISPs individually. Can you accept that result? > > > I hear a lot of ideology in this debate. Are either/both of you > willing to measure and follow the data instead? > > Regards, > Bill Herrin > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From jcurran at arin.net Fri Feb 25 10:33:57 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 15:33:57 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <82AD97AC-AD1B-4B68-B9A3-CFD3040A5316@queuefull.net> Message-ID: <3C632B88-5C4A-4DA0-A586-4724952BF113@corp.arin.net> On Feb 25, 2011, at 9:50 PM, Chris Grundemann wrote: > Transfer of space is already allowed in the ARIN region, and there are > discussions going on now which may lead to them being allowed > inter-RIR as well. So, all of the benefits to those with "extra" IPv4 > addresses and those who need them are already built into the existing > system. The only thing missing today is the ability for "address > brokers" to get rich in the process. I'm not certain that's missing either ("brokers getting rich") - While not the goal of the specified transfer policy, there is likely a great opportunity in helping organizations economize their usage and offer the unneeded space to others, and also in helping those who want to acquire such space for their growth needs, but it requires being a "broker" in the classic sense of bringing parties together as opposed to the "speculator" sense of the term. As long as those appearing before ARIN are presenting a valid transfer per policy, this works just fine, and there is no reason that someone making this happen can't be compensated for their efforts*. ARIN is indifferent to such arrangements as long as the participants in the transfer meet the policy and agree to the transfer. FYI, /John John Curran President and CEO ARIN *ARIN staff excluded (per conflict of interest policy) From cgrundemann at gmail.com Fri Feb 25 10:57:51 2011 From: cgrundemann at gmail.com (Chris Grundemann) Date: Fri, 25 Feb 2011 08:57:51 -0700 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D596163.7000009@arin.net> References: <4D596163.7000009@arin.net> Message-ID: I think we may be over-complicating a fairly straight forward issue here. There are few facts facing us: 1) IPv4 addresses are quickly approaching maximum utilization. 2) There are basically two ways to continue to grow the Internet beyond this threshold: A) Implement IPv6 B) Further oversubscribe IPv4 addresses (LSN) 3) Although 2-A could preclude the necessity of 2-B, it is likely that IPv6 deployment will take too long to avoid the need for LSN of some flavor in many/most growing networks. 4) LSN breaks stuff (with varying definitions of both breaks and stuff) 5) Overlapping the LSN and CPE NAPT ranges increases this brokeness We end up with two questions to ask: 1) Is there a problem that can be solved through policy? 2) Is the cost of the policy change greater or less than the benefit of the change? My opinion is that this proposal appropriately addresses the issue defined in fact 5 above. So, what is the cost? We lose one /10 that could have been assigned or allocated as unique space for a handful of orgs (or potentially one large one). But we gain a shared space that can be used by all ISPs with need for it, the world over. The proposal appears to provide the greatest good. Another argument against this policy (and a large part of why it failed in other forums) is that having this shared space available will encourage folks to deploy LSN, or to use LSN for a longer period of time. This is a lot like saying that putting blankets in cars will encourage folks to sleep in their cars. The fact is that while that may make sleeping in your car a bit more comfortable, sleeping in the house is still going to be the preferred option. Only folks who must sleep in their cars (deploy LSN), will. Everyone who can avoid it, will - regardless of some blankets. The only argument against that I see remaining sounds a lot like "well, I might be the guy who gets part of that /10 for myself..." If there are other arguments that I have missed, or if I am miscalculating the cost of this proposal, I would love to be enlightened. Cheers, ~Chris > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org From khelms at zcorum.com Fri Feb 25 11:25:50 2011 From: khelms at zcorum.com (Scott Helms) Date: Fri, 25 Feb 2011 11:25:50 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> Message-ID: <4D67D80E.9060900@zcorum.com> The only argument against that I see remaining sounds a lot like > "well, I might be the guy who gets part of that /10 for myself..." > > If there are other arguments that I have missed, or if I am > miscalculating the cost of this proposal, I would love to be > enlightened. > > Cheers, > ~Chris Well said Chris! -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jmaimon at chl.com Fri Feb 25 11:52:28 2011 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 25 Feb 2011 11:52:28 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> Message-ID: <4D67DE4C.8070304@chl.com> Chris Grundemann wrote: > So, what is the cost? We lose one /10 that could have been assigned or > allocated as unique space for a handful of orgs (or potentially one > large one). But we gain a shared space that can be used by all ISPs > with need for it, the world over. The proposal appears to provide the > greatest good. To who? Are they or are they not going to refrain from further justified requests so long as the resources are available to do so? Either way the space is gone (largely to the same folk). This way it is gone forever. If this cost (a quarter of the last IANA allocation to ARIN) was high enough to dissuade the community from reserving it for new entrants who have no other recourse but to beg borrow or steal addresses from the likely to form address cartel, I fail to see how it is now low enough to be used for marginal aid and comfort to the likely members of that very same cartel, who do have plenty of recourse. I will reiterate just the one option (of many) that I havent seen much discussion about, that of adding some intelligence into their dynamic provisioning systems. Say for example a DHCP server. A client that repeatedly refuses an address from Scope A is offered one from Scope B. And then Scope C. And then Scope D. Perhaps Scope Z is actually global unique addresses. Presumably the client would be rejecting the address because it cannot install it in its routing table due to conflicts. Or because the end user is frustratingly rebooting it repeatedly. Either way a large portion of the problem (its actual size a matter of opinion) is solved, from the provider point of view. Patent and royalty free. Very generous of me. Joe From Wesley.E.George at sprint.com Fri Feb 25 11:55:55 2011 From: Wesley.E.George at sprint.com (George, Wes E [NTK]) Date: Fri, 25 Feb 2011 16:55:55 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> Message-ID: <54E900DC635DAB4DB7A6D799B3C4CD8E374324@PDAWM12B.ad.sprint.com> I actually don't disagree with the facts that you raised, and I appreciate you trying to bring this to some closure. Allow me to summarize the grey areas that have triggered most of the debate and make it much less simple than you're making it. We have differing opinions as to the risk of triggering #5, as well as how much of an operational issue it might be for your average ISP, and little more than anecdotal evidence to go on to support either viewpoint. We also have differing opinions regarding the suitability of alternatives to prevent #5: a) an ISP repurposes some of their own space to use as inside NAT pool, with the understanding that implementing CGN will actually free up addresses that are in use today by those users moved to the CGN. b) squatting on unrouted but allocated space c) using whatever RFC1918 space meets the 80/20 rule for avoiding CPE gear defaults to ensure that the risk of encountering #5 is lowered, and when it happens, is more manageable to fix. If you are in the camp that believes that the above would solve most of the problems you listed, then you're wondering what problem this proposal is trying to solve. If you believe that none of the above are workable, or aren't workable enough for the majority of applications, then you likely believe that this proposal is the only correct answer. Finally, in addition to your questions, I'd add, "What happens if this proposal doesn't pass?" or perhaps "*Should* this problem be solved with policy?" Here again, we have nothing but educated guesses to go on, and I'm not sure "the Mega-ISPs will come in and make lots of requests for space for their CGN and we have to avoid that" is a good enough justification on its own, and I'm not in favor of policy for policy's sake. I'm not against this policy because I'd rather have part of the /10 for my company. I'm against it because I'm afraid of stranding limited resources to solve a problem in the face of imperfect, but still viable alternatives that do not require new addresses, especially when the threat of exhaustion in this manner remains largely unsubstantiated by any of the parties who have a vested interest in using this shared space. Wes George -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Grundemann Sent: Friday, February 25, 2011 10:58 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] I think we may be over-complicating a fairly straight forward issue here. There are few facts facing us: 1) IPv4 addresses are quickly approaching maximum utilization. 2) There are basically two ways to continue to grow the Internet beyond this threshold: A) Implement IPv6 B) Further oversubscribe IPv4 addresses (LSN) 3) Although 2-A could preclude the necessity of 2-B, it is likely that IPv6 deployment will take too long to avoid the need for LSN of some flavor in many/most growing networks. 4) LSN breaks stuff (with varying definitions of both breaks and stuff) 5) Overlapping the LSN and CPE NAPT ranges increases this brokeness We end up with two questions to ask: 1) Is there a problem that can be solved through policy? 2) Is the cost of the policy change greater or less than the benefit of the change? My opinion is that this proposal appropriately addresses the issue defined in fact 5 above. So, what is the cost? We lose one /10 that could have been assigned or allocated as unique space for a handful of orgs (or potentially one large one). But we gain a shared space that can be used by all ISPs with need for it, the world over. The proposal appears to provide the greatest good. Another argument against this policy (and a large part of why it failed in other forums) is that having this shared space available will encourage folks to deploy LSN, or to use LSN for a longer period of time. This is a lot like saying that putting blankets in cars will encourage folks to sleep in their cars. The fact is that while that may make sleeping in your car a bit more comfortable, sleeping in the house is still going to be the preferred option. Only folks who must sleep in their cars (deploy LSN), will. Everyone who can avoid it, will - regardless of some blankets. The only argument against that I see remaining sounds a lot like "well, I might be the guy who gets part of that /10 for myself..." If there are other arguments that I have missed, or if I am miscalculating the cost of this proposal, I would love to be enlightened. Cheers, ~Chris > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN > Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6781 bytes Desc: not available URL: From owen at delong.com Fri Feb 25 12:00:10 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 09:00:10 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> Message-ID: <7AA53746-34C9-42D8-8EE7-57B4B8E307D4@delong.com> On Feb 25, 2011, at 1:27 AM, Benson Schliesser wrote: > > On Feb 25, 2011, at 2:36 AM, Bill Woodcock wrote: >> >> On Feb 25, 2011, at 12:31 AM, Benson Schliesser wrote: >>> Where does such authority come from? >> >> - From the same government that allocated the addresses to the legacy holder in the first place. >> >> You can't have it both ways. > > That seems fair - I agree. > >> Either: >> >> 1) The USG had the authority to allocate addresses to legacy holders, and still has the authority to delegate management of those address to ICANN -> NRO -> ARIN, or >> >> 2) The USG has no authority in the matter, and thus legacy holders have no claim in the first place. > > Option #1 above is perfectly reasonable. There is a DoC contract with ICANN for the IANA function. In the Joint Project Agreement related to that IANA contract, the DoC instructs ICANN to maintain legal agreements with the RIRs. A review of the NRO history reveals only a non-binding letter of affirmation with the NRO, but let's just assume that is adequate. In the affirmation letter, ICANN delegates responsibility for allocating addresses and "facilitating" development of policies. I do not see the delegation of other powers such as "reclamation" authority etc. Maybe I'm missing something? > You seem to have left out the MOU: http://www.icann.org/en/aso/aso-mou-29oct04.htm and also the ICANN bylaws: http://www.icann.org/en/general/bylaws.htm#VIII Those documents combined make it pretty clear that number policy responsibility and address authority rest in the NRO/ASO. Again, revocation is the wrong term. Deregistration is a more accurate description of what would happen. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From mueller at syr.edu Fri Feb 25 12:38:36 2011 From: mueller at syr.edu (Milton L Mueller) Date: Fri, 25 Feb 2011 12:38:36 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <76157739-84F5-4F06-B395-252F672DC816@pch.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> Message-ID: <75822E125BCB994F8446858C4B19F0D714409798F0@SUEX07-MBX-04.ad.syr.edu> > -----Original Message----- > You can't have it both ways. > > Either: > > 1) The USG had the authority to allocate addresses to legacy holders, and still > has the authority to delegate management of those address to ICANN -> > NRO -> ARIN, or > > 2) The USG has no authority in the matter, and thus legacy holders have no > claim in the first place. > > False dichotomy. If the USG has no authority and legacy holders are currently holding the resource, most legal precedents and norms of justice would continue to let them hold it and dispose of it as they see fit. At least in this country, people who occupy unowned resources get to continue occupying them in the absence of any higher claim. From owen at delong.com Fri Feb 25 12:34:57 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 09:34:57 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D67DE4C.8070304@chl.com> References: <4D596163.7000009@arin.net> <4D67DE4C.8070304@chl.com> Message-ID: <71166A68-AD6C-4643-8804-92EED9A679B7@delong.com> On Feb 25, 2011, at 8:52 AM, Joe Maimon wrote: > > > Chris Grundemann wrote: > >> So, what is the cost? We lose one /10 that could have been assigned or >> allocated as unique space for a handful of orgs (or potentially one >> large one). But we gain a shared space that can be used by all ISPs >> with need for it, the world over. The proposal appears to provide the >> greatest good. > > To who? Are they or are they not going to refrain from further justified requests so long as the resources are available to do so? > > Either way the space is gone (largely to the same folk). This way it is gone forever. > > If this cost (a quarter of the last IANA allocation to ARIN) was high enough to dissuade the community from reserving it for new entrants who have no other recourse but to beg borrow or steal addresses from the likely to form address cartel, I fail to see how it is now low enough to be used for marginal aid and comfort to the likely members of that very same cartel, who do have plenty of recourse. > > I will reiterate just the one option (of many) that I havent seen much discussion about, that of adding some intelligence into their dynamic provisioning systems. > > Say for example a DHCP server. A client that repeatedly refuses an address from Scope A is offered one from Scope B. And then Scope C. And then Scope D. Perhaps Scope Z is actually global unique addresses. > > Presumably the client would be rejecting the address because it cannot install it in its routing table due to conflicts. Or because the end user is frustratingly rebooting it repeatedly. > > Either way a large portion of the problem (its actual size a matter of opinion) is solved, from the provider point of view. Patent and royalty free. Very generous of me. > You're requiring changes to both the CPE and the provisioning system that are impractical in the circumstance. Owen From matthew at matthew.at Fri Feb 25 12:46:11 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 25 Feb 2011 09:46:11 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> Message-ID: <4D67EAE3.7090802@matthew.at> On 2/24/2011 10:35 PM, Bill Woodcock wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Feb 24, 2011, at 9:19 PM, Matthew Kaufman wrote: >> So the issue is that if ARIN believes that legacy non-LRSA resources are not transferable and yet the transferer and the transferee believe they are, we have a problem. > Then there's no problem, because there's no resource that's not transferrable. I meant to say "if ARIN believes that legacy non-LRSA resources are not transferable *to another party who hasn't signed the RSA*, and yet the trasferer and the transferee believe they are" > Qualifications attach to the recipient of a resource, not to the donor or the resource itself. And how would you go about enforcing that in the case where, because of ARIN policy, neither party bothers to notify ARIN? Matthew Kaufman From kkargel at polartel.com Fri Feb 25 12:49:49 2011 From: kkargel at polartel.com (Kevin Kargel) Date: Fri, 25 Feb 2011 11:49:49 -0600 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67EAE3.7090802@matthew.at> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> Message-ID: <8695009A81378E48879980039EEDAD288C048DD3@MAIL1.polartel.local> > -----Original Message----- > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On > Behalf Of Matthew Kaufman > Sent: Friday, February 25, 2011 11:46 AM > To: Bill Woodcock > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] LRSA requirement for resources being transferred > (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address > Blocks > > On 2/24/2011 10:35 PM, Bill Woodcock wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > > > On Feb 24, 2011, at 9:19 PM, Matthew Kaufman wrote: > >> So the issue is that if ARIN believes that legacy non-LRSA resources > are not transferable and yet the transferer and the transferee believe > they are, we have a problem. > > Then there's no problem, because there's no resource that's not > transferrable. > > I meant to say "if ARIN believes that legacy non-LRSA resources are not > transferable *to another party who hasn't signed the RSA*, and yet the > trasferer and the transferee believe they are" > > > Qualifications attach to the recipient of a resource, not to the donor > or the resource itself. > > And how would you go about enforcing that in the case where, because of > ARIN policy, neither party bothers to notify ARIN? > > Matthew Kaufman > How would you even know it happened? From matthew at matthew.at Fri Feb 25 12:49:43 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 25 Feb 2011 09:49:43 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> Message-ID: <4D67EBB7.6050807@matthew.at> On 2/24/2011 11:30 PM, Benson Schliesser wrote: > Hi, John. > > On Feb 24, 2011, at 12:51 PM, John Curran wrote: >> If the intended benefit of ARIN-prop-136 is to actually to >> propose alternative transfer policies, it would be best to >> propose the specific changes to the transfer policy section >> of NRPM. > The intended benefit of ARIN-prop-136 is to accommodate organizations that do not consent to be regulated by ARIN policy. I just don't see how they opt-out under this policy. ARIN still provides the uniqueness (and can assign the addresses to someone else if they believe that something improper has happened, see the repeated veiled threats about ARIN simply updating the database it controls)... ARIN still provides the reverse DNS service... ARIN still provides the pointer to the whois service. Without actually moving the block in question from ARIN to another RIR that doesn't yet exist (and cannot be created using the ARIN PDP), I'm not sure how there's any improvement under this policy. Matthew Kaufman From matthew at matthew.at Fri Feb 25 12:51:12 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 25 Feb 2011 09:51:12 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <290C4A3C-DBC1-46C3-88EA-62D547631122@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <4D66A7C0.4000803@matthew.at> <290C4A3C-DBC1-46C3-88EA-62D547631122@queuefull.net> Message-ID: <4D67EC10.9040503@matthew.at> On 2/24/2011 11:42 PM, Benson Schliesser wrote: > Hi, Matthew. > > On Feb 24, 2011, at 12:47 PM, Matthew Kaufman wrote: >> I don't understand the proposal. Are you trying to: >> >> A) Keep the registration (uniqueness), whois (at least pointers), and reverse DNS (again, at least pointers) for the legacy address blocks in the ARIN region under ARIN control? (In which case I don't see what anyone would be "opting out" of) >> >> B) Remove the legacy address blocks from ARIN control and transfer them to a new entity? (In which case I think you need to be operating under ICANN ICP-2 with regard to the formation of this new entity, and it isn't appropriate for the ARIN PDP) >> >> C) Remove the legacy address blocks from ARIN control and NOT transfer them to a new entity? (In which case I'm not sure where you'd go, because ICANN clearly has the assumption that a single RIR will have responsibility for the block(s)) > I'm not pre-supposing any one approach. I think approach A above is the status quo, and (as you say) it wouldn't be an opt-out. However, approach B or C make sense - an organization might opt-out of ARIN whois in order to run their own whois server or ask somebody else to do it on their behalf. > > Note that, regarding approach B, the entity doesn't necessarily have to be a RIR within the meaning of ICP-2. ARIN could, for instance, allow a registry/registrar approach, allow a post-allocation service provider approach, etc - wherein the ARIN whois remains the common fabric that connects the distributed system. This is something that would have to emerge. Sure. But How does proposal 136 further this at all? Matthew Kaufman From jcurran at arin.net Fri Feb 25 12:51:38 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 17:51:38 +0000 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67EAE3.7090802@matthew.at> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> Message-ID: On Feb 26, 2011, at 1:46 AM, Matthew Kaufman wrote: > And how would you go about enforcing that in the case where, because of ARIN policy, neither party bothers to notify ARIN? We update the database when a valid request is submitted, otherwise we don't. Ultimately the ISP community decides the usefulness of the Whois database, and generally works for policy which matches their requirements. /John John Curran President and CEO ARIN From matthew at matthew.at Fri Feb 25 12:54:02 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 25 Feb 2011 09:54:02 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> Message-ID: <4D67ECBA.4000100@matthew.at> On 2/25/2011 12:46 AM, John Curran wrote: > > > ARIN has full authority to manage entries in the > ARIN Whois database. I keep reading this as "ARIN has full authority to remove entries that are currently in the ARIN whois database and (re-)assign the addresses that now appear to be free as a result to new holders"... Am I wrong? Matthew Kaufman From Daniel_Alexander at Cable.Comcast.com Fri Feb 25 12:56:00 2011 From: Daniel_Alexander at Cable.Comcast.com (Alexander, Daniel) Date: Fri, 25 Feb 2011 17:56:00 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <82AD97AC-AD1B-4B68-B9A3-CFD3040A5316@queuefull.net> Message-ID: On 2/25/11 3:12 AM, "Benson Schliesser" wrote: >Hi, Dan. > >Thanks for your thoughtful questions. > >On Feb 25, 2011, at 12:02 AM, Alexander, Daniel wrote: > >> Everyone likes to talk about the benefits of a market and efficiencies >> that may or may not be provided. While this model is possible, I'm >>trying >> to understand how this change would benefit all involved more than the >> current model. On the surface, it looks like the only ones that would >> benefit from a change like this would be those who hope to profit from >> brokering transfers. While we could open the door to opt out of >>services, >> this genie cannot be put back in the bottle if it's let out. > >To some extent, I'm not sure the genie is under our control in the first >place. But focusing on your question of "who benefits"... Prop 136 >doesn't deal directly with address markets, but may help a legacy market >emerge. You mentioned brokers as benefiting, which is probably true. >But I would suggest that buyers and sellers would be the primary >beneficiaries of a market. Consider for example: regulated industries >like health care that may need access to IPv4 addresses, developing >economies around the world including those in regions with fewer >addresses than the ARIN region, etc. A market certainly brings with it a >number of new fears, but would also have much benefit. [DA] I agree, I hear it is tough to keep a hold of a genie. While prop 136 does not deal directly with address markets, how markets develop would be a direct consequence of prop 136. If 136 were abandoned, transfers from one to another can still occur under existing policies. What you are proposing here is the difference between an unrestricted market that this proposal could enable, and an attempt at evolving a structured market that we hope could limit abuse under existing policies. I'm not na?ve enough to think that existing policy couldn't be abused, but I cannot see how 136 could provide an environment with fewer negative consequences. [DA] I should also revise an earlier point I made that brokers would be the only beneficiaries. This change is not limited to brokers facilitating the exchange of /24's or /16's between individuals or companies. This proposal could open the door for governments or international organizations to acquire /8's and circumvent the RIR's. I think the potential of these implications far outweigh the desires that a legacy resource holder may have to avoid ARIN policy. > >> While a resource holder could be given the opportunity to opt out of >> services provided by ARIN, there is no recourse in this proposal for >>those >> who are unable to maintain the pointers. There are also no restrictions >>on >> how many levels this could go if blocks were transferred repeatedly. >>There >> are also no obligations placed on resource holders should transfers go >> more than one level deep. And there is no way to ensure that pointers >> would remain relevant once blocks get transferred multiple times. > >This is a valid point. I see two questions that need to be considered. >First, I agree that the proposal would be improved by dealing with the >possibility of future non-performance of the whois requirement. I'm not >sure what to do about that specifically, and would welcome input. > >Second, I think we need to have a discussion about deaggregation. >Topmost blocks being transferred repeatedly might create a transaction >cost for ARIN, but is otherwise minimal impact on the community. >However, if a topmost block is parceled then there may be an undesirable >effect on the routing table. My personal opinion is that this is >unavoidable - new routes show up every time a new network is created or >multi-homes. In fact, ARIN policy of "needs-based justification" >amplifies this effect by causing networks to announce multiple smaller >blocks (rather than one very large block). Nevertheless anything we can >do to prevent table growth, as a result of people buying lots of small >address blocks, would be good. Perhaps this could be another requirement >for opt-out, such as an agreement to not deaggregate faster than 2 bits >per year. Do you have any thoughts on how to deal with this? > >> Law enforcement agencies, service providers, and end users already have >>a >> difficult time trying to track down the users of a resource in WHOIS. >>What >> recourse is there when broken chains are formed through opt out >>transfers? >> At least in the current model, the community can point to ARIN as a >>forum >> to direct these issues. ARIN also provides the forum for everyone on >>this >> list to voice issues, concerns, and suggestions for improvement. If a >> large percentage of IPv4 resource holders can opt out of ARIN registry >> services, where can one go to have their issues addressed? > >If an organization were to opt-out, the goal would be for them to >continue maintaining their own whois records and have ARIN point to them. > Under those circumstances I think the model works. But I agree, if >somebody fails to maintain their delegated whois records then we have an >undesired outcome. As I mentioned above, I'm interested in feedback on >how to solve this. Revoking the opt-out seems awkward, but I'm not sure >what else is possible. [DA] I don't see a way around this problem. If a holder X has a non-(L)RSA resource and opts out of ARIN provided services, you suggest ARIN would provide a pointer to holder X. Now holder X transfers to holder Y. Holder Y has no obligations whatsoever to provide WHOIS services or pointers. While holder X may have a pointer, which they are not obligated to do, it will likely be irrelevant since holder Y, or anyone further down the chain has no obligation to do anything. This makes WHOIS services far worse then they are today. > >Cheers, >-Benson > From jmaimon at chl.com Fri Feb 25 13:02:10 2011 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 25 Feb 2011 13:02:10 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <71166A68-AD6C-4643-8804-92EED9A679B7@delong.com> References: <4D596163.7000009@arin.net> <4D67DE4C.8070304@chl.com> <71166A68-AD6C-4643-8804-92EED9A679B7@delong.com> Message-ID: <4D67EEA2.7040903@chl.com> Owen DeLong wrote: > On Feb 25, 2011, at 8:52 AM, Joe Maimon wrote: > > >> > You're requiring changes to both the CPE and the provisioning system that are impractical in the circumstance. > > Owen > > > The only changes required are on the DHCP server. DHCP clients will continue to request leases all on their own. End users will continue to reboot CPE's all on their own. And this is only one option of many, a number of which can be employed in tandem. Joe From jcurran at arin.net Fri Feb 25 13:07:51 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 18:07:51 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67ECBA.4000100@matthew.at> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> Message-ID: <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> On Feb 26, 2011, at 1:54 AM, Matthew Kaufman wrote: >> ARIN has full authority to manage entries in the >> ARIN Whois database. > > I keep reading this as "ARIN has full authority to remove entries that are currently in the ARIN whois database and (re-)assign the addresses that now appear to be free as a result to new holders"... Am I wrong? You are correct, if by full authority you mean legal authority. I will immediately note that there are many things one can do that is legal that may not be proper, particularly if one is a non-profit serving a particular mission and which has agreed to serve as part of the global number registry system. It's actually quite similar to the question that came up earlier, when someone asked if the Board developed policy or did the community. The fact is that the Board certainly has the ability to make policy, but we've adopted a policy development process which greatly encourages that policy is developed by the Internet community via a particular open and transparent process. What is normally appropriate to do in order to serve the mission is often a subset of the full range of actions which are simply allowed by law. So, in the case of the particular reassignment that you propose, I will note that we have done that on occasion, but generally only as a result of a resource fraud report when we determine that the original resource holder is defunct and the addresses have been hijacked. To do so simply because an registration was out of date and pointed to the original resource holder (despite obvious use by an unrelated party now) would require very clear direction from the community, and obviously would conflict with several policy proposals that have been made recently. Hope this helps, /John John Curran President and CEO ARIN From owen at delong.com Fri Feb 25 13:12:37 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 10:12:37 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67EAE3.7090802@matthew.at> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> Message-ID: On Feb 25, 2011, at 9:46 AM, Matthew Kaufman wrote: > On 2/24/2011 10:35 PM, Bill Woodcock wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> On Feb 24, 2011, at 9:19 PM, Matthew Kaufman wrote: >>> So the issue is that if ARIN believes that legacy non-LRSA resources are not transferable and yet the transferer and the transferee believe they are, we have a problem. >> Then there's no problem, because there's no resource that's not transferrable. > > I meant to say "if ARIN believes that legacy non-LRSA resources are not transferable *to another party who hasn't signed the RSA*, and yet the trasferer and the transferee believe they are" > In such case, the transferor and transferee are both mistaken. >> Qualifications attach to the recipient of a resource, not to the donor or the resource itself. > > And how would you go about enforcing that in the case where, because of ARIN policy, neither party bothers to notify ARIN? > Once ARIN becomes aware that the resources are no longer being utilized by the resource holder of record, they can be considered abandoned and made available for registration to an RSA-contracted recipient. Beyond that, there is no real need for enforcement, per se. Owen From owen at delong.com Fri Feb 25 13:10:31 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 10:10:31 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <75822E125BCB994F8446858C4B19F0D714409798F0@SUEX07-MBX-04.ad.syr.edu> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <75822E125BCB994F8446858C4B19F0D714409798F0@SUEX07-MBX-04.ad.syr.edu> Message-ID: <3EC3C997-ECD7-40B0-8C43-C26BD3FE9E55@delong.com> On Feb 25, 2011, at 9:38 AM, Milton L Mueller wrote: > >> -----Original Message----- >> You can't have it both ways. >> >> Either: >> >> 1) The USG had the authority to allocate addresses to legacy holders, and still >> has the authority to delegate management of those address to ICANN -> >> NRO -> ARIN, or >> >> 2) The USG has no authority in the matter, and thus legacy holders have no >> claim in the first place. >> >> > > False dichotomy. If the USG has no authority and legacy holders are currently holding the resource, most legal precedents and norms of justice would continue to let them hold it and dispose of it as they see fit. At least in this country, people who occupy unowned resources get to continue occupying them in the absence of any higher claim. > This includes a number of false assumptions... 1. IP Addresses are not property. 2. ARIN does not grant license, title, lease, or other property rights in addresses. 3. ARIN registers addresses and administers the registry for uniqueness. 4. People who run routers control who can actually route a particular prefix. They are free to use the ARIN database as a reference or not as they see fit. 5. As a registration service, absent a contract ARIN has the right to add, delete, or modify a registration as they see fit. Functioning within the terms of the ICANN MOU and within the combined RIR/ICANN/ASO/NRO structure makes things more convenient for everyone and makes the internet function more reliably than would a fragmented and disparate collection of registries with differing policies. However, nothing prevents such non-cooperating registries from acting as they wish. I do, however, tend to think that ISPs prefer a functional internet and are thus unlikely to give much credence to the data in such registries. Arguing over property rights in 32-bit integers is like trying to get a royalty from people for using the number 5. It might be amusing for a while, but, in the end, it's mostly pointless and maybe a bit counter-productive. Owen From tedm at ipinc.net Fri Feb 25 13:15:02 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 10:15:02 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> Message-ID: <4D67F1A6.30403@ipinc.net> On 2/25/2011 10:07 AM, John Curran wrote: > On Feb 26, 2011, at 1:54 AM, Matthew Kaufman wrote: >>> ARIN has full authority to manage entries in the >>> ARIN Whois database. >> >> I keep reading this as "ARIN has full authority to remove entries that are currently in the ARIN whois database and (re-)assign the addresses that now appear to be free as a result to new holders"... Am I wrong? > > You are correct, if by full authority you mean legal authority. > I will immediately note that there are many things one can do > that is legal that may not be proper, particularly if one is a > non-profit serving a particular mission and which has agreed to > serve as part of the global number registry system. > > It's actually quite similar to the question that came up earlier, > when someone asked if the Board developed policy or did the > community. The fact is that the Board certainly has the ability > to make policy, but we've adopted a policy development process > which greatly encourages that policy is developed by the Internet > community via a particular open and transparent process. What > is normally appropriate to do in order to serve the mission is > often a subset of the full range of actions which are simply > allowed by law. > > So, in the case of the particular reassignment that you propose, > I will note that we have done that on occasion, but generally > only as a result of a resource fraud report when we determine > that the original resource holder is defunct and the addresses > have been hijacked. To do so simply because an registration > was out of date and pointed to the original resource holder > (despite obvious use by an unrelated party now) would require > very clear direction from the community, and obviously would > conflict with several policy proposals that have been made > recently. > John, the community has given clear direction that such resources, when brought to your attention, are to be marked as bogus in whois. In fact, you are SUPPOSED to be seeking out and marking these as such. Or is there some clarity issue with section 3.6.1 of the NRPM? Ted > Hope this helps, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From JOHN at egh.com Fri Feb 25 13:26:05 2011 From: JOHN at egh.com (John Santos) Date: Fri, 25 Feb 2011 13:26:05 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: Message-ID: <1110225130621.854E-100000@Ives.egh.com> Nice summary, Chris. Perhaps this policy needs one additional feature: If it passes, CGN can not be included in "need" (for additional space) or in their existing usage (if they've already deployed it.) This would push anyone deploying it to use the allocated /10 rather than using their own private space. Also, in view of the proposal that if less then 10 organizations use it, or when usage drops below 10, that it revert to the normal unallocated pool, ARIN would have to keep track of usage. While doing this, perhaps they should also keep track of how much is being used and encourage orgs to use starting from the beginning of the address range (rather than random chunks in the middle.) Then, if it turns out that hundreds of orgs are using this space, but none are using more than a /14, the reserved space could be shrunk and the remainder returned to the free pool. But this may just be deck-chair re-arrangement. Finally, if the usage is popular, but eventually shrinks, that would most likely be a sign of wide-spread IPv6 single-stack adoption, and wasted or unused IPv4 would no longer be important to anyone. On Fri, 25 Feb 2011, Chris Grundemann wrote: > I think we may be over-complicating a fairly straight forward issue here. > > There are few facts facing us: > 1) IPv4 addresses are quickly approaching maximum utilization. > 2) There are basically two ways to continue to grow the Internet > beyond this threshold: > A) Implement IPv6 > B) Further oversubscribe IPv4 addresses (LSN) > 3) Although 2-A could preclude the necessity of 2-B, it is likely that > IPv6 deployment will take too long to avoid the need for LSN of some > flavor in many/most growing networks. > 4) LSN breaks stuff (with varying definitions of both breaks and stuff) > 5) Overlapping the LSN and CPE NAPT ranges increases this brokeness > > We end up with two questions to ask: > 1) Is there a problem that can be solved through policy? > 2) Is the cost of the policy change greater or less than the benefit > of the change? > > My opinion is that this proposal appropriately addresses the issue > defined in fact 5 above. > > So, what is the cost? We lose one /10 that could have been assigned or > allocated as unique space for a handful of orgs (or potentially one > large one). But we gain a shared space that can be used by all ISPs > with need for it, the world over. The proposal appears to provide the > greatest good. > > Another argument against this policy (and a large part of why it > failed in other forums) is that having this shared space available > will encourage folks to deploy LSN, or to use LSN for a longer period > of time. This is a lot like saying that putting blankets in cars will > encourage folks to sleep in their cars. The fact is that while that > may make sleeping in your car a bit more comfortable, sleeping in the > house is still going to be the preferred option. Only folks who must > sleep in their cars (deploy LSN), will. Everyone who can avoid it, > will - regardless of some blankets. > > The only argument against that I see remaining sounds a lot like > "well, I might be the guy who gets part of that /10 for myself..." > > If there are other arguments that I have missed, or if I am > miscalculating the cost of this proposal, I would love to be > enlightened. > > Cheers, > ~Chris -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From jcurran at arin.net Fri Feb 25 13:29:48 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 18:29:48 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67F1A6.30403@ipinc.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> Message-ID: On Feb 26, 2011, at 2:15 AM, Ted Mittelstaedt wrote: > > John, the community has given clear direction that such resources, > when brought to your attention, are to be marked as bogus in whois. > In fact, you are SUPPOSED to be seeking out and marking these > as such. > > Or is there some clarity issue with section 3.6.1 of the NRPM? There is no issue regarding 3.6.1 (POC validation) - we are performing it and give updates on it at each Public Policy meeting. I was referring the NRPM section 12. /John John Curran President and CEO ARIN From matthew at matthew.at Fri Feb 25 13:33:43 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 25 Feb 2011 10:33:43 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <3EC3C997-ECD7-40B0-8C43-C26BD3FE9E55@delong.com> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <75822E125BCB994F8446858C4B19F0D714409798F0@SUEX07-MBX-04.ad.syr.edu> <3EC3C997-ECD7-40B0-8C43-C26BD3FE9E55@delong.com> Message-ID: <4D67F607.3030605@matthew.at> On 2/25/2011 10:10 AM, Owen DeLong wrote: > > 4. People who run routers control who can actually route a particular prefix. They are > free to use the ARIN database as a reference or not as they see fit. And is there *any* concern here on the list that people will stop using the ARIN database as such a reference the moment ARIN removes the registration an address block that has been "improperly" transferred to an entity that is routing the space and hosting something that's popular, and allocates those same numbers to someone else? Matthew Kaufman From owen at delong.com Fri Feb 25 13:43:26 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 10:43:26 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <4D67EEA2.7040903@chl.com> References: <4D596163.7000009@arin.net> <4D67DE4C.8070304@chl.com> <71166A68-AD6C-4643-8804-92EED9A679B7@delong.com> <4D67EEA2.7040903@chl.com> Message-ID: <887E559A-5170-4E1A-B02E-1AA5CB5377A4@delong.com> On Feb 25, 2011, at 10:02 AM, Joe Maimon wrote: > > > Owen DeLong wrote: >> On Feb 25, 2011, at 8:52 AM, Joe Maimon wrote: >> >> >>> >> You're requiring changes to both the CPE and the provisioning system that are impractical in the circumstance. >> >> Owen >> >> >> > > The only changes required are on the DHCP server. DHCP clients will continue to request leases all on their own. End users will continue to reboot CPE's all on their own. > > And this is only one option of many, a number of which can be employed in tandem. > > Joe You've made the assertion that the DHCP client will reject a lease for an address that it cannot install in its routing table due to conflict with the LAN segment. I am arguing that would be a change to the behavior of most CPE. Yes, you can make the argument that CPE that doesn't behave that way is broken. Guess what, most CPE is arguably broken in at least one fundamental way. That's what happens when you buy routers for $30. Owen From jcurran at arin.net Fri Feb 25 13:44:34 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 18:44:34 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67F607.3030605@matthew.at> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <75822E125BCB994F8446858C4B19F0D714409798F0@SUEX07-MBX-04.ad.syr.edu> <3EC3C997-ECD7-40B0-8C43-C26BD3FE9E55@delong.com> <4D67F607.3030605@matthew.at> Message-ID: <101B8FF9-F041-41B0-A3F2-8C29BF3299F0@corp.arin.net> On Feb 26, 2011, at 2:33 AM, Matthew Kaufman wrote: > On 2/25/2011 10:10 AM, Owen DeLong wrote: >> >> 4. People who run routers control who can actually route a particular prefix. They are >> free to use the ARIN database as a reference or not as they see fit. > > And is there *any* concern here on the list that people will stop using the ARIN database as such a reference the moment ARIN removes the registration an address block that has been "improperly" transferred to an entity that is routing the space and hosting something that's popular, and allocates those same numbers to someone else? To make it worse: 'allocates those same numbers to something else which is also very popular.' There is absolutely a concern, which is why I'd recommend folks only make policy that they expect to be enforced and can live with the consequences. /John John Curran President and CEO ARIN From jmaimon at chl.com Fri Feb 25 13:58:53 2011 From: jmaimon at chl.com (Joe Maimon) Date: Fri, 25 Feb 2011 13:58:53 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <887E559A-5170-4E1A-B02E-1AA5CB5377A4@delong.com> References: <4D596163.7000009@arin.net> <4D67DE4C.8070304@chl.com> <71166A68-AD6C-4643-8804-92EED9A679B7@delong.com> <4D67EEA2.7040903@chl.com> <887E559A-5170-4E1A-B02E-1AA5CB5377A4@delong.com> Message-ID: <4D67FBED.2090105@chl.com> Owen DeLong wrote: > On Feb 25, 2011, at 10:02 AM, Joe Maimon wrote: > > >> >> Owen DeLong wrote: >> >>> On Feb 25, 2011, at 8:52 AM, Joe Maimon wrote: >>> >>> >>> >>>> >>> You're requiring changes to both the CPE and the provisioning system that are impractical in the circumstance. >>> >>> Owen >>> >>> >>> >>> >> The only changes required are on the DHCP server. DHCP clients will continue to request leases all on their own. End users will continue to reboot CPE's all on their own. >> >> And this is only one option of many, a number of which can be employed in tandem. >> >> Joe >> > You've made the assertion that the DHCP client will reject a lease for an address that it cannot install in > its routing table due to conflict with the LAN segment. I am arguing that would be a change to the > behavior of most CPE. > > I assume you have anecdotal evidence, just like I have anecdotal evidence of an ISP whose CPE defaults to 10.0.0.100/16, knocking out the DHCP client on the Corporate IOS with internal lan 10.4.x.x/27. Fix the mask, problem solved, remotely. A solution doesnt have to be perfect, it simply needs to lower the problem ratio to manageable levels. Which this would. Which the others solutions would as well. Which combined they would do so even more. > Yes, you can make the argument that CPE that doesn't behave that way is broken. Guess what, > most CPE is arguably broken in at least one fundamental way. That's what happens when you > buy routers for $30. > > Owen > > > These are exactly the CPE's that are rebooted repeatedly by their users hoping to get them to work again. More problem space covered. Joe From owen at delong.com Fri Feb 25 13:55:03 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 10:55:03 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67F607.3030605@matthew.at> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <75822E125BCB994F8446858C4B19F0D714409798F0@SUEX07-MBX-04.ad.syr.edu> <3EC3C997-ECD7-40B0-8C43-C26BD3FE9E55@delong.com> <4D67F607.3030605@matthew.at> Message-ID: On Feb 25, 2011, at 10:33 AM, Matthew Kaufman wrote: > On 2/25/2011 10:10 AM, Owen DeLong wrote: >> >> 4. People who run routers control who can actually route a particular prefix. They are >> free to use the ARIN database as a reference or not as they see fit. > > And is there *any* concern here on the list that people will stop using the ARIN database as such a reference the moment ARIN removes the registration an address block that has been "improperly" transferred to an entity that is routing the space and hosting something that's popular, and allocates those same numbers to someone else? > > Matthew Kaufman > Probably. However, if they do, they'll need something else to use instead. Whatever that is, I don't see anything good coming out of ARIN assisting in its construction or development. Such alternative registries with differing policies of address stewardship are contrary to what the ARIN community has spent years developing. I think they will, if utilized, destabilize the IPv4 internet. I tend to think that most ISPs will recognize this fact and continue to use the ARIN database and the policies they have worked with the ARIN community to develop. Owen From matthew at matthew.at Fri Feb 25 14:00:20 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 25 Feb 2011 11:00:20 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <101B8FF9-F041-41B0-A3F2-8C29BF3299F0@corp.arin.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <75822E125BCB994F8446858C4B19F0D714409798F0@SUEX07-MBX-04.ad.syr.edu> <3EC3C997-ECD7-40B0-8C43-C26BD3FE9E55@delong.com> <4D67F607.3030605@matthew.at> <101B8FF9-F041-41B0-A3F2-8C29BF3299F0@corp.arin.net> Message-ID: <4D67FC44.4090006@matthew.at> On 2/25/2011 10:44 AM, John Curran wrote: > > ...I'd recommend folks only make policy that they expect to be > enforced and can live with the consequences. > +1 Matthew Kaufman From Keith at jcc.com Fri Feb 25 14:19:30 2011 From: Keith at jcc.com (Keith W. Hare) Date: Fri, 25 Feb 2011 14:19:30 -0500 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> References: <4D65B8B2.9070702@arin.net> <8d75e1781ebad5a4f4f1e11c0a039a314d65ddbd@jcc.com> <83609417-4B3B-4833-A6A3-D201EA8BF069@queuefull.net> Message-ID: <5306350885dab705f8986ab266e1a9d34d67ffe9@jcc.com> > -----Original Message----- > From: Benson Schliesser [mailto:bensons at queuefull.net] > Sent: Thursday, February 24, 2011 12:52 PM > To: Keith W. Hare > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for > Unaffiliated Address Blocks > > Hi, Keith. > > On Feb 23, 2011, at 10:29 PM, Keith W. Hare wrote: > > > I am opposed to prop-136. > > > > Prop-136 is dancing around the edges of the real question of whether > the ARIN community wants to give up on participant-driven policies and > needs-based resource allocations in favor of money-based allocations and > for-profit corporate policies. > > I don't think prop-136 dances around the issue: it deals with it > directly, for legacy holders in the ARIN region, by allowing them to > opt-out of ARIN regulation. Opt-out of ARIN regulation in favor of what? What regulations would a for-profit registration service impose? And what is really in this for me? The ARIN process has been working fairly well -- the internet works reasonably well most of the time. What is it that is not working therefore needs to be changed? There is a little problem looming of running out of IPv4 addresses, but how would a for-profit registration service solve that any better than ARIN can? I've read discussion of market efficiencies, but what are the costs of using a for-profit registration service really going to be? How are the costs going to be cheaper than the costs for working with ARIN? The ARIN policy process is driven by the participants. My company has a legacy /24. However, I have as much voice in the ARIN policy process as someone representing the largest ISP. Why would I want to switch to a for-profit corporation where I would have no say in policies? What is it that the ARIN "regulation" is preventing me from doing? The only thing I can see that ARIN "regulation" prevents me from doing is transferring our IPv4 address resource to an organization who cannot justify a need for IPv4 addresses. I suppose that if someone offered ten million (US dollars) for our /24, I might feel differently, but I do not see any benefit to me in supporting IPv4 address speculators. As a small IPv4 resource holder, I think my company is better served by ARIN as it exists today than it would be by a for-profit registration service. Therefore, I continue to oppose Prop-136. Keith Hare ______________________________________________________________ Keith W. Hare JCC Consulting, Inc. keith at jcc.com 600 Newark Road Phone: 740-587-0157 P.O. Box 381 Fax: 740-587-0163 Granville, Ohio 43023 http://www.jcc.com USA ______________________________________________________________ From bensons at queuefull.net Fri Feb 25 14:19:06 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 13:19:06 -0600 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> Message-ID: <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> I think Chris' message below summarizes the issue correctly, and I support a shared transition space policy. Cheers, -Benson On Feb 25, 2011, at 9:57 AM, Chris Grundemann wrote: > I think we may be over-complicating a fairly straight forward issue here. > > There are few facts facing us: > 1) IPv4 addresses are quickly approaching maximum utilization. > 2) There are basically two ways to continue to grow the Internet > beyond this threshold: > A) Implement IPv6 > B) Further oversubscribe IPv4 addresses (LSN) > 3) Although 2-A could preclude the necessity of 2-B, it is likely that > IPv6 deployment will take too long to avoid the need for LSN of some > flavor in many/most growing networks. > 4) LSN breaks stuff (with varying definitions of both breaks and stuff) > 5) Overlapping the LSN and CPE NAPT ranges increases this brokeness > > We end up with two questions to ask: > 1) Is there a problem that can be solved through policy? > 2) Is the cost of the policy change greater or less than the benefit > of the change? > > My opinion is that this proposal appropriately addresses the issue > defined in fact 5 above. > > So, what is the cost? We lose one /10 that could have been assigned or > allocated as unique space for a handful of orgs (or potentially one > large one). But we gain a shared space that can be used by all ISPs > with need for it, the world over. The proposal appears to provide the > greatest good. > > Another argument against this policy (and a large part of why it > failed in other forums) is that having this shared space available > will encourage folks to deploy LSN, or to use LSN for a longer period > of time. This is a lot like saying that putting blankets in cars will > encourage folks to sleep in their cars. The fact is that while that > may make sleeping in your car a bit more comfortable, sleeping in the > house is still going to be the preferred option. Only folks who must > sleep in their cars (deploy LSN), will. Everyone who can avoid it, > will - regardless of some blankets. > > The only argument against that I see remaining sounds a lot like > "well, I might be the guy who gets part of that /10 for myself..." > > If there are other arguments that I have missed, or if I am > miscalculating the cost of this proposal, I would love to be > enlightened. > > Cheers, > ~Chris > From gbonser at seven.com Fri Feb 25 14:27:34 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Feb 2011 11:27:34 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> > > The only argument against that I see remaining sounds a lot like > > "well, I might be the guy who gets part of that /10 for myself..." > > > > If there are other arguments that I have missed, or if I am > > miscalculating the cost of this proposal, I would love to be > > enlightened. > > > > Cheers, > > ~Chris I am neutral on this one. The argument I see is that once that /10 is set aside for that purpose, you have no control that it is actually used for that purpose. It will become de facto 1918 space and people will use it in all sorts of places and you run into exactly the problem this /10 was meant to solve (resolving collisions between customer 1918 domains) when you start running into customer nets numbered in this /10 or nets in regions outside ARIN numbered in this range. From bensons at queuefull.net Fri Feb 25 14:35:13 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 13:35:13 -0600 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: <54E900DC635DAB4DB7A6D799B3C4CD8E374324@PDAWM12B.ad.sprint.com> References: <4D596163.7000009@arin.net> <54E900DC635DAB4DB7A6D799B3C4CD8E374324@PDAWM12B.ad.sprint.com> Message-ID: <2FE3BDDF-4758-4BA3-A07C-5D563B6108CB@queuefull.net> On Feb 25, 2011, at 10:55 AM, George, Wes E [NTK] wrote: > We also have differing opinions regarding the suitability of alternatives to prevent #5: > a) an ISP repurposes some of their own space to use as inside NAT pool, with the understanding that > implementing CGN will actually free up addresses that are in use today by those users moved to the > CGN. > b) squatting on unrouted but allocated space > c) using whatever RFC1918 space meets the 80/20 rule for avoiding CPE gear defaults to ensure that > the risk of encountering #5 is lowered, and when it happens, is more manageable to fix. > > If you are in the camp that believes that the above would solve most of the problems you listed, > then you're wondering what problem this proposal is trying to solve. If you believe that none of the > above are workable, or aren't workable enough for the majority of applications, then you likely > believe that this proposal is the only correct answer. I agree with this portrayal. Further, I've actually supported networks that were built according to each approach (a,b,c). And while they *can* be made to work, from my experiences I say that a shared transition space would be a valuable improvement. > Finally, in addition to your questions, I'd add, "What happens if this proposal doesn't pass?" or > perhaps "*Should* this problem be solved with policy?" Here again, we have nothing but educated > guesses to go on, and I'm not sure "the Mega-ISPs will come in and make lots of requests for space > for their CGN and we have to avoid that" is a good enough justification on its own, and I'm not in > favor of policy for policy's sake. According to my count, a /10 represents about 5% of the existing ARIN free pool (including IANA "holes"). I think it's safe to assume that at least some ISPs will use this shared transition space. So the question is whether that collection of ISPs would use more than 5% of the ARIN free pool. I've had conversations with multiple large ISPs about their CGN deployment plans, and collectively they would support 4-5x more customers behind a CGN than a single /10 would facilitate. Even if only 1 or 2 of these large ISPs follow-through with their plans, I think there is savings to the ARIN free pool. Cheers, -Benson From tedm at ipinc.net Fri Feb 25 14:37:31 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 11:37:31 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> Message-ID: <4D6804FB.6030202@ipinc.net> On 2/25/2011 10:29 AM, John Curran wrote: > On Feb 26, 2011, at 2:15 AM, Ted Mittelstaedt wrote: >> >> John, the community has given clear direction that such resources, >> when brought to your attention, are to be marked as bogus in whois. >> In fact, you are SUPPOSED to be seeking out and marking these >> as such. >> >> Or is there some clarity issue with section 3.6.1 of the NRPM? > > There is no issue regarding 3.6.1 (POC validation) - we are > performing it and give updates on it at each Public Policy > meeting. I was referring the NRPM section 12. > You had stated: "...To do so simply because an registration was out of date and pointed to the original resource holder (despite obvious use by an unrelated party now)..." John, please explain how a an out of date registration that points to the original resource holder despite obvious use by an unrelated party now, is NOT being deemed by ARIN staff to be completely and permanently abandoned. Seems to me by even making that hypothesis you are designating that legacy resource as abandoned - you are ARIN staff after all. ARIN cannot have it's cake and eat it too - if ARIN says a resource is being used by an unrelated party, then section 3.6.1 states "the POC record shall be marked invalid" Is it ARIN's position that legacy resources that are marked invalid are NOT available for reclamation because of section 12.8 somehow prohibiting ARIN from taking action? Because if that is ARIN's view then IMHO we need a policy proposal that modifies section 12.8 and directs ARIN to reclaim legacy resources that are marked completely and permanently abandonded by section 3.6.1 It seems to me that if an unrelated party is using a legacy resource that the first step of any legacy reclamation effort would be to contact that party and tell them they must sign an RSA and start paying the fees to continue using the numbers. Ted From jcurran at arin.net Fri Feb 25 14:38:33 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 19:38:33 +0000 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> Message-ID: <70ABB360-E28B-4A9D-BC10-0D5EBD158B63@corp.arin.net> On Feb 25, 2011, at 11:57 PM, Chris Grundemann wrote: > If there are other arguments that I have missed, or if I am > miscalculating the cost of this proposal, I would love to be > enlightened. On February 15th, the following update to staff assessment was made: >> In keeping with the spirit of RFC 2860 with respect to the assignment >> of specialized address blocks, ARIN Staff will consult with the IANA and >> the IAB regarding implementation of this draft policy. It is clear to me that ARIN can make this assignment with the consent of the IAB, but it is not clear that we may do so without such consent. I simply note that there exists a non-zero chance that this draft policy may encounter some atypical implementation issues. This is not a statement in favor or opposed, but simply a fact for the community to be aware for purposes of setting appropriate expectations. FYI, /John John Curran President and CEO ARIN From jcurran at arin.net Fri Feb 25 14:45:29 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 19:45:29 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D6804FB.6030202@ipinc.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> Message-ID: <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> On Feb 26, 2011, at 3:37 AM, Ted Mittelstaedt wrote: > ARIN cannot have it's cake and eat it too - if ARIN says > a resource is being used by an unrelated party, then section > 3.6.1 states "the POC record shall be marked invalid" Ted - If we determined that the POC was illegitimate, then we would mark the POC appropriate. This does not mandate a resource review per section NRPM 12, and a change to policy to mandate such would require discussing the level of staff resources we would need to dedicate to this effort. > It seems to me that if an unrelated party is using a legacy > resource that the first step of any legacy reclamation effort would > be to contact that party and tell them they must sign an RSA and > start paying the fees to continue using the numbers. We contact them and explain that they need to update the contact information on number resources accordingly, and if a different organization is involved, then must also initiate an appropriate transfer request. FYI, /John John Curran President and CEO ARIN From tedm at ipinc.net Fri Feb 25 14:53:39 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 11:53:39 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> Message-ID: <4D6808C3.7040808@ipinc.net> On 2/25/2011 11:45 AM, John Curran wrote: > On Feb 26, 2011, at 3:37 AM, Ted Mittelstaedt wrote: > >> ARIN cannot have it's cake and eat it too - if ARIN says >> a resource is being used by an unrelated party, then section >> 3.6.1 states "the POC record shall be marked invalid" > > Ted - If we determined that the POC was illegitimate, then > we would mark the POC appropriate. This does not mandate a > resource review per section NRPM 12, and a change to policy > to mandate such would require discussing the level of staff > resources we would need to dedicate to this effort. > Ah. Let me ask then - if a legacy POC is determined to be illegitimate and marked as such, then what is current ARIN practice - do you attempt to contact any squatter, or do you reclaim and reassign the resource, or do you simply do nothing? >> It seems to me that if an unrelated party is using a legacy >> resource that the first step of any legacy reclamation effort would >> be to contact that party and tell them they must sign an RSA and >> start paying the fees to continue using the numbers. > > > We contact them and explain that they need to update the > contact information on number resources accordingly, and > if a different organization is involved, then must also > initiate an appropriate transfer request. > But that assumes you can contact them, that the original entity exists. What if it does not? Or what if you contact them and they don't know who you are and what your talking about and can't answer your questions? Ted > FYI, > /John > > John Curran > President and CEO > ARIN > > From jcurran at arin.net Fri Feb 25 15:09:06 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 20:09:06 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D6808C3.7040808@ipinc.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> <4D6808C3.7040808@ipinc.net> Message-ID: On Feb 26, 2011, at 3:53 AM, Ted Mittelstaedt wrote: > Ah. Let me ask then - if a legacy POC is determined to be > illegitimate and marked as such, then what is current ARIN > practice - do you attempt to contact any squatter, or do > you reclaim and reassign the resource, or do you simply do nothing? POC validation will get them marked as unresponsive, but we are unlikely to determine them invalid unless it is the result of a fraud report, and yes, we try to determine whether the original resource holder is still out there somewhere. > But that assumes you can contact them, that the original entity > exists. What if it does not? Or what if you contact them and > they don't know who you are and what your talking about and > can't answer your questions? That happens... Generally, we can find someone who knows the relationship and then we work to document it. If it's a true squatter, they usually disappear at our first contact. If we can find the original resource holder, we change it to them, and if not we reclaim the resource and put it in hold down for reuse. FYI, /John John Curran President and CEO ARIN (about to go offline for 20 hrs) From bensons at queuefull.net Fri Feb 25 15:09:43 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 14:09:43 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <7AA53746-34C9-42D8-8EE7-57B4B8E307D4@delong.com> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> <7AA53746-34C9-42D8-8EE7-57B4B8E307D4@delong.com> Message-ID: <88083657-AB6B-45F7-B229-D638B9DAB9D2@queuefull.net> On Feb 25, 2011, at 11:00 AM, Owen DeLong wrote: >> Option #1 above is perfectly reasonable. There is a DoC contract with ICANN for the IANA function. In the Joint Project Agreement related to that IANA contract, the DoC instructs ICANN to maintain legal agreements with the RIRs. A review of the NRO history reveals only a non-binding letter of affirmation with the NRO, but let's just assume that is adequate. In the affirmation letter, ICANN delegates responsibility for allocating addresses and "facilitating" development of policies. I do not see the delegation of other powers such as "reclamation" authority etc. Maybe I'm missing something? >> > You seem to have left out the MOU: http://www.icann.org/en/aso/aso-mou-29oct04.htm > > and also the ICANN bylaws: http://www.icann.org/en/general/bylaws.htm#VIII I just read these documents, and I see that they create a relationship for the development of global policy. I don't see where they grant regulatory authority to any RIR - perhaps you can clarify with something more than your opinion? Cheers, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Feb 25 15:18:06 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 20:18:06 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <88083657-AB6B-45F7-B229-D638B9DAB9D2@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> <7AA53746-34C9-42D8-8EE7-57B4B8E307D4@delong.com> <88083657-AB6B-45F7-B229-D638B9DAB9D2@queuefull.net> Message-ID: <4F63078B-3112-4F96-9D02-1A8ECF9BF10D@corp.arin.net> I just read these documents, and I see that they create a relationship for the development of global policy. I don't see where they grant regulatory authority to any RIR - perhaps you can clarify with something more than your opinion? "The NRO shall fulfill the role, responsibilities and functions of the ASO as defined within the ICANN Bylaws." Per the ICANN Bylaws, this includes advising the Board "with respect to policy issues relating to the operation, assignment, and management of Internet addresses." The Board accepted ICP-2 < http://www.icann.org/en/icp/icp-2.htm> as a statement of policy, with the NRO fulfilling ICANN's duties of coordination of number resources and in particular the stable and secure operation of the Internet's number identifier systems. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From bensons at queuefull.net Fri Feb 25 14:57:09 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 13:57:09 -0600 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> Message-ID: <24EC5AAD-2309-4D40-9F79-051B2C29703F@queuefull.net> On Feb 25, 2011, at 12:12 PM, Owen DeLong wrote: >> >> And how would you go about enforcing that in the case where, because of ARIN policy, neither party bothers to notify ARIN? >> > Once ARIN becomes aware that the resources are no longer being utilized by the > resource holder of record, they can be considered abandoned and made available > for registration to an RSA-contracted recipient. Beyond that, there is no real need > for enforcement, per se. And that *is* enforcement of ARIN policy. In the example, number resources are being used in a manner agreed upon by both the original resource holder and the new resource holder. What you propose is to override their choice with ARIN's policy. This action would possibly incite users of ARIN's database to collude against a competitor. Good luck defending that behavior in a court of law. Cheers, -Benson From bensons at queuefull.net Fri Feb 25 15:26:47 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 14:26:47 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> Message-ID: Hi, John. Thanks for helping me explore this question. If a global policy is needed, then I'll consider proposing one. But please indulge me a bit further, as I don't yet understand the need. On Feb 25, 2011, at 3:37 AM, John Curran wrote: >> In the context of proposal 136, as well as 133 and 134, you have suggested the need for a global policy discussion. My question is a result of your suggestion. Why specifically, in the context of global policy, is this not a matter for ARIN to decide? As I outlined in my quoted text above, I don't think ICP-2 limits ARIN's ability to decide this issue. But this is an honest question - if I'm overlooking something I'd like to know. > > My apologies for being unclear - In the policy proposal, you reference > hypothetical "replacement directory services". If these entities are > allowed under ARIN's local policy framework, then ICP-2 states that > ARIN's policies would need to apply in a fair and equitable manner > these entities just as they apply to ISP's in the region. Does that > actually meet your requirements? I expected otherwise from the policy > background statement. and On Feb 25, 2011, at 4:00 AM, John Curran wrote: >> A review of the NRO history reveals only a non-binding letter of affirmation with the NRO, but let's just assume that is adequate. In the affirmation letter, ICANN delegates responsibility for allocating addresses and "facilitating" development of policies. I do not see the delegation of other powers such as "reclamation" authority etc. Maybe I'm missing something? > > Perhaps the first sentence? > > "The NRO shall fulfill the role, responsibilities and functions of the ASO as defined > within the ICANN Bylaws." > > Per the ICANN Bylaws, this includes advising the Board "with respect to policy issues > relating to the operation, assignment, and management of Internet addresses." > The Board accepted ICP-2 < http://www.icann.org/en/icp/icp-2.htm> as a statement > of policy, with the NRO fulfilling ICANN's duties of coordination of number resources > and in particular the stable and secure operation of the Internet's number identifier > systems. I see how the ICANN Bylaws and NRO MOU establish a role for the RIRs in policy development. And I see that there are guidelines for recognizing RIRs in the ICANN-adopted ICP-2 policy. What I don't see is anything limiting the formation of a registry/registrar system, post-allocation services, etc, especially if done within the scope of a single region. While prop 136 doesn't directly call for the formation of a registrar system or post-allocation services, I admit that it does imply the opportunity. However, there is no requirement that "replacement directory services" are provided by a third party - I imagine that the address holder can provide a directory service for themselves. Another thing I don't see is any requirement that a RIR enforce policy on post-allocation behaviors. As far as I can tell, this is the realm of RIR-specific "management" policy. In as much as the RIR is allowed to create policy regulating address resources in their region, it should likewise be able to deregulate those resources. Perhaps I'm overlooking or misunderstanding something, but I still fail to see the requirement for a global policy associated with prop 136. Thanks, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Feb 25 15:35:31 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 20:35:31 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> Message-ID: <05951496-672B-4A91-970B-85F15D450FE3@arin.net> On Feb 26, 2011, at 4:26 AM, Benson Schliesser wrote: What I don't see is anything limiting the formation of a registry/registrar system, post-allocation services, etc, especially if done within the scope of a single region. While prop 136 doesn't directly call for the formation of a registrar system or post-allocation services, I admit that it does imply the opportunity. However, there is no requirement that "replacement directory services" are provided by a third party - I imagine that the address holder can provide a directory service for themselves. Again: if such registries where allowed under ARIN's local policy framework, then ICP-2 states that ARIN's policies would need to apply in a fair and equitable manner these entities just as they apply to ISP's in the region. Does that actually meet your requirements for "opting out"? I expected otherwise from the policy background statement as the policies adopted in the ARIN region would apply fully to any such "replacement directory services." /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Fri Feb 25 15:47:56 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 12:47:56 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> <4D6808C3.7040808@ipinc.net> Message-ID: <4D68157C.6080004@ipinc.net> On 2/25/2011 12:09 PM, John Curran wrote: > On Feb 26, 2011, at 3:53 AM, Ted Mittelstaedt wrote: > >> Ah. Let me ask then - if a legacy POC is determined to be >> illegitimate and marked as such, then what is current ARIN >> practice - do you attempt to contact any squatter, or do >> you reclaim and reassign the resource, or do you simply do nothing? > > POC validation will get them marked as unresponsive, but we > are unlikely to determine them invalid unless it is the result > of a fraud report, and yes, we try to determine whether the > original resource holder is still out there somewhere. > >> But that assumes you can contact them, that the original entity >> exists. What if it does not? Or what if you contact them and >> they don't know who you are and what your talking about and >> can't answer your questions? > > That happens... Generally, we can find someone who knows > the relationship and then we work to document it. If it's a true > squatter, they usually disappear at our first contact. If we can > find the original resource holder, we change it to them, and if > not we reclaim the resource and put it in hold down for reuse. > OK then riddle me this: Let's say you look at the current month's list of unresponsive POCs and you notice that there's a "legacy" /17 in the list. It's significant enough to investigate so you do. (/17 is chosen as an arbitrary number I do not know what you currently consider large enough to pursue, although I know it's not a /24, at least not yet) You don't see it advertised in the DFZ. You send a letter to the original holder at the address and it gets "returned to sender no longer at this address, no forwarding address left" You then Google the original holder and discover they are still around in the original city. So you call them. After some digging you find out that it's a lawyer's office charged with bankruptcy disposal of the entity. You explain what your calling about and the lawyer (smelling some money here) suddenly gets all grabby and tells you that they "it's theirs and they aren't giving it up but you can buy it if you want" and threatens to sue you if you take it back. Or instead of a lawyer you finally get to the IT person and find out the entity is 1/10th the size it used to be, and they aren't using this block and never plan to - but once more, the person you talk to isn't willing to "give it up" What do you do then? ARIN staff by now has determined the following: 1) The block is not used even in an unconnected network 2) The original holder is either ignorant of it's use and/or unable to use it, or is a proxy for the original holder. 3) Your not going to get permission, written or verbal, from anyone to take it back, based on them thinking that it might be worth something someday 4) The original holder doesn't give a damn what you mark for it in whois but is clearly never going to exert the effort to login to ARIN and modify the whois record. The reason I am asking is that I am thinking that perhaps ARIN needs some more clarity on what constitutes an abandoned legacy resource. > FYI, > /John > > John Curran > President and CEO > ARIN > > (about to go offline for 20 hrs) > > From bensons at queuefull.net Fri Feb 25 15:49:08 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 14:49:08 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: Message-ID: <2F80AF77-788B-4E52-B274-0EA6445B9280@queuefull.net> Hi, Dan. On Feb 25, 2011, at 11:56 AM, Alexander, Daniel wrote: > [DA] I agree, I hear it is tough to keep a hold of a genie. While prop 136 > does not deal directly with address markets, how markets develop would be > a direct consequence of prop 136. If 136 were abandoned, transfers from > one to another can still occur under existing policies. What you are > proposing here is the difference between an unrestricted market that this > proposal could enable, and an attempt at evolving a structured market that > we hope could limit abuse under existing policies. I'm not na?ve enough to > think that existing policy couldn't be abused, but I cannot see how 136 > could provide an environment with fewer negative consequences. I don't necessarily disagree with you - in fact, I think you make valid points. But I'm coming from the perspective that transfers (bypassing ARIN policy) are already happening, and that ARIN would better serve the community by recognizing them. If we want to go the other path, and force all transfers to comply with ARIN policy, then we have a difficult legal position with regard to legacy holders. If all legacy holders were under LRSA then we'd be fine. Or if there was some unambiguous delegation of regulatory authority then we'd be fine. But ARIN is just a 501(c)6 business league with a loosely-defined ICANN relationship. I'm not sure that strong-arm tactics will work. Is there another alternative? > [DA] I should also revise an earlier point I made that brokers would be > the only beneficiaries. This change is not limited to brokers facilitating > the exchange of /24's or /16's between individuals or companies. This > proposal could open the door for governments or international > organizations to acquire /8's and circumvent the RIR's. I think the > potential of these implications far outweigh the desires that a legacy > resource holder may have to avoid ARIN policy. Another good point. Of course, (as we've recently seen) governments can control Internet connectivity regardless of whether they "own" the address blocks. >> If an organization were to opt-out, the goal would be for them to >> continue maintaining their own whois records and have ARIN point to them. >> Under those circumstances I think the model works. But I agree, if >> somebody fails to maintain their delegated whois records then we have an >> undesired outcome. As I mentioned above, I'm interested in feedback on >> how to solve this. Revoking the opt-out seems awkward, but I'm not sure >> what else is possible. > > [DA] I don't see a way around this problem. If a holder X has a non-(L)RSA > resource and opts out of ARIN provided services, you suggest ARIN would > provide a pointer to holder X. Now holder X transfers to holder Y. Holder > Y has no obligations whatsoever to provide WHOIS services or pointers. > While holder X may have a pointer, which they are not obligated to do, it > will likely be irrelevant since holder Y, or anyone further down the chain > has no obligation to do anything. This makes WHOIS services far worse then > they are today. Naturally, we can avoid this specific problem by not allowing opt-out. But that may result in inaccurate whois data, too - based on my comments above. Perhaps the right approach is to modify the proposal 136 text, so that it requires a legal agreement for ongoing accuracy in the whois. The agreement would have to be inherited or novated to each new holder or assignee. That seems to be similar to what happens today, for holders that opt-in. Does that seem good enough? Cheers, -Benson From jcurran at arin.net Fri Feb 25 16:02:56 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 21:02:56 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D68157C.6080004@ipinc.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> <4D6808C3.7040808@ipinc.net> <4D68157C.6080004@ipinc.net> Message-ID: On Feb 26, 2011, at 4:47 AM, Ted Mittelstaedt wrote: > What do you do then? ARIN staff by now has determined the following: > > 1) The block is not used even in an unconnected network > 2) The original holder is either ignorant of it's use and/or unable to > use it, or is a proxy for the original holder. > 3) Your not going to get permission, written or verbal, from anyone to take it back, based on them thinking that it might be worth something someday > 4) The original holder doesn't give a damn what you mark for it in whois but is clearly never going to exert the effort to login to ARIN and modify the whois record. Ted - you have multiple hypotheticals here, so it's hard to provide a single answer. If the resource holder still exists then they can prove it and then just keep using it and/or put the resource until LRSA and make use of the specified transfer policy to monetize it. If they aren't the resource holder, then the resource is likely coming back so we can find the valid holder or reclaim the resource. /John John Curran President and CEO ARIN From gbonser at seven.com Fri Feb 25 16:12:58 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Feb 2011 13:12:58 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D68157C.6080004@ipinc.net> References: <1110224132339.854B-400000@Ives.egh.com><6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net><6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net><59300825-6E20-4B2D-B701-B9D096787014@arin.net><4D67ECBA.4000100@matthew.at><5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net><4D67F1A6.30403@ipinc.net><4D6804FB.6030202@ipinc.net><4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net><4D6808C3.7040808@ipinc.net> <4D68157C.6080004@ipinc.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13DA5@RWC-EX1.corp.seven.com> > > What do you do then? ARIN staff by now has determined the following: > > 1) The block is not used even in an unconnected network > 2) The original holder is either ignorant of it's use and/or unable to > use it, or is a proxy for the original holder. > 3) Your not going to get permission, written or verbal, from anyone to > take it back, based on them thinking that it might be worth something > someday > 4) The original holder doesn't give a damn what you mark for it in > whois > but is clearly never going to exert the effort to login to ARIN and > modify the whois record. > > The reason I am asking is that I am thinking that perhaps ARIN needs > some more clarity on what constitutes an abandoned legacy resource. > ARIN policy, as far as I know, is about the requirements of issuing new IP addresses. If this entity went to ARIN to get new IP addresses, considering their current assignment and usage according to your scenario, they would be denied. As far as I know, ARIN policy isn't about constantly monitoring usage and yanking assignments when they are not currently in use. That would result in a constant back and forth of assignments/revocation/assignment/revocation as an entity changes. When they got the assignment, they qualified for the IP addresses. They might not qualify for that assignment *today* but they aren't making a request *today*. This isn't, to my knowledge, about making sure that everyone is always within the usage guidelines of assignment, it is about being within the usage guidelines when an assignment is made. This is the sort of mess that is going to quickly make IPv4 useless and probably ARIN-PPML useless if we continue to contort ourselves to chop v4 into smaller and smaller pieces. Forget v4. It is out to pasture. It is done. V4 is what it is. It will be around a while but I am projecting that within 12 to 18 months time, my traffic will be about 85% v6 and 15% v4. In 24 to 36 months v4 traffic will be down to 5% of my total bandwidth. It isn't worth spending a huge amount of time over. Here's an idea: Give all of IPv4 North America to Benson to manage. Let him handle it. The whole thing. Within 5 years it will still be around but in the overall scheme of things, irrelevant, and Benson will have managed to speed up the migration to v6 at least in the North American region. From jcurran at arin.net Fri Feb 25 16:15:00 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 21:15:00 +0000 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <24EC5AAD-2309-4D40-9F79-051B2C29703F@queuefull.net> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> <24EC5AAD-2309-4D40-9F79-051B2C29703F@queuefull.net> Message-ID: On Feb 26, 2011, at 3:57 AM, Benson Schliesser wrote: > On Feb 25, 2011, at 12:12 PM, Owen DeLong wrote: >> Once ARIN becomes aware that the resources are no longer being utilized by the >> resource holder of record, they can be considered abandoned and made available >> for registration to an RSA-contracted recipient. Beyond that, there is no real need >> for enforcement, per se. > > And that *is* enforcement of ARIN policy. In the example, number resources are being used in a manner agreed upon by both the original resource holder and the new resource holder. We have no problem changing the registration records in the ARIN Whois in accordance with the community-developed policy. To the extent a resource holder is using the resources (even if underutilized), it has been our practice not to make policy that would hinder their use of the resources. This is not the case when a party has stopped using the number resources, and then attempts to attempts to fraudulently transfer them. /John John Curran President and CEO ARIN From tedm at ipinc.net Fri Feb 25 16:19:53 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 13:19:53 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> <4D6808C3.7040808@ipinc.net> <4D68157C.6080004@ipinc.net> Message-ID: <4D681CF9.2010401@ipinc.net> On 2/25/2011 1:02 PM, John Curran wrote: > On Feb 26, 2011, at 4:47 AM, Ted Mittelstaedt wrote: > >> What do you do then? ARIN staff by now has determined the following: >> >> 1) The block is not used even in an unconnected network >> 2) The original holder is either ignorant of it's use and/or unable to >> use it, or is a proxy for the original holder. >> 3) Your not going to get permission, written or verbal, from anyone to take it back, based on them thinking that it might be worth something someday >> 4) The original holder doesn't give a damn what you mark for it in whois but is clearly never going to exert the effort to login to ARIN and modify the whois record. > > Ted - you have multiple hypotheticals here, so it's hard to provide > a single answer. If the resource holder still exists then they can > prove it and then just keep using it and/or put the resource until > LRSA and make use of the specified transfer policy to monetize it. Ah ha. That is what I was looking for. OK, then next question. Right now ARIN is still handing out IPv4. Thus there is no incentive for a would-be buyer wanting IPv4 to go to the lawyer for a bankrupt ISP that is sitting on that /17, because he can simply go to ARIN and ask for the numbers. In other words, because the transfer cannot take place unless the legacy resource is under LRSA, and once under the LSRA any transfer obligates the receiver to start paying fees, to paraphrase one of our great authors "..I don't see no p'ints about that IPv4 that's any better'n any other IPv4...." So, it is likely that the lawyer isn't going to bother putting the block under LRSA (unless you tell him to do that or lose it) right now - because it's not worth anything - right now. So I then have to ask you John, in ARIN's opinion, based on the work it's already had to do on invalid POC's, is there a rather large amount of legacy IPv4 that is sitting out there in limbo, waiting for ARIN to run out of addresses, so they can, as you put it, "...put the resource under LRSA and make use of the specified transfer policy to monetize it..." Are we going to see a big flushing of limbo legacy IPv4 transfers on to the "market" in the months after ARIN announces it's assigned it's last IPv4? Is that why you guys pushed through the transfer policy? Just trying to understand the behind-the-scenes, here. Ted > If they aren't the resource holder, then the resource is likely > coming back so we can find the valid holder or reclaim the resource. > > /John > > John Curran > President and CEO > ARIN > > > From bensons at queuefull.net Fri Feb 25 16:25:33 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 15:25:33 -0600 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> <24EC5AAD-2309-4D40-9F79-051B2C29703F@queuefull.net> Message-ID: On Feb 25, 2011, at 3:15 PM, John Curran wrote: > On Feb 26, 2011, at 3:57 AM, Benson Schliesser wrote: >> On Feb 25, 2011, at 12:12 PM, Owen DeLong wrote: >>> Once ARIN becomes aware that the resources are no longer being utilized by the >>> resource holder of record, they can be considered abandoned and made available >>> for registration to an RSA-contracted recipient. Beyond that, there is no real need >>> for enforcement, per se. >> >> And that *is* enforcement of ARIN policy. In the example, number resources are being used in a manner agreed upon by both the original resource holder and the new resource holder. > > We have no problem changing the registration records in the > ARIN Whois in accordance with the community-developed policy. > To the extent a resource holder is using the resources (even > if underutilized), it has been our practice not to make policy > that would hinder their use of the resources. This is not the > case when a party has stopped using the number resources, and > then attempts to attempts to fraudulently transfer them. The word "fraudulently" is contentious when applied in this situation, i.e. applied to transfers that are prohibited solely within the context of ARIN policy. It's not clear that ARIN has the authority to interfere with any behavior (including transfer) post-allocation of an address block, absent an agreement with the holder. Cheers, -Benson From bensons at queuefull.net Fri Feb 25 16:28:05 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 15:28:05 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <05951496-672B-4A91-970B-85F15D450FE3@arin.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> <05951496-672B-4A91-970B-85F15D450FE3@arin.net> Message-ID: <73DDC555-0DB4-475E-A54B-795A077A5D02@queuefull.net> On Feb 25, 2011, at 2:35 PM, John Curran wrote: > On Feb 26, 2011, at 4:26 AM, Benson Schliesser wrote: > >> What I don't see is anything limiting the formation of a registry/registrar system, post-allocation services, etc, especially if done within the scope of a single region. While prop 136 doesn't directly call for the formation of a registrar system or post-allocation services, I admit that it does imply the opportunity. However, there is no requirement that "replacement directory services" are provided by a third party - I imagine that the address holder can provide a directory service for themselves. > > Again: if such registries where allowed under ARIN's local policy > framework, then ICP-2 states that ARIN's policies would need to apply > in a fair and equitable manner these entities just as they apply to > ISP's in the region. Does that actually meet your requirements for > "opting out"? I expected otherwise from the policy background statement > as the policies adopted in the ARIN region would apply fully to any > such "replacement directory services." Thanks for your clarification, John. Perhaps I understand you correctly now. To rephrase what I hear you saying: As a result of RIR recognition by ICANN per ICP-2, ARIN has a responsibility to apply address management policy to all organizations within their region, and is not permitted to allow anybody to opt-out of that policy. Have I captured your meaning correctly? Thanks, -Benson -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Feb 25 16:31:40 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 21:31:40 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D681CF9.2010401@ipinc.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> <4D6808C3.7040808@ipinc.net> <4D68157C.6080004@ipinc.net> <4D681CF9.2010401@ipinc.net> Message-ID: <98C4D20C-6578-4C3F-8849-777F83C8859E@arin.net> On Feb 26, 2011, at 5:19 AM, Ted Mittelstaedt wrote: > OK, then next question. Right now ARIN is still handing out IPv4. Note: ARIN provides space to meet 3 months need, whereas the specified transfer policy allows a party to transfer space to meet 12 months of their documented need. > Thus there is no incentive for a would-be buyer wanting IPv4 to > go to the lawyer for a bankrupt ISP that is sitting on that /17, > because he can simply go to ARIN and ask for the numbers. There is presently some demand, by parties who are thinking that 12 months now (via transfer might be better 3 months, even "free") > In other words, because the transfer cannot take place unless the > legacy resource is under LRSA, and once under the LSRA any transfer > obligates the receiver to start paying fees, to paraphrase > one of our great authors "..I don't see no p'ints about that IPv4 that's any better'n any other IPv4...." The fees are $100/year, so it's minimal barrier. The LRSA itself (discussed here at length, let's not revisit now) appears to be a larger impediment. > So, it is likely that the lawyer isn't going to bother putting the > block under LRSA (unless you tell him to do that or lose it) right now - because it's not worth anything - right now. Hmm. Hard to tell, since putting under LRSA makes clear that the resource is valid and potentially available. > So I then have to ask you John, in ARIN's opinion, based on the work > it's already had to do on invalid POC's, is there a rather large amount of legacy IPv4 that is sitting out there in limbo, waiting for ARIN to > run out of addresses, so they can, as you put it, "...put the resource under LRSA and make use of the specified transfer policy to monetize it..." Independent of the invalid POC work, there is an a very large amount of potential address space that might come in for transfer. > Are we going to see a big flushing of limbo legacy IPv4 transfers > on to the "market" in the months after ARIN announces it's assigned > it's last IPv4? Quite possibly. We may also see holders under RSA deciding that they also want to free up resources for the specified transfer policy. /John From jcurran at arin.net Fri Feb 25 16:31:14 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 21:31:14 +0000 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> <24EC5AAD-2309-4D40-9F79-051B2C29703F@queuefull.net> Message-ID: <4C27EF8A-AF29-4A36-BC28-607371CEF981@arin.net> On Feb 26, 2011, at 5:25 AM, Benson Schliesser wrote: > > The word "fraudulently" is contentious when applied in this situation, i.e. applied to transfers that are prohibited solely within the context of ARIN policy. It's not clear that ARIN has the authority to interfere with any behavior (including transfer) post-allocation of an address block, absent an agreement with the holder. The word "interfere" is contentious when applied in this situation, in that ARIN is managing the ARIN Whois database based on the policies developed by the community. At this point, can we agree to disagree on this point and move on to discussing policy proposals. ARIN will manage the Whois database in accordance with the community developed policies, please take that as given when preparing policy proposals. Thanks, /John From jcurran at arin.net Fri Feb 25 16:39:15 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 21:39:15 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <73DDC555-0DB4-475E-A54B-795A077A5D02@queuefull.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> <05951496-672B-4A91-970B-85F15D450FE3@arin.net> <73DDC555-0DB4-475E-A54B-795A077A5D02@queuefull.net> Message-ID: On Feb 26, 2011, at 5:28 AM, Benson Schliesser wrote: Again: if such registries where allowed under ARIN's local policy framework, then ICP-2 states that ARIN's policies would need to apply in a fair and equitable manner these entities just as they apply to ISP's in the region. Does that actually meet your requirements for "opting out"? I expected otherwise from the policy background statement as the policies adopted in the ARIN region would apply fully to any such "replacement directory services." Please address the question, so that we can prepare an adequate policy review materials on the policy proposal: Do you intend that the "replacement directory services" would fully conform with ARIN's number resource policies, or not? This may have to be clarified in the policy proposal before it can be further considered. Thanks for your clarification, John. Perhaps I understand you correctly now. To rephrase what I hear you saying: As a result of RIR recognition by ICANN per ICP-2, ARIN has a responsibility to apply address management policy to all organizations within their region, and is not permitted to allow anybody to opt-out of that policy. Have I captured your meaning correctly? No, I indicated that ARIN would need to apply policies in a fair and equitable manner to "replacement directory services" just they apply to ISPs in the region. FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Fri Feb 25 16:48:08 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 13:48:08 -0800 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <98C4D20C-6578-4C3F-8849-777F83C8859E@arin.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> <4D6808C3.7040808@ipinc.net> <4D68157C.6080004@ipinc.net> <4D681CF9.2010401@ipinc.net> <98C4D20C-6578-4C3F-8849-777F83C8859E@arin.net> Message-ID: <4D682398.7020801@ipinc.net> On 2/25/2011 1:31 PM, John Curran wrote: >> So I then have to ask you John, in ARIN's opinion, based on the work >> it's already had to do on invalid POC's, is there a rather large amount of legacy IPv4 that is sitting out there in limbo, waiting for ARIN to >> run out of addresses, so they can, as you put it, "...put the resource under LRSA and make use of the specified transfer policy to monetize it..." > > Independent of the invalid POC work, there is an a very large amount > of potential address space that might come in for transfer. > Heh heh heh heh heh. No wonder you guys wanted that transfer policy so bad. You don't play poker without heat, now do you? Ted From narten at us.ibm.com Fri Feb 25 16:48:49 2011 From: narten at us.ibm.com (Thomas Narten) Date: Fri, 25 Feb 2011 16:48:49 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201102252148.p1PLmnG6031436@cichlid.raleigh.ibm.com> I've been running a "weekly posting summary" on several mailing lists for sometime, and was recently asked if I could do the same for ppml. After a short discussion with a couple of folk, I've decided to do so. All this shows is who was posting/contributing the most in the last week. I'll leave it to the reader to interpret significance of any individual's overall or relative ranking in a given week, or the overall volume of postings in a given week. Note that the ordering is not a straight ranking by number of posts, but weighted somewhat by size of posting (that's what the original script does, and I haven't felt much of an urge to tweak it). So sometimes someone with fewer posts may rank slightly higher, either because they had a lot to say, they quote a lot of text, etc. Thomas Total of 194 messages in the last 7 days. script run at: Fri Feb 25 00:53:02 EST 2011 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.95% | 29 | 15.11% | 226537 | owen at delong.com 9.28% | 18 | 8.11% | 121608 | bill at herrin.us 4.64% | 9 | 10.97% | 164374 | wesley.e.george at sprint.com 8.25% | 16 | 6.69% | 100312 | jcurran at arin.net 6.19% | 12 | 5.75% | 86165 | bensons at queuefull.net 4.12% | 8 | 4.36% | 65345 | jeffrey.lyon at blacklotus.net 4.64% | 9 | 3.40% | 50971 | gbonser at seven.com 4.12% | 8 | 3.86% | 57909 | frnkblk at iname.com 3.61% | 7 | 4.04% | 60528 | tedm at ipinc.net 3.61% | 7 | 3.92% | 58726 | mueller at syr.edu 3.61% | 7 | 3.58% | 53668 | hannigan at gmail.com 3.61% | 7 | 2.50% | 37418 | matthew at matthew.at 3.09% | 6 | 2.98% | 44688 | alh-ietf at tndh.net 2.58% | 5 | 2.27% | 33969 | mpetach at netflight.com 2.58% | 5 | 2.20% | 32925 | cgrundemann at gmail.com 2.06% | 4 | 1.95% | 29203 | info at arin.net 1.55% | 3 | 2.43% | 36439 | scottleibrand at gmail.com 2.06% | 4 | 1.87% | 28089 | dwing at cisco.com 2.06% | 4 | 1.63% | 24432 | jmaimon at chl.com 2.06% | 4 | 1.63% | 24410 | joelja at bogus.com 1.55% | 3 | 1.56% | 23455 | kkargel at polartel.com 1.03% | 2 | 0.91% | 13619 | mysidia at gmail.com 1.03% | 2 | 0.73% | 10899 | keith at jcc.com 0.52% | 1 | 0.80% | 12050 | packetgrrl at gmail.com 0.52% | 1 | 0.72% | 10794 | john.sweeting at twcable.com 0.52% | 1 | 0.70% | 10445 | markk at arin.net 0.52% | 1 | 0.68% | 10259 | john.sweeting at gmail.com 0.52% | 1 | 0.57% | 8593 | john at egh.com 0.52% | 1 | 0.55% | 8219 | billd at cait.wustl.edu 0.52% | 1 | 0.51% | 7698 | arin-ppml at westbrook.com 0.52% | 1 | 0.47% | 7112 | marka at isc.org 0.52% | 1 | 0.45% | 6722 | jhg at omsys.com 0.52% | 1 | 0.42% | 6267 | pwilson at apnic.net 0.52% | 1 | 0.38% | 5737 | gary.buhrmaster at gmail.com 0.52% | 1 | 0.36% | 5403 | springer at inlandnet.com 0.52% | 1 | 0.33% | 4919 | jcurran at istaff.org 0.52% | 1 | 0.32% | 4866 | woody at pch.net 0.52% | 1 | 0.29% | 4305 | vixie at vix.com --------+------+--------+----------+------------------------ 100.00% | 194 |100.00% | 1499078 | Total From jcurran at arin.net Fri Feb 25 16:56:19 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 21:56:19 +0000 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D682398.7020801@ipinc.net> References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <4D67ECBA.4000100@matthew.at> <5DA442A1-0012-4A72-9BE2-0621C54CA3B0@arin.net> <4D67F1A6.30403@ipinc.net> <4D6804FB.6030202@ipinc.net> <4C3E2C91-5EB6-40A9-9A8F-D594653FE4E3@arin.net> <4D6808C3.7040808@ipinc.net> <4D68157C.6080004@ipinc.net> <4D681CF9.2010401@ipinc.net> <98C4D20C-6578-4C3F-8849-777F83C8859E@arin.net> <4D682398.7020801@ipinc.net> Message-ID: On Feb 26, 2011, at 5:48 AM, Ted Mittelstaedt wrote: > Heh heh heh heh heh. No wonder you guys wanted that transfer policy > so bad. You don't play poker without heat, now do you? Actually, I'll admit I'm not a poker player, so the reference may be lost on me. I don't "want" or "make" policy, although I do get the honor of being accountable for its implementation. Without any form of transfer policy, there is little doubt that we would have underutilized resources that were likely to never be returned for reuse. As many have already noted, a "market" is one method of providing the right incentives for redistribution, and a market which also respects the allocation policy and its goals seems to provide a mechanism for redistribution without losing the benefits of the current policy framework. This is how I explain what was done by the community when asked by those outside of ARIN, so I hope the explanation helps. /John John Curran President and CEO ARIN From tedm at ipinc.net Fri Feb 25 16:56:38 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 13:56:38 -0800 Subject: [arin-ppml] Please try the strong arm tactics first - was Re: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <2F80AF77-788B-4E52-B274-0EA6445B9280@queuefull.net> References: <2F80AF77-788B-4E52-B274-0EA6445B9280@queuefull.net> Message-ID: <4D682596.3020104@ipinc.net> On 2/25/2011 12:49 PM, Benson Schliesser wrote: > But I'm coming from the perspective that transfers > (bypassing ARIN policy) are already happening, and that ARIN would > better serve the community by recognizing them. > Why? If they are happening outside of the ARIN transfer policy then they are fraudulent. There is no incentive for non-fraudulent transfers to happen and the participating bodies to NOT register them with ARIN. None at all. Even if they are purely ignorant, the moment ARIN contacts them they register and that is that. Thus if they are not registering, they are doing so in order to conceal, because they are doing something against the rules. > If we want to go the other path, and force all transfers to comply > with ARIN policy, then we have a difficult legal position with regard > to legacy holders. If all legacy holders were under LRSA then we'd > be fine. Or if there was some unambiguous delegation of regulatory > authority then we'd be fine. But ARIN is just a 501(c)6 business > league with a loosely-defined ICANN relationship. I'm not sure that > strong-arm tactics will work. I would prefer that we try the strong arm tactics first. If they don't work then we can then entertain "another alternative" But just lying down and giving up, without even trying, is utter B.S. There are thousands of legal, honest, orgs who are paying the yearly transfer fees, signed the RSA, and did what was needed to meet the requirements. They deserve something better than an RIR that is a limp, wimp, for their money. The RIR may not win in the end but I would gladly see most of my org's fee go to making the miscreant pay dearly in legal fees to get away with a fraudulent transfer. Ultimately there's more of us than of the miscreants. We also have an almost inexhaustible supply of money in yearly fees to keep funding the fight from now until IPv4 becomes unused on the Internet. For an org to deliberately set out to fraudulently obtain legacy resources and not follow the rules, is in my opinion, very stupid. The only thing stupider would be for us as a community to seriously entertain the idea that orgs that are intent on obtaining addresses outside of the rules should be allowed to have any kind of alternative. That is just going to encourage misbehavior and you might as well not have an RIR system then, and let everyone pull any old IPv4 and IPv6 addresses out of their asses. For an example of why you cannot adopt a "hang-em-high" attitude I would suggest you examine the CAN-SPAM act in the United States and how well that has worked. Ted From jcurran at arin.net Fri Feb 25 16:57:43 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Feb 2011 21:57:43 +0000 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net In-Reply-To: <201102252148.p1PLmnG6031436@cichlid.raleigh.ibm.com> References: <201102252148.p1PLmnG6031436@cichlid.raleigh.ibm.com> Message-ID: Thomas - Thanks! /John On Feb 26, 2011, at 5:48 AM, Thomas Narten wrote: > I've been running a "weekly posting summary" on several mailing lists > for sometime, and was recently asked if I could do the same for > ppml. After a short discussion with a couple of folk, I've decided to > do so. > > All this shows is who was posting/contributing the most in the last > week. I'll leave it to the reader to interpret significance of any > individual's overall or relative ranking in a given week, or the > overall volume of postings in a given week. > > Note that the ordering is not a straight ranking by number of posts, > but weighted somewhat by size of posting (that's what the original > script does, and I haven't felt much of an urge to tweak it). So > sometimes someone with fewer posts may rank slightly higher, either > because they had a lot to say, they quote a lot of text, etc. > > Thomas > > Total of 194 messages in the last 7 days. > > script run at: Fri Feb 25 00:53:02 EST 2011 > > Messages | Bytes | Who > --------+------+--------+----------+------------------------ > 14.95% | 29 | 15.11% | 226537 | owen at delong.com > 9.28% | 18 | 8.11% | 121608 | bill at herrin.us > 4.64% | 9 | 10.97% | 164374 | wesley.e.george at sprint.com > 8.25% | 16 | 6.69% | 100312 | jcurran at arin.net > 6.19% | 12 | 5.75% | 86165 | bensons at queuefull.net > 4.12% | 8 | 4.36% | 65345 | jeffrey.lyon at blacklotus.net > 4.64% | 9 | 3.40% | 50971 | gbonser at seven.com > 4.12% | 8 | 3.86% | 57909 | frnkblk at iname.com > 3.61% | 7 | 4.04% | 60528 | tedm at ipinc.net > 3.61% | 7 | 3.92% | 58726 | mueller at syr.edu > 3.61% | 7 | 3.58% | 53668 | hannigan at gmail.com > 3.61% | 7 | 2.50% | 37418 | matthew at matthew.at > 3.09% | 6 | 2.98% | 44688 | alh-ietf at tndh.net > 2.58% | 5 | 2.27% | 33969 | mpetach at netflight.com > 2.58% | 5 | 2.20% | 32925 | cgrundemann at gmail.com > 2.06% | 4 | 1.95% | 29203 | info at arin.net > 1.55% | 3 | 2.43% | 36439 | scottleibrand at gmail.com > 2.06% | 4 | 1.87% | 28089 | dwing at cisco.com > 2.06% | 4 | 1.63% | 24432 | jmaimon at chl.com > 2.06% | 4 | 1.63% | 24410 | joelja at bogus.com > 1.55% | 3 | 1.56% | 23455 | kkargel at polartel.com > 1.03% | 2 | 0.91% | 13619 | mysidia at gmail.com > 1.03% | 2 | 0.73% | 10899 | keith at jcc.com > 0.52% | 1 | 0.80% | 12050 | packetgrrl at gmail.com > 0.52% | 1 | 0.72% | 10794 | john.sweeting at twcable.com > 0.52% | 1 | 0.70% | 10445 | markk at arin.net > 0.52% | 1 | 0.68% | 10259 | john.sweeting at gmail.com > 0.52% | 1 | 0.57% | 8593 | john at egh.com > 0.52% | 1 | 0.55% | 8219 | billd at cait.wustl.edu > 0.52% | 1 | 0.51% | 7698 | arin-ppml at westbrook.com > 0.52% | 1 | 0.47% | 7112 | marka at isc.org > 0.52% | 1 | 0.45% | 6722 | jhg at omsys.com > 0.52% | 1 | 0.42% | 6267 | pwilson at apnic.net > 0.52% | 1 | 0.38% | 5737 | gary.buhrmaster at gmail.com > 0.52% | 1 | 0.36% | 5403 | springer at inlandnet.com > 0.52% | 1 | 0.33% | 4919 | jcurran at istaff.org > 0.52% | 1 | 0.32% | 4866 | woody at pch.net > 0.52% | 1 | 0.29% | 4305 | vixie at vix.com > --------+------+--------+----------+------------------------ > 100.00% | 194 |100.00% | 1499078 | Total > _______________________________________________ > 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 bensons at queuefull.net Fri Feb 25 19:23:51 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Fri, 25 Feb 2011 18:23:51 -0600 Subject: [arin-ppml] ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <1110224132339.854B-400000@Ives.egh.com> <6526FDAE-46FB-4BD6-BD3A-0B5B2184865D@queuefull.net> <6235D98C-7259-4B98-BB47-DD03F34C4160@queuefull.net> <59300825-6E20-4B2D-B701-B9D096787014@arin.net> <76157739-84F5-4F06-B395-252F672DC816@pch.net> <1257E855-B9F0-4066-9426-AB06EE5E80D6@queuefull.net> <05951496-672B-4A91-970B-85F15D450FE3@arin.net> <73DDC555-0DB4-475E-A54B-795A077A5D02@queuefull.net> Message-ID: <124BC7E6-BB9E-48C3-9747-E343FF4F6A72@queuefull.net> On Feb 25, 2011, at 3:39 PM, John Curran wrote: > Please address the question, so that we can prepare an adequate policy review > materials on the policy proposal: Do you intend that the "replacement directory > services" would fully conform with ARIN's number resource policies, or not? This > may have to be clarified in the policy proposal before it can be further considered. No. The intent of an opt-out is to remove oneself from the imposition of ARIN policy. After an opt-out, whether the holder conforms (fully or in-part) would be up to them. My assumption has been that, by removing the enforcement mechanism (e.g. whois), prop 136 already implies this. If I need to clarify the language, I can do so. >> >> Thanks for your clarification, John. Perhaps I understand you correctly now. To rephrase what I hear you saying: As a result of RIR recognition by ICANN per ICP-2, ARIN has a responsibility to apply address management policy to all organizations within their region, and is not permitted to allow anybody to opt-out of that policy. Have I captured your meaning correctly? > > No, I indicated that ARIN would need to apply policies in a fair and equitable > manner to "replacement directory services" just they apply to ISPs in the region. How are these statements different? I said, in effect: ARIN cannot permit anybody to opt-out of policy. You said, in effect: ARIN needs to apply policy to everybody. Did I misunderstand? Cheers, -Benson From mysidia at gmail.com Fri Feb 25 20:01:17 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Fri, 25 Feb 2011 19:01:17 -0600 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> <24EC5AAD-2309-4D40-9F79-051B2C29703F@queuefull.net> Message-ID: On Fri, Feb 25, 2011 at 3:25 PM, Benson Schliesser wrote: > The word "fraudulently" is contentious when applied in this >situation, i.e. applied to transfers that are prohibited solely within >the context of ARIN policy. ?It's not clear that ARIN has the authority >to interfere with any behavior (including transfer) post-allocation of >an address block, absent an agreement with the holder. ARIN doesn't need to "interfere", because there was no right to transfer in the first place stated to be granted when the legacy networks were originally assigned; it was merely "Ok, use these numbers for your network". It was never "Use these numbers for your network, but if some day you don't need them anymore, they are all yours, feel free to give these to someone else" Pre-ARIN the IANA assigned IP addresses to organizations; nothing in the RFCs showing that transfer of these assignments is or would be allowed. "Fraudulent" transfer perhaps isn't the word to use -- a transfer that wasn't effected in the registry is in effect a non-transfer. I would consider "Fraudulent transfer" to mean intentionally, knowingly using false information to get a transfer recognized by an RIR that is supposed to be invalid under that RIR's policies, and that RIR relying on that info / being tricked into cooperating. > Cheers, > -Benson -- -JH From tedm at ipinc.net Fri Feb 25 20:18:45 2011 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Fri, 25 Feb 2011 17:18:45 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> <24EC5AAD-2309-4D40-9F79-051B2C29703F@queuefull.net> Message-ID: <4D6854F5.1040606@ipinc.net> On 2/25/2011 5:01 PM, Jimmy Hess wrote: > On Fri, Feb 25, 2011 at 3:25 PM, Benson Schliesser > wrote: >> The word "fraudulently" is contentious when applied in this >> situation, i.e. applied to transfers that are prohibited solely within >> the context of ARIN policy. It's not clear that ARIN has the authority >> to interfere with any behavior (including transfer) post-allocation of >> an address block, absent an agreement with the holder. > > ARIN doesn't need to "interfere", because there was no right to > transfer in the first place stated to be granted when the legacy > networks were originally assigned; it was merely "Ok, use these > numbers for your network". > > It was never "Use these numbers for your network, but if some day you > don't need them anymore, they are all yours, feel free to give these > to someone else" > > Pre-ARIN the IANA assigned IP addresses to organizations; nothing > in the RFCs showing that transfer of these assignments is or would be allowed. > > "Fraudulent" transfer perhaps isn't the word to use -- a transfer that > wasn't effected in the registry is in effect a non-transfer. > > I would consider "Fraudulent transfer" to mean intentionally, > knowingly using false information to get a transfer recognized > by an RIR that is supposed to be invalid under that RIR's > policies, and that RIR relying on that info / being tricked > into cooperating. > What did ARIN promise the legacy holders, that is the $64K question, when ARIN was formed and took over the assignment function from IANA? It is my understanding they promised them nothing other than maintaining the existing whois database. It is also my understanding that none of the "promises" were anything other than verbal ones, thus legally meaningless. They certainly did not take the form of any legally enforceable contract. This kind of thing happens all the time, people say "I'll wash your car for $5 next Wednesday" and then Wednesday comes and they are too busy. Without a written contract between each legacy holder and ARIN the legacy holders have nothing and all of the creative manipulations of the adverse possession law that I have read here isn't going to change that. The Legacy holders have more when they sign the LRSA than they ever had. Ted > >> Cheers, >> -Benson > -- > -JH > _______________________________________________ > 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 warren at wholesaleinternet.com Fri Feb 25 22:56:56 2011 From: warren at wholesaleinternet.com (Warren Johnson) Date: Fri, 25 Feb 2011 21:56:56 -0600 Subject: [arin-ppml] Please try the strong arm tactics first - was Re: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D682596.3020104@ipinc.net> References: <2F80AF77-788B-4E52-B274-0EA6445B9280@queuefull.net> <4D682596.3020104@ipinc.net> Message-ID: <395d01cbd569$37539ce0$a5fad6a0$@com> Comments below -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ted Mittelstaedt Sent: Friday, February 25, 2011 3:57 PM To: arin-ppml at arin.net Subject: [arin-ppml] Please try the strong arm tactics first - was Re: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks On 2/25/2011 1 > If we want to go the other path, and force all transfers to comply > with ARIN policy, then we have a difficult legal position with regard > to legacy holders. If all legacy holders were under LRSA then we'd > be fine. Or if there was some unambiguous delegation of regulatory > authority then we'd be fine. But ARIN is just a 501(c)6 business > league with a loosely-defined ICANN relationship. I'm not sure that > strong-arm tactics will work. I would prefer that we try the strong arm tactics first. If they don't work then we can then entertain "another alternative" But just lying down and giving up, without even trying, is utter B.S. =============================== Strong arm won't work. The Internet runs because everyone plays nicely with each other. As soon as you start strong arming, you're changing the entire nature of the situation. If it becomes a truly market-based economy, the entire game changes. =============================== There are thousands of legal, honest, orgs who are paying the yearly transfer fees, signed the RSA, and did what was needed to meet the requirements. They deserve something better than an RIR that is a limp, wimp, for their money. The RIR may not win in the end but I would gladly see most of my org's fee go to making the miscreant pay dearly in legal fees to get away with a fraudulent transfer. ================================ You and the community would quickly tire of spending millions a year on legal fees. Trust me; that sh*t gets old fast. ================================ Ultimately there's more of us than of the miscreants. We also have an almost inexhaustible supply of money in yearly fees to keep funding the fight from now until IPv4 becomes unused on the Internet. ================================ Inexhaustible huh? Let us not forget that the annual dues actually go to operating the organization. It doesn't take long to burn through a lot of legal fees. I have seen simple shareholder buyout negotiations cost each side $25k->$50k. Now I want you to imagine that some organization with millions at its disposal is fighting for its life. Now multiply that by fighting a dozen "miscreants". I promise you, you don't have the stomach for that fight. ================================ For an org to deliberately set out to fraudulently obtain legacy resources and not follow the rules, is in my opinion, very stupid. ================================ Define stupid? Because you never know what people will do if they're desperate or greedy or both; especially if they have a large legal defense fund. ================================ The only thing stupider would be for us as a community to seriously entertain the idea that orgs that are intent on obtaining addresses outside of the rules should be allowed to have any kind of alternative. That is just going to encourage misbehavior and you might as well not have an RIR system then, and let everyone pull any old IPv4 and IPv6 addresses out of their asses. ================================ Ipv4 depletion has the potential to reshape the entire Internet; and I don't mean by changing to ipv6. If IPv4 becomes valuable property and people can't get what they want, they're going to do very naughty things. Remember, the corporation exists to make money for its shareholders so all they're going to do is consider the potential legal costs associated with litigating the RIR if they're caught and factor that into the cost of what they're doing. I do not envy the registries. They're in a very tough spot. Somewhere is a compromise. But first you have to open your eyes and see the brick coming at you. ================================ -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4398 bytes Desc: not available URL: From tvest at eyeconomics.com Fri Feb 25 22:23:39 2011 From: tvest at eyeconomics.com ( ) Date: Sat, 26 Feb 2011 11:23:39 +0800 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: John Curran wrote: >Thomas - > >Thanks! > >/John > >On Feb 26, 2011, at 5:48 AM, Thomas Narten wrote: > >> I've been running a "weekly posting summary" on several mailing lists >> for sometime, and was recently asked if I could do the same for >> ppml. After a short discussion with a couple of folk, I've decided to >> do so. >> >> All this shows is who was posting/contributing the most in the last >> week. I'll leave it to the reader to interpret significance of any >> individual's overall or relative ranking in a given week, or the >> overall volume of postings in a given week. >> >> Note that the ordering is not a straight ranking by number of posts, >> but weighted somewhat by size of posting (that's what the original >> script does, and I haven't felt much of an urge to tweak it). So >> sometimes someone with fewer posts may rank slightly higher, either >> because they had a lot to say, they quote a lot of text, etc. >> >> Thomas >> >> Total of 194 messages in the last 7 days. >> >> script run at: Fri Feb 25 00:53:02 EST 2011 >> >> Messages | Bytes | Who >> --------+------+--------+----------+------------------------ >> 14.95% | 29 | 15.11% | 226537 | owen at delong.com >> 9.28% | 18 | 8.11% | 121608 | bill at herrin.us >> 4.64% | 9 | 10.97% | 164374 | wesley.e.george at sprint.com >> 8.25% | 16 | 6.69% | 100312 | jcurran at arin.net >> 6.19% | 12 | 5.75% | 86165 | bensons at queuefull.net >> 4.12% | 8 | 4.36% | 65345 | jeffrey.lyon at blacklotus.net >> 4.64% | 9 | 3.40% | 50971 | gbonser at seven.com >> 4.12% | 8 | 3.86% | 57909 | frnkblk at iname.com >> 3.61% | 7 | 4.04% | 60528 | tedm at ipinc.net >> 3.61% | 7 | 3.92% | 58726 | mueller at syr.edu >> 3.61% | 7 | 3.58% | 53668 | hannigan at gmail.com >> 3.61% | 7 | 2.50% | 37418 | matthew at matthew.at >> 3.09% | 6 | 2.98% | 44688 | alh-ietf at tndh.net >> 2.58% | 5 | 2.27% | 33969 | mpetach at netflight.com >> 2.58% | 5 | 2.20% | 32925 | cgrundemann at gmail.com >> 2.06% | 4 | 1.95% | 29203 | info at arin.net >> 1.55% | 3 | 2.43% | 36439 | scottleibrand at gmail.com >> 2.06% | 4 | 1.87% | 28089 | dwing at cisco.com >> 2.06% | 4 | 1.63% | 24432 | jmaimon at chl.com >> 2.06% | 4 | 1.63% | 24410 | joelja at bogus.com >> 1.55% | 3 | 1.56% | 23455 | kkargel at polartel.com >> 1.03% | 2 | 0.91% | 13619 | mysidia at gmail.com >> 1.03% | 2 | 0.73% | 10899 | keith at jcc.com >> 0.52% | 1 | 0.80% | 12050 | packetgrrl at gmail.com >> 0.52% | 1 | 0.72% | 10794 | john.sweeting at twcable.com >> 0.52% | 1 | 0.70% | 10445 | markk at arin.net >> 0.52% | 1 | 0.68% | 10259 | john.sweeting at gmail.com >> 0.52% | 1 | 0.57% | 8593 | john at egh.com >> 0.52% | 1 | 0.55% | 8219 | billd at cait.wustl.edu >> 0.52% | 1 | 0.51% | 7698 | arin-ppml at westbrook.com >> 0.52% | 1 | 0.47% | 7112 | marka at isc.org >> 0.52% | 1 | 0.45% | 6722 | jhg at omsys.com >> 0.52% | 1 | 0.42% | 6267 | pwilson at apnic.net >> 0.52% | 1 | 0.38% | 5737 | gary.buhrmaster at gmail.com >> 0.52% | 1 | 0.36% | 5403 | springer at inlandnet.com >> 0.52% | 1 | 0.33% | 4919 | jcurran at istaff.org >> 0.52% | 1 | 0.32% | 4866 | woody at pch.net >> 0.52% | 1 | 0.29% | 4305 | vixie at vix.com >> --------+------+--------+----------+------------------------ >> 100.00% | 194 |100.00% | 1499078 | Total >> _______________________________________________ >> 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 frnkblk at iname.com Sat Feb 26 00:39:50 2011 From: frnkblk at iname.com (Frank Bulk) Date: Fri, 25 Feb 2011 23:39:50 -0600 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> Message-ID: <000a01cbd577$9638f210$c2aad630$@iname.com> George: When you say "people", do you include non-service providers? Do you think that even if we mark the space for "service providers" only, that that note will be ignored? Frank -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of George Bonser Sent: Friday, February 25, 2011 1:28 PM To: Benson Schliesser; arin-ppml at arin.net Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] > > The only argument against that I see remaining sounds a lot like > > "well, I might be the guy who gets part of that /10 for myself..." > > > > If there are other arguments that I have missed, or if I am > > miscalculating the cost of this proposal, I would love to be > > enlightened. > > > > Cheers, > > ~Chris I am neutral on this one. The argument I see is that once that /10 is set aside for that purpose, you have no control that it is actually used for that purpose. It will become de facto 1918 space and people will use it in all sorts of places and you run into exactly the problem this /10 was meant to solve (resolving collisions between customer 1918 domains) when you start running into customer nets numbered in this /10 or nets in regions outside ARIN numbered in this range. _______________________________________________ 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 gbonser at seven.com Sat Feb 26 00:42:16 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Feb 2011 21:42:16 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: <000a01cbd577$9638f210$c2aad630$@iname.com> References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> <000a01cbd577$9638f210$c2aad630$@iname.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13DC1@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Friday, February 25, 2011 9:40 PM > To: George Bonser; arin-ppml at arin.net > Subject: RE: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition > Spacefor IPv4 Address Extension] > > George: > > When you say "people", do you include non-service providers? Do you > think > that even if we mark the space for "service providers" only, that that > note > will be ignored? > > Frank Yes, I believe it will be ignored. Particularly outside of the ARIN region, it will be views as additional "free" space but inside as well. From bill at herrin.us Sat Feb 26 01:02:26 2011 From: bill at herrin.us (William Herrin) Date: Sat, 26 Feb 2011 01:02:26 -0500 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> Message-ID: On Fri, Feb 25, 2011 at 2:27 PM, George Bonser wrote: > I am neutral on this one. ?The argument I see is that once that /10 is > set aside for that purpose, you have no control that it is actually used > for that purpose. ?It will become de facto 1918 space and people will > use it in all sorts of places and you run into exactly the problem this > /10 was meant to solve (resolving collisions between customer 1918 > domains) when you start running into customer nets numbered in this /10 > or nets in regions outside ARIN numbered in this range. Hi George, Such an argument would be red herring (logical fallacy). I can claim 128.0.0.0/8 for my own as well. When I have trouble connecting to Internet hosts which overlap this range, it's nobody's fault but my own. RFC1918 space is valid within an administrative domain. Using RFC1918 space for carrier NAT requires the ISP to stretch his use of RFC1918 beyond his borders into the customer's administrative domain. The customer has a well founded expectation that will not happen -- that the customer may use any RFC1918 space he wants without conflict with his ISP. Such is not the case if the customer claims a range of addresses which have not been designated for his use. This has ever been the case and it has been resolved by renumbering and various hacks when it (rarely) crops up. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gbonser at seven.com Sat Feb 26 01:14:48 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Feb 2011 22:14:48 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13DC2@RWC-EX1.corp.seven.com> > Hi George, > > Such an argument would be red herring (logical fallacy). I can claim > 128.0.0.0/8 for my own as well. When I have trouble connecting to > Internet hosts which overlap this range, it's nobody's fault but my > own. Well, to some extent you are correct. I mean, it certainly would be one's own fault but this net would be quite unlike 128/8 in that one would be pretty much guaranteed not to overlap with any host on the Internet. And to the extent to which it is the problem only of the end network depends upon whether or not they are the only one a service provider runs into using that space. After about the 20th one or so, I would guess it would become a giant pain in the service provider's hips, too. But if I am right, it will become obvious in a year or two. I am not opposed to this, but I will have to suppress an "I told you so" moment when this becomes a pain in the hips being reported in NANOG every week. Where a provider will run into this is provisioning a new customer whose previous provider didn't use this space and is moving to a provider who does use the space for their WAN addressing. It will take a couple of years to raise its ugly head and the way most networks operate in reality "it isn't a problem until it is a problem". It won't be a problem for a couple of years down the road. I'll keep an eye out for the stories, though, when they start to appear. I two years time people will be using every scrap of v4 they can find and this /10 will end up being pressed into service in the most unexpected ways. I hope I am wrong. George From owen at delong.com Sat Feb 26 01:14:30 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 22:14:30 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13DC1@RWC-EX1.corp.seven.com> References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> <000a01cbd577$9638f210$c2aad630$@iname.com> <5A6D953473350C4B9995546AFE9939EE0BC13DC1@RWC-EX1.corp.seven.com> Message-ID: <82DB39F1-2A33-411C-9E3E-576F1C70AA45@delong.com> On Feb 25, 2011, at 9:42 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Frank Bulk [mailto:frnkblk at iname.com] >> Sent: Friday, February 25, 2011 9:40 PM >> To: George Bonser; arin-ppml at arin.net >> Subject: RE: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition >> Spacefor IPv4 Address Extension] >> >> George: >> >> When you say "people", do you include non-service providers? Do you >> think >> that even if we mark the space for "service providers" only, that that >> note >> will be ignored? >> >> Frank > > Yes, I believe it will be ignored. Particularly outside of the ARIN > region, it will be views as additional "free" space but inside as well. > I see where that becomes potentially inconvenient for service providers and their customers in those regions, but, otherwise, I don't see harm in this fact. Owen From gbonser at seven.com Sat Feb 26 01:21:56 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Feb 2011 22:21:56 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: <82DB39F1-2A33-411C-9E3E-576F1C70AA45@delong.com> References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> <000a01cbd577$9638f210$c2aad630$@iname.com> <5A6D953473350C4B9995546AFE9939EE0BC13DC1@RWC-EX1.corp.seven.com> <82DB39F1-2A33-411C-9E3E-576F1C70AA45@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13DC3@RWC-EX1.corp.seven.com> > >> > >> George: > >> > >> When you say "people", do you include non-service providers? Do you > >> think > >> that even if we mark the space for "service providers" only, that > that > >> note > >> will be ignored? > >> > >> Frank > > > > Yes, I believe it will be ignored. Particularly outside of the ARIN > > region, it will be views as additional "free" space but inside as > well. > > > I see where that becomes potentially inconvenient for service providers > and their customers in those regions, but, otherwise, I don't see harm > in this fact. > > Owen Right, it won't do any harm, it will just be another additional bit of pain thrown on the pile of other bits of pain for people who continue to use v4. It can be worked around which is why I don't outright oppose it, it isn't going to do any harm. And I can't think of a better way off the top of my head short of using Class E, which would be the "right" way to do this, in my opinion, but has its own sets of issues. From owen at delong.com Sat Feb 26 01:28:30 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Feb 2011 22:28:30 -0800 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Spacefor IPv4 Address Extension] In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13DC2@RWC-EX1.corp.seven.com> References: <4D596163.7000009@arin.net> <96A3E9A0-5E57-4697-B842-A03CB6C9F01A@queuefull.net> <5A6D953473350C4B9995546AFE9939EE0BC13D94@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC13DC2@RWC-EX1.corp.seven.com> Message-ID: <933121BC-EAB4-4B38-8FE7-15F8C19E1E9A@delong.com> On Feb 25, 2011, at 10:14 PM, George Bonser wrote: >> Hi George, >> >> Such an argument would be red herring (logical fallacy). I can claim >> 128.0.0.0/8 for my own as well. When I have trouble connecting to >> Internet hosts which overlap this range, it's nobody's fault but my >> own. > > Well, to some extent you are correct. I mean, it certainly would be > one's own fault but this net would be quite unlike 128/8 in that one > would be pretty much guaranteed not to overlap with any host on the > Internet. And to the extent to which it is the problem only of the end > network depends upon whether or not they are the only one a service > provider runs into using that space. After about the 20th one or so, I > would guess it would become a giant pain in the service provider's hips, > too. > The difference is that this pain means that they used the space after it was set aside for the provider to use for the conflicting purpose. That makes it easy for the service provider to tell those users bluntly "You need to renumber your network, you used a range that is reserved for our upstream connection to you." Whereas the user would be perfectly right to argue that it is up to the service provider to deal with their choice of RFC-1918 space. > But if I am right, it will become obvious in a year or two. I am not > opposed to this, but I will have to suppress an "I told you so" moment > when this becomes a pain in the hips being reported in NANOG every week. > Providers reporting this pain to NANOG will find deaf ears IMHO. Users do dumb things. Providers deal with this fact all the time. Nature of the business. However, when users do dumb things that go against rational policy, it's a lot easier to tell them so than when they do things that are simply inconvenient to the provider, but, technically correct (such as using whatever arbitrary RFC-1918 prefix they want). > Where a provider will run into this is provisioning a new customer whose > previous provider didn't use this space and is moving to a provider who > does use the space for their WAN addressing. It will take a couple of > years to raise its ugly head and the way most networks operate in > reality "it isn't a problem until it is a problem". It won't be a > problem for a couple of years down the road. I'll keep an eye out for > the stories, though, when they start to appear. > Meh, of course it will happen. The thing is it will still be a much smaller problem both in scope and difficulty. > I two years time people will be using every scrap of v4 they can find > and this /10 will end up being pressed into service in the most > unexpected ways. I hope I am wrong. > I tend to doubt that. Really we're mostly talking about residential end users here and for the most part they use whatever default chunk of 1918 space came on their home gateway and aren't particularly constrained by that space. Even if they feel constrained, I'd say their far more likely to decide to use 10.0.0.0/8 than to use some arbitrary x.192.0.0/10. Owen From mysidia at gmail.com Sat Feb 26 11:49:43 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Sat, 26 Feb 2011 10:49:43 -0600 Subject: [arin-ppml] Please try the strong arm tactics first - was Re: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <395d01cbd569$37539ce0$a5fad6a0$@com> References: <2F80AF77-788B-4E52-B274-0EA6445B9280@queuefull.net> <4D682596.3020104@ipinc.net> <395d01cbd569$37539ce0$a5fad6a0$@com> Message-ID: On Fri, Feb 25, 2011 at 9:56 PM, Warren Johnson wrote: > ================================ > Ipv4 depletion has the potential to reshape the entire Internet; and I don't > mean by changing to ipv6. ?If IPv4 becomes valuable property and people > can't get what they want, they're going to do very naughty things. > Remember, the corporation exists to make money for its shareholders so all > they're going to do is consider the potential legal costs associated with > litigating the RIR if they're caught and factor that into the cost of what > they're doing. ?I do not envy the registries. ?They're in a very tough spot. If that actually happens... the RIR community will have to deal with the eventual reality of government investigations and intervention, specifically, possibly a run-in with congress, the ITU, FCC, etc. Which would hurt the entire community, not just the legacy holders and ARIN, whose policymaking process would be co-opted, and there would be other unpredictable outcomes. Conflicts of that nature with sufficiently naughty things being done by major players would be proof that the industry failed to self-regulate, necessitating that the government respond to the crisis by coming in to "help" as in imposing some number assignment policy to force participants to behave. Since the internet has been elevated to the status of "important" for national security purposes, should naughty things involve IP hijacking happen, endusers will cry out to their representatives for help, when they cannot access their Facebook, because someone's doing naughty things hijacked its IPs; the larger the disruption caused by any addressing misbehvaior; the greater the danger, if a conflict with ARIN is somehow involved.... In the face of the risk of possible regulation, the RIRs would desperately need to establish their legitimacy, to continue to exist at all, which means using all reasonable means necessary to ensure an RSA or anything else required to enforce its policies applies to all resources under its stewardship. Using strong arm tactics FIRST is not really rational; if the objective is to maximize stability of the internet, the minimal "force" necessary should be used to get as many 'out of good standing' resource assignments as possible under proper RSAs.. Strong arm tactics, if considered at all, should only be considered in an emergency, after other options have been exhausted > Somewhere is a compromise. ?But first you have to open your eyes and see the > brick coming at you. -- -JH From owen at delong.com Sat Feb 26 12:12:21 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Feb 2011 09:12:21 -0800 Subject: [arin-ppml] Please try the strong arm tactics first - was Re: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: References: <2F80AF77-788B-4E52-B274-0EA6445B9280@queuefull.net> <4D682596.3020104@ipinc.net> <395d01cbd569$37539ce0$a5fad6a0$@com> Message-ID: <4D2A1CDF-1B31-4122-94AD-93A3CE6DC29F@delong.com> On Feb 26, 2011, at 8:49 AM, Jimmy Hess wrote: > On Fri, Feb 25, 2011 at 9:56 PM, Warren Johnson > wrote: >> ================================ >> Ipv4 depletion has the potential to reshape the entire Internet; and I don't >> mean by changing to ipv6. If IPv4 becomes valuable property and people >> can't get what they want, they're going to do very naughty things. >> Remember, the corporation exists to make money for its shareholders so all >> they're going to do is consider the potential legal costs associated with >> litigating the RIR if they're caught and factor that into the cost of what >> they're doing. I do not envy the registries. They're in a very tough spot. > > If that actually happens... the RIR community will have to deal with > the eventual reality of government investigations and > intervention, specifically, possibly a run-in with congress, > the ITU, FCC, etc. Which would hurt the entire community, not just > the legacy holders and ARIN, whose policymaking process would be > co-opted, and there would be other unpredictable outcomes. > I think assuming that the RIR policy process would be co-opted in such an event is speculative at best. I agree that it will hurt the entire internet (See my blog post at theipv6experts about how cooperation is key). However, the RIRs (and ARIN in particular) have not been operating in a vacuum or without some understanding of government and the likely outcomes of such suits. > Conflicts of that nature with sufficiently naughty things being done > by major players would be proof that the industry failed to self-regulate, > necessitating that the government respond to the crisis by coming in to > "help" as in imposing some number assignment policy to force participants > to behave. > Conflicts of that nature that result from certain bodies violating the "regulations" put in place by the community may result in government responding by giving those regulations the force of law. They may respond in other ways. Predicting what they will do is an imprecise activity at best. However, I think that if the government sees a consistent policy framework that works if people follow it, they are likely to do minimal tampering with the policy framework and work, instead, to apply that framework more forcefully. > Since the internet has been elevated to the status of "important" for > national security purposes, should naughty things involve IP hijacking > happen, endusers will cry out to their representatives for help, when > they cannot access their Facebook, because someone's doing naughty > things hijacked its IPs; the larger the disruption caused by any addressing > misbehvaior; the greater the danger, if a conflict with ARIN is somehow > involved.... > Indeed, the lack of cooperation will be damaging to all. The internet works because it is a cooperative anarchy and because through independent decisions of local network operators, miscreants tend to be regarded as damage and routed around. If local network operators stop de-routing miscreants, bad things will happen. If cooperation breaks down, bad things will happen. IP Address disputes are not the only threat of this nature. Peering politics also threaten the internet's ability to operate autonomous from burdensome regulation. Some larger players seem to want to bring such burdensome regulation to the internet. Indeed, that seemed to be the common ground/goal of both L3 and Comcast in some recent spats over who should pay what for mutual connectivity to each other's customers. However, such regulation will be difficult to apply to the internet as a whole (since it traverses virtually every jurisdiction on the planet and because it isn't a single entity, but, instead, a collection of independently owned and operated networks using a common protocol) and virtually impossible to do in a way that is non-destructive to what we currently expect in terms of capabilities from the internet. > > In the face of the risk of possible regulation, the RIRs would > desperately need to establish their legitimacy, to continue to > exist at all, which means using all reasonable means necessary to > ensure an RSA or anything else required to enforce its policies > applies to all resources under its stewardship. > I think that the combination of documents from DoC to ICANN and between ICANN and the NRO/ASO and thus the RIRs does a pretty good job to establish this legitimacy. Getting more legacy holders under RSA would also be useful, but, I doubt the RIRs will have trouble being recognized by any regulator as the most legitimate address authority currently in existence, whether they choose to continue with that system or not. > > Using strong arm tactics FIRST is not really rational; if the objective > is to maximize stability of the internet, the minimal "force" necessary > should be used to get as many 'out of good standing' resource > assignments as possible under proper RSAs.. > It really depends. I think a more accurate version of the request would be "Use strong arm tactics before simply allowing the legacy holders to steam-roll the policy process and create a speculative secondary IP market with independent registries not subject to any community driven address policy or process". Viewed in that light, I think that strong arm tactics are, indeed, more appropriate than the stated alternative. > Strong arm tactics, if considered at all, should only be considered > in an emergency, after other options have been exhausted > In general, I agree with you, but, in many ways, prop-136 looks like an opposing strong-arm tactic by those that want to establish registries that are not permitted under ICP-2 and would be contrary to the community's best interest IMHO. The proposal author claims that is not his intent, and that he has no such relationship. I'm inclined to believe him. Nonetheless, the proposed policy would accomplish that result even if that is not the actual intent. >> Somewhere is a compromise. But first you have to open your eyes and see the >> brick coming at you. Let's try to keep this civil and not start throwing bricks. Owen From woody at pch.net Sat Feb 26 20:39:01 2011 From: woody at pch.net (Bill Woodcock) Date: Sat, 26 Feb 2011 17:39:01 -0800 Subject: [arin-ppml] LRSA requirement for resources being transferred (Was: ARIN-prop-136 Services Opt-out Allowed for Unaffiliated Address Blocks In-Reply-To: <4D67EAE3.7090802@matthew.at> References: <4D67030F.6000600@matthew.at> <45805CA9-81EA-4913-B073-A5111A07199D@delong.com> <4D673BD8.6040003@matthew.at> <3C48D829-5DA8-45B7-9EE6-B145BFB4A0A6@pch.net> <4D67EAE3.7090802@matthew.at> Message-ID: <49FE5EAD-5918-420F-A2D3-EF2CB004F870@pch.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Feb 25, 2011, at 9:46 AM, Matthew Kaufman wrote: > And how would you go about enforcing that in the case... ARIN is not in the enforcement business. Internet assigned numbers are a consensual system. People participate in it if they want to. Anyone is free to set up a system other than the Internet, any time they want, based on any addressing system they want. The Internet is the system of people who choose to cooperate. Anyone who doesn't feel like cooperating is free to do whatever they want; they just won't be on the Internet, they'll be on some other network of people who don't cooperate. Which might be a small one. Since people are, generally speaking, sociable critters who like to cooperate to get things done. The existence of a few outlying sociopaths, in a world population of nearly seven billion, should come as no surprise, and has no deleterious effect, provided normal people don't allow them to erode the usual level of trust and cooperation. http://www.google.com/search&q=rule+14+of+the+internet -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk1pqzUACgkQGvQy4xTRsBGfzgCg0zcYW69QAjGU8OMbM/UE8pcZ cuUAoNIuoBNYVeHdS9P3ZduA0dnfnftf =4qGP -----END PGP SIGNATURE----- From farmer at umn.edu Sat Feb 26 23:45:33 2011 From: farmer at umn.edu (David Farmer) Date: Sat, 26 Feb 2011 22:45:33 -0600 Subject: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension] In-Reply-To: References: <4D596163.7000009@arin.net> <4D630A28.3010206@bogus.com> <2637BB05-4C32-49EB-A7BB-B73AA7A01718@delong.com> <4D631E4A.7070102@bogus.com> <3E60562B-F984-4DAE-878A-954C69A28F9C@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E370CDB@PDAWM12B.ad.sprint.com> <84FECA03-4B1B-4F9D-BE2D-C1A88D07FD42@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E3715DA@PDAWM12B.ad.sprint.com> <7643290F-4CF0-4C62-B32F-2F6CE12971FF@delong.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371763@PDAWM12B.ad.sprint.com> <54E900DC635DAB4DB7A6D799B3C4CD8E371CBA@PDAWM12B.ad.sprint.com> <45C6EA1D-2688-4060-8024-65A9BE508DD9@delong.com> Message-ID: <4D69D6ED.3000501@umn.edu> On 2/24/11 10:27 CST, William Herrin wrote: ... > So, Wes, Owen: Let's put our money where our mouths are so to speak. > If these addresses won't be wasted, let's require the policy to prove > it. Adjust the policy so that: > > 1) Within 6 months of ratification at least 10 ARIN allocation holders > must register with ARIN an intent to use addresses within the /10 in > their network within 24 months. If fewer than 10 register that intent > then the policy is void and the /10 is returned to the ARIN pool. While in general I currently support this proposal, even though I would rather not. I do think it is completely reasonable to ask some non-trivial number of service providers to come forward and announce they will use this block if allocated by ARIN. You can argue about the over-all merits and stewardship of this proposal, but without a reasonable number of service providers announcing they would use this block it would be impossible to defend the stewardship of this proposal in my opinion. So, if you are a service provider that would use this block if this proposal succeeds, please speak up and let us know soon, by the end of the San Juan meeting at the latest. > 2) After the first 24 months and every 24 months thereafter ARIN must > review the use of the /10 and make a positive determination that at > least 10 ARIN allocation holders are actually using it. If fewer than > 10 are using it and ARIN does not otherwise have at least a > /8-equivalent available for allocation (i.e. IPv4 isn't yet on the > decline), the whole pool is recycled into ARIN's free pool with a 12 > month delay for the 9 or fewer folks using it to renumber. It is about as practical to withdraw this allocation once it has been made, as it is to try to put toothpaste back into a tube. If service providers are going to deploy using an allocated block they need certainty that it is safe to do so, a withdrawal clause would probably not provide sufficient certainty. Who would want it to be allocated to this block after it was withdrawn, if any service providers actually deploy using this block? You would almost be assured of issues with any providers that have deployed using this block, therefore making it more or less useless for normal Internet use. > Owen, if we can't find 10 ISPs who are willing to step up and say > they'll use these addresses then Wes will have made his point: this > won't be a good use of a /10. Can you accept that result? +1 I agree we need service providers to step up and say they will use it, but before we allocate it. I think this is the bare minimum that the rest of the community should expect before allocating this block. > Wes, if a non-trivial number of ISPs actually use the addresses in > parallel then plainly this was a better use than assigning the > addresses to ISPs individually. Can you accept that result? +1 I agree. > I hear a lot of ideology in this debate. Are either/both of you > willing to measure and follow the data instead? +1 If no one says they will use it then it doesn't matter, it is not good stewardship! If providers use it, then it is probably as good of stewardship as we can expect in this situation. Better stewardship would have been to deploy dual-stack IPv6 by now, but that hasn't happened. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================