From hnarayan at cs.ucsd.edu Mon Feb 3 19:51:49 2003 From: hnarayan at cs.ucsd.edu (Harsha Narayan) Date: Mon, 3 Feb 2003 16:51:49 -0800 (PST) Subject: [ppml] Question Message-ID: Hello, Could you please answer the following question? Under what circumstances or conditions does ARIN or any other RIR get a new /8 fron IANA/ICANN? Harsha. From john at chagres.net Mon Feb 3 20:00:01 2003 From: john at chagres.net (John M. Brown) Date: Mon, 3 Feb 2003 18:00:01 -0700 Subject: [ppml] Question In-Reply-To: Message-ID: <001601c2cbe8$bf20e350$f9ecdfd8@laptoy> RFC 2050 but I think the 80 percent rule should NOT be applied to RIR's. That would be a /8 for every 10 the get... It would also be handy if ICANN actually did an audit of the RIR's and their space allocations someday :) basicly, when the RIR thinks its going to run out, they ask IANA for another > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Harsha Narayan > Sent: Monday, February 03, 2003 5:52 PM > To: ppml at arin.net > Subject: [ppml] Question > > > Hello, > Could you please answer the following question? > > Under what circumstances or conditions does ARIN or any > other RIR get a new /8 fron IANA/ICANN? > > Harsha. > From hnarayan at cs.ucsd.edu Mon Feb 3 20:03:39 2003 From: hnarayan at cs.ucsd.edu (Harsha Narayan) Date: Mon, 3 Feb 2003 17:03:39 -0800 (PST) Subject: [ppml] Question In-Reply-To: <001601c2cbe8$bf20e350$f9ecdfd8@laptoy> Message-ID: Hi, Do you mean that if an RIR uses up 80% of a /8, it gets a new /8 from IANA? However, I found that 6 out of ARIN's 17 /8s were below 80% utilization. The numbers for RIPE and APNIC are 3 out of 9 and 2 out of 9 respectively. Why is there a difference? Thank you very much for your reply. Harsha. On Mon, 3 Feb 2003, John M. Brown wrote: > RFC 2050 > > but I think the 80 percent rule should NOT be applied > to RIR's. That would be a /8 for every 10 the get... > > It would also be handy if ICANN actually did an audit of > the RIR's and their space allocations someday :) > > basicly, when the RIR thinks its going to run out, they > ask IANA for another > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Harsha Narayan > > Sent: Monday, February 03, 2003 5:52 PM > > To: ppml at arin.net > > Subject: [ppml] Question > > > > > > Hello, > > Could you please answer the following question? > > > > Under what circumstances or conditions does ARIN or any > > other RIR get a new /8 fron IANA/ICANN? > > > > Harsha. > > > From john at chagres.net Mon Feb 3 20:08:06 2003 From: john at chagres.net (John M. Brown) Date: Mon, 3 Feb 2003 18:08:06 -0700 Subject: [ppml] Question In-Reply-To: Message-ID: <001701c2cbe9$e02959a0$f9ecdfd8@laptoy> how did you make these tests ? > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Harsha Narayan > Sent: Monday, February 03, 2003 6:04 PM > To: John M. Brown > Cc: 'Harsha Narayan'; ppml at arin.net > Subject: RE: [ppml] Question > > > Hi, > Do you mean that if an RIR uses up 80% of a /8, it gets a > new /8 from IANA? > > However, I found that 6 out of ARIN's 17 /8s were below 80% > utilization. > > The numbers for RIPE and APNIC are 3 out of 9 and 2 out of 9 > respectively. > > Why is there a difference? > > Thank you very much for your reply. > > Harsha. > On Mon, 3 Feb 2003, John M. Brown wrote: > > > RFC 2050 > > > > but I think the 80 percent rule should NOT be applied > > to RIR's. That would be a /8 for every 10 the get... > > > > It would also be handy if ICANN actually did an audit of > > the RIR's and their space allocations someday :) > > > > basicly, when the RIR thinks its going to run out, they > > ask IANA for another > > > > > -----Original Message----- > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of > > > Harsha Narayan > > > Sent: Monday, February 03, 2003 5:52 PM > > > To: ppml at arin.net > > > Subject: [ppml] Question > > > > > > > > > Hello, > > > Could you please answer the following question? > > > > > > Under what circumstances or conditions does ARIN or any > other RIR > > > get a new /8 fron IANA/ICANN? > > > > > > Harsha. > > > > > > From jmcburnett at msmgmt.com Mon Feb 3 20:08:10 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Mon, 3 Feb 2003 20:08:10 -0500 Subject: [ppml] Question Message-ID: <390E55B947E7C848898AEBB9E507706041E197@msmdcfs01.msmgmt.com> Harsha, Please forgive my somewhat uneducated question.. How did you come up with this number? I am curious, but also just learning... Unless I am wrong, I am willing to bet that ARIN has more swamp space than RIPE and APNIC combined, and don't forget the recent divesture of LACNIC.. Anyway... This does sound awefully curious... J >Hi, > Do you mean that if an RIR uses up 80% of a /8, it gets a new /8 from >IANA? > >However, I found that 6 out of ARIN's 17 /8s were below 80% >utilization. > >The numbers for RIPE and APNIC are 3 out of 9 and 2 out of 9 >respectively. > >Why is there a difference? > >Thank you very much for your reply. > >Harsha. >On Mon, 3 Feb 2003, John M. Brown wrote: > >> RFC 2050 >> >> but I think the 80 percent rule should NOT be applied >> to RIR's. That would be a /8 for every 10 the get... >> >> It would also be handy if ICANN actually did an audit of >> the RIR's and their space allocations someday :) >> >> basicly, when the RIR thinks its going to run out, they >> ask IANA for another >> >> > -----Original Message----- >> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On >> > Behalf Of Harsha Narayan >> > Sent: Monday, February 03, 2003 5:52 PM >> > To: ppml at arin.net >> > Subject: [ppml] Question >> > >> > >> > Hello, >> > Could you please answer the following question? >> > >> > Under what circumstances or conditions does ARIN or any >> > other RIR get a new /8 fron IANA/ICANN? >> > >> > Harsha. >> > >> > > From hnarayan at cs.ucsd.edu Mon Feb 3 20:10:56 2003 From: hnarayan at cs.ucsd.edu (Harsha Narayan) Date: Mon, 3 Feb 2003 17:10:56 -0800 (PST) Subject: [ppml] Question In-Reply-To: <001701c2cbe9$e02959a0$f9ecdfd8@laptoy> Message-ID: Hi, I took the databases from ftp.arin.net, ftp.apnic.net, ftp.ripe.net. Then I saw how much of address space was represented by the allocations and assignments listed there from the RIRs' /8s. Thanks, Harsha. On Mon, 3 Feb 2003, John M. Brown wrote: > how did you make these tests ? > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Harsha Narayan > > Sent: Monday, February 03, 2003 6:04 PM > > To: John M. Brown > > Cc: 'Harsha Narayan'; ppml at arin.net > > Subject: RE: [ppml] Question > > > > > > Hi, > > Do you mean that if an RIR uses up 80% of a /8, it gets a > > new /8 from IANA? > > > > However, I found that 6 out of ARIN's 17 /8s were below 80% > > utilization. > > > > The numbers for RIPE and APNIC are 3 out of 9 and 2 out of 9 > > respectively. > > > > Why is there a difference? > > > > Thank you very much for your reply. > > > > Harsha. > > On Mon, 3 Feb 2003, John M. Brown wrote: > > > > > RFC 2050 > > > > > > but I think the 80 percent rule should NOT be applied > > > to RIR's. That would be a /8 for every 10 the get... > > > > > > It would also be handy if ICANN actually did an audit of > > > the RIR's and their space allocations someday :) > > > > > > basicly, when the RIR thinks its going to run out, they > > > ask IANA for another > > > > > > > -----Original Message----- > > > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of > > > > Harsha Narayan > > > > Sent: Monday, February 03, 2003 5:52 PM > > > > To: ppml at arin.net > > > > Subject: [ppml] Question > > > > > > > > > > > > Hello, > > > > Could you please answer the following question? > > > > > > > > Under what circumstances or conditions does ARIN or any > > other RIR > > > > get a new /8 fron IANA/ICANN? > > > > > > > > Harsha. > > > > > > > > > > From cire at deckerstone.net Mon Feb 3 21:35:11 2003 From: cire at deckerstone.net (Eric B. Decker) Date: Mon, 03 Feb 2003 18:35:11 -0800 Subject: [ppml] Question In-Reply-To: Message from "McBurnett, Jim" of "Mon, 03 Feb 2003 20:08:10 EST." <390E55B947E7C848898AEBB9E507706041E197@msmdcfs01.msmgmt.com> Message-ID: <20030204023512.5578.qmail@deckerstone.net> >>>>> "jm" == McBurnett, Jim writes: jm> Harsha, jm> Unless I am wrong, I am willing to bet that ARIN jm> has more swamp space than RIPE and APNIC combined, jm> and don't forget the recent divesture of LACNIC.. jm> Anyway... I beleive that is correct. I beleive that the Legacy space allocations (pre-RIPE) show up in ARIN land. -c aso ac - ARIN jm> This does sound awefully curious... jm> J >> Hi, >> Do you mean that if an RIR uses up 80% of a /8, it gets a new /8 from >> IANA? >> >> However, I found that 6 out of ARIN's 17 /8s were below 80% >> utilization. >> >> The numbers for RIPE and APNIC are 3 out of 9 and 2 out of 9 >> respectively. >> >> Why is there a difference? >> >> Thank you very much for your reply. >> >> Harsha. >> On Mon, 3 Feb 2003, John M. Brown wrote: >> >>> RFC 2050 >>> >>> but I think the 80 percent rule should NOT be applied >>> to RIR's. That would be a /8 for every 10 the get... >>> >>> It would also be handy if ICANN actually did an audit of >>> the RIR's and their space allocations someday :) >>> >>> basicly, when the RIR thinks its going to run out, they >>> ask IANA for another >>> >>> > -----Original Message----- >>> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On >>> > Behalf Of Harsha Narayan >>> > Sent: Monday, February 03, 2003 5:52 PM >>> > To: ppml at arin.net >>> > Subject: [ppml] Question >>> > >>> > >>> > Hello, >>> > Could you please answer the following question? >>> > >>> > Under what circumstances or conditions does ARIN or any >>> > other RIR get a new /8 fron IANA/ICANN? >>> > >>> > Harsha. >>> > >>> >> >> From cjw at groovy.com Mon Feb 3 21:54:58 2003 From: cjw at groovy.com (CJ Wittbrodt) Date: Mon, 03 Feb 2003 18:54:58 -0800 Subject: [ppml] Question In-Reply-To: Message from "Eric B. Decker" of "Mon, 03 Feb 2003 18:35:11 PST." <20030204023512.5578.qmail@deckerstone.net> Message-ID: <200302040254.h142swj83056@duchess.groovy.com> There has been a project underway for quite some time. The RIRs have been in the process of moving the pre-RIR address space allocations to their appropriate RIR. ---CJ From: "Eric B. Decker" Subject: Re: [ppml] Question >>>>> "jm" == McBurnett, Jim writes: jm> Harsha, jm> Unless I am wrong, I am willing to bet that ARIN jm> has more swamp space than RIPE and APNIC combined, jm> and don't forget the recent divesture of LACNIC.. jm> Anyway... I beleive that is correct. I beleive that the Legacy space allocations (pre-RIPE) show up in ARIN land. -c aso ac - ARIN jm> This does sound awefully curious... jm> J >> Hi, >> Do you mean that if an RIR uses up 80% of a /8, it gets a new /8 from >> IANA? >> >> However, I found that 6 out of ARIN's 17 /8s were below 80% >> utilization. >> >> The numbers for RIPE and APNIC are 3 out of 9 and 2 out of 9 >> respectively. >> >> Why is there a difference? >> >> Thank you very much for your reply. >> >> Harsha. >> On Mon, 3 Feb 2003, John M. Brown wrote: >> >>> RFC 2050 >>> >>> but I think the 80 percent rule should NOT be applied >>> to RIR's. That would be a /8 for every 10 the get... >>> >>> It would also be handy if ICANN actually did an audit of >>> the RIR's and their space allocations someday :) >>> >>> basicly, when the RIR thinks its going to run out, they >>> ask IANA for another >>> >>> > -----Original Message----- >>> > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On >>> > Behalf Of Harsha Narayan >>> > Sent: Monday, February 03, 2003 5:52 PM >>> > To: ppml at arin.net >>> > Subject: [ppml] Question >>> > >>> > >>> > Hello, >>> > Could you please answer the following question? >>> > >>> > Under what circumstances or conditions does ARIN or any >>> > other RIR get a new /8 fron IANA/ICANN? >>> > >>> > Harsha. >>> > >>> >> >> From cire at deckerstone.net Tue Feb 4 00:09:28 2003 From: cire at deckerstone.net (Eric B. Decker) Date: Mon, 03 Feb 2003 21:09:28 -0800 Subject: [ppml] Question In-Reply-To: Message from CJ Wittbrodt of "Mon, 03 Feb 2003 18:54:58 PST." <200302040254.h142swj83056@duchess.groovy.com> Message-ID: <20030204050928.5960.qmail@deckerstone.net> Hi Cathy, Do you know who has been working on this lately? Its my understanding there is still a fair amount that hasn't been gone through. At least that is something I heard at the RIPE meeting and I'm trying to check it out. thanks, -c >>>>> "cjw" == CJ Wittbrodt writes: cjw> There has been a project underway for quite some time. The RIRs cjw> have been in the process of moving the pre-RIR address space allocations cjw> to their appropriate RIR. cjw> ---CJ From cjw at groovy.com Tue Feb 4 00:15:14 2003 From: cjw at groovy.com (CJ Wittbrodt) Date: Mon, 03 Feb 2003 21:15:14 -0800 Subject: [ppml] Question In-Reply-To: Message from "Eric B. Decker" of "Mon, 03 Feb 2003 21:09:28 PST." <20030204050928.5960.qmail@deckerstone.net> Message-ID: <200302040515.h145FEj84077@duchess.groovy.com> It is a project that the RIRs are working on together. You'd have to ask them. I know that continuing in-addr service for these blocks is important and rushing the process could cause an interrupt of service. ---CJ From: "Eric B. Decker" Subject: Re: [ppml] Question Hi Cathy, Do you know who has been working on this lately? Its my understanding there is still a fair amount that hasn't been gone through. At least that is something I heard at the RIPE meeting and I'm trying to check it out. thanks, -c >>>>> "cjw" == CJ Wittbrodt writes: cjw> There has been a project underway for quite some time. The RIRs cjw> have been in the process of moving the pre-RIR address space allocations cjw> to their appropriate RIR. cjw> ---CJ From richardj at arin.net Tue Feb 4 09:08:15 2003 From: richardj at arin.net (Richard Jimmerson) Date: Tue, 4 Feb 2003 09:08:15 -0500 Subject: [ppml] Question In-Reply-To: <20030204050928.5960.qmail@deckerstone.net> Message-ID: <010801c2cc56$ddd3bc50$d4fc95c0@Cobalt2> Hello Eric, > Do you know who has been working on this lately? > Its my understanding there is still a fair amount that hasn't > been gone through. At least that is something I heard at the > RIPE meeting and I'm trying to check it out. Information about the early registration transfer project is available at: http://www.arin.net/registration/erx/index.html All of the AS numbers were transferred last year. Recently, 129.0.0.0/8 has been the focus of the project and the transfers associated with that /8 have been completed. RIPE NCC reported the results of this transfer to the Database Working Group at the RIPE meeting last week and has the approval of their community to move forward with additional transfers. APNIC and LACNIC are also working very closely with ARIN on this project and transfers within several /8s are expected to be completed within the next few months. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Eric B. Decker > Sent: Tuesday, February 04, 2003 12:09 AM > To: CJ Wittbrodt > Cc: McBurnett, Jim; Harsha Narayan; John M. Brown; ppml at arin.net > Subject: Re: [ppml] Question > > > > Hi Cathy, > > Do you know who has been working on this lately? > Its my understanding there is still a fair amount that hasn't > been gone through. At least that is something I heard at the > RIPE meeting and I'm trying to check it out. > > thanks, > > -c > > >>>>> "cjw" == CJ Wittbrodt writes: > > cjw> There has been a project underway for quite some > time. The RIRs > cjw> have been in the process of moving the pre-RIR > address space allocations > cjw> to their appropriate RIR. > > cjw> ---CJ > From cire at deckerstone.net Tue Feb 4 10:15:20 2003 From: cire at deckerstone.net (Eric B. Decker) Date: Tue, 04 Feb 2003 07:15:20 -0800 Subject: [ppml] Question In-Reply-To: Message from "Richard Jimmerson" of "Tue, 04 Feb 2003 09:08:15 EST." <010801c2cc56$ddd3bc50$d4fc95c0@Cobalt2> Message-ID: <20030204151520.7485.qmail@deckerstone.net> Thanks for the update Richard. I appreciate. -c >>>>> "rj" == Richard Jimmerson writes: rj> Hello Eric, >> Do you know who has been working on this lately? >> Its my understanding there is still a fair amount that hasn't >> been gone through. At least that is something I heard at the >> RIPE meeting and I'm trying to check it out. rj> Information about the early registration transfer project is rj> available at: rj> http://www.arin.net/registration/erx/index.html rj> All of the AS numbers were transferred last year. Recently, rj> 129.0.0.0/8 has been the focus of the project and the transfers rj> associated with that /8 have been completed. RIPE NCC reported rj> the results of this transfer to the Database Working Group at rj> the RIPE meeting last week and has the approval of their rj> community to move forward with additional transfers. APNIC and rj> LACNIC are also working very closely with ARIN on this project rj> and transfers within several /8s are expected to be completed rj> within the next few months. rj> Best Regards, rj> Richard Jimmerson rj> Director of Operations rj> American Registry for Internet Numbers (ARIN) >> -----Original Message----- >> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On >> Behalf Of Eric B. Decker >> Sent: Tuesday, February 04, 2003 12:09 AM >> To: CJ Wittbrodt >> Cc: McBurnett, Jim; Harsha Narayan; John M. Brown; ppml at arin.net >> Subject: Re: [ppml] Question >> >> >> >> Hi Cathy, >> >> Do you know who has been working on this lately? >> Its my understanding there is still a fair amount that hasn't >> been gone through. At least that is something I heard at the >> RIPE meeting and I'm trying to check it out. >> >> thanks, >> >> -c >> >> >>>>> "cjw" == CJ Wittbrodt writes: >> cjw> There has been a project underway for quite some >> time. The RIRs cjw> have been in the process of moving the pre-RIR >> address space allocations cjw> to their appropriate RIR. >> cjw> ---CJ >> From steve at rovingplanet.com Tue Feb 11 11:50:04 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Tue, 11 Feb 2003 09:50:04 -0700 Subject: [ppml] ppml 2002-7 Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7700@pluto.rovingplanet.com> I would like to thank those that brought this matter forward and apologize for commenting so late on the issue. I just found out about this proposal since it is buried in the ARIN site. As someone that has helped companies establish multihomed networks, I have seen the need for this for a long time. I reviewed the email listing to see what issue this would raise and found that none of the objections were really credible. There is little credible engineering reason to deny allowing an organization to own a small public block. I have not seen any research done that would suggest that doing this would impact routing table size. Business today really requires that companies have solid Internet connectivity. Companies understand that their email, informational and e-commerce sites need to be available. Hosting is not the slam dunk decision anymore and many companies are keeping or bringing back their internet apps on site using multihomed networks. This is what is driving the table growth. While the provider that gives a block to an organization can aggregate the announcement from its network, that is not the case with the other provider(s) that the site is connected to. Thus outside the connecting providers, the table has grown when the site goes live. What is the difference if the block was sold by one provider or ARIN? As for the block size, the only given reason this is an issue is in aggregation. Look at the number of tupples being reported in the last meeting in Oregon. 50,000+ in the /24 block. Where is the aggregation? Its not there because the idea of aggregation appears to be a fallacy. There is no reason to keep an artificially high block size other then keep money going to large companies that can afford to buy large blocks for resale. In fact I would bet that ARIN could pull back even more numbers if more providers would announce smaller blocks then /24. Most organizations really need fewer then 64 public addresses now since the rest of their networks use non routable address space and reside behind firewalls. That means that 3/4 of the IP space those 50,000+ tupples have could possibly be reused if better support were given. This wouldn't make the tables grow just migrate the tupples to smaller blocks. The arguments about links are meaningless. If a provider is willing to provide BGP service, it's because someone is willing to pay for it and only for that reason no matter if the link an OC-192 or a 56k dialup. It doesn't matter if the block came from ARIN or one of the providers. The table still grows. >From a business standpoint it makes sense to own a public IP block especially at this point in time. Yes, organizations are being hurt by ISPs that suddenly close their doors. The hurt is more then just a renumbering. It is actual dollars, pesos or whatever currency is used by that organization. There is software that is VERY expensive that many times must be tied to a public IP address. The companies providing this software make it expensive to re-license systems to another IP or limit the number of times it can be done (I seen and heard of companies hit more than 3 times in a six month period). Additionally it takes time to do a renumber and if the need is sudden, business is lost while arrangements are made to get space from the other provider, get new licenses, renumber systems and wait for DNS caches to time out. Not allowing smaller block sizes only helps the providers lock in a customer. Why should ARIN care about such matters? Because ARIN was created to serve the general public's need for addressing not the business desires of a few companies that wish to monopolize this limited commodity. Thank you, Steve Rolapp -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahp at hilander.com Tue Feb 11 11:56:29 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Tue, 11 Feb 2003 09:56:29 -0700 Subject: [ppml] ppml 2002-7 In-Reply-To: <661F9268BBA8CB4EB92CC12B8C42F0690F7700@pluto.rovingplanet.com> References: <661F9268BBA8CB4EB92CC12B8C42F0690F7700@pluto.rovingplanet.com> Message-ID: <2147483647.1044957389@macleod.hilander.com> --On Tuesday, February 11, 2003 9:50 -0700 Steve Rolapp wrote: > > There is little credible engineering reason to deny allowing an > organization to own a small public block. I have not seen any research > done that would suggest that doing this would impact routing table size. The routing table size isn't really the main argument against this. It's the _structure_ of the routing table, in terms of ability to aggregate. Right now, ARIN only allocates /20 and longer blocks. This means that service providers could filter routes they receive on this boundary (in ARIN blocks anyway) to help control the size of the routing table in their network. If ARIN allocates longer blocks, this ties the hands of service providers. > > While the provider that gives a block to an organization can aggregate > the announcement from its network, that is not the case with the other > provider(s) that the site is connected to. Thus outside the connecting > providers, the table has grown when the site goes live. What is the > difference if the block was sold by one provider or ARIN? The blocks are not 'sold'. And see above for the difference. Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From cjw at groovy.com Tue Feb 11 12:04:45 2003 From: cjw at groovy.com (CJ Wittbrodt) Date: Tue, 11 Feb 2003 09:04:45 -0800 Subject: [ppml] ppml 2002-7 In-Reply-To: Message from "Alec H. Peterson" of "Tue, 11 Feb 2003 09:56:29 MST." <2147483647.1044957389@macleod.hilander.com> Message-ID: <200302111704.h1BH4jj68204@duchess.groovy.com> > > There is little credible engineering reason to deny allowing an > organization to own a small public block. I have not seen any research > done that would suggest that doing this would impact routing table size. The routing table size isn't really the main argument against this. It's the _structure_ of the routing table, in terms of ability to aggregate. Right now, ARIN only allocates /20 and longer blocks. This means that service providers could filter routes they receive on this boundary (in ARIN blocks anyway) to help control the size of the routing table in their network. If ARIN allocates longer blocks, this ties the hands of service providers. Don't you mean ARIN allocates /20 or shorter length blocks? Anyway, I have been doing some work with some students at UCLA. The current results say that around 48% of allocated blocks are advertised identically to how they're allocated (same prefix length, not fragments). Around 40% of the allocated blocks are advertised in one or modes of fragmentation (combinations of aggregates and fragments). This means that an ISP could get great benefit from being able to filter out the fragments of shorter provider blocks. I am presenting this at NANOG so fee free to look at my slides. ---CJ From ahp at hilander.com Tue Feb 11 12:04:46 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Tue, 11 Feb 2003 10:04:46 -0700 Subject: [ppml] ppml 2002-7 In-Reply-To: <200302111704.h1BH4jj68204@duchess.groovy.com> References: <200302111704.h1BH4jj68204@duchess.groovy.com> Message-ID: <2147483647.1044957886@macleod.hilander.com> --On Tuesday, February 11, 2003 9:04 -0800 CJ Wittbrodt wrote: > > Don't you mean ARIN allocates /20 or shorter length blocks? Hrm, yes, that seems to make much more sense. *face turns crimson* Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From forrest at almighty.c64.org Tue Feb 11 12:19:48 2003 From: forrest at almighty.c64.org (Forrest) Date: Tue, 11 Feb 2003 11:19:48 -0600 (CST) Subject: [ppml] ppml 2002-7 In-Reply-To: <200302111704.h1BH4jj68204@duchess.groovy.com> Message-ID: On Tue, 11 Feb 2003, CJ Wittbrodt wrote: > > > > > > There is little credible engineering reason to deny allowing an > > organization to own a small public block. I have not seen any research > > done that would suggest that doing this would impact routing table size. > > The routing table size isn't really the main argument against this. It's > the _structure_ of the routing table, in terms of ability to aggregate. > > Right now, ARIN only allocates /20 and longer blocks. This means that > service providers could filter routes they receive on this boundary (in > ARIN blocks anyway) to help control the size of the routing table in their > network. If ARIN allocates longer blocks, this ties the hands of service > providers. > > Don't you mean ARIN allocates /20 or shorter length blocks? > > Anyway, I have been doing some work with some students at UCLA. The current > results say that around 48% of allocated blocks are advertised identically > to how they're allocated (same prefix length, not fragments). Around > 40% of the allocated blocks are advertised in one or modes of fragmentation > (combinations of aggregates and fragments). This means that an ISP could > get great benefit from being able to filter out the fragments of shorter > provider blocks. I am presenting this at NANOG so fee free to look at my > slides. > > ---CJ > To me, it seems that the biggest issue that 2002-7 seems to address is trying to multihome small blocks that aren't located in the old Class C space. It seems that most providers that do filtering, they filter on the old Class boundries. In the old Class C space, they'll accept /24's because of people using old swamp space. So suppose you have block 192.0.0.0/23, your block won't likely get filtered, but suppose you have 12.100.100.0/23, what good is it to multihome if nobody would accept your small route? Basically it makes sense to allocate a specific block just for small organizations that want to multihome, that providers will accept /24's and shorter from (allocate it from the old Class C range and I doubt anyone will have to adjust their filters). I just don't see this causing the routing table to explode in size. What's exploding the routing table is stuff like someone announcing a /18 as 64 /24's (look at 205.145.0.0). Forrest From ahp at hilander.com Tue Feb 11 12:26:41 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Tue, 11 Feb 2003 10:26:41 -0700 Subject: [ppml] ppml 2002-7 In-Reply-To: References: Message-ID: <2147483647.1044959201@macleod.hilander.com> --On Tuesday, February 11, 2003 11:19 -0600 Forrest wrote: > > To me, it seems that the biggest issue that 2002-7 seems to address is > trying to multihome small blocks that aren't located in the old Class C > space. It seems that most providers that do filtering, they filter on > the old Class boundries. In the old Class C space, they'll accept /24's > because of people using old swamp space. So suppose you have block > 192.0.0.0/23, your block won't likely get filtered, but suppose you have > 12.100.100.0/23, what good is it to multihome if nobody would accept your > small route? Basically it makes sense to allocate a specific block just > for small organizations that want to multihome, that providers will > accept /24's and shorter from (allocate it from the old Class C range and > I doubt anyone will have to adjust their filters). I just don't see this > causing the routing table to explode in size. What's exploding the > routing table is stuff like someone announcing a /18 as 64 /24's (look at > 205.145.0.0). But this is entirely the point behind the objections to allocating /24s again. We used to allocate /24s,?and now we have a horrible mess of unaggregatable space (the swamp, 205/8 is pre-/19 space). Current allocation policy has not stopped people from announcing /24s, but it at least allows people to aggregate to a certain degree and still be able to reach the entire Internet. If we do allocate /24s, even from existing swamp space, eventually we'll run out and we'll have to create a new swamp. It seems to me that this would be failing to learn from previous mistakes. And as far as people announcing 64 /24s instead of the /18, that space can in fact be aggregated (assuming it is indeed a /18 allocation). A service provider could filter those and be OK. Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From jmcburnett at msmgmt.com Tue Feb 11 12:40:41 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Tue, 11 Feb 2003 12:40:41 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <390E55B947E7C848898AEBB9E507706041E243@msmdcfs01.msmgmt.com> OK... Please not comments below... >But this is entirely the point behind the objections to >allocating /24s >again. > >We used to allocate /24s,?and now we have a horrible mess of >unaggregatable >space (the swamp, 205/8 is pre-/19 space). Current allocation >policy has >not stopped people from announcing /24s, but it at least >allows people to >aggregate to a certain degree and still be able to reach the entire >Internet. Aggregate- formed by the collection of units or particles into a body, mass, or amount as defined by Webster. Purpose in routing-- to decrease the size of often unwieldy route tables due to router constraints. HMMM.. I seem to remember a PP be 2002-3 or -7 that specifically said one of the reasons that give cause to the /24 for small to mid-sized companies is the increase in the abilities of the lower priced routers to handle this.. Especially the Cisco 2650XM and 2690 series. With that said, what is the holdback.. As I see it.. it is the ISP's balking at routing my little ole /24 from the 66.x.y.z block that is not on the class boundaries. And this brings up the question: If their routers can't handle this, how in the world are they going to be ready for IPv6????? I really think we are talking about old school network engineers that think their routers just won't handle it.. mostly I see Cisco 12000 doing the routing and the juniper equiv. Sure the small ISPs will use 7200, and maybe 7500, but what are we talking about here... The big boys are the holdup... Anyway just my thoughts.... J From chuegen at cisco.com Tue Feb 11 12:44:29 2003 From: chuegen at cisco.com (Craig A. Huegen) Date: Tue, 11 Feb 2003 11:44:29 -0600 (Central Standard Time) Subject: [ppml] ppml 2002-7 In-Reply-To: <200302111704.h1BH4jj68204@duchess.groovy.com> Message-ID: On Tue, 11 Feb 2003, CJ Wittbrodt wrote: > Anyway, I have been doing some work with some students at UCLA. The current > results say that around 48% of allocated blocks are advertised identically > to how they're allocated (same prefix length, not fragments). Around > 40% of the allocated blocks are advertised in one or modes of fragmentation > (combinations of aggregates and fragments). This means that an ISP could > get great benefit from being able to filter out the fragments of shorter > provider blocks. I am presenting this at NANOG so fee free to look at my > slides. There is a valid application for a difference between the prefix allocation size and the actual announcements found on the Internet, perhaps not at the scale that you're finding. Large, multi-national enterprises are depending more and more upon the Internet and connectivity to it, and the distribution of Internet access points is increasing. Where it was okay to have a single connection in 1995 for a large organization, today's use of remote access VPN, branch office VPN, support sites, etc. all demand that an organization's network be close to the user. An enterprise is not a transit network, and it doesn't make sense for the enterprise to pay a service provider to deliver Internet traffic to him in a location far from his destination, then pay another service provider to carry it on an internal WAN. This should be considered when a discussion is made of allocation size versus announced block size. A large multi-national might have address space needs of a /14, but may announce only portions of that block from various regional hubs. The alternative, of course, is to make more work for the registries in forcing the enterprise to make individual block requests for each regional hub to be deployed. We could assure that allocation size was consistent with announced size, for zero gain (same # of prefixes in the table) and more work for the registry. /cah -- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From forrest at almighty.c64.org Tue Feb 11 12:45:07 2003 From: forrest at almighty.c64.org (Forrest) Date: Tue, 11 Feb 2003 11:45:07 -0600 (CST) Subject: [ppml] ppml 2002-7 In-Reply-To: <2147483647.1044959201@macleod.hilander.com> Message-ID: On Tue, 11 Feb 2003, Alec H. Peterson wrote: > We used to allocate /24s,?and now we have a horrible mess of unaggregatable > space (the swamp, 205/8 is pre-/19 space). Current allocation policy has > not stopped people from announcing /24s, but it at least allows people to > aggregate to a certain degree and still be able to reach the entire > Internet. It seems like alot of the people announcing /24's are not doing it to provide redundancy, but rather to load balance between their two circuits. I can completely understand filtering these /24's, but in the process it hurts the small organization that wants to multihome for redundancy but isn't large enough to qualify for a /20. In reality, the current ARIN allocation policy actually seems to encourage the wasting of IP address space just to be able to qualify for a /19, when perhaps only a /22 would be more than plenty. You only have to look at some of these web hosting companies to see evidence of wasting IP addresses. I've seen a whole /25 assigned to ONE single webserver before, even when virtual hosting would have worked just fine. > > If we do allocate /24s, even from existing swamp space, eventually we'll > run out and we'll have to create a new swamp. It seems to me that this > would be failing to learn from previous mistakes. > I don't see anything necessarily bad with a new swamp if all of the addresses in it are used to multihome. It would be silly to assign a /24 to someone that only connects to one provider, since you could just give them a /24 from the provider's larger aggregate. If you quit multihoming, you return your addresses back to the "multihome swamp". This would allow providers to filter out the useless /24's (like the /18 being announced as 64 /24's, yet allow them to accept somewhat more important small multihoming blocks). Forrest From chuegen at cisco.com Tue Feb 11 12:52:07 2003 From: chuegen at cisco.com (Craig A. Huegen) Date: Tue, 11 Feb 2003 11:52:07 -0600 (Central Standard Time) Subject: [ppml] ppml 2002-7 In-Reply-To: <2147483647.1044959201@macleod.hilander.com> Message-ID: On Tue, 11 Feb 2003, Alec H. Peterson wrote: > But this is entirely the point behind the objections to allocating /24s > again. > > We used to allocate /24s,?and now we have a horrible mess of unaggregatable > space (the swamp, 205/8 is pre-/19 space). Current allocation policy has > not stopped people from announcing /24s, but it at least allows people to > aggregate to a certain degree and still be able to reach the entire > Internet. I don't think you can blame the prefix length for the problems in the dump or swamp. I think you can blame a number of other factors which are more significant, like the lack of alignment to bit boundaries for aggregation, the very loose (if at all) requirements for justification. Counting on /24 vs. /20 to establish a bar to entry is a risky approach. Leave it at /20 and you'll find people getting more space than they need, creating waste of address space. I think we might see more gains if we focus more heavily on the reclaim side when an organization comes back for more. /cah -- Craig A. Huegen, Chief Network Architect C i s c o S y s t e m s IT Transport, Network Technology & Design || || Cisco Systems, Inc., 400 East Tasman Drive || || San Jose, CA 95134, (408) 526-8104 |||| |||| email: chuegen at cisco.com CCIE #2100 ..:||||||:..:||||||:.. From jmcburnett at msmgmt.com Tue Feb 11 13:00:56 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Tue, 11 Feb 2003 13:00:56 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <390E55B947E7C848898AEBB9E507706041E246@msmdcfs01.msmgmt.com> >> >> If we do allocate /24s, even from existing swamp space, >eventually we'll >> run out and we'll have to create a new swamp. It seems to >me that this >> would be failing to learn from previous mistakes. >> > >I don't see anything necessarily bad with a new swamp if all of the >addresses in it are used to multihome. It would be silly to >assign a /24 >to someone that only connects to one provider, since you could >just give >them a /24 from the provider's larger aggregate. If you quit >multihoming, >you return your addresses back to the "multihome swamp". This >would allow >providers to filter out the useless /24's (like the /18 being >announced as >64 /24's, yet allow them to accept somewhat more important small >multihoming blocks). > >Forrest > > Swamp space.. I have only a vague comprehension of this.. Can someone elaborate for me? Thanks, Jim Jim McBurnett Director of Information Technology Mid-South Management Company, Inc. From forrest at almighty.c64.org Tue Feb 11 13:17:03 2003 From: forrest at almighty.c64.org (Forrest) Date: Tue, 11 Feb 2003 12:17:03 -0600 (CST) Subject: [ppml] ppml 2002-7 In-Reply-To: <390E55B947E7C848898AEBB9E507706041E246@msmdcfs01.msmgmt.com> Message-ID: > Swamp space.. I have only a vague comprehension of this.. > Can someone elaborate for me? > > Thanks, > Jim > Basically it's the old address space that /24's used to be allocated directly from ARIN and can't be aggregated today. Just to pick some random examples. 192.12.3.0/24 192.12.4.0/24 192.12.5.0/24 ... .. Those blocks are all allocated to different organizations and have to be announced as individual /24's to be reachable because no larger aggregate can be announced. Forrest From jmcburnett at msmgmt.com Tue Feb 11 13:34:15 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Tue, 11 Feb 2003 13:34:15 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <390E55B947E7C848898AEBB9E507706041E249@msmdcfs01.msmgmt.com> THANKS!!! But I guess I would have to wonder who had that address before me If I got swamp space... IE SPAMMER FROM ****.... But that is another discussion... J >-----Original Message----- >From: Forrest [mailto:forrest at almighty.c64.org] >Sent: Tuesday, February 11, 2003 1:17 PM >To: ppml at arin.net >Subject: RE: [ppml] ppml 2002-7 > > > > >> Swamp space.. I have only a vague comprehension of this.. >> Can someone elaborate for me? >> >> Thanks, >> Jim >> > >Basically it's the old address space that /24's used to be allocated >directly from ARIN and can't be aggregated today. Just to pick some >random examples. > >192.12.3.0/24 >192.12.4.0/24 >192.12.5.0/24 >... >.. > >Those blocks are all allocated to different organizations and >have to be >announced as individual /24's to be reachable because no >larger aggregate >can be announced. > >Forrest > > From forrest at almighty.c64.org Tue Feb 11 13:46:08 2003 From: forrest at almighty.c64.org (Forrest) Date: Tue, 11 Feb 2003 12:46:08 -0600 (CST) Subject: [ppml] ppml 2002-7 In-Reply-To: <390E55B947E7C848898AEBB9E507706041E249@msmdcfs01.msmgmt.com> Message-ID: On Tue, 11 Feb 2003, McBurnett, Jim wrote: > THANKS!!! > But I guess I would have to wonder who had that address before me > If I got swamp space... > IE SPAMMER FROM ****.... > But that is another discussion... > J I'm not saying we should reuse the old swamp space for a new "multihome swamp". I'm saying set aside a new previously unused block of addresses from the old Class C range to be assigned directly to small organizations that multihome, which is basically what 2002-7 is suggesting. I'm definitely in favor of cleaning up the existing swamp space however, get any organization that still uses space in the swamp to renumber into their provider's larger aggregate and give the space back. I think this is basically what 2002-6 is attempting to encourage. The only way you're going to get people to renumber out of the swamp is to offer some sort of incentive to do so (money), or just plain force them to do it. Forrest From Stacy_Taylor at icgcomm.com Tue Feb 11 14:19:15 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 11 Feb 2003 12:19:15 -0700 Subject: [ppml] Linking Threads.... Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DADCFD@denexg21.icgcomm.com> It actually relates to previous discussions re: 2002-5 and 2002-6, (Amnesty and Aggregation Requests). If these policies are ratified and organizations start returning blocks, there would be more swamp from which to allocate. There probably will be issues regarding "cleanliness" of the blocks. Should the Registry require some sort of verification that the blocks have been completely renumbered? Should the Registry refrain from reissuing the blocks for a longer time than one year? Is the growth of the swamp a valid reason to not ratify one or both of these policies? Stacy -----Original Message----- From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] Sent: Tuesday, February 11, 2003 10:34 AM To: ppml at arin.net Subject: RE: [ppml] ppml 2002-7 THANKS!!! But I guess I would have to wonder who had that address before me If I got swamp space... IE SPAMMER FROM ****.... But that is another discussion... J >-----Original Message----- >From: Forrest [mailto:forrest at almighty.c64.org] >Sent: Tuesday, February 11, 2003 1:17 PM >To: ppml at arin.net >Subject: RE: [ppml] ppml 2002-7 > > > > >> Swamp space.. I have only a vague comprehension of this.. >> Can someone elaborate for me? >> >> Thanks, >> Jim >> > >Basically it's the old address space that /24's used to be allocated >directly from ARIN and can't be aggregated today. Just to pick some >random examples. > >192.12.3.0/24 >192.12.4.0/24 >192.12.5.0/24 >... >.. > >Those blocks are all allocated to different organizations and >have to be >announced as individual /24's to be reachable because no >larger aggregate >can be announced. > >Forrest > > From John.Sweeting at teleglobe.com Tue Feb 11 14:22:16 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Tue, 11 Feb 2003 14:22:16 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BDF2@usresms03.teleglobe.com> actually the "swamp" was created before ARIN's time...... -----Original Message----- From: Forrest [mailto:forrest at almighty.c64.org] Sent: Tuesday, February 11, 2003 1:17 PM To: ppml at arin.net Subject: RE: [ppml] ppml 2002-7 > Swamp space.. I have only a vague comprehension of this.. > Can someone elaborate for me? > > Thanks, > Jim > Basically it's the old address space that /24's used to be allocated directly from ARIN and can't be aggregated today. Just to pick some random examples. 192.12.3.0/24 192.12.4.0/24 192.12.5.0/24 ... .. Those blocks are all allocated to different organizations and have to be announced as individual /24's to be reachable because no larger aggregate can be announced. Forrest From steve at rovingplanet.com Tue Feb 11 14:28:28 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Tue, 11 Feb 2003 12:28:28 -0700 Subject: [ppml] ppml 2002-7 Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7702@pluto.rovingplanet.com> > snip To me, it seems that the biggest issue that 2002-7 seems to address is trying to multihome small blocks that aren't located in the old Class C space. It seems that most providers that do filtering, they filter on the old Class boundries. In the old Class C space, they'll accept /24's because of people using old swamp space. So suppose you have block 192.0.0.0/23, your block won't likely get filtered, but suppose you have 12.100.100.0/23, what good is it to multihome if nobody would accept your small route? Basically it makes sense to allocate a specific block just for small organizations that want to multihome, that providers will accept /24's and shorter from (allocate it from the old Class C range and I doubt anyone will have to adjust their filters). I just don't see this causing the routing table to explode in size. What's exploding the routing table is stuff like someone announcing a /18 as 64 /24's (look at 205.145.0.0). Forrest > This is essentially one of my points. The whole idea of aggregating only works well for the provider that "owns" the base block. As an example, there are many /24 that I see from old class A's. They may be aggregated by the base providers but the other providers can't aggregate unless other adjoining bit wise networks are also present. Upstreams can't filter without potentially blackholing traffic (something I have observed more then once much to the chagrin of that provider). So in practice what it comes down to is that the /24 is seen by the world. So I go back. Aggregation can't be an issue. What is the real issue with allowing small (or otherwise) multi-homed organizations to have assigned a single /24 (or even smaller) of their own? It really sounds like the reason to deny is based on address space. Again if the Network/AS pair is being seen by the world anyway why set an arbitrary /24. As was commented already, I have also seen single digit usage of a /24 because the /24 was all that could be announced. Steve From stevek at onshore.com Tue Feb 11 18:03:12 2003 From: stevek at onshore.com (Steve Kent) Date: Tue, 11 Feb 2003 17:03:12 -0600 (CST) Subject: [ppml] ppml 2002-7 In-Reply-To: Message-ID: On Tue, 11 Feb 2003, Forrest wrote: > It seems like a lot of the people announcing /24's are not doing it to > provide redundancy, but rather to load balance between their two circuits. > I can completely understand filtering these /24's, but in the process it > hurts the small organization that wants to multi-home for redundancy but > isn't large enough to qualify for a /20. In reality, the current AKIN > allocation policy actually seems to encourage the wasting of IP address > space just to be able to qualify for a /19, when perhaps only a /22 would > be more than plenty. You only have to look at some of these web hosting > companies to see evidence of wasting IP addresses. I've seen a whole /25 > assigned to ONE single webserver before, even when virtual hosting would > have worked just fine. We deal with a number of clients who have decided to multi-home -- mainly for redundancy. A number of enterprise managers have expressed concerns about the stability of some providers, and thus want to announce their own blocks. I would rather see them given a /24 or /23; otherwise, it is likely they will try to pump their numbers for a /22. This just wastes addresses. > > > > I don't see anything necessarily bad with a new swamp if all of the > addresses in it are used to multihome. It would be silly to assign a /24 > to someone that only connects to one provider, since you could just give > them a /24 from the provider's larger aggregate. If you quit multihoming, > you return your addresses back to the "multihome swamp". This would allow > providers to filter out the useless /24's (like the /18 being announced as > 64 /24's, yet allow them to accept somewhat more important small > multihoming blocks). I agree completely. I would like to see new swamp space make a bit more sense though -- /24s out of a single larger block. This will make filtering and aggregation potentially easier. Networks who cease multi-homing should, of course, be required to give up their block. Perhaps, I am not fully grasping the ramification of this, but I don't see this increasing routing tables more substantially then the current system. Under the current system, for instance, as a small provider I would announce a /19 -- now a customer who wants to multi-home get assigned a /24. Of course that assigned block is out of my /19 announcement -- but the second peer he announces to will only get the /24. That peer would only be able to forward the /24 -- thus no aggregation and an increase in table size. --Steve _____________________________________ Steven Kent Senior Network Engineer onShore, Inc. http://www.onshore.com From jrace at attglobal.net Thu Feb 13 10:25:30 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Thu, 13 Feb 2003 22:25:30 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <200302131525.h1DFPfqn080869@smtp1.arin.net> Interested parties are invited to provide comments to correct, elaborate or perfect my proposal, abstracted below. I'd also welcome suggestions for other fora in which to post requests for comments. I plan to offer as Internet Draft when comments are all in. Comments or objections to the effect "This is going to be burdensome on $spam_enabler" are superfluous because that is the precise intention of the proposed Practice: to move the burden from victims to polluters and their enablers. Thanks for all help. Jeffrey Race BEST CURRENT PRACTICE FOR DUTY OF CARE OF INTERNET RESOURCES Pre-release version 1.31 Draft date: February 13, 2003 Drafted by Jeffrey Race Current draft version (4,000 words) available at ABSTRACT This document defines a Best Current Practice to minimize pollution of the Internet by various types of abuse, using the community's own measures in the absence of effective legal, regulatory and technical measures. The Internet's design and management were predicated on voluntary cooperation, self-imposed good behavior, and the non-profit motivational structure of custodians of Internet Resources extant at its inception. Current experience of constantly rising pollution invalidates these formative assumptions and demands prompt and effective curative measures. Present anti-pollution measures fall under four generic headings: (1) self-directed good behavior; (2) legal sanctions (3) technical measures (principally filtering) and (4) self-help defensive measures (principally blocklisting). The first three have definitively failed and will continue to fail for reasons specified in the document. The fourth is generally completely effective in warding off ingress of pollution and frequently results in reforming abuse enablers, but it has two major shortcomings: limited uptake due to fear of loss of competitive market position by early adopters, and sustained transmission outages ("collateral damage"). In view of the failure of (1), (2) and (3) and the effectiveness despite shortcomings of (4), the document proposes to apply to the Internet the same rules society applies to all other resources to deter antisocial behavior viz. proper behavior requires clear published standards, standards entail accountability, accountability entails multiple modes of enforceability, and enforceability entails traceability. The document details procedures and implementing mechanisms based on this universal rule of human experience, while preserving present levels of anonymity for deserving cases. Since both legal and technical measures have failed and will continue to fail, only the behavior modification method of stopping pollution remains, and the only proven effective method of behavior modification is withdrawal of internet resources of identity and connectivity to continue pollution. Numerous tests have shown this sanction to work equally well against both the wilful and the negligent to halt pollution immediately, where prior efforts at polite persuasion to follow best practice were ignored with impunity. The proposal thus innovates in four respects to halt Internet pollution: (1) It makes explicit that every custodian of internet resources is responsible for preventing emission of pollution (2) Adopting a simultaneous universal practice of withdrawal of internet resources means that no provider will suffer competitive disadvantage (3) The burden of pollution now falls on the polluter and his enabler rather than on the victim, so conforming to the basic principle used everywhere else in society to maintain justice and good order. (4) This Practice legitimates withdrawal of internet resources as the only method proven effective in halting abuse. The Practice is intended to apply at every level of allocation, registration and usage of internet resources including but not limited to RIRs, LIRs, ISPs, webhosting firms, backbone connectivity providers, domain name registrars, and end-users. It defines internet resources, unsolicited bulk electronic messaging, and abuse, and specifies procedures progressively to sanction abuse after a period of public admonishment. In effect, the proposal implements the "user pays" paradigm in a completely new and clever way, without requiring any complicated metering technology all proposals for which have failed on issues of complexity, backward compatibility, absence of adequate hardware, and the need for universal adoption to be effective at all. The document embodies the only set of measures now on offer which will quickly end the spam menace internationally without any new legislation, and with but small and transitory disruption, by moving from the discredited "victim pays" model to the modern "polluting user pays" model, without any metering. Adoption will not only be cost-free for the Internet as a whole but will substantially reduce the current economic burden of abuse. It does this by transferring the economic burden from abuse victims to the polluters and their enablers, which is fair, easily feasible, and indeed the system used everywhere else in society. As such the anticipated vigorous objections to adoption from some parties may be seen in advance as self-serving attempts to perpetuate the discredited "victim pays" model by those now profiting from an environmental polluter business model or by their accessories and enablers. E:\WS\COMPOSE\RFCABST2.TXT From Trevor.Paquette at TeraGo.ca Fri Feb 14 10:22:33 2003 From: Trevor.Paquette at TeraGo.ca (Trevor Paquette) Date: Fri, 14 Feb 2003 08:22:33 -0700 Subject: [ppml] ppml 2002-7 In-Reply-To: Message-ID: <000a01c2d43c$e6431f00$3102a8c0@teraint.net> > be more than plenty. You only have to look at some of these > web hosting > companies to see evidence of wasting IP addresses. I've seen > a whole /25 > assigned to ONE single webserver before, even when virtual > hosting would > have worked just fine. This is the fault of the ISP.. that space should have been pulled back.. does not meet 25% immediate use.. my thought. > I don't see anything necessarily bad with a new swamp if all of the > addresses in it are used to multihome. It would be silly to > assign a /24 > to someone that only connects to one provider, since you The point that people who want it policy to be approved is just opposite that.. they WANT the ability to use their own assigned Class C and go anywhere with it; even if it is only one upstream ISP and even if they only use 3 IPs out of the entire block. They feel that they are being held "hostage" by their ISP; and that renumbering is "too difficult".. guess what.. get over it. 1) If you don't like the charging policy of your ISP, find another. This is a capitalist society, buyer beware and all that. 2) Renumbering happens, deal with it. It's a fact of life and part of working with networks. People change phone numbers.. people can change IPs. LNP (Local Number Portability) with the phone systems allow you to keep your same phone number if you move within the same area code (same ISP Networks); if you move to a different area code you get a new phone number.. (whine whine whine.. I have to change phone numbers.. I have to get new business cards... I have to renumber my phone systems...) Think of changing ISPs as changing area codes.. it happens. Renumbering is part of doing business and should be factored in to your costs of doing business. When we can all finally accept this fact, we'll all be able to get on with our jobs. My opinion is that if this policy is passed, there will be a massive land rush for IP space.. with more then 75% of the IPs be unused. Just folks who want their own space cause they can get it.. and let's not even get into the greymarket reselling of these subnets; it can, does and will happen. > could just give > them a /24 from the provider's larger aggregate. If you quit > multihoming, > you return your addresses back to the "multihome swamp". > This would allow > providers to filter out the useless /24's (like the /18 being > announced as > 64 /24's, yet allow them to accept somewhat more important small > multihoming blocks). > > Forrest Ahh.. see here is the one of the keys to the fault of this policy.. there is no clear reclamation process. The policy is totally without merit until 'exact' criteria is outlined on how you can qualify for space, retain that space on an ongoing timeframe, and how that space is reclaimed. From Trevor.Paquette at TeraGo.ca Fri Feb 14 10:32:49 2003 From: Trevor.Paquette at TeraGo.ca (Trevor Paquette) Date: Fri, 14 Feb 2003 08:32:49 -0700 Subject: [ppml] ppml 2002-7 In-Reply-To: Message-ID: <000b01c2d43e$5598e6e0$3102a8c0@teraint.net> > We deal with a number of clients who have decided to > multi-home -- mainly > for redundancy. A number of enterprise managers have expressed > concerns about the stability of some providers, and thus want > to announce > their own blocks. I would rather see them given a /24 or /23; > otherwise, > it is likely they will try to pump their numbers for a /22. > This just wastes > addresses. And what about the on-going viability of all the companies with their own Class C???? What makes people think they so much more stable then the provider? What happens to the IP space that they have been allocated when they go under? We need to learn from the existing telephone companies.. they have been doing this for YEARS and have way more experience then we do; assigning numbers, dealing with renumbering issues etc.. that is. Do you think that the phone companies would allow for everyone to have their own phone number and be able to take it with them should they move? No.. thought not. Why is that? Think about for a bit. Maybe instead of looking for the 'quick' fix (allow companies their own /24), we should be looking at the 'right' fix (how can we make renumbering a snap). By making renumbering a very easy process, you actually will create a benefit that is more usable to more people then allowing a wholesale 'open season' on getting IP space. From jmcburnett at msmgmt.com Fri Feb 14 10:45:40 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Fri, 14 Feb 2003 10:45:40 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <390E55B947E7C848898AEBB9E50770600EB5E9@msmdcfs01.msmgmt.com> >The point that people who want it policy to be approved is >just opposite that.. they WANT the ability to use their own >assigned Class C and go anywhere with it; even if it is only >one upstream ISP and even if they only use 3 IPs out of the >entire block. For The record: I am trying to get Multihomed, Have 2 ISPs in the building in the router, and 1 ISP would not MH me until I have the Address space Swiped to me. And every policy will have the abusers, >They feel that they are being held "hostage" by their ISP; and >that renumbering is "too difficult".. guess what.. get over it. So is life.... >My opinion is that if this policy is passed, there will be a >massive land rush for IP space.. with more then 75% of the IPs >be unused. Just folks who want their own space cause they can >get it.. and let's not even get into the greymarket reselling >of these subnets; it can, does and will happen. I have a Class C from my upstream, and I can honestly say that 50-60% of it is used.. BUT to Multi-home it has to be a Class C So there is waste. And think about this: A class C subnetted to /30 is also wasteful... I have seen 3 consecutive Class C's subnetted as all /30's HMMM that alone is 50% loss of usable IP's There will be loss.. But that is the system.. If 50 companies want to multihome and they only use 10 IP addresses per company, you are wasting IP addresses, but the policy currently exists that allows this and is justifiable. Too late to comment on that, except to amend it.. > >Ahh.. see here is the one of the keys to the fault of this >policy.. there is no clear reclamation process. The policy is >totally without merit until 'exact' criteria is outlined on >how you can qualify for space, retain that space on an ongoing >timeframe, and how that space is reclaimed. > Reclamation: There are policies in place now for some reclamation but the RIR's are too busy to work on it and they have no enforcement ability. So why stress on reclamation if you can;t enforce it??? Jim From forrest at almighty.c64.org Fri Feb 14 10:55:40 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 14 Feb 2003 09:55:40 -0600 (CST) Subject: [ppml] ppml 2002-7 In-Reply-To: <000a01c2d43c$e6431f00$3102a8c0@teraint.net> Message-ID: On Fri, 14 Feb 2003, Trevor Paquette wrote: > > > I don't see anything necessarily bad with a new swamp if all of the > > addresses in it are used to multihome. It would be silly to > > assign a /24 > > to someone that only connects to one provider, since you > > The point that people who want it policy to be approved is just > opposite that.. they WANT the ability to use their own assigned Class C > and go anywhere with it; even if it is only one upstream ISP and even if > they only use 3 IPs out of the entire block. > > They feel that they are being held "hostage" by their ISP; and that > renumbering is "too difficult".. guess what.. get over it. The way I read proposal 2002-7, it's not suggesting giving a /24 to anyone who asks for it, multihomed or not. I agree, that would be silly and basically creating the same problems that the original /24 allocations caused. The problems I see 2002-7 addressing are the problems a small organization might face when trying to multihome small blocks out of a provider's larger aggregate. It pretty much defeats the purpose of multihoming if nobody will accept your /24 announcement. Sure, if your provider is able to give you a /24 out of the old Class C space, you probably won't have any issues since ISP's that filter seem to do it on the old class boundries. But if you're multihomed, then you're already adding routes to the global routing tables, so what difference does it make on the number of routes whether your /24 is from your provider's aggregate, or from a block assigned to you by ARIN? > Ahh.. see here is the one of the keys to the fault of this policy.. > there is no clear reclamation process. The policy is totally without > merit until 'exact' criteria is outlined on how you can qualify for > space, retain that space on an ongoing timeframe, and how that space is > reclaimed. > > I agree, there definitely would need to be strict requirements to obtain this space, as well as keep it. Perhaps something like having to prove once a year that you are indeed still multihomed and announcing your routes to both upstreams. If you aren't multihomed, your allocation and ASN get revoked. How to go about doing this, that I don't know. Forrest From stevek at onshore.com Fri Feb 14 10:59:35 2003 From: stevek at onshore.com (Steve Kent) Date: Fri, 14 Feb 2003 09:59:35 -0600 (CST) Subject: [ppml] ppml 2002-7 In-Reply-To: <000b01c2d43e$5598e6e0$3102a8c0@teraint.net> Message-ID: On Fri, 14 Feb 2003, Trevor Paquette wrote: > > > We deal with a number of clients who have decided to > > multi-home -- mainly > > for redundancy. A number of enterprise managers have expressed > > concerns about the stability of some providers, and thus want > > to announce > > their own blocks. I would rather see them given a /24 or /23; > > otherwise, > > it is likely they will try to pump their numbers for a /22. > > This just wastes > > addresses. > > And what about the on-going viability of all the companies with their > own Class C???? What makes people think they so much more stable then > the provider? What happens to the IP space that they have been allocated > when they go under? > > We need to learn from the existing telephone companies.. they have been > doing this for YEARS and have way more experience then we do; assigning > numbers, dealing with renumbering issues etc.. that is. > > Do you think that the phone companies would allow for everyone to have > their own phone number and be able to take it with them should they > move? No.. thought not. Why is that? Think about for a bit. In principle, I agree with your sentiments. I, personally, believe any /24 assigned from swamp space should be monitored. If it is not being mutiihomed or exported at all for a period -- of say -- 180 days then the address space should be revoked. Address space is unfortunately not like a phone number -- there is no centralized way to do redirection or update all directories. Re-IPing -- for many enterprises -- is not simple or fast. Most admins will try to avoid it at all costs, and I have seen some pretty silly steps taken by admins to keep a particular block. --steve _____________________________________ Steven Kent Senior Network Engineer onShore, Inc. http://www.onshore.com From jmcburnett at msmgmt.com Fri Feb 14 11:03:35 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Fri, 14 Feb 2003 11:03:35 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <390E55B947E7C848898AEBB9E50770600EB5EA@msmdcfs01.msmgmt.com> >And what about the on-going viability of all the companies >with their own Class C???? What makes people think they so >much more stable then the provider? What happens to the IP >space that they have been allocated when they go under? It seems this is very contradictory to your last post.. YEP, if everyone that multihomed had their own ARIN CLASS C That end user could be more stable than the provider... Case in point: My Company can trace it's root back over 100 years.. One of my providers can go back 6 years. And even went through Chapter 11... Should I be more concerned about them than my company? YES YES YES!!!!!!! >We need to learn from the existing telephone companies.. they >have been doing this for YEARS and have way more experience >then we do; assigning numbers, dealing with renumbering issues >etc.. that is. Having worked for a CLEC and dealing with LECs, I have issue with trusting this experience. I have seen it take 5 days to issue a Phone # and even longer to fix a call routing issue...... Oh and by the way they learned by trial and error.. Will that trial and error apply to IP addressing? Maybe maybe not. Are you willing to bank the stability of the Internet on that? Jon Postel is rolling in his grave over that one..... You do know who Jon is, right? >Do you think that the phone companies would allow for everyone >to have their own phone number and be able to take it with >them should they move? No.. thought not. Why is that? Think >about for a bit. UHH.. this is happening.. In the states local number portability is soon to be extended to even cell phones.... And in the states when Joe moves he can very well keep his # depending on his distance of the move... AND depending on the ISP, I have seen a customer move 700 Miles and keep the same IP addresses... It's all about routing... >Maybe instead of looking for the 'quick' fix (allow companies >their own /24), we should be looking at the 'right' fix (how >can we make renumbering a snap). A quick Fix? No this is about allowing IP's to be issued.. No quick fix was ever mentioned!! Anyway I thought you said in another email: >2) Renumbering happens, deal with it. It's a fact of life and part of working with networks. (DIRECT QUOTE) Why changes your tune now?? >By making renumbering a very easy process, you actually will >create a benefit that is more usable to more people then >allowing a wholesale 'open season' on getting IP space. Getting IP space is not the issue. It is conserving it until v6 comes online...... Confused, Jim From steve at rovingplanet.com Fri Feb 14 11:15:49 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Fri, 14 Feb 2003 09:15:49 -0700 Subject: [ppml] ppml 2002-7 Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7714@pluto.rovingplanet.com> >> We deal with a number of clients who have decided to >> multi-home -- mainly >> for redundancy. A number of enterprise managers have expressed >> concerns about the stability of some providers, and thus want >> to announce >> their own blocks. I would rather see them given a /24 or /23; >> otherwise, >> it is likely they will try to pump their numbers for a /22. >> This just wastes >> addresses. > >And what about the on-going viability of all the companies with their own >Class C???? What makes people think they so much more stable then the >provider? What happens to the IP space that they have been allocated when >they go under? > >We need to learn from the existing telephone companies.. they have been >doing this for YEARS and have way more experience then we do; assigning >numbers, dealing with renumbering issues etc.. that is. > >Do you think that the phone companies would allow for everyone to have >their own phone number and be able to take it with them should they move? >No.. thought not. Why is that? Think about for a bit. > Actually you can. You have to deal with a clec that will do the paperwork (most are happy to). This is a part of the telecommunications act that the ilec's want voided. I wonder why? :) >Maybe instead of looking for the 'quick' fix (allow companies their own >/24), we should be looking at the 'right' fix (how can we make renumbering >a snap). > >By making renumbering a very easy process, you actually will create a >benefit that is more usable to more people then allowing a wholesale 'open >season' on getting IP space. The actual renumbering is only part of the issue. There is the time to get new numbering which differs by providers and time, during which there are potential business losses, there are licensing issues with certain devices like firewalls and so on. These issues can not be addressed by ARIN except by allowing an organization to "own" its IP block. Steve Rolapp From jlewis at lewis.org Fri Feb 14 11:29:04 2003 From: jlewis at lewis.org (jlewis at lewis.org) Date: Fri, 14 Feb 2003 11:29:04 -0500 (EST) Subject: [ppml] ppml 2002-7 In-Reply-To: <000b01c2d43e$5598e6e0$3102a8c0@teraint.net> Message-ID: On Fri, 14 Feb 2003, Trevor Paquette wrote: > Do you think that the phone companies would allow for everyone to have > their own phone number and be able to take it with them should they > move? No.. thought not. Why is that? Think about for a bit. They may not like it, but they are required to allow it. It's called LNP (local number portability) and we take our phone numbers with us when we switch service from one LEC to another. ---------------------------------------------------------------------- Jon Lewis *jlewis at lewis.org*| I route System Administrator | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ahp at hilander.com Fri Feb 14 11:29:33 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 14 Feb 2003 09:29:33 -0700 Subject: [ppml] ppml 2002-7 In-Reply-To: References: Message-ID: <2147483647.1045214973@macleod.hilander.com> --On Friday, February 14, 2003 9:59 -0600 Steve Kent wrote: > > Address space is unfortunately not like a phone number -- there is no > centralized way to do redirection or update all directories. Re-IPing -- > for many enterprises -- is not simple or fast. Most admins will try to > avoid it at all costs, and I have seen some pretty silly steps taken by > admins to keep a particular block. Uhm, I must be confused. Doesn't DNS accomplish this? Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From steve at rovingplanet.com Fri Feb 14 11:40:17 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Fri, 14 Feb 2003 09:40:17 -0700 Subject: [ppml] ppml 2002-7 Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7716@pluto.rovingplanet.com> The issue here is that there are some Apps and configurations that require an IP instead of a host name. Take access filters on a firewall or router as an example. DNS is not a full solution. Steve Rolapp > -----Original Message----- > From: Alec H. Peterson [mailto:ahp at hilander.com] > Sent: Friday, February 14, 2003 9:30 AM > To: Steve Kent; Trevor Paquette > Cc: 'Forrest'; ppml at arin.net > Subject: RE: [ppml] ppml 2002-7 > > --On Friday, February 14, 2003 9:59 -0600 Steve Kent > wrote: > > > > > Address space is unfortunately not like a phone number -- there is no > > centralized way to do redirection or update all directories. Re-IPing -- > > for many enterprises -- is not simple or fast. Most admins will try to > > avoid it at all costs, and I have seen some pretty silly steps taken by > > admins to keep a particular block. > > Uhm, I must be confused. Doesn't DNS accomplish this? > > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com From steve at rovingplanet.com Fri Feb 14 12:09:03 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Fri, 14 Feb 2003 10:09:03 -0700 Subject: No subject Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7717@pluto.rovingplanet.com> The issue of a fixed block size bothers me. I have noted that comments seem to set the lower limit to a /24. For an organization that does not provide hosting services to others, that size should be overkill in a world that requires organizations to have the core network NATed for a sensible security. If you look at the BGP routing tables, you will indeed find /25-/27 out there. Whether an organization pulls a /24 or a /27, its out on the net. Follow the heart of the idea on cidr to this also. Make the organization multi-home with the rule that their AS and block will be revoked if the block is not multihomed for 180 days. Organizations can not be assigned more then one block. Mergers of companies that are each assigned a block must relinquish one in 180 days of the completed merger. Failure to do so voids both blocks and ASs. Multihoming is not cheap. I will get hate mail for this probably but the proposed fees are too low. Make sure that those doing this have the resources to keep it going and ARIN has the resources to take it away. Failure to pay fees in a timely manner are grounds for voiding the space. The issue here shouldn't be whether to do this but instead how to proceed. This is a needed solution that needs to be implemented. Steve Rolapp From steve at rovingplanet.com Fri Feb 14 12:16:10 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Fri, 14 Feb 2003 10:16:10 -0700 Subject: [ppml] ppml 2002-7 Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F4A3D@pluto.rovingplanet.com> My apologies to all for not including the subject. Steve Rolapp > -----Original Message----- > From: Steve Rolapp > Sent: Friday, February 14, 2003 10:09 AM > To: ppml at arin.net > Subject: > > The issue of a fixed block size bothers me. I have noted that comments > seem to set the lower limit to a /24. For an organization that does not > provide hosting services to others, that size should be overkill in a > world that requires organizations to have the core network NATed for a > sensible security. If you look at the BGP routing tables, you will > indeed find /25-/27 out there. Whether an organization pulls a /24 or a > /27, its out on the net. Follow the heart of the idea on cidr to this > also. > > Make the organization multi-home with the rule that their AS and block > will be revoked if the block is not multihomed for 180 days. > > Organizations can not be assigned more then one block. Mergers of > companies that are each assigned a block must relinquish one in 180 days > of the completed merger. Failure to do so voids both blocks and ASs. > > Multihoming is not cheap. I will get hate mail for this probably but > the proposed fees are too low. Make sure that those doing this have the > resources to keep it going and ARIN has the resources to take it away. > Failure to pay fees in a timely manner are grounds for voiding the > space. > > The issue here shouldn't be whether to do this but instead how to > proceed. This is a needed solution that needs to be implemented. > > > Steve Rolapp > > From ron at aol.net Fri Feb 14 12:17:24 2003 From: ron at aol.net (Ron da Silva) Date: Fri, 14 Feb 2003 12:17:24 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <200302131525.h1DFPfqn080869@smtp1.arin.net> References: <200302131525.h1DFPfqn080869@smtp1.arin.net> Message-ID: <20030214171724.GO21907@aol.net> Jeffrey - As this seems to relate to ARIN, On Thu, Feb 13, 2003 at 10:25:30PM +0700, Dr. Jeffrey Race wrote: > > > (1) It makes explicit that every custodian of internet resources is > responsible for preventing emission of pollution > > (2) Adopting a simultaneous universal practice of withdrawal of internet > resources means that no provider will suffer competitive > disadvantage > > (4) This Practice legitimates withdrawal of internet resources as the > only method proven effective in halting abuse. Are you proposing that ARIN revoke certain resources (assignments, allocations, ASNs, etc) under certain conditions to influence certain behaviors (decreasing SPAM propagation)? If so, can you be more exact on which resources and under which conditions? Also, not sure if the revocation of an assignment (for example) necessarily stops an end user from using that assignment. ARIN currently has no method to stop an end user from using space illegitimately. Providers may influence that by the extent that they could refuse to offer transport of bits sourced from that revoked-now-illegitimate assignment, but that is outside the scope of PPML (but certainly worth noting). -ron From jmcburnett at msmgmt.com Fri Feb 14 12:21:27 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Fri, 14 Feb 2003 12:21:27 -0500 Subject: [ppml] RE: Message-ID: <390E55B947E7C848898AEBB9E50770600EB5EB@msmdcfs01.msmgmt.com> >The issue of a fixed block size bothers me. I have noted that comments >seem to set the lower limit to a /24. For an organization >that does not >provide hosting services to others, that size should be overkill in a >world that requires organizations to have the core network NATed for a >sensible security. If you look at the BGP routing tables, you will >indeed find /25-/27 out there. Whether an organization pulls >a /24 or a >/27, its out on the net. Follow the heart of the idea on cidr to this >also. OKay, I agree that a /24 is overkill... BUT some ISPs will filter small blocks I have seen it. CIDR is great, but some filter that too.. >Organizations can not be assigned more then one block. Mergers of >companies that are each assigned a block must relinquish one >in 180 days >of the completed merger. Failure to do so voids both blocks and ASs. This won't work. Company A merges with Company B. Offices in Canada and the US. Large research facility in W city and corp HQ in X City with Manufactuering Plants in Y and Z Cities. If more than 1 office is so critical they need to Multi-home, this would prevent that if they are using /24s or they have to renumber for a /23.... >Multihoming is not cheap. I will get hate mail for this probably but >the proposed fees are too low. Make sure that those doing >this have the >resources to keep it going and ARIN has the resources to take it away. >Failure to pay fees in a timely manner are grounds for voiding the >space. YES, it is not cheap. But the whole point is to make it easier for the small-mid sized companies to multi-home. So you think ARIN and other RIR's should become the finance police in a sense to prevent the fly by night from becoming multi-homed and going under? If a company is that stupid, let em. And then Let ARIN or Other RIR make the money for the extra assignments. Failure to pay is always that way though... Inflation is a bad thing, and competition in the market place to get those high IP "lease" prices lowered at some ISP's is worth a lot.. Why should anyone pay $60 for 5 static IP addresses EVERY MONTH, from X provider? in this case 1 is $40, so most pay the extra $20 and waste IP addresses. Taking it away how ? ARIN can't change a routing table. ARIN would need help from every backbone provider to do this.. Jim >The issue here shouldn't be whether to do this but instead how to >proceed. This is a needed solution that needs to be implemented. > I agree here... We need to discuss all options. Jim From david.conrad at nominum.com Fri Feb 14 13:14:10 2003 From: david.conrad at nominum.com (David Conrad) Date: Fri, 14 Feb 2003 10:14:10 -0800 Subject: [ppml] ppml 2002-7 In-Reply-To: <000b01c2d43e$5598e6e0$3102a8c0@teraint.net> Message-ID: <1D60C87C-4048-11D7-9D66-000393DB42B2@nominum.com> Trevor, On Friday, February 14, 2003, at 07:32 AM, Trevor Paquette wrote: > We need to learn from the existing telephone companies.. they have > been doing this for YEARS and have way more experience then we do; > assigning numbers, dealing with renumbering issues etc.. that is. Recent experiences with area code renumbering and number block size reduction would tend to indicate the telephone companies (in the US at least) had the same philosophy wrt number allocation that the (early) Internet did -- "ask and you shall receive 'cause there are so many numbers, we'll never run out". As with the Internet, this has become a bit of a problem. > Do you think that the phone companies would allow for everyone to have > their own phone number and be able to take it with them should they > move? No.. thought not. As has been indicated LNP does exactly this. And no, the telephone companies aren't particularly excited about it, but they don't have a choice. Government mandates and all that. > Why is that? Think about for a bit. In fact, the implication of LNP is to turn "telephone numbers" into something that looks, smells, and feels like a domain name. > Maybe instead of looking for the 'quick' fix (allow companies their > own /24), we should be looking at the 'right' fix (how can we make > renumbering a snap). > > By making renumbering a very easy process, you actually will create a > benefit that is more usable to more people then allowing a wholesale > 'open season' on getting IP space. Well, yes. Unfortunately, for a variety of reasons, renumbering is viewed as a _very_ difficult problem. Literal IP addresses in routers, ACLs, /etc/hosts (or equivalent), management systems, software "floating licensing" systems, etc. are one aspect of this. The use of IP addresses in transport layer pseudo-header computation are another. There are possible solutions, but they require a non-trivial amount of work and will not happen in the near term. Rgds, -drc (Speaking for myself only) From tme at multicasttech.com Fri Feb 14 13:27:22 2003 From: tme at multicasttech.com (Marshall Eubanks) Date: Fri, 14 Feb 2003 13:27:22 -0500 Subject: [ppml] ppml 2002-7 In-Reply-To: <1D60C87C-4048-11D7-9D66-000393DB42B2@nominum.com> Message-ID: Don't they hand out telephone numbers in minimum blocks of 500 or 1000, and haven't they had to install new area codes in some areas even though the actual usage was fairly low ? Sounds like a similar problem to me. On Friday, February 14, 2003, at 01:14 PM, David Conrad wrote: > Trevor, > > On Friday, February 14, 2003, at 07:32 AM, Trevor Paquette wrote: >> We need to learn from the existing telephone companies.. they have >> been doing this for YEARS and have way more experience then we do; >> assigning numbers, dealing with renumbering issues etc.. that is. > > Recent experiences with area code renumbering and number block size > reduction would tend to indicate the telephone companies (in the US at > least) had the same philosophy wrt number allocation that the (early) > Internet did -- "ask and you shall receive 'cause there are so many > numbers, we'll never run out". As with the Internet, this has become a > bit of a problem. > >> Do you think that the phone companies would allow for everyone to have >> their own phone number and be able to take it with them should they >> move? No.. thought not. > > As has been indicated LNP does exactly this. And no, the telephone > companies aren't particularly excited about it, but they don't have a > choice. Government mandates and all that. > >> Why is that? Think about for a bit. > > In fact, the implication of LNP is to turn "telephone numbers" into > something that looks, smells, and feels like a domain name. > >> Maybe instead of looking for the 'quick' fix (allow companies their >> own /24), we should be looking at the 'right' fix (how can we make >> renumbering a snap). >> >> By making renumbering a very easy process, you actually will create a >> benefit that is more usable to more people then allowing a wholesale >> 'open season' on getting IP space. > > Well, yes. Unfortunately, for a variety of reasons, renumbering is > viewed as a _very_ difficult problem. Literal IP addresses in routers, > ACLs, /etc/hosts (or equivalent), management systems, software > "floating licensing" systems, etc. are one aspect of this. The use of > IP addresses in transport layer pseudo-header computation are another. > There are possible solutions, but they require a non-trivial amount of > work and will not happen in the near term. > > Rgds, > -drc > (Speaking for myself only) > > Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : tme at multicasttech.com http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html From steve at rovingplanet.com Fri Feb 14 13:43:35 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Fri, 14 Feb 2003 11:43:35 -0700 Subject: [ppml] RE: ppml 2007 (was blank) Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7718@pluto.rovingplanet.com> Comments below. Steve Rolapp > -----Original Message----- > From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] > Sent: Friday, February 14, 2003 10:21 AM > To: Steve Rolapp; ppml at arin.net > Subject: RE: > > > >The issue of a fixed block size bothers me. I have noted that comments > >seem to set the lower limit to a /24. For an organization > >that does not > >provide hosting services to others, that size should be overkill in a > >world that requires organizations to have the core network NATed for a > >sensible security. If you look at the BGP routing tables, you will > >indeed find /25-/27 out there. Whether an organization pulls > >a /24 or a > >/27, its out on the net. Follow the heart of the idea on cidr to this > >also. > > OKay, I agree that a /24 is overkill... BUT some ISPs will filter > small blocks I have seen it. CIDR is great, but some filter that too.. This isn't to say that won't happen. Every ISP can make their own decisions but they have to live with those when their customers complain. If it becomes known that an ISP has decided to not listen to these routes and people can't get there, their customers will leave. Competition will drive this. I have personal experience in showing companies that are blackholing routes. It always gets fixed. > >Organizations can not be assigned more then one block. Mergers of > >companies that are each assigned a block must relinquish one > >in 180 days > >of the completed merger. Failure to do so voids both blocks and ASs. > > This won't work. Company A merges with Company B. Offices in Canada and > the US. > Large research facility in W city and corp HQ in X City with > Manufactuering Plants > in Y and Z Cities. If more than 1 office is so critical they need to > Multi-home, > this would prevent that if they are using /24s or they have to renumber > for a > /23.... Lets take the assumption that the merger happened such that A had three of those offices and B had one. If a /24 was the min then A would have needed a /22 leaving an unused /24 for the merger. Lets take the assumption that they each have two offices. This is the sticking point. They each have a /23. As I read 2002-7, an org could have only one block. That means they must give up both unless they can get an a joining block for one of them. Bad news but it's the price of business. I'm not really that cold. This goes back to the issue of block size. Unless these companies are all hosting providers, which precludes them anyway, the address space we are talking about is overkill. Two real issues ensue. Can one of the existing blocks be subnetted to accomidate the needs or has the org grown to the point it needs a bigger address space (an issue without a merger). In both cases there is a forced need to re-architect the IP space. But this really is part of business and it can be managed. The sudden loss of a provider and the IP space from them is not. > >Multihoming is not cheap. I will get hate mail for this probably but > >the proposed fees are too low. Make sure that those doing > >this have the > >resources to keep it going and ARIN has the resources to take it away. > >Failure to pay fees in a timely manner are grounds for voiding the > >space. > YES, it is not cheap. But the whole point is to make it easier for the > small-mid sized companies to multi-home. So you think ARIN and other RIR's > should become the finance police in a sense to prevent the fly by night > from > becoming multi-homed and going under? If a company is that stupid, let em. > And then Let ARIN or Other RIR make the money for the extra assignments. > Failure to pay is always that way though... I am not saying set an artificially high price but ARIN does need to be responsible for getting the space back whether it be with help from the ISP's or the courts. That does have a cost and what was given appeared to not take that into account. > Taking it away how ? ARIN can't change a routing table. > ARIN would need help from every backbone provider to do this.. Agreed. IETF would need to be involved such that part of the next rev of BGP might include valid AS and IP blocks that's fed from the RIR's. I didn't say it could happen over night but instead said lets start working towards it. > > Jim > > > >The issue here shouldn't be whether to do this but instead how to > >proceed. This is a needed solution that needs to be implemented. > > > I agree here... We need to discuss all options. > > Jim From owen at delong.com Fri Feb 14 14:26:46 2003 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Feb 2003 11:26:46 -0800 Subject: [ppml] ppml 2002-7 In-Reply-To: <000a01c2d43c$e6431f00$3102a8c0@teraint.net> References: <000a01c2d43c$e6431f00$3102a8c0@teraint.net> Message-ID: <2147483647.1045222006@imac-en0.delong.sj.ca.us> >> I don't see anything necessarily bad with a new swamp if all of the >> addresses in it are used to multihome. It would be silly to >> assign a /24 >> to someone that only connects to one provider, since you > > The point that people who want it policy to be approved is just opposite > that.. they WANT the ability to use their own assigned Class C and go > anywhere with it; even if it is only one upstream ISP and even if they > only use 3 IPs out of the entire block. > > They feel that they are being held "hostage" by their ISP; and that > renumbering is "too difficult".. guess what.. get over it. > > People change phone numbers.. people can change IPs. LNP (Local Number > Portability) with the phone systems allow you to keep your same phone > number if you move within the same area code (same ISP Networks); if you > move to a different area code you get a new phone number.. (whine whine > whine.. I have to change phone numbers.. I have to get new business > cards... I have to renumber my phone systems...) > NO. LNP allows you to switch phone companies and keep your numbers. If you move to a different geographical location, you may lose LNP. Changing ISPs is like changing phone companies. Not like changing locations. Eventually, we need to come up with a solution for the internet that allows this type of portability. I don't believe the backbone technology available today can support it, but I do believe it needs to happen at some point before we can really call the technology mature. I certainly believe that the analogy above just doesn't work. I haven't read the proposed policy well enough yet to comment on it's merits, but I felt I needed to comment on this analogy separately. > Think of changing ISPs as changing area codes.. it happens. Renumbering > is part of doing business and should be factored in to your costs of > doing business. When we can all finally accept this fact, we'll all be > able to get on with our jobs. > No... Changing ISPs is like changing phone companies. Moving from New York to Tenessee is like changing area codes. Additionally, the assumption that everyone who runs a network is a business is also a fallacy. Some of us run networks in our homes. Some people want to be connected to the internet without being held hostage by some particular ISP. If you had the ability to change power companies, would you consider it acceptable if different power companies had different voltages or frequencies, and every homeowner that switched had to reconfigure all their appliances for the new power company? Owen From owen at delong.com Fri Feb 14 14:44:46 2003 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Feb 2003 11:44:46 -0800 Subject: [ppml] RE: ppml 2007 (was blank) In-Reply-To: <661F9268BBA8CB4EB92CC12B8C42F0690F7718@pluto.rovingplanet.com> References: <661F9268BBA8CB4EB92CC12B8C42F0690F7718@pluto.rovingplanet.com> Message-ID: <2147483647.1045223086@imac-en0.delong.sj.ca.us> Since we're starting to split really fine hairs (hares? poor bunnies)... How do you even plan to identify, let alone enforce the ORG limit, when all the orgs would have to do is simply continue to function/interact with ARIN as multiple ORGs. Heck, under existing policies, one ORG where I worked turned themselves into multiple ARIN customers just to simplify the process of getting the address space they needed for rational localization of IP blocks. How do you expect ARIN to identify that the ORGs should be considered a single ORG. How do you identify a single ORG vs. multiple ORGs. Is a subsidiary an ORG, or does the parent company have to be involved in ALL IP issues for the subsidiary? Would American Airlines be able to get IP space for the airline, or would AMR have to handle all IP space for American, AMR Combs FBOs, and the various oher AMR companies? Sorry, the whole issue of 1 block per ORG just doesn't work out in the long run, because there's no way to identify an ORG. Owen --On Friday, February 14, 2003 11:43 AM -0700 Steve Rolapp wrote: > > Comments below. > > Steve Rolapp > >> -----Original Message----- >> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] >> Sent: Friday, February 14, 2003 10:21 AM >> To: Steve Rolapp; ppml at arin.net >> Subject: RE: >> >> >> > The issue of a fixed block size bothers me. I have noted that > comments >> > seem to set the lower limit to a /24. For an organization >> > that does not >> > provide hosting services to others, that size should be overkill in a >> > world that requires organizations to have the core network NATed for > a >> > sensible security. If you look at the BGP routing tables, you will >> > indeed find /25-/27 out there. Whether an organization pulls >> > a /24 or a >> > /27, its out on the net. Follow the heart of the idea on cidr to > this >> > also. >> >> OKay, I agree that a /24 is overkill... BUT some ISPs will filter >> small blocks I have seen it. CIDR is great, but some filter that > too.. > > This isn't to say that won't happen. Every ISP can make their own > decisions but they have to live with those when their customers > complain. If it becomes known that an ISP has decided to not listen to > these routes and people can't get there, their customers will leave. > Competition will drive this. I have personal experience in showing > companies that are blackholing routes. It always gets fixed. > >> > Organizations can not be assigned more then one block. Mergers of >> > companies that are each assigned a block must relinquish one >> > in 180 days >> > of the completed merger. Failure to do so voids both blocks and ASs. >> >> This won't work. Company A merges with Company B. Offices in Canada > and >> the US. >> Large research facility in W city and corp HQ in X City with >> Manufactuering Plants >> in Y and Z Cities. If more than 1 office is so critical they need to >> Multi-home, >> this would prevent that if they are using /24s or they have to > renumber >> for a >> /23.... > > Lets take the assumption that the merger happened such that A had three > of those offices and B had one. If a /24 was the min then A would have > needed a /22 leaving an unused /24 for the merger. > > Lets take the assumption that they each have two offices. This is the > sticking point. They each have a /23. As I read 2002-7, an org could > have only one block. That means they must give up both unless they can > get an a joining block for one of them. Bad news but it's the price of > business. > > I'm not really that cold. This goes back to the issue of block size. > Unless these companies are all hosting providers, which precludes them > anyway, the address space we are talking about is overkill. Two real > issues ensue. Can one of the existing blocks be subnetted to accomidate > the needs or has the org grown to the point it needs a bigger address > space (an issue without a merger). > > In both cases there is a forced need to re-architect the IP space. But > this really is part of business and it can be managed. The sudden loss > of a provider and the IP space from them is not. > >> > Multihoming is not cheap. I will get hate mail for this probably but >> > the proposed fees are too low. Make sure that those doing >> > this have the >> > resources to keep it going and ARIN has the resources to take it > away. >> > Failure to pay fees in a timely manner are grounds for voiding the >> > space. >> YES, it is not cheap. But the whole point is to make it easier for > the >> small-mid sized companies to multi-home. So you think ARIN and other > RIR's >> should become the finance police in a sense to prevent the fly by > night >> from >> becoming multi-homed and going under? If a company is that stupid, let > em. >> And then Let ARIN or Other RIR make the money for the extra > assignments. >> Failure to pay is always that way though... > > I am not saying set an artificially high price but ARIN does need to be > responsible for getting the space back whether it be with help from the > ISP's or the courts. That does have a cost and what was given appeared > to not take that into account. > >> Taking it away how ? ARIN can't change a routing table. >> ARIN would need help from every backbone provider to do this.. > > Agreed. IETF would need to be involved such that part of the next rev > of BGP might include valid AS and IP blocks that's fed from the RIR's. > I didn't say it could happen over night but instead said lets start > working towards it. >> >> Jim >> >> >> > The issue here shouldn't be whether to do this but instead how to >> > proceed. This is a needed solution that needs to be implemented. >> > >> I agree here... We need to discuss all options. >> >> Jim From steve at rovingplanet.com Fri Feb 14 17:00:44 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Fri, 14 Feb 2003 15:00:44 -0700 Subject: [ppml] RE: ppml 2007 (was blank) Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7719@pluto.rovingplanet.com> The way I understand the proposal was that the purpose was to allow small to medium orgs to be able to get a block assignment if they were multihomed. There was no teeth in the proposal to ensure that those getting the assignment should be allowed and I believe that became one sticking point. Yes, its difficult to ID who is part of another org. While it is difficult to identify who should or should not be classified as multiple orgs, as a CIO or network director, I would not put my company in a position where its connectivity could suddenly be cut because of fraud. What that requires is that the RIR's have to have a mechanism to affect the routing tables (gads!). Should that be tied to whether this moves forward? I don't feel so. But lets do get the issues out there. As I have said before, I really feel this needs to happen. I have been affected and along with others I know. It sounds like a lot of other people commenting on this list feel the same way. Lets start a new thread that lists the issues for and against and start addressing them. Right now a lot of the comments have been in that direction (as has yours). I am new to the list. Is there a moderator and are they/he/she willing to start building a subthreads for each issue? I would really like to see it move forward and would like to hear from the RIR's and ISP's on this also. I'll throw what I think are the issues so far: Aggregation Block sizes IP address pool Swamp use Reallocations Org qualification Multihoming Company size RIR administration Policing Thanks, Steve Rolapp > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Friday, February 14, 2003 12:45 PM > To: Steve Rolapp; ppml at arin.net > Subject: Re: [ppml] RE: ppml 2007 (was blank) > > Since we're starting to split really fine hairs (hares? poor bunnies)... > > How do you even plan to identify, let alone enforce the ORG limit, when > all the orgs would have to do is simply continue to function/interact > with ARIN as multiple ORGs. Heck, under existing policies, one ORG > where I worked turned themselves into multiple ARIN customers just to > simplify the process of getting the address space they needed for rational > localization of IP blocks. How do you expect ARIN to identify that the > ORGs should be considered a single ORG. How do you identify a single > ORG vs. multiple ORGs. Is a subsidiary an ORG, or does the parent company > have to be involved in ALL IP issues for the subsidiary? Would American > Airlines be able to get IP space for the airline, or would AMR have to > handle all IP space for American, AMR Combs FBOs, and the various oher > AMR companies? Sorry, the whole issue of 1 block per ORG just doesn't > work out in the long run, because there's no way to identify an ORG. > > Owen > > > --On Friday, February 14, 2003 11:43 AM -0700 Steve Rolapp > wrote: > > > > > Comments below. > > > > Steve Rolapp > > > >> -----Original Message----- > >> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] > >> Sent: Friday, February 14, 2003 10:21 AM > >> To: Steve Rolapp; ppml at arin.net > >> Subject: RE: > >> > >> > >> > The issue of a fixed block size bothers me. I have noted that > > comments > >> > seem to set the lower limit to a /24. For an organization > >> > that does not > >> > provide hosting services to others, that size should be overkill in a > >> > world that requires organizations to have the core network NATed for > > a > >> > sensible security. If you look at the BGP routing tables, you will > >> > indeed find /25-/27 out there. Whether an organization pulls > >> > a /24 or a > >> > /27, its out on the net. Follow the heart of the idea on cidr to > > this > >> > also. > >> > >> OKay, I agree that a /24 is overkill... BUT some ISPs will filter > >> small blocks I have seen it. CIDR is great, but some filter that > > too.. > > > > This isn't to say that won't happen. Every ISP can make their own > > decisions but they have to live with those when their customers > > complain. If it becomes known that an ISP has decided to not listen to > > these routes and people can't get there, their customers will leave. > > Competition will drive this. I have personal experience in showing > > companies that are blackholing routes. It always gets fixed. > > > >> > Organizations can not be assigned more then one block. Mergers of > >> > companies that are each assigned a block must relinquish one > >> > in 180 days > >> > of the completed merger. Failure to do so voids both blocks and ASs. > >> > >> This won't work. Company A merges with Company B. Offices in Canada > > and > >> the US. > >> Large research facility in W city and corp HQ in X City with > >> Manufactuering Plants > >> in Y and Z Cities. If more than 1 office is so critical they need to > >> Multi-home, > >> this would prevent that if they are using /24s or they have to > > renumber > >> for a > >> /23.... > > > > Lets take the assumption that the merger happened such that A had three > > of those offices and B had one. If a /24 was the min then A would have > > needed a /22 leaving an unused /24 for the merger. > > > > Lets take the assumption that they each have two offices. This is the > > sticking point. They each have a /23. As I read 2002-7, an org could > > have only one block. That means they must give up both unless they can > > get an a joining block for one of them. Bad news but it's the price of > > business. > > > > I'm not really that cold. This goes back to the issue of block size. > > Unless these companies are all hosting providers, which precludes them > > anyway, the address space we are talking about is overkill. Two real > > issues ensue. Can one of the existing blocks be subnetted to accomidate > > the needs or has the org grown to the point it needs a bigger address > > space (an issue without a merger). > > > > In both cases there is a forced need to re-architect the IP space. But > > this really is part of business and it can be managed. The sudden loss > > of a provider and the IP space from them is not. > > > >> > Multihoming is not cheap. I will get hate mail for this probably but > >> > the proposed fees are too low. Make sure that those doing > >> > this have the > >> > resources to keep it going and ARIN has the resources to take it > > away. > >> > Failure to pay fees in a timely manner are grounds for voiding the > >> > space. > >> YES, it is not cheap. But the whole point is to make it easier for > > the > >> small-mid sized companies to multi-home. So you think ARIN and other > > RIR's > >> should become the finance police in a sense to prevent the fly by > > night > >> from > >> becoming multi-homed and going under? If a company is that stupid, let > > em. > >> And then Let ARIN or Other RIR make the money for the extra > > assignments. > >> Failure to pay is always that way though... > > > > I am not saying set an artificially high price but ARIN does need to be > > responsible for getting the space back whether it be with help from the > > ISP's or the courts. That does have a cost and what was given appeared > > to not take that into account. > > > >> Taking it away how ? ARIN can't change a routing table. > >> ARIN would need help from every backbone provider to do this.. > > > > Agreed. IETF would need to be involved such that part of the next rev > > of BGP might include valid AS and IP blocks that's fed from the RIR's. > > I didn't say it could happen over night but instead said lets start > > working towards it. > >> > >> Jim > >> > >> > >> > The issue here shouldn't be whether to do this but instead how to > >> > proceed. This is a needed solution that needs to be implemented. > >> > > >> I agree here... We need to discuss all options. > >> > >> Jim > From william at elan.net Fri Feb 14 15:08:46 2003 From: william at elan.net (william at elan.net) Date: Fri, 14 Feb 2003 12:08:46 -0800 (PST) Subject: [ppml] ppml 2002-7 In-Reply-To: Message-ID: What do you think about doing this different then what is in 2002-7 and instead of lowering minimimum allocation/assignment and having company become new full member, doing this with special policy and special associate membership. We can do it so that to get this membership company would need to have two ARIN full members sponsor it (i.e. its two upstreams) and would not be able to go directly to ARIN but would need to have one of sponsors come to ARIN and request this ip block on their behalf. This has the following advantages over current proposal: 1. ARIN is not put in the position of having to verify multihoming, having two sponsors makes sure of that. 2. Presumably existing arin members would filter out some companies that really do not need this separate ip block and make sure and make sure that some technical requirements exist for the assignment. 3. It is still possible for company that got this associative membership to move to another isp and keep the ip block, but they would need to make sure their new isp is willing to sponsor them. 4. ARIN has records on who sponsors are and in case of billing problems or if it receives reports that address or some other whois info is not kept up to date, it can ask for assistance of their sponsors to get in touch with right people. I do realize this would be kind of compromise and it would not be as easy to get small ip block as some would like but on the other hand I believe some of the current proponents (like large ISPs who are worried about loosing control of ip assignments) may support this and it might be good as compromise between different positions. Please comment on above and if you think this is a good idea, I'll write up official proposal. ---- William Leibzon Elan Communications william at elan.net From steve at rovingplanet.com Fri Feb 14 17:47:04 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Fri, 14 Feb 2003 15:47:04 -0700 Subject: [ppml] ppml 2002-7 Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F4A41@pluto.rovingplanet.com> This sounds like a positive proposal. This has some addition benefits. 5. In the event an org discontinues service, the ISP can notify ARIN. In the event the org does not get a new sponsor, ARIN can notify the other sponsor that the assignment is no longer valid. This should take care of the issue some have that an org could get an assignment and then stop multihoming. 6. I disagree that getting small IP blocks is hampered by this. The sponsors would have to agree to announce the block and the block could be smaller then a /24 thus conserving the address pool. Since the block may not be contiguous with other blocks, there is no aggregation possible and both sponsors would be announcing the block to the world. An issue is that ISPs would have to agree to this. But if there can be a financial benefit to them then of course they would do it. Some would sign on to gain the competitive advantage and the others would probably follow. Steve Rolapp > -----Original Message----- > From: william at elan.net [mailto:william at elan.net] > Sent: Friday, February 14, 2003 1:09 PM > To: ppml at arin.net > Subject: Re: [ppml] ppml 2002-7 > > What do you think about doing this different then what is in 2002-7 and > instead of lowering minimimum allocation/assignment and having company > become new full member, doing this with special policy and special > associate membership. We can do it so that to get this membership company > would need to have two ARIN full members sponsor it (i.e. its two > upstreams) and would not be able to go directly to ARIN but would need to > have one of sponsors come to ARIN and request this ip block on their > behalf. This has the following advantages over current proposal: > 1. ARIN is not put in the position of having to verify multihoming, > having two sponsors makes sure of that. > 2. Presumably existing arin members would filter out some companies that > really do not need this separate ip block and make sure and make sure > that some technical requirements exist for the assignment. > 3. It is still possible for company that got this associative membership > to move to another isp and keep the ip block, but they would need to > make sure their new isp is willing to sponsor them. > 4. ARIN has records on who sponsors are and in case of billing problems > or if it receives reports that address or some other whois info is not > kept up to date, it can ask for assistance of their sponsors to get in > touch with right people. > > I do realize this would be kind of compromise and it would not be as easy > to get small ip block as some would like but on the other hand I believe > some of the current proponents (like large ISPs who are worried about > loosing control of ip assignments) may support this and it might be > good as compromise between different positions. > > Please comment on above and if you think this is a good idea, I'll write > up official proposal. > > ---- > William Leibzon > Elan Communications > william at elan.net From jmcburnett at msmgmt.com Fri Feb 14 19:02:26 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Fri, 14 Feb 2003 19:02:26 -0500 Subject: [ppml] RE: ppml 2007 (was blank) Message-ID: <390E55B947E7C848898AEBB9E50770600EB5EE@msmdcfs01.msmgmt.com> > > The way I understand the proposal was that the purpose was to allow > small to medium orgs to be able to get a block assignment if they were > multihomed. There was no teeth in the proposal to ensure that those > getting the assignment should be allowed and I believe that became one > sticking point. This is done. 2001-2 gives me the ARIN approval to have a Class C- This is how I got my Class C. > Yes, its difficult to ID who is part of another org. While it is > difficult to identify who should or should not be classified > as multiple > orgs, as a CIO or network director, I would not put my company in a > position where its connectivity could suddenly be cut because > of fraud. HMM I know an ISP with at least 3 ORG IDs.. > What that requires is that the RIR's have to have a mechanism > to affect > the routing tables (gads!). Should that be tied to whether this moves > forward? I don't feel so. But lets do get the issues out > there. As I > have said before, I really feel this needs to happen. I have been > affected and along with others I know. It sounds like a lot of other > people commenting on this list feel the same way. This is a topic that has been covered to such a high degree many of us, just give up.. > Lets start a new thread that lists the issues for and against > and start > addressing them. Right now a lot of the comments have been in that > direction (as has yours). I am new to the list. Is there a moderator > and are they/he/she willing to start building a subthreads for each > issue? I would really like to see it move forward and would like to > hear from the RIR's and ISP's on this also. No real moderator, That I have ever noticed.. Start the thread with a topic whenever you feel. If it touches a thread in someone it will continue.. > I'll throw what I think are the issues so far: > > Aggregation > Block sizes > IP address pool > Swamp use > Reallocations > Org qualification > Multihoming > Company size > RIR administration > Policing Steve-- Check this out: http://www.arin.net/policy/2001_2.html Some of those issues are too big enough for a single thread. J > > Thanks, > > Steve Rolapp > > > -----Original Message----- > > From: Owen DeLong [mailto:owen at delong.com] > > Sent: Friday, February 14, 2003 12:45 PM > > To: Steve Rolapp; ppml at arin.net > > Subject: Re: [ppml] RE: ppml 2007 (was blank) > > > > Since we're starting to split really fine hairs (hares? poor > bunnies)... > > > > How do you even plan to identify, let alone enforce the ORG limit, > when > > all the orgs would have to do is simply continue to > function/interact > > with ARIN as multiple ORGs. Heck, under existing policies, one ORG > > where I worked turned themselves into multiple ARIN > customers just to > > simplify the process of getting the address space they needed for > rational > > localization of IP blocks. How do you expect ARIN to identify that > the > > ORGs should be considered a single ORG. How do you > identify a single > > ORG vs. multiple ORGs. Is a subsidiary an ORG, or does the parent > company > > have to be involved in ALL IP issues for the subsidiary? Would > American > > Airlines be able to get IP space for the airline, or would > AMR have to > > handle all IP space for American, AMR Combs FBOs, and the > various oher > > AMR companies? Sorry, the whole issue of 1 block per ORG > just doesn't > > work out in the long run, because there's no way to identify an ORG. > > > > Owen > > > > > > --On Friday, February 14, 2003 11:43 AM -0700 Steve Rolapp > > wrote: > > > > > > > > Comments below. > > > > > > Steve Rolapp > > > > > >> -----Original Message----- > > >> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] > > >> Sent: Friday, February 14, 2003 10:21 AM > > >> To: Steve Rolapp; ppml at arin.net > > >> Subject: RE: > > >> > > >> > > >> > The issue of a fixed block size bothers me. I have noted that > > > comments > > >> > seem to set the lower limit to a /24. For an organization > > >> > that does not > > >> > provide hosting services to others, that size should > be overkill > in a > > >> > world that requires organizations to have the core > network NATed > for > > > a > > >> > sensible security. If you look at the BGP routing tables, you > will > > >> > indeed find /25-/27 out there. Whether an organization pulls > > >> > a /24 or a > > >> > /27, its out on the net. Follow the heart of the idea > on cidr to > > > this > > >> > also. > > >> > > >> OKay, I agree that a /24 is overkill... BUT some ISPs will filter > > >> small blocks I have seen it. CIDR is great, but some filter that > > > too.. > > > > > > This isn't to say that won't happen. Every ISP can make their own > > > decisions but they have to live with those when their customers > > > complain. If it becomes known that an ISP has decided to > not listen > to > > > these routes and people can't get there, their customers > will leave. > > > Competition will drive this. I have personal experience > in showing > > > companies that are blackholing routes. It always gets fixed. > > > > > >> > Organizations can not be assigned more then one block. Mergers > of > > >> > companies that are each assigned a block must relinquish one > > >> > in 180 days > > >> > of the completed merger. Failure to do so voids both > blocks and > ASs. > > >> > > >> This won't work. Company A merges with Company B. Offices in > Canada > > > and > > >> the US. > > >> Large research facility in W city and corp HQ in X City with > > >> Manufactuering Plants > > >> in Y and Z Cities. If more than 1 office is so critical they need > to > > >> Multi-home, > > >> this would prevent that if they are using /24s or they have to > > > renumber > > >> for a > > >> /23.... > > > > > > Lets take the assumption that the merger happened such that A had > three > > > of those offices and B had one. If a /24 was the min then A would > have > > > needed a /22 leaving an unused /24 for the merger. > > > > > > Lets take the assumption that they each have two offices. This is > the > > > sticking point. They each have a /23. As I read 2002-7, an org > could > > > have only one block. That means they must give up both > unless they > can > > > get an a joining block for one of them. Bad news but > it's the price > of > > > business. > > > > > > I'm not really that cold. This goes back to the issue of block > size. > > > Unless these companies are all hosting providers, which precludes > them > > > anyway, the address space we are talking about is overkill. Two > real > > > issues ensue. Can one of the existing blocks be subnetted to > accomidate > > > the needs or has the org grown to the point it needs a bigger > address > > > space (an issue without a merger). > > > > > > In both cases there is a forced need to re-architect the IP space. > But > > > this really is part of business and it can be managed. The sudden > loss > > > of a provider and the IP space from them is not. > > > > > >> > Multihoming is not cheap. I will get hate mail for > this probably > but > > >> > the proposed fees are too low. Make sure that those doing > > >> > this have the > > >> > resources to keep it going and ARIN has the resources > to take it > > > away. > > >> > Failure to pay fees in a timely manner are grounds for voiding > the > > >> > space. > > >> YES, it is not cheap. But the whole point is to make it > easier for > > > the > > >> small-mid sized companies to multi-home. So you think ARIN and > other > > > RIR's > > >> should become the finance police in a sense to prevent the fly by > > > night > > >> from > > >> becoming multi-homed and going under? If a company is > that stupid, > let > > > em. > > >> And then Let ARIN or Other RIR make the money for the extra > > > assignments. > > >> Failure to pay is always that way though... > > > > > > I am not saying set an artificially high price but ARIN > does need to > be > > > responsible for getting the space back whether it be with > help from > the > > > ISP's or the courts. That does have a cost and what was given > appeared > > > to not take that into account. > > > > > >> Taking it away how ? ARIN can't change a routing table. > > >> ARIN would need help from every backbone provider to do this.. > > > > > > Agreed. IETF would need to be involved such that part of the next > rev > > > of BGP might include valid AS and IP blocks that's fed from the > RIR's. > > > I didn't say it could happen over night but instead said > lets start > > > working towards it. > > >> > > >> Jim > > >> > > >> > > >> > The issue here shouldn't be whether to do this but > instead how to > > >> > proceed. This is a needed solution that needs to be > implemented. > > >> > > > >> I agree here... We need to discuss all options. > > >> > > >> Jim > > > > From jmcburnett at msmgmt.com Fri Feb 14 19:34:20 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Fri, 14 Feb 2003 19:34:20 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <390E55B947E7C848898AEBB9E50770600EB5EF@msmdcfs01.msmgmt.com> First, I do like the way this sounds. BUT, I have some concerns. see inline.. > What do you think about doing this different then what is in > 2002-7 and > instead of lowering minimimum allocation/assignment and > having company > become new full member, doing this with special policy and special > associate membership. We can do it so that to get this > membership company > would need to have two ARIN full members sponsor it (i.e. its two > upstreams) It took me nearly a month to get the right people at one provider to agree they would multi-home. How long would it take to get 2 providers to agree to this. I am sure we have some IP Admin's from large ISP's on here.. COMMENTS?? > 1. ARIN is not put in the position of having to verify multihoming, > having two sponsors makes sure of that. Have you ever filled out an ASN request? If no, take a look at the form. You have to have two peer ASNs to properly mult-home. Sure an upstream may let send them a private, but...... > 2. Presumably existing arin members would filter out some > companies that > really do not need this separate ip block and make sure and > make sure > that some technical requirements exist for the assignment. yea, and are these the same folks that should make sure X user does not get 128 IP addresses to host 38 domain webpages? > 3. It is still possible for company that got this > associative membership > to move to another isp and keep the ip block, but they > would need to > make sure their new isp is willing to sponsor them. This could fall back to the same kinds of diffuculty. The policy would only work if ALL ISP's played well togather... > 4. ARIN has records on who sponsors are and in case of > billing problems > or if it receives reports that address or some other whois > info is not > kept up to date, it can ask for assistance of their > sponsors to get in > touch with right people. This is really good. If I don't know how to contact a customer I send a bill to every month, boy would that be dumb.. Just as long as the ISP plays well.. You might learn a little about pain in the rear ISPs on the SPAM-L list... ISPs that are a haven for SPAMMERS, careless about blacklists, so they may care even less on this.. Bottom line is: UNTIL ARIN gets some real abilities to slap penalties of some kind on ISPs and end users, a lot of people won't care.. > I do realize this would be kind of compromise and it would > not be as easy > to get small ip block as some would like but on the other > hand I believe > some of the current proponents (like large ISPs who are worried about > loosing control of ip assignments) may support this and it might be > good as compromise between different positions. > > Please comment on above and if you think this is a good idea, > I'll write > up official proposal. Overall, I like this..especially #4.. Don't take me as overly critical, I am just trying to cover every base.. And no I am not that rententive, just to much time justifing all I do... later, j From owen at delong.com Sat Feb 15 12:27:48 2003 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Feb 2003 09:27:48 -0800 Subject: [ppml] RE: ppml 2007 (was blank) In-Reply-To: <661F9268BBA8CB4EB92CC12B8C42F0690F7719@pluto.rovingplanet.com> References: <661F9268BBA8CB4EB92CC12B8C42F0690F7719@pluto.rovingplanet.com> Message-ID: <2147483647.1045301268@imac-en0.delong.sj.ca.us> I think you missed my point. As an example... Does the CIO of American Airlines consider American Airlines an ORG, or does he need to consider that AMR is the ORG and go to them? The whole idea of an "ORG" is so ambiguous that using it as a limiting factor in a policy seems absurd. Not because it is unenforceable, but because noone can figure out how to comply. Owen --On Friday, February 14, 2003 3:00 PM -0700 Steve Rolapp wrote: > The way I understand the proposal was that the purpose was to allow > small to medium orgs to be able to get a block assignment if they were > multihomed. There was no teeth in the proposal to ensure that those > getting the assignment should be allowed and I believe that became one > sticking point. > > Yes, its difficult to ID who is part of another org. While it is > difficult to identify who should or should not be classified as multiple > orgs, as a CIO or network director, I would not put my company in a > position where its connectivity could suddenly be cut because of fraud. > > > What that requires is that the RIR's have to have a mechanism to affect > the routing tables (gads!). Should that be tied to whether this moves > forward? I don't feel so. But lets do get the issues out there. As I > have said before, I really feel this needs to happen. I have been > affected and along with others I know. It sounds like a lot of other > people commenting on this list feel the same way. > > Lets start a new thread that lists the issues for and against and start > addressing them. Right now a lot of the comments have been in that > direction (as has yours). I am new to the list. Is there a moderator > and are they/he/she willing to start building a subthreads for each > issue? I would really like to see it move forward and would like to > hear from the RIR's and ISP's on this also. > > I'll throw what I think are the issues so far: > > Aggregation > Block sizes > IP address pool > Swamp use > Reallocations > Org qualification > Multihoming > Company size > RIR administration > Policing > > > Thanks, > > Steve Rolapp > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Friday, February 14, 2003 12:45 PM >> To: Steve Rolapp; ppml at arin.net >> Subject: Re: [ppml] RE: ppml 2007 (was blank) >> >> Since we're starting to split really fine hairs (hares? poor > bunnies)... >> >> How do you even plan to identify, let alone enforce the ORG limit, > when >> all the orgs would have to do is simply continue to function/interact >> with ARIN as multiple ORGs. Heck, under existing policies, one ORG >> where I worked turned themselves into multiple ARIN customers just to >> simplify the process of getting the address space they needed for > rational >> localization of IP blocks. How do you expect ARIN to identify that > the >> ORGs should be considered a single ORG. How do you identify a single >> ORG vs. multiple ORGs. Is a subsidiary an ORG, or does the parent > company >> have to be involved in ALL IP issues for the subsidiary? Would > American >> Airlines be able to get IP space for the airline, or would AMR have to >> handle all IP space for American, AMR Combs FBOs, and the various oher >> AMR companies? Sorry, the whole issue of 1 block per ORG just doesn't >> work out in the long run, because there's no way to identify an ORG. >> >> Owen >> >> >> --On Friday, February 14, 2003 11:43 AM -0700 Steve Rolapp >> wrote: >> >> > >> > Comments below. >> > >> > Steve Rolapp >> > >> >> -----Original Message----- >> >> From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] >> >> Sent: Friday, February 14, 2003 10:21 AM >> >> To: Steve Rolapp; ppml at arin.net >> >> Subject: RE: >> >> >> >> >> >> > The issue of a fixed block size bothers me. I have noted that >> > comments >> >> > seem to set the lower limit to a /24. For an organization >> >> > that does not >> >> > provide hosting services to others, that size should be overkill > in a >> >> > world that requires organizations to have the core network NATed > for >> > a >> >> > sensible security. If you look at the BGP routing tables, you > will >> >> > indeed find /25-/27 out there. Whether an organization pulls >> >> > a /24 or a >> >> > /27, its out on the net. Follow the heart of the idea on cidr to >> > this >> >> > also. >> >> >> >> OKay, I agree that a /24 is overkill... BUT some ISPs will filter >> >> small blocks I have seen it. CIDR is great, but some filter that >> > too.. >> > >> > This isn't to say that won't happen. Every ISP can make their own >> > decisions but they have to live with those when their customers >> > complain. If it becomes known that an ISP has decided to not listen > to >> > these routes and people can't get there, their customers will leave. >> > Competition will drive this. I have personal experience in showing >> > companies that are blackholing routes. It always gets fixed. >> > >> >> > Organizations can not be assigned more then one block. Mergers > of >> >> > companies that are each assigned a block must relinquish one >> >> > in 180 days >> >> > of the completed merger. Failure to do so voids both blocks and > ASs. >> >> >> >> This won't work. Company A merges with Company B. Offices in > Canada >> > and >> >> the US. >> >> Large research facility in W city and corp HQ in X City with >> >> Manufactuering Plants >> >> in Y and Z Cities. If more than 1 office is so critical they need > to >> >> Multi-home, >> >> this would prevent that if they are using /24s or they have to >> > renumber >> >> for a >> >> /23.... >> > >> > Lets take the assumption that the merger happened such that A had > three >> > of those offices and B had one. If a /24 was the min then A would > have >> > needed a /22 leaving an unused /24 for the merger. >> > >> > Lets take the assumption that they each have two offices. This is > the >> > sticking point. They each have a /23. As I read 2002-7, an org > could >> > have only one block. That means they must give up both unless they > can >> > get an a joining block for one of them. Bad news but it's the price > of >> > business. >> > >> > I'm not really that cold. This goes back to the issue of block > size. >> > Unless these companies are all hosting providers, which precludes > them >> > anyway, the address space we are talking about is overkill. Two > real >> > issues ensue. Can one of the existing blocks be subnetted to > accomidate >> > the needs or has the org grown to the point it needs a bigger > address >> > space (an issue without a merger). >> > >> > In both cases there is a forced need to re-architect the IP space. > But >> > this really is part of business and it can be managed. The sudden > loss >> > of a provider and the IP space from them is not. >> > >> >> > Multihoming is not cheap. I will get hate mail for this probably > but >> >> > the proposed fees are too low. Make sure that those doing >> >> > this have the >> >> > resources to keep it going and ARIN has the resources to take it >> > away. >> >> > Failure to pay fees in a timely manner are grounds for voiding > the >> >> > space. >> >> YES, it is not cheap. But the whole point is to make it easier for >> > the >> >> small-mid sized companies to multi-home. So you think ARIN and > other >> > RIR's >> >> should become the finance police in a sense to prevent the fly by >> > night >> >> from >> >> becoming multi-homed and going under? If a company is that stupid, > let >> > em. >> >> And then Let ARIN or Other RIR make the money for the extra >> > assignments. >> >> Failure to pay is always that way though... >> > >> > I am not saying set an artificially high price but ARIN does need to > be >> > responsible for getting the space back whether it be with help from > the >> > ISP's or the courts. That does have a cost and what was given > appeared >> > to not take that into account. >> > >> >> Taking it away how ? ARIN can't change a routing table. >> >> ARIN would need help from every backbone provider to do this.. >> > >> > Agreed. IETF would need to be involved such that part of the next > rev >> > of BGP might include valid AS and IP blocks that's fed from the > RIR's. >> > I didn't say it could happen over night but instead said lets start >> > working towards it. >> >> >> >> Jim >> >> >> >> >> >> > The issue here shouldn't be whether to do this but instead how to >> >> > proceed. This is a needed solution that needs to be implemented. >> >> > >> >> I agree here... We need to discuss all options. >> >> >> >> Jim >> > From owen at delong.com Sat Feb 15 12:30:09 2003 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Feb 2003 09:30:09 -0800 Subject: [ppml] ppml 2002-7 In-Reply-To: References: Message-ID: <2147483647.1045301409@imac-en0.delong.sj.ca.us> Although I think this facilitates abuse by the ISPs, I think it's a better compromise than what is currently proposed. There should, however, be some form of process included for redress of abuse by ISP so that people trying to get sponsored have some recourse if their ISP won't sponsor them other than finding another ISP. Owen --On Friday, February 14, 2003 12:08 PM -0800 william at elan.net wrote: > What do you think about doing this different then what is in 2002-7 and > instead of lowering minimimum allocation/assignment and having company > become new full member, doing this with special policy and special > associate membership. We can do it so that to get this membership company > would need to have two ARIN full members sponsor it (i.e. its two > upstreams) and would not be able to go directly to ARIN but would need to > have one of sponsors come to ARIN and request this ip block on their > behalf. This has the following advantages over current proposal: > 1. ARIN is not put in the position of having to verify multihoming, > having two sponsors makes sure of that. > 2. Presumably existing arin members would filter out some companies > that really do not need this separate ip block and make sure and make > sure that some technical requirements exist for the assignment. > 3. It is still possible for company that got this associative > membership to move to another isp and keep the ip block, but they > would need to make sure their new isp is willing to sponsor them. > 4. ARIN has records on who sponsors are and in case of billing problems > or if it receives reports that address or some other whois info is not > kept up to date, it can ask for assistance of their sponsors to get in > touch with right people. > > I do realize this would be kind of compromise and it would not be as easy > to get small ip block as some would like but on the other hand I believe > some of the current proponents (like large ISPs who are worried about > loosing control of ip assignments) may support this and it might be > good as compromise between different positions. > > Please comment on above and if you think this is a good idea, I'll write > up official proposal. > > ---- > William Leibzon > Elan Communications > william at elan.net > From owen at delong.com Sat Feb 15 12:38:40 2003 From: owen at delong.com (Owen DeLong) Date: Sat, 15 Feb 2003 09:38:40 -0800 Subject: [ppml] ppml 2002-7 In-Reply-To: <390E55B947E7C848898AEBB9E50770600EB5EF@msmdcfs01.msmgmt.com> References: <390E55B947E7C848898AEBB9E50770600EB5EF@msmdcfs01.msmgmt.com> Message-ID: <2147483647.1045301920@imac-en0.delong.sj.ca.us> --On Friday, February 14, 2003 7:34 PM -0500 "McBurnett, Jim" wrote: > First, I do like the way this sounds. BUT, I have some concerns. > see inline.. >> What do you think about doing this different then what is in >> 2002-7 and >> instead of lowering minimimum allocation/assignment and >> having company >> become new full member, doing this with special policy and special >> associate membership. We can do it so that to get this >> membership company >> would need to have two ARIN full members sponsor it (i.e. its two >> upstreams) > It took me nearly a month to get the right people at one provider > to agree they would multi-home. How long would it take to get 2 > providers to agree to this. I am sure we have some IP Admin's from large > ISP's on here.. COMMENTS?? > In my experience, it will take less time if there is a standardized method of handling it available from ARIN than if it's a matter of getting two ISPs to agree to work together with you. This would provide that solution. >> 3. It is still possible for company that got this >> associative membership >> to move to another isp and keep the ip block, but they >> would need to >> make sure their new isp is willing to sponsor them. > This could fall back to the same kinds of diffuculty. > The policy would only work if ALL ISP's played well togather... > In my experience, if ARIN adopts a policy, the ISPs will try to work with it unless it is going to melt their network. The concern here would be the route table growth possibly creating a flood of new prefixes that would overwhelm the default-free zone. I think the proposal in question is unlikely to have that result, and, I think most of the backbones would play fair until it became a problem. > This is really good. If I don't know how to contact a customer I > send a bill to every month, boy would that be dumb.. > Just as long as the ISP plays well.. You might learn a little about > pain in the rear ISPs on the SPAM-L list... ISPs that are a haven for > SPAMMERS, careless about blacklists, so they may care even less on > this.. Maybe the way to solve this is to have ARIN bill 1/2 of the members annual fee to each of the two sponsors. The sponsors are expected to bill the member for that. That way, if the sponsor doesn't keep getting the money from the member, they have a financial incentive to inform ARIN that the member is unpaid. > Bottom line is: UNTIL ARIN gets some real abilities to slap > penalties of some kind on ISPs and end users, a lot of people > won't care.. > > I think my paragraph above sort of addresses this particular situation. Owen From jmcburnett at msmgmt.com Sat Feb 15 15:12:46 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Sat, 15 Feb 2003 15:12:46 -0500 Subject: [ppml] ppml 2002-7 Message-ID: <390E55B947E7C848898AEBB9E507706041E2B1@msmdcfs01.msmgmt.com> >From: Owen DeLong [mailto:owen at delong.com] > > >Although I think this facilitates abuse by the ISPs, I think >it's a better >compromise than what is currently proposed. There should, however, be >some form of process included for redress of abuse by ISP so >that people >trying to get sponsored have some recourse if their ISP won't sponsor >them other than finding another ISP. > I think we should leave this alone. If I was an ISP and some guy call John Doe, who happens to be the talk of the town on SPAM-L as an ISP hopping SPAMMER, were to ask me to sponsor him, not only would it be no, but (fill in many choice words here). I don't think this redress is a good idea. An ISP just like any other business should be allowed to choose who they want to service. It is a bigger deal in the US than elsewhere, I believe it is a federal law.... Jim From owen at delong.com Sun Feb 16 03:54:38 2003 From: owen at delong.com (Owen DeLong) Date: Sun, 16 Feb 2003 00:54:38 -0800 Subject: [ppml] ppml 2002-7 In-Reply-To: <390E55B947E7C848898AEBB9E507706041E2B1@msmdcfs01.msmgmt.com> References: <390E55B947E7C848898AEBB9E507706041E2B1@msmdcfs01.msmgmt.com> Message-ID: <2147483647.1045356878@imac-en0.delong.sj.ca.us> I'm not suggesting that it should be easy or incredibly likely to succeed, but there has to be a way to deal with the possibility of a grossly abusive ISP. If there isn't a documented resolution process, it will invite litigation. If there is a documented resolution process within the community, the courts will generally take a dim view of efforts to circumvent it through litigation. I'm thinking something along the lines of creating a dispute resolution committee made up of members nominated by the ASO AC from ARIN members and confirmed by general vote (like the votes for ASO AC members). The committee could review filed grievances and make a binding ruling. Thoughts? Owen --On Saturday, February 15, 2003 3:12 PM -0500 "McBurnett, Jim" wrote: > > >> From: Owen DeLong [mailto:owen at delong.com] >> >> >> Although I think this facilitates abuse by the ISPs, I think >> it's a better >> compromise than what is currently proposed. There should, however, be >> some form of process included for redress of abuse by ISP so >> that people >> trying to get sponsored have some recourse if their ISP won't sponsor >> them other than finding another ISP. >> > I think we should leave this alone. > If I was an ISP and some guy call John Doe, who happens to be the talk of > the town on SPAM-L as an ISP hopping SPAMMER, were to ask me to sponsor > him, not only would it be no, but (fill in many choice words here). > > I don't think this redress is a good idea. An ISP just like any other > business should be allowed to choose who they want to service. > It is a bigger deal in the US than elsewhere, I believe it is a federal > law.... > > Jim From jrace at attglobal.net Sun Feb 16 04:43:58 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Sun, 16 Feb 2003 16:43:58 +0700 Subject: [ppml] ppml 2002-7 Message-ID: <200302160944.h1G9iBqn047594@smtp1.arin.net> On Sun, 16 Feb 2003 00:54:38 -0800, Owen DeLong wrote: >I'm not suggesting that it should be easy or incredibly likely to succeed, >but there has to be a way to deal with the possibility of a grossly abusive >ISP. If there isn't a documented resolution process, it will invite >litigation. If there is a documented resolution process within the >community, >the courts will generally take a dim view of efforts to circumvent it >through litigation. > >I'm thinking something along the lines of creating a dispute resolution >committee made up of members nominated by the ASO AC from ARIN members >and confirmed by general vote (like the votes for ASO AC members). >The committee could review filed grievances and make a binding ruling. > >Thoughts? To extent relevant I'd like to look at how this issue relates to a proposal I am hatching so as perhaps to include some guidance. Please see appended abstract which points to the URL where the current draft resides and offer me any thoughts. Jeffrey Race BEST CURRENT PRACTICE FOR DUTY OF CARE OF INTERNET RESOURCES Pre-release version 1.31 Draft date: February 13, 2003 Drafted by Jeffrey Race Current draft version (4,000 words) available at ABSTRACT This document defines a Best Current Practice to minimize pollution of the Internet by various types of abuse, using the community's own measures in the absence of effective legal, regulatory and technical measures. The Internet's design and management were predicated on voluntary cooperation, self-imposed good behavior, and the non-profit motivational structure of custodians of Internet Resources extant at its inception. Current experience of constantly rising pollution invalidates these formative assumptions and demands prompt and effective curative measures. Present anti-pollution measures fall under four generic headings: (1) self-directed good behavior; (2) legal sanctions (3) technical measures (principally filtering) and (4) self-help defensive measures (principally blocklisting). The first three have definitively failed and will continue to fail for reasons specified in the document. The fourth is generally completely effective in warding off ingress of pollution and frequently results in reforming abuse enablers, but it has two major shortcomings: limited uptake due to fear of loss of competitive market position by early adopters, and sustained transmission outages ("collateral damage"). In view of the failure of (1), (2) and (3) and the effectiveness despite shortcomings of (4), the document proposes to apply to the Internet the same rules society applies to all other resources to deter antisocial behavior viz. proper behavior requires clear published standards, standards entail accountability, accountability entails multiple modes of enforceability, and enforceability entails traceability. The document details procedures and implementing mechanisms based on this universal rule of human experience, while preserving present levels of anonymity for deserving cases. Since both legal and technical measures have failed and will continue to fail, only the behavior modification method of stopping pollution remains, and the only proven effective method of behavior modification is withdrawal of internet resources of identity and connectivity to continue pollution. Numerous tests have shown this sanction to work equally well against both the wilful and the negligent to halt pollution immediately, where prior efforts at polite persuasion to follow best practice were ignored with impunity. The proposal thus innovates in four respects to halt Internet pollution: (1) It makes explicit that every custodian of internet resources is responsible for preventing emission of pollution (2) Adopting a simultaneous universal practice of withdrawal of internet resources means that no provider will suffer competitive disadvantage (3) The burden of pollution now falls on the polluter and his enabler rather than on the victim, so conforming to the basic principle used everywhere else in society to maintain justice and good order. (4) This Practice legitimates withdrawal of internet resources as the only method proven effective in halting abuse. The Practice is intended to apply at every level of allocation, registration and usage of internet resources including but not limited to RIRs, LIRs, ISPs, webhosting firms, backbone connectivity providers, domain name registrars, and end-users. It defines internet resources, unsolicited bulk electronic messaging, and abuse, and specifies procedures progressively to sanction abuse after a period of public admonishment. In effect, the proposal implements the "user pays" paradigm in a completely new and clever way, without requiring any complicated metering technology all proposals for which have failed on issues of complexity, backward compatibility, absence of adequate hardware, and the need for universal adoption to be effective at all. The document embodies the only set of measures now on offer which will quickly end the spam menace internationally with no new legislation, and but small and transitory disruption, by moving from the discredited "victim pays" model to the modern "polluting user pays" model. Adoption will not only be cost-free for the Internet as a whole but will substantially reduce the current economic burden of abuse. It does this by transferring the economic burden from abuse victims to the polluters and their enablers, which is fair and feasible, and indeed the system used everywhere else in society. As such the anticipated vigorous objections to adoption from some parties may be seen in advance as self-serving attempts to perpetuate the discredited "victim pays" model by those now profiting from an environmental polluter business model or by their accessories and enablers. From william at elan.net Mon Feb 17 15:17:35 2003 From: william at elan.net (william at elan.net) Date: Mon, 17 Feb 2003 12:17:35 -0800 (PST) Subject: [ppml] ppml 2002-7 In-Reply-To: <390E55B947E7C848898AEBB9E50770600EB5EF@msmdcfs01.msmgmt.com> Message-ID: > > What do you think about doing this different then what is in > > 2002-7 and > > instead of lowering minimimum allocation/assignment and > > having company > > become new full member, doing this with special policy and special > > associate membership. We can do it so that to get this > > membership company > > would need to have two ARIN full members sponsor it (i.e. its two > > upstreams) > It took me nearly a month to get the right people at one provider > to agree they would multi-home. How long would it take to get 2 > providers to agree to this. I am sure we have some IP Admin's from large > ISP's on here.. COMMENTS?? Most agree that having separate ip block only makes sence if you're multihomed, otherwise you'd be polluting bgp table with all the small blocks one could get. If you plan to multihome you'd have to get in touch with right people at each of your upstream provider's anyway to setup bgp, these techs are either ones handling arin requests already or they would know for sure who is and would assist in sponsorship requests. > > 1. ARIN is not put in the position of having to verify multihoming, > > having two sponsors makes sure of that. > Have you ever filled out an ASN request? I filled out about 10 ASN requests for my company and several companies I consult and well familiar with the process as well as the process to get an ip block (my company has two /19s and I also helped two other companies to get /20s). It may not be easy for somebody "new" but really ASN requests are not that hard if you're technically familar with what is asked there and if somebody does not know how to do ASN request, they probably would not know how to setup BGP and would not be able to setup multihoming or go through more complex request to get ip block so having done an ASN request would be kindof automatic requirement for this sponsorship membership anyway. However when request comes from the "sponsor" or both of them, ARIN would already know that client has discussed their need for separate ip block with their upstream and they agree that this is needed. It can come directly from the company as well but ARIN would have to do agressive verification that upstreams agreed to be sponsors. This is different then what ARIN does currently as it does not try to verify upstreams for ASN and just keeps what you send in their records and never uses it. > If no, take a look at the form. You have to have two peer ASNs to > properly mult-home. Sure an upstream may let > send them a private, but...... > > > 2. Presumably existing arin members would filter out some > > companies that > > really do not need this separate ip block and make sure and > > make sure > > that some technical requirements exist for the assignment. > yea, and are these the same folks that should make sure X user does not > get 128 IP addresses to host 38 domain webpages? If ISP is full member of ARIN they know difficulties of getting additional ips and justifications required for that, so hopefully such cases as 128 ips for 38 domains would not be allowed by them. However this does not mean ISP would be sole judge of the ip request, they would be just "first filter" and afterwards ARIN would still need to verify the the client would need the space. And you have to remember, /24 is the stanard minimum for ip allocation for multihomed customer, this due to many ISPs filtering announcements which are smaller then /24. > > 3. It is still possible for company that got this > > associative membership > > to move to another isp and keep the ip block, but they > > would need to > > make sure their new isp is willing to sponsor them. > This could fall back to the same kinds of diffuculty. > The policy would only work if ALL ISP's played well togather... I believe that getting sponsorship when moving to new ISP would be almost automatic, I don't think this would be much opposed by ISPs - they do not need to do much more then just confirmation email as most difficulty in actually getting the block has already been done before. Besides that ISP would know that since client already has the ip block and hence considers renumbering to be extemely difficult then if they do not sponsor them, they would loose this potential client and client would probably find somebody else. > > 4. ARIN has records on who sponsors are and in case of > > billing problems > > or if it receives reports that address or some other whois > > info is not > > kept up to date, it can ask for assistance of their > > sponsors to get in > > touch with right people. > This is really good. If I don't know how to contact a customer I > send a bill to every month, boy would that be dumb.. > Just as long as the ISP plays well.. You might learn a little about > pain in the rear ISPs on the SPAM-L list... ISPs that are a haven for > SPAMMERS, careless about blacklists, so they may care even less on > this.. > Bottom line is: UNTIL ARIN gets some real abilities to slap > penalties of some kind on ISPs and end users, a lot of people > won't care.. ARIN actions & penalties for not maintaing proper records should be discussed as separate proposal and not be linked to this one. The reason I mentioned #4 is that some who oppose allocation of small blocks are afraid that smaller companies that want these blocks would be less stable, more likely to change their address (difficult to get in touch with based on whois info if it is absolute) and create more difficulty for ARIN to collect the money from them. Plus many are afraid that these small ip blocks maybe used by companies that are engaged in questionable activities and just want to get new ip block as the ones they may have from somewhere else do not work for them anymore due to filtering by other isps. Having sponsors who know exactly who they deal with would help in trying to keep good records for arin and everybody else. > > I do realize this would be kind of compromise and it would > > not be as easy > > to get small ip block as some would like but on the other > > hand I believe > > some of the current proponents (like large ISPs who are worried about > > loosing control of ip assignments) may support this and it might be > > good as compromise between different positions. NOTE: I made a mistake above, I meant some "opponents" may support this policy if they are able to have some say on if their client can get an ip block. > > Please comment on above and if you think this is a good idea, > > I'll write > > up official proposal. > > Overall, I like this..especially #4.. > Don't take me as overly critical, I am just trying to cover every base.. > And no I am not that rententive, just to much time justifing all I do... > > later, > j From jrace at attglobal.net Tue Feb 18 04:57:52 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Tue, 18 Feb 2003 16:57:52 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <200302180958.h1I9w8qn077869@smtp1.arin.net> Please see inline comments On Fri, 14 Feb 2003 12:17:24 -0500, Ron da Silva wrote: >Jeffrey - As this seems to relate to ARIN, >>On Thu, Feb 13, 2003 at 10:25:30PM +0700, Dr. Jeffrey Race wrote: >> (1) It makes explicit that every custodian of internet resources is >> responsible for preventing emission of pollution >> (2) Adopting a simultaneous universal practice of withdrawal of internet >> resources means that no provider will suffer competitive >> disadvantage >> (4) This Practice legitimates withdrawal of internet resources as the >> only method proven effective in halting abuse. > >Are you proposing that ARIN revoke certain resources (assignments, >allocations, ASNs, etc) under certain conditions to influence >certain behaviors (decreasing SPAM propagation)? Yes! It is the only way proven to ensure good behavior among the refractory and the negligent. It gets their attention. Initially the withdrawal might be merely symbolic (because it would have been preceded by a public admonishment) but if necessary an abuser's or enabler's entire address space might be withdrawn. >If so, can you be >more exact on which resources and under which conditions? The resources would be of two types (at least; suggest more as appropriate) - addresses (IP addresses and domain names) - connectivity (service from ISPs, webhosting firms, backbone providers) I welcome any suggestions here to elaborate or improve >Also, not sure if the revocation of an assignment (for example) >necessarily stops an end user from using that assignment. ARIN >currently has no method to stop an end user from using space >illegitimately. Why not and what can be done? It is an obvious loophole in the system from the point of view of a sociologist of group behavior. If the Motor Vehicle Registry can't revoke licenses for abuse, of course the drivers will ignore the rules. Providers may influence that by the extent that >they could refuse to offer transport of bits sourced from that >revoked-now-illegitimate assignment, but that is outside the scope >of PPML (but certainly worth noting). Please elaborate on how this might be implemented. I do NOT want to go into excessive detail of implementation, but I DO want, accurately, to specify a chain of causation (implemented by the Internet resource custodians) leading to the behavior modification of abusers/enablers, or if not, then their disconnection from the Internet Jeffrey Race From jb at jbacher.com Tue Feb 18 09:58:11 2003 From: jb at jbacher.com (J Bacher) Date: Tue, 18 Feb 2003 08:58:11 -0600 (CST) Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <200302180958.h1I9w8qn077869@smtp1.arin.net> Message-ID: On Tue, 18 Feb 2003, Dr. Jeffrey Race wrote: > >Are you proposing that ARIN revoke certain resources (assignments, > >allocations, ASNs, etc) under certain conditions to influence > >certain behaviors (decreasing SPAM propagation)? > > Yes! It is the only way proven to ensure good behavior among the > refractory and the negligent. It gets their attention. Initially > Why not and what can be done? It is an obvious loophole in the > system from the point of view of a sociologist of group behavior. > If the Motor Vehicle Registry can't revoke licenses for abuse, > of course the drivers will ignore the rules. The state can revoke a license under authority of the law. Vocal anti-spammers can't even agree as to what exactly constitutes the various types of unsolicited email. I can't see how we can expect to draft a proposal that goes above any law in this country and expect ARIN to have the resources to enforce it. Your original post (possibly the first bullet point) suggested that ISPs *prevent* this type of abuse. What solutions can you offer that will allow an ISP to prevent spam? From arin_ppml at comcept.net Tue Feb 18 10:25:23 2003 From: arin_ppml at comcept.net (Brian S. Bergin) Date: Tue, 18 Feb 2003 10:25:23 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: References: <200302180958.h1I9w8qn077869@smtp1.arin.net> Message-ID: <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> At 09:58 18 02 03 Tuesday, J Bacher wrote: >On Tue, 18 Feb 2003, Dr. Jeffrey Race wrote: > > > >Are you proposing that ARIN revoke certain resources (assignments, > > >allocations, ASNs, etc) under certain conditions to influence > > >certain behaviors (decreasing SPAM propagation)? > > > > Yes! It is the only way proven to ensure good behavior among the > > refractory and the negligent. It gets their attention. Initially > > > > > Why not and what can be done? It is an obvious loophole in the > > system from the point of view of a sociologist of group behavior. > > If the Motor Vehicle Registry can't revoke licenses for abuse, > > of course the drivers will ignore the rules. > >The state can revoke a license under authority of the law. > >Vocal anti-spammers can't even agree as to what exactly constitutes the >various types of unsolicited email. I can't see how we can expect to >draft a proposal that goes above any law in this country and expect ARIN >to have the resources to enforce it. > >Your original post (possibly the first bullet point) suggested that ISPs >*prevent* this type of abuse. What solutions can you offer that will >allow an ISP to prevent spam? If I might, while I'm new to this list, I deal with the junk daily. The problem is ISPs and individuals buying large blocks of IPs then reselling them to others and then washing their hands of the mess. I can point you to dozens of examples of this. Someone goes out and buy 30-40 /24's then sells them to whomever will pay for them and since they're not hosted on the same backbone as the address owner they are not held liable by their upstream provider(s) for the spam generated on the resold blocks. Those blocks often end up in Asia or South America where ISPs often do not enforce any kind of AUP. As for the vocal anti-spammers not agreeing on what constitutes UE, I disagree. UE is any mail sent unsolicited and without the addressee's permission. Furthermore, forged headers or relayed mail is abusive. Go look at the major backbone providers like C&W & uu.net. Their AUPs are quite clear. To top it all off, many of these blocks, when SWIP'd, contain fraudulent information. ICANN will revoke a fraudulent or invalid domain registration why can't ARIN revoke a fraudulent IP SWIP and if the block owner is found to also have fraudulent or invalid registration information they should have their entire block revoked. That's the way the rest of the world works. Do you think the FCC would allow someone to buy a block of frequencies and give them false contact info? The FCC would yank the licenses immediately with NO refund. ARIN must evolve to function like the rest of the world. Apply existing fraud laws. If someone obtains goods or services under misleading or fraudulent circumstances no matter the intended use they have violated criminal laws in every state and Federal laws as well. Why can't ARIN use existing laws to go after them? Anyway, if ARIN doesn't get its act together count on the government coming up with a "solution" that doesn't work and is impossible to enforce. Simple rules work best. Register your IPs with valid info. Keep that info up to date. Follow an established AUP with those IPs. Violate any one and you lose them all with no refund. Sincerely, ComCept Solutions, LLC. Brian S. Bergin Network Systems Administrator (828) 265-1234 http://www.comcept.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From cscott at gaslightmedia.com Tue Feb 18 11:34:55 2003 From: cscott at gaslightmedia.com (Charles Scott) Date: Tue, 18 Feb 2003 11:34:55 -0500 (EST) Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> Message-ID: Brian: Being a vocal anti-spammer, I have to disagree with this statement (or did you not mean it to sound this way). Just because a provider SWIP's an address block to someone who deploys it on another network does not mean they are absolved of responsibility for its use. The "chain of custody" is critical. If a provider reassigns space and accepts no responsibility for its use, they should be considered as culpable as the actual abuser. Chuck On Tue, 18 Feb 2003, Brian S. Bergin wrote: > If I might, while I'm new to this list, I deal with the junk daily. The > problem is ISPs and individuals buying large blocks of IPs then reselling > them to others and then washing their hands of the mess. I can point you > to dozens of examples of this. Someone goes out and buy 30-40 /24's then > sells them to whomever will pay for them and since they're not hosted on > the same backbone as the address owner they are not held liable by their > upstream provider(s) for the spam generated on the resold blocks. Those > blocks often end up in Asia or South America where ISPs often do not > enforce any kind of AUP. From jb at jbacher.com Tue Feb 18 11:47:39 2003 From: jb at jbacher.com (J Bacher) Date: Tue, 18 Feb 2003 10:47:39 -0600 (CST) Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> Message-ID: On Tue, 18 Feb 2003, Brian S. Bergin wrote: > >Your original post (possibly the first bullet point) suggested that ISPs > >*prevent* this type of abuse. What solutions can you offer that will > >allow an ISP to prevent spam? > > If I might, while I'm new to this list, I deal with the junk daily. The > problem is ISPs and individuals buying large blocks of IPs then reselling > them to others and then washing their hands of the mess. I can point you The question isn't one of ISP policy, it's posed from a technical perspective. I can prevent outbound port 25 from all dialup/dsl/cable except to my servers. I can be proactive when handling spam complaints. But how do I *prevent* spam? > As for the vocal anti-spammers not agreeing on what constitutes UE, I > disagree. UE is any mail sent unsolicited and without the addressee's > permission. Furthermore, forged headers or relayed mail is abusive. Go > look at the major backbone providers like C&W & uu.net. Their AUPs are > quite clear. I find that, to many people, everything constitutes spam. A single virus transmission or a typoed email address is justification to submit a report to any and every one that will listen. > To top it all off, many of these blocks, when SWIP'd, contain fraudulent > information. ICANN will revoke a fraudulent or invalid domain registration > why can't ARIN revoke a fraudulent IP SWIP and if the block owner is found > to also have fraudulent or invalid registration information they should > have their entire block revoked. That's the way the rest of the world > works. Do you think the FCC would allow someone to buy a block of > frequencies and give them false contact info? The FCC would yank the This has nothing to do with spam. This is a valid complaint regardless. From arin_ppml at comcept.net Tue Feb 18 12:03:43 2003 From: arin_ppml at comcept.net (Brian Bergin) Date: Tue, 18 Feb 2003 12:03:43 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <5.2.1.0.2.20030218120337.02b9f328@mail> Not what I meant. What I said was this IS a problem. Entities buying large blocks, reselling them, then washing their hands of the responsibility is a HUGE problem. I couldn't agree with you more. They ARE as responsible as the abuser. Sorry for any misunderstanding. Brian At 11:34 18 02 03 Tuesday, you wrote: >Brian: > Being a vocal anti-spammer, I have to disagree with this statement (or >did you not mean it to sound this way). Just because a provider SWIP's an >address block to someone who deploys it on another network does not mean >they are absolved of responsibility for its use. The "chain of custody" is >critical. If a provider reassigns space and accepts no responsibility for >its use, they should be considered as culpable as the actual abuser. > >Chuck > >On Tue, 18 Feb 2003, Brian S. Bergin wrote: > > > If I might, while I'm new to this list, I deal with the junk daily. The > > problem is ISPs and individuals buying large blocks of IPs then reselling > > them to others and then washing their hands of the mess. I can point you > > to dozens of examples of this. Someone goes out and buy 30-40 /24's then > > sells them to whomever will pay for them and since they're not hosted on > > the same backbone as the address owner they are not held liable by their > > upstream provider(s) for the spam generated on the resold blocks. Those > > blocks often end up in Asia or South America where ISPs often do not > > enforce any kind of AUP. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin_ppml at comcept.net Tue Feb 18 12:03:54 2003 From: arin_ppml at comcept.net (Brian Bergin) Date: Tue, 18 Feb 2003 12:03:54 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <5.2.1.0.2.20030218120349.02ba55f0@mail> At 10:57 18 02 03 Tuesday, you wrote: >so color me naive, but how does one "buy a block of 30-40 /24's" ?? Sorry, perhaps not 30-40, but try this: http://ws.arin.net/cgi-bin/whois.pl?queryinput=!%20NET-209-236-0-0-1. There are 64 and a prime example of this. They have had their share of abusive customers. >your analogy to the FCC has a small flaw. The FCC is a gov org and >as such is protected from certain actions that ARIN, which isn't a gov >org, is not. Not true. Any organization can setup rules by which anyone who wishes to work with them must abide by. No one's forcing the spammers to buy blocks of IPs and no one is forcing the ISPs to sell them. It's totally voluntary. No one forces people to use the Internet and therefore abide by their ISP's AUP and yet all of them find ways of enforcing them. It's called a contract. >ICANN doesn't revoke a fraudulent or invalid domain name, the registrar >or the registry does. if they don't then ICANN could revoke the registrar >or registry's certification. Semantics. If say Register.com refuses to update a domain registration reported to ICANN as containing invalid or fraudulent information and they refuse to delete the registration ICANN, as you say, simple revoke the registrar. Either way the invalid domain registration is revoked. >For ARIN to "go after" fraud is mission creep for ARIN. Its not their job >and they are NOT the Net.Police. Fraud is between two people, the victim >and the person committing fraud. ARIN is not a direct party to that event IMHO, If ARIN knowingly allows someone to commit fraud and provides a way for them to do it then they become party to the fraud. Once ARIN has been notified of the fraud they should be required to remove the registration. If a gun dealer sells a gun to a known criminal they become party to any acts committed with the gun. Before you flame me saying this is different, IPs don't kill, it's back to the culpability. >But most importantly ARIN can not make a "moral or otherwise" decision >on the potential us of allocated IP space. To say some can and some can't >have IP space based on intended use would land ARIN in court on anti-trust >or other legal hot water. ISPs get sued often over AUP enforcements. I've not seen one case lead to the reinstatement of a user's account. AUPs are contracts. ARIN members agree to certain terms and those terms can be updated to include things like no fraudulent or invalid information. > >I believe the "gov" will keep its fingers out of the pie, for if they >don't it will >then go the way of the ITU, and *nobody* wants that to happen No it won't. Businesses are ever increasingly yelling at Washington to do something. I've seen reports that 50-60% of all e-mail delivered to corporate America is junk. It's costing them, and therefore us in the form of passed on costs, billions each year. The Gov will get involved if something is not done by the industry. Brian >If I might, while I'm new to this list, I deal with the junk daily. The >problem is ISPs and individuals buying large blocks of IPs then reselling >them to others and then washing their hands of the mess. I can point you >to dozens of examples of this. Someone goes out and buy 30-40 /24's then >sells them to whomever will pay for them and since they're not hosted on >the same backbone as the address owner they are not held liable by their >upstream provider(s) for the spam generated on the resold blocks. Those >blocks often end up in Asia or South America where ISPs often do not >enforce any kind of AUP. > >As for the vocal anti-spammers not agreeing on what constitutes UE, I >disagree. UE is any mail sent unsolicited and without the addressee's >permission. Furthermore, forged headers or relayed mail is abusive. Go >look at the major backbone providers like C&W & uu.net. Their AUPs are >quite clear. >To top it all off, many of these blocks, when SWIP'd, contain fraudulent >information. ICANN will revoke a fraudulent or invalid domain >registration why can't ARIN revoke a fraudulent IP SWIP and if the block >owner is found to also have fraudulent or invalid registration information >they should have their entire block revoked. That's the way the rest of >the world works. Do you think the FCC would allow someone to buy a block >of frequencies and give them false contact info? The FCC would yank the >licenses immediately with NO refund. ARIN must evolve to function like >the rest of the world. Apply existing fraud laws. If someone obtains >goods or services under misleading or fraudulent circumstances no matter >the intended use they have violated criminal laws in every state and >Federal laws as well. Why can't ARIN use existing laws to go after them? >Anyway, if ARIN doesn't get its act together count on the government >coming up with a "solution" that doesn't work and is impossible to >enforce. Simple rules work best. Register your IPs with valid >info. Keep that info up to date. Follow an established AUP with those >IPs. Violate any one and you lose them all with no refund. >Sincerely, >ComCept Solutions, LLC. >Brian S. Bergin >Network Systems Administrator >(828) 265-1234 >http://www.comcept.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at rovingplanet.com Tue Feb 18 12:04:23 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Tue, 18 Feb 2003 10:04:23 -0700 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7721@pluto.rovingplanet.com> Snip > > To top it all off, many of these blocks, when SWIP'd, contain fraudulent > > information. ICANN will revoke a fraudulent or invalid domain > registration > > why can't ARIN revoke a fraudulent IP SWIP and if the block owner is > found > > to also have fraudulent or invalid registration information they should > > have their entire block revoked. That's the way the rest of the world > > works. Do you think the FCC would allow someone to buy a block of > > frequencies and give them false contact info? The FCC would yank the > > This has nothing to do with spam. This is a valid complaint regardless. ARIN and the other RIR's need to work with the IETF to build into BGP or its replacement a method of de-authenticating address space and AS assignments along with announcing valid AS's and blocks. Then they also need to create rules that will stand up in court so that when they yank someone's connectivity it will stick. Steve Rolapp From arin_ppml at comcept.net Tue Feb 18 12:10:35 2003 From: arin_ppml at comcept.net (Brian Bergin) Date: Tue, 18 Feb 2003 12:10:35 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: References: <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> Message-ID: <5.2.1.0.2.20030218115737.0296c590@mail.comcept.net> At 11:47 18 02 03 Tuesday, you wrote: >On Tue, 18 Feb 2003, Brian S. Bergin wrote: > > > >Your original post (possibly the first bullet point) suggested that ISPs > > >*prevent* this type of abuse. What solutions can you offer that will > > >allow an ISP to prevent spam? > > > > If I might, while I'm new to this list, I deal with the junk daily. The > > problem is ISPs and individuals buying large blocks of IPs then reselling > > them to others and then washing their hands of the mess. I can point you > >The question isn't one of ISP policy, it's posed from a technical >perspective. > >I can prevent outbound port 25 from all dialup/dsl/cable except to my >servers. I can be proactive when handling spam complaints. That's quickly becoming a moot point. There are plenty services both in and out of North America that allow people to send SMTP traffic on other than port 25 then they in turn send it out on port 25. As more and more ISPs block port 25 more and more spammers figure out it's easy to get around. Blocking 25 isn't the answer. IMHO, the biggest thing is to clean up the open port 25 relays. We were required by our backbone providers to show that our mail servers were secure. Now blocking inbound port 25 from Asia and Eastern Europe does cut down on spam by 90%. I know, we've tried it... >But how do I *prevent* spam? > > > As for the vocal anti-spammers not agreeing on what constitutes UE, I > > disagree. UE is any mail sent unsolicited and without the addressee's > > permission. Furthermore, forged headers or relayed mail is abusive. Go > > look at the major backbone providers like C&W & uu.net. Their AUPs are > > quite clear. > >I find that, to many people, everything constitutes spam. A single virus >transmission or a typoed email address is justification to submit a report >to any and every one that will listen. No. Most AUPs have something to the effect of "if it could reasonability be considered to result in complaints". Every spammer knows what s/he is doing. A cut-and-dry limit could be set. x number of complaints generates a contact e-mail to the admin & tech contacts (if they're bounced as undeliverable the account is suspended). x number of additional complaints generates a x-hour suspension of IPs. x number more and the account is off for a month. After that, one more set of complaints and it's off for good with no refund. Also, a mis-typed e-mail address or virus is not spam by any AUP I've ever seen although continued unchecked viruses should result in the ISP suspending the account until it's corrected. Most will do that if enough complaints come in. > > To top it all off, many of these blocks, when SWIP'd, contain fraudulent > > information. ICANN will revoke a fraudulent or invalid domain > registration > > why can't ARIN revoke a fraudulent IP SWIP and if the block owner is found > > to also have fraudulent or invalid registration information they should > > have their entire block revoked. That's the way the rest of the world > > works. Do you think the FCC would allow someone to buy a block of > > frequencies and give them false contact info? The FCC would yank the > >This has nothing to do with spam. This is a valid complaint regardless. You're right; however, ARIN will NOT go after a block of IPs that has fraudulent info. I have dozens of tickets with them stating they will not do anything other than list the fact that the info has been reported as inaccurate. What good does that do. If the state just issued me informational 'tickets' for violating the speed limit with no enforcement teeth do you think I'm ever going to slow down? Until ARIN actually gets some backbone, and I'm not talking about bandwidth, people will continue to abuse the IP space by committing fraud to obtain and continue to use them. Honestly I fail to see why there's so much concern about ARIN enforcing an AUP or no-fraud clauses. If you don't spam and don't host spammers or if you actually enforce an AUP and remove spammers I can't see why anyone would be against this. I would think legit ISPs would welcome the change at the top. It would given them yet another tool to remove spammers from their network. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at chagres.net Tue Feb 18 12:35:33 2003 From: john at chagres.net (John M. Brown) Date: Tue, 18 Feb 2003 10:35:33 -0700 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) In-Reply-To: <661F9268BBA8CB4EB92CC12B8C42F0690F7721@pluto.rovingplanet.com> Message-ID: <001101c2d774$252e88a0$f9ecdfd8@laptoy> no they don't The ability to accept routes from a customer is strictly a matter between the service provider and its customer. We do not need to overload protocols with this type of data. I can see a nice little DDOS vector here. Happy Hacker tricks BGP into revoking EBAY's prefix, EBAY looses millions, sues RIR. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Steve Rolapp > Sent: Tuesday, February 18, 2003 10:04 AM > To: ppml at arin.net > Subject: RE: [ppml] Abstract of proposed Internet Draft for > Best CurrentPractice (please comment) > > > > > ARIN and the other RIR's need to work with the IETF to build > into BGP or its replacement a method of de-authenticating > address space and AS assignments along with announcing valid > AS's and blocks. Then they also need to create rules that > will stand up in court so that when they yank someone's > connectivity it will stick. > > Steve Rolapp > From jb at jbacher.com Tue Feb 18 12:34:58 2003 From: jb at jbacher.com (J Bacher) Date: Tue, 18 Feb 2003 11:34:58 -0600 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice In-Reply-To: <5.2.1.0.2.20030218115737.0296c590@mail.comcept.net> References: <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> Message-ID: <5.1.0.14.2.20030218112004.0246deb8@localhost> >> > >Your original post (possibly the first bullet point) suggested that ISPs >> > >*prevent* this type of abuse. What solutions can you offer that will >> > >allow an ISP to prevent spam? >> >>The question isn't one of ISP policy, it's posed from a technical >>perspective. >> >>I can prevent outbound port 25 from all dialup/dsl/cable except to my >>servers. I can be proactive when handling spam complaints. > >That's quickly becoming a moot point. There are plenty services both in >and out of North America that allow people to send SMTP The recommendation was that ISPs prevent spam. I'd like to know a solution that scales. >>I find that, to many people, everything constitutes spam. A single virus >>transmission or a typoed email address is justification to submit a report >>to any and every one that will listen. > >No. Most AUPs have something to the effect of "if it could reasonability >be considered to result in complaints". Every spammer And I'm telling you, yes. The point of view is of the complainant -- not the AUP of a company. From john at chagres.net Tue Feb 18 12:42:25 2003 From: john at chagres.net (John M. Brown) Date: Tue, 18 Feb 2003 10:42:25 -0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <5.2.1.0.2.20030218115737.0296c590@mail.comcept.net> Message-ID: <001201c2d775$191cd2a0$f9ecdfd8@laptoy> Lovely conversation about RIR's fighting SPAM, Hackers and that the RIR's should have the power to revoke routing and IP space for these evil doers. Lets get real for a moment, eh... 1. RIR's are not the place to fight the spam problem. Washington or your local equiv is. You should be asking your Senators / Congress Critters why they keep killing Federal Anti-Spam legislation, why they keep taking reasonable bills and turning them into mush. 2. RIR's are not the place to fight hackers, DDOS'rs etc If you want to keep your network from being hacked place a firewall and participate in the security of your network, which is a constant activity. If you want to stop DDOS, then filter the edge of the the network and prevent bad packets from leaving YOUR network. Having the RIR's control the routing tables is a pandora's box you all really really don't want to have opened up. It will lead to bad laws, anti-trust issues, RIR's will have a monopoly of control that you don't want. Money will play a bigger role in who gets to have their prefix listed, etc. Just don't go there, eh. From jb at jbacher.com Tue Feb 18 12:49:59 2003 From: jb at jbacher.com (J Bacher) Date: Tue, 18 Feb 2003 11:49:59 -0600 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <001201c2d775$191cd2a0$f9ecdfd8@laptoy> References: <5.2.1.0.2.20030218115737.0296c590@mail.comcept.net> Message-ID: <5.1.0.14.2.20030218114856.04378008@localhost> At 10:42 AM 2/18/2003 -0700, John M. Brown wrote: >Lovely conversation about RIR's fighting SPAM, Hackers >and that the RIR's should have the power to revoke routing >and IP space for these evil doers. > >Lets get real for a moment, eh... > >1. RIR's are not the place to fight the spam problem. > >2. RIR's are not the place to fight hackers, DDOS'rs etc > >Having the RIR's control the routing tables is a pandora's >box you all really really don't want to have opened up. It >will lead to bad laws, anti-trust issues, RIR's will have >a monopoly of control that you don't want. Money will >play a bigger role in who gets to have their prefix >listed, etc. A voice of reason. And ... it doesn't scale. From steve at rovingplanet.com Tue Feb 18 12:58:07 2003 From: steve at rovingplanet.com (Steve Rolapp) Date: Tue, 18 Feb 2003 10:58:07 -0700 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) Message-ID: <661F9268BBA8CB4EB92CC12B8C42F0690F7722@pluto.rovingplanet.com> I disagree. Take DNS. The registrares are able to pull a domain from the root servers for fraud and as was noted ICAAN can inforce that. Its no different a senerio for the RIR's. Yes the protocol would need to be made bullet proof. The real purpose of this is not so specific as to fight spam but instead is to maintain more control of the IP space that they allocate. Fraud or spam are examples of how else something like this might be used. >From what I understand, there are blocks from spammers in the swamp now that can't be used because they have been labeled as spam nets. In this way the RIR's could reuse these nets and everyone knows they are not from the spammer. Steve Rolapp > -----Original Message----- > From: John M. Brown [mailto:john at chagres.net] > Sent: Tuesday, February 18, 2003 10:36 AM > To: Steve Rolapp; ppml at arin.net > Subject: RE: [ppml] Abstract of proposed Internet Draft for Best > CurrentPractice (please comment) > > no they don't The ability to accept routes from a customer > is strictly a matter between the service provider and > its customer. > > We do not need to overload protocols with this type of > data. > > I can see a nice little DDOS vector here. Happy Hacker > tricks BGP into revoking EBAY's prefix, EBAY looses > millions, sues RIR. > > > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of Steve Rolapp > > Sent: Tuesday, February 18, 2003 10:04 AM > > To: ppml at arin.net > > Subject: RE: [ppml] Abstract of proposed Internet Draft for > > Best CurrentPractice (please comment) > > > > > > > > > > ARIN and the other RIR's need to work with the IETF to build > > into BGP or its replacement a method of de-authenticating > > address space and AS assignments along with announcing valid > > AS's and blocks. Then they also need to create rules that > > will stand up in court so that when they yank someone's > > connectivity it will stick. > > > > Steve Rolapp > > From arin_ppml at comcept.net Tue Feb 18 13:05:15 2003 From: arin_ppml at comcept.net (Brian Bergin) Date: Tue, 18 Feb 2003 13:05:15 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <001201c2d775$191cd2a0$f9ecdfd8@laptoy> References: <5.2.1.0.2.20030218115737.0296c590@mail.comcept.net> Message-ID: <5.2.1.0.2.20030218125508.02ba5bd8@mail> Sorry for this gripe; however, there are members of this list that find it necessary to take conversations off-list without first requesting a private conversation. I believe that to be inappropriate. I didn't join this list to have private discussions. Those same members are unhappy, actually they were quite belligerent, when their comments are posted back to the list claiming copyright and DMCA violations, even though they never requested their comments remain private. This thread states "please comment" not "please comment in private". Unsolicited private comments are not only counterproductive, they are rude. This is notice that all communications sent to me based on this list will be automatically forwarded to the list. If you don't want your comments to me sent to the list don't send them to me. Brian Bergin arin_ppml at comcept.net From ppml at rsuc.gweep.net Tue Feb 18 15:23:07 2003 From: ppml at rsuc.gweep.net (Joe Provo) Date: Tue, 18 Feb 2003 15:23:07 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) In-Reply-To: <001101c2d774$252e88a0$f9ecdfd8@laptoy> References: <661F9268BBA8CB4EB92CC12B8C42F0690F7721@pluto.rovingplanet.com> <001101c2d774$252e88a0$f9ecdfd8@laptoy> Message-ID: <20030218202307.GA53772@gweep.net> [similar to a rant half-written and not sent during nanog] On Tue, Feb 18, 2003 at 10:35:33AM -0700, John M. Brown wrote: > no they don't The ability to accept routes from a customer > is strictly a matter between the service provider and > its customer. [snip - we'll use this context later] > I can see a nice little DDOS vector here. Happy Hacker > tricks BGP into revoking EBAY's prefix, EBAY looses > millions, sues RIR. Straightforward denial of service, nothing distributed. And guess waht - the black hats are already (have been for a while) exploting longest-match as a way to impersonate routes/steal traffic/smokescreen their black-hatted-ness. How does this relate to RIRs? Through the side door: - RIRs already have multihoming as a requirement for AS allocations. - Some RIRs have multihoming as address allocation justification. ...seems that the RIR's are NOT 'controlling the routing table' (but gosh, is there a problem with publishing allocation data in standardized machine-parsable format? RIPE seems to do it a-ok...) but DO have their fingers in the justification of space and -to a limited degree- how that space is to be utilized. See it isn't the Vendor-customer relationship (well, except from clueless vendors who think any routes they propagate are instantly going to be "valid" because they are special/big/buy from 'all the tier1s'/etc) so much as the customer-vendor-rest of the net. It is a Very Short step to dedicating and policing space for 'officially blessed small multihoming'. This would - be consistnt with RIR roles and previous actions (ASNs not used for multihomed entities can be revoked; ISPs and other LIRs are tacitly encouraged to revoke space that was justified by multihoming when said multihoming doesn't occur; etc) - reduce deaggregation/holes in areas populated by aggregates - give network operators additional tools to do *their* jobs of filtering/fighting black-hatted-ness *without* making it the RIR's job (ie, i can filter against longest-match abuse in space knpown to be populated with aggregates AND point any complainers to the Right Thing) Do I want the RIRs managing the routing tables? No. Do I want registries to hold confirmed data, audit trails disambiguated, and everyone playing by the same rules? Yes. joe, not enough coffee so i hope this is coherent -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From ron at aol.net Tue Feb 18 15:28:46 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 15:28:46 -0500 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <661F9268BBA8CB4EB92CC12B8C42F0690F7722@pluto.rovingplanet.com> <001101c2d774$252e88a0$f9ecdfd8@laptoy> <661F9268BBA8CB4EB92CC12B8C42F0690F7721@pluto.rovingplanet.com> <5.2.1.0.2.20030218120349.02ba55f0@mail> <5.2.1.0.2.20030218120337.02b9f328@mail> <5.2.1.0.2.20030218115737.0296c590@mail.comcept.net> <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> <200302180957.h1I9vMv08906@postman5.mx.aol.com> References: <661F9268BBA8CB4EB92CC12B8C42F0690F7721@pluto.rovingplanet.com> <001101c2d774$252e88a0$f9ecdfd8@laptoy> <661F9268BBA8CB4EB92CC12B8C42F0690F7721@pluto.rovingplanet.com> <5.2.1.0.2.20030218120349.02ba55f0@mail> <5.2.1.0.2.20030218120337.02b9f328@mail> <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> <5.2.1.0.2.20030218115737.0296c590@mail.comcept.net> <200302180958.h1I9w8qn077869@smtp1.arin.net> <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> <200302180957.h1I9vMv08906@postman5.mx.aol.com> Message-ID: <20030218202846.GF22895@aol.net> All, This thread has become a bit convoluted. Let's split it up please. I've tried to capture the different issues below. First, ppml is not a list to discuss SPAM per se. (so please do NOT). However, if we want to address certain policies or proposed policies of ARIN that could impact SPAM practices, then lets do. This is a public policy list for ARIN. So, we don't need to discuss domainname revocation or routing announcements - neither service is provided by ARIN. Now, about allocations and assignments... Suggested Thread #1: Revocation I believe this thread began with the idea of having certain services (allocations/assignments) revoked by ARIN under given circumstances (namely fostering SPAM). We need to be more precise on which resources and under which conditions those resources are to be revoked. Suggested Thread #2: Enforcement The motor vehicle registry can revoke a license to drive, but not stop you from driving your car - that is the role of law enforcement. ARIN currently has no mechanism to enforce policy other than removing allocations/assignments or other database resources. If there is a specific suggestion on how ARIN could provide enforcement of resources it manages, please take this to that thread (rename the subject please)! Suggested Thread #3: Selling /24's There was an assertion that folks are purchasing /24's for abuse. Sorry, simple taxonomy correction. No address space is ever sold, "leased" is the term here. So, should there be an AUP that describes leasing of space downstream? If you have suggested policy for that purpose, let's discuss. Suggested Thread #4: Inaccurate/fraudulent data Some concerns have been raised here regarding SWIP data, or data in general. Some work has been done here (2002-7) for in-addr's. Perhaps there is some crisp policy suggestions that someone would like to make here for discussion? Suggested Thread #5: Collaboration with IETF This might be along the lines of soBGP, etc. for authenticating BGP announcements. Perhaps ARIN could provide database information for initial AS_to_allocation/assignments for BGP auth. ARIN has involvement with IETF and other organizations via its staff, the AC and the BOT. If there is a particular service or policy that we should discuss regarding a specific technology, please suggest it here. ARIN involvement with other organizations is more of a staff issue though, and not a specific policy topic. (Richard - correct me if I'm wrong here!) These are great topics. Thanks!! -ron ARIN AC From john at chagres.net Tue Feb 18 15:44:00 2003 From: john at chagres.net (John M. Brown) Date: Tue, 18 Feb 2003 13:44:00 -0700 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) In-Reply-To: <20030218202307.GA53772@gweep.net> Message-ID: <002601c2d78e$77606890$f9ecdfd8@laptoy> once upon a time we tried to create a data base, RADB, IRR etc. They don't seem to be getting as much use as they used to. I am extremely leary of having the RIR's become involved in "asserting" whats in the routing table. The failure modes of that database being corrupt, hacked or fat finger'd are to big to justify the value of it, IMHO. If someone like ARIN did it I would expect them to carry a liability policy of multiple millions incase they fat fingered or other screwed the data up and cause someone get get dropped off the net that wasn't suppose to be. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Joe Provo > Sent: Tuesday, February 18, 2003 1:23 PM > To: John M. Brown > Cc: ppml at arin.net > Subject: Re: [ppml] Abstract of proposed Internet Draft for > Best CurrentPractice (please comment) > > > > [similar to a rant half-written and not sent during nanog] > > On Tue, Feb 18, 2003 at 10:35:33AM -0700, John M. Brown wrote: > > no they don't The ability to accept routes from a customer is > > strictly a matter between the service provider and its customer. > [snip - we'll use this context later] > > I can see a nice little DDOS vector here. Happy Hacker tricks BGP > > into revoking EBAY's prefix, EBAY looses millions, sues RIR. > > Straightforward denial of service, nothing distributed. And > guess waht - the black hats are already (have been for a while) > exploting longest-match as a way to impersonate routes/steal > traffic/smokescreen their black-hatted-ness. How does this > relate to RIRs? Through the side door: > > - RIRs already have multihoming as a requirement for AS > allocations. > - Some RIRs have multihoming as address allocation > justification. > ...seems that the RIR's are NOT 'controlling the routing table' > (but gosh, is there a problem with publishing allocation data > in standardized machine-parsable format? RIPE seems to do it > a-ok...) but DO have their fingers in the justification of > space and -to a limited degree- how that space is to be > utilized. > > See it isn't the Vendor-customer relationship (well, except from > clueless vendors who think any routes they propagate are instantly > going to be "valid" because they are special/big/buy from 'all > the tier1s'/etc) so much as the customer-vendor-rest of the net. > > It is a Very Short step to dedicating and policing space for > 'officially blessed small multihoming'. This would > - be consistnt with RIR roles and previous actions (ASNs not > used for multihomed entities can be revoked; ISPs and other > LIRs are tacitly encouraged to revoke space that was > justified by multihoming when said multihoming doesn't > occur; etc) > - reduce deaggregation/holes in areas populated by aggregates > - give network operators additional tools to do *their* jobs > of filtering/fighting black-hatted-ness *without* making it > the RIR's job (ie, i can filter against longest-match abuse > in space knpown to be populated with aggregates AND point > any complainers to the Right Thing) > > > Do I want the RIRs managing the routing tables? No. Do I > want registries to hold confirmed data, audit trails > disambiguated, and everyone playing by the same rules? Yes. > > joe, not enough coffee so i hope this is coherent > > -- > RSUC / GweepNet / Spunk / FnB / Usenix / SAGE > From john at chagres.net Tue Feb 18 15:52:03 2003 From: john at chagres.net (John M. Brown) Date: Tue, 18 Feb 2003 13:52:03 -0700 Subject: [ppml] comments on various new possible threads In-Reply-To: <20030218202846.GF22895@aol.net> Message-ID: <002701c2d78f$97421220$f9ecdfd8@laptoy> > revocation or routing > announcements - neither service is provided by ARIN. There has been RIR talk about providing such service. So if you are stating that the RIR known as ARIN is not talking about or going to provide such service, we can drop the thread. Otherwise its valid to be talked about on the PPML list. > Now, about allocations and assignments... > > Suggested Thread #1: Revocation > I believe this thread began with the idea of having certain > services (allocations/assignments) revoked by ARIN under > given circumstances (namely fostering SPAM). We need to be > more precise on which resources and under which conditions > those resources are to be revoked. Since there isn't a "standard" lithmus test for what SPAM is, ARIN can't have a policy to revoke a prefix because of SPAM. This should be dropped. Spam is a social issue that is not in the perview of ARIN or any other RIR. > Suggested Thread #2: Enforcement > The motor vehicle registry can revoke a license to drive, but > not stop you from driving your car - that is the role of law > enforcement. ARIN currently has no mechanism to enforce > policy other than removing allocations/assignments or other > database resources. If there is a specific suggestion on how > ARIN could provide enforcement of resources it manages, > please take this to that thread (rename the subject please)! RIR's are not in the business of providing this service. The liability risk is way to high. > Suggested Thread #3: Selling /24's > There was an assertion that folks are purchasing /24's for > abuse. Sorry, simple taxonomy correction. No address space > is ever sold, "leased" is the term here. So, should there be > an AUP that describes leasing of space downstream? If you > have suggested policy for that purpose, let's discuss. A RIR should not dictate or control, what someone does with their space in this manner. Having a RIR control that, means the RIR is controlling the business model for some organization. Terms like Anti-Trust, Monopoly and other such come to mind with this thread idea. > Suggested Thread #5: Collaboration with IETF > This might be along the lines of soBGP, etc. for > authenticating BGP announcements. Perhaps ARIN could provide > database information for initial AS_to_allocation/assignments > for BGP auth. ARIN has involvement with IETF and other > organizations via its staff, the AC and the BOT. If there is > a particular service or policy that we should discuss > regarding a specific technology, please suggest it here. > ARIN involvement with other organizations is more of a staff > issue though, and not a specific policy topic. (Richard - > correct me if I'm wrong here!) Making use of new protocols that affect allocations and their uses, is a policy issue to be brought before the membership, prior to adoption. sBGP and other such things will take multiple years to role out, the equipment, IOS-ish, and other costs are way high to make this a requirement in the short term. From Stacy_Taylor at icgcomm.com Tue Feb 18 17:04:36 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Tue, 18 Feb 2003 15:04:36 -0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DADD5D@denexg21.icgcomm.com> Speaking only for myself, I believe it is absolutely not for the RIR to police or monitor use of blocks. The Registry is there for just that: to keep track of who is using what. It must not be responsible for pulling routes or revoking rights for abuse reasons. The onus must ultimately be on the upstream operators to maintain the integrity of the blocks: both for contiguity and for purity. Stacy -----Original Message----- From: John M. Brown [mailto:john at chagres.net] Sent: Tuesday, February 18, 2003 12:44 PM To: ppml at arin.net Subject: RE: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) once upon a time we tried to create a data base, RADB, IRR etc. They don't seem to be getting as much use as they used to. I am extremely leary of having the RIR's become involved in "asserting" whats in the routing table. The failure modes of that database being corrupt, hacked or fat finger'd are to big to justify the value of it, IMHO. If someone like ARIN did it I would expect them to carry a liability policy of multiple millions incase they fat fingered or other screwed the data up and cause someone get get dropped off the net that wasn't suppose to be. > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Joe Provo > Sent: Tuesday, February 18, 2003 1:23 PM > To: John M. Brown > Cc: ppml at arin.net > Subject: Re: [ppml] Abstract of proposed Internet Draft for > Best CurrentPractice (please comment) > > > > [similar to a rant half-written and not sent during nanog] > > On Tue, Feb 18, 2003 at 10:35:33AM -0700, John M. Brown wrote: > > no they don't The ability to accept routes from a customer is > > strictly a matter between the service provider and its customer. > [snip - we'll use this context later] > > I can see a nice little DDOS vector here. Happy Hacker tricks BGP > > into revoking EBAY's prefix, EBAY looses millions, sues RIR. > > Straightforward denial of service, nothing distributed. And > guess waht - the black hats are already (have been for a while) > exploting longest-match as a way to impersonate routes/steal > traffic/smokescreen their black-hatted-ness. How does this > relate to RIRs? Through the side door: > > - RIRs already have multihoming as a requirement for AS > allocations. > - Some RIRs have multihoming as address allocation > justification. > ...seems that the RIR's are NOT 'controlling the routing table' > (but gosh, is there a problem with publishing allocation data > in standardized machine-parsable format? RIPE seems to do it > a-ok...) but DO have their fingers in the justification of > space and -to a limited degree- how that space is to be > utilized. > > See it isn't the Vendor-customer relationship (well, except from > clueless vendors who think any routes they propagate are instantly > going to be "valid" because they are special/big/buy from 'all > the tier1s'/etc) so much as the customer-vendor-rest of the net. > > It is a Very Short step to dedicating and policing space for > 'officially blessed small multihoming'. This would > - be consistnt with RIR roles and previous actions (ASNs not > used for multihomed entities can be revoked; ISPs and other > LIRs are tacitly encouraged to revoke space that was > justified by multihoming when said multihoming doesn't > occur; etc) > - reduce deaggregation/holes in areas populated by aggregates > - give network operators additional tools to do *their* jobs > of filtering/fighting black-hatted-ness *without* making it > the RIR's job (ie, i can filter against longest-match abuse > in space knpown to be populated with aggregates AND point > any complainers to the Right Thing) > > > Do I want the RIRs managing the routing tables? No. Do I > want registries to hold confirmed data, audit trails > disambiguated, and everyone playing by the same rules? Yes. > > joe, not enough coffee so i hope this is coherent > > -- > RSUC / GweepNet / Spunk / FnB / Usenix / SAGE > From ppml at rsuc.gweep.net Tue Feb 18 18:20:24 2003 From: ppml at rsuc.gweep.net (Joe Provo) Date: Tue, 18 Feb 2003 18:20:24 -0500 Subject: [ppml] 2002-7 and "Abstract of [...]" In-Reply-To: <002601c2d78e$77606890$f9ecdfd8@laptoy> References: <20030218202307.GA53772@gweep.net> <002601c2d78e$77606890$f9ecdfd8@laptoy> Message-ID: <20030218232024.GA86699@gweep.net> On Tue, Feb 18, 2003 at 01:44:00PM -0700, John M. Brown wrote: > once upon a time we tried to create a data base, RADB, IRR > etc. They don't seem to be getting as much use as they > used to. I don't see that assertion to hold water. RIPE and APNIC run them as part of the registry by default; seems that is the only way to get lazy folks to register stuff. Major (and minor) ISPs run their own IRR nodes and *require* customers to use them. 1239 and 701 are the only real holdouts; one significant IRR node proxy-registers stuff it sees from 1239 too. :-) It isn't a small list at http://www.irr.net/docs/list.html > I am extremely leary of having the RIR's become involved > in "asserting" whats in the routing table. Does this mean you think folks should be routing whatever they please, allocations be damned? Either the allocations are meaningful or they aren't; please choose. Seems that if the registry doesn't care about address squatters then who should? > The failure modes of that database being corrupt, hacked > or fat finger'd are to big to justify the value of it, > IMHO. If someone like ARIN did it I would expect them > to carry a liability policy of multiple millions incase > they fat fingered or other screwed the data up and cause > someone get get dropped off the net that wasn't suppose > to be. Compare and contrast with what is done in RIPE and APNIC spheres if continuing down this thread. I wonder if this notion/assumption/attitude is the explaination why ALTDB still exists and ARINdb is under-populated? Or why most of the 'independant' IRR nodes are in the ARIn sphere? All I was trying to (undercaffenated) do was point out legitimate operationals support of the concept of a "known- to-be-small-net-multihoming-specific" block, a la 2002-7. Not sure how it veered into this arena. See below: > > It is a Very Short step to dedicating and policing space for > > 'officially blessed small multihoming'. This would > > - be consistnt with RIR roles and previous actions (ASNs not > > used for multihomed entities can be revoked; ISPs and other > > LIRs are tacitly encouraged to revoke space that *was* > > justified by multihoming when said multihoming doesn't > > occur; etc) > > - reduce deaggregation/holes in areas populated by aggregates > > - give network operators additional tools to do *their* jobs > > of filtering/fighting black-hatted-ness *without* making it > > the RIR's job (ie, i can filter against longest-match abuse > > in space knpown to be populated with aggregates AND point > > any complainers to the Right Thing) > > > > > > Do I want the RIRs managing the routing tables? No. Do I > > want registries to hold confirmed data, audit trails > > disambiguated, and everyone playing by the same rules? Yes. The above is "support for 2002-7" FWIW. Joe, still too low on coffee -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From ron at aol.net Tue Feb 18 18:36:09 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 18:36:09 -0500 Subject: [ppml] Revocation In-Reply-To: <002701c2d78f$97421220$f9ecdfd8@laptoy> References: <20030218202846.GF22895@aol.net> <002701c2d78f$97421220$f9ecdfd8@laptoy> Message-ID: <20030218233609.GA23709@aol.net> On Tue, Feb 18, 2003 at 01:52:03PM -0700, John M. Brown wrote: > > Now, about allocations and assignments... > > > > Suggested Thread #1: Revocation > > I believe this thread began with the idea of having certain > > services (allocations/assignments) revoked by ARIN under > > given circumstances (namely fostering SPAM). We need to be > > more precise on which resources and under which conditions > > those resources are to be revoked. > > Since there isn't a "standard" lithmus test for what SPAM is, > ARIN can't have a policy to revoke a prefix because of SPAM. > This should be dropped. Spam is a social issue that is not > in the perview of ARIN or any other RIR. If we generalize this thread, what I was asking for is a standard test for when to revoke resources and how. SPAM is only a subset of that discussion. One obvious condition is lack of payment. But, I thought Jeffrey was suggesting other conditions. Certainly if we cannot define (for the purposes of ARIN policy) what SPAM is then we will not be able to create such a policy. I certainly would encourage someone to propose something though to start that discussion rather than to debate whether to have even have the discussion itself. -ron From ron at aol.net Tue Feb 18 19:08:28 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 19:08:28 -0500 Subject: [ppml] Enforcement In-Reply-To: <002701c2d78f$97421220$f9ecdfd8@laptoy> References: <20030218202846.GF22895@aol.net> <002701c2d78f$97421220$f9ecdfd8@laptoy> Message-ID: <20030219000828.GA23737@aol.net> On Tue, Feb 18, 2003 at 01:52:03PM -0700, John M. Brown wrote: > > Suggested Thread #2: Enforcement > > The motor vehicle registry can revoke a license to drive, but > > not stop you from driving your car - that is the role of law > > enforcement. ARIN currently has no mechanism to enforce > > policy other than removing allocations/assignments or other > > database resources. If there is a specific suggestion on how > > ARIN could provide enforcement of resources it manages, > > please take this to that thread (rename the subject please)! > > RIR's are not in the business of providing this service. The liability > risk is way to high. Agreed. But, should someone think otherwise and have some reasonable suggestion on how it could be done then speak up! -ron From ron at aol.net Tue Feb 18 19:10:36 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 19:10:36 -0500 Subject: [ppml] Selling /24's In-Reply-To: <002701c2d78f$97421220$f9ecdfd8@laptoy> References: <20030218202846.GF22895@aol.net> <002701c2d78f$97421220$f9ecdfd8@laptoy> Message-ID: <20030219001036.GB23737@aol.net> On Tue, Feb 18, 2003 at 01:52:03PM -0700, John M. Brown wrote: > > > > Suggested Thread #3: Selling /24's > > There was an assertion that folks are purchasing /24's for > > abuse. Sorry, simple taxonomy correction. No address space > > is ever sold, "leased" is the term here. So, should there be > > an AUP that describes leasing of space downstream? If you > > have suggested policy for that purpose, let's discuss. > > A RIR should not dictate or control, what someone does with > their space in this manner. Having a RIR control that, means > the RIR is controlling the business model for some organization. > Terms like Anti-Trust, Monopoly and other such come to mind > with this thread idea. This is not a suggestion on how it would be done. If everyone agrees that and RIR should not do this and there are not suggested policy changes to reverse this current position, then let this thread die. -ron From ron at aol.net Tue Feb 18 19:12:30 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 19:12:30 -0500 Subject: [ppml] Collaboration with IETF In-Reply-To: <002701c2d78f$97421220$f9ecdfd8@laptoy> References: <20030218202846.GF22895@aol.net> <002701c2d78f$97421220$f9ecdfd8@laptoy> Message-ID: <20030219001230.GC23737@aol.net> On Tue, Feb 18, 2003 at 01:52:03PM -0700, John M. Brown wrote: > > > Suggested Thread #5: Collaboration with IETF > > This might be along the lines of soBGP, etc. for > > authenticating BGP announcements. Perhaps ARIN could provide > > database information for initial AS_to_allocation/assignments > > for BGP auth. ARIN has involvement with IETF and other > > organizations via its staff, the AC and the BOT. If there is > > a particular service or policy that we should discuss > > regarding a specific technology, please suggest it here. > > ARIN involvement with other organizations is more of a staff > > issue though, and not a specific policy topic. (Richard - > > correct me if I'm wrong here!) > > Making use of new protocols that affect allocations and their > uses, is a policy issue to be brought before the membership, > prior to adoption. > sBGP and other such things will take multiple years to role > out, the equipment, IOS-ish, and other costs are way high > to make this a requirement in the short term. *sigh* Does anyone have proposed policy though? -ron From arin_ppml at comcept.net Tue Feb 18 19:49:14 2003 From: arin_ppml at comcept.net (Brian Bergin) Date: Tue, 18 Feb 2003 19:49:14 -0500 Subject: [ppml] Revocation In-Reply-To: <20030219001643.GD23737@aol.net> References: <5.2.1.0.2.20030218190058.02febb28@mail> <002701c2d78f$97421220$f9ecdfd8@laptoy> <20030218202846.GF22895@aol.net> <002701c2d78f$97421220$f9ecdfd8@laptoy> <5.2.1.0.2.20030218190058.02febb28@mail> Message-ID: <5.2.1.0.2.20030218194624.030443d8@mail> At 19:16 18 02 03 Tuesday, you wrote: >Brian - Please send this to ppml at arin.net. In order to have a productive >policy discussion, we need this type of dialogue there. Consider addressing >which contact info is required, optional, how to interface with providers >who are not directly members of ARIN, etc. We should be able to come >up with something that is not friendly to SPAMMERS but also is >acceptable to the ARIN membership and the internet community in general. > >thanks! >-ron I just noticed this, even after I posted earlier about having private discussions. ARIN's lists allow, actually encourage, replies to the sender not the list. That's a poor setup IMHO. One must remember to change the To: to the ARIN address. It's too easy to jot down a reply and hit send without remembering to change the To: address. I would propose a policy change to ARIN that their lists have replies go to the list and not the sender. It's normally a simple change to most list servers, it is on ours. Again, my apologies... Brian From john at chagres.net Tue Feb 18 20:02:00 2003 From: john at chagres.net (John M. Brown) Date: Tue, 18 Feb 2003 18:02:00 -0700 Subject: [ppml] Proposal to change how the PPML LISTServ works Message-ID: <004501c2d7b2$821f11e0$f9ecdfd8@laptoy> I'd agree. Getting added to all the CC's means that active posters end up getting multiple copies of the same thread. this is annoying and a waste. the reply to should be the list. if you want a private reply then edit the to: part of your out going msg. the attached email is in support of this change from another list user. I have recommended this several times to RichardJ at arin, with little to no response. -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Brian Bergin Sent: Tuesday, February 18, 2003 5:49 PM To: ppml at arin.net Subject: Re: [ppml] Revocation At 19:16 18 02 03 Tuesday, you wrote: >Brian - Please send this to ppml at arin.net. In order to have a >productive policy discussion, we need this type of dialogue there. >Consider addressing which contact info is required, optional, how to >interface with providers who are not directly members of ARIN, etc. We >should be able to come up with something that is not friendly to >SPAMMERS but also is acceptable to the ARIN membership and the internet >community in general. > >thanks! >-ron I just noticed this, even after I posted earlier about having private discussions. ARIN's lists allow, actually encourage, replies to the sender not the list. That's a poor setup IMHO. One must remember to change the To: to the ARIN address. It's too easy to jot down a reply and hit send without remembering to change the To: address. I would propose a policy change to ARIN that their lists have replies go to the list and not the sender. It's normally a simple change to most list servers, it is on ours. Again, my apologies... Brian From jrace at attglobal.net Tue Feb 18 20:16:18 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 08:16:18 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice Message-ID: <200302190116.h1J1GWqn098976@smtp1.arin.net> On Tue, 18 Feb 2003 11:34:58 -0600, J Bacher wrote: >The recommendation was that ISPs prevent spam. I'd like to know a solution >that scales. Many thanks for your valuable prodding. I will clarify this and would welcome suggested wording to make my intention clear: ISPs are clarified (in my proposal) to have an affirmative duty to prevent abuse as defined and are liable for damages to victims if they don't. In fact this simply recapitulates the import of th law now, except that it has (to my knowledge) rarely yet been litigated. My point is that the ISPs AT LEAST must establish the enforcement mechanism specified so as to respond to complaints of AUP violation. They should establish a preventive system as well by technical means. This point needs elaboration. Wording welcome. I hasten to add that well-managed service providers do this already; I aim simply to elevate industry standards to the level of the best current operators. For example, my provider here in Bangkok blocks transmission of many types of headers, as a spam deterrent. I must manually modify the headers in many of my spam complaints or I cannot even transmit the message. Jeffrey Race From jrace at attglobal.net Tue Feb 18 20:19:40 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 08:19:40 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) Message-ID: <200302190119.h1J1Jrqn099093@smtp1.arin.net> On Tue, 18 Feb 2003 10:35:33 -0700, John M. Brown wrote: >no they don't The ability to accept routes from a customer >is strictly a matter between the service provider and >its customer. > >We do not need to overload protocols with this type of >data. > >I can see a nice little DDOS vector here. Happy Hacker >tricks BGP into revoking EBAY's prefix, EBAY looses >millions, sues RIR. My original proposal states that action is to be taken only after sufficient investigation to prevent such errors. From traffic on Spam-L it is apparent that joe-jobs and fraudulent routings are discovered in hours by the cognoscenti who live there. Jeffrey Race From owen at delong.com Tue Feb 18 19:58:13 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Feb 2003 16:58:13 -0800 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> References: <200302180958.h1I9w8qn077869@smtp1.arin.net> <5.2.1.0.2.20030218101016.02af0e30@mail.comcept.net> Message-ID: <2147483647.1045587493@imac-en0.delong.sj.ca.us> > To top it all off, many of these blocks, when SWIP'd, contain fraudulent > information. ICANN will revoke a fraudulent or invalid domain > registration why can't ARIN revoke a fraudulent IP SWIP and if the block > owner is found to also have fraudulent or invalid registration > information they should have their entire block revoked. That's the way > the rest of the world works. Do you think the FCC would allow someone to > buy a block of frequencies and give them false contact info? The FCC > would yank the licenses immediately with NO refund. ARIN must evolve to > function like the rest of the world. Apply existing fraud laws. If > someone obtains goods or services under misleading or fraudulent > circumstances no matter the intended use they have violated criminal laws > in every state and Federal laws as well. Why can't ARIN use existing > laws to go after them? > Here's the real problem, as I see it. When a domain is revoked, name service for that domain stops working at the root or TLD level. When ARIN revokes an IP, nothing happens until an ISP stops routing it. Owen From steve at blighty.com Tue Feb 18 21:09:19 2003 From: steve at blighty.com (Steve Atkins) Date: Tue, 18 Feb 2003 18:09:19 -0800 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) In-Reply-To: <200302190119.h1J1Jrqn099093@smtp1.arin.net>; from jrace@attglobal.net on Wed, Feb 19, 2003 at 08:19:40AM +0700 References: <200302190119.h1J1Jrqn099093@smtp1.arin.net> Message-ID: <20030218180919.A3430@blighty.com> On Wed, Feb 19, 2003 at 08:19:40AM +0700, Dr. Jeffrey Race wrote: > On Tue, 18 Feb 2003 10:35:33 -0700, John M. Brown wrote: > >no they don't The ability to accept routes from a customer > >is strictly a matter between the service provider and > >its customer. > > > >We do not need to overload protocols with this type of > >data. > > > >I can see a nice little DDOS vector here. Happy Hacker > >tricks BGP into revoking EBAY's prefix, EBAY looses > >millions, sues RIR. > > My original proposal > states that action is to be taken only after sufficient > investigation to prevent such errors. From traffic on Spam-L > it is apparent that joe-jobs and fraudulent routings are > discovered in hours by the cognoscenti who live there. Wrongly, in many cases. If you work an abuse desk or work with abuse desks you rapidly discover that the universe isn't as obvious as some of the amateurs think it is. Actually investigating to discover the truth of what happened in a particular incident is not trivial. It requires a lot of skill and can be very time-consuming (a latency of weeks or more in some cases that we've handled recently). And an ISP can afford to terminate a customer with very little liability as long as they have reasonable evidence that a customer violated their contract (which usually includes an AUP by reference). That's a much easier position than a third-party would be in. I wouldn't care to be in the position of an RIR trying to do that, let alone having to fund the abuse investigation team and legal staff that would be needed to do so. Cheers, Steve -- -- Steve Atkins -- steve at blighty.com -- http://word-to-the-wise.com/ From jrace at attglobal.net Tue Feb 18 20:29:31 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 08:29:31 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <200302190129.h1J1Tiqn099404@smtp1.arin.net> See inline comments On Tue, 18 Feb 2003 10:42:25 -0700, John M. Brown wrote: >Lovely conversation about RIR's fighting SPAM, Hackers >and that the RIR's should have the power to revoke routing >and IP space for these evil doers. > >Lets get real for a moment, eh... > >1. RIR's are not the place to fight the spam problem. > The intent of this proposal is to remove the burden of abuse from the victims, and place it where it properly belongs, on the abusers (spammers) and their enablers (ISPs and RIRs among others), without requiring any technical cost metering system. This is the way the rest of the society and the economy works. The Internet is such a mess because it is exempted from the normal rules that govern human behavior. If you don't agree with placing the burden of the damages on those who create them, then you will find thousands of ways to nitpick my proposal. > Washington or your local equiv is. > > You should be asking your Senators / Congress Critters > why they keep killing Federal Anti-Spam legislation, > why they keep taking reasonable bills and turning them > into mush. > For the simple reason explained in the proposal no legislation will ever succeed in decreasing spam. > >2. RIR's are not the place to fight hackers, DDOS'rs etc > The RIRs are key enablers because they delegate the abused resource. > > If you want to keep your network from being hacked > place a firewall and participate in the security > of your network, You continue to live in the "let the victims pay" world. We no longer let GE dump pcbs into streams in Pittsfield Massachusetts. Why should we let spammers dump their trash onto the Internet without penalty? which is a constant activity. > > If you want to stop DDOS, then filter the edge of the > the network and prevent bad packets from leaving YOUR > network. > "Let the victims pay" > > >Having the RIR's control the routing tables is a pandora's >box you all really really don't want to have opened up. It >will lead to bad laws, The purpose of this proposal is to AVOID unpleasant legislation by cleaning up our own sandbox. If you leave it filled with dog excrement, then the health inspectors will soon come. This has proven true in industry after industry. Look at what is happening in the securities industry. anti-trust issues, RIR's will have >a monopoly of control that you don't want. I'd be pleased if you'd elaborate on the details of any genuinely foreseeable scenarios you envison. Jeffrey Race From owen at delong.com Tue Feb 18 20:40:29 2003 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Feb 2003 17:40:29 -0800 Subject: [ppml] Revocation In-Reply-To: <5.2.1.0.2.20030218194624.030443d8@mail> References: <5.2.1.0.2.20030218190058.02febb28@mail> <002701c2d78f$97421220$f9ecdfd8@laptoy> <20030218202846.GF22895@aol.net> <002701c2d78f$97421220$f9ecdfd8@laptoy> <5.2.1.0.2.20030218190058.02febb28@mail> <5.2.1.0.2.20030218194624.030443d8@mail> Message-ID: <2147483647.1045590029@imac-en0.delong.sj.ca.us> Count this as my vote to keep it the way it is. I find lists that set the Reply-To to the list annoying. Owen --On Tuesday, February 18, 2003 7:49 PM -0500 Brian Bergin wrote: > At 19:16 18 02 03 Tuesday, you wrote: >> Brian - Please send this to ppml at arin.net. In order to have a productive >> policy discussion, we need this type of dialogue there. Consider >> addressing which contact info is required, optional, how to interface >> with providers who are not directly members of ARIN, etc. We should be >> able to come up with something that is not friendly to SPAMMERS but also >> is >> acceptable to the ARIN membership and the internet community in general. >> >> thanks! >> -ron > > I just noticed this, even after I posted earlier about having private > discussions. ARIN's lists allow, actually encourage, replies to the > sender not the list. That's a poor setup IMHO. One must remember to > change the To: to the ARIN address. It's too easy to jot down a reply > and hit send without remembering to change the To: address. > > I would propose a policy change to ARIN that their lists have replies go > to the list and not the sender. It's normally a simple change to most > list servers, it is on ours. > > Again, my apologies... > > Brian From jmcburnett at msmgmt.com Tue Feb 18 20:51:21 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Tue, 18 Feb 2003 20:51:21 -0500 Subject: [ppml] List modification Message-ID: <390E55B947E7C848898AEBB9E50770600EB5FA@msmdcfs01.msmgmt.com> In support of Owen: 1. I Agree 2. Due to the massive amounts of email I get, I use rules to redirect it to a special ARIN folder. When someone does a Reply All, the email hits instant notice. 3. If it was set up this way, and has been for so long, why change it now? Jim > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Tuesday, February 18, 2003 8:40 PM > To: Brian Bergin; ppml at arin.net > Subject: Re: [ppml] Revocation > > > Count this as my vote to keep it the way it is. I find lists that set > the Reply-To to the list annoying. > > Owen > > > --On Tuesday, February 18, 2003 7:49 PM -0500 Brian Bergin > wrote: > > > At 19:16 18 02 03 Tuesday, you wrote: > >> Brian - Please send this to ppml at arin.net. In order to > have a productive > >> policy discussion, we need this type of dialogue there. Consider > >> addressing which contact info is required, optional, how > to interface > >> with providers who are not directly members of ARIN, etc. > We should be > >> able to come up with something that is not friendly to > SPAMMERS but also > >> is > >> acceptable to the ARIN membership and the internet > community in general. > >> > >> thanks! > >> -ron > > > > I just noticed this, even after I posted earlier about > having private > > discussions. ARIN's lists allow, actually encourage, replies to the > > sender not the list. That's a poor setup IMHO. One must > remember to > > change the To: to the ARIN address. It's too easy to jot > down a reply > > and hit send without remembering to change the To: address. > > > > I would propose a policy change to ARIN that their lists > have replies go > > to the list and not the sender. It's normally a simple > change to most > > list servers, it is on ours. > > > > Again, my apologies... > > > > Brian > > > From jrace at attglobal.net Tue Feb 18 20:46:29 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 08:46:29 +0700 Subject: [ppml] comments on various new possible threads Message-ID: <200302190203.h1J23rqn000173@smtp1.arin.net> See inline comments On Tue, 18 Feb 2003 13:52:03 -0700, John M. Brown wrote: [snip] >> >> Suggested Thread #1: Revocation >> I believe this thread began with the idea of having certain >> services (allocations/assignments) revoked by ARIN under >> given circumstances (namely fostering SPAM). We need to be >> more precise on which resources and under which conditions >> those resources are to be revoked. > >Since there isn't a "standard" lithmus test for what SPAM is, >ARIN can't have a policy to revoke a prefix because of SPAM. I have nominated a definition of abuse which would capture 99.9% of it with (so far as I can tell) no false positives. Please look at it and critique. > >This should be dropped. Spam is a social issue that is not >in the perview of ARIN or any other RIR. > Well for me (as victim) spam is a MONEY issue because of all the resources I have to devote to dealing with it. I can't put an e-mail address or a on my firm's website because of the spam menace. My colleague's machine was taken down for several days because of a virus infection, and I had to help him clean it. Please get out of the "let the victims pay" model. >> Suggested Thread #2: Enforcement >> The motor vehicle registry can revoke a license to drive, but >> not stop you from driving your car - that is the role of law >> enforcement. ARIN currently has no mechanism to enforce >> policy other than removing allocations/assignments or other >> database resources. If there is a specific suggestion on how >> ARIN could provide enforcement of resources it manages, >> please take this to that thread (rename the subject please)! > >RIR's are not in the business of providing this service. They delegate the resources and so they are the enablers. They cannot, like Pilate, say "I wash my hands of the consequences of my actions" The liability >risk is way to high. Buy insurance. Why should I (the victim) have to pay? > >> Suggested Thread #3: Selling /24's >> There was an assertion that folks are purchasing /24's for >> abuse. Sorry, simple taxonomy correction. No address space >> is ever sold, "leased" is the term here. So, should there be >> an AUP that describes leasing of space downstream? If you >> have suggested policy for that purpose, let's discuss. > >A RIR should not dictate or control, what someone does with >their space in this manner. Having a RIR control that, means >the RIR is controlling the business model for some organization. YES! It controls it to the extent that it forbids and Environmental Polluter business model. You understand it now! Wonderful! >Terms like Anti-Trust, Monopoly and other such come to mind >with this thread idea. ICANN enforces revocation of domain names for fraud. No reason the RIRs can't do the same thing. > >> Suggested Thread #5: Collaboration with IETF >> This might be along the lines of soBGP, etc. for >> authenticating BGP announcements. Perhaps ARIN could provide >> database information for initial AS_to_allocation/assignments >> for BGP auth. ARIN has involvement with IETF and other >> organizations via its staff, the AC and the BOT. If there is >> a particular service or policy that we should discuss >> regarding a specific technology, please suggest it here. >> ARIN involvement with other organizations is more of a staff >> issue though, and not a specific policy topic. (Richard - >> correct me if I'm wrong here!) > >Making use of new protocols that affect allocations and their >uses, is a policy issue to be brought before the membership, >prior to adoption. > >sBGP and other such things will take multiple years to role >out, the equipment, IOS-ish, and other costs are way high >to make this a requirement in the short term. > > Lots of things can be done manually TODAY. I am sick of quarreling with RIRs who reply (in answer to complaints of bouncing mail to of delegated IP addresses) "Not our business, go away". It's disgusting and a halt needs to be called right now to this behavior. Jeffrey Race From jrace at attglobal.net Tue Feb 18 20:47:42 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 08:47:42 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <200302190206.h1J26nqn000230@smtp1.arin.net> On Tue, 18 Feb 2003 15:04:36 -0700, Taylor, Stacy wrote: >Speaking only for myself, I believe it is absolutely not for the RIR to >police or monitor use of blocks. The Registry is there for just that: to >keep track of who is using what. It must not be responsible for pulling >routes or revoking rights for abuse reasons. > >The onus must ultimately be on the upstream operators to maintain the >integrity of the blocks: both for contiguity and for purity. The only "onus" they will recognize is loss of their space. Jeffrey Race From jrace at attglobal.net Tue Feb 18 20:50:37 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 08:50:37 +0700 Subject: [ppml] Revocation Message-ID: <200302190207.h1J27pqn000295@smtp1.arin.net> On Tue, 18 Feb 2003 18:36:09 -0500, Ron da Silva wrote: >other conditions. Certainly if we cannot define (for the >purposes of ARIN policy) what SPAM is then we will not be >able to create such a policy. See Sec. 6. Jeffrey Race From john at chagres.net Tue Feb 18 21:08:02 2003 From: john at chagres.net (John M. Brown) Date: Tue, 18 Feb 2003 19:08:02 -0700 Subject: [ppml] List modification In-Reply-To: <390E55B947E7C848898AEBB9E50770600EB5FA@msmdcfs01.msmgmt.com> Message-ID: <005e01c2d7bb$bbb0fd70$f9ecdfd8@laptoy> if the PPML list is cc'd and not the prime, you then have to have multiple rules. In addition you get multiple copies of the same email. For example: This email will send to Jim and Owen, plus the list, which will send it to Jim and Owen AGAIN So Jim and Owen will get this message TWICE, have to filter twice and store twice. Having the list set reply-to: to the list reduces this to only one email each. It also ensures that the LIST is receiving mail. Count this as my vote to CHANGE THE LIST AND SET REPLY-TO: towards the list thanks > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of McBurnett, Jim > Sent: Tuesday, February 18, 2003 6:51 PM > To: Owen DeLong; ppml at arin.net > Subject: [ppml] List modification > > > In support of Owen: > 1. I Agree > 2. Due to the massive amounts of email I get, > I use rules to redirect it to a special ARIN > folder. When someone does a Reply All, the email > hits instant notice. > 3. If it was set up this way, and has been for so long, why > change it now? > > Jim > > > -----Original Message----- > > From: Owen DeLong [mailto:owen at delong.com] > > Sent: Tuesday, February 18, 2003 8:40 PM > > To: Brian Bergin; ppml at arin.net > > Subject: Re: [ppml] Revocation > > > > > > Count this as my vote to keep it the way it is. I find > lists that set > > the Reply-To to the list annoying. > > > > Owen > > > > > > --On Tuesday, February 18, 2003 7:49 PM -0500 Brian Bergin > > wrote: > > > > > At 19:16 18 02 03 Tuesday, you wrote: > > >> Brian - Please send this to ppml at arin.net. In order to > > have a productive > > >> policy discussion, we need this type of dialogue there. > Consider > > >> addressing which contact info is required, optional, how > > to interface > > >> with providers who are not directly members of ARIN, etc. > > We should be > > >> able to come up with something that is not friendly to > > SPAMMERS but also > > >> is > > >> acceptable to the ARIN membership and the internet > > community in general. > > >> > > >> thanks! > > >> -ron > > > > > > I just noticed this, even after I posted earlier about > > having private > > > discussions. ARIN's lists allow, actually encourage, > replies to the > > > sender not the list. That's a poor setup IMHO. One must > > remember to > > > change the To: to the ARIN address. It's too easy to jot > > down a reply > > > and hit send without remembering to change the To: address. > > > > > > I would propose a policy change to ARIN that their lists > > have replies go > > > to the list and not the sender. It's normally a simple > > change to most > > > list servers, it is on ours. > > > > > > Again, my apologies... > > > > > > Brian > > > > > > > From ron at aol.net Tue Feb 18 21:33:02 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 21:33:02 -0500 Subject: [ppml] Revocation In-Reply-To: <200302190207.h1J276E09092@postman5.mx.aol.com> References: <200302190207.h1J276E09092@postman5.mx.aol.com> Message-ID: <20030219023302.GD23786@aol.net> On Wed, Feb 19, 2003 at 08:50:37AM +0700, Dr. Jeffrey Race wrote: > On Tue, 18 Feb 2003 18:36:09 -0500, Ron da Silva wrote: > >other conditions. Certainly if we cannot define (for the > >purposes of ARIN policy) what SPAM is then we will not be > >able to create such a policy. > > See Sec. 6. s/UBE/SPAM/ ----- UBE shall mean - messages, regardless of content, sent in multiple similar or identical copies to recipients who did not request to receive such messages from their sender. In deciding whether a transmission shall be deemed UBE, common sense shall be applied encompassing the totality of facts knowable about the transmission including subject line, actual content, source of addresses, falsification of message parts, use of promiscuous relays or proxies or other abusable resources, obfuscation of return path or true identity of sender, or history of sender's previous abuse as recorded in any accessible database. ----- Ok, suppose we define spam as above. Now what? Is there a mechanism to traceback ARIN resources currently in use by the originator? (As well as a clear mechanism to traceback the sender himself!) And then, suppose we have identified that entity and its ARIN resources but that entity is not a direct member of ARIN. What action do you propose be taken? -ron From ron at aol.net Tue Feb 18 21:37:18 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 21:37:18 -0500 Subject: [ppml] Proposal to change how the PPML LISTServ works In-Reply-To: <004501c2d7b2$821f11e0$f9ecdfd8@laptoy> References: <004501c2d7b2$821f11e0$f9ecdfd8@laptoy> Message-ID: <20030219023718.GE23786@aol.net> Hmm...FWIW I agree with Owen and prefer to explicitly set To: Cc: From: etc... I don't like listservs that try to do it for me. But then again, a good mailer will let you do whatever you want... Ignore-Reply-To: etc.. -ron From ron at aol.net Tue Feb 18 22:11:12 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 18 Feb 2003 22:11:12 -0500 Subject: [ppml] Revocation In-Reply-To: <200302190116.h1J1GWqn098976@smtp1.arin.net> <200302190119.h1J1Jrqn099093@smtp1.arin.net> <20030218180919.A3430@blighty.com> <200302190129.h1J1Tiqn099404@smtp1.arin.net> <200302190203.h1J23rqn000173@smtp1.arin.net> <20030219023302.GD23786@aol.net> References: <200302190116.h1J1GWqn098976@smtp1.arin.net> <200302190119.h1J1Jrqn099093@smtp1.arin.net> <200302190119.h1J1Jrqn099093@smtp1.arin.net> <20030218180919.A3430@blighty.com> <200302190129.h1J1Tiqn099404@smtp1.arin.net> <200302190203.h1J23rqn000173@smtp1.arin.net> <200302190207.h1J276E09092@postman5.mx.aol.com> <20030219023302.GD23786@aol.net> Message-ID: <20030219031112.GA23842@aol.net> On Wed, Feb 19, 2003 at 08:19:40AM +0700, Dr. Jeffrey Race wrote: > My original proposal > states that action is to be taken only after sufficient > investigation to prevent such errors. How do you define "sufficient investigation" ?? On Wed, Feb 19, 2003 at 08:29:31AM +0700, Dr. Jeffrey Race wrote: > The RIRs are key enablers because they delegate the abused > resource. I think you mean, "RIRs delegate resources that later get abused." On Wed, Feb 19, 2003 at 08:46:29AM +0700, Dr. Jeffrey Race wrote: > I have nominated a definition of abuse which would capture > 99.9% of it with (so far as I can tell) no false positives. > Please look at it and critique. I read through the "abuse" definition in section 6 and have a concern: "Abuse shall be deemed a pattern of offensive behavior..." I think "pattern" needs to be specific. How is a pattern of this behavior defined, exactly? > Buy insurance [to cover litigation costs] Interesting suggestion for ARIN staff...(which I'm sure they'll consider)..but probably not directly a policy topic. -ron From john at chagres.net Tue Feb 18 22:20:41 2003 From: john at chagres.net (John M. Brown) Date: Tue, 18 Feb 2003 20:20:41 -0700 Subject: [ppml] Revocation In-Reply-To: <20030219031112.GA23842@aol.net> Message-ID: <006501c2d7c5$e1c8fd50$f9ecdfd8@laptoy> > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Ron da Silva > > > Buy insurance [to cover litigation costs] > > Interesting suggestion for ARIN staff...(which I'm sure > they'll consider)..but probably not directly a policy topic. True, but policy needs to reflect cost structures as well. I'd hate to see us approve a policy and then find out what the cost impact is after the fact. Yes, Ron, I believe that ARIN staff and the BOT would not do that! > -ron > From jmcburnett at msmgmt.com Tue Feb 18 22:48:26 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Tue, 18 Feb 2003 22:48:26 -0500 Subject: [ppml] Revocation Message-ID: <390E55B947E7C848898AEBB9E50770600EB5FB@msmdcfs01.msmgmt.com> > > s/UBE/SPAM/ > ----- > UBE shall mean > > - messages, regardless of content, sent in multiple similar or > identical copies to recipients who did not request to receive > such messages from their sender. > > In deciding whether a transmission shall be deemed UBE, common sense > shall be applied encompassing the totality of facts knowable about the > transmission including subject line, actual content, source of > addresses, falsification of message parts, use of promiscuous relays > or proxies or other abusable resources, obfuscation of return path or > true identity of sender, or history of sender's previous abuse as > recorded in any accessible database. > ----- Add: Falsifacation includes, but is not limited to, the use of IP addresses or DNS information in the header that is known to be reserved by IANA... I just got 7 messages with IANA reserved blocks in the header.... anyway.... Jim > Ok, suppose we define spam as above. Now what? Is there a mechanism > to traceback ARIN resources currently in use by the > originator? (As well > as a clear mechanism to traceback the sender himself!) And > then, suppose > we have identified that entity and its ARIN resources but that entity > is not a direct member of ARIN. What action do you > propose be taken? > > -ron > > From jrace at attglobal.net Wed Feb 19 04:06:31 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 16:06:31 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <200302190906.h1J96qqn004680@smtp1.arin.net> On Tue, 18 Feb 2003 16:58:13 -0800, Owen DeLong wrote: >Here's the real problem, as I see it. When a domain is revoked, name >service >for that domain stops working at the root or TLD level. When ARIN revokes >an IP, nothing happens until an ISP stops routing it. I am interested in learning more about the technical measures which the RIRs can employ to prevent fraudulent use of IP address space (which is now occasionally reported on Spam-L already). But at the level of the draft BCP, I am considering to add a new type of abuse: - announcing a non-delegated route or other fraudulent use of IP address space. Comments invited on * wording (correctness, inclusiveness) * practical effectiveness. Those following the draft BCP would blocklist the offending ISP. These things would get around pretty quickly. Jeffrey Race From jrace at attglobal.net Wed Feb 19 04:17:22 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 16:17:22 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best CurrentPractice (please comment) Message-ID: <200302190918.h1J9IOqn004756@smtp1.arin.net> On Tue, 18 Feb 2003 18:09:19 -0800, Steve Atkins wrote: >And an ISP can afford to terminate a customer with very little >liability as long as they have reasonable evidence that a customer >violated their contract (which usually includes an AUP by reference). >That's a much easier position than a third-party would be in. > >I wouldn't care to be in the position of an RIR trying to do that, let >alone having to fund the abuse investigation team and legal staff that >would be needed to do so. This is an interesting point so please clarify it so that I may clarify my proposal as necessary. >From a reading of my draft text, the revocation of IP address space would be consequent to a (months-long) pattern of ignoring documented complaints or refusing to enable or (once enabled) operate or other RFC-mandated role accounts. These are easily and irrefutably documented and not susceptible to joe-jobs. I have one particular case in mind (in APNIC space) where the service provider brazenly ignores all complaints about spam. This is the kind of scum who should be shut off. So what is the particular problematical scenario you foresee, so that we can come up with a strategy to deal with it? Jeffrey Race From jrace at attglobal.net Wed Feb 19 04:29:42 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 16:29:42 +0700 Subject: [ppml] Revocation Message-ID: <200302190930.h1J9Txqn004844@smtp1.arin.net> See inline comments On Tue, 18 Feb 2003 21:33:02 -0500, Ron da Silva wrote: >Ok, suppose we define spam as above. Now what? Is there a mechanism >to traceback ARIN resources currently in use by the originator? Yes I do a lookup on the upload and return paths (see for my MO). (As well >as a clear mechanism to traceback the sender himself!) We don't need that because (in the case of an open relay or proxy, or dialup) it is the responsibility of the custodian of the Internet resources (e.g. mail servers or modem pools) used. The custodian of these resources is responsible for taking action. And then, suppose >we have identified that entity and its ARIN resources but that entity >is not a direct member of ARIN. What action do you >propose be taken? Here's where I need your help. I don't want to make the proposal too specific. But I want it clear that there is a chain of custody of delegated resources and they come with conditions. I don't know how it is done now. Contracts might have to be rewritten. It is clear with the well-managed ISPs and backbones: they have an abuse-forbidding AUP and it binds every contracting and sub- contracting party. Something like this needs to be enforced for IP addresses delegations. The irreducibly essential point is that this public resource is borrowed for use during good behavior. As noted in previous post, the RIRs only would become involved in cases of prolonged egregious negligence or tortious conduct. If it were known that address space could be yanked, the bad hats would not dare to misbehave as at present. Comments please . . . . Jeffrey Race From chris at telespan.co.uk Wed Feb 19 04:33:24 2003 From: chris at telespan.co.uk (Chris Jones) Date: Wed, 19 Feb 2003 09:33:24 -0000 Subject: [ppml] Proposal to change how the PPML LISTServ works In-Reply-To: <004501c2d7b2$821f11e0$f9ecdfd8@laptoy> Message-ID: <000d01c2d7f9$f6c995f0$0100a8c0@gandalf> > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of John > M. Brown > Sent: 19 February 2003 01:02 > To: ppml at arin.net > Subject: [ppml] Proposal to change how the PPML LISTServ works > > > > I'd agree. Getting added to all the CC's means that > active posters end up getting multiple copies of the > same thread. this is annoying and a waste. > > the reply to should be the list. if you want a private > reply then edit the to: part of your out going msg. > > the attached email is in support of this change from another > list user. I totally agree with John here. Most other mailing lists are configured to reply to the list, allowing the responder to *add* other recipients if they consider this necessary. -- >From Chris Jones mailto: chris at telespan.co.uk web: http://www.telespan.co.uk/ My PGP Key:- RSA 2048/1024 Key ID: 0x2B1F1593 Fingerprint: B073 FE31 0A6A 6BD6 C4DB 750D 2B30 D0E7 2B1F 1593 From randy at psg.com Wed Feb 19 04:41:52 2003 From: randy at psg.com (Randy Bush) Date: Wed, 19 Feb 2003 18:41:52 +0900 Subject: [ppml] Proposal to change how the PPML LISTServ works References: <004501c2d7b2$821f11e0$f9ecdfd8@laptoy> <000d01c2d7f9$f6c995f0$0100a8c0@gandalf> Message-ID: >> the reply to should be the list. if you want a private >> reply then edit the to: part of your out going msg. a fantastic recipe to cause major public embarrassment to someone hitting the reply key and thinking they are sending privately to the From: > Most other mailing lists are configured to reply to the list false assertion randy From jrace at attglobal.net Wed Feb 19 04:41:32 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Wed, 19 Feb 2003 16:41:32 +0700 Subject: [ppml] Revocation Message-ID: <200302190942.h1J9gcqn005062@smtp1.arin.net> See inline comments On Tue, 18 Feb 2003 22:11:12 -0500, Ron da Silva wrote: >How do you define "sufficient investigation" ?? Adequate to prevent error according to the facts and complexity of the incident > >On Wed, Feb 19, 2003 at 08:29:31AM +0700, Dr. Jeffrey Race wrote: >> The RIRs are key enablers because they delegate the abused >> resource. > >I think you mean, "RIRs delegate resources that later get abused." > Precisely >On Wed, Feb 19, 2003 at 08:46:29AM +0700, Dr. Jeffrey Race wrote: >> I have nominated a definition of abuse which would capture >> 99.9% of it with (so far as I can tell) no false positives. >> Please look at it and critique. > >I read through the "abuse" definition in section 6 and have a >concern: "Abuse shall be deemed a pattern of offensive behavior..." >I think "pattern" needs to be specific. How is a pattern >of this behavior defined, exactly? I guess we could look in our dictionaries but for me, in this matter, I would define it as a multiplicity of facts which demonstrate an intention to abuse. Very very occasionally there are (in my experience) gray areas, and I have reformed a few incipient spammers who thought what they were doing was legitimate. However almost in their entirety spammers know what they are doing is wrong and take careful steps to conceal their identities on both the upload path (e.g. use open relays or abusable proxies or scripts) and the return path (e.g. using untraceable toll-free numbers, answering machines). I should stress one point: the RIRs are not intended in my plan to be acting against spammers. That is not their or our job. They would act against delegatees of the IP address space who operated on the Environmental Polluter business model by allowing open relays, abusable proxies and scripts and the like and by not responding to abuse complaints. I believe the mallet of IP address space withdrawal would have to be used very rarely (if at all) once it were announced that this sanction existed. (As every parent knows . . . . ) Jeffrey Race From keith.talent at eudoramail.com Wed Feb 19 08:14:40 2003 From: keith.talent at eudoramail.com (Keith Talent) Date: Wed, 19 Feb 2003 23:14:40 +1000 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: >>2. RIR's are not the place to fight hackers, DDOS'rs etc > > The RIRs are key enablers because they delegate the abused >resource. What does spam have to do with IP addresses? How is the RIR any more responsible than the vendor who sells someone a router? ...or the software company who provides the email software? ...or the power company that sells the electricity? This seems a very strange way of looking at the problem. And what happens to all the non-spamming customers of an ISP who has their addresses revoked on the basis that a another customer spams? Will each of those innocent customers have a potential lawsuit? ********************************* Keith Talent Snr Sys Admin MSCE DART Problem? What problem? ********************************* Need a new email address that people can remember Check out the new EudoraMail at http://www.eudoramail.com From John.Sweeting at teleglobe.com Wed Feb 19 08:46:57 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Wed, 19 Feb 2003 08:46:57 -0500 Subject: [ppml] Proposal to change how the PPML LISTServ works Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BE53@usresms03.teleglobe.com> In all fairness to RichardJ and the ARIN staff I have never seen this request on any of the ARIN mailing lists. It is good that it has now been officially requested on the PPML as there will be an archive of the request. I would suggest that everyone that has a request of ARIN that affects the public at large to officially voice it on the PPML in order that it be documented in the archives. This will keep us out of the "he said", "she said", "I requested but received no response" mode. Thanks. BTW this is not directed at John but to everyone that participates on this list. -----Original Message----- From: John M. Brown [mailto:john at chagres.net] Sent: Tuesday, February 18, 2003 8:02 PM To: ppml at arin.net Subject: [ppml] Proposal to change how the PPML LISTServ works I'd agree. Getting added to all the CC's means that active posters end up getting multiple copies of the same thread. this is annoying and a waste. the reply to should be the list. if you want a private reply then edit the to: part of your out going msg. the attached email is in support of this change from another list user. I have recommended this several times to RichardJ at arin, with little to no response. -----Original Message----- From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of Brian Bergin Sent: Tuesday, February 18, 2003 5:49 PM To: ppml at arin.net Subject: Re: [ppml] Revocation At 19:16 18 02 03 Tuesday, you wrote: >Brian - Please send this to ppml at arin.net. In order to have a >productive policy discussion, we need this type of dialogue there. >Consider addressing which contact info is required, optional, how to >interface with providers who are not directly members of ARIN, etc. We >should be able to come up with something that is not friendly to >SPAMMERS but also is acceptable to the ARIN membership and the internet >community in general. > >thanks! >-ron I just noticed this, even after I posted earlier about having private discussions. ARIN's lists allow, actually encourage, replies to the sender not the list. That's a poor setup IMHO. One must remember to change the To: to the ARIN address. It's too easy to jot down a reply and hit send without remembering to change the To: address. I would propose a policy change to ARIN that their lists have replies go to the list and not the sender. It's normally a simple change to most list servers, it is on ours. Again, my apologies... Brian From chris at telespan.co.uk Wed Feb 19 08:56:54 2003 From: chris at telespan.co.uk (Chris Jones) Date: Wed, 19 Feb 2003 13:56:54 -0000 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: Message-ID: <003801c2d81e$c4db4c80$0100a8c0@gandalf> > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Keith > Talent > Sent: 19 February 2003 13:15 > To: ppml at arin.net > Subject: RE: [ppml] Abstract of proposed Internet Draft for > Best Current > Practice (please comment) > > > > >>2. RIR's are not the place to fight hackers, DDOS'rs etc > > > > The RIRs are key enablers because they delegate the abused > >resource. > > > What does spam have to do with IP addresses? > Each and every item of spam originates from one (or more) ip addresses. > How is the RIR any more responsible than the vendor who sells > someone a router? > The RIR's are "responsible" for maintaining the register of IP address blocks. The LIR/ISPs are responsible for maintaining their allocated blocks. This includes (in the case of the majority of LIR/ISP's) ensuring that generally accepted internet rules are *complied* with. > And what happens to all the non-spamming customers of an ISP > who has their addresses revoked on the basis that a another > customer spams? Will each of those innocent customers have a > potential lawsuit? They will quickly realise that, should this happen, that their ISP has breached the rules and that they have a choice. Stay with the ISP who now cannot service their customers needs, or change to another ISP, probably one who *does* implement (and police) acceptable AUP's. -- >From Chris Jones mailto: chris at telespan.co.uk web: http://www.telespan.co.uk/ My PGP Key:- RSA 2048/1024 Key ID: 0x2B1F1593 Fingerprint: B073 FE31 0A6A 6BD6 C4DB 750D 2B30 D0E7 2B1F 1593 From Michael.Dillon at radianz.com Wed Feb 19 09:38:51 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Wed, 19 Feb 2003 14:38:51 +0000 Subject: [ppml] Withdrawal of 2002-7 Message-ID: My take on the discussion of 2002-7 is that it is bad policy because it mixes too many issues together. I have nothing against an omnibus policy as long as it is well organized so that the individual issues are clear in and of themselves. But 2002-7 doesn't do that and as a result the discussion just keeps going around in twisted and convoluted circles. Therefore, I suggest that ARIN should set aside this policy proposal and not give it any further consideration. Ron Da Silva has made a very good suggestion for separating the distinct items and discussing them in separate threads. I would like to further suggest that these items be discussed with an intent to turn them into a series of separate policy proposals. To refresh your memories, Ron suggested that we should deal with the following separate issues: Revocation - under what conditions should ARIN revoke an address allocation? Should this action extend to include assignments? Enforcement - what actions should ARIN take to enforce its allocations and its policies, if any? Leasing - what AUP should ARIN impose on anyone receiving an allocation to ensure that any "lease terms" are passed on to sub-allocations and assignments? Accuracy of data - what is ARIN's policy regarding the accuracy of SWIP and rwhois data? How will ARIN enforce this policy? Then he suggested an item regarding IETF cooperation that wasn't clear to me but which appears to include my following suggestion: Public Authoritative Directory: ---------------------------- ARIN will publish an authoritative directory for all of the IP address space which it administers. This directory will be public and will be published using LDAP v3 also known as referral LDAP. Only a minimal set of information will be made fully public, i.e. one email address and one phone number per organization along with the organization's name and city. Additional contact information, personal names and street addresses will be in the directory but will only be accessible to ARIN members who are in posession of suitable credentials. The intent is to facilitate communication while inhibiting email address scraping and stalking. All organizations receiving ARIN allocations must either maintain an accurate record of their sub-allocations and assignment with ARIN or they must operate an LDAP v3 server containing such information and open to the public. ARIN will ensure that existence information is updated in this directory on a daily basis. Existence information refers to the fact that an allocation exists, i.e. it has been allocated and has not been revoked. ARIN will also do a twice yearly audit of the accuracy of the contact information in this database. When contacts do not respond, the data in the ARIN database will be replaced with contact info for the next level up in the hierarchy. In other words, if an ISP gets address space from UUNet and does not respond during the audit, then ARIN will record UUNet contact info for this ISP. The intent is to ensure that there is an identifiable and responsive contact for all address space that is legitimately in use. ARIN will provide a mirroring mechanism for this directory and encourage organizations to mirror the entire directory for use in their firewalls, route servers, etc. ARIN will warn that it is not good engineering practice to connect this directory directly to BGP route filters but will not prohibit the practice. However ARIN will disclaim all responsibility for any damage that may result from such misuse. Please CHANGE THE SUBJECT if you wish to discuss one of these policy items. ---- Michael Dillon From ron at aol.net Wed Feb 19 09:58:33 2003 From: ron at aol.net (Ron da Silva) Date: Wed, 19 Feb 2003 09:58:33 -0500 Subject: [ppml] Revocation In-Reply-To: <200302190929.EAA24852@postman4.mx.aol.com> References: <200302190929.EAA24852@postman4.mx.aol.com> Message-ID: <20030219145833.GG23909@aol.net> On Wed, Feb 19, 2003 at 04:29:42PM +0700, Dr. Jeffrey Race wrote: > > Yes I do a lookup on the upload and return paths (see > http://www.camblab.com/nugget/extermin.htm for my MO). Interesting redirect in your document to Va Code ? 18.2-152.1-15... (I think your annotation reference is incorrect though). In particular, http://leg1.state.va.us/cgi-bin/legp504.exe?000+cod+18.2-152.12 regarding SPAM which seems to exempt the transiting relay or ISP. Anyhow, I read through your methodology and see how you identify an ip address associated with the SPAM (last relay before delivery to recipient). That address may be the originator, a friendly supporter of the originator, a compromised host, an open relay (intentional or unintentional), etc. The next step is the difficult part. We can correlate that address with some allocation or assignment by an RIR. What next? > Here's where I need your help. I don't want to make the proposal > too specific. But I want it clear that there is a chain of custody > of delegated resources and they come with conditions. Unfortunately, policy needs to be specific in order to be effective. I think the best thing to do would be for you to consider under what conditions do you propose ARIN take action and what actions should be taken. You (and anyone else that would like to help you with this proposal) need to be as specific as possible. > As noted in previous post, the RIRs only would become involved in > cases of prolonged egregious negligence or tortious conduct. Great step in getting more specific. Need to define "prolonged egregious negligence" though and then the associated proposed actions by ARIN. -ron From jsw at five-elements.com Wed Feb 19 12:16:30 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 19 Feb 2003 12:16:30 -0500 Subject: [ppml] Withdrawal of 2002-7 In-Reply-To: References: Message-ID: <1045674991.737.24.camel@intrepid> On Wed, 2003-02-19 at 09:38, Michael.Dillon at radianz.com wrote: > My take on the discussion of 2002-7 is that it is bad policy because it > mixes too many issues together. I have nothing against an omnibus policy > as long as it is well organized so that the individual issues are clear in > and of themselves. But 2002-7 doesn't do that and as a result the > discussion just keeps going around in twisted and convoluted circles. > > Therefore, I suggest that ARIN should set aside this policy proposal and > not give it any further consideration. >From an outsider's perspective, it seems that no progress is being made to implement this or any other policy to serve the addressing needs of small multihomers. Perhaps I should relocate my headquarters to a country which is served by LACNIC? -- Jeff S Wheeler From owen at delong.com Wed Feb 19 12:55:46 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Feb 2003 09:55:46 -0800 Subject: [ppml] List modification In-Reply-To: <005e01c2d7bb$bbb0fd70$f9ecdfd8@laptoy> References: <005e01c2d7bb$bbb0fd70$f9ecdfd8@laptoy> Message-ID: <2147483647.1045648546@imac-en0.delong.sj.ca.us> --On Tuesday, February 18, 2003 7:08 PM -0700 "John M. Brown" wrote: > if the PPML list is cc'd and not the prime, you > then have to have multiple rules. > Or a rule with a "To: or Cc:" clause. (big deal) > In addition you get multiple copies of the same > email. > Yep. This is useful in some cases. (Sometimes I want to know that something in a thread is a reply to what I said instead of more of the thread in general. In those cases, I have different rules for To: and Cc: which work just fine.) > For example: > > This email will send to Jim and Owen, plus the list, > which will send it to Jim and Owen AGAIN > > So Jim and Owen will get this message TWICE, have to filter > twice and store twice. > Yep. Again, this is useful. > Having the list set reply-to: to the list reduces this to > only one email each. It also ensures that the LIST > is receiving mail. > No it doesn't, because people still reply-all anyway. Owen From Stacy_Taylor at icgcomm.com Wed Feb 19 13:19:47 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Wed, 19 Feb 2003 11:19:47 -0700 Subject: [ppml] Withdrawal of 2002-7 Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DADD65@denexg21.icgcomm.com> I agree with Michael. Let's see what the authors of 2002-3 come up with in their rewrite. Hopefully it will be more succinct. S -----Original Message----- From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] Sent: Wednesday, February 19, 2003 6:39 AM To: ppml at arin.net Subject: [ppml] Withdrawal of 2002-7 My take on the discussion of 2002-7 is that it is bad policy because it mixes too many issues together. I have nothing against an omnibus policy as long as it is well organized so that the individual issues are clear in and of themselves. But 2002-7 doesn't do that and as a result the discussion just keeps going around in twisted and convoluted circles. Therefore, I suggest that ARIN should set aside this policy proposal and not give it any further consideration. Ron Da Silva has made a very good suggestion for separating the distinct items and discussing them in separate threads. I would like to further suggest that these items be discussed with an intent to turn them into a series of separate policy proposals. To refresh your memories, Ron suggested that we should deal with the following separate issues: Revocation - under what conditions should ARIN revoke an address allocation? Should this action extend to include assignments? Enforcement - what actions should ARIN take to enforce its allocations and its policies, if any? Leasing - what AUP should ARIN impose on anyone receiving an allocation to ensure that any "lease terms" are passed on to sub-allocations and assignments? Accuracy of data - what is ARIN's policy regarding the accuracy of SWIP and rwhois data? How will ARIN enforce this policy? Then he suggested an item regarding IETF cooperation that wasn't clear to me but which appears to include my following suggestion: Public Authoritative Directory: ---------------------------- ARIN will publish an authoritative directory for all of the IP address space which it administers. This directory will be public and will be published using LDAP v3 also known as referral LDAP. Only a minimal set of information will be made fully public, i.e. one email address and one phone number per organization along with the organization's name and city. Additional contact information, personal names and street addresses will be in the directory but will only be accessible to ARIN members who are in posession of suitable credentials. The intent is to facilitate communication while inhibiting email address scraping and stalking. All organizations receiving ARIN allocations must either maintain an accurate record of their sub-allocations and assignment with ARIN or they must operate an LDAP v3 server containing such information and open to the public. ARIN will ensure that existence information is updated in this directory on a daily basis. Existence information refers to the fact that an allocation exists, i.e. it has been allocated and has not been revoked. ARIN will also do a twice yearly audit of the accuracy of the contact information in this database. When contacts do not respond, the data in the ARIN database will be replaced with contact info for the next level up in the hierarchy. In other words, if an ISP gets address space from UUNet and does not respond during the audit, then ARIN will record UUNet contact info for this ISP. The intent is to ensure that there is an identifiable and responsive contact for all address space that is legitimately in use. ARIN will provide a mirroring mechanism for this directory and encourage organizations to mirror the entire directory for use in their firewalls, route servers, etc. ARIN will warn that it is not good engineering practice to connect this directory directly to BGP route filters but will not prohibit the practice. However ARIN will disclaim all responsibility for any damage that may result from such misuse. Please CHANGE THE SUBJECT if you wish to discuss one of these policy items. ---- Michael Dillon From arin_ppml at comcept.net Wed Feb 19 13:25:21 2003 From: arin_ppml at comcept.net (Brian Bergin) Date: Wed, 19 Feb 2003 13:25:21 -0500 Subject: [ppml] List modification In-Reply-To: <2147483647.1045648546@imac-en0.delong.sj.ca.us> References: <005e01c2d7bb$bbb0fd70$f9ecdfd8@laptoy> <005e01c2d7bb$bbb0fd70$f9ecdfd8@laptoy> Message-ID: <5.2.1.0.2.20030219132219.03215718@mail> At 12:55 19 02 03 Wednesday, Owen DeLong wrote: >--On Tuesday, February 18, 2003 7:08 PM -0700 "John M. Brown" > wrote: > >>if the PPML list is cc'd and not the prime, you >>then have to have multiple rules. >Or a rule with a "To: or Cc:" clause. (big deal) > >>In addition you get multiple copies of the same >>email. >Yep. This is useful in some cases. (Sometimes I want to know that >something in a thread is a reply to what I said instead of more of >the thread in general. In those cases, I have different rules for >To: and Cc: which work just fine.) That's why usenet would be a better place for this type of discussion. >>For example: >> >>This email will send to Jim and Owen, plus the list, >>which will send it to Jim and Owen AGAIN >> >>So Jim and Owen will get this message TWICE, have to filter >>twice and store twice. >Yep. Again, this is useful. Really? IMHO it's a waste of bandwidth, storage space, and my time having to look at more than one copy of an e-mail. >>Having the list set reply-to: to the list reduces this to >>only one email each. It also ensures that the LIST >>is receiving mail. >No it doesn't, because people still reply-all anyway. Setup correctly reply all would only have the list address. The person's address would still be in the headers, but someone would have to manually put their address in the To:, CC:, or BCC field. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin_ppml at comcept.net Wed Feb 19 13:45:15 2003 From: arin_ppml at comcept.net (Brian Bergin) Date: Wed, 19 Feb 2003 13:45:15 -0500 Subject: [ppml] List modification In-Reply-To: <005e01c2d7bb$bbb0fd70$f9ecdfd8@laptoy> References: <390E55B947E7C848898AEBB9E50770600EB5FA@msmdcfs01.msmgmt.com> Message-ID: <5.2.1.0.2.20030219132556.03215860@mail> At 21:08 18 02 03 Tuesday, John M. Brown wrote: >if the PPML list is cc'd and not the prime, you >then have to have multiple rules. Not in Eudora ;-) Eudora's filters are much better than Outlook, IMHO, I have one filter for all mail coming to this list and it works great (the other solution is to setup an alias like mine so that a simple rule always works for that alias, though not everyone will have that ability). >In addition you get multiple copies of the same >email. > >For example: > >This email will send to Jim and Owen, plus the list, >which will send it to Jim and Owen AGAIN > >So Jim and Owen will get this message TWICE, have to filter >twice and store twice. Unless you take the time to remove them, which I did here, but won't always remember to do. One can always CC or BCC the original sender if they feel it's necessary, but the important thing for discussion lists like this is that everyone sees everyone else's input. 2 or 3 chatting back and forth in private does little to promote discussion amongst others in the list. IMHO.... Brian >Having the list set reply-to: to the list reduces this to >only one email each. It also ensures that the LIST >is receiving mail. > >Count this as my vote to CHANGE THE LIST AND SET REPLY-TO: >towards the list > >thanks > > > -----Original Message----- > > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > > Behalf Of McBurnett, Jim > > Sent: Tuesday, February 18, 2003 6:51 PM > > To: Owen DeLong; ppml at arin.net > > Subject: [ppml] List modification > > > > > > In support of Owen: > > 1. I Agree > > 2. Due to the massive amounts of email I get, > > I use rules to redirect it to a special ARIN > > folder. When someone does a Reply All, the email > > hits instant notice. > > 3. If it was set up this way, and has been for so long, why > > change it now? > > > > Jim > > > > > -----Original Message----- > > > From: Owen DeLong [mailto:owen at delong.com] > > > Sent: Tuesday, February 18, 2003 8:40 PM > > > To: Brian Bergin; ppml at arin.net > > > Subject: Re: [ppml] Revocation > > > > > > > > > Count this as my vote to keep it the way it is. I find > > lists that set > > > the Reply-To to the list annoying. > > > > > > Owen > > > > > > > > > --On Tuesday, February 18, 2003 7:49 PM -0500 Brian Bergin > > > wrote: > > > > > > > At 19:16 18 02 03 Tuesday, you wrote: > > > >> Brian - Please send this to ppml at arin.net. In order to > > > have a productive > > > >> policy discussion, we need this type of dialogue there. > > Consider > > > >> addressing which contact info is required, optional, how > > > to interface > > > >> with providers who are not directly members of ARIN, etc. > > > We should be > > > >> able to come up with something that is not friendly to > > > SPAMMERS but also > > > >> is > > > >> acceptable to the ARIN membership and the internet > > > community in general. > > > >> > > > >> thanks! > > > >> -ron > > > > > > > > I just noticed this, even after I posted earlier about > > > having private > > > > discussions. ARIN's lists allow, actually encourage, > > replies to the > > > > sender not the list. That's a poor setup IMHO. One must > > > remember to > > > > change the To: to the ARIN address. It's too easy to jot > > > down a reply > > > > and hit send without remembering to change the To: address. > > > > > > > > I would propose a policy change to ARIN that their lists > > > have replies go > > > > to the list and not the sender. It's normally a simple > > > change to most > > > > list servers, it is on ours. > > > > > > > > Again, my apologies... > > > > > > > > Brian > > > > > > > > > > > From chris at telespan.co.uk Wed Feb 19 13:56:50 2003 From: chris at telespan.co.uk (Chris Jones) Date: Wed, 19 Feb 2003 18:56:50 -0000 Subject: [ppml] List modification In-Reply-To: <2147483647.1045648546@imac-en0.delong.sj.ca.us> Message-ID: <004601c2d848$a9d63d30$0100a8c0@gandalf> > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On > Behalf Of Owen > DeLong > Sent: 19 February 2003 17:56 > To: john at chagres.net; 'McBurnett, Jim'; ppml at arin.net > Subject: RE: [ppml] List modification > > > > > No it doesn't, because people still reply-all anyway. .. and those people very often do not think about whether everyone on the cc list *should* have a copy of their response. Think about how much time that can waste. NB: I had to think about how to reply to this, then hit the 'Reply to All' button (one that I only very rarely use), and then remove three cc names, merely to ensure that this response arrived at the list. If that action has to be repeated 50 times per day per internet user, that will be something like 50 x 20 seconds x number of internet email users (say 10 million). How many wasted hours does that add up to? -- >From Chris Jones mailto: chris at telespan.co.uk web: http://www.telespan.co.uk/ My PGP Key:- RSA 2048/1024 Key ID: 0x2B1F1593 Fingerprint: B073 FE31 0A6A 6BD6 C4DB 750D 2B30 D0E7 2B1F 1593 From owen at delong.com Wed Feb 19 14:01:46 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Feb 2003 11:01:46 -0800 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) In-Reply-To: <200302190906.BAA10696@dixon.DeLong.SJ.CA.US> References: <200302190906.BAA10696@dixon.DeLong.SJ.CA.US> Message-ID: <2147483647.1045652506@imac-en0.delong.sj.ca.us> The problem is that, even according to ARIN, there are a number of issues with identifying this. Several prefixes appear to be legitimately in the routing table, but ARIN has lost the records of their allocation. Heck, some of them seem to belong to Bill Manning. Somehow, I don't think Bill has been pirating address space. Any enforcement action taken based on the contents of the ARIN database before these issues are resolved would be folly. Especially automated enforcement. Additionally, the internet depends on rough consensus. It always has, and, I believe it will stop functioning if it doesn't continue to. This means that the people running the routers need to develop consensus on what to route. The RIRs can provide tools towards that end, but I don't believe it is their role to control the configuration or operation of the routers. I'm all for the RIRs providing a centralized "Valid Prefixes" list. Heck, I'd even support a database of "Valid Prefixes and the origin AS that maintains them." However, the use of such databases is a matter for RFC, BCP, and/or IETF. It is _NOT_ an ARIN policy issue. As such, I think your 2002-7 proposal needs to be separated into two parts. The RFC/BCP/IETF track part (things that should be done by the people that operate the routers), and the ARIN policy part. Also, unlike the DNS situation, ARIN has a tentative hold on address issuance based entirely on the support of the community. If enough people oppose ARIN policy, they can just as easily create their own address registry. ISPs would be free to choose which registry they wanted to believe about addresses. The conflict could be very ugly. Heck, this has already happened with DNS, but none of the oppositions were able to come together to a large enough cohesive group to tackle the basic suffixes, so in self-preservation, they avoided existing namespaces in favor of new ones. This isn't as easily done when the namespace is limited to 32 bit integers, most of which are already issued at one level or another. So.... Enforcement will depend on the BCP being something the default free zone is largely willing to follow. The BCP will have to drive this, and not ARIN policy. ARIN policy should be an enabler for the BCP, and should, IMHO, accomplish the following... 1. Each maintainer must provide at least one contact point which reaches an actual human being. Not an autoresponder, not a voice mail box, a live human being. (Not necessarily 24x7x365, but at least during business hours). It may be desirable for access to this contact information to be visible only to other maintainers, ARIN, and paid ARIN members. This would hopefully reduce the number of irrate and irrational attacks. 2. Each RIR should publish a list of valid prefixes and the ASN to which they were Allocated or Assigned. Ideally, this list should be available in a machine-readable format and published by means of a well known protocol. 3. ARIN should have the ability to revoke an allocation or assignment as a result of verified abuse. It should become part of the ARIN contract for registration services that the ASSIGNEE/ALLOCEE is responsible for the prevention of abuse within the resources allocated/assigned, and that they must revoke sub-assignments they have made in cases of verified abuse or risk their allocation being revoked by ARIN. 4. ARIN should have the responsibility to revoke any allocation or assignment which fails to meet the requirements of (1) above. 5. ARIN should set up a revocation review committee made up of representatives from ARIN members with allocations and nominated by the ASO AC. The members should be elected for a 2 year term by the community at large (similar to the ASO AC election at the ARIN/NANOG meeting). The committee should consist of 7 members. 6. The revocation process should look something like the following: A. ARIN staff receives report of or identifies abuse. B. ARIN staff investigates and confirms abuse. If abuse is not confirmed, the process ends here. C. If abuse is confirmed, ARIN staff sends a cease-and-desist letter to the required human contact of the maintainer in question via a confirmed-delivery mechanism. D. If, 15 days after the message is received by the maintainer, the abuse has not been resolved, ARIN should immediately revoke the applicable allocations and/or assignments, and refer the matter to the committee. E. If the maintainer wishes to appeal the decision, he should notify the committee of his desire to appeal within 30 days. The maintainer should submit his appeal in written form (preferably via electronic means). The committee has 60 days to review the information before it must render a decision. The committee's decision is final. F. Absent an appeal by the maintainer, no action is required from the committee, however, any member of the committee may also start the appeal process absent request from the maintainer. G. Any revocations should be published by ARIN on a specified place on the ARIN web site, as well as their removal from the valid prefixes list as soon as they take effect. H. Revocations should be effective when the first of the following occurs: 1. The time for appeal has lapsed, and no appeal has been filed. 2. The comittee has ruled in support of the revocation. 3. The time for the committee to rule has elapsed and no ruling has been made. Further, I think it would be desirable for ARIN to issue a single ASN to ARIN as BOGON-ASN. ARIN should publish a BGP feed (peered to any ARIN member with an ASN with no more than two peering sessions) which will contain all currently known BOGON prefixes. This would include IANA-RESERVED, RFC-1918, and any revoked prefixes. Revoked prefixes should not be reallocated for a period of one (1) year from the date of final revocation. Whatcha all think? Owen --On Wednesday, February 19, 2003 4:06 PM +0700 "Dr. Jeffrey Race" wrote: > On Tue, 18 Feb 2003 16:58:13 -0800, Owen DeLong wrote: > >> Here's the real problem, as I see it. When a domain is revoked, name >> service >> for that domain stops working at the root or TLD level. When ARIN > revokes >> an IP, nothing happens until an ISP stops routing it. > > I am interested in learning more about the technical measures which > the RIRs can employ to prevent fraudulent use of IP address space > (which is now occasionally reported on Spam-L already). But at > the level of the draft BCP, I am considering to add a new type > of abuse: > > - announcing a non-delegated route or other fraudulent use of > IP address space. > > Comments invited on > * wording (correctness, inclusiveness) > * practical effectiveness. > > Those following the draft BCP would blocklist the offending ISP. > These things would get around pretty quickly. > > Jeffrey Race > From steve at blighty.com Wed Feb 19 14:42:04 2003 From: steve at blighty.com (Steve Atkins) Date: Wed, 19 Feb 2003 11:42:04 -0800 Subject: [ppml] List modification In-Reply-To: <004601c2d848$a9d63d30$0100a8c0@gandalf>; from chris@telespan.co.uk on Wed, Feb 19, 2003 at 06:56:50PM -0000 References: <2147483647.1045648546@imac-en0.delong.sj.ca.us> <004601c2d848$a9d63d30$0100a8c0@gandalf> Message-ID: <20030219114203.A33816@blighty.com> On Wed, Feb 19, 2003 at 06:56:50PM -0000, Chris Jones wrote: > > No it doesn't, because people still reply-all anyway. > > .. and those people very often do not think about whether everyone on the cc > list *should* have a copy of their response. Think about how much time that > can waste. > > NB: I had to think about how to reply to this, then hit the 'Reply to All' > button (one that I only very rarely use), and then remove three cc names, > merely to ensure that this response arrived at the list. If that action has > to be repeated 50 times per day per internet user, that will be something > like 50 x 20 seconds x number of internet email users (say 10 million). How > many wasted hours does that add up to? I posted this yesterday, but it seems to have been eaten somewhere in the list processing works. This sums up most of the reasons why sabotaging use of the Reply-To header by the MLM is not a good thing. http://www.unicom.com/pw/reply-to-harmful.html Cheers, Steve From owen at delong.com Wed Feb 19 14:04:31 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Feb 2003 11:04:31 -0800 Subject: [ppml] Proposal to change how the PPML LISTServ works In-Reply-To: References: <004501c2d7b2$821f11e0$f9ecdfd8@laptoy> <000d01c2d7f9$f6c995f0$0100a8c0@gandalf> Message-ID: <2147483647.1045652670@imac-en0.delong.sj.ca.us> OK... Now I know something is wrong. I'm actually on the same side as Randy in a debate? That's a first! Owen --On Wednesday, February 19, 2003 6:41 PM +0900 Randy Bush wrote: >>> the reply to should be the list. if you want a private >>> reply then edit the to: part of your out going msg. > > a fantastic recipe to cause major public embarrassment to > someone hitting the reply key and thinking they are sending > privately to the From: > >> Most other mailing lists are configured to reply to the list > > false assertion > > randy > From owen at delong.com Wed Feb 19 14:33:43 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Feb 2003 11:33:43 -0800 Subject: [ppml] List modification In-Reply-To: <004601c2d848$a9d63d30$0100a8c0@gandalf> References: <004601c2d848$a9d63d30$0100a8c0@gandalf> Message-ID: <2147483647.1045654423@imac-en0.delong.sj.ca.us> >> No it doesn't, because people still reply-all anyway. > > .. and those people very often do not think about whether everyone on the > cc list *should* have a copy of their response. Think about how much time > that can waste. > Agreed. Point is, changing the Reply-To won't solve that unless you also make it _VERY_ time-consuming to reply off list by stripping the other headers. > NB: I had to think about how to reply to this, then hit the 'Reply to All' > button (one that I only very rarely use), and then remove three cc names, > merely to ensure that this response arrived at the list. If that action > has to be repeated 50 times per day per internet user, that will be > something like 50 x 20 seconds x number of internet email users (say 10 > million). How many wasted hours does that add up to? > -- Right... Well, you need a better mailer, or better proficiency with your current mailer. It sure didn't take me 20 seconds to hit reply, click the appropriate button to reply only to the list, and start typing my message. I'll say it took me probably about 1 second to get from reading to typing. I figure about 80% of the people who do a significant volume of email are proficient enough with their mailers to do this in <=5 seconds, and that you and I are exceptions at opposite ends, so, giving the idea 10% take 20 seconds, 10% take 1 second, and 80% take 5 seconds, I figure it's more like: 10*1+80*5+10*20=610/100=6.1 seconds average. Now, let's assume that this exceptional action is ONLY required for list mailing responses, which is probably more like 10 per day for most users, we're at 10*6.1 seconds per day per user. So... What exactly do you plan to do with the extra minute you gain by inconveniencing everyone who likes it the way it is? Owen > From > Chris Jones > mailto: chris at telespan.co.uk > web: http://www.telespan.co.uk/ > > My PGP Key:- > RSA 2048/1024 Key ID: 0x2B1F1593 > Fingerprint: B073 FE31 0A6A 6BD6 C4DB 750D 2B30 D0E7 2B1F 1593 > From ron at aol.net Wed Feb 19 16:11:53 2003 From: ron at aol.net (Ron da Silva) Date: Wed, 19 Feb 2003 16:11:53 -0500 Subject: [ppml] Revocation In-Reply-To: <2147483647.1045652506@imac-en0.delong.sj.ca.us> References: <200302190906.BAA10696@dixon.DeLong.SJ.CA.US> <2147483647.1045652506@imac-en0.delong.sj.ca.us> Message-ID: <20030219211153.GA23909@aol.net> On Wed, Feb 19, 2003 at 11:01:46AM -0800, Owen DeLong wrote: > > Whatcha all think? Nice detailed proposal. One area that needs some more meat is the definition of abuse. Any suggestions there would be great! I do have some particulars about the details to consider... > 2. Each RIR should publish a list of valid prefixes and the ASN to which > they were Allocated or Assigned. Ideally, this list should be available > in a machine-readable format and published by means of a well known > protocol. Do we need a mechanism for downstream allocations/assignments to be mapped to an origin ASN by the ARIN member when downstreams are not members? > 5. ARIN should set up a revocation review committee made up of > representatives from ARIN members with allocations and nominated > by the ASO AC. The members should be elected for a 2 year > term by the community at large (similar to the ASO AC election > at the ARIN/NANOG meeting). The committee should consist > of 7 members. Nominated by ASO AC or ARIN AC? Or, by general community? Any requirements for candidacy? > 6. The revocation process should look something like the following... > B. ARIN staff investigates and confirms abuse. If abuse is > not confirmed, the process ends here... How is abuse confirmed? Again, related to the definition of abuse. > D. If, 15 days after the message is received by the maintainer, > the abuse has not been resolved, ARIN should immediately > revoke the applicable allocations and/or assignments, > and refer the matter to the committee. Similarly, how is resolution of abuse determined? > E. If the maintainer wishes to appeal the decision, he should > notify the committee of his desire to appeal within 30 > days. The maintainer should submit his appeal in written > form (preferably via electronic means). The committee has > 60 days to review the information before it must render a > decision. The committee's decision is final... How does one ensure that there is no abuse by the committee itself? Or do we trust the judgment of the committee based on the nomination process? Also, would a reinstatement process be needed? -ron From jmcburnett at msmgmt.com Wed Feb 19 16:37:04 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 19 Feb 2003 16:37:04 -0500 Subject: [ppml] 2002-7--- A New idea--- Message-ID: <390E55B947E7C848898AEBB9E507706041E30B@msmdcfs01.msmgmt.com> I have an idea: Does any other RIR have a policy like this? If so, let's cheat and look at their's and see if we can use it? Why reinvent the wheel? And why didn't someone else think about this? Later, Jim >-----Original Message----- >From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com] >Sent: Wednesday, February 19, 2003 1:20 PM >To: 'Michael.Dillon at radianz.com'; ppml at arin.net >Subject: RE: [ppml] Withdrawal of 2002-7 > > >I agree with Michael. Let's see what the authors of 2002-3 >come up with in >their rewrite. Hopefully it will be more succinct. >S >-----Original Message----- >From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] >Sent: Wednesday, February 19, 2003 6:39 AM >To: ppml at arin.net >Subject: [ppml] Withdrawal of 2002-7 > > >My take on the discussion of 2002-7 is that it is bad policy >because it >mixes too many issues together. I have nothing against an >omnibus policy >as long as it is well organized so that the individual issues >are clear in >and of themselves. But 2002-7 doesn't do that and as a result the >discussion just keeps going around in twisted and convoluted circles. > >Therefore, I suggest that ARIN should set aside this policy >proposal and >not give it any further consideration. > >Ron Da Silva has made a very good suggestion for separating >the distinct >items and discussing them in separate threads. I would like to further >suggest that these items be discussed with an intent to turn >them into a >series of separate policy proposals. To refresh your memories, Ron >suggested that we should deal with the following separate issues: > >Revocation - under what conditions should ARIN revoke an address >allocation? Should this action extend to include assignments? > >Enforcement - what actions should ARIN take to enforce its >allocations and >its policies, if any? > >Leasing - what AUP should ARIN impose on anyone receiving an >allocation to >ensure that any "lease terms" are passed on to sub-allocations and >assignments? > >Accuracy of data - what is ARIN's policy regarding the >accuracy of SWIP >and rwhois data? How will ARIN enforce this policy? > >Then he suggested an item regarding IETF cooperation that >wasn't clear to >me but which appears to include my following suggestion: > >Public Authoritative Directory: >---------------------------- >ARIN will publish an authoritative directory for all of the IP address >space which it administers. > >This directory will be public and will be published using LDAP v3 also >known as referral LDAP. > >Only a minimal set of information will be made fully public, i.e. one >email address and one phone number per organization along with the >organization's name and city. >Additional contact information, personal names and street >addresses will >be in the directory but will only be accessible to ARIN >members who are in >posession of suitable credentials. >The intent is to facilitate communication while inhibiting >email address >scraping and stalking. > >All organizations receiving ARIN allocations must either maintain an >accurate record of their sub-allocations and assignment with >ARIN or they >must operate an LDAP v3 server containing such information and >open to the >public. > >ARIN will ensure that existence information is updated in this >directory >on a daily basis. >Existence information refers to the fact that an allocation >exists, i.e. >it has been allocated and has not been revoked. > >ARIN will also do a twice yearly audit of the accuracy of the contact >information in this database. > >When contacts do not respond, the data in the ARIN database will be >replaced with contact info for the next level up in the hierarchy. >In other words, if an ISP gets address space from UUNet and does not >respond during the audit, then ARIN will record UUNet contact info for >this ISP. >The intent is to ensure that there is an identifiable and responsive >contact for all address space that is legitimately in use. > >ARIN will provide a mirroring mechanism for this directory and >encourage >organizations to mirror the entire directory for use in their >firewalls, >route servers, etc. > >ARIN will warn that it is not good engineering practice to >connect this >directory directly to BGP route filters but will not prohibit the >practice. >However ARIN will disclaim all responsibility for any damage that may >result from such misuse. > >Please CHANGE THE SUBJECT if you wish to discuss one of these policy >items. > >---- >Michael Dillon > From william at elan.net Wed Feb 19 15:19:25 2003 From: william at elan.net (william at elan.net) Date: Wed, 19 Feb 2003 12:19:25 -0800 (PST) Subject: [ppml] Draft 1 of possible proposal for ip assignment with sponsorship In-Reply-To: Message-ID: As both publicly and privately I have received positive reaction to idea posted last week on small ip block allocations with sponsorship by the isps, I'v put this into draft for a proposal. Please feel free to comment on idea, alternatives listed and any wording that is seriously wrong and anything that is missing or is too much (I tried my best not to overload, but I do tend to write long emails as well as other documents). Those of you who have better skill at writing, please fee free to post your own alternative wording if it sounds better. --------------------------------------------------------------------------- Under this policy proposal, a company or individual may become ARIN client and receive IP allocation from ARIN without becoming ARIN member if it has a sponsorship of two or more ARIN subscriber members. Under this policy a company or individual may become ARIN associate subscriber member and receive IP allocation from ARIN if it has sponsorship of two or more ARIN ISP subsriber members. A company or individual may not directly contact ARIN to request ip allocation under this policy, instead contact first needs to be made with companies that will act as sponsors and after these companies have verified technical details of the request, one of the future sponsors may submit the request futher to ARIN. A company or individual must first provide technical information regarding each ip request under this policy to the companies that will act as its sponsors. Only after approval is received from two or more such companies can the contact with ARIN be initiated. ARIN members that agree to act as sponsors for the ip request under this policy must have business relationship with the company or individual requesting ip allocation. If in the future this relationship is terminated, the sponsor agrees to notify ARIN no longer then 30 days after such an event that it will not continue to be a sponsor. An entity that has received ip block according to this policy may change one or more of its sponsors at any time, it must then send information regarding its new sponsor to ARIN and ARIN must verify such request with listed subscriber member. If entity that has received ip block has less then two sponsors for period longer then one month, ARIN may withdraw its ip block assignment provided 30-day notice has been issued to the last known mailing address. In the event that a sponsor becomes aware that any information regarding ip request received under this policy is no longer valid, a sponsor must notify ARIN or verify that sponsored organization or individual has already made necessary updates. Above is meant to encorage ISPs/sponsors to keep updated information on its clients and if anything changes, let them know that they need to contact ARIN or otherwise, the ISP would have to notify ARIN anyway because of its sponsorship obligations. Changes meant to include company name some way must be provided for company to keep its ip block if its name is changed by legal means , its physical address, email address as well as technical information regarding ip blocks (to discourag those who no longer need larger ip blocks from keeping all of it). There is no minimum or maximum ip block size for allocation that company may receive under this policy but any ip allocations made must be according with guidelines listed in RFC2050, except where other ARIN policies may take precedence. The above rather short statement is put here instead of making long paragraph describing what what would be the minimum set of requirements to receive an ip block request, generally it is excepted that company would receive no more then 50% larger block that its currently needs no less then what is necessary for proper internet routing. Besides that the above also allows ARIN to have policies that would otherwise override the guidelines, for example allowing minimum allocation of /24 for multihomed customers Perhaps what I have put is too short for what it is meant to be, in this case, feel free to provide your own alternatives, but please try not to unecessarily overload the policy text. An entity that has received ip block according to this policy may not at the same time have another ip block according to this or some other policy for period longer then 6 months except where special arrangements have been made with ARIN. If in the future entity that has received an ip block according to this policy makes a request for additional ip block, it may receive a larger shouldn't this be smaller, i.e. ip block prefix size? ip block as a replacement for the existing block and according to additional requirements in its new request. In this case a period of up to 6 months must be provided by ARIN when both assignments are valid in order to allow for renumbering and after that ARIN may withdraw its initial allocation. A company or individual may not have more then two ip blocks assigned according to this policy for period longer then 6 months, except where special arrangements have been made with ARIN. An entity that has received an ip block is responsible for making regular yearly maintanence fee payments according to special maintance schedule to be adapted by ARIN board of trustees. ARIN must provide an renewal invoice to last known mailing address by the yearly renewal date and if payment is not received up to 30 days after the due date, it must contact sponsors to verify the correct address. In the event that ARIN is unable to make proper contact with the entity or when payment is still not received 90 days after the due date, ARIN may withdraw ip block assignment and must then notify all existing sponsors of such an event. The above paragraph and actually all other paragraphs regarding sponsors, places no particular "punishment" for arin members for failure to keep its sponsoring obligations (i.e. notify ARIN in time when its no longer a sponsor and keep arin otherwise informed about any changes to sponsored company). Perhaps stronger wording is needed or otherwise ARIN may want to have sponsors sign special agreement as well legal document for sponsorship may very well be needed anyway . One alternative is also to have sponsors financially liable for money owed to ARIN if it failed to notify arin and arin finds that company is no longer in business when it does not get paid. Before this policy can be used ARIN board of trustees must approve special payment schedule to be used for companies and individuals requesting ip space under this policy. The followingis the recommended schedule for the initial period after the adaption of the policy: /24 or less: $500 /23: $750 /22: $1,000 /21: $1,500 /20: $2,000 /19: $2,500 /18: $5,000 /17: $7,500 /16 and larger: $10K per /16 It is also recommended that one-time registration fee be charged that is equivalent to yearly maintaince fee for the block. There maybe companies that receive ip transit in US from ISPs not based in US that are not members of ARIN. It may very well be beneficial for such companies to receive an ip block directly from ARIN according to above policy, but it would not be possible because one or more of its upstream providers is not arin member and can not act as sponsor. I do not see any easy way to incorporate this situation into above proposal without overloading it or otherwise creating a loophole. Any suggestions on what to do in such case and/or how to modify the above proposal are greatly appreciated. There mabe some cases where ISP wants to withdraw its sponsorship because it changed its policies and no longer wants to do sponsorships. The above makes it impossible as in order to withdraw sponsorship, it must end "business relationship" but this may not be the case. Perhaps more clear wording that ISP may withdraw sponsorship at any time is needed but this may lead to above (i.e. isp threatening to withdraw sponsorship during contract negogiations, etc). In general there may need to be some "arbitration comitee" for issues regarding sponsorship. I often use assignment and allocations in place of one another in the above. You can safely assume general "assignment or allocation" is meant, I personally do not like to make a distinction between one and another and don't see why should ARIN care if ip block is sub-allocated to companie's customers or used on its own entire by the same company. However to be move precise in most cases, the proposal is meant to replace current problem with small "assignments" and to supplement ARIN's current policies on minimum assignment to end users. The wording and using either just "assignment" or "assignment or allocation" or some other more general term would be fixed for final draft. From william at elan.net Wed Feb 19 15:25:44 2003 From: william at elan.net (william at elan.net) Date: Wed, 19 Feb 2003 12:25:44 -0800 (PST) Subject: [ppml] Re: Draft 1 of possible proposal for ip assignment with sponsorship In-Reply-To: Message-ID: Same as previous doc but without inline comments for easier reading on how it looks as a whole. I prefer you respond to previous email. --------------------------------------------------------------------------- Under this policy proposal, a company or individual may become ARIN client and receive IP allocation from ARIN without becoming ARIN member if it has a sponsorship of two or more ARIN subscriber members. A company or individual may not directly contact ARIN to request ip allocation under this policy, instead contact first needs to be made with companies that will act as sponsors and after these companies have verified technical details of the request, one of the future sponsors may submit the request futher to ARIN. ARIN members that agree to act as sponsors for the ip request under this policy must have business relationship with the company or individual requesting ip allocation. If in the future this relationship is terminated, the sponsor agrees to notify ARIN no longer then 30 days after such anevent that it will not continue to be a sponsor. An entity that has received ip block according to this policy may change one or more of its sponsors at any time, it must then send information regarding its new sponsor to ARIN and ARIN must verify such request with listed subscriber member. If entity that has received ip block has less then two sponsors for period longer then one month, ARIN may withdraw its ip block assignment provided 30-day notice has been issued to the last known mailing address. In the event that a sponsor becomes aware that any information regarding ip request received under this policy is no longer valid, a sponsor must notify ARIN or verify that sponsored organization or individual has already made necessary updates. There is no minimum or maximum ip block size for allocation that company may receive under this policy but any ip allocations made must be according with guidelines listed in RFC2050, except where other ARIN policies may take precedence. An entity that has received ip block according to this policy may not at the same time have another ip block according to this or some other policy for period longer then 6 months except where special arrangements have been made with ARIN. An entity that has received an ip block is responsible for making regular yearly maintanence fee payments according to special maintance schedule to be adapted by ARIN board of trustees. ARIN must provide a renewal invoice to last known mailing address by the yearly renewal date and if payment is not received up to 30 days after the due date, it must contact sponsors to verify the correct address. In the event that ARIN is unable to make proper contact with the entity or when payment is still not received 90 days after the due date, ARIN may withdraw ip block assignment and must then notify all existing sponsors of such an event. From memsvcs at arin.net Wed Feb 19 17:18:22 2003 From: memsvcs at arin.net (Member Services) Date: Wed, 19 Feb 2003 17:18:22 -0500 (EST) Subject: [ppml] ARIN XI Meeting Registration Now Open Message-ID: Don't get the blues about the future of IP policy - Be a part of policy discussions in the Birthplace of Rock and Roll, Memphis, TN. ARIN XI will be held in Memphis from Sunday, April 6th to Wednesday, April 9th. Arrive on Sunday for the IPv6 Mini-Workshop scheduled to begin at 1:00 PM. The open Public Policy meeting will be held on Monday and Tuesday. We conclude with the ARIN Members meeting on Wednesday, April 9th. Meeting registration and hotel information can be found on the ARIN website. Be sure to sign up for ARIN's 4th Annual Foosball Tournament and the ARIN social when you register. http://www.arin.net/ARIN-XI/ ARIN would like to thank NASA for sponsoring portions of this meeting. Please contact us if you have any questions, need assistance with meeting registration or would like to hear about additional sponsorship opportunities in Memphis. We look forward to seeing you there! ARIN Member Services =================================================================== e-mail memsvcs at ARIN.NET telephone +1.703.227.9878 website http://www.arin.net =================================================================== From forrest at almighty.c64.org Wed Feb 19 17:37:10 2003 From: forrest at almighty.c64.org (Forrest) Date: Wed, 19 Feb 2003 16:37:10 -0600 (CST) Subject: [ppml] 2002-7--- A New idea--- Message-ID: It appears that APNIC assigns small blocks of portable IP addresses to multihomed organizations. http://www.apnic.net/info/faq/multihoming_faq.html Forrest On Wed, 19 Feb 2003, McBurnett, Jim wrote: > I have an idea: > Does any other RIR have a policy like this? > If so, let's cheat and look at their's and see if we can use it? Why reinvent the wheel? > And why didn't someone else think about this? > > Later, > Jim > > > > > >-----Original Message----- > >From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com] > >Sent: Wednesday, February 19, 2003 1:20 PM > >To: 'Michael.Dillon at radianz.com'; ppml at arin.net > >Subject: RE: [ppml] Withdrawal of 2002-7 > > > > > >I agree with Michael. Let's see what the authors of 2002-3 > >come up with in > >their rewrite. Hopefully it will be more succinct. > >S > >-----Original Message----- > >From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] > >Sent: Wednesday, February 19, 2003 6:39 AM > >To: ppml at arin.net > >Subject: [ppml] Withdrawal of 2002-7 > > > > > >My take on the discussion of 2002-7 is that it is bad policy > >because it > >mixes too many issues together. I have nothing against an > >omnibus policy > >as long as it is well organized so that the individual issues > >are clear in > >and of themselves. But 2002-7 doesn't do that and as a result the > >discussion just keeps going around in twisted and convoluted circles. > > > >Therefore, I suggest that ARIN should set aside this policy > >proposal and > >not give it any further consideration. > > > >Ron Da Silva has made a very good suggestion for separating > >the distinct > >items and discussing them in separate threads. I would like to further > >suggest that these items be discussed with an intent to turn > >them into a > >series of separate policy proposals. To refresh your memories, Ron > >suggested that we should deal with the following separate issues: > > > >Revocation - under what conditions should ARIN revoke an address > >allocation? Should this action extend to include assignments? > > > >Enforcement - what actions should ARIN take to enforce its > >allocations and > >its policies, if any? > > > >Leasing - what AUP should ARIN impose on anyone receiving an > >allocation to > >ensure that any "lease terms" are passed on to sub-allocations and > >assignments? > > > >Accuracy of data - what is ARIN's policy regarding the > >accuracy of SWIP > >and rwhois data? How will ARIN enforce this policy? > > > >Then he suggested an item regarding IETF cooperation that > >wasn't clear to > >me but which appears to include my following suggestion: > > > >Public Authoritative Directory: > >---------------------------- > >ARIN will publish an authoritative directory for all of the IP address > >space which it administers. > > > >This directory will be public and will be published using LDAP v3 also > >known as referral LDAP. > > > >Only a minimal set of information will be made fully public, i.e. one > >email address and one phone number per organization along with the > >organization's name and city. > >Additional contact information, personal names and street > >addresses will > >be in the directory but will only be accessible to ARIN > >members who are in > >posession of suitable credentials. > >The intent is to facilitate communication while inhibiting > >email address > >scraping and stalking. > > > >All organizations receiving ARIN allocations must either maintain an > >accurate record of their sub-allocations and assignment with > >ARIN or they > >must operate an LDAP v3 server containing such information and > >open to the > >public. > > > >ARIN will ensure that existence information is updated in this > >directory > >on a daily basis. > >Existence information refers to the fact that an allocation > >exists, i.e. > >it has been allocated and has not been revoked. > > > >ARIN will also do a twice yearly audit of the accuracy of the contact > >information in this database. > > > >When contacts do not respond, the data in the ARIN database will be > >replaced with contact info for the next level up in the hierarchy. > >In other words, if an ISP gets address space from UUNet and does not > >respond during the audit, then ARIN will record UUNet contact info for > >this ISP. > >The intent is to ensure that there is an identifiable and responsive > >contact for all address space that is legitimately in use. > > > >ARIN will provide a mirroring mechanism for this directory and > >encourage > >organizations to mirror the entire directory for use in their > >firewalls, > >route servers, etc. > > > >ARIN will warn that it is not good engineering practice to > >connect this > >directory directly to BGP route filters but will not prohibit the > >practice. > >However ARIN will disclaim all responsibility for any damage that may > >result from such misuse. > > > >Please CHANGE THE SUBJECT if you wish to discuss one of these policy > >items. > > > >---- > >Michael Dillon > > > From jmcburnett at msmgmt.com Wed Feb 19 17:42:58 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 19 Feb 2003 17:42:58 -0500 Subject: [ppml] 2002-7--- A New idea--- Message-ID: <390E55B947E7C848898AEBB9E507706041E30F@msmdcfs01.msmgmt.com> Everyone let's cut the red tape.. Everyone read the attached FAQ that Forrest sent. This is the answer.. Jim >-----Original Message----- >From: Forrest [mailto:forrest at almighty.c64.org] >Sent: Wednesday, February 19, 2003 5:37 PM >To: ppml at arin.net >Subject: Re: [ppml] 2002-7--- A New idea--- > > > >It appears that APNIC assigns small blocks of portable IP addresses to >multihomed organizations. > >http://www.apnic.net/info/faq/multihoming_faq.html > >Forrest > >On Wed, 19 Feb 2003, McBurnett, Jim wrote: > >> I have an idea: >> Does any other RIR have a policy like this? >> If so, let's cheat and look at their's and see if we can use >it? Why reinvent the wheel? >> And why didn't someone else think about this? >> >> Later, >> Jim >> >> >> >> >> >-----Original Message----- >> >From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com] >> >Sent: Wednesday, February 19, 2003 1:20 PM >> >To: 'Michael.Dillon at radianz.com'; ppml at arin.net >> >Subject: RE: [ppml] Withdrawal of 2002-7 >> > >> > >> >I agree with Michael. Let's see what the authors of 2002-3 >> >come up with in >> >their rewrite. Hopefully it will be more succinct. >> >S >> >-----Original Message----- >> >From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] >> >Sent: Wednesday, February 19, 2003 6:39 AM >> >To: ppml at arin.net >> >Subject: [ppml] Withdrawal of 2002-7 >> > >> > >> >My take on the discussion of 2002-7 is that it is bad policy >> >because it >> >mixes too many issues together. I have nothing against an >> >omnibus policy >> >as long as it is well organized so that the individual issues >> >are clear in >> >and of themselves. But 2002-7 doesn't do that and as a result the >> >discussion just keeps going around in twisted and >convoluted circles. >> > >> >Therefore, I suggest that ARIN should set aside this policy >> >proposal and >> >not give it any further consideration. >> > >> >Ron Da Silva has made a very good suggestion for separating >> >the distinct >> >items and discussing them in separate threads. I would like >to further >> >suggest that these items be discussed with an intent to turn >> >them into a >> >series of separate policy proposals. To refresh your memories, Ron >> >suggested that we should deal with the following separate issues: >> > >> >Revocation - under what conditions should ARIN revoke an address >> >allocation? Should this action extend to include assignments? >> > >> >Enforcement - what actions should ARIN take to enforce its >> >allocations and >> >its policies, if any? >> > >> >Leasing - what AUP should ARIN impose on anyone receiving an >> >allocation to >> >ensure that any "lease terms" are passed on to sub-allocations and >> >assignments? >> > >> >Accuracy of data - what is ARIN's policy regarding the >> >accuracy of SWIP >> >and rwhois data? How will ARIN enforce this policy? >> > >> >Then he suggested an item regarding IETF cooperation that >> >wasn't clear to >> >me but which appears to include my following suggestion: >> > >> >Public Authoritative Directory: >> >---------------------------- >> >ARIN will publish an authoritative directory for all of the >IP address >> >space which it administers. >> > >> >This directory will be public and will be published using >LDAP v3 also >> >known as referral LDAP. >> > >> >Only a minimal set of information will be made fully >public, i.e. one >> >email address and one phone number per organization along with the >> >organization's name and city. >> >Additional contact information, personal names and street >> >addresses will >> >be in the directory but will only be accessible to ARIN >> >members who are in >> >posession of suitable credentials. >> >The intent is to facilitate communication while inhibiting >> >email address >> >scraping and stalking. >> > >> >All organizations receiving ARIN allocations must either >maintain an >> >accurate record of their sub-allocations and assignment with >> >ARIN or they >> >must operate an LDAP v3 server containing such information and >> >open to the >> >public. >> > >> >ARIN will ensure that existence information is updated in this >> >directory >> >on a daily basis. >> >Existence information refers to the fact that an allocation >> >exists, i.e. >> >it has been allocated and has not been revoked. >> > >> >ARIN will also do a twice yearly audit of the accuracy of >the contact >> >information in this database. >> > >> >When contacts do not respond, the data in the ARIN database will be >> >replaced with contact info for the next level up in the hierarchy. >> >In other words, if an ISP gets address space from UUNet and >does not >> >respond during the audit, then ARIN will record UUNet >contact info for >> >this ISP. >> >The intent is to ensure that there is an identifiable and >responsive >> >contact for all address space that is legitimately in use. >> > >> >ARIN will provide a mirroring mechanism for this directory and >> >encourage >> >organizations to mirror the entire directory for use in their >> >firewalls, >> >route servers, etc. >> > >> >ARIN will warn that it is not good engineering practice to >> >connect this >> >directory directly to BGP route filters but will not prohibit the >> >practice. >> >However ARIN will disclaim all responsibility for any >damage that may >> >result from such misuse. >> > >> >Please CHANGE THE SUBJECT if you wish to discuss one of >these policy >> >items. >> > >> >---- >> >Michael Dillon >> > >> > > > From Stacy_Taylor at icgcomm.com Wed Feb 19 17:45:58 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Wed, 19 Feb 2003 15:45:58 -0700 Subject: [ppml] Draft 1 of possible proposal for ip assignment with sp onsorship Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DADD73@denexg21.icgcomm.com> If this policy were to go forward, it may be wise to limit its scope to /24 to /21 CIDR blocks. If an entity qualified for a /20 I, as IP Goddess for ICG, would have the entity apply to ARIN on its own. Also, to avoid confusion, perhaps the policy should define "allocation" as a block straight from the Registry, and "assignment" a block from an upstream. What say you? S -----Original Message----- From: william at elan.net [mailto:william at elan.net] Sent: Wednesday, February 19, 2003 12:19 PM To: ppml at arin.net Subject: [ppml] Draft 1 of possible proposal for ip assignment with sponsorship As both publicly and privately I have received positive reaction to idea posted last week on small ip block allocations with sponsorship by the isps, I'v put this into draft for a proposal. Please feel free to comment on idea, alternatives listed and any wording that is seriously wrong and anything that is missing or is too much (I tried my best not to overload, but I do tend to write long emails as well as other documents). Those of you who have better skill at writing, please fee free to post your own alternative wording if it sounds better. --------------------------------------------------------------------------- Under this policy proposal, a company or individual may become ARIN client and receive IP allocation from ARIN without becoming ARIN member if it has a sponsorship of two or more ARIN subscriber members. Under this policy a company or individual may become ARIN associate subscriber member and receive IP allocation from ARIN if it has sponsorship of two or more ARIN ISP subsriber members. A company or individual may not directly contact ARIN to request ip allocation under this policy, instead contact first needs to be made with companies that will act as sponsors and after these companies have verified technical details of the request, one of the future sponsors may submit the request futher to ARIN. A company or individual must first provide technical information regarding each ip request under this policy to the companies that will act as its sponsors. Only after approval is received from two or more such companies can the contact with ARIN be initiated. ARIN members that agree to act as sponsors for the ip request under this policy must have business relationship with the company or individual requesting ip allocation. If in the future this relationship is terminated, the sponsor agrees to notify ARIN no longer then 30 days after such an event that it will not continue to be a sponsor. An entity that has received ip block according to this policy may change one or more of its sponsors at any time, it must then send information regarding its new sponsor to ARIN and ARIN must verify such request with listed subscriber member. If entity that has received ip block has less then two sponsors for period longer then one month, ARIN may withdraw its ip block assignment provided 30-day notice has been issued to the last known mailing address. In the event that a sponsor becomes aware that any information regarding ip request received under this policy is no longer valid, a sponsor must notify ARIN or verify that sponsored organization or individual has already made necessary updates. Above is meant to encorage ISPs/sponsors to keep updated information on its clients and if anything changes, let them know that they need to contact ARIN or otherwise, the ISP would have to notify ARIN anyway because of its sponsorship obligations. Changes meant to include company name some way must be provided for company to keep its ip block if its name is changed by legal means , its physical address, email address as well as technical information regarding ip blocks (to discourag those who no longer need larger ip blocks from keeping all of it). There is no minimum or maximum ip block size for allocation that company may receive under this policy but any ip allocations made must be according with guidelines listed in RFC2050, except where other ARIN policies may take precedence. The above rather short statement is put here instead of making long paragraph describing what what would be the minimum set of requirements to receive an ip block request, generally it is excepted that company would receive no more then 50% larger block that its currently needs no less then what is necessary for proper internet routing. Besides that the above also allows ARIN to have policies that would otherwise override the guidelines, for example allowing minimum allocation of /24 for multihomed customers Perhaps what I have put is too short for what it is meant to be, in this case, feel free to provide your own alternatives, but please try not to unecessarily overload the policy text. An entity that has received ip block according to this policy may not at the same time have another ip block according to this or some other policy for period longer then 6 months except where special arrangements have been made with ARIN. If in the future entity that has received an ip block according to this policy makes a request for additional ip block, it may receive a larger shouldn't this be smaller, i.e. ip block prefix size? ip block as a replacement for the existing block and according to additional requirements in its new request. In this case a period of up to 6 months must be provided by ARIN when both assignments are valid in order to allow for renumbering and after that ARIN may withdraw its initial allocation. A company or individual may not have more then two ip blocks assigned according to this policy for period longer then 6 months, except where special arrangements have been made with ARIN. An entity that has received an ip block is responsible for making regular yearly maintanence fee payments according to special maintance schedule to be adapted by ARIN board of trustees. ARIN must provide an renewal invoice to last known mailing address by the yearly renewal date and if payment is not received up to 30 days after the due date, it must contact sponsors to verify the correct address. In the event that ARIN is unable to make proper contact with the entity or when payment is still not received 90 days after the due date, ARIN may withdraw ip block assignment and must then notify all existing sponsors of such an event. The above paragraph and actually all other paragraphs regarding sponsors, places no particular "punishment" for arin members for failure to keep its sponsoring obligations (i.e. notify ARIN in time when its no longer a sponsor and keep arin otherwise informed about any changes to sponsored company). Perhaps stronger wording is needed or otherwise ARIN may want to have sponsors sign special agreement as well legal document for sponsorship may very well be needed anyway . One alternative is also to have sponsors financially liable for money owed to ARIN if it failed to notify arin and arin finds that company is no longer in business when it does not get paid. Before this policy can be used ARIN board of trustees must approve special payment schedule to be used for companies and individuals requesting ip space under this policy. The followingis the recommended schedule for the initial period after the adaption of the policy: /24 or less: $500 /23: $750 /22: $1,000 /21: $1,500 /20: $2,000 /19: $2,500 /18: $5,000 /17: $7,500 /16 and larger: $10K per /16 It is also recommended that one-time registration fee be charged that is equivalent to yearly maintaince fee for the block. There maybe companies that receive ip transit in US from ISPs not based in US that are not members of ARIN. It may very well be beneficial for such companies to receive an ip block directly from ARIN according to above policy, but it would not be possible because one or more of its upstream providers is not arin member and can not act as sponsor. I do not see any easy way to incorporate this situation into above proposal without overloading it or otherwise creating a loophole. Any suggestions on what to do in such case and/or how to modify the above proposal are greatly appreciated. There mabe some cases where ISP wants to withdraw its sponsorship because it changed its policies and no longer wants to do sponsorships. The above makes it impossible as in order to withdraw sponsorship, it must end "business relationship" but this may not be the case. Perhaps more clear wording that ISP may withdraw sponsorship at any time is needed but this may lead to above (i.e. isp threatening to withdraw sponsorship during contract negogiations, etc). In general there may need to be some "arbitration comitee" for issues regarding sponsorship. I often use assignment and allocations in place of one another in the above. You can safely assume general "assignment or allocation" is meant, I personally do not like to make a distinction between one and another and don't see why should ARIN care if ip block is sub-allocated to companie's customers or used on its own entire by the same company. However to be move precise in most cases, the proposal is meant to replace current problem with small "assignments" and to supplement ARIN's current policies on minimum assignment to end users. The wording and using either just "assignment" or "assignment or allocation" or some other more general term would be fixed for final draft. From Stacy_Taylor at icgcomm.com Wed Feb 19 17:51:06 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Wed, 19 Feb 2003 15:51:06 -0700 Subject: [ppml] 2002-7--- A New idea--- Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DADD74@denexg21.icgcomm.com> Shouldn't we have a minimum /24 assignment, though? S -----Original Message----- From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] Sent: Wednesday, February 19, 2003 2:43 PM To: ppml at arin.net Subject: RE: [ppml] 2002-7--- A New idea--- Everyone let's cut the red tape.. Everyone read the attached FAQ that Forrest sent. This is the answer.. Jim >-----Original Message----- >From: Forrest [mailto:forrest at almighty.c64.org] >Sent: Wednesday, February 19, 2003 5:37 PM >To: ppml at arin.net >Subject: Re: [ppml] 2002-7--- A New idea--- > > > >It appears that APNIC assigns small blocks of portable IP addresses to >multihomed organizations. > >http://www.apnic.net/info/faq/multihoming_faq.html > >Forrest > >On Wed, 19 Feb 2003, McBurnett, Jim wrote: > >> I have an idea: >> Does any other RIR have a policy like this? >> If so, let's cheat and look at their's and see if we can use >it? Why reinvent the wheel? >> And why didn't someone else think about this? >> >> Later, >> Jim >> >> >> >> >> >-----Original Message----- >> >From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com] >> >Sent: Wednesday, February 19, 2003 1:20 PM >> >To: 'Michael.Dillon at radianz.com'; ppml at arin.net >> >Subject: RE: [ppml] Withdrawal of 2002-7 >> > >> > >> >I agree with Michael. Let's see what the authors of 2002-3 >> >come up with in >> >their rewrite. Hopefully it will be more succinct. >> >S >> >-----Original Message----- >> >From: Michael.Dillon at radianz.com [mailto:Michael.Dillon at radianz.com] >> >Sent: Wednesday, February 19, 2003 6:39 AM >> >To: ppml at arin.net >> >Subject: [ppml] Withdrawal of 2002-7 >> > >> > >> >My take on the discussion of 2002-7 is that it is bad policy >> >because it >> >mixes too many issues together. I have nothing against an >> >omnibus policy >> >as long as it is well organized so that the individual issues >> >are clear in >> >and of themselves. But 2002-7 doesn't do that and as a result the >> >discussion just keeps going around in twisted and >convoluted circles. >> > >> >Therefore, I suggest that ARIN should set aside this policy >> >proposal and >> >not give it any further consideration. >> > >> >Ron Da Silva has made a very good suggestion for separating >> >the distinct >> >items and discussing them in separate threads. I would like >to further >> >suggest that these items be discussed with an intent to turn >> >them into a >> >series of separate policy proposals. To refresh your memories, Ron >> >suggested that we should deal with the following separate issues: >> > >> >Revocation - under what conditions should ARIN revoke an address >> >allocation? Should this action extend to include assignments? >> > >> >Enforcement - what actions should ARIN take to enforce its >> >allocations and >> >its policies, if any? >> > >> >Leasing - what AUP should ARIN impose on anyone receiving an >> >allocation to >> >ensure that any "lease terms" are passed on to sub-allocations and >> >assignments? >> > >> >Accuracy of data - what is ARIN's policy regarding the >> >accuracy of SWIP >> >and rwhois data? How will ARIN enforce this policy? >> > >> >Then he suggested an item regarding IETF cooperation that >> >wasn't clear to >> >me but which appears to include my following suggestion: >> > >> >Public Authoritative Directory: >> >---------------------------- >> >ARIN will publish an authoritative directory for all of the >IP address >> >space which it administers. >> > >> >This directory will be public and will be published using >LDAP v3 also >> >known as referral LDAP. >> > >> >Only a minimal set of information will be made fully >public, i.e. one >> >email address and one phone number per organization along with the >> >organization's name and city. >> >Additional contact information, personal names and street >> >addresses will >> >be in the directory but will only be accessible to ARIN >> >members who are in >> >posession of suitable credentials. >> >The intent is to facilitate communication while inhibiting >> >email address >> >scraping and stalking. >> > >> >All organizations receiving ARIN allocations must either >maintain an >> >accurate record of their sub-allocations and assignment with >> >ARIN or they >> >must operate an LDAP v3 server containing such information and >> >open to the >> >public. >> > >> >ARIN will ensure that existence information is updated in this >> >directory >> >on a daily basis. >> >Existence information refers to the fact that an allocation >> >exists, i.e. >> >it has been allocated and has not been revoked. >> > >> >ARIN will also do a twice yearly audit of the accuracy of >the contact >> >information in this database. >> > >> >When contacts do not respond, the data in the ARIN database will be >> >replaced with contact info for the next level up in the hierarchy. >> >In other words, if an ISP gets address space from UUNet and >does not >> >respond during the audit, then ARIN will record UUNet >contact info for >> >this ISP. >> >The intent is to ensure that there is an identifiable and >responsive >> >contact for all address space that is legitimately in use. >> > >> >ARIN will provide a mirroring mechanism for this directory and >> >encourage >> >organizations to mirror the entire directory for use in their >> >firewalls, >> >route servers, etc. >> > >> >ARIN will warn that it is not good engineering practice to >> >connect this >> >directory directly to BGP route filters but will not prohibit the >> >practice. >> >However ARIN will disclaim all responsibility for any >damage that may >> >result from such misuse. >> > >> >Please CHANGE THE SUBJECT if you wish to discuss one of >these policy >> >items. >> > >> >---- >> >Michael Dillon >> > >> > > > From owen at delong.com Wed Feb 19 17:36:40 2003 From: owen at delong.com (Owen DeLong) Date: Wed, 19 Feb 2003 14:36:40 -0800 Subject: [ppml] Revocation In-Reply-To: <20030219211153.GA23909@aol.net> References: <200302190906.BAA10696@dixon.DeLong.SJ.CA.US> <2147483647.1045652506@imac-en0.delong.sj.ca.us> <20030219211153.GA23909@aol.net> Message-ID: <2147483647.1045665400@dhcp156-223.corp.tellme.com> Ron, Excellent feedback! Thanks. My responses inline below. Owen --On Wednesday, February 19, 2003 16:11 -0500 Ron da Silva wrote: > On Wed, Feb 19, 2003 at 11:01:46AM -0800, Owen DeLong wrote: >> > >> Whatcha all think? > > Nice detailed proposal. One area that needs some more meat is > the definition of abuse. Any suggestions there would be great! > Agreed. I think abuse needs to be defined for this purpose through the RFC or BCP process in the IETF and incorporated by reference by ARIN. In this way, there is an internet definition of abuse, which ARIN (and hopefully other RIRs) simply facilitate the enforcement by providers. > I do have some particulars about the details to consider... > >> 2. Each RIR should publish a list of valid prefixes and the ASN to which >> they were Allocated or Assigned. Ideally, this list should be available >> in a machine-readable format and published by means of a well known >> protocol. > > Do we need a mechanism for downstream allocations/assignments to be mapped > to an origin ASN by the ARIN member when downstreams are not members? > If they have an ASN, they have a maintainer record. Whether they are a member or not, they are a maintainer. It is maintainers, not members, which I believe should be subject to the policy. If they don't have an ASN, it's hard to consider them in ARIN policy effectively. However, certainly, a provider should be allowed to revoke the resource from the assignee without penalty to the provider in such circumstance. >> 5. ARIN should set up a revocation review committee made up of >> representatives from ARIN members with allocations and nominated >> by the ASO AC. The members should be elected for a 2 year >> term by the community at large (similar to the ASO AC election >> at the ARIN/NANOG meeting). The committee should consist >> of 7 members. > > Nominated by ASO AC or ARIN AC? Or, by general community? Any > requirements for candidacy? > I recommend nomination by ASO AC. My theory for this is that this is an ADDRESS SUPPORTING role. As I understand it, the ASO AC comes from ARIN and other sources which have a vested interest in ASO activities. I don't have any strong opinions on requirements for candidacy other than 18 years of age and the ability to do the job. Beyond that, I think that if the ASO AC can't be trusted to nominate good candidates, we have bigger problems than the things this committee can influence. Again, nominated by ASO AC, and elected by general community. >> 6. The revocation process should look something like the following... >> B. ARIN staff investigates and confirms abuse. If abuse is >> not confirmed, the process ends here... > > How is abuse confirmed? Again, related to the definition of abuse. > Agreed. See my comments on the definition of abuse above. I know this is kind of a cop-out on my part, but I will comment on the definition of abuse when/if I come up with a good formulation for it. However, I do feel that discussion should take place in an RFC/BCP context and not on the ARIN policy list. For now, the things I think need to be included as abuse at a minimum are: + Activities which are illegal in the jurisdictions applicable to the address on file for the maintainer. + Activities which are intended to interferre with the normal functioning of the internet (DDOS, Worms, Viruses, etc.) + Obviously, some definition of the sending of SPAM and/or hosting of sites advertised in SPAM should also be included. >> D. If, 15 days after the message is received by the maintainer, >> the abuse has not been resolved, ARIN should immediately >> revoke the applicable allocations and/or assignments, >> and refer the matter to the committee. > > Similarly, how is resolution of abuse determined? > Basically, once abuse is defined, resolution would simply be defined as the identified abuse no longer continuing to occur/recur. Obviously, some more elaborate language will need to be crafted to cover situations like abuse->notification->stop->resolve->start again and/or abuse->notification->stop->resolve->different abuse. I don't have a good idea on the exact language just yet. >> E. If the maintainer wishes to appeal the decision, he should >> notify the committee of his desire to appeal within 30 >> days. The maintainer should submit his appeal in written >> form (preferably via electronic means). The committee has >> 60 days to review the information before it must render a >> decision. The committee's decision is final... > > How does one ensure that there is no abuse by the committee itself? > Or do we trust the judgment of the committee based on the nomination > process? > I think we have to trust the judgement of the committee and the RIR staff. Afterall, the committee can't originate an abuse revocation, they can only stop one or confirm it. As such, they have little power to abuse other than to approve the continuing abuse. I think we should be able to depend on the election process to prevent this, although, it does identify a possible need for a recall process on the committee. > Also, would a reinstatement process be needed? > In my opinion, no. However, I can see circumstances where it would be necessary to make a revocation provisional or temporary in a case where for some reason, 15 days isn't long enough to fully resolve the abuse (bad contract or such). In such a case, I think we should include language to give the committee this flexibility. If the committee feels that a resource needs to be permanently revoked, then the abuser, if sufficiently determined, can create a new org and start the process all over again. This doesn't seem like an excessive penalty, in my opinion. Owen From jmcburnett at msmgmt.com Wed Feb 19 19:13:14 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 19 Feb 2003 19:13:14 -0500 Subject: [ppml] 2002-7--- A New idea--- Message-ID: <390E55B947E7C848898AEBB9E50770600EB603@msmdcfs01.msmgmt.com> If we went exactly by the APNIC policy- they do not stipulate a block size... Then maybe we, those of us in ARIN, are too bent around the axel with US Law and triyng to be TOO exact and TOO strict. Think of this. 2001-2 justifies a Class C for Multihoming. Change the below to read: You can apply for an assigment of any size with a minimum of a /24, as defined bby ARIN 2001-2. All blocks large than a /24 are subject to standard 25 % and 50 % usage requirements as defined by current ARIN policy. Anyway I consider this to be simple. Let's plagerize (SP?), submit this to voting members and move on.. Jim APNIC website as noted below.. QUOTE What size are the assignments? You can apply for an assignment of any size provided you can demonstrate the need for that space. You must demonstrate that you will use 25 percent of the assignment immediately and 50 percent within one year. Please remember, APNIC cannot guarantee the routability of any assignment it makes and very small assignments may not be globally routable. Top Is there a maximum or minimum assignment size? No. Assignments are based on demonstrated need. However, if you are close to meeting the minimum allocation size (/20), you may find it more economical to become an APNIC member and apply for a portable allocation using the APNIC IPv4 ISP request form. END QUOTE: > -----Original Message----- > From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com] > Sent: Wednesday, February 19, 2003 5:51 PM > To: McBurnett, Jim; ppml at arin.net > Subject: RE: [ppml] 2002-7--- A New idea--- > > > Shouldn't we have a minimum /24 assignment, though? > S > > -----Original Message----- > From: McBurnett, Jim [mailto:jmcburnett at msmgmt.com] > Sent: Wednesday, February 19, 2003 2:43 PM > To: ppml at arin.net > Subject: RE: [ppml] 2002-7--- A New idea--- > > > Everyone let's cut the red tape.. > Everyone read the attached FAQ that Forrest sent. > This is the answer.. > Jim > > > >-----Original Message----- > >From: Forrest [mailto:forrest at almighty.c64.org] > >Sent: Wednesday, February 19, 2003 5:37 PM > >To: ppml at arin.net > >Subject: Re: [ppml] 2002-7--- A New idea--- > > > > > > > >It appears that APNIC assigns small blocks of portable IP > addresses to > >multihomed organizations. > > > >http://www.apnic.net/info/faq/multihoming_faq.html > > > >Forrest > > > >On Wed, 19 Feb 2003, McBurnett, Jim wrote: > > > >> I have an idea: > >> Does any other RIR have a policy like this? > >> If so, let's cheat and look at their's and see if we can use > >it? Why reinvent the wheel? > >> And why didn't someone else think about this? > >> > >> Later, > >> Jim > >> > >> > >> > >> > >> >-----Original Message----- > >> >From: Taylor, Stacy [mailto:Stacy_Taylor at icgcomm.com] > >> >Sent: Wednesday, February 19, 2003 1:20 PM > >> >To: 'Michael.Dillon at radianz.com'; ppml at arin.net > >> >Subject: RE: [ppml] Withdrawal of 2002-7 > >> > > >> > > >> >I agree with Michael. Let's see what the authors of 2002-3 > >> >come up with in > >> >their rewrite. Hopefully it will be more succinct. > >> >S > >> >-----Original Message----- > >> >From: Michael.Dillon at radianz.com > [mailto:Michael.Dillon at radianz.com] > >> >Sent: Wednesday, February 19, 2003 6:39 AM > >> >To: ppml at arin.net > >> >Subject: [ppml] Withdrawal of 2002-7 > >> > > >> > > >> >My take on the discussion of 2002-7 is that it is bad policy > >> >because it > >> >mixes too many issues together. I have nothing against an > >> >omnibus policy > >> >as long as it is well organized so that the individual issues > >> >are clear in > >> >and of themselves. But 2002-7 doesn't do that and as a result the > >> >discussion just keeps going around in twisted and > >convoluted circles. > >> > > >> >Therefore, I suggest that ARIN should set aside this policy > >> >proposal and > >> >not give it any further consideration. > >> > > >> >Ron Da Silva has made a very good suggestion for separating > >> >the distinct > >> >items and discussing them in separate threads. I would like > >to further > >> >suggest that these items be discussed with an intent to turn > >> >them into a > >> >series of separate policy proposals. To refresh your > memories, Ron > >> >suggested that we should deal with the following separate issues: > >> > > >> >Revocation - under what conditions should ARIN revoke an address > >> >allocation? Should this action extend to include assignments? > >> > > >> >Enforcement - what actions should ARIN take to enforce its > >> >allocations and > >> >its policies, if any? > >> > > >> >Leasing - what AUP should ARIN impose on anyone receiving an > >> >allocation to > >> >ensure that any "lease terms" are passed on to > sub-allocations and > >> >assignments? > >> > > >> >Accuracy of data - what is ARIN's policy regarding the > >> >accuracy of SWIP > >> >and rwhois data? How will ARIN enforce this policy? > >> > > >> >Then he suggested an item regarding IETF cooperation that > >> >wasn't clear to > >> >me but which appears to include my following suggestion: > >> > > >> >Public Authoritative Directory: > >> >---------------------------- > >> >ARIN will publish an authoritative directory for all of the > >IP address > >> >space which it administers. > >> > > >> >This directory will be public and will be published using > >LDAP v3 also > >> >known as referral LDAP. > >> > > >> >Only a minimal set of information will be made fully > >public, i.e. one > >> >email address and one phone number per organization along > with the > >> >organization's name and city. > >> >Additional contact information, personal names and street > >> >addresses will > >> >be in the directory but will only be accessible to ARIN > >> >members who are in > >> >posession of suitable credentials. > >> >The intent is to facilitate communication while inhibiting > >> >email address > >> >scraping and stalking. > >> > > >> >All organizations receiving ARIN allocations must either > >maintain an > >> >accurate record of their sub-allocations and assignment with > >> >ARIN or they > >> >must operate an LDAP v3 server containing such information and > >> >open to the > >> >public. > >> > > >> >ARIN will ensure that existence information is updated in this > >> >directory > >> >on a daily basis. > >> >Existence information refers to the fact that an allocation > >> >exists, i.e. > >> >it has been allocated and has not been revoked. > >> > > >> >ARIN will also do a twice yearly audit of the accuracy of > >the contact > >> >information in this database. > >> > > >> >When contacts do not respond, the data in the ARIN > database will be > >> >replaced with contact info for the next level up in the > hierarchy. > >> >In other words, if an ISP gets address space from UUNet and > >does not > >> >respond during the audit, then ARIN will record UUNet > >contact info for > >> >this ISP. > >> >The intent is to ensure that there is an identifiable and > >responsive > >> >contact for all address space that is legitimately in use. > >> > > >> >ARIN will provide a mirroring mechanism for this directory and > >> >encourage > >> >organizations to mirror the entire directory for use in their > >> >firewalls, > >> >route servers, etc. > >> > > >> >ARIN will warn that it is not good engineering practice to > >> >connect this > >> >directory directly to BGP route filters but will not prohibit the > >> >practice. > >> >However ARIN will disclaim all responsibility for any > >damage that may > >> >result from such misuse. > >> > > >> >Please CHANGE THE SUBJECT if you wish to discuss one of > >these policy > >> >items. > >> > > >> >---- > >> >Michael Dillon > >> > > >> > > > > > > > From forrest at almighty.c64.org Wed Feb 19 20:41:12 2003 From: forrest at almighty.c64.org (Forrest) Date: Wed, 19 Feb 2003 19:41:12 -0600 (CST) Subject: [ppml] 2002-7--- A New idea--- In-Reply-To: <390E55B947E7C848898AEBB9E50770600EB603@msmdcfs01.msmgmt.com> Message-ID: On Wed, 19 Feb 2003, McBurnett, Jim wrote: > If we went exactly by the APNIC policy- > they do not stipulate a block size... > Then maybe we, those of us in ARIN, are too bent around the > axel with US Law and triyng to be TOO exact and TOO strict. > > Think of this. 2001-2 justifies a Class C for Multihoming. > Change the below to read: > You can apply for an assigment of any size with a minimum of a /24, as defined bby ARIN 2001-2. > All blocks large than a /24 are subject to standard 25 % and 50 % usage requirements as defined by current ARIN > policy. > I don't really think you need to specify a minimum block size for this. Assuming ARIN adopted the exact same policy/fees that APNIC is using, I can't imagine anyone paying $1200 per year for a /25 or longer. Not to mention that most of the internet isn't going to accept their route anyway. I think APNIC's policy is a little vague though, there doesn't seem to be any requirement to continue being multi-homed after receiving your IP assignment. APNIC's policy is a good template to work from but I think something needs to be added to it saying that your IP space will be revoked if you can't prove that you're still multihomed when it comes time to pay your annual IP address and/or ASN fee. I think something also needs to be added saying that these small IP assignments will come from blocks within the old Class C space to avoid being filtered by ISP's that filter on the old class boundries. Otherwise, you may find that your /23 assignment out of 69.0.0.0/8 is blackholed by some providers. Forrest From jrace at attglobal.net Thu Feb 20 00:07:50 2003 From: jrace at attglobal.net (Dr. Jeffrey Race) Date: Thu, 20 Feb 2003 12:07:50 +0700 Subject: [ppml] Abstract of proposed Internet Draft for Best Current Practice (please comment) Message-ID: <200302200508.h1K58Bqn034567@smtp1.arin.net> On Wed, 19 Feb 2003 23:14:40 +1000, Keith Talent wrote: >And what happens to all the non-spamming customers of an ISP who has their addresses revoked on the basis that a another customer spams? Will each of those innocent customers have a potential lawsuit? Extract from "Even the best ISPs (including my own, AT&T) occasionally fall afoul of blocklists, but they cure the problem fast. Indeed it is almost comical how fast spamming stops when a blocklist is used, or even just threatened. Consider the case of Connect, one of Australia's largest ISPs, which long harbored a notorious spammer. At 10:00 a.m. on January 3 a group of concerned system administrators finally tired of politely asking Connect to shape up and instead laid down their new zero-tolerance policy: blocking would ensue that day unless Connect disconnected the spammers on its network. By 1:30 p.m. the spammers were gone, with no interruption in service. Merely the threat of disconnection from the Internet caused management to pull up its socks. A similar incident occurred in late September in Australia when Optus defiantly refused to cut spammers loose. Blocklist adoption by an important group of victims forced Optus to change its policy two days later. In an equally dramatic incident Earthlink, an American ISP not famous for cracking down on spammers, was forced to sue abusers, stating in its pleading that it finally had to act because blocklists jeopardized its Internet connectivity. Before the blocklists Earthlink was content to let injury accrue to the victims on other networks; after the blocklists began to bite, Earthlink was motivated to put its own house in order due to the magic of "actions have consequences"." Reference: Jeffrey Race From ron at aol.net Thu Feb 20 15:20:30 2003 From: ron at aol.net (Ron da Silva) Date: Thu, 20 Feb 2003 15:20:30 -0500 Subject: [ppml] Revocation In-Reply-To: <2147483647.1045665400@dhcp156-223.corp.tellme.com> References: <200302190906.BAA10696@dixon.DeLong.SJ.CA.US> <2147483647.1045652506@imac-en0.delong.sj.ca.us> <20030219211153.GA23909@aol.net> <2147483647.1045665400@dhcp156-223.corp.tellme.com> Message-ID: <20030220202030.GS24515@aol.net> On Wed, Feb 19, 2003 at 02:36:40PM -0800, Owen DeLong wrote: > Agreed. I think abuse needs to be defined for this purpose through the > RFC or BCP process in the IETF and incorporated by reference by ARIN. > In this way, there is an internet definition of abuse, which ARIN (and > hopefully other RIRs) simply facilitate the enforcement by providers. I like this approach. > If they have an ASN, they have a maintainer record... Is this always true? Are there ASNs from other sources or pre-ARIN assignments, or direct assignments from IANA or other source that do not have a maintainer. Would it be easier to have the policy applied only to maintainers then instead? Also, then the definition of abuse (see above) will need to make sure that it is maintainer associated rather than ip address based. > Whether they are a member or not, they are a maintainer... Just to be clear, what do you mean by a maintainer? Do you mean an OrgId? or something else here? -ron From ras at e-gerbil.net Mon Feb 24 14:16:27 2003 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 24 Feb 2003 14:16:27 -0500 Subject: [ppml] IPv6 Justifications Message-ID: <20030224191627.GC25273@overlord.e-gerbil.net> > 1. Please describe what IPv6 services you expect to offer. If > available, provide the URL that details the services. > > > 2. Please provide a date for your deployment of V6 service. > > > 3. ARIN will need to see your plan for making at least 200 > /48 assignments to other organizations within 2 years. Please > use the following format to provdide your topology plan. Would someone please explain to me why in gods name ARIN thinks they need to continue the IP justification anal-probes into v6? Is there some pre-planned v6 shortage I'm not aware of? I am completely appalled that as an early adopter applying for v6 space, one would be required to provide topologies and plans to make 200 assignments. Let's be realistic, in the US there aren't tons of people willing to pay for v6 services right now. Maybe we should try putting the horse before the cart here? -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From richardj at arin.net Mon Feb 24 14:57:18 2003 From: richardj at arin.net (Richard Jimmerson) Date: Mon, 24 Feb 2003 14:57:18 -0500 Subject: [ppml] IPv6 Justifications In-Reply-To: <20030224191627.GC25273@overlord.e-gerbil.net> Message-ID: <00cf01c2dc3e$f0ae40f0$478888c0@Cobalt2> Hello Richard, The current IPv6 policy in place that ARIN staff uses to review requests for IPv6 address space cites the 200 /48 assignments in two years language, therefore asking questions about that is part of the request process. There has been some discussion on this list recently about possibly modifying the policy to remove the 200 customers within two years criteria language. Some participants on this list have stated the 200 /48 assignments in two years criteria may actually be preventing organizations from requesting IPv6 address space from the Regional Internet Registries. One individual has posted a policy proposal to this mailing list for discussion that would change the 200 customers within two years criteria. Along with other policy proposals this one will be re-posted to the ARIN public policy mailing list later this week for discussion prior to the upcoming public policy meeting scheduled for April 6 - 9. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Richard A Steenbergen > Sent: Monday, February 24, 2003 2:16 PM > To: ppml at arin.net > Subject: [ppml] IPv6 Justifications > > > > 1. Please describe what IPv6 services you expect to offer. If > > available, provide the URL that details the services. > > > > > > 2. Please provide a date for your deployment of V6 service. > > > > > > 3. ARIN will need to see your plan for making at least 200 /48 > > assignments to other organizations within 2 years. Please use the > > following format to provdide your topology plan. > > Would someone please explain to me why in gods name ARIN > thinks they need to continue the IP justification anal-probes > into v6? Is there some > pre-planned v6 shortage I'm not aware of? > > I am completely appalled that as an early adopter applying for v6 > space, one would be required to provide topologies and plans > to make 200 > assignments. Let's be realistic, in the US there aren't tons > of people > willing to pay for v6 services right now. > > Maybe we should try putting the horse before the cart here? > > -- > Richard A Steenbergen > http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 > 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) > From david.conrad at nominum.com Mon Feb 24 16:26:56 2003 From: david.conrad at nominum.com (David Conrad) Date: Mon, 24 Feb 2003 13:26:56 -0800 Subject: [ppml] IPv6 Justifications In-Reply-To: <20030224191627.GC25273@overlord.e-gerbil.net> Message-ID: On Monday, February 24, 2003, at 11:16 AM, Richard A Steenbergen wrote: > Would someone please explain to me why in gods name ARIN thinks they > need > to continue the IP justification anal-probes into v6? Swamp (or repeating history) avoidance? Rgds, -drc (Speaking personally) From jsw at five-elements.com Mon Feb 24 18:06:24 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 24 Feb 2003 18:06:24 -0500 Subject: [ppml] IPv6 Justifications In-Reply-To: <00cf01c2dc3e$f0ae40f0$478888c0@Cobalt2> References: <00cf01c2dc3e$f0ae40f0$478888c0@Cobalt2> Message-ID: <1046127984.990.250.camel@intrepid> On Mon, 2003-02-24 at 14:57, Richard Jimmerson wrote: > The current IPv6 policy in place that ARIN staff uses to > review requests for IPv6 address space cites the 200 /48 > assignments in two years language, therefore asking > questions about that is part of the request process. I'm not aware of the issues surrounding the implementation of ARIN policy, so perhaps you can enlighten me. If there is a FAQ or other document which I have missed, I must apologize in advance for being ignorant of this resource. What is the reason that ARIN chooses to implement policy and operate in a manner that restricts IPv6 assignments in such a manner as to hinder IPv6's wide-spread adoption, when, seemingly, ARIN refuses to implement an IPv4 small-multihomer policy, such as 2002-7, which was adopted by the membership's voting body, as I understand. I am not aware of the process by which ARIN's operations are governed, however I would appreciate any insight you could give me with regard to policy-making matters in general, and specifically the non-implementation of 2002-7. Kind thanks, -- Jeff S Wheeler From mury at goldengate.net Mon Feb 24 18:20:41 2003 From: mury at goldengate.net (Mury) Date: Mon, 24 Feb 2003 17:20:41 -0600 (CST) Subject: [ppml] FYI: Policy Revision Proposal - IPv6 Message-ID: For those that were asking about the IPv6 policies here are some changes I suggested that should be up for review... Mury ---------- Forwarded message ---------- Date: Thu, 9 Jan 2003 16:42:14 -0600 (CST) From: Mury To: ppml at arin.net Subject: Policy Revision Proposal I propose the following additions to: http://www.arin.net/policy/ipv6_policy.html Regards, Mury GoldenGate Internet Services 5.1.1 [under d) add: Other oganizations are defined as any customer of the LIR. No distinction will be made in terms of number of IP addresses required, even if that number is one. 5.8 Allocation for Early Adopters 5.8.1 Waiver of criteria listed in 5.1.1 (d) To promote the allocation of IPv6 space the requirment to make 200 /48 assignments within two years shall be waived for anyone requesting IPv6 space before Dec 31, 2004 or until this policy is ammended. In the event that this policy is ammended the existing IPv6 space holders shall not be subject to new or waived criteria for a period of 10 years from their initial allocation date. 5.8.2 Waiver of fees a) To promote the allocation of IPv6 space all IPv6 related fees shall be waived until Dec 31, 2006 for anyone requesting and receiving space before Dec 31, 2004. In the even that this policy is ammended the existing IPv6 space holders shall under no circumstances be subject to waived or new fees until Dec 31, 2006. b) For billing purposes fees will be due according to normal ARIN billing policies on Jan 1, 2007. All early adopters will have the same billing date regardless of the date they received their allocation. 5.8.3 Micro Allocations a) To promote the allocation and deployment of IPv6 all the criteria in 5.1.1 shall be waived to those requesting a /48 micro allocation before Dec 31, 2004, or until this policy is changed. If this policy is changed, current space holders shall not be subject to any new or waived criteria. b) All fees shall be waived under the same rules listed in 5.8.2. c) Those receiving micro allocations shall not be allowed to make further allocations or assignments out of their /48. It is intended for their internal use only. d) When possible those receiving micro allocations shall return their allocation and receive a new /48 from their upstream provider (a LIR). This is requested in a good faith manner until Jan 1, 2007 at which time all micro allocations granted under these waived criteria must be returned. From john at chagres.net Mon Feb 24 18:21:33 2003 From: john at chagres.net (John M. Brown) Date: Mon, 24 Feb 2003 16:21:33 -0700 Subject: [ppml] IPv6 Justifications In-Reply-To: Message-ID: <001201c2dc5b$7834dc20$f9ecdfd8@laptoy> seems unlikely that we will repeat the swamp problem since people can't even get the space to begin with. is it avoidance, or has the ball swung to far the other way that we are "BLOCKING" the adoption of space by way of a visceral desire to not repeat all the mistakes of the past. perfect may be our enemy of getting it done here..... john brown IXNM, New Mexico's Neutral IX and Co-op Wanting portable IPv6 Space, never having 200 /48 clients thus not meeting the requirements, thus can't get space, thus no early adoption...... > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of David Conrad > Sent: Monday, February 24, 2003 2:27 PM > To: Richard A Steenbergen > Cc: ppml at arin.net > Subject: Re: [ppml] IPv6 Justifications > > > On Monday, February 24, 2003, at 11:16 AM, Richard A > Steenbergen wrote: > > Would someone please explain to me why in gods name ARIN thinks they > > need > > to continue the IP justification anal-probes into v6? > > Swamp (or repeating history) avoidance? > > Rgds, > -drc > (Speaking personally) > From richardj at arin.net Mon Feb 24 20:11:26 2003 From: richardj at arin.net (Richard Jimmerson) Date: Mon, 24 Feb 2003 20:11:26 -0500 Subject: [ppml] IPv6 Justifications In-Reply-To: <1046127984.990.250.camel@intrepid> Message-ID: <00fb01c2dc6a$d2213170$478888c0@Cobalt2> Hello Jeff, The current IPv6 policies implemented by the ARIN staff were created by the ARIN community. In the case of the IPv6 addressing policies, the same policy is implemented across all four Regional Internet Registries (APNIC, ARIN, LACNIC, and RIPE NCC). A single IPv6 policy document was agreed to by the communities of all the RIRs. When it comes to implementing an IPv4 policy for small multihomed organizations, that is up to the ARIN community, not the ARIN staff. ARIN staff does not make decisions about Internet resource policy. A full description of the process is available at http://www.arin.net/policy/ipep.html. Policy Proposal 2002-7 did not achieve consensus with the community to be passed as written at the last ARIN meeting. Policy Proposals 2002-3 and 2002-7 were very similar, as both proposed small IPv4 assignments/allocations for multihomed organizations. The authors of policy proposal 2002-3 have drafted some clarifying language that will be posted to the public policy mailing list for discussion, along with all other policy proposals, over the next week. Best Regards, Richard Jimmerson Director of Operations American Registry for Internet Numbers (ARIN) > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of Jeff S Wheeler > Sent: Monday, February 24, 2003 6:06 PM > To: ppml at arin.net > Cc: richardj at arin.net > Subject: RE: [ppml] IPv6 Justifications > > > On Mon, 2003-02-24 at 14:57, Richard Jimmerson wrote: > > The current IPv6 policy in place that ARIN staff uses to review > > requests for IPv6 address space cites the 200 /48 > assignments in two > > years language, therefore asking questions about that is > part of the > > request process. > I'm not aware of the issues surrounding the implementation of > ARIN policy, so perhaps you can enlighten me. If there is a > FAQ or other document which I have missed, I must apologize > in advance for being ignorant of this resource. > > What is the reason that ARIN chooses to implement policy and > operate in a manner that restricts IPv6 assignments in such a > manner as to hinder IPv6's wide-spread adoption, when, > seemingly, ARIN refuses to implement an IPv4 small-multihomer > policy, such as 2002-7, which was adopted by the membership's > voting body, as I understand. I am not aware of the process > by which ARIN's operations are governed, however I would > appreciate any insight you could give me with regard to > policy-making matters in general, and specifically the > non-implementation of 2002-7. > > Kind thanks, > > -- > Jeff S Wheeler > From david.conrad at nominum.com Mon Feb 24 20:29:25 2003 From: david.conrad at nominum.com (David Conrad) Date: Mon, 24 Feb 2003 17:29:25 -0800 Subject: [ppml] IPv6 Justifications In-Reply-To: <001201c2dc5b$7834dc20$f9ecdfd8@laptoy> Message-ID: <93486D88-4860-11D7-92B3-000393DB42B2@nominum.com> John, On Monday, February 24, 2003, at 03:21 PM, John M. Brown wrote: > seems unlikely that we will repeat the swamp problem > since people can't even get the space to begin with. I thought RIPE-NCC and APNIC, with essentially the same policies, have allocated not insignificant amounts of space. Is this not correct? Rgds, -drc (Speaking personally) From john at chagres.net Mon Feb 24 20:43:45 2003 From: john at chagres.net (John M. Brown) Date: Mon, 24 Feb 2003 18:43:45 -0700 Subject: [ppml] IPv6 Justifications In-Reply-To: <93486D88-4860-11D7-92B3-000393DB42B2@nominum.com> Message-ID: <002f01c2dc6f$55b2b190$f9ecdfd8@laptoy> True, but the basis of RIPE-NCC and APNIC is membership. Pay the annual membership fee and get space. in addition those regions have more "uptake" of IPv6 compared to the ARIN region. This isn't about RIPE-NCC or APNIC. Its about ARIN and the policies as viewed from potential members, existing members and those that want to make use of IPv6 space. We are arguing over different points, when the basic point is that. ARIN REGION Members feel the policy for getting IPv6 space is preventing them from doing so. ARIN REGION internet users (non-members and members) are interested in becoming early adopters of IPv6 services and technoloiges, yet the policy prevents these people from getting the integers they need. If we want to see IPv6 start moving, we have to allow people to get the space, use the space, make requests to the backbone providers that they want native transport, etc. Why not allow early adopters, reguardless to if they have ARIN alloc'd v4 space or not, to easily, cheaply get a /35, heck even a /48 would be plenty for these folks. Create an "early adopters micro-alloc" program. a /48 is what, 65535 /64 neworks ? Should be plenty to allow early adopters to play with stuff. I'd love there to be the problem of "Route Table Growth" :) Me thinks we are over worrying about the issues of v4 wrt v6. > -----Original Message----- > From: David Conrad [mailto:david.conrad at nominum.com] > Sent: Monday, February 24, 2003 6:29 PM > To: john at chagres.net > Cc: ppml at arin.net > Subject: Re: [ppml] IPv6 Justifications > > > John, > > On Monday, February 24, 2003, at 03:21 PM, John M. Brown wrote: > > seems unlikely that we will repeat the swamp problem > > since people can't even get the space to begin with. > > I thought RIPE-NCC and APNIC, with essentially the same > policies, have > allocated not insignificant amounts of space. Is this not correct? > > Rgds, > -drc > (Speaking personally) > From jmcburnett at msmgmt.com Mon Feb 24 20:59:45 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Mon, 24 Feb 2003 20:59:45 -0500 Subject: [ppml] IPv6 Justifications Message-ID: <390E55B947E7C848898AEBB9E507706041E34B@msmdcfs01.msmgmt.com> Here Here... I agree. John, I know it is too late for a policy proposal for the upcoming meeting, but should we push this out anyway? Jim > -----Original Message----- > From: John M. Brown [mailto:john at chagres.net] > Sent: Monday, February 24, 2003 8:44 PM > To: ppml at arin.net > Subject: RE: [ppml] IPv6 Justifications > > > True, but the basis of RIPE-NCC and APNIC is membership. > Pay the annual membership fee and get space. > > in addition those regions have more "uptake" of IPv6 > compared to the ARIN region. > > This isn't about RIPE-NCC or APNIC. Its about ARIN > and the policies as viewed from potential members, existing > members and those that want to make use of IPv6 space. > > We are arguing over different points, when the basic point > is that. > > ARIN REGION Members feel the policy for getting IPv6 space > is preventing them from doing so. > > ARIN REGION internet users (non-members and members) are interested > in becoming early adopters of IPv6 services and technoloiges, > yet the policy prevents these people from getting the integers > they need. > > If we want to see IPv6 start moving, we have to allow people > to get the space, use the space, make requests to the backbone > providers that they want native transport, etc. > > > Why not allow early adopters, reguardless to if they have ARIN > alloc'd v4 space or not, to easily, cheaply get a /35, heck even > a /48 would be plenty for these folks. > > Create an "early adopters micro-alloc" program. > > a /48 is what, 65535 /64 neworks ? Should be plenty to > allow early adopters to play with stuff. > > I'd love there to be the problem of "Route Table Growth" :) > > Me thinks we are over worrying about the issues of v4 wrt v6. > > > > > -----Original Message----- > > From: David Conrad [mailto:david.conrad at nominum.com] > > Sent: Monday, February 24, 2003 6:29 PM > > To: john at chagres.net > > Cc: ppml at arin.net > > Subject: Re: [ppml] IPv6 Justifications > > > > > > John, > > > > On Monday, February 24, 2003, at 03:21 PM, John M. Brown wrote: > > > seems unlikely that we will repeat the swamp problem > > > since people can't even get the space to begin with. > > > > I thought RIPE-NCC and APNIC, with essentially the same > > policies, have > > allocated not insignificant amounts of space. Is this not correct? > > > > Rgds, > > -drc > > (Speaking personally) > > > > From john at chagres.net Mon Feb 24 21:10:53 2003 From: john at chagres.net (John M. Brown) Date: Mon, 24 Feb 2003 19:10:53 -0700 Subject: [ppml] IPv6 Justifications In-Reply-To: <390E55B947E7C848898AEBB9E507706041E34B@msmdcfs01.msmgmt.com> Message-ID: <003001c2dc73$1fe50e10$f9ecdfd8@laptoy> Don't see why its to late to submit a draft policy for the upcoming meeting. Bylaws say 30 days. Meeting is Monday 7-April. Seems like we have at least till 28-Feb, to get stuff to Richard, who could then get it posted by the 6-Mar time to be in agreement with the By-laws. Anyone what to work with me on making changes to the existing policy and submitting that to ARIN ?? Note: Don't signup unless you intend to work quick and hard :) john brown > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of McBurnett, Jim > Sent: Monday, February 24, 2003 7:00 PM > To: ppml at arin.net > Subject: RE: [ppml] IPv6 Justifications > > > Here Here... > I agree. John, I know it is too late for a policy proposal > for the upcoming meeting, but should we push this out anyway? > > Jim > > > -----Original Message----- > > From: John M. Brown [mailto:john at chagres.net] > > Sent: Monday, February 24, 2003 8:44 PM > > To: ppml at arin.net > > Subject: RE: [ppml] IPv6 Justifications > > > > > > True, but the basis of RIPE-NCC and APNIC is membership. > > Pay the annual membership fee and get space. > > > > in addition those regions have more "uptake" of IPv6 > > compared to the ARIN region. > > > > This isn't about RIPE-NCC or APNIC. Its about ARIN > > and the policies as viewed from potential members, existing members > > and those that want to make use of IPv6 space. > > > > We are arguing over different points, when the basic point > > is that. > > > > ARIN REGION Members feel the policy for getting IPv6 space > > is preventing them from doing so. > > > > ARIN REGION internet users (non-members and members) are > interested in > > becoming early adopters of IPv6 services and technoloiges, yet the > > policy prevents these people from getting the integers they need. > > > > If we want to see IPv6 start moving, we have to allow people to get > > the space, use the space, make requests to the backbone > providers that > > they want native transport, etc. > > > > > > Why not allow early adopters, reguardless to if they have > ARIN alloc'd > > v4 space or not, to easily, cheaply get a /35, heck even a > /48 would > > be plenty for these folks. > > > > Create an "early adopters micro-alloc" program. > > > > a /48 is what, 65535 /64 neworks ? Should be plenty to > > allow early adopters to play with stuff. > > > > I'd love there to be the problem of "Route Table Growth" :) > > > > Me thinks we are over worrying about the issues of v4 wrt v6. > > > > > > > > > -----Original Message----- > > > From: David Conrad [mailto:david.conrad at nominum.com] > > > Sent: Monday, February 24, 2003 6:29 PM > > > To: john at chagres.net > > > Cc: ppml at arin.net > > > Subject: Re: [ppml] IPv6 Justifications > > > > > > > > > John, > > > > > > On Monday, February 24, 2003, at 03:21 PM, John M. Brown wrote: > > > > seems unlikely that we will repeat the swamp problem > since people > > > > can't even get the space to begin with. > > > > > > I thought RIPE-NCC and APNIC, with essentially the same > > > policies, have > > > allocated not insignificant amounts of space. Is this > not correct? > > > > > > Rgds, > > > -drc > > > (Speaking personally) > > > > > > > > From mury at goldengate.net Mon Feb 24 21:40:37 2003 From: mury at goldengate.net (Mury) Date: Mon, 24 Feb 2003 20:40:37 -0600 (CST) Subject: [ppml] IPv6 Justifications In-Reply-To: <390E55B947E7C848898AEBB9E507706041E34B@msmdcfs01.msmgmt.com> Message-ID: What am I missing? Doesn't my proposal address your needs? 1) It removes barriers for getting the space, whether you are an ISP or an end user. 2) It removes the costs for a reasonable period of time. 3) It guarantees a resonable length of time to not be subject to current requirements and future requirements. 4) It has defined end dates for the eased requirements and costs so we don't end up with the same problem that IPv4 has. With these revisions what other problems do you have? Thanks. Mury On Mon, 24 Feb 2003, McBurnett, Jim wrote: > Here Here... > I agree. John, I know it is too late for a policy proposal for the upcoming meeting, but should we push this out anyway? > > Jim > > > -----Original Message----- > > From: John M. Brown [mailto:john at chagres.net] > > Sent: Monday, February 24, 2003 8:44 PM > > To: ppml at arin.net > > Subject: RE: [ppml] IPv6 Justifications > > > > > > True, but the basis of RIPE-NCC and APNIC is membership. > > Pay the annual membership fee and get space. > > > > in addition those regions have more "uptake" of IPv6 > > compared to the ARIN region. > > > > This isn't about RIPE-NCC or APNIC. Its about ARIN > > and the policies as viewed from potential members, existing > > members and those that want to make use of IPv6 space. > > > > We are arguing over different points, when the basic point > > is that. > > > > ARIN REGION Members feel the policy for getting IPv6 space > > is preventing them from doing so. > > > > ARIN REGION internet users (non-members and members) are interested > > in becoming early adopters of IPv6 services and technoloiges, > > yet the policy prevents these people from getting the integers > > they need. > > > > If we want to see IPv6 start moving, we have to allow people > > to get the space, use the space, make requests to the backbone > > providers that they want native transport, etc. > > > > > > Why not allow early adopters, reguardless to if they have ARIN > > alloc'd v4 space or not, to easily, cheaply get a /35, heck even > > a /48 would be plenty for these folks. > > > > Create an "early adopters micro-alloc" program. > > > > a /48 is what, 65535 /64 neworks ? Should be plenty to > > allow early adopters to play with stuff. > > > > I'd love there to be the problem of "Route Table Growth" :) > > > > Me thinks we are over worrying about the issues of v4 wrt v6. > > > > > > > > > -----Original Message----- > > > From: David Conrad [mailto:david.conrad at nominum.com] > > > Sent: Monday, February 24, 2003 6:29 PM > > > To: john at chagres.net > > > Cc: ppml at arin.net > > > Subject: Re: [ppml] IPv6 Justifications > > > > > > > > > John, > > > > > > On Monday, February 24, 2003, at 03:21 PM, John M. Brown wrote: > > > > seems unlikely that we will repeat the swamp problem > > > > since people can't even get the space to begin with. > > > > > > I thought RIPE-NCC and APNIC, with essentially the same > > > policies, have > > > allocated not insignificant amounts of space. Is this not correct? > > > > > > Rgds, > > > -drc > > > (Speaking personally) > > > > > > > > From william at elan.net Mon Feb 24 20:12:49 2003 From: william at elan.net (william at elan.net) Date: Mon, 24 Feb 2003 17:12:49 -0800 (PST) Subject: [ppml] FYI: Policy Revision Proposal - IPv6 In-Reply-To: Message-ID: Very good proposal and addresses the issues. I do still think that micro-allocations would be better if done by 6bone and ARIN and other RIRs should help manage such allocations for next 2-4. But that 200 assignments requirement should be waived for sure for ISPs that want to work on ipv6 deployment. Also in the past, it appears ARIN board of trustees did not like proposals that deal with fees, but since amount is not mentioned and only waiving the fees, this maybe ok. On Mon, 24 Feb 2003, Mury wrote: > > For those that were asking about the IPv6 policies here are some changes I > suggested that should be up for review... > > Mury > > ---------- Forwarded message ---------- > Date: Thu, 9 Jan 2003 16:42:14 -0600 (CST) > From: Mury > To: ppml at arin.net > Subject: Policy Revision Proposal > > > I propose the following additions to: > > http://www.arin.net/policy/ipv6_policy.html > > Regards, > > Mury > GoldenGate Internet Services > > > 5.1.1 > [under d) add: > > Other oganizations are defined as any customer of the LIR. > No distinction will be made in terms of number of IP addresses > required, even if that number is one. > > 5.8 Allocation for Early Adopters > > 5.8.1 Waiver of criteria listed in 5.1.1 (d) > > To promote the allocation of IPv6 space the requirment to make 200 > /48 assignments within two years shall be waived for anyone > requesting IPv6 space before Dec 31, 2004 or until this policy > is ammended. In the event that this policy is ammended the > existing IPv6 space holders shall not be subject to new or > waived criteria for a period of 10 years from their initial > allocation date. > > 5.8.2 Waiver of fees > > a) To promote the allocation of IPv6 space all IPv6 related fees > shall be waived until Dec 31, 2006 for anyone requesting and > receiving space before Dec 31, 2004. In the even that this > policy is ammended the existing IPv6 space holders shall > under no circumstances be subject to waived or new fees until > Dec 31, 2006. > > b) For billing purposes fees will be due according to normal > ARIN billing policies on Jan 1, 2007. All early adopters > will have the same billing date regardless of the date > they received their allocation. > > 5.8.3 Micro Allocations > > a) To promote the allocation and deployment of IPv6 all the > criteria in 5.1.1 shall be waived to those requesting a /48 > micro allocation before Dec 31, 2004, or until this policy > is changed. If this policy is changed, current space holders > shall not be subject to any new or waived criteria. > > b) All fees shall be waived under the same rules listed in > 5.8.2. > > c) Those receiving micro allocations shall not be allowed to > make further allocations or assignments out of their /48. It > is intended for their internal use only. > > d) When possible those receiving micro allocations shall > return their allocation and receive a new /48 from their > upstream provider (a LIR). This is requested in a good faith > manner until Jan 1, 2007 at which time all micro allocations > granted under these waived criteria must be returned. > > -- From david.conrad at nominum.com Tue Feb 25 01:52:22 2003 From: david.conrad at nominum.com (David Conrad) Date: Mon, 24 Feb 2003 22:52:22 -0800 Subject: [ppml] IPv6 Justifications In-Reply-To: <002f01c2dc6f$55b2b190$f9ecdfd8@laptoy> Message-ID: John, On Monday, February 24, 2003, at 05:43 PM, John M. Brown wrote: > True, but the basis of RIPE-NCC and APNIC is membership. > Pay the annual membership fee and get space. I do not believe this to be an accurate reflection of the address allocation procedures of either APNIC or RIPE-NCC. > in addition those regions have more "uptake" of IPv6 > compared to the ARIN region. Given you agree the policies are similar, one might ask why the disparity. > ARIN REGION Members feel the policy for getting IPv6 space > is preventing them from doing so. ARIN REGION Members approved the current policies. If they wish to change those policies, the mechanisms to do so are well documented. There is no conspiracy here (at least any that I'm a party to :-)). > If we want to see IPv6 start moving, we have to allow people > to get the space, use the space, Given the addressing and routing architecture of IPv6, I will admit some concerns about topological leaf node sites getting address space that would need to appear in the IPv6 default free zone. However, perhaps that is just me. > make requests to the backbone > providers that they want native transport, etc. I wasn't aware ARIN policies prohibited people from requesting native v6 transport. > Why not allow early adopters, reguardless to if they have ARIN > alloc'd v4 space or not, to easily, cheaply get a /35, heck even > a /48 would be plenty for these folks. > > Create an "early adopters micro-alloc" program. Feel free to propose such policies. There is time before the next meeting, I believe (ARIN staff will correct me if I am wrong). > I'd love there to be the problem of "Route Table Growth" :) > Me thinks we are over worrying about the issues of v4 wrt v6. Given v6 uses the EXACT SAME routing technology as v4, doesn't this concern make a small bit of sense? Rgds, -drc (speaking personally) From Michael.Dillon at radianz.com Tue Feb 25 05:58:18 2003 From: Michael.Dillon at radianz.com (Michael.Dillon at radianz.com) Date: Tue, 25 Feb 2003 10:58:18 +0000 Subject: [ppml] IPv6 Justifications Message-ID: >> Would someone please explain to me why in gods name ARIN thinks they >> need >> to continue the IP justification anal-probes into v6? >Swamp (or repeating history) avoidance? Having some swamp is a good thing. In fact, today we don't have enough swamp and really should be looking at an orderly expansion of it in IPv4. When the swamp originally came about, it was bad because it stressed the limits of ancient IPv4 technology. But today, in comparison with the early 90's, we have cheap and plentiful RAM and we have plenty of spare CPU power. For IPv6, I support a looser policy for early adopters. Let's pick a magic number of IPv6 blocks and use that as the end of the early adopter era. For instance, if we believe that having 4,000 IPv6 blocks allocated in North America represents the end of the early adopter era, then let's have a looser policy for v6 allocations that is in effect until that magic number of allocations is done. This is one way in which we can avoid an uncontrolled swamp like we had with v4. Second suggestion for swamp avoidance. For all IPv6 allocations the organization must maintain up-to-date contact information with ARIN. If they fall out of contact for 6 months, the allocation is revoked and will be re-issued to someone else. As for my comment about needing more swamp in v4, I believe that we need a policy that allows ARIN to allocate blocks as small as /24 out of an identifiable aggregate that is know to be used only for small allocations. As part of this change, ARIN should apply to IANA for an allocation from the swamp space to be used for these small allocations. Of course, these allocations would still be subject to the multihoming requirement. The intention is not that these allocations should make it easier for ISPs to get initial PI space but that it should make it easier for organizations with static long-term IP requirements to get PI space. ISPs are still a special beast because their IP requirements grow continually and if we did allow them to get a small swamp block then we would need strict rules to renumber out of that space after they grow out of a /24. P.S. To anyone thinking about ARIN policy. Please don't try and make policy to solve a problem that you see today. Policies are not a tool for quick fixes. They are a way of creating a long-term environment. Because of this, you need to consider the general situation as well as the specific. And you need to think about what will happen years from now as well as today. IPv4 policies in particular need to reflect the fact that the IPv6 Internet is here today and therefore IPv4 no longer needs to be the solution to every problem. Some problems, such as address space exhaustion, are best solved by pushing them onto IPv6. --Michael Dillon From ron at aol.net Tue Feb 25 09:10:43 2003 From: ron at aol.net (Ron da Silva) Date: Tue, 25 Feb 2003 09:10:43 -0500 Subject: [ppml] FYI: Policy Revision Proposal - IPv6 In-Reply-To: References: Message-ID: <20030225141043.GP27891@aol.net> On Mon, Feb 24, 2003 at 05:12:49PM -0800, william at elan.net wrote: > > Also in the past, it appears ARIN board of trustees did not like proposals > that deal with fees, but since amount is not mentioned and only waiving > the fees, this maybe ok. In general, a policy that recommends certain special fee considerations (such as waivers, discounts, extra fees) to impact the policy itself are fine. The actual values though need to be determined by ARIN based on their operations costs, etc and thus should not be specified. -ron From John.Sweeting at teleglobe.com Tue Feb 25 09:16:01 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Tue, 25 Feb 2003 09:16:01 -0500 Subject: [ppml] IPv6 Justifications Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BE8F@usresms03.teleglobe.com> John, There is already a proposal from Mury that addresses most of these issues surrounding the IPv6 policy. It might make sense to review those and use them as a starting point if you feel additional requirements should be waived or implemented. Thanks. http://www.arin.net/policy/ipv6_policy.html -----Original Message----- From: John M. Brown [mailto:john at chagres.net] Sent: Monday, February 24, 2003 9:11 PM To: ppml at arin.net Subject: RE: [ppml] IPv6 Justifications Don't see why its to late to submit a draft policy for the upcoming meeting. Bylaws say 30 days. Meeting is Monday 7-April. Seems like we have at least till 28-Feb, to get stuff to Richard, who could then get it posted by the 6-Mar time to be in agreement with the By-laws. Anyone what to work with me on making changes to the existing policy and submitting that to ARIN ?? Note: Don't signup unless you intend to work quick and hard :) john brown > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of McBurnett, Jim > Sent: Monday, February 24, 2003 7:00 PM > To: ppml at arin.net > Subject: RE: [ppml] IPv6 Justifications > > > Here Here... > I agree. John, I know it is too late for a policy proposal > for the upcoming meeting, but should we push this out anyway? > > Jim > > > -----Original Message----- > > From: John M. Brown [mailto:john at chagres.net] > > Sent: Monday, February 24, 2003 8:44 PM > > To: ppml at arin.net > > Subject: RE: [ppml] IPv6 Justifications > > > > > > True, but the basis of RIPE-NCC and APNIC is membership. > > Pay the annual membership fee and get space. > > > > in addition those regions have more "uptake" of IPv6 > > compared to the ARIN region. > > > > This isn't about RIPE-NCC or APNIC. Its about ARIN > > and the policies as viewed from potential members, existing members > > and those that want to make use of IPv6 space. > > > > We are arguing over different points, when the basic point > > is that. > > > > ARIN REGION Members feel the policy for getting IPv6 space > > is preventing them from doing so. > > > > ARIN REGION internet users (non-members and members) are > interested in > > becoming early adopters of IPv6 services and technoloiges, yet the > > policy prevents these people from getting the integers they need. > > > > If we want to see IPv6 start moving, we have to allow people to get > > the space, use the space, make requests to the backbone > providers that > > they want native transport, etc. > > > > > > Why not allow early adopters, reguardless to if they have > ARIN alloc'd > > v4 space or not, to easily, cheaply get a /35, heck even a > /48 would > > be plenty for these folks. > > > > Create an "early adopters micro-alloc" program. > > > > a /48 is what, 65535 /64 neworks ? Should be plenty to > > allow early adopters to play with stuff. > > > > I'd love there to be the problem of "Route Table Growth" :) > > > > Me thinks we are over worrying about the issues of v4 wrt v6. > > > > > > > > > -----Original Message----- > > > From: David Conrad [mailto:david.conrad at nominum.com] > > > Sent: Monday, February 24, 2003 6:29 PM > > > To: john at chagres.net > > > Cc: ppml at arin.net > > > Subject: Re: [ppml] IPv6 Justifications > > > > > > > > > John, > > > > > > On Monday, February 24, 2003, at 03:21 PM, John M. Brown wrote: > > > > seems unlikely that we will repeat the swamp problem > since people > > > > can't even get the space to begin with. > > > > > > I thought RIPE-NCC and APNIC, with essentially the same > > > policies, have > > > allocated not insignificant amounts of space. Is this > not correct? > > > > > > Rgds, > > > -drc > > > (Speaking personally) > > > > > > > > From John.Sweeting at teleglobe.com Tue Feb 25 09:17:38 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Tue, 25 Feb 2003 09:17:38 -0500 Subject: [ppml] IPv6 Justifications Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BE90@usresms03.teleglobe.com> Sorry, the following was left off: (these are Mury's proposed changes and they have been officially received by ARIN) 5.1.1 [under d) add: Other oganizations are defined as any customer of the LIR. No distinction will be made in terms of number of IP addresses required, even if that number is one. 5.8 Allocation for Early Adopters 5.8.1 Waiver of criteria listed in 5.1.1 (d) To promote the allocation of IPv6 space the requirment to make 200 /48 assignments within two years shall be waived for anyone requesting IPv6 space before Dec 31, 2004 or until this policy is ammended. In the event that this policy is ammended the existing IPv6 space holders shall not be subject to new or waived criteria for a period of 10 years from their initial allocation date. 5.8.2 Waiver of fees a) To promote the allocation of IPv6 space all IPv6 related fees shall be waived until Dec 31, 2006 for anyone requesting and receiving space before Dec 31, 2004. In the even that this policy is ammended the existing IPv6 space holders shall under no circumstances be subject to waived or new fees until Dec 31, 2006. b) For billing purposes fees will be due according to normal ARIN billing policies on Jan 1, 2007. All early adopters will have the same billing date regardless of the date they received their allocation. 5.8.3 Micro Allocations a) To promote the allocation and deployment of IPv6 all the criteria in 5.1.1 shall be waived to those requesting a /48 micro allocation before Dec 31, 2004, or until this policy is changed. If this policy is changed, current space holders shall not be subject to any new or waived criteria. b) All fees shall be waived under the same rules listed in 5.8.2. c) Those receiving micro allocations shall not be allowed to make further allocations or assignments out of their /48. It is intended for their internal use only. d) When possible those receiving micro allocations shall return their allocation and receive a new /48 from their upstream provider (a LIR). This is requested in a good faith manner until Jan 1, 2007 at which time all micro allocations granted under these waived criteria must be returned. -----Original Message----- From: Sweeting, John Sent: Tuesday, February 25, 2003 9:16 AM To: ppml at arin.net Subject: RE: [ppml] IPv6 Justifications John, There is already a proposal from Mury that addresses most of these issues surrounding the IPv6 policy. It might make sense to review those and use them as a starting point if you feel additional requirements should be waived or implemented. Thanks. http://www.arin.net/policy/ipv6_policy.html -----Original Message----- From: John M. Brown [mailto:john at chagres.net] Sent: Monday, February 24, 2003 9:11 PM To: ppml at arin.net Subject: RE: [ppml] IPv6 Justifications Don't see why its to late to submit a draft policy for the upcoming meeting. Bylaws say 30 days. Meeting is Monday 7-April. Seems like we have at least till 28-Feb, to get stuff to Richard, who could then get it posted by the 6-Mar time to be in agreement with the By-laws. Anyone what to work with me on making changes to the existing policy and submitting that to ARIN ?? Note: Don't signup unless you intend to work quick and hard :) john brown > -----Original Message----- > From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On > Behalf Of McBurnett, Jim > Sent: Monday, February 24, 2003 7:00 PM > To: ppml at arin.net > Subject: RE: [ppml] IPv6 Justifications > > > Here Here... > I agree. John, I know it is too late for a policy proposal > for the upcoming meeting, but should we push this out anyway? > > Jim > > > -----Original Message----- > > From: John M. Brown [mailto:john at chagres.net] > > Sent: Monday, February 24, 2003 8:44 PM > > To: ppml at arin.net > > Subject: RE: [ppml] IPv6 Justifications > > > > > > True, but the basis of RIPE-NCC and APNIC is membership. > > Pay the annual membership fee and get space. > > > > in addition those regions have more "uptake" of IPv6 > > compared to the ARIN region. > > > > This isn't about RIPE-NCC or APNIC. Its about ARIN > > and the policies as viewed from potential members, existing members > > and those that want to make use of IPv6 space. > > > > We are arguing over different points, when the basic point > > is that. > > > > ARIN REGION Members feel the policy for getting IPv6 space > > is preventing them from doing so. > > > > ARIN REGION internet users (non-members and members) are > interested in > > becoming early adopters of IPv6 services and technoloiges, yet the > > policy prevents these people from getting the integers they need. > > > > If we want to see IPv6 start moving, we have to allow people to get > > the space, use the space, make requests to the backbone > providers that > > they want native transport, etc. > > > > > > Why not allow early adopters, reguardless to if they have > ARIN alloc'd > > v4 space or not, to easily, cheaply get a /35, heck even a > /48 would > > be plenty for these folks. > > > > Create an "early adopters micro-alloc" program. > > > > a /48 is what, 65535 /64 neworks ? Should be plenty to > > allow early adopters to play with stuff. > > > > I'd love there to be the problem of "Route Table Growth" :) > > > > Me thinks we are over worrying about the issues of v4 wrt v6. > > > > > > > > > -----Original Message----- > > > From: David Conrad [mailto:david.conrad at nominum.com] > > > Sent: Monday, February 24, 2003 6:29 PM > > > To: john at chagres.net > > > Cc: ppml at arin.net > > > Subject: Re: [ppml] IPv6 Justifications > > > > > > > > > John, > > > > > > On Monday, February 24, 2003, at 03:21 PM, John M. Brown wrote: > > > > seems unlikely that we will repeat the swamp problem > since people > > > > can't even get the space to begin with. > > > > > > I thought RIPE-NCC and APNIC, with essentially the same > > > policies, have > > > allocated not insignificant amounts of space. Is this > not correct? > > > > > > Rgds, > > > -drc > > > (Speaking personally) > > > > > > > > From william at elan.net Wed Feb 26 13:47:37 2003 From: william at elan.net (william at elan.net) Date: Wed, 26 Feb 2003 10:47:37 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: Message-ID: I'v made a 2nd draft for proposal for ip micro-assignment with sponsorship. It does not format well to be posted in the email as text but you can review it online at: http://www.elan.net/~william/arin_proposal_for_micro_assignments_with_sponsorship.htm If you have any futher suggestions please feel free to email me or otherwise discuss it on this list. If there are no suggestions for addition to the current text, this will be the proposal I will send to Richard Jimmerson end of this week. ---- William Leibzon Elan Communications william at elan.net From forrest at almighty.c64.org Wed Feb 26 19:00:17 2003 From: forrest at almighty.c64.org (Forrest) Date: Wed, 26 Feb 2003 18:00:17 -0600 (CST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: Message-ID: I think some sort of language saying that ARIN will do audits of the assignments from time to time is needed. Or perhaps when you pay your annual renewal fee, you should have to provide proof along with it that you are still connected to more than 1 upstream. Basically something that will prevent someone from being multihomed today, get a micro assignment, and then drop their second provider while keeping their micro assignment. Forrest On Wed, 26 Feb 2003 william at elan.net wrote: > > I'v made a 2nd draft for proposal for ip micro-assignment with sponsorship. > It does not format well to be posted in the email as text but you can > review it online at: > > http://www.elan.net/~william/arin_proposal_for_micro_assignments_with_sponsorship.htm > > If you have any futher suggestions please feel free to email me or otherwise > discuss it on this list. If there are no suggestions for addition to the > current text, this will be the proposal I will send to Richard Jimmerson > end of this week. > > ---- > William Leibzon > Elan Communications > william at elan.net > From jmcburnett at msmgmt.com Wed Feb 26 20:33:29 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Wed, 26 Feb 2003 20:33:29 -0500 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship Message-ID: <390E55B947E7C848898AEBB9E507706041E36D@msmdcfs01.msmgmt.com> I would rather not see this language. The policy states that ISP A or ISP B must inform ARIN when this happens. I know we can't depend on this to work, but if we build in a backup, why even ask ISP A or ISP B to inform ARIN of this change? Jim > > I think some sort of language saying that ARIN will do audits of the > assignments from time to time is needed. Or perhaps when you > pay your > annual renewal fee, you should have to provide proof along > with it that > you are still connected to more than 1 upstream. Basically > something that > will prevent someone from being multihomed today, get a micro > assignment, > and then drop their second provider while keeping their micro > assignment. > > Forrest > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > with sponsorship. > > It does not format well to be posted in the email as text > but you can > > review it online at: > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > ts_with_sponsorship.htm > > > > If you have any futher suggestions please feel free to > email me or otherwise > > discuss it on this list. If there are no suggestions for > addition to the > > current text, this will be the proposal I will send to > Richard Jimmerson > > end of this week. > > > > ---- > > William Leibzon > > Elan Communications > > william at elan.net > > > > > > > From forrest at almighty.c64.org Thu Feb 27 00:26:06 2003 From: forrest at almighty.c64.org (Forrest) Date: Wed, 26 Feb 2003 23:26:06 -0600 (CST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <390E55B947E7C848898AEBB9E507706041E36D@msmdcfs01.msmgmt.com> Message-ID: I think ARIN doing audits on the space periodically and/or doing checks when you pay your renewal fee would be a lot more reliable than hoping that an upstream would notify ARIN if you ceased being their customer. There are providers out there whose billing systems are so screwed up that they'll continue billing you for services long after you've stopped using them. Yet they will somehow magically notify ARIN that you're no longer a customer even when they're own billing department doesn't get the message? As sad as it is to say, I just don't think you can rely on everyone to be good netizens, so ARIN needs to be more proactive. If everyone was, you wouldn't have problems like people announcing a bunch of unnecessary /24's instead of their larger aggregate or people still filtering 69.0.0.0/8 etc... Forrest On Wed, 26 Feb 2003, McBurnett, Jim wrote: > > I would rather not see this language. The policy states that ISP A or ISP B must inform ARIN > when this happens. I know we can't depend on this to work, but if we build in a backup, why even > ask ISP A or ISP B to inform ARIN of this change? > > Jim > > > > I think some sort of language saying that ARIN will do audits of the > > assignments from time to time is needed. Or perhaps when you > > pay your > > annual renewal fee, you should have to provide proof along > > with it that > > you are still connected to more than 1 upstream. Basically > > something that > > will prevent someone from being multihomed today, get a micro > > assignment, > > and then drop their second provider while keeping their micro > > assignment. > > > > Forrest > > From william at elan.net Thu Feb 27 07:29:26 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 04:29:26 -0800 (PST) Subject: [ppml] draft for another proposal In-Reply-To: <390E55B947E7C848898AEBB9E507706041E36D@msmdcfs01.msmgmt.com> Message-ID: I'm trying to make a draft for another proposal which I have actually mentioned even several months ago. This is to specify how ARIN assigns new ip blocks as to make sure all micro allocations and assignments are in the /8 specifically known to have these small assignments and this is needed for proposals 2002-5, 2002-6, 2002-7 as well as any other proposals for micro-assignments and it seems unnecessary waste of space if same statement as already exist on 2001-3 had to be added into each proposal, easier to just make it a global policy. In addition to that new part is trying to deal with how ARIN makes new IANA assignments known. In part this is due to many complaints many have seen (especially on nanog) regarding 69.0.0.0/8 block and how some ISPs have not updated filters in time even now, those receiving allocations from this block are having problems! I'm not sure how to even call this proposal yet, so feel free to make a suggestins on the name, if its needed at all, if its better be devided into several proposals and on the text itself (which I'm not too happy with actually). Here is the text I have so far as draft of this proposal: ------------------------------------------------------------------------ ARIN should make an effort to allocate and assign ip blocks to ISP subscribers and end-users so that customers with allocations of the same size (such as micro-allocations, small, middle, large ip blocks) receive assignments from the same class-A block as much as possible. In all cases of allocations and assignments smaller then current minimum allocation size for ISP subscriber members, these allocations and assignments should be made from CLASS-A block specifically reserved for micro-allocations and assignments. ARIN should request new CLASS-A blocks from IANA at least 6 months in advance of expected first allocation or assignment. After IANA has made an assignment ARIN should provide information regarding new ip block and expected minimum allocations and assignments to be made out of this ip block on network engineering mailing lists as well as send email to techical contacts for all ISP subscriber members and end-users regarding this new IANA assigned block. An additional announcement should be made one month or less prior to first assignment or allocation and if complaints are received by ARIN regarding routability problems with new ip block, ARIN may make additional announcements on mailing lists as needed and all complains received by ARIN regarding operational issues with new ip allocations should also be forwarded to proper regional mailing list such as NANOG. When changes are made in the future regarding minimum allocation or assignments from any CLASS-A block, additional announcement must also be made at least 30 days prior to first smaller assignment or allocation. ARIN should also conduct one-time audit and afterdards provide updated information on its website regarding smallest size blocks it has allocated or assigned for each CLASS-A block ARIN has received from IANA. ------------------------------------------------------------------------- One last note - I'm not sure if this can actually be a policy as it regulates how ARIN operates and makes assignments rather then how members or end-users deal with ARIN. From william at elan.net Thu Feb 27 07:44:13 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 04:44:13 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: Message-ID: If the company keeps billing many months after, what makes you think they would not just answer yes when asked by ARIN if they still sponsor particular assignment? I'm not really against audits, but I do not think they will seriously change how ISP operate and I think this should be more of something ARIN can do on its own without it necessarily being in the policy itself. This is really part of a more general problem which I mentioned in comments of draft1 - in the draft while 1/4 of it talks about what ISPs should do as sponsors there are absolutly no consecunces for them not doing their sponsoring duties. I really do not see how to easily deal with it other then to mention that ISPs that are known not do as they are supposed as sponsors may not be accepted by ARIN as sponsors for other assignments, but I did not think this phrase would necessarily change anything either. > I think ARIN doing audits on the space periodically and/or doing checks > when you pay your renewal fee would be a lot more reliable than hoping > that an upstream would notify ARIN if you ceased being their customer. > There are providers out there whose billing systems are so screwed up > that they'll continue billing you for services long after you've stopped > using them. Yet they will somehow magically notify ARIN that you're no > longer a customer even when they're own billing department doesn't get > the message? > > As sad as it is to say, I just don't think you can rely on everyone to be > good netizens, so ARIN needs to be more proactive. If everyone was, you > wouldn't have problems like people announcing a bunch of unnecessary /24's > instead of their larger aggregate or people still filtering 69.0.0.0/8 > etc... > > Forrest > > On Wed, 26 Feb 2003, McBurnett, Jim wrote: > > > > > I would rather not see this language. The policy states that ISP A or ISP B must inform ARIN > > when this happens. I know we can't depend on this to work, but if we build in a backup, why even > > ask ISP A or ISP B to inform ARIN of this change? > > > > Jim > > > > > > I think some sort of language saying that ARIN will do audits of the > > > assignments from time to time is needed. Or perhaps when you > > > pay your > > > annual renewal fee, you should have to provide proof along > > > with it that > > > you are still connected to more than 1 upstream. Basically > > > something that > > > will prevent someone from being multihomed today, get a micro > > > assignment, > > > and then drop their second provider while keeping their micro > > > assignment. > > > > > > Forrest > > > From marla_azinger at eli.net Thu Feb 27 11:44:54 2003 From: marla_azinger at eli.net (Marla Azinger) Date: Thu, 27 Feb 2003 08:44:54 -0800 Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship Message-ID: <000701c2de7f$8e4a1db0$770d1bac@eli.czn.com> Hello- I know I've missed alot of the discussion between the last conference and up to this point...so please bear with me and the question I have... Why is it necessary for an ISP to "sponsor" this? So far...sponsorship sounds like more of a headache than anything...I'm sure I'm missing something because up to this point...I would just say my company isnt going to participate in order to avoid...basically...all of it...we'v done fine without this until now... I guess what I'm missing here is...how is a smaller telecom company that provides internet access supposed to benefit from "sponsoring" this? Is there a benefit...or is this a bandaid for integrity issues? I'm sure there's a good list of reasons I'm missing...like I said I've missed most of the discussion up to this point...but could someone provide a short and to the point list of how we'd benefit from "sponsoring" this? Thank you for your patience and time Marla ELI IP Analyst I would rather not see this language. The policy states that ISP A or ISP B must inform ARIN when this happens. I know we can't depend on this to work, but if we build in a backup, why even ask ISP A or ISP B to inform ARIN of this change? Jim > > I think some sort of language saying that ARIN will do audits of the > assignments from time to time is needed. Or perhaps when you > pay your > annual renewal fee, you should have to provide proof along > with it that > you are still connected to more than 1 upstream. Basically > something that > will prevent someone from being multihomed today, get a micro > assignment, > and then drop their second provider while keeping their micro > assignment. > > Forrest > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > with sponsorship. > > It does not format well to be posted in the email as text > but you can > > review it online at: > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > ts_with_sponsorship.htm > > > > If you have any futher suggestions please feel free to > email me or otherwise > > discuss it on this list. If there are no suggestions for > addition to the > > current text, this will be the proposal I will send to > Richard Jimmerson > > end of this week. > > > > ---- > > William Leibzon > > Elan Communications > > william at elan.net > > > > > > > From mury at goldengate.net Thu Feb 27 12:35:47 2003 From: mury at goldengate.net (Mury) Date: Thu, 27 Feb 2003 11:35:47 -0600 (CST) Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <000701c2de7f$8e4a1db0$770d1bac@eli.czn.com> Message-ID: I've missed most of this discussion too, but it sure seems like it leaves a lot open for abuse, confusion, mistakes, etc. Why can't ARIN check to make sure they have 2 upstreams by asking for contracts and bills the first time around, and at renewal time check some of the backbone routers to make sure their AS is being announced by two providers. There are gobs of places that ARIN could check this from that would take 1 minute to do. If for some reason it doesn't show up in the routing tables, then the ISP could provide bills. If they can't provide bills proving they have two upstreams, yank the IPs. Part of me is also against the /24 allocation in the first place. I know what it feels like, since I was a little irked when I couldn't get space when we started out. But in the end it wasn't the end of the world. Renumbering out of a /24 isn't a life ending task. Sure, it sucks, and everyone would rather not do it, but hey almost all of us have had to deal with it and we all made it okay. If you are multi-homed you need to contact your upstreams to announce the block anyway so it doesn't provide any benefit there. Sorry to all those who disagree, it's just my two cents. Mury On Thu, 27 Feb 2003, Marla Azinger wrote: > Hello- I know I've missed alot of the discussion between the last > conference and up to this point...so please bear with me and the question I > have... > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > sounds like more of a headache than anything...I'm sure I'm missing > something because up to this point...I would just say my company isnt going > to participate in order to avoid...basically...all of it...we'v done fine > without this until now... > > I guess what I'm missing here is...how is a smaller telecom company that > provides internet access supposed to benefit from "sponsoring" this? Is > there a benefit...or is this a bandaid for integrity issues? I'm sure > there's a good list of reasons I'm missing...like I said I've missed most of > the discussion up to this point...but could someone provide a short and to > the point list of how we'd benefit from "sponsoring" this? > > Thank you for your patience and time > Marla > ELI IP Analyst > > > > > I would rather not see this language. The policy states that ISP A or ISP B > must inform ARIN > when this happens. I know we can't depend on this to work, but if we build > in a backup, why even > ask ISP A or ISP B to inform ARIN of this change? > > Jim > > > > I think some sort of language saying that ARIN will do audits of the > > assignments from time to time is needed. Or perhaps when you > > pay your > > annual renewal fee, you should have to provide proof along > > with it that > > you are still connected to more than 1 upstream. Basically > > something that > > will prevent someone from being multihomed today, get a micro > > assignment, > > and then drop their second provider while keeping their micro > > assignment. > > > > Forrest > > > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > > with sponsorship. > > > It does not format well to be posted in the email as text > > but you can > > > review it online at: > > > > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > > ts_with_sponsorship.htm > > > > > > If you have any futher suggestions please feel free to > > email me or otherwise > > > discuss it on this list. If there are no suggestions for > > addition to the > > > current text, this will be the proposal I will send to > > Richard Jimmerson > > > end of this week. > > > > > > ---- > > > William Leibzon > > > Elan Communications > > > william at elan.net > > > > > > > > > > > > > > From Stacy_Taylor at icgcomm.com Thu Feb 27 12:58:56 2003 From: Stacy_Taylor at icgcomm.com (Taylor, Stacy) Date: Thu, 27 Feb 2003 10:58:56 -0700 Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment w ith sponsorship Message-ID: <5BDB545714D0764F8452CC5A25DDEEFA04DADDD6@denexg21.icgcomm.com> Hi All, Speaking for the Office of IP Management for ICG only, I wonder why I would have to do more templates when multihoming information from two ISPs is required on the ASN request template. Is my ASN not already in fact "sponsoring" the multihomer by including my information on the record/request? If the ASN registrant changes one or both of its ISPs, it is for the registrant to update their ARIN record, not the upstreams. If we are to recommend a microallocation policy, I would like to see it linked to the ASN process, since you shouldn't have one without the other. Stacy -----Original Message----- From: Mury [mailto:mury at goldengate.net] Sent: Thursday, February 27, 2003 9:36 AM To: Marla Azinger Cc: ppml at arin.net Subject: Re: [ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship I've missed most of this discussion too, but it sure seems like it leaves a lot open for abuse, confusion, mistakes, etc. Why can't ARIN check to make sure they have 2 upstreams by asking for contracts and bills the first time around, and at renewal time check some of the backbone routers to make sure their AS is being announced by two providers. There are gobs of places that ARIN could check this from that would take 1 minute to do. If for some reason it doesn't show up in the routing tables, then the ISP could provide bills. If they can't provide bills proving they have two upstreams, yank the IPs. Part of me is also against the /24 allocation in the first place. I know what it feels like, since I was a little irked when I couldn't get space when we started out. But in the end it wasn't the end of the world. Renumbering out of a /24 isn't a life ending task. Sure, it sucks, and everyone would rather not do it, but hey almost all of us have had to deal with it and we all made it okay. If you are multi-homed you need to contact your upstreams to announce the block anyway so it doesn't provide any benefit there. Sorry to all those who disagree, it's just my two cents. Mury On Thu, 27 Feb 2003, Marla Azinger wrote: > Hello- I know I've missed alot of the discussion between the last > conference and up to this point...so please bear with me and the question I > have... > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > sounds like more of a headache than anything...I'm sure I'm missing > something because up to this point...I would just say my company isnt going > to participate in order to avoid...basically...all of it...we'v done fine > without this until now... > > I guess what I'm missing here is...how is a smaller telecom company that > provides internet access supposed to benefit from "sponsoring" this? Is > there a benefit...or is this a bandaid for integrity issues? I'm sure > there's a good list of reasons I'm missing...like I said I've missed most of > the discussion up to this point...but could someone provide a short and to > the point list of how we'd benefit from "sponsoring" this? > > Thank you for your patience and time > Marla > ELI IP Analyst > > > > > I would rather not see this language. The policy states that ISP A or ISP B > must inform ARIN > when this happens. I know we can't depend on this to work, but if we build > in a backup, why even > ask ISP A or ISP B to inform ARIN of this change? > > Jim > > > > I think some sort of language saying that ARIN will do audits of the > > assignments from time to time is needed. Or perhaps when you > > pay your > > annual renewal fee, you should have to provide proof along > > with it that > > you are still connected to more than 1 upstream. Basically > > something that > > will prevent someone from being multihomed today, get a micro > > assignment, > > and then drop their second provider while keeping their micro > > assignment. > > > > Forrest > > > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > > with sponsorship. > > > It does not format well to be posted in the email as text > > but you can > > > review it online at: > > > > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > > ts_with_sponsorship.htm > > > > > > If you have any futher suggestions please feel free to > > email me or otherwise > > > discuss it on this list. If there are no suggestions for > > addition to the > > > current text, this will be the proposal I will send to > > Richard Jimmerson > > > end of this week. > > > > > > ---- > > > William Leibzon > > > Elan Communications > > > william at elan.net > > > > > > > > > > > > > > From ebohlin at UU.NET Thu Feb 27 14:00:28 2003 From: ebohlin at UU.NET (Einar Bohlin) Date: Thu, 27 Feb 2003 14:00:28 -0500 (EST) Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment w ith sponsorship In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA04DADDD6@denexg21.icgcomm.com> Message-ID: > If we are to recommend a microallocation policy, I would like to see it > linked to the ASN process, since you shouldn't have one without the other. Everybody who registers an ASN ultimately wants their own net. An ASN and a net should be a simple ARIN bundled service. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - WorldCom Phone: 703 886-7362 (VNET 806-7362) email: einar.bohlin at wcom.com On Thu, 27 Feb 2003, Taylor, Stacy wrote: > Hi All, > Speaking for the Office of IP Management for ICG only, I wonder why I would > have to do more templates when multihoming information from two ISPs is > required on the ASN request template. Is my ASN not already in fact > "sponsoring" the multihomer by including my information on the > record/request? > > If the ASN registrant changes one or both of its ISPs, it is for the > registrant to update their ARIN record, not the upstreams. > > If we are to recommend a microallocation policy, I would like to see it > linked to the ASN process, since you shouldn't have one without the other. > > Stacy > > -----Original Message----- > From: Mury [mailto:mury at goldengate.net] > Sent: Thursday, February 27, 2003 9:36 AM > To: Marla Azinger > Cc: ppml at arin.net > Subject: Re: [ppml] Question RE: Draft 2 of proposal for ip assignment > with sponsorship > > > > I've missed most of this discussion too, but it sure seems like it leaves > a lot open for abuse, confusion, mistakes, etc. > > Why can't ARIN check to make sure they have 2 upstreams by asking for > contracts and bills the first time around, and at renewal time check some > of the backbone routers to make sure their AS is being announced by two > providers. There are gobs of places that ARIN could check this from that > would take 1 minute to do. If for some reason it doesn't show up in the > routing tables, then the ISP could provide bills. If they can't provide > bills proving they have two upstreams, yank the IPs. > > Part of me is also against the /24 allocation in the first place. I know > what it feels like, since I was a little irked when I couldn't get space > when we started out. But in the end it wasn't the end of the world. > Renumbering out of a /24 isn't a life ending task. Sure, it sucks, and > everyone would rather not do it, but hey almost all of us have had to deal > with it and we all made it okay. > > If you are multi-homed you need to contact your upstreams to announce the > block anyway so it doesn't provide any benefit there. > > Sorry to all those who disagree, it's just my two cents. > > Mury > > > On Thu, 27 Feb 2003, Marla Azinger wrote: > > > Hello- I know I've missed alot of the discussion between the last > > conference and up to this point...so please bear with me and the question > I > > have... > > > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > > sounds like more of a headache than anything...I'm sure I'm missing > > something because up to this point...I would just say my company isnt > going > > to participate in order to avoid...basically...all of it...we'v done fine > > without this until now... > > > > I guess what I'm missing here is...how is a smaller telecom company that > > provides internet access supposed to benefit from "sponsoring" this? Is > > there a benefit...or is this a bandaid for integrity issues? I'm sure > > there's a good list of reasons I'm missing...like I said I've missed most > of > > the discussion up to this point...but could someone provide a short and to > > the point list of how we'd benefit from "sponsoring" this? > > > > Thank you for your patience and time > > Marla > > ELI IP Analyst > > > > > > > > > > I would rather not see this language. The policy states that ISP A or ISP > B > > must inform ARIN > > when this happens. I know we can't depend on this to work, but if we build > > in a backup, why even > > ask ISP A or ISP B to inform ARIN of this change? > > > > Jim > > > > > > I think some sort of language saying that ARIN will do audits of the > > > assignments from time to time is needed. Or perhaps when you > > > pay your > > > annual renewal fee, you should have to provide proof along > > > with it that > > > you are still connected to more than 1 upstream. Basically > > > something that > > > will prevent someone from being multihomed today, get a micro > > > assignment, > > > and then drop their second provider while keeping their micro > > > assignment. > > > > > > Forrest > > > > > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > > > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > > > with sponsorship. > > > > It does not format well to be posted in the email as text > > > but you can > > > > review it online at: > > > > > > > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > > > ts_with_sponsorship.htm > > > > > > > > If you have any futher suggestions please feel free to > > > email me or otherwise > > > > discuss it on this list. If there are no suggestions for > > > addition to the > > > > current text, this will be the proposal I will send to > > > Richard Jimmerson > > > > end of this week. > > > > > > > > ---- > > > > William Leibzon > > > > Elan Communications > > > > william at elan.net > > > > > > > > > > > > > > > > > > > > > > From william at elan.net Thu Feb 27 12:11:17 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 09:11:17 -0800 (PST) Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <000701c2de7f$8e4a1db0$770d1bac@eli.czn.com> Message-ID: It is not "necessary" for isp to sponsor and you should consider my proposal as backup/alternate approach as somebody else already working on successor to 2002-3/2002-7. The reasons for this approach is that with some companies I talked to that were against previous proposals, they were most concerned about possible abuse if small netblocks are given by ARIN and they feel that only ISP can best deal with this situation and know if they need to accept customer or not. Most of my proposals deals with how to prevent abuse and I'd venture to say I'v gone as far as can possibly be without having to put ARIN be the judge of what abuse is which is what they want to avoid. And as I said in the beginning this is "compromise" approach, it bridges gap in between some large isps, that do not want to give up their control of ip assigments and companies that want to be completely independent of them and deal only with arin on ip assignments. This still allows ISPs some control over how ips are given but allows changing of backbone providers and keeping your ip block. This may bring support of some that apposed previous proposals because but would obviously loose support of some as well. As far as your ISP choosing to participate or not to participate in sponsorship, this would be up to you, but you might loose potential or actual customers if you do not and with telecom as competitive as it is, this might make a difference. And I don't think its much of a headache, most being asked is the same ISP already does when it gets request for IP block from a customer (and I'm sure those who would refer customer to ARIN would most likely already looked at their request for ip block), /24 is already includes as automatic minimum with no justification and most other being asked is that ISPs keep good records on who their customers are which any good ISP should already anyway. Now I'm going to list additional positive points me and somebody else made about this approach in the email two weeks ago: 1. ARIN is not put in the position of having to verify multihoming, having two sponsors makes sure of that. 2. Presumably existing arin members would filter out some companies that really do not need this separate ip block and make sure and make sure that some technical requirements exist for the assignment. 3. It is still possible for company thatlgot this associative membership to move to another isp and keep the ip block, but they would need to make sure their new isp is willing to sponsor them. 4. ARIN has records on who sponsors are and in case of billing problems or if it receives reports that address or some other whois info is not kept up to date, it can ask for assistance of their sponsors to get in touch with right people. 5. In the event an org discontinues service, the ISP can notify ARIN. In the event the org does not get a new sponsor, ARIN can notify the other sponsor that the assignment is no longer valid. This should take care of the issue some have that an org could get an assignment and then stop multihoming 6. I disagree that getting small IP blocks is hampered by this. The sponsors would have to agree to announce the block and the block could be smaller then a /24 thus conserving the address pool. Since the block may not be contiguous with other blocks, there is no aggregation possible and both sponsors would be announcing the block to the world (Note: 5,6 are by Steve Rolapp, post on Feb 14th) On Thu, 27 Feb 2003, Marla Azinger wrote: > Hello- I know I've missed alot of the discussion between the last > conference and up to this point...so please bear with me and the question I > have... > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > sounds like more of a headache than anything...I'm sure I'm missing > something because up to this point...I would just say my company isnt going > to participate in order to avoid...basically...all of it...we'v done fine > without this until now... > > I guess what I'm missing here is...how is a smaller telecom company that > provides internet access supposed to benefit from "sponsoring" this? Is > there a benefit...or is this a bandaid for integrity issues? I'm sure > there's a good list of reasons I'm missing...like I said I've missed most of > the discussion up to this point...but could someone provide a short and to > the point list of how we'd benefit from "sponsoring" this? > > Thank you for your patience and time > Marla > ELI IP Analyst > > > > > I would rather not see this language. The policy states that ISP A or ISP B > must inform ARIN > when this happens. I know we can't depend on this to work, but if we build > in a backup, why even > ask ISP A or ISP B to inform ARIN of this change? > > Jim > > > > I think some sort of language saying that ARIN will do audits of the > > assignments from time to time is needed. Or perhaps when you > > pay your > > annual renewal fee, you should have to provide proof along > > with it that > > you are still connected to more than 1 upstream. Basically > > something that > > will prevent someone from being multihomed today, get a micro > > assignment, > > and then drop their second provider while keeping their micro > > assignment. > > > > Forrest > > > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > > with sponsorship. > > > It does not format well to be posted in the email as text > > but you can > > > review it online at: > > > > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > > ts_with_sponsorship.htm > > > > > > If you have any futher suggestions please feel free to > > email me or otherwise > > > discuss it on this list. If there are no suggestions for > > addition to the > > > current text, this will be the proposal I will send to > > Richard Jimmerson > > > end of this week. > > > > > > ---- > > > William Leibzon > > > Elan Communications > > > william at elan.net > > > > > > > From jmcburnett at msmgmt.com Thu Feb 27 14:13:32 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 27 Feb 2003 14:13:32 -0500 Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship Message-ID: <390E55B947E7C848898AEBB9E507706041E37B@msmdcfs01.msmgmt.com> Please see notes inline. >Why can't ARIN check to make sure they have 2 upstreams by asking for >contracts and bills the first time around, and at renewal time >check some >of the backbone routers to make sure their AS is being announced by two >providers. See note below... >There are gobs of places that ARIN could check >this from that >would take 1 minute to do. If for some reason it doesn't show >up in the >routing tables, then the ISP could provide bills. I am multi-homed and I will only show up in 1 route table- I use it for failover- not dynamic routing. Also, do you want make ARIN big Brother on this? There has to be some kind of accountability at the provider level, and to address the small ISPs: how many customers really would Multi-home with a tier 2 or Tier 3 provider? I am sorry, but I would not.... >If they >can't provide >bills proving they have two upstreams, yank the IPs. How are the going to YANK the IPs? This has been a major issue. >Part of me is also against the /24 allocation in the first >place. I know >what it feels like, since I was a little irked when I couldn't >get space >when we started out. But in the end it wasn't the end of the world. >Renumbering out of a /24 isn't a life ending task. Sure, it sucks, and >everyone would rather not do it, but hey almost all of us have >had to deal >with it and we all made it okay. Well /24 is the really only acceptable min size to announce.. I got mine, and then we decided to host all of our websites in house, after the fact. multiple servers, multiple websites, etc... I am glad we have a /24.. >If you are multi-homed you need to contact your upstreams to >announce the >block anyway so it doesn't provide any benefit there. Yeah, and if the upstream knows he is your sponsor, and he has some kind of grip on you, he won't be willing to loose you so easily... > >Sorry to all those who disagree, it's just my two cents. > >Mury Mine too... Jim From jmcburnett at msmgmt.com Thu Feb 27 14:14:57 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 27 Feb 2003 14:14:57 -0500 Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment w ith sponsorship Message-ID: <390E55B947E7C848898AEBB9E507706041E37C@msmdcfs01.msmgmt.com> here here... I agree totally.. But does that go in this policy or do we just send this as a comment to ARIN BOT? Jim > >> If we are to recommend a microallocation policy, I would >like to see it >> linked to the ASN process, since you shouldn't have one >without the other. > >Everybody who registers an ASN ultimately wants their >own net. An ASN and a net should be a simple ARIN bundled >service. > >Regards, > >Einar Bohlin, IP Analyst >IP Team - Ashburn Virginia - WorldCom >Phone: 703 886-7362 (VNET 806-7362) >email: einar.bohlin at wcom.com > > >On Thu, 27 Feb 2003, Taylor, Stacy wrote: > >> Hi All, >> Speaking for the Office of IP Management for ICG only, I >wonder why I would >> have to do more templates when multihoming information from >two ISPs is >> required on the ASN request template. Is my ASN not already in fact >> "sponsoring" the multihomer by including my information on the >> record/request? >> >> If the ASN registrant changes one or both of its ISPs, it is for the >> registrant to update their ARIN record, not the upstreams. >> >> If we are to recommend a microallocation policy, I would >like to see it >> linked to the ASN process, since you shouldn't have one >without the other. >> >> Stacy >> >> -----Original Message----- >> From: Mury [mailto:mury at goldengate.net] >> Sent: Thursday, February 27, 2003 9:36 AM >> To: Marla Azinger >> Cc: ppml at arin.net >> Subject: Re: [ppml] Question RE: Draft 2 of proposal for ip >assignment >> with sponsorship >> >> >> >> I've missed most of this discussion too, but it sure seems >like it leaves >> a lot open for abuse, confusion, mistakes, etc. >> >> Why can't ARIN check to make sure they have 2 upstreams by asking for >> contracts and bills the first time around, and at renewal >time check some >> of the backbone routers to make sure their AS is being >announced by two >> providers. There are gobs of places that ARIN could check >this from that >> would take 1 minute to do. If for some reason it doesn't >show up in the >> routing tables, then the ISP could provide bills. If they >can't provide >> bills proving they have two upstreams, yank the IPs. >> >> Part of me is also against the /24 allocation in the first >place. I know >> what it feels like, since I was a little irked when I >couldn't get space >> when we started out. But in the end it wasn't the end of the world. >> Renumbering out of a /24 isn't a life ending task. Sure, it >sucks, and >> everyone would rather not do it, but hey almost all of us >have had to deal >> with it and we all made it okay. >> >> If you are multi-homed you need to contact your upstreams to >announce the >> block anyway so it doesn't provide any benefit there. >> >> Sorry to all those who disagree, it's just my two cents. >> >> Mury >> >> >> On Thu, 27 Feb 2003, Marla Azinger wrote: >> >> > Hello- I know I've missed alot of the discussion between the last >> > conference and up to this point...so please bear with me >and the question >> I >> > have... >> > >> > Why is it necessary for an ISP to "sponsor" this? So >far...sponsorship >> > sounds like more of a headache than anything...I'm sure I'm missing >> > something because up to this point...I would just say my >company isnt >> going >> > to participate in order to avoid...basically...all of >it...we'v done fine >> > without this until now... >> > >> > I guess what I'm missing here is...how is a smaller >telecom company that >> > provides internet access supposed to benefit from >"sponsoring" this? Is >> > there a benefit...or is this a bandaid for integrity >issues? I'm sure >> > there's a good list of reasons I'm missing...like I said >I've missed most >> of >> > the discussion up to this point...but could someone >provide a short and to >> > the point list of how we'd benefit from "sponsoring" this? >> > >> > Thank you for your patience and time >> > Marla >> > ELI IP Analyst >> > >> > >> > >> > >> > I would rather not see this language. The policy states >that ISP A or ISP >> B >> > must inform ARIN >> > when this happens. I know we can't depend on this to work, >but if we build >> > in a backup, why even >> > ask ISP A or ISP B to inform ARIN of this change? >> > >> > Jim >> > > >> > > I think some sort of language saying that ARIN will do >audits of the >> > > assignments from time to time is needed. Or perhaps when you >> > > pay your >> > > annual renewal fee, you should have to provide proof along >> > > with it that >> > > you are still connected to more than 1 upstream. Basically >> > > something that >> > > will prevent someone from being multihomed today, get a micro >> > > assignment, >> > > and then drop their second provider while keeping their micro >> > > assignment. >> > > >> > > Forrest >> > > >> > > On Wed, 26 Feb 2003 william at elan.net wrote: >> > > >> > > > >> > > > I'v made a 2nd draft for proposal for ip micro-assignment >> > > with sponsorship. >> > > > It does not format well to be posted in the email as text >> > > but you can >> > > > review it online at: >> > > > >> > > > >> > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen >> > > ts_with_sponsorship.htm >> > > > >> > > > If you have any futher suggestions please feel free to >> > > email me or otherwise >> > > > discuss it on this list. If there are no suggestions for >> > > addition to the >> > > > current text, this will be the proposal I will send to >> > > Richard Jimmerson >> > > > end of this week. >> > > > >> > > > ---- >> > > > William Leibzon >> > > > Elan Communications >> > > > william at elan.net >> > > > >> > > >> > > >> > > >> > > >> > > >> > >> > > From william at elan.net Thu Feb 27 12:24:14 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 09:24:14 -0800 (PST) Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment w ith sponsorship In-Reply-To: <5BDB545714D0764F8452CC5A25DDEEFA04DADDD6@denexg21.icgcomm.com> Message-ID: I wonder how many times ARIN has contacted you to verify about templates for new ASN's your customers may have filled out when requesting ASN and listing you as contact person. Would never be a correct answer? As far as I know, ARIN does not does not really do anything when it gets ASN request, it just collects it and assigns the number. Once you get it, there is nothing requiring you to use it or be multihomed or even when using it you could only be announcing your net through one provider. In short multihoming is not really verifyied by ARIN at all. Besides that very few actually update ASN records (or at least I'v never seen anybody do it beyond listing new email address maybe). Now another approach maybe to make new policies regarding ASN assignments that would mirror what I listed and require upstreams to actually verify their downstream ASN requests as well as some way to make sure all those listed ASN's are actually used and are not just requested just to get an ip block. On Thu, 27 Feb 2003, Taylor, Stacy wrote: > Hi All, > Speaking for the Office of IP Management for ICG only, I wonder why I would > have to do more templates when multihoming information from two ISPs is > required on the ASN request template. Is my ASN not already in fact > "sponsoring" the multihomer by including my information on the > record/request? > > If the ASN registrant changes one or both of its ISPs, it is for the > registrant to update their ARIN record, not the upstreams. > > If we are to recommend a microallocation policy, I would like to see it > linked to the ASN process, since you shouldn't have one without the other. > > Stacy > > -----Original Message----- > From: Mury [mailto:mury at goldengate.net] > Sent: Thursday, February 27, 2003 9:36 AM > To: Marla Azinger > Cc: ppml at arin.net > Subject: Re: [ppml] Question RE: Draft 2 of proposal for ip assignment > with sponsorship > > > > I've missed most of this discussion too, but it sure seems like it leaves > a lot open for abuse, confusion, mistakes, etc. > > Why can't ARIN check to make sure they have 2 upstreams by asking for > contracts and bills the first time around, and at renewal time check some > of the backbone routers to make sure their AS is being announced by two > providers. There are gobs of places that ARIN could check this from that > would take 1 minute to do. If for some reason it doesn't show up in the > routing tables, then the ISP could provide bills. If they can't provide > bills proving they have two upstreams, yank the IPs. > > Part of me is also against the /24 allocation in the first place. I know > what it feels like, since I was a little irked when I couldn't get space > when we started out. But in the end it wasn't the end of the world. > Renumbering out of a /24 isn't a life ending task. Sure, it sucks, and > everyone would rather not do it, but hey almost all of us have had to deal > with it and we all made it okay. > > If you are multi-homed you need to contact your upstreams to announce the > block anyway so it doesn't provide any benefit there. > > Sorry to all those who disagree, it's just my two cents. > > Mury > > > On Thu, 27 Feb 2003, Marla Azinger wrote: > > > Hello- I know I've missed alot of the discussion between the last > > conference and up to this point...so please bear with me and the question > I > > have... > > > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > > sounds like more of a headache than anything...I'm sure I'm missing > > something because up to this point...I would just say my company isnt > going > > to participate in order to avoid...basically...all of it...we'v done fine > > without this until now... > > > > I guess what I'm missing here is...how is a smaller telecom company that > > provides internet access supposed to benefit from "sponsoring" this? Is > > there a benefit...or is this a bandaid for integrity issues? I'm sure > > there's a good list of reasons I'm missing...like I said I've missed most > of > > the discussion up to this point...but could someone provide a short and to > > the point list of how we'd benefit from "sponsoring" this? > > > > Thank you for your patience and time > > Marla > > ELI IP Analyst > > > > > > > > > > I would rather not see this language. The policy states that ISP A or ISP > B > > must inform ARIN > > when this happens. I know we can't depend on this to work, but if we build > > in a backup, why even > > ask ISP A or ISP B to inform ARIN of this change? > > > > Jim > > > > > > I think some sort of language saying that ARIN will do audits of the > > > assignments from time to time is needed. Or perhaps when you > > > pay your > > > annual renewal fee, you should have to provide proof along > > > with it that > > > you are still connected to more than 1 upstream. Basically > > > something that > > > will prevent someone from being multihomed today, get a micro > > > assignment, > > > and then drop their second provider while keeping their micro > > > assignment. > > > > > > Forrest > > > > > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > > > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > > > with sponsorship. > > > > It does not format well to be posted in the email as text > > > but you can > > > > review it online at: > > > > > > > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > > > ts_with_sponsorship.htm > > > > > > > > If you have any futher suggestions please feel free to > > > email me or otherwise > > > > discuss it on this list. If there are no suggestions for > > > addition to the > > > > current text, this will be the proposal I will send to > > > Richard Jimmerson > > > > end of this week. > > > > > > > > ---- > > > > William Leibzon > > > > Elan Communications > > > > william at elan.net > > > > From william at elan.net Thu Feb 27 12:35:00 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 09:35:00 -0800 (PST) Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment w ith sponsorship In-Reply-To: Message-ID: Is this position taken by UUNET or just your personal opinion? And you're not necessarily right, I can list you many reasons why somebody would want an ASN and not want their own NET. The other way is more clear, generally ASN should be a prerequisite for netblock but exceptions can happen there too. On Thu, 27 Feb 2003, Einar Bohlin wrote: > > If we are to recommend a microallocation policy, I would like to see it > > linked to the ASN process, since you shouldn't have one without the other. > > Everybody who registers an ASN ultimately wants their > own net. An ASN and a net should be a simple ARIN bundled > service. > > Regards, > > Einar Bohlin, IP Analyst > IP Team - Ashburn Virginia - WorldCom > Phone: 703 886-7362 (VNET 806-7362) > email: einar.bohlin at wcom.com > > > On Thu, 27 Feb 2003, Taylor, Stacy wrote: > > > Hi All, > > Speaking for the Office of IP Management for ICG only, I wonder why I would > > have to do more templates when multihoming information from two ISPs is > > required on the ASN request template. Is my ASN not already in fact > > "sponsoring" the multihomer by including my information on the > > record/request? > > > > If the ASN registrant changes one or both of its ISPs, it is for the > > registrant to update their ARIN record, not the upstreams. > > > > If we are to recommend a microallocation policy, I would like to see it > > linked to the ASN process, since you shouldn't have one without the other. > > > > Stacy > > > > -----Original Message----- > > From: Mury [mailto:mury at goldengate.net] > > Sent: Thursday, February 27, 2003 9:36 AM > > To: Marla Azinger > > Cc: ppml at arin.net > > Subject: Re: [ppml] Question RE: Draft 2 of proposal for ip assignment > > with sponsorship > > > > > > > > I've missed most of this discussion too, but it sure seems like it leaves > > a lot open for abuse, confusion, mistakes, etc. > > > > Why can't ARIN check to make sure they have 2 upstreams by asking for > > contracts and bills the first time around, and at renewal time check some > > of the backbone routers to make sure their AS is being announced by two > > providers. There are gobs of places that ARIN could check this from that > > would take 1 minute to do. If for some reason it doesn't show up in the > > routing tables, then the ISP could provide bills. If they can't provide > > bills proving they have two upstreams, yank the IPs. > > > > Part of me is also against the /24 allocation in the first place. I know > > what it feels like, since I was a little irked when I couldn't get space > > when we started out. But in the end it wasn't the end of the world. > > Renumbering out of a /24 isn't a life ending task. Sure, it sucks, and > > everyone would rather not do it, but hey almost all of us have had to deal > > with it and we all made it okay. > > > > If you are multi-homed you need to contact your upstreams to announce the > > block anyway so it doesn't provide any benefit there. > > > > Sorry to all those who disagree, it's just my two cents. > > > > Mury > > > > > > On Thu, 27 Feb 2003, Marla Azinger wrote: > > > > > Hello- I know I've missed alot of the discussion between the last > > > conference and up to this point...so please bear with me and the question > > I > > > have... > > > > > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > > > sounds like more of a headache than anything...I'm sure I'm missing > > > something because up to this point...I would just say my company isnt > > going > > > to participate in order to avoid...basically...all of it...we'v done fine > > > without this until now... > > > > > > I guess what I'm missing here is...how is a smaller telecom company that > > > provides internet access supposed to benefit from "sponsoring" this? Is > > > there a benefit...or is this a bandaid for integrity issues? I'm sure > > > there's a good list of reasons I'm missing...like I said I've missed most > > of > > > the discussion up to this point...but could someone provide a short and to > > > the point list of how we'd benefit from "sponsoring" this? > > > > > > Thank you for your patience and time > > > Marla > > > ELI IP Analyst > > > > > > > > > > > > > > > I would rather not see this language. The policy states that ISP A or ISP > > B > > > must inform ARIN > > > when this happens. I know we can't depend on this to work, but if we build > > > in a backup, why even > > > ask ISP A or ISP B to inform ARIN of this change? > > > > > > Jim > > > > > > > > I think some sort of language saying that ARIN will do audits of the > > > > assignments from time to time is needed. Or perhaps when you > > > > pay your > > > > annual renewal fee, you should have to provide proof along > > > > with it that > > > > you are still connected to more than 1 upstream. Basically > > > > something that > > > > will prevent someone from being multihomed today, get a micro > > > > assignment, > > > > and then drop their second provider while keeping their micro > > > > assignment. > > > > > > > > Forrest > > > > > > > > On Wed, 26 Feb 2003 william at elan.net wrote: > > > > > > > > > > > > > > I'v made a 2nd draft for proposal for ip micro-assignment > > > > with sponsorship. > > > > > It does not format well to be posted in the email as text > > > > but you can > > > > > review it online at: > > > > > > > > > > > > > > http://www.elan.net/~william/arin_proposal_for_micro_assignmen > > > > ts_with_sponsorship.htm > > > > > > > > > > If you have any futher suggestions please feel free to > > > > email me or otherwise > > > > > discuss it on this list. If there are no suggestions for > > > > addition to the > > > > > current text, this will be the proposal I will send to > > > > Richard Jimmerson > > > > > end of this week. > > > > > > > > > > ---- > > > > > William Leibzon > > > > > Elan Communications > > > > > william at elan.net > > > > > > > > > > > > > > > > > > > > > > > > > From jsw at five-elements.com Thu Feb 27 17:40:03 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 27 Feb 2003 17:40:03 -0500 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship Message-ID: <1046385603.701.246.camel@intrepid> On Thu, 2003-02-27 at 00:26, Forrest wrote: > I think ARIN doing audits on the space periodically and/or doing checks > when you pay your renewal fee would be a lot more reliable than hoping > that an upstream would notify ARIN if you ceased being their customer. I think the idea that the ARIN periodically audit micro-allocations is utterly unrealistic. In my experience they barely have the manpower and organizational capabilities to keep up with their current duties, even with a large budget excess. Do you expect the ARIN to suddenly increase headcount to accomodate an audit process for an allocation policy that it evidently does not want to see implemented in the first place? I must agree with Einar Bohlin's position that nearly every organization who registers an ASN does indeed want their own provider-independent space. Mine most certainly does, and I don't mean a /24. My company can easily justify allocation of a /22 under current IPv4 allocation guidelines, and could grow into a /21 easily. There is simply no procedure for issuing such long allocations. Sadly, the practice of submitting false documentation to the ARIN with the intent of reaching the minimum allocation size is very common. Anyone who does not know that is wholely out of touch with small ISPs and mid-size corporate Internet users. In the current environment, it seems that the ARIN membership must be very accepting of folks lieing to get their provider-independent /20, even if they could get by with a longer allocation for a year or more. Either that, or organizationally, policy changes cannot be dedided upon and implemented by the ARIN in a business-like timeframe, so everyone is forced to turn a blind eye to this space-wasting practice. -- Jeff S Wheeler From marla_azinger at eli.net Thu Feb 27 17:38:49 2003 From: marla_azinger at eli.net (Marla Azinger) Date: Thu, 27 Feb 2003 14:38:49 -0800 Subject: [ppml] re: /24 no justification needed Message-ID: <000e01c2deb0$ff754100$770d1bac@eli.czn.com> ok... Thank you for the input on the micro allocations... But...now you bring up another interesting subject... you wrote in the middle of one paragraph: "/24 is already includes as automatic minimum with no justification" At the last conference people stood up to the mic and said this exact same thing...but when I went and confirmed this with ARIN staff they said no...everything has to be justified. So I would like some dogma here ...is it true or not that a customer can be given a /24 if they want to multi-home even if they wont use all but one quarter to a half of the assignment? Thank you Marla ELI IP Analyst From ahp at hilander.com Thu Feb 27 17:52:41 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 27 Feb 2003 15:52:41 -0700 Subject: [ppml] re: /24 no justification needed In-Reply-To: <000e01c2deb0$ff754100$770d1bac@eli.czn.com> References: <000e01c2deb0$ff754100$770d1bac@eli.czn.com> Message-ID: <2147483647.1046361161@d57.wireless.hilander.com> Justification can come in many forms. There is a ratified policy that allows ISPs to assign a /24 to any customer they have as long as the customer is multi-homed. The multi-homing is the justification. Note that this is specifically only a provider assigned space. Alec --On Thursday, February 27, 2003 2:38 PM -0800 Marla Azinger wrote: > ok... Thank you for the input on the micro allocations... > > But...now you bring up another interesting subject... you wrote in the > middle of one paragraph: > > "/24 is > already includes as automatic minimum with no justification" > > > At the last conference people stood up to the mic and said this exact same > thing...but when I went and confirmed this with ARIN staff they said > no...everything has to be justified. So I would like some dogma here > ...is it true or not that a customer can be given a /24 if they want to > multi-home even if they wont use all but one quarter to a half of the > assignment? > > Thank you > Marla > ELI IP Analyst > -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From ebohlin at UU.NET Thu Feb 27 17:52:43 2003 From: ebohlin at UU.NET (Einar Bohlin) Date: Thu, 27 Feb 2003 17:52:43 -0500 (EST) Subject: [ppml] re: /24 no justification needed In-Reply-To: <000e01c2deb0$ff754100$770d1bac@eli.czn.com> Message-ID: Hi, http://www.arin.net/policy/2001_2.html A multihomed customer is allowed one /24 from one of their upstream ISPs regardless of host count. Regards, Einar Bohlin, IP Analyst IP Team - Ashburn Virginia - WorldCom Phone: 703 886-7362 (VNET 806-7362) email: einar.bohlin at wcom.com On Thu, 27 Feb 2003, Marla Azinger wrote: > ok... Thank you for the input on the micro allocations... > > But...now you bring up another interesting subject... you wrote in the > middle of one paragraph: > > "/24 is > already includes as automatic minimum with no justification" > > > At the last conference people stood up to the mic and said this exact same > thing...but when I went and confirmed this with ARIN staff they said > no...everything has to be justified. So I would like some dogma here ...is > it true or not that a customer can be given a /24 if they want to multi-home > even if they wont use all but one quarter to a half of the assignment? > > Thank you > Marla > ELI IP Analyst > > From forrest at almighty.c64.org Thu Feb 27 17:55:54 2003 From: forrest at almighty.c64.org (Forrest) Date: Thu, 27 Feb 2003 16:55:54 -0600 (CST) Subject: [ppml] re: /24 no justification needed In-Reply-To: <000e01c2deb0$ff754100$770d1bac@eli.czn.com> Message-ID: The policy you're looking for that covers the /24 reassignment with no justification needed other than being multihomed is 2001-2. http://www.arin.net/policy/2001_2.html Forrest On Thu, 27 Feb 2003, Marla Azinger wrote: > ok... Thank you for the input on the micro allocations... > > But...now you bring up another interesting subject... you wrote in the > middle of one paragraph: > > "/24 is > already includes as automatic minimum with no justification" > > > At the last conference people stood up to the mic and said this exact same > thing...but when I went and confirmed this with ARIN staff they said > no...everything has to be justified. So I would like some dogma here ...is > it true or not that a customer can be given a /24 if they want to multi-home > even if they wont use all but one quarter to a half of the assignment? > > Thank you > Marla > ELI IP Analyst > From ahp at hilander.com Thu Feb 27 17:56:29 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 27 Feb 2003 15:56:29 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <1046385603.701.246.camel@intrepid> References: <1046385603.701.246.camel@intrepid> Message-ID: <2147483647.1046361389@d57.wireless.hilander.com> --On Thursday, February 27, 2003 5:40 PM -0500 Jeff S Wheeler wrote: > > Sadly, the practice of submitting false documentation to the ARIN with > the intent of reaching the minimum allocation size is very common. > Anyone who does not know that is wholely out of touch with small ISPs > and mid-size corporate Internet users. > > In the current environment, it seems that the ARIN membership must be > very accepting of folks lieing to get their provider-independent /20, > even if they could get by with a longer allocation for a year or more. > Either that, or organizationally, policy changes cannot be dedided upon > and implemented by the ARIN in a business-like timeframe, so everyone is > forced to turn a blind eye to this space-wasting practice. "Thieves aren't criminals, they are just underpaid". No matter how much we change the rules people are going to lie. Why should this be a reason to relax the ARIN minimum allocation? Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From william at elan.net Thu Feb 27 16:43:36 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 13:43:36 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046361389@d57.wireless.hilander.com> Message-ID: At least they will get the space they actually need and not try to get /20 and not use 80% of it, so in the end we get some space conservation. I do hope you are wrong how widespread "lying" is and what exist is likely the result of larger size on ARIN's initial assignment anyway. Would be good to compare with what is happening at RIPE or APNIC, none of them have this large initial allocation size, yet they seem to use space more "conservatively" and use less of it eventhough grown of internet there is larger now then in US. > > No matter how much we change the rules people are going to lie. Why should > this be a reason to relax the ARIN minimum allocation? > > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com From ahp at hilander.com Thu Feb 27 18:47:01 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 27 Feb 2003 16:47:01 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046364421@d57.wireless.hilander.com> --On Thursday, February 27, 2003 1:43 PM -0800 william at elan.net wrote: > At least they will get the space they actually need and not try to get > /20 and not use 80% of it, so in the end we get some space conservation. The space people 'need' is only one side of this discussion. The structure of the routing table is another issue that cannot be ignored. I do not think anybody is disputing the point that provider independent is easier for many reasons. However, addresses are addresses, and while renumbering may be annoying it is really not that difficult when you structure your system properly. The key here is that we consider all of the issues surrounding ARIN's minimum allocation size. If we just focus on people lying, how much of a pain it is to renumber, or the routing table structure individually then we will not come to a conclusion that satisfies all of the issues. > > I do hope you are wrong how widespread "lying" is and what exist is > likely the result of larger size on ARIN's initial assignment anyway. Well getting accurate data on that would be tricky. > > Would be good to compare with what is happening at RIPE or APNIC, none of > them have this large initial allocation size, yet they seem to use space > more "conservatively" and use less of it eventhough grown of internet > there is larger now then in US. I'm curious, where do you get your data on this (internet growth and address space utilization)? Also, RIPE uses a very different system for allocating addresses, every time a RIPE LIR wants to make an assignment you have to get permission from RIPE (Cathy Wittbrodt calls this the "Mother May I" system). Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From owen at delong.com Thu Feb 27 19:28:56 2003 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Feb 2003 16:28:56 -0800 Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <000701c2de7f$8e4a1db0$770d1bac@eli.czn.com> References: <000701c2de7f$8e4a1db0$770d1bac@eli.czn.com> Message-ID: <2147483647.1046363336@imac-en0.delong.sj.ca.us> The point is to have a way to issue microallocations only to multihomed orgs with a process that allows the ISPs to have a defined procedure for working with ARIN on it and preserves the integrity of the system. By requiring an ORG that wants a microallocation to have two ISP sponsors, ARIN can guarantee that the ORG is multihomed. The ISPs that sponsor it are saying that they are providing connectivity to the ORG. I don't see where this is much more of a headache to an ISP than having a multihomed customer in the first place. However, any ISP would certainly be free to decline business and refuse to sponsore ORGs that wanted to pay them to provide transit to their multihomed network. Owen --On Thursday, February 27, 2003 8:44 AM -0800 Marla Azinger wrote: > Hello- I know I've missed alot of the discussion between the last > conference and up to this point...so please bear with me and the question > I have... > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > sounds like more of a headache than anything...I'm sure I'm missing > something because up to this point...I would just say my company isnt > going to participate in order to avoid...basically...all of it...we'v > done fine without this until now... > > I guess what I'm missing here is...how is a smaller telecom company that > provides internet access supposed to benefit from "sponsoring" this? Is > there a benefit...or is this a bandaid for integrity issues? I'm sure > there's a good list of reasons I'm missing...like I said I've missed most > of the discussion up to this point...but could someone provide a short > and to the point list of how we'd benefit from "sponsoring" this? > > Thank you for your patience and time > Marla > ELI IP Analyst > > > > > I would rather not see this language. The policy states that ISP A or ISP > B must inform ARIN > when this happens. I know we can't depend on this to work, but if we build > in a backup, why even > ask ISP A or ISP B to inform ARIN of this change? > > Jim >> >> I think some sort of language saying that ARIN will do audits of the >> assignments from time to time is needed. Or perhaps when you >> pay your >> annual renewal fee, you should have to provide proof along >> with it that >> you are still connected to more than 1 upstream. Basically >> something that >> will prevent someone from being multihomed today, get a micro >> assignment, >> and then drop their second provider while keeping their micro >> assignment. >> >> Forrest >> >> On Wed, 26 Feb 2003 william at elan.net wrote: >> >> > >> > I'v made a 2nd draft for proposal for ip micro-assignment >> with sponsorship. >> > It does not format well to be posted in the email as text >> but you can >> > review it online at: >> > >> > >> http://www.elan.net/~william/arin_proposal_for_micro_assignmen >> ts_with_sponsorship.htm >> > >> > If you have any futher suggestions please feel free to >> email me or otherwise >> > discuss it on this list. If there are no suggestions for >> addition to the >> > current text, this will be the proposal I will send to >> Richard Jimmerson >> > end of this week. >> > >> > ---- >> > William Leibzon >> > Elan Communications >> > william at elan.net >> > >> >> >> >> >> > From owen at delong.com Thu Feb 27 19:31:39 2003 From: owen at delong.com (Owen DeLong) Date: Thu, 27 Feb 2003 16:31:39 -0800 Subject: [ppml] Question RE: Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046363499@imac-en0.delong.sj.ca.us> Renumbering out of a /24 may not be the end of the world, but what about renumbering all of your /28 customers out of a /21? Owen --On Thursday, February 27, 2003 11:35 AM -0600 Mury wrote: > > I've missed most of this discussion too, but it sure seems like it leaves > a lot open for abuse, confusion, mistakes, etc. > > Why can't ARIN check to make sure they have 2 upstreams by asking for > contracts and bills the first time around, and at renewal time check some > of the backbone routers to make sure their AS is being announced by two > providers. There are gobs of places that ARIN could check this from that > would take 1 minute to do. If for some reason it doesn't show up in the > routing tables, then the ISP could provide bills. If they can't provide > bills proving they have two upstreams, yank the IPs. > > Part of me is also against the /24 allocation in the first place. I know > what it feels like, since I was a little irked when I couldn't get space > when we started out. But in the end it wasn't the end of the world. > Renumbering out of a /24 isn't a life ending task. Sure, it sucks, and > everyone would rather not do it, but hey almost all of us have had to deal > with it and we all made it okay. > > If you are multi-homed you need to contact your upstreams to announce the > block anyway so it doesn't provide any benefit there. > > Sorry to all those who disagree, it's just my two cents. > > Mury > > > On Thu, 27 Feb 2003, Marla Azinger wrote: > >> Hello- I know I've missed alot of the discussion between the last >> conference and up to this point...so please bear with me and the >> question I have... >> >> Why is it necessary for an ISP to "sponsor" this? So far...sponsorship >> sounds like more of a headache than anything...I'm sure I'm missing >> something because up to this point...I would just say my company isnt >> going to participate in order to avoid...basically...all of it...we'v >> done fine without this until now... >> >> I guess what I'm missing here is...how is a smaller telecom company that >> provides internet access supposed to benefit from "sponsoring" this? Is >> there a benefit...or is this a bandaid for integrity issues? I'm sure >> there's a good list of reasons I'm missing...like I said I've missed >> most of the discussion up to this point...but could someone provide a >> short and to the point list of how we'd benefit from "sponsoring" this? >> >> Thank you for your patience and time >> Marla >> ELI IP Analyst >> >> >> >> >> I would rather not see this language. The policy states that ISP A or >> ISP B must inform ARIN >> when this happens. I know we can't depend on this to work, but if we >> build in a backup, why even >> ask ISP A or ISP B to inform ARIN of this change? >> >> Jim >> > >> > I think some sort of language saying that ARIN will do audits of the >> > assignments from time to time is needed. Or perhaps when you >> > pay your >> > annual renewal fee, you should have to provide proof along >> > with it that >> > you are still connected to more than 1 upstream. Basically >> > something that >> > will prevent someone from being multihomed today, get a micro >> > assignment, >> > and then drop their second provider while keeping their micro >> > assignment. >> > >> > Forrest >> > >> > On Wed, 26 Feb 2003 william at elan.net wrote: >> > >> > > >> > > I'v made a 2nd draft for proposal for ip micro-assignment >> > with sponsorship. >> > > It does not format well to be posted in the email as text >> > but you can >> > > review it online at: >> > > >> > > >> > http://www.elan.net/~william/arin_proposal_for_micro_assignmen >> > ts_with_sponsorship.htm >> > > >> > > If you have any futher suggestions please feel free to >> > email me or otherwise >> > > discuss it on this list. If there are no suggestions for >> > addition to the >> > > current text, this will be the proposal I will send to >> > Richard Jimmerson >> > > end of this week. >> > > >> > > ---- >> > > William Leibzon >> > > Elan Communications >> > > william at elan.net >> > > >> > >> > >> > >> > >> > >> > From william at elan.net Thu Feb 27 18:14:36 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 15:14:36 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046364421@d57.wireless.hilander.com> Message-ID: On Thu, 27 Feb 2003, Alec H. Peterson wrote: > --On Thursday, February 27, 2003 1:43 PM -0800 william at elan.net wrote: > > > At least they will get the space they actually need and not try to get > > /20 and not use 80% of it, so in the end we get some space conservation. > > The space people 'need' is only one side of this discussion. The structure > of the routing table is another issue that cannot be ignored. Agreed. That is why multihoming (and not just saying so or just requiring an ASN but actually verifying that it is done) must be part of the deal. > I do not think anybody is disputing the point that provider independent is > easier for many reasons. However, addresses are addresses, and while > renumbering may be annoying it is really not that difficult when you > structure your system properly. We're not in ipv6 age yet. In ipp4 renumbering, no matter how well the network is setup, is difficult - especially when dealing with large enough network. You have to change setup in most several routers (include firewall, switches as well as changing filters, change setup in many computers (even dhcp will not completely solve things), change dns (both nameserver ip and actualdns zones). So let me respectively disagree with you about how easy renumbering is. > The key here is that we consider all of the issues surrounding ARIN's > minimum allocation size. If we just focus on people lying, how much of a > pain it is to renumber, or the routing table structure individually then we > will not come to a conclusion that satisfies all of the issues. I agree with you. And considering widespread difference in opinion on this micro-assignment issue we may not be able to get everybody to support any policy proposal so a compromise proposal that has support of majority but may not go far enough for some but too far for others maybe the answer. This is a tipical situation with the how laws are made. And on specific points you have above: honesty: Proposal has to provide for good way to catch people who are lying and to minimize the abuse. Many believe that relying only on ARIN staff to catch those who lie does not work (you said it yourself!). ARIN becoming net-police also is not an answer to stop possible abuse. renumbering: I think I already said enough on this above. routing table: Multihoming organizations are already announcing part of their upstream's block as separate BGP announcement. Having them announce their own block would not change size of the routing table, but good provisions must be put to check that those requesting micro-assignments are indeed multihomed. Relying on them just having an ASN without futher verification may not be enough. > > I do hope you are wrong how widespread "lying" is and what exist is > > likely the result of larger size on ARIN's initial assignment anyway. > > Well getting accurate data on that would be tricky. Yes. So lets drop this point. > > > > Would be good to compare with what is happening at RIPE or APNIC, none of > > them have this large initial allocation size, yet they seem to use space > > more "conservatively" and use less of it eventhough grown of internet > > there is larger now then in US. > > I'm curious, where do you get your data on this (internet growth and > address space utilization)? Amount of space used from ARIN's statistics, still shows ARIN ahead of others in yearly grown (its evening now), this statistics are presented on each ARIN's meeeting and are not under dispute. Amount of growth from multiple sites, each one of them uses different methods so results are questionable by different parties' views. Opinion about grown of internet larger outside of US is my own based on results from these and other sites: http://www.glreach.com/globstats/ http://www.internetstats.com/ http://www.cybergeography.org/statistics.html (likes to many other sites) http://www.caida.org Others sites I can't remember without looking deep into my bookmarks and history of websites I'v visited. > Also, RIPE uses a very different system for allocating addresses, every > time a RIPE LIR wants to make an assignment you have to get permission from > RIPE (Cathy Wittbrodt calls this the "Mother May I" system). That seems to indicate that in RIPE-land RIPE has the strictest policies and ISPs are more liberal. In ARIN-land the situation may actually be completely opposite. At least some of the opposition I'v seen to previous proposals came from ISPs who believe they know how to assign ips properly and whome to and do not think ARIN can do the same. That view is supported by that support for the micro-assignments in part comes from those organizations who have problems getting ip space from their upstreams and believe ARIN can do a lot better for them and at least it has well-known policies and procedures that can be argued and changed if necessary. > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > From ahp at hilander.com Thu Feb 27 20:24:13 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 27 Feb 2003 18:24:13 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046370253@d57.wireless.hilander.com> --On Thursday, February 27, 2003 3:14 PM -0800 william at elan.net wrote: > We're not in ipv6 age yet. In ipp4 renumbering, no matter how well the > network is setup, is difficult - especially when dealing with large > enough network. You have to change setup in most several routers > (include firewall, switches as well as changing filters, change setup in > many computers (even dhcp will not completely solve things), change dns > (both nameserver ip and actualdns zones). So let me respectively > disagree with you about how easy renumbering is. Fair enough. > I agree with you. And considering widespread difference in opinion on > this micro-assignment issue we may not be able to get everybody to > support any policy proposal so a compromise proposal that has support of > majority but may not go far enough for some but too far for others maybe > the answer. This is a tipical situation with the how laws are made. We'll never get 100% concensus, but we need to be closer to where we are now. > > And on specific points you have above: > honesty: Proposal has to provide for good way to catch people who are > lying and to minimize the abuse. Many believe that relying only > on ARIN staff to catch those who lie does not work (you said it > yourself!). ARIN becoming net-police also is not an answer to > stop possible abuse. True. And changing policies just because people lie is also a poor idea. > renumbering: I think I already said enough on this above. > routing table: Multihoming organizations are already announcing part > of their upstream's block as separate BGP announcement. Having > them announce their own block would not change size of the > routing table, but good provisions must be put to check that > those requesting micro-assignments are indeed multihomed. > Relying on them just having an ASN without futher verification > may not be enough. But there is one key point that you have missed (and many people have missed). While the number of prefixes may not change, the structure of the table will change. Right now, a /24 out of one of UUnet's /14s is part of a larger aggregate. If this UUnet customer has his own /24 this is not part of a larger aggregate. What is the impact of this? Well, with today's routing table and routers nothing. However, history has prooven that it is sometimes necessary to not accept all announcements, and the easiest way to deal with this is to filter on RIR allocation boundaries. If we move forward with having ARIN allocate /24s then we are tying the hands of the backbones that we all depend on. Making these microallocations out of a separate block would help mitigate the issue, but there would still be far more prefixes out there that are not part of smaller aggregates, which is the fundamental issue here as I see it. As I have said in the past, there are so many new mistakes we can make, why must we insist on making the same ones again? Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From jmcburnett at msmgmt.com Thu Feb 27 21:29:51 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 27 Feb 2003 21:29:51 -0500 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship Message-ID: <390E55B947E7C848898AEBB9E5077060750AC7@msmdcfs01.msmgmt.com> Okay I have a few questions here see inlne: > From: Alec H. Peterson > But there is one key point that you have missed (and many people have > missed). While the number of prefixes may not change, the > structure of the > table will change. Right now, a /24 out of one of UUnet's > /14s is part of > a larger aggregate. If this UUnet customer has his own /24 > this is not > part of a larger aggregate. As I read this: This means that the ARIN Micro allocation may be more likely to be globally routeable than the UUnet Class C multihomed Class C.... True / False? If this is TRUE, then why would anyone not want to do this? >From the customer stand point: Hey I like this!! >From the ISP standpoint: My block(s) is(are) now summarizeable again!! AND IT makes it much easier to allow a Multihomer to be a customer! > > What is the impact of this? Well, with today's routing table > and routers > nothing. However, history has prooven that it is sometimes > necessary to > not accept all announcements, and the easiest way to deal > with this is to > filter on RIR allocation boundaries. If we move forward with > having ARIN > allocate /24s then we are tying the hands of the backbones > that we all > depend on. Making these microallocations out of a separate > block would > help mitigate the issue, but there would still be far more > prefixes out > there that are not part of smaller aggregates, which is the > fundamental > issue here as I see it. > > As I have said in the past, there are so many new mistakes we > can make, why > must we insist on making the same ones again? YES, we must make mistakes, but now let's learn from this one and move on.. I would like to see the latest policy as it stands now... I think that Micro-Allocations is something we MUST do.. Routing table- I think this issue is probrably null? ISP involvement? I think Alec just hit it has anyone here ever had to carve out a /24 from a /14 and then re-define BGP networks to remove it? This time savings for some high $$ network Eng and on to a low $$ sales/cust care person.. hmmmm Either way- adding an ASN to filter into an ASN should be easier with the IP's coming from a non-ISP block!!! YES / NO? does this sway anyone's thoughts? or is it just bait? J From william at elan.net Thu Feb 27 19:41:23 2003 From: william at elan.net (william at elan.net) Date: Thu, 27 Feb 2003 16:41:23 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046370253@d57.wireless.hilander.com> Message-ID: I have not missed this point, in fact I already made a draft available in separate email to this list for proposal that would require ARIN to make micro-assignments from specific class-A and in fact to try to keep size of assignments about the same for each /8 ARIN has and make information about this size of smallest announement for each /8 publicly available (to be fair they already provide this information on website even now). I also argued before against what are otherwise fairly good proposals 2002-5 and 2002-6 on the grounds that they do not include provision that when changing to smaller size block then /20 ISPs must get allocated space from /8 block here other micro-allocations are also being made and where ISPs do not filter it on /20 boundary. In addition I have to point out again that both APNIC and RIPE are making assignments smaller then /20 out of their blocks which seems to indicate a support of this among majority of RIRs. And this also means no matter how we look at it, smaller announcements would still dominate routing table if the grows of internet in the countries that represent 90% of the World population continues. And as far as load on the routers we have Moor's law that says that they would become twice as fast every two years, the grows of the routing table as seen at http://www.employees.org/~tbates/cidr.plot.html is a lot smaller and everything does indicate that routers are becoming faster and smarter and more capable and new technologies are also being invented that help to deal with more complex routing table. > > routing table: Multihoming organizations are already announcing part > > of their upstream's block as separate BGP announcement. Having > > them announce their own block would not change size of the > > routing table, but good provisions must be put to check that > > those requesting micro-assignments are indeed multihomed. > > Relying on them just having an ASN without futher verification > > may not be enough. > > But there is one key point that you have missed (and many people have > missed). While the number of prefixes may not change, the structure of the > table will change. Right now, a /24 out of one of UUnet's /14s is part of > a larger aggregate. If this UUnet customer has his own /24 this is not > part of a larger aggregate. > > What is the impact of this? Well, with today's routing table and routers > nothing. However, history has prooven that it is sometimes necessary to > not accept all announcements, and the easiest way to deal with this is to > filter on RIR allocation boundaries. If we move forward with having ARIN > allocate /24s then we are tying the hands of the backbones that we all > depend on. Making these microallocations out of a separate block would > help mitigate the issue, but there would still be far more prefixes out > there that are not part of smaller aggregates, which is the fundamental > issue here as I see it. > > As I have said in the past, there are so many new mistakes we can make, why > must we insist on making the same ones again? > > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > From ahp at hilander.com Thu Feb 27 22:51:58 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Thu, 27 Feb 2003 20:51:58 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046379118@d57.wireless.hilander.com> --On Thursday, February 27, 2003 4:41 PM -0800 william at elan.net wrote: > I have not missed this point, in fact I already made a draft available in > separate email to this list for proposal that would require ARIN to make > micro-assignments from specific class-A and in fact to try to keep size > of assignments about the same for each /8 ARIN has and make information > about this size of smallest announement for each /8 publicly available > (to be fair they already provide this information on website even now). > I also argued before against what are otherwise fairly good proposals > 2002-5 and 2002-6 on the grounds that they do not include provision that > when changing to smaller size block then /20 ISPs must get allocated > space from /8 block here other micro-allocations are also being made and > where ISPs do not filter it on /20 boundary. But regardless of where the allocations come from, there will still be lots of allocations that cannot be summarized that otherwise could be summarized. > > In addition I have to point out again that both APNIC and RIPE are making > assignments smaller then /20 out of their blocks which seems to indicate > a support of this among majority of RIRs. And this also means no matter > how we look at it, smaller announcements would still dominate routing > table if the grows of internet in the countries that represent 90% of the > World population continues. I am not intimately familiar with RIPEs or APNICs policies. However, according to RIPE-269 you are not correct: IPv4 CIDR block Default RIPE NCC Smallest RIPE NCC Allocation Allocation / Assignment 62/8 /19 /19 80/8 /20 /20 81/8 /20 /20 82/8 /20 /20 193/8 /19 /29 194/8 /19 /29 195/8 /19 /29 212/8 /19 /19 213/8 /19 /19 217/8 /20 /20 APNIC does have a policy for multi-homing though I am not familiar with it. I am sure somebody else here can provide more accurate information. > > And as far as load on the routers we have Moor's law that says that they > would become twice as fast every two years, the grows of the routing > table as seen at http://www.employees.org/~tbates/cidr.plot.html is a > lot smaller and everything does indicate that routers are becoming faster > and smarter and more capable and new technologies are also being invented > that help to deal with more complex routing table. Well, routers are getting faster and smarter, but you are assuming that routing table growth and routing table computation increase linearly with respect to one another. I do not know enough about route computation algorithms to say one way or another. But can multihomed joe end user afford the latest and greatest 6 and 7 figure router? Many people are running low-end or old routers that are being pushed to the limit. What about them? Just so we're all on the same page, I am all for doing what is best for the entire Internet. I realize I have mainly been arguing routing table issues against reducing the minimum size, but that is mainly because of the fact that there are very few people arguing those points, and I feel it is important for both sides of an argument to be presented. Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From anne at apnic.net Thu Feb 27 23:35:35 2003 From: anne at apnic.net (Anne Lord) Date: Fri, 28 Feb 2003 14:35:35 +1000 (EST) Subject: [hm-staff] RE: [ppml] Draft 2 of proposal for ip assignment with sponsorship Message-ID: Hi Alec, Just to respond to one point in this email. > APNIC does have a policy for multi-homing though I am not familiar with it. > I am sure somebody else here can provide more accurate information. It is known as the 'small multihoming assignment policy'. In brief you can receive portable address space direct from APNIC if you meet specific criteria: - If you are multihomed or plan to multihome withinone month; - Agree to renumber out of previously assigned space. Organisations requesting a portable assignment under these terms must demonstrate that they are able to use 25 percent of the requested assignment immediately and 50 percent within one year. There is no minimum assignment size for portable assignments made under these terms. There is also no maximum size but note it is an assignment and this implies no further sub-assignment of the address space. It is often more economical for an ISP who meets the critieria for a minimum allocation to request an allocation instead. You can request an assignment if you meet the criteria as a member or non-member. You can find a description of the policy here: http://www.apnic.net/docs/policy/add-manage-policy.html#11.1 Section 11.1. Take up of the policy has been relatively slow. This may also be of use to this discussion: http://www.apnic.net/db/min-alloc.html Which states APNIC minimum assignment and allocation sizes within blocks. Hope this helps, Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 _____________________________________________________________________ > > > > > And as far as load on the routers we have Moor's law that says that they > > would become twice as fast every two years, the grows of the routing > > table as seen at http://www.employees.org/~tbates/cidr.plot.html is a > > lot smaller and everything does indicate that routers are becoming faster > > and smarter and more capable and new technologies are also being invented > > that help to deal with more complex routing table. > > Well, routers are getting faster and smarter, but you are assuming that > routing table growth and routing table computation increase linearly with > respect to one another. I do not know enough about route computation > algorithms to say one way or another. > > But can multihomed joe end user afford the latest and greatest 6 and 7 > figure router? Many people are running low-end or old routers that are > being pushed to the limit. What about them? > > Just so we're all on the same page, I am all for doing what is best for the > entire Internet. I realize I have mainly been arguing routing table issues > against reducing the minimum size, but that is mainly because of the fact > that there are very few people arguing those points, and I feel it is > important for both sides of an argument to be presented. > > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > _______________________________________________ > Hostmaster-staff mailing list > Hostmaster-staff at apnic.net > http://mailman.apnic.net/mailman/listinfo/hostmaster-staff > From jmcburnett at msmgmt.com Thu Feb 27 23:49:46 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Thu, 27 Feb 2003 23:49:46 -0500 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship Message-ID: <390E55B947E7C848898AEBB9E5077060750AC8@msmdcfs01.msmgmt.com> > Well, routers are getting faster and smarter, but you are > assuming that > routing table growth and routing table computation increase > linearly with > respect to one another. I do not know enough about route computation > algorithms to say one way or another. Although I am not an expert.. Consider this: Cisco will tell you that a 2650XM router Retail:$3295. This has the power and RAM to handle a huge route table.. > But can multihomed joe end user afford the latest and > greatest 6 and 7 > figure router? Many people are running low-end or old > routers that are > being pushed to the limit. What about them? See note above.. Routers are cheap.. I am using a 2621 to multihome.. Default route only.. Ya don't need a 7200 anymore... and with the new 7200 Proc upgrade..... anyway we should not be doing WAN design here..... > > Just so we're all on the same page, I am all for doing what > is best for the > entire Internet. I realize I have mainly been arguing > routing table issues > against reducing the minimum size, but that is mainly because > of the fact > that there are very few people arguing those points, and I feel it is > important for both sides of an argument to be presented. > > Alec Route table size..Assume an end user is multi-homed with ISP A and ISP B ISP A provides the IP addresses, and ISP A can summarize.. ISP B can't so routing table size is still gonna grow!!! NOTE 2: If we use the /8 block to Multi-home, the back bone providers may very well have the option to summarize the multi-homers.... They, Assume backbone A, get 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24 and more.. All of these go to different Tier 2/3 providers below Backbone A. Backbone A will summarize.. hence global tables don't really grow that much.. Anyway, this is not a routing class either... J > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > From forrest at almighty.c64.org Fri Feb 28 09:27:56 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 28 Feb 2003 08:27:56 -0600 (CST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046379118@d57.wireless.hilander.com> Message-ID: On Thu, 27 Feb 2003, Alec H. Peterson wrote: > --On Thursday, February 27, 2003 4:41 PM -0800 william at elan.net wrote: > > > I have not missed this point, in fact I already made a draft available in > > separate email to this list for proposal that would require ARIN to make > > micro-assignments from specific class-A and in fact to try to keep size > > of assignments about the same for each /8 ARIN has and make information > > about this size of smallest announement for each /8 publicly available > > (to be fair they already provide this information on website even now). > > I also argued before against what are otherwise fairly good proposals > > 2002-5 and 2002-6 on the grounds that they do not include provision that > > when changing to smaller size block then /20 ISPs must get allocated > > space from /8 block here other micro-allocations are also being made and > > where ISPs do not filter it on /20 boundary. > > But regardless of where the allocations come from, there will still be lots > of allocations that cannot be summarized that otherwise could be summarized. > If you get a /24 from one of your upstreams, your /24 is part of your ISP's larger aggregate. The people arguing routing table explosion caused by a micro allocation policy seem to take the stance that they can filter your /24 from your ISP's aggregate and you'll be fine because they'll still have a route to you via that aggregate. If you receive a micro allocation they will no longer be able to filter your /24. If you filter my /24 from my provider's aggregate, what exactly is the point of me multihoming? If I lose connectivity with that upstream, you'll no longer be able to reach me because you won't hear my /24 announcement from my other upstream. To me, it doesn't seem acceptable to filter out multihoming /24's at all. Creating a micro allocation policy would seem to address this issue. Create a block of addresses that /24's won't get filtered from, while still allowing everyone to filter out the garbage more specific /24's from elsewhere. Forrest From william at elan.net Fri Feb 28 07:40:12 2003 From: william at elan.net (william at elan.net) Date: Fri, 28 Feb 2003 04:40:12 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046379118@d57.wireless.hilander.com> Message-ID: > But regardless of where the allocations come from, there will still be lots > of allocations that cannot be summarized that otherwise could be summarized. Are you so sure summarization is such a good thing? Multihoming is the way to allow multiple routes to a network and to allow network to be up through backup provider when primary one is down. Now you summarize the routes and primary provider of some organization is down (assuming primary is the one who has that /14 and company is using /22 out of that) because you summarized the routes you would not be able to reach that companies' servers. So you customers are not able to get to that network and your competitor next door are because they do not do summarization. Who is the winner here, your users or your competitor's users? > > > > In addition I have to point out again that both APNIC and RIPE are making > > assignments smaller then /20 out of their blocks which seems to indicate > > a support of this among majority of RIRs. And this also means no matter > > how we look at it, smaller announcements would still dominate routing > > table if the grows of internet in the countries that represent 90% of the > > World population continues. > > I am not intimately familiar with RIPEs or APNICs policies. However, > according to RIPE-269 you are not correct: > > IPv4 CIDR block Default RIPE NCC Smallest RIPE NCC > Allocation Allocation / Assignment > 62/8 /19 /19 > 80/8 /20 /20 > 81/8 /20 /20 > 82/8 /20 /20 > 193/8 /19 /29 > 194/8 /19 /29 > 195/8 /19 /29 > 212/8 /19 /19 > 213/8 /19 /19 > 217/8 /20 /20 How am I not correct if on the same RIPE document it says "Allocations or assignments smaller than the default size have been made to users requesting Provider Independent (PI) IPv4 address space." (did I see /29 there above?). And do note that by RIPE's definition and the name itself LIR (Local Internet Registry) does not necessarily have to be an ISP, it can be organization dedicated to subdelegating space to ISPs somewhat in a way RIR does (so they could fragment the space in routing table, but this is obviously discoraged). But to be more to the point RIPE has a procedure in place on how LIR can do micro-assignments (they call it Provider Independent Address Space): http://www.ripe.net/training/lir/material/slides/page103.htm http://www.ripe.net/training/lir/material/slides/page106.htm By that procedure LIR can request PI space on behelf of the end-user and then RIPE assigns that space to LIR and LIR to the end-user. This procedure seems somewhat similar to what I'm proposing in that ISP as direct contact with end-user first checks the request and then sends it to RIR and RIR assigns the space, the difference is that in my proposal end-user becomes client of RIR where as with RIPE's system, end-user is still a client of LIR but can change to different LIR. > APNIC does have a policy for multi-homing though I am not familiar with it. > I am sure somebody else here can provide more accurate information. APNIC person already answered confirming that they have specific policy for micro-assignments and its generally more liberal then ARIN's current proposals. > > And as far as load on the routers we have Moor's law that says that they > > would become twice as fast every two years, the grows of the routing > > table as seen at http://www.employees.org/~tbates/cidr.plot.html is a > > lot smaller and everything does indicate that routers are becoming faster > > and smarter and more capable and new technologies are also being invented > > that help to deal with more complex routing table. > > Well, routers are getting faster and smarter, but you are assuming that > routing table growth and routing table computation increase linearly with > respect to one another. I do not know enough about route computation > algorithms to say one way or another. More research is indeed needed, but so far nothing has suggested that non-linear situation exists if anything things in computing world with large databases show a different trend. But having no data on the issues does not allow use it either way in this debate. > But can multihomed joe end user afford the latest and greatest 6 and 7 > figure router? Many people are running low-end or old routers that are > being pushed to the limit. What about them? Upgrade - equipment is cheap these days. Somebody not upgrading and still being in the "stone age" should not be keeping us in the same age! New technologies are being created and if anything ARIN should encorage technological progress and not the other way around. And just on this point, the proposal would not increase size of routing table at least not to those who do not do summarization and for others not right away in any considerable amount giving them enough time (i.e. probably 2-5 years) to upgrade and take advantage of new router hardware that will be needed anyway if they want to speak ipv6 in the future. > Just so we're all on the same page, I am all for doing what is best for the > entire Internet. I realize I have mainly been arguing routing table issues > against reducing the minimum size, but that is mainly because of the fact > that there are very few people arguing those points, and I feel it is > important for both sides of an argument to be presented. So far I have not seen conclusive evidence indicating that multihoming organizations should continue to use their upstream providers's ip blocks. This in itself goes against all purpose of multihoming! > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com From ahp at hilander.com Fri Feb 28 09:38:40 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 28 Feb 2003 07:38:40 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046417920@macleod.hilander.com> --On Friday, February 28, 2003 8:27 AM -0600 Forrest wrote: > > If you get a /24 from one of your upstreams, your /24 is part of your > ISP's larger aggregate. The people arguing routing table explosion > caused by a micro allocation policy seem to take the stance that they > can filter your /24 from your ISP's aggregate and you'll be fine because > they'll still have a route to you via that aggregate. If you receive a > micro allocation they will no longer be able to filter your /24. That is precisely the point. > > If you filter my /24 from my provider's aggregate, what exactly is the > point of me multihoming? If I lose connectivity with that upstream, > you'll no longer be able to reach me because you won't hear my /24 > announcement from my other upstream. To me, it doesn't seem acceptable > to filter out multihoming /24's at all. Creating a micro allocation > policy would seem to address this issue. Create a block of addresses > that /24's won't get filtered from, while still allowing everyone to > filter out the garbage more specific /24's from elsewhere. You are forgetting that each network provider is free to decide which routes it will carry. Just because you connect to provider 'a' and provider 'b' does not mean that provider 'c' has to listen to each and every route that 'a' and 'b' carry. Now I grant that filtering more specifics of an aggregate does reduce the benefit of multi-homing, but my point is that keeping things the way they are at least gives service providers a way to keep the network running in the event that their routers can't handle the large routing table size. Wouldn't you agree that in that situation it is better to have a reduced benefit to your multi-homing than have an entire backbone shutdown? I know I know, it will never happen because of Moore's law and we have such powerful routers now. But it is precisely that type of attitude that got us in the hole in the 90s. Given history I think it is remis of us to not look very very closely at our past before making any decisions going forward. See, the major problem here is the method we are using for multi-homing. IPv4 was not desgined with this issue in mind (well perhaps it was, but certainly not with the scale issues that we have been faced with). This is why the multi6 IETF working group exists, to find an elegant way to multi-home using provider-assigned address space. Clearly we are not going to solve this problem in in the ARIN public policy working group, but people involved in this discussion may have valuable insight for the multi6 discussion. Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From forrest at almighty.c64.org Fri Feb 28 09:53:24 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 28 Feb 2003 08:53:24 -0600 (CST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046417920@macleod.hilander.com> Message-ID: On Fri, 28 Feb 2003, Alec H. Peterson wrote: > > If you filter my /24 from my provider's aggregate, what exactly is the > > point of me multihoming? If I lose connectivity with that upstream, > > you'll no longer be able to reach me because you won't hear my /24 > > announcement from my other upstream. To me, it doesn't seem acceptable > > to filter out multihoming /24's at all. Creating a micro allocation > > policy would seem to address this issue. Create a block of addresses > > that /24's won't get filtered from, while still allowing everyone to > > filter out the garbage more specific /24's from elsewhere. > > You are forgetting that each network provider is free to decide which > routes it will carry. Just because you connect to provider 'a' and > provider 'b' does not mean that provider 'c' has to listen to each and > every route that 'a' and 'b' carry. > > Now I grant that filtering more specifics of an aggregate does reduce the > benefit of multi-homing, but my point is that keeping things the way they > are at least gives service providers a way to keep the network running in > the event that their routers can't handle the large routing table size. > Wouldn't you agree that in that situation it is better to have a reduced > benefit to your multi-homing than have an entire backbone shutdown? If every backbone network filtered out my multihomed /24, how exactly would this only be a reduced benefit to my multihoming? This would be a complete waste of time for me. When packets destined for me hit a defaultless router, where do you think the packet is going to go? Toward the ISP that has the large aggregate, which I have lost connectivity with. Forrest From ahp at hilander.com Fri Feb 28 09:52:40 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 28 Feb 2003 07:52:40 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046418760@macleod.hilander.com> --On Friday, February 28, 2003 4:40 AM -0800 william at elan.net wrote: > > Are you so sure summarization is such a good thing? Multihoming is the > way to allow multiple routes to a network and to allow network to be up > through backup provider when primary one is down. Now you summarize the > routes and primary provider of some organization is down (assuming > primary is the one who has that /14 and company is using /22 out of > that) because you summarized the routes you would not be able to reach > that companies' servers. So you customers are not able to get to that > network and your competitor next door are because they do not do > summarization. Who is the winner here, your users or your competitor's > users? I'm not saying it is necessarily a 'good thing' to summarize. However, the situations where backbone providers are forced to filter the way I see it are situations where the alternative is to shutdown their entire network. Wouldn't you agree that it is important to keep a large network running in such a case, even if it degrades the multi-homing for some customers? > How am I not correct if on the same RIPE document it says "Allocations or > assignments smaller than the default size have been made to users > requesting Provider Independent (PI) IPv4 address space." (did I see /29 > there above?). Look at the blocks. Those are ancient (swamp) blocks (193/8, 194/8, 195/8). The recent ones are /20 and /19 (62/8, 80/8, 81/8, 82/8). > > And do note that by RIPE's definition and the name itself LIR (Local > Internet Registry) does not necessarily have to be an ISP, it can be > organization dedicated to subdelegating space to ISPs somewhat in a way > RIR does (so they could fragment the space in routing table, but this is > obviously discoraged). > > But to be more to the point RIPE has a procedure in place on how LIR can > do micro-assignments (they call it Provider Independent Address Space): > http://www.ripe.net/training/lir/material/slides/page103.htm > http://www.ripe.net/training/lir/material/slides/page106.htm > By that procedure LIR can request PI space on behelf of the end-user and > then RIPE assigns that space to LIR and LIR to the end-user. This > procedure seems somewhat similar to what I'm proposing in that ISP as > direct contact with end-user first checks the request and then sends it > to RIR and RIR assigns the space, the difference is that in my proposal > end-user becomes client of RIR where as with RIPE's system, end-user is > still a client of LIR but can change to different LIR. You are correct. However, the minimum block size is still /19 or /20 depending on the block. Not /24. The minimum block sizes still apply in the document I quoted. And whenever you want to use space you must get permission from RIPE (for each block). ARIN's fee structure doesn't support that type of service by ARIN, but even if it did I doubt ARIN's members would want to have to go through that level of oversight. > Upgrade - equipment is cheap these days. Somebody not upgrading and still > being in the "stone age" should not be keeping us in the same age! New > technologies are being created and if anything ARIN should encorage > technological progress and not the other way around. So now ARIN's policy proposals are forcing joe end user to upgrade their routers? If we have that power, then why don't we force people to invest development dollars to make renumbering a piece of cake? Large service providers have done it, so clearly it is possible. I realize that is a somewhat snide comment, but it was to make a point, that in these tight economic times can we really assume people have dollars to even afford a cheap upgrade? > > And just on this point, the proposal would not increase size of routing > table at least not to those who do not do summarization and for others > not right away in any considerable amount giving them enough time (i.e. > probably 2-5 years) to upgrade and take advantage of new router hardware > that will be needed anyway if they want to speak ipv6 in the future. Y2K. People will run the same old hardware and software for decades. > So far I have not seen conclusive evidence indicating that multihoming > organizations should continue to use their upstream providers's ip blocks. > This in itself goes against all purpose of multihoming! Well that is one person's opinion. I would _love_ to see more than the handful of people who have been participating in this discussion weigh in. The problem with these mailing lists is that a few people (myself easily included) can monopolize the discussion. So other people, __PLEASE__ put in your two cents. I am quite sure there are more than a half dozen people with a stake in this discussion. For my part, I've presented what I see as an under-represented side of the argument. For what it's worth I agree that being tied to one's ISP by IP space is a Bad Thing[tm], though I do maintain that setting up good procedures with one's customers and in one's systems can minimize the impact of that. I probably won't participate much any more so that other people can weigh in, since as an AC member what I really hope to get out of these discussions is what the community thinks (so far I and the rest of the AC only know what a few people think). I know everybody hates 'Me Too' posts, but in this instance (where we are trying to gauge some sort of concensus) it would actually be helpful (though perhaps a few sentences describing exactly what you think relating to these topics). Alec, who will do his best to return to lurk mode -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From ahp at hilander.com Fri Feb 28 09:56:32 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 28 Feb 2003 07:56:32 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046418992@macleod.hilander.com> --On Friday, February 28, 2003 8:53 AM -0600 Forrest wrote: > > If every backbone network filtered out my multihomed /24, how exactly > would this only be a reduced benefit to my multihoming? This would be a > complete waste of time for me. When packets destined for me hit a > defaultless router, where do you think the packet is going to go? Toward > the ISP that has the large aggregate, which I have lost connectivity with. I know exactly what would happen, and you are exactly right. But there is more to the Internet than just you and your company, and the attitude that you are only considering your needs and not the needs of the rest of the Internet is somewhat disappointing. -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From ahp at hilander.com Fri Feb 28 10:00:04 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 28 Feb 2003 08:00:04 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046418992@macleod.hilander.com> References: <2147483647.1046418992@macleod.hilander.com> Message-ID: <2147483647.1046419204@macleod.hilander.com> --On Friday, February 28, 2003 7:56 AM -0700 "Alec H. Peterson" wrote: > > I know exactly what would happen, and you are exactly right. > > But there is more to the Internet than just you and your company, and the > attitude that you are only considering your needs and not the needs of > the rest of the Internet is somewhat disappointing. That didn't come out quite right. What I meant to say is that the connectivity to your company is one part of the issue, and an important one. But we need to consider the impact that these policies would have on the entire Internet, and you are just focusing on one piece of it. I agree that it would reduce the effectiveness of your multi-homing. I am trying to point out that it is probably a bad idea to potentially sacrafice the good of the entire network so that multi-homing for a few companies will work better (assuming the whole network does not shutdown, in which case it won't work at all). Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From forrest at almighty.c64.org Fri Feb 28 10:03:42 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 28 Feb 2003 09:03:42 -0600 (CST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046418992@macleod.hilander.com> Message-ID: On Fri, 28 Feb 2003, Alec H. Peterson wrote: > --On Friday, February 28, 2003 8:53 AM -0600 Forrest > wrote: > > > > > If every backbone network filtered out my multihomed /24, how exactly > > would this only be a reduced benefit to my multihoming? This would be a > > complete waste of time for me. When packets destined for me hit a > > defaultless router, where do you think the packet is going to go? Toward > > the ISP that has the large aggregate, which I have lost connectivity with. > > I know exactly what would happen, and you are exactly right. > > But there is more to the Internet than just you and your company, and the > attitude that you are only considering your needs and not the needs of the > rest of the Internet is somewhat disappointing. > So basically what you're saying then is that to "deserve" to be multihomed and be reatchable, you must be a large company/ISP/whatever. Screw the little guy, we didn't need to talk to him anyway. Where exactly do you draw the line? Why not take it a step further and just filter out everything longer than an /8 in the old Class A space. Hey, who needs to hear your /16 announcement out of the 12.0.0.0/8 block anyway. AT&T has the entire /8 so you'll still be reachable. In fact, lets just change the minimum allocation to /8 and then we'll never have to worry about routing table growth ever again. Forrest From forrest at almighty.c64.org Fri Feb 28 10:15:02 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 28 Feb 2003 09:15:02 -0600 (CST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship Message-ID: On Fri, 28 Feb 2003, Alec H. Peterson wrote: > --On Friday, February 28, 2003 7:56 AM -0700 "Alec H. Peterson" > wrote: > > > > > I know exactly what would happen, and you are exactly right. > > > > But there is more to the Internet than just you and your company, and the > > attitude that you are only considering your needs and not the needs of > > the rest of the Internet is somewhat disappointing. > > That didn't come out quite right. > > What I meant to say is that the connectivity to your company is one part of > the issue, and an important one. But we need to consider the impact that > these policies would have on the entire Internet, and you are just focusing > on one piece of it. > I'm just focusing on one piece of it because the other pieces have already been debated over and over again. No, routing table growth isn't the only thing to take into consideration, and yes it is an important one. However, I have yet to see any studies/documentation/whatever that would indicate that giving multihomers a /24 would be the collapse of the internet as we know it. If this was truly a large concern, why isn't there more of an effort to reclaim the old swamp space, or more of an effort to force people to aggregate. I'll go back to my example of weeks ago of someone receiving an /18 allocation and announcing it as 64 individual /24's (yes, those are out there). Forrest From ahp at hilander.com Fri Feb 28 10:17:04 2003 From: ahp at hilander.com (Alec H. Peterson) Date: Fri, 28 Feb 2003 08:17:04 -0700 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <2147483647.1046420224@macleod.hilander.com> Sigh, my quest to lurk is not going well. Sorry. --On Friday, February 28, 2003 9:03 AM -0600 Forrest wrote: > > So basically what you're saying then is that to "deserve" to be > multihomed and be reatchable, you must be a large company/ISP/whatever. > Screw the little guy, we didn't need to talk to him anyway. Where > exactly do you draw the line? Why not take it a step further and just > filter out everything longer than an /8 in the old Class A space. Hey, > who needs to hear your /16 announcement out of the 12.0.0.0/8 block > anyway. AT&T has the entire /8 so you'll still be reachable. In fact, > lets just change the minimum allocation to /8 and then we'll never have > to worry about routing table growth ever again. I really hate it when people put words into my mouth. I am all for making things as easy as reasonably possible, and the current ARIN multi-homing policy I see as quite reasonable. If you can fully utilize a /21, you will be allocated a /20. Many entities have made use of it quite successfully. Perhaps we should look at modifying that policy slightly, perhaps by only requiring people to fully utilize a /22 in order to get a /20 (this is just a strawman). The 'you hate small business' argument is a popular one, because it puts whoever you are opposing on very dangerous footing with really no graceful way out. Just so everybody knows, my company is a small company, so suggesting that I am somehow against small companies is rather comical. The fact of the matter is that I pray (even though I'm agnostic) that we will never again be in a situation where we _need_ to filter route announcements on registry allocation boundaries. However, putting our heads in the sand and just hoping that it will never happen is a great way to help it happen again. I really don't want this discussion to turn into an argument. Our goal here should be to persuade those who are reading but not participating to develop an opinion such that they too can help us gain concensus one way or another. There was nothing close to concensus at the last public policy meeting, I really hope we can fix that at the next meeting, no matter which way it goes. Alec -- Alec H. Peterson -- ahp at hilander.com Chief Technology Officer Catbird Networks, http://www.catbird.com From forrest at almighty.c64.org Fri Feb 28 10:46:21 2003 From: forrest at almighty.c64.org (Forrest) Date: Fri, 28 Feb 2003 09:46:21 -0600 (CST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046420224@macleod.hilander.com> Message-ID: On Fri, 28 Feb 2003, Alec H. Peterson wrote: > --On Friday, February 28, 2003 9:03 AM -0600 Forrest > wrote: > > > > > So basically what you're saying then is that to "deserve" to be > > multihomed and be reatchable, you must be a large company/ISP/whatever. > > Screw the little guy, we didn't need to talk to him anyway. Where > > exactly do you draw the line? Why not take it a step further and just > > filter out everything longer than an /8 in the old Class A space. Hey, > > who needs to hear your /16 announcement out of the 12.0.0.0/8 block > > anyway. AT&T has the entire /8 so you'll still be reachable. In fact, > > lets just change the minimum allocation to /8 and then we'll never have > > to worry about routing table growth ever again. > > I really hate it when people put words into my mouth. > > I am all for making things as easy as reasonably possible, and the current > ARIN multi-homing policy I see as quite reasonable. If you can fully > utilize a /21, you will be allocated a /20. Many entities have made use of > it quite successfully. Perhaps we should look at modifying that policy > slightly, perhaps by only requiring people to fully utilize a /22 in order > to get a /20 (this is just a strawman). > > The 'you hate small business' argument is a popular one, because it puts > whoever you are opposing on very dangerous footing with really no graceful > way out. Just so everybody knows, my company is a small company, so > suggesting that I am somehow against small companies is rather comical. > I'm not saying you hate small business and I'm sorry I put words in your mouth, I'm definitely not looking to pick a fight on this issue. I'm just saying the current allocation policy is definitely slanted against small businesses, and most of the reasons listed in 2002-7 are valid in my opinion. I doubt giving people a /20 if they can utilize a /22 will do much of anything. I don't have any documentation to back up my argument obviously, but if some of the web hosting companies that I've seen are any indication I would guess that alot of the people receiving a /20 currently could definitely get by with a much smaller allocation, and have found "creative" ways to show utilization in order to get a portable allocation. I guess my whole beef with the routing table explosion argument is this. There's no consensus that there even would be a large explosion in the routing table if a micro allocation for multihomers policy was approved. Forrest From william at elan.net Fri Feb 28 09:11:05 2003 From: william at elan.net (william at elan.net) Date: Fri, 28 Feb 2003 06:11:05 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046418760@macleod.hilander.com> Message-ID: > > that companies' servers. So you customers are not able to get to that > > network and your competitor next door are because they do not do > > summarization. Who is the winner here, your users or your competitor's > > users? > > I'm not saying it is necessarily a 'good thing' to summarize. However, the > situations where backbone providers are forced to filter the way I see it > are situations where the alternative is to shutdown their entire network. > Wouldn't you agree that it is important to keep a large network running in > such a case, even if it degrades the multi-homing for some customers? ARIN makes it very clear when they assign the ip block that they do not guarantee routability. So provider with serious network issue would be free to filter out all the small blocks (do any do that now for swamp space?) and those who receive micro-assignments should understand that they maybe taking a risk when receiving such an ip block. It would also be up to the ISP that they contact to try to explain to them what would happen but in the end I believe its up to end-user to decide if they would benefits or not from micro-assignment and if they believe the benefit is bigger to them then the risks, there should a procedure for them to get such a miro-assignment from ARIN. > > How am I not correct if on the same RIPE document it says "Allocations or > > assignments smaller than the default size have been made to users > > requesting Provider Independent (PI) IPv4 address space." (did I see /29 > > there above?). > > Look at the blocks. Those are ancient (swamp) blocks (193/8, 194/8, > 195/8). The recent ones are /20 and /19 (62/8, 80/8, 81/8, 82/8). Some of these blocks RIPE received very recently (year ago). Also as you pointed out RIPE is very very conservative about ip assignments and allocations and I'v heard some really nasty things said about their policies and how ARIN community does not want ARIN to be like RIPE. But to the point they are conserving space and reusing the same blocks for micro-assignments especially since these blocks can hold a lot more micro-assignments then new block can hold larger allocations. I would expect the same for ARIN that they would first try to reuse old swamp space and then assign one particular /8 for micro-assignments but not use any other blocks for it. That is part of my other proposal. > > And do note that by RIPE's definition and the name itself LIR (Local > > Internet Registry) does not necessarily have to be an ISP, it can be > > organization dedicated to subdelegating space to ISPs somewhat in a way > > RIR does (so they could fragment the space in routing table, but this is > > obviously discoraged). > > > > But to be more to the point RIPE has a procedure in place on how LIR can > > do micro-assignments (they call it Provider Independent Address Space): > > http://www.ripe.net/training/lir/material/slides/page103.htm > > http://www.ripe.net/training/lir/material/slides/page106.htm > > By that procedure LIR can request PI space on behelf of the end-user and > > then RIPE assigns that space to LIR and LIR to the end-user. This > > procedure seems somewhat similar to what I'm proposing in that ISP as > > direct contact with end-user first checks the request and then sends it > > to RIR and RIR assigns the space, the difference is that in my proposal > > end-user becomes client of RIR where as with RIPE's system, end-user is > > still a client of LIR but can change to different LIR. > > You are correct. However, the minimum block size is still /19 or /20 > depending on the block. Not /24. The minimum block sizes still apply in > the document I quoted. I don't think I'm wrong and I think their minimum is even smaller then /24. Look at this document for example: http://www.ripe.net/training/lir/material/slides/page109.htm They are not making these assignments from LIR's ip blocks, they are making it out of separatly situated part of RIR space as I see it. Now at this point I believe it is necessary for somebody from RIPE to come in and clarify the issue as it was done for APNIC. > And whenever you want to use space you must get permission from RIPE (for > each block). ARIN's fee structure doesn't support that type of service by > ARIN, but even if it did I doubt ARIN's members would want to have to go > through that level of oversight. ARIN's fee structure must be changed to accomodate smaller block assignments and allocations. I'v directly added necessity for new fee schedule in the draft of proposal and even said that policy can not be used until new fee structure is approved. I also argued that new fee strucuture is necessary to accomodate for example micro-allocations and smaller blocks that may become as a result of use of 2002-5 and 2002-6 proposals. > > Upgrade - equipment is cheap these days. Somebody not upgrading and still > > being in the "stone age" should not be keeping us in the same age! New > > technologies are being created and if anything ARIN should encorage > > technological progress and not the other way around. > > So now ARIN's policy proposals are forcing joe end user to upgrade their > routers? If we have that power, then why don't we force people to invest > development dollars to make renumbering a piece of cake? We're investing in this in development of ipv6 which in fact probably cost millions if not billions to companies but have not produced any profit. > I realize that is a somewhat snide comment, but it was to make a point, > that in these tight economic times can we really assume people have dollars > to even afford a cheap upgrade? Down the road road they will have to look into upgrades for many other reasons or if they can not afford it what makes you think they should continue to be multihomed and not just getting default route from their upstreams. Being multihomed and getting entire routing table is not "cheap" and not everybody can afford it and should do it but for those who do we should provide a way to make it worth it with their own ip blocks. > > So far I have not seen conclusive evidence indicating that multihoming > > organizations should continue to use their upstream providers's ip blocks. > > This in itself goes against all purpose of multihoming! > > Well that is one person's opinion. That is hardly my own opinion. The person from Worldcom has made the argument yesterday about how separate network should be tied to ASN and so did Stacy Taylor from ICG and she's also on AC and in fact she's been working with some others on more standard and more liberal approach to micro-assignments as successor to 2002-3 and 2002-7. They are also several others arguing on the same issue with you all representing this multi-homing "opinion". You may not realize it but I'v received emails from people who believe I'm too conservative with my proposal and they do not want any ISP involvement and should be completely free to do what they want and everybody should have their own micro-block. I'm actually trying to find middle ground between different positions. > I would _love_ to see more than the > handful of people who have been participating in this discussion weigh in. > The problem with these mailing lists is that a few people (myself easily > included) can monopolize the discussion. And I hope you do not take it personally, especially since previously you'v been very fair and argued generally for development of micro-assignment proposals, but I do think this list is intended for those outside of AC and BoT to make their arguments and then AC and BoT should base their decisions based on arguments presented and not directly on their own opinion. I do appreciate you making the argument for the other side, but I'd like to see somebody else do it too, because otherwise it does seem that my side has upper hand which may or may not be the case, though I do think (taking ARIN member meetings aside, which are populated by large ISPs) the general ARIN community is for multihoming and micro-assignments in such a large way that overwhelming majority would have supported previous 2002-3 and 2002-7 proposals if given a chance to vote on it. One thing to note that point of any debate is not necessarily to win over the other side, which is sometimes impossible (and often is not an issue since good debater can take any position and argue it successfully if there is some ground to stand on) but rather to explain the arguments and supporting documentation in detail which we have done quite well so far. It is for larger group that is listening to a debate to decide based on presented points which side is more correct. > Alec, who will do his best to return to lurk mode I certainly have problems going back to lurk mode and I doubt you can either.... Though it would really be at this point to allow others to say what they think about arguments that have been presented. > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > -- William Leibzon Elan Communications william at elan.net From william at elan.net Fri Feb 28 09:57:58 2003 From: william at elan.net (william at elan.net) Date: Fri, 28 Feb 2003 06:57:58 -0800 (PST) Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: <2147483647.1046420224@macleod.hilander.com> Message-ID: > ARIN multi-homing policy I see as quite reasonable. If you can fully > utilize a /21, you will be allocated a /20. Many entities have made use of > it quite successfully. Perhaps we should look at modifying that policy > slightly, perhaps by only requiring people to fully utilize a /22 in order > to get a /20 (this is just a strawman). Why not just give /21 for /22 or /22 for /23? And do you really expect less companies to get allocations of the size they really need if you decrease requirement to /22 justification? I'd bet more would apply and qualify, maybe less would lie about it but if they did before, they could then too and it would just make it easier to get /20 for them. > Our goal here should be to persuade those who are reading but > not participating to develop an opinion such that they too can help us gain > concensus one way or another. I agree with you completely. And by arguing on the list we maybe able to get people on the list to agree to one side or the other. But there does not exit any way right now, that ARIN would agree to, that would provide for a way to check if the majority on the list support one side, especially considering that many do not like to actively partipate and just listen. The best way to even try would be to allow polls of list members to be conducted (obviously only of those who have listened to the argument from the start). > There was nothing close to concensus at the > last public policy meeting, I really hope we can fix that at the next > meeting, no matter which way it goes. When confronted about it arin BoT admitted that they are required to make decisions based on opinions represented on this list rather then what can be seen on ARIN meeting. While I do not believe they can do it even if when they try (which I'm sure they are), I do think taking an argument that ARIN meeting makes it possible to establish a concensus on this issue is wrong, especially when taking into account that: 1. Almost all attending meeting already have an ip block and this is not a "hot" issue for them 2. Eventhough out of ARIN's members 80-90% are small ISPs, out of companies represented on ARIN meeting < 5% are small ISPs. The best we can hope to do is get 50% of large ISPs represented in the meeting to support such a proposal, if they do I dare say that would represented a concensus for ARIN community since majority of small ISPs support the proposal and overwhelming majority of others who are not members or ARIN but should still be counted as part of the decision on any policy made for ARIN region support this as well. > Alec > > -- > Alec H. Peterson -- ahp at hilander.com > Chief Technology Officer > Catbird Networks, http://www.catbird.com > From memsvcs at arin.net Fri Feb 28 12:08:01 2003 From: memsvcs at arin.net (Member Services) Date: Fri, 28 Feb 2003 12:08:01 -0500 (EST) Subject: [ppml] Register Now for ARIN XI Public Policy Meeting Message-ID: Just a reminder, April is right around the corner! If you haven't registered for ARIN XI in Memphis, it's time to get involved. Be a part of all the current policy discussions, as well as the IPv6 Mini-Workshop. The Peabody Memphis has a limited number of rooms reserved for our meeting. These rooms are being held until Friday, March 14th, so book now by calling the Peabody Memphis at 1-800-PEABODY. To register for ARIN XI, please visit our website: http://www.arin.net/ARIN-XI/index.html ARIN graciously thanks NASA for sponsoring the wireless network in Memphis for ARIN XI. As part of their sponsorship, NASA will be supplying the network connectivity, and will also be setting up and managing the wireless network. We are still accepting sponsorship offers for the terminal room, continental breakfasts and lunches during the meeting, as well as our Foosball tournament and social event! For more information about the meeting as well as sponsorship opportunities, contact Edward Pizzarello, ARIN Event Coordinator, at (703) 227-9878 or memsvcs at arin.net. ARIN Member Services From billd at cait.wustl.edu Fri Feb 28 12:28:03 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 28 Feb 2003 11:28:03 -0600 Subject: [ppml] What do we do with 2002-6? Message-ID: The wordings (far) below represent the original and a proposed re-wording of the 2002-6 Policy Proposal: Aggregation Requests The spirit of this proposal I believe to be associate with eliminating separate blocks under the control of a single authority to provide for better address aggregation and address allocation efficiencies. Objections to this policy proposal range from... it solves a problem no one is concerned with, it will be used to 'launder' tainted blocks......... Questions have been asked about the 'scope of the problem' and the likihood that this proposal will find a sympathetic audience.... In other words, will people be motivated to act under this policy in sufficient numbers to warrant such a process. Others who think the proposal is worthwhile take issue with the time allotted for renumbering... with a range being addressed in the reworded alternative. Still others were concerned about the block sizes to be aggregated may scale to a size that allowed the 'next bit' to represent an 'un-justified give-away' of address space..... that is... if one returns 3 /24s they will get a /22........ the equivalent of 4 /24s......... as the block sizes increase in this scenario, the give-away gets more onerous......As such, 'justification' of the blocks size to be distributed comes under discussion........ Justification almost always leads to the red-herring of ARIN doing address reclamation............. At this point in the discuission someone again brings up the question of whether this proposal is worth pursuing..... I am now bringing this very question back to the ppml............. what's your suggestion?...... word smith the existing proposal and bring it back to ARIN XI in Memphis (please offer suggested verbage)?.... drop the proposal altogether?...... some other alternative that you would like to propose? Original.... If an organization, whether a member or non-member, ISP or end-user, relinquishes a group of portable, non-aggregatable address blocks to ARIN, they shall be allowed to receive a block in exchange, /24 or shorter, but no more than the shortest block that could contain all of the returned blocks. Exchanged space shall be returned within 12 months. For example, if an organization relinquished three /24s, they should be allowed to take either a /24, a /23, or a /22 in exchange. If all of the previous address blocks were maintained in the ARIN database without maintenance fees, the replacement space shall be as well, but if any one of the returned blocks had associated maintenance fees, then the replacement block shall also be subject to maintenance fees. Proposed rewording.... If any organization relinquishes a group of portable, non-aggregatable address blocks to ARIN, they shall receive a block in exchange. Exchange blocks will be of sufficient size to contain the space of all returned blocks without justification up to /17. Exchange blocks of greater than /17 will require justification of address useage per existing ARIN requirements for addtional address allocations. Exchange blocks larger than /20 must be renumbered within 12 months; all others must be renumbered within 6 months. If ALL returned blocks were maintained by ARIN without maintenance fees, the exchange block will also be maintained without fee. Other alternatives? Bill Darte ARIN Advisory Council From woody at pch.net Fri Feb 28 12:21:06 2003 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Feb 2003 09:21:06 -0800 (PST) Subject: [ppml] What do we do with 2002-6? In-Reply-To: Message-ID: > I am now bringing this very question back to the ppml............. what's > your suggestion?...... word smith the existing proposal and bring it back to > ARIN XI in Memphis (please offer suggested verbage)?.... drop the proposal > altogether?...... some other alternative that you would like to propose? I would point out that this proposal received essentially unanimous support in the last member meeting, and although this isn't a popular place to point it out, the opinions of a very small number of people on the list shouldn't outweigh the order of magnitude more people who approved it at the meeting. Again, the point of this proposal is to create uniform policy between RIRs, and discourage RIR-shopping. -Bill From william at elan.net Fri Feb 28 10:45:00 2003 From: william at elan.net (william at elan.net) Date: Fri, 28 Feb 2003 07:45:00 -0800 (PST) Subject: [ppml] What do we do with 2002-6? In-Reply-To: Message-ID: I'm curious if you could explain this part a little more, I actually do not see how that proposal has anything do do with "RIR-shopping" and in fact how that is at all possible when geographical regions are clearly defined. > Again, the point of this proposal is to create uniform policy between > RIRs, and discourage RIR-shopping. > > -Bill > From woody at pch.net Fri Feb 28 12:42:32 2003 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Feb 2003 09:42:32 -0800 (PST) Subject: [ppml] What do we do with 2002-6? In-Reply-To: Message-ID: > I'm curious if you could explain this part a little more, I actually do > not see how that proposal has anything do do with "RIR-shopping" and in > fact how that is at all possible when geographical regions are clearly > defined. It's quite a common practice. Anyone who's present in multiple regions can choose which policy they feel like using on which occasions, as best suits their needs at that moment. There's a general desire among the registries to discourage this practice, for a wide range of reasons, and the best way of discouraging it is through cleaning up pointless discrepancies between RIR policies. Of which this is an example. I don't particularly care about this issue, per se, the point of the motion was to bring ARIN into line so as to avoid pushing ARIN members to shop the other RIR's policies. -Bill From william at elan.net Fri Feb 28 11:01:02 2003 From: william at elan.net (william at elan.net) Date: Fri, 28 Feb 2003 08:01:02 -0800 (PST) Subject: [ppml] What do we do with 2002-6? In-Reply-To: Message-ID: Perhaps it would then be usefull if you point to policies of other RIRs that are similar to 2002-6 so we could make a comparison. Also if what you're saying is true about RIR-shopping (I personally always believed that company is required to obtain space from multiple RIRs if it has networks that goes into multiple geographical regions) and there is a desire to bring conformity of policies to RIRs this would seem to help in the argument for micro-assignments... I actually do not much see it this way, I think RIRs should be free to do as they are in their regions and only rough agreement that is represented by RFCs and BCPs (such as RFC2050) should be maintained. On Fri, 28 Feb 2003, Bill Woodcock wrote: > > I'm curious if you could explain this part a little more, I actually do > > not see how that proposal has anything do do with "RIR-shopping" and in > > fact how that is at all possible when geographical regions are clearly > > defined. > > It's quite a common practice. Anyone who's present in multiple regions > can choose which policy they feel like using on which occasions, as best > suits their needs at that moment. There's a general desire among the > registries to discourage this practice, for a wide range of reasons, and > the best way of discouraging it is through cleaning up pointless > discrepancies between RIR policies. Of which this is an example. I don't > particularly care about this issue, per se, the point of the motion was to > bring ARIN into line so as to avoid pushing ARIN members to shop the other > RIR's policies. > > -Bill > From billd at cait.wustl.edu Fri Feb 28 13:53:24 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 28 Feb 2003 12:53:24 -0600 Subject: [ppml] What do we do with 2002-6? Message-ID: Thank you for that information, Bill.... really. I too recall that this was a popular proposal on its face, but the final call produced all of the items I referenced as objections and questions and suggestions...and more. You reference these as a very small number of people on the list, but where is all the advocacy from the meeting to ovecome the objections raise? I assume by your comments that you are not in favor of option 2 of my email....that is, to drop the proposal, but I cannot determine whether you are in favor of word smithing the existing policy statements that where enclosed or have an alternative. I suggested then, and do so again....if you or anyone has a proposal to support one or more of the wordings that exist or suggest some alternate wording please forward it to the list. If you would like to propose something altogether alternative, that would be good too. We have had lots of discussion beginning before ARIN X and we need to move this along or let it die. I am merely sheparding this proposal as is my charge through the AC. Bill Darte ARIN Advisory Council > -----Original Message----- > From: Bill Woodcock [mailto:woody at pch.net] > Sent: Friday, February 28, 2003 11:21 AM > To: Bill Darte > Cc: ppml at arin.net > Subject: Re: [ppml] What do we do with 2002-6? > > > > I am now bringing this very question back to the > ppml............. what's > > your suggestion?...... word smith the existing proposal > and bring it back to > > ARIN XI in Memphis (please offer suggested > verbage)?.... drop the proposal > > altogether?...... some other alternative that you would > like to propose? > > I would point out that this proposal received essentially unanimous > support in the last member meeting, and although this isn't a popular > place to point it out, the opinions of a very small number of > people on > the list shouldn't outweigh the order of magnitude more people who > approved it at the meeting. > > Again, the point of this proposal is to create uniform policy between > RIRs, and discourage RIR-shopping. > > -Bill > > From woody at pch.net Fri Feb 28 13:49:16 2003 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Feb 2003 10:49:16 -0800 (PST) Subject: [ppml] What do we do with 2002-6? In-Reply-To: Message-ID: > I assume by your comments that you are not in favor of option 2 of my > email....that is, to drop the proposal, but > I cannot determine whether you are in favor of word smithing the existing > policy statements that where enclosed or have an alternative. Changing the wording just causes it to diverge from the other RIR's policy, which defeats the entire purpose. Obviously the population of this list is significantly different, smaller, and more contentious than the attendees at the member meeting. Asking why everyone who attends the meetings doesn't have the patience to put up with the list seems to beg an obvious answer. The fact that a few people continue to have objections which were raised and dealt with to the satisfaction of the membership at the meeting doesn't seem terribly pertinent to me. -Bill From ron at aol.net Fri Feb 28 13:46:36 2003 From: ron at aol.net (Ron da Silva) Date: Fri, 28 Feb 2003 13:46:36 -0500 Subject: [ppml] What do we do with 2002-6? In-Reply-To: References: Message-ID: <20030228184636.GB29457@aol.net> William - You can shop for an RIR. There is nothing indicating that you may only obtain services from a particular RIR, regardless of your geography. That said, most folks simply develop a relationship with the RIR based in their region for a variety of other reasons. -ron From ron at aol.net Fri Feb 28 13:48:00 2003 From: ron at aol.net (Ron da Silva) Date: Fri, 28 Feb 2003 13:48:00 -0500 Subject: [ppml] What do we do with 2002-6? In-Reply-To: References: Message-ID: <20030228184800.GC29457@aol.net> Darte - I like the re-wording and would also welcome similar changes. -ron /AOL From marla_azinger at eli.net Fri Feb 28 13:57:35 2003 From: marla_azinger at eli.net (Marla Azinger) Date: Fri, 28 Feb 2003 10:57:35 -0800 Subject: [ppml] Draft 2 of proposal for ip assignmentwith sponsorship Message-ID: <000201c2df5b$4276b8d0$770d1bac@eli.czn.com> ok..I'm going to be short and to the point here... If all I have to do is admit we multihome with someone...then fine. However, some of the prior suggestions to this proposal appear to be adding on resposibility and work to the "upstream providers" with the word "sponsorship". I dont want to support anything that creates unnecessary "upstream provider" paperwork, followups and downtime. I have enough keeping me buisy with all the current sensible/practical policies. Marla ******************** The point is to have a way to issue microallocations only to multihomed orgs with a process that allows the ISPs to have a defined procedure for working with ARIN on it and preserves the integrity of the system. By requiring an ORG that wants a microallocation to have two ISP sponsors, ARIN can guarantee that the ORG is multihomed. The ISPs that sponsor it are saying that they are providing connectivity to the ORG. I don't see where this is much more of a headache to an ISP than having a multihomed customer in the first place. However, any ISP would certainly be free to decline business and refuse to sponsore ORGs that wanted to pay them to provide transit to their multihomed network. Owen --On Thursday, February 27, 2003 8:44 AM -0800 Marla Azinger wrote: > Hello- I know I've missed alot of the discussion between the last > conference and up to this point...so please bear with me and the question > I have... > > Why is it necessary for an ISP to "sponsor" this? So far...sponsorship > sounds like more of a headache than anything...I'm sure I'm missing > something because up to this point...I would just say my company isnt > going to participate in order to avoid...basically...all of it...we'v > done fine without this until now... > > I guess what I'm missing here is...how is a smaller telecom company that > provides internet access supposed to benefit from "sponsoring" this? Is > there a benefit...or is this a bandaid for integrity issues? I'm sure > there's a good list of reasons I'm missing...like I said I've missed most > of the discussion up to this point...but could someone provide a short > and to the point list of how we'd benefit from "sponsoring" this? > > Thank you for your patience and time > Marla > ELI IP Analyst > > > > > I would rather not see this language. The policy states that ISP A or ISP > B must inform ARIN > when this happens. I know we can't depend on this to work, but if we build > in a backup, why even > ask ISP A or ISP B to inform ARIN of this change? > > Jim >> >> I think some sort of language saying that ARIN will do audits of the >> assignments from time to time is needed. Or perhaps when you >> pay your >> annual renewal fee, you should have to provide proof along >> with it that >> you are still connected to more than 1 upstream. Basically >> something that >> will prevent someone from being multihomed today, get a micro >> assignment, >> and then drop their second provider while keeping their micro >> assignment. >> >> Forrest >> >> On Wed, 26 Feb 2003 william at elan.net wrote: >> >> > >> > I'v made a 2nd draft for proposal for ip micro-assignment >> with sponsorship. >> > It does not format well to be posted in the email as text >> but you can >> > review it online at: >> > >> > >> http://www.elan.net/~william/arin_proposal_for_micro_assignmen >> ts_with_sponsorship.htm >> > >> > If you have any futher suggestions please feel free to >> email me or otherwise >> > discuss it on this list. If there are no suggestions for >> addition to the >> > current text, this will be the proposal I will send to >> Richard Jimmerson >> > end of this week. >> > >> > ---- >> > William Leibzon >> > Elan Communications >> > william at elan.net >> > >> >> >> >> >> > From jsw at five-elements.com Fri Feb 28 14:01:14 2003 From: jsw at five-elements.com (Jeff S Wheeler) Date: 28 Feb 2003 14:01:14 -0500 Subject: [ppml] Draft 2 of proposal for ip assignment with sponsorship In-Reply-To: References: Message-ID: <1046458874.1040.88.camel@intrepid> On Fri, 2003-02-28 at 09:11, william at elan.net wrote: > ARIN makes it very clear when they assign the ip block that they do not > guarantee routability. So provider with serious network issue would be > free to filter out all the small blocks (do any do that now for swamp > space?) and those who receive micro-assignments should understand that > they maybe taking a risk when receiving such an ip block. It would also be Indeed, the ARIN web site and other materials discourage users from applying for provider-independent space because it may not be globally routable, and quite obviously the best way to get globally reachable space is to request it from your transitors. However, the current filtering policies in use by carriers are there today primarily to manage clueless/abusive route table growth, rather than to impact allocation policy to end-users and small organizations who are not multihomed, as was necessary and prudent in the mid-ninties. I do not want to bash Verio, but I will use their policy of filtering out /24s from non-swamp space as an example. If you hop onto your nearest router that carries a full view from a carrier who does not filter /24s in, say, 69/8 (or route-views.oregon-ix.net), you will find that there are a number of organizations who were allocated space by the ARIN recently, and who are cluelessly advertising both aggregates and many de-aggregates. One group advertises both a /20, and every possible de-aggregate /24 as well as others within that recently allocated /20. Clearly, the maximum allocation length does not necessarily constrain global route table growth. Provider filtering will, and I believe that if a responsible micro-allocation policy is implemented in seperate, well-defined space (e.g. a /8 or perhaps longer), that will only lend additional credibility to the ISPs who choose to filter on RIR maximum allocation length boundaries, or drop /24s as Verio does, etc. I believe a working reclaimation and reissue plan must be utilized in this new space, if it is to exist, such that members who are allocated a /24 - /21 and later grow into a /20 or shorter are able and encouraged to renumber out of the micro-allocation space, which may be reissued. I do not believe that a new swamp is a good use of a valuable /8, however if old swamp is reissued (and believe me, there are huge gaps in the old swamp which can be reused) that may wholely satisfy the needs of future applicants for multi-homer /24s. I additionally suggest that if new IANA space, or ARIN space in the old Class B region, is utilized for micro-allocations to multi-homers, that the space be segregated by allocation-length, such that if I, as a small ISP, am granted a /22, it will be in a region of the IP space such that ARIN has published its maximum allocation-length to be /22. I don't need to be polluting the route table with de-aggregates, and this once more lends credibility to ISPs who filter on maximum allocation-length in order to keep their route tables managable. -- Jeff S Wheeler From billd at cait.wustl.edu Fri Feb 28 14:13:04 2003 From: billd at cait.wustl.edu (Bill Darte) Date: Fri, 28 Feb 2003 13:13:04 -0600 Subject: [ppml] What do we do with 2002-6? Message-ID: Begging the obvious answer.... I assume that you choose to leave the wording as is? And, It seems to me that crafting any policy in the ARIN region solely to be consistent with the other RIRs is not precisely the objective....and that when objections to the wording of this policy suggest shortcomings to the implementation or support of it, or subversive use of the policy beyond its design are worthy of discussion. Objecting to that discussion or the numbers or character of those discussing a policy is not pertinent to the policy at hand and falls into the realm of how policies are proposed and ratified. As I am intimately involved in that process, I welcome your suggestions on how to improve this process at all stages, in the meeting and on the list, in private or in public. Bill Darte ARIN Advisory Council > -----Original Message----- > From: Bill Woodcock [mailto:woody at pch.net] > Sent: Friday, February 28, 2003 12:49 PM > To: Bill Darte > Cc: ppml at arin.net > Subject: RE: [ppml] What do we do with 2002-6? > > > > I assume by your comments that you are not in favor of > option 2 of my > > email....that is, to drop the proposal, but > > I cannot determine whether you are in favor of word > smithing the existing > > policy statements that where enclosed or have an alternative. > > Changing the wording just causes it to diverge from the other RIR's > policy, which defeats the entire purpose. > > Obviously the population of this list is significantly > different, smaller, > and more contentious than the attendees at the member > meeting. Asking why > everyone who attends the meetings doesn't have the patience > to put up with > the list seems to beg an obvious answer. > > The fact that a few people continue to have objections which > were raised > and dealt with to the satisfaction of the membership at the meeting > doesn't seem terribly pertinent to me. > > -Bill > > From woody at pch.net Fri Feb 28 14:14:07 2003 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Feb 2003 11:14:07 -0800 (PST) Subject: [ppml] What do we do with 2002-6? In-Reply-To: Message-ID: > I assume that you choose to leave the wording as is? Yes. > It seems to me that crafting any policy in the ARIN region solely > to be consistent with the other RIRs is not precisely the objective. Had the policy been crafted in the ARIN region, it could not have been, by definition, consistent with that of the other RIRs. The objective (of the management of all three RIRs, on whose behalf I brought the motion, of myself because it seems sensible, and I presume of the rest of the ARIN board) is to make policy uniform wherever possible. Taking an existing policy and changing it just makes the discrepancy worse, not better. > when objections to the wording of this policy suggest shortcomings to the > implementation or support of it, or subversive use of the policy beyond its > design are worthy of discussion. Quite possibly, but if so, the ARIN policy list certainly isn't the place for it. We just wrapped up the APNIC meeting today, and I didn't hear anyone suggesting the policy needed rewording. If the policy needed to be reworded, this was where someone should have mentioned it, since this is where it can be changed. > I welcome your suggestions on how to improve this process at all > stages, in the meeting and on the list, in private or in public. I suggest that gratuitous changes by a small and opinionated group, to things which have already been discussed and ratified in the light of day by the full members' meeting is a bad process, and wastes the time of everyone involved, as well as producing policy which fails to represent the consensus of the group. -Bill From ron at aol.net Fri Feb 28 14:22:21 2003 From: ron at aol.net (Ron da Silva) Date: Fri, 28 Feb 2003 14:22:21 -0500 Subject: [ppml] Re: common policy across RIRs In-Reply-To: References: Message-ID: <20030228192221.GD29457@aol.net> Woodcock - Interesting. If we are looking to craft policies that are uniform across RIRs, would it be best to have a forum to discuss them jointly? That is, a policy that is worded by consensus in APNIC might not necessarily capture concerns by ARIN. I don't think we have a joint RIR ppml list to discuss common policy...but it might be useful. Hmmm...? -ron From woody at pch.net Fri Feb 28 14:30:25 2003 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Feb 2003 11:30:25 -0800 (PST) Subject: [ppml] Re: common policy across RIRs In-Reply-To: <20030228192221.GD29457@aol.net> Message-ID: > Woodcock - Interesting. If we are looking to craft policies that > are uniform across RIRs, would it be best to have a forum to discuss > them jointly? That is, a policy that is worded by consensus in APNIC > might not necessarily capture concerns by ARIN. I don't think we > have a joint RIR ppml list to discuss common policy...but it might > be useful. Hmmm...? We do have a process, but it's the meetings, not the lists. When we have new policies, we submit them before all three meetings, and edit until they're acceptable. Or, we get them through one RIR, and hope the other three will follow. Or, as in this case, we take preexisting differences, and try to make them uniform after-the-fact. This is clean-up. Not an attempt to do something new. -Bill From John.Sweeting at teleglobe.com Fri Feb 28 14:58:35 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Fri, 28 Feb 2003 14:58:35 -0500 Subject: [ppml] What do we do with 2002-6? Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BED2@usresms03.teleglobe.com> Bill W., Last call on the mailing list is there to give people that were unable to attend the meeting to let their opinions be heard...that being said there was a significant amount of traffic reference this policy with much of it pertaining to what the public felt were loopholes that could lead to abuse. Bill D.'s wordsmithing,along with Richard J's assurances that legacy address space is normally not reissued and other returned space is kept out of circulation for at least a year, seems to address all the concerns and recommendations that were received. So I guess my question is does the rewording of the policy make that much difference in regards to the other RIR's? My personal feelings are that trying to have common policies is a good thing, reasoning tells me that there will have to be some differences to account for the difference point of views held by the potential users of each RIR. -----Original Message----- From: Bill Woodcock [mailto:woody at pch.net] Sent: Friday, February 28, 2003 2:14 PM To: Bill Darte Cc: ppml at arin.net Subject: RE: [ppml] What do we do with 2002-6? > I assume that you choose to leave the wording as is? Yes. > It seems to me that crafting any policy in the ARIN region solely > to be consistent with the other RIRs is not precisely the objective. Had the policy been crafted in the ARIN region, it could not have been, by definition, consistent with that of the other RIRs. The objective (of the management of all three RIRs, on whose behalf I brought the motion, of myself because it seems sensible, and I presume of the rest of the ARIN board) is to make policy uniform wherever possible. Taking an existing policy and changing it just makes the discrepancy worse, not better. > when objections to the wording of this policy suggest shortcomings to the > implementation or support of it, or subversive use of the policy beyond its > design are worthy of discussion. Quite possibly, but if so, the ARIN policy list certainly isn't the place for it. We just wrapped up the APNIC meeting today, and I didn't hear anyone suggesting the policy needed rewording. If the policy needed to be reworded, this was where someone should have mentioned it, since this is where it can be changed. > I welcome your suggestions on how to improve this process at all > stages, in the meeting and on the list, in private or in public. I suggest that gratuitous changes by a small and opinionated group, to things which have already been discussed and ratified in the light of day by the full members' meeting is a bad process, and wastes the time of everyone involved, as well as producing policy which fails to represent the consensus of the group. -Bill From woody at pch.net Fri Feb 28 15:18:50 2003 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Feb 2003 12:18:50 -0800 (PST) Subject: [ppml] What do we do with 2002-6? In-Reply-To: <170E5E7779BCD3118C2A0008C7F40C1906E9BED2@usresms03.teleglobe.com> Message-ID: > Last call on the mailing list is there to give people that were unable to > attend the meeting to let their opinions be heard. Great in theory, except that's not how you folks are using the list. A very small number of people on the list, nearly all of whom were also at the meeting, are using it, in relative privacy, to countermand the decisions of the majority, which were discussed and made publicly, in the meeting. I find that really annoying. I wouldn't care if it weren't making extra work for me, when I already have plenty on my plate. > that being said there > was a significant amount of traffic reference this policy with much of it > pertaining to what the public felt were loopholes that could lead to abuse. What the public felt we heard and addressed in the meeting. I encourage you to compare the numbers. We also heard that there had never, in the entire history of the policy, been a case of abuse or even attempted abuse. So we've wasted hours and hours and hours in mangling an already-over-long policy still further, _for the possibility_ of preventing _hypothetical future waste of a few minutes of hostmaster time_. > my question is does the rewording of the policy make that much > difference in regards to the other RIRs? Of course not... This re-wording makes it somewhat more cumbersome and awkward than the existing policy, but no sane person could possibly care about it at this level of detail. The problem isn't what the words say, but that if people go and try to change the words in teh wrong forum like this, it _triples the amount of work I have to do_. I didn't sign up to do this three times, I signed up to do it once. And if people on the list make a habit of screwing up the process like this, it's going to make it impossible to find anyone to do the work at all, in the future. I know it's going to take a lot more pursuading to get me to take it on again next time. The pool of non-staff multi-region members isn't that big, and many have even less time for this kind of nonsense than I do. -Bill From John.Sweeting at teleglobe.com Fri Feb 28 16:51:07 2003 From: John.Sweeting at teleglobe.com (Sweeting, John) Date: Fri, 28 Feb 2003 16:51:07 -0500 Subject: [ppml] What do we do with 2002-6? Message-ID: <170E5E7779BCD3118C2A0008C7F40C1906E9BEDC@usresms03.teleglobe.com> > -----Original Message----- > From: Bill Woodcock [mailto:woody at pch.net] > Sent: Friday, February 28, 2003 3:19 PM > To: Sweeting, John > Cc: Bill Darte; ppml at arin.net > Subject: RE: [ppml] What do we do with 2002-6? > > > > Last call on the mailing list is there to give people > that were unable to > > attend the meeting to let their opinions be heard. > > Great in theory, except that's not how you folks are using the list. > A very small number of people on the list, nearly all of whom > were also at > the meeting, are using it, in relative privacy, to countermand the > decisions of the majority, which were discussed and made > publicly, in the > meeting. I find that really annoying. I wouldn't care if it weren't > making extra work for me, when I already have plenty on my plate. I agree with you totally on this point. Hopefully, we will get relief with the new Policy Evaluation Process but I am not sure about that. > > > that being said there > > was a significant amount of traffic reference this > policy with much of it > > pertaining to what the public felt were loopholes that > could lead to abuse. > > What the public felt we heard and addressed in the meeting. > I encourage > you to compare the numbers. > > We also heard that there had never, in the entire history of > the policy, > been a case of abuse or even attempted abuse. So we've > wasted hours and > hours and hours in mangling an already-over-long policy still further, > _for the possibility_ of preventing _hypothetical future waste of a > few minutes of hostmaster time_. Again, I agree with you. > > > my question is does the rewording of the policy make that much > > difference in regards to the other RIRs? > > Of course not... This re-wording makes it somewhat more > cumbersome and > awkward than the existing policy, but no sane person could > possibly care > about it at this level of detail. The problem isn't what the > words say, > but that if people go and try to change the words in teh > wrong forum like > this, it _triples the amount of work I have to do_. I didn't > sign up to > do this three times, I signed up to do it once. And if > people on the list > make a habit of screwing up the process like this, it's going > to make it > impossible to find anyone to do the work at all, in the > future. I know > it's going to take a lot more pursuading to get me to take it on again > next time. The pool of non-staff multi-region members isn't > that big, and > many have even less time for this kind of nonsense than I do. I understand, at this time I am trying to reach a compromise so the time spent on this can be minimized to that already spent. Thanks. > > -Bill > > From jmcburnett at msmgmt.com Fri Feb 28 22:14:46 2003 From: jmcburnett at msmgmt.com (McBurnett, Jim) Date: Fri, 28 Feb 2003 22:14:46 -0500 Subject: [ppml] RIR shopping??? Message-ID: <390E55B947E7C848898AEBB9E507706041E398@msmdcfs01.msmgmt.com> Wait a min.. If I understand you right: If I disagree with the MicroAllocation policy as it exists with ARIN and I want a CLASS C from APNIC or RIR, All I have to do is ask APNIC or RIR? Even if I am in North America? If that is the case, then why are we so picky over some of the parts of 2002-7? Jim > -----Original Message----- > From: Ron da Silva [mailto:ron at aol.net] > Sent: Friday, February 28, 2003 1:47 PM > To: ppml at arin.net > Subject: Re: [ppml] What do we do with 2002-6? > > > > William - You can shop for an RIR. There is nothing indicating that > you may only obtain services from a particular RIR, regardless of > your geography. That said, most folks simply develop a relationship > with the RIR based in their region for a variety of other reasons. > > -ron > From woody at pch.net Fri Feb 28 23:26:30 2003 From: woody at pch.net (Bill Woodcock) Date: Fri, 28 Feb 2003 20:26:30 -0800 (PST) Subject: [ppml] RIR shopping??? In-Reply-To: <390E55B947E7C848898AEBB9E507706041E398@msmdcfs01.msmgmt.com> Message-ID: > If I disagree with the MicroAllocation policy as it exists with ARIN and I want > a CLASS C from APNIC or RIR, All I have to do is ask APNIC or RIR? > Even if I am in North America? Sure, if you're an APNIC or RIPE member, or qualify under one of the policies which applies to non-members. You might want to get an in-region P.O. box or use a local office, but that's what people do, yes. > If that is the case, then why are we so picky over some of the parts of 2002-7? That's what I've been asking. -Bill