From rbush at bainbridge.verio.net Sun Jun 4 18:56:40 2000 From: rbush at bainbridge.verio.net (Randy Bush) Date: Sun, 04 Jun 2000 15:56:40 -0700 Subject: split b Message-ID: this seems to be missing from the documentation of allocation policy, or i am even more confused than usual. randy rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 Cable & Wireless USA (NETBLK-CW-NETCS) 9000 Regency Parkway, Suite 200 Cary, NC 27511 US Netname: CW-NETCS20 Netblock: 166.49.0.0 - 166.49.127.255 Coordinator: Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net 919-465-4160 Fax- 919-465-4187 Domain System inverse mapping provided by: NS.CW.NET 204.70.128.1 NS2.CW.NET 204.70.57.242 NS3.CW.NET 204.70.25.234 NS4.CW.NET 204.70.49.234 Record last updated on 16-Sep-1999. Database last updated on 2-Jun-2000 17:47:08 EDT. rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 Concert Communications Co. (NETBLK-CONCERTCOMM) 81 Newgate Street London, EC1A 7AJ GB Netname: CONCERTCOMM Netblock: 166.49.128.0 - 166.49.255.255 Coordinator: Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET +31 20 487 6584 (FAX) +31 20 487 6307 Domain System inverse mapping provided by: NS2.EU.CONCERT.NET 195.99.65.212 NS1.EU.CONCERT.NET 195.99.66.211 Record last updated on 23-Oct-1998. Database last updated on 2-Jun-2000 17:47:08 EDT. From bmanning at vacation.karoshi.com Sun Jun 4 22:11:32 2000 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 4 Jun 2000 19:11:32 -0700 (PDT) Subject: split b In-Reply-To: from "Randy Bush" at Jun 04, 2000 03:56:40 PM Message-ID: <200006050211.TAA01893@vacation.karoshi.com> Since this delegation predates ARINs existance, it seems that ARIN could have very little to say other than they grandfathered it in. > > this seems to be missing from the documentation of allocation policy, or i > am even more confused than usual. > > randy > > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 > Cable & Wireless USA (NETBLK-CW-NETCS) > 9000 Regency Parkway, Suite 200 > Cary, NC 27511 > US > > Netname: CW-NETCS20 > Netblock: 166.49.0.0 - 166.49.127.255 > > Coordinator: > Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net > 919-465-4160 > Fax- 919-465-4187 > > Domain System inverse mapping provided by: > > NS.CW.NET 204.70.128.1 > NS2.CW.NET 204.70.57.242 > NS3.CW.NET 204.70.25.234 > NS4.CW.NET 204.70.49.234 > > Record last updated on 16-Sep-1999. > Database last updated on 2-Jun-2000 17:47:08 EDT. > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 > Concert Communications Co. (NETBLK-CONCERTCOMM) > 81 Newgate Street > London, EC1A 7AJ > GB > > Netname: CONCERTCOMM > Netblock: 166.49.128.0 - 166.49.255.255 > > Coordinator: > Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET > +31 20 487 6584 (FAX) +31 20 487 6307 > > Domain System inverse mapping provided by: > > NS2.EU.CONCERT.NET 195.99.65.212 > NS1.EU.CONCERT.NET 195.99.66.211 > > Record last updated on 23-Oct-1998. > Database last updated on 2-Jun-2000 17:47:08 EDT. > From Tanya.Hinman at cwusa.com Mon Jun 5 08:16:15 2000 From: Tanya.Hinman at cwusa.com (Tanya Hinman) Date: Mon, 5 Jun 2000 08:16:15 -0400 Subject: split b In-Reply-To: Message-ID: <000101bfcee7$d84793c0$242547cc@thinman.cary.cw.netcw.net> Randy, This allocation was a transfer/merger issue. What policy are you referring to? Tanya -----Original Message----- From: owner-arin-discuss at arin.net [mailto:owner-arin-discuss at arin.net]On Behalf Of Randy Bush Sent: Sunday, June 04, 2000 6:57 PM To: arin-discuss at arin.net Subject: split b this seems to be missing from the documentation of allocation policy, or i am even more confused than usual. randy rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 Cable & Wireless USA (NETBLK-CW-NETCS) 9000 Regency Parkway, Suite 200 Cary, NC 27511 US Netname: CW-NETCS20 Netblock: 166.49.0.0 - 166.49.127.255 Coordinator: Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net 919-465-4160 Fax- 919-465-4187 Domain System inverse mapping provided by: NS.CW.NET 204.70.128.1 NS2.CW.NET 204.70.57.242 NS3.CW.NET 204.70.25.234 NS4.CW.NET 204.70.49.234 Record last updated on 16-Sep-1999. Database last updated on 2-Jun-2000 17:47:08 EDT. rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 Concert Communications Co. (NETBLK-CONCERTCOMM) 81 Newgate Street London, EC1A 7AJ GB Netname: CONCERTCOMM Netblock: 166.49.128.0 - 166.49.255.255 Coordinator: Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET +31 20 487 6584 (FAX) +31 20 487 6307 Domain System inverse mapping provided by: NS2.EU.CONCERT.NET 195.99.65.212 NS1.EU.CONCERT.NET 195.99.66.211 Record last updated on 23-Oct-1998. Database last updated on 2-Jun-2000 17:47:08 EDT. From John.Sweeting at cwusa.com Mon Jun 5 08:52:07 2000 From: John.Sweeting at cwusa.com (Sweeting, John) Date: Mon, 5 Jun 2000 08:52:07 -0400 Subject: split b Message-ID: <3FD40150593CD2119D5200805FA7D965050A7F8D@us-cwi-exc-a07.cwi.cablew.com> Bill, this does not predate ARIN, this was accomplished through ARIN. -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Sunday, June 04, 2000 10:12 PM To: rbush at bainbridge.verio.net Cc: arin-discuss at arin.net Subject: Re: split b Since this delegation predates ARINs existance, it seems that ARIN could have very little to say other than they grandfathered it in. > > this seems to be missing from the documentation of allocation policy, or i > am even more confused than usual. > > randy > > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 > Cable & Wireless USA (NETBLK-CW-NETCS) > 9000 Regency Parkway, Suite 200 > Cary, NC 27511 > US > > Netname: CW-NETCS20 > Netblock: 166.49.0.0 - 166.49.127.255 > > Coordinator: > Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net > 919-465-4160 > Fax- 919-465-4187 > > Domain System inverse mapping provided by: > > NS.CW.NET 204.70.128.1 > NS2.CW.NET 204.70.57.242 > NS3.CW.NET 204.70.25.234 > NS4.CW.NET 204.70.49.234 > > Record last updated on 16-Sep-1999. > Database last updated on 2-Jun-2000 17:47:08 EDT. > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 > Concert Communications Co. (NETBLK-CONCERTCOMM) > 81 Newgate Street > London, EC1A 7AJ > GB > > Netname: CONCERTCOMM > Netblock: 166.49.128.0 - 166.49.255.255 > > Coordinator: > Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET > +31 20 487 6584 (FAX) +31 20 487 6307 > > Domain System inverse mapping provided by: > > NS2.EU.CONCERT.NET 195.99.65.212 > NS1.EU.CONCERT.NET 195.99.66.211 > > Record last updated on 23-Oct-1998. > Database last updated on 2-Jun-2000 17:47:08 EDT. > From bmanning at vacation.karoshi.com Mon Jun 5 09:58:25 2000 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Jun 2000 06:58:25 -0700 (PDT) Subject: split b In-Reply-To: <3FD40150593CD2119D5200805FA7D965050A7F93@us-cwi-exc-a07.cwi.cablew.com> from "Sweeting, John" at Jun 05, 2000 09:11:01 AM Message-ID: <200006051358.GAA02369@vacation.karoshi.com> Its useful to send this to the arin-discuss list so that a correct impression is made. The original delegation was made prior to ARIN and ARIN simply approved the split of a pre-existing delegation. ------------------------------------------------------ > > that was to MCI, it was split between C&W and Concert due to MCI selling its > internet business to C&W in the fall of 1998. > > -----Original Message----- > From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, June 05, 2000 9:44 AM > To: John.Sweeting at cwusa.com > Cc: bmanning at vacation.karoshi.com > Subject: Re: split b > > > Hum, according to my database snapshots, 166.49.0.0/16 was delegated > in late 1996/early 1997. ARIN came into existance in 4q1997. I don't > know when the split in 166.49.0.0/16 occured. > > > > > > Bill, this does not predate ARIN, this was accomplished through ARIN. > > > > -----Original Message----- > > > > > > Since this delegation predates ARINs existance, it seems > > that ARIN could have very little to say other than they > > grandfathered > > it in. > > > > > > > > > > this seems to be missing from the documentation of allocation policy, or > i > > > am even more confused than usual. > > > > > > randy > > > > > > > > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 > > > Cable & Wireless USA (NETBLK-CW-NETCS) > > > 9000 Regency Parkway, Suite 200 > > > Cary, NC 27511 > > > US > > > > > > Netname: CW-NETCS20 > > > Netblock: 166.49.0.0 - 166.49.127.255 > > > > > > Coordinator: > > > Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net > > > 919-465-4160 > > > Fax- 919-465-4187 > > > > > > Domain System inverse mapping provided by: > > > > > > NS.CW.NET 204.70.128.1 > > > NS2.CW.NET 204.70.57.242 > > > NS3.CW.NET 204.70.25.234 > > > NS4.CW.NET 204.70.49.234 > > > > > > Record last updated on 16-Sep-1999. > > > Database last updated on 2-Jun-2000 17:47:08 EDT. > > > > > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 > > > Concert Communications Co. (NETBLK-CONCERTCOMM) > > > 81 Newgate Street > > > London, EC1A 7AJ > > > GB > > > > > > Netname: CONCERTCOMM > > > Netblock: 166.49.128.0 - 166.49.255.255 > > > > > > Coordinator: > > > Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET > > > +31 20 487 6584 (FAX) +31 20 487 6307 > > > > > > Domain System inverse mapping provided by: > > > > > > NS2.EU.CONCERT.NET 195.99.65.212 > > > NS1.EU.CONCERT.NET 195.99.66.211 > > > > > > Record last updated on 23-Oct-1998. > > > Database last updated on 2-Jun-2000 17:47:08 EDT. > > > > > > From rbush at bainbridge.verio.net Mon Jun 5 10:37:45 2000 From: rbush at bainbridge.verio.net (Randy Bush) Date: Mon, 05 Jun 2000 07:37:45 -0700 Subject: split b References: <000101bfcee7$d84793c0$242547cc@thinman.cary.cw.netcw.net> Message-ID: > This allocation was a transfer/merger issue. What policy are you referring > to? hi tanya (and john), a number of isps have route filters based on the rirs' allocation policies. 166.49.0.0 is in classic b space, where allocations are on a /16 boundary. our noc received a report of problems reaching the two /17s now being announced. i am trying to determine if arin has changed its allocation policy in part of the classic b space, in which case we would change our filters. i gather not. randy From John.Sweeting at cwusa.com Mon Jun 5 10:47:04 2000 From: John.Sweeting at cwusa.com (Sweeting, John) Date: Mon, 5 Jun 2000 10:47:04 -0400 Subject: split b Message-ID: <3FD40150593CD2119D5200805FA7D965050A7F97@us-cwi-exc-a07.cwi.cablew.com> All, this block went through the process and was reallocated by ARIN to C&W and Concert. Thanks. -----Original Message----- From: Peter Schroebel [mailto:pschroebel at fullport.com] Sent: Monday, June 05, 2000 10:32 AM To: Sweeting, John; bmanning at vacation.karoshi.com; rbush at bainbridge.verio.net Cc: arin-discuss at arin.net Subject: Re: split b It is my understanding that splitting netblocks or gaining netblocks via an aquistion or merger does not matter. In all cases netblocks are to be returned and reassigned based on the new entities qualified requirements. ARIN's has made this position very clear. If case should arise wherein there becomes numerous repeated aquistions and mergers. Then the network and netblocks would be owned by the Big Dogs and there would little that the small business and system users could do or say about. Moreover, there would no longer be an ARIN either Regards, Peter From kimh at arin.net Mon Jun 5 11:51:46 2000 From: kimh at arin.net (Kim Hubbard) Date: Mon, 05 Jun 2000 11:51:46 -0400 Subject: split b In-Reply-To: References: <000101bfcee7$d84793c0$242547cc@thinman.cary.cw.netcw.net> Message-ID: <4.1.20000605115028.01ad13c0@192.149.252.141> Randy, The original allocation was made pre-ARIN, however, the split was made by ARIN at the request of the participating organizations with the full understanding that there may be routing issues. We did not see any need to change our policies. Kim At 07:37 AM 6/5/00 -0700, Randy Bush wrote: >> This allocation was a transfer/merger issue. What policy are you referring >> to? > >hi tanya (and john), > >a number of isps have route filters based on the rirs' allocation policies. >166.49.0.0 is in classic b space, where allocations are on a /16 boundary. >our noc received a report of problems reaching the two /17s now being >announced. i am trying to determine if arin has changed its allocation >policy in part of the classic b space, in which case we would change our >filters. i gather not. > >randy From John.Sweeting at cwusa.com Mon Jun 5 08:52:07 2000 From: John.Sweeting at cwusa.com (Sweeting, John) Date: Mon, 5 Jun 2000 08:52:07 -0400 Subject: split b Message-ID: <3FD40150593CD2119D5200805FA7D965050A7F8D@us-cwi-exc-a07.cwi.cablew.com> Bill, this does not predate ARIN, this was accomplished through ARIN. -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: Sunday, June 04, 2000 10:12 PM To: rbush at bainbridge.verio.net Cc: arin-discuss at arin.net Subject: Re: split b Since this delegation predates ARINs existance, it seems that ARIN could have very little to say other than they grandfathered it in. > > this seems to be missing from the documentation of allocation policy, or i > am even more confused than usual. > > randy > > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 > Cable & Wireless USA (NETBLK-CW-NETCS) > 9000 Regency Parkway, Suite 200 > Cary, NC 27511 > US > > Netname: CW-NETCS20 > Netblock: 166.49.0.0 - 166.49.127.255 > > Coordinator: > Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net > 919-465-4160 > Fax- 919-465-4187 > > Domain System inverse mapping provided by: > > NS.CW.NET 204.70.128.1 > NS2.CW.NET 204.70.57.242 > NS3.CW.NET 204.70.25.234 > NS4.CW.NET 204.70.49.234 > > Record last updated on 16-Sep-1999. > Database last updated on 2-Jun-2000 17:47:08 EDT. > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 > Concert Communications Co. (NETBLK-CONCERTCOMM) > 81 Newgate Street > London, EC1A 7AJ > GB > > Netname: CONCERTCOMM > Netblock: 166.49.128.0 - 166.49.255.255 > > Coordinator: > Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET > +31 20 487 6584 (FAX) +31 20 487 6307 > > Domain System inverse mapping provided by: > > NS2.EU.CONCERT.NET 195.99.65.212 > NS1.EU.CONCERT.NET 195.99.66.211 > > Record last updated on 23-Oct-1998. > Database last updated on 2-Jun-2000 17:47:08 EDT. > From jerry at fc.net Mon Jun 5 12:43:48 2000 From: jerry at fc.net (Jeremy Porter) Date: Mon, 05 Jun 2000 11:43:48 -0500 Subject: split b In-Reply-To: Your message of "Mon, 05 Jun 2000 06:58:25 PDT." <200006051358.GAA02369@vacation.karoshi.com> Message-ID: <200006051643.LAA34700@freeside.fc.net> There still seems to be some confusion here, as far as I know there is no policy at ARIN that provides for a legacy assignment (one made before ARIN's inception) to be split into multiple parts. I know of no ARIN policy that prevents this either. However, according to the guidelines I'm aware of, both parties would be required to re-justify each /17 worth of space. Presumeably they did so, in order for ARIN to approve it. This is explicitly required under current ARIN policy, as I understand it. The problem becomes then, assuming ARIN did approve the rejustification, that there is no mechanism at ARIN or elsewhere to provide notifications of current "delegation models" which inidicate what size blocks are allocated out of what size ranges. ARIN does operate a Routing Registry in which this information could be stored programaticlly which could be queried programaticly or manually to check BGP announcements v. RIR assignment or allocation. I believe Randy is correct in his opinion that no policy decision was made with regard to making assignments out of "Classic B Space" of a prefix size of /17. (Which is what happened). However it seems clear to me that ARIN polices and guidelines allow for this to happen under the circumstances described. Thus it is important that we take this into consideration. In message <200006051358.GAA02369 at vacation.karoshi.com>, bmanning at vacation.karoshi .com writes: > > Its useful to send this to the arin-discuss list so that a correct > impression is made. The original delegation was made prior to ARIN > and ARIN simply approved the split of a pre-existing delegation. > > ------------------------------------------------------ > > >> >> that was to MCI, it was split between C&W and Concert due to MCI selling its >> internet business to C&W in the fall of 1998. >> >> -----Original Message----- >> From: bmanning at vacation.karoshi.com >> [mailto:bmanning at vacation.karoshi.com] >> Sent: Monday, June 05, 2000 9:44 AM >> To: John.Sweeting at cwusa.com >> Cc: bmanning at vacation.karoshi.com >> Subject: Re: split b >> >> >> Hum, according to my database snapshots, 166.49.0.0/16 was delegated >> in late 1996/early 1997. ARIN came into existance in 4q1997. I don't >> know when the split in 166.49.0.0/16 occured. >> >> >> > >> > Bill, this does not predate ARIN, this was accomplished through ARIN. >> > >> > -----Original Message----- >> > >> > >> > Since this delegation predates ARINs existance, it seems >> > that ARIN could have very little to say other than they >> > grandfathered >> > it in. >> > >> > >> > > >> > > this seems to be missing from the documentation of allocation policy, or >> i >> > > am even more confused than usual. >> > > >> > > randy >> > > >> > > >> > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 >> > > Cable & Wireless USA (NETBLK-CW-NETCS) >> > > 9000 Regency Parkway, Suite 200 >> > > Cary, NC 27511 >> > > US >> > > >> > > Netname: CW-NETCS20 >> > > Netblock: 166.49.0.0 - 166.49.127.255 >> > > >> > > Coordinator: >> > > Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net >> > > 919-465-4160 >> > > Fax- 919-465-4187 >> > > >> > > Domain System inverse mapping provided by: >> > > >> > > NS.CW.NET 204.70.128.1 >> > > NS2.CW.NET 204.70.57.242 >> > > NS3.CW.NET 204.70.25.234 >> > > NS4.CW.NET 204.70.49.234 >> > > >> > > Record last updated on 16-Sep-1999. >> > > Database last updated on 2-Jun-2000 17:47:08 EDT. >> > > >> > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 >> > > Concert Communications Co. (NETBLK-CONCERTCOMM) >> > > 81 Newgate Street >> > > London, EC1A 7AJ >> > > GB >> > > >> > > Netname: CONCERTCOMM >> > > Netblock: 166.49.128.0 - 166.49.255.255 >> > > >> > > Coordinator: >> > > Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET >> > > +31 20 487 6584 (FAX) +31 20 487 6307 >> > > >> > > Domain System inverse mapping provided by: >> > > >> > > NS2.EU.CONCERT.NET 195.99.65.212 >> > > NS1.EU.CONCERT.NET 195.99.66.211 >> > > >> > > Record last updated on 23-Oct-1998. >> > > Database last updated on 2-Jun-2000 17:47:08 EDT. >> > > >> > >> > --- jerry at fc.net Director Network Operations/Network Engineering, Wayport, Inc. 512-519-6193 www.wayport.net 8303 Mopac Expressway Suite A300, Austin Tx. From bmanning at vacation.karoshi.com Mon Jun 5 13:37:55 2000 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 5 Jun 2000 10:37:55 -0700 (PDT) Subject: split b In-Reply-To: <200006051643.LAA34700@freeside.fc.net> from "Jeremy Porter" at Jun 05, 2000 11:43:48 AM Message-ID: <200006051737.KAA02756@vacation.karoshi.com> > The problem becomes then, assuming ARIN did approve the rejustification, > that there is no mechanism at ARIN or elsewhere to provide notifications > of current "delegation models" which inidicate what size blocks are > allocated out of what size ranges. ARIN does operate a Routing Registry > in which this information could be stored programaticlly which could > be queried programaticly or manually to check BGP announcements v. > RIR assignment or allocation. ARINs use of registry technology post-dates this split. One presumes that Mr. Bush pulled the relevent information from the ARIN routing registry via whois. > I believe Randy is correct in his opinion that no policy decision was > made with regard to making assignments out of "Classic B Space" of a > prefix size of /17. (Which is what happened). However it seems clear > to me that ARIN polices and guidelines allow for this to happen > under the circumstances described. Thus it is important that > we take this into consideration. Well, I beg to differ. A policy decision was made and the split was done. This may have been done as a "one-off" but it does provide a prior-use argument for future splits to occur. I agree that existant ARIN policy (as I understand it) will allow such splits to occur. Perhaps ISPs would begin to realize that a blanket summarization of filtering is prone to many errors, esp. due to historical delegations and policy considerations that are now OBE but have been grandfathered in. > > In message <200006051358.GAA02369 at vacation.karoshi.com>, bmanning at vacation.karoshi > .com writes: > > > > Its useful to send this to the arin-discuss list so that a correct > > impression is made. The original delegation was made prior to ARIN > > and ARIN simply approved the split of a pre-existing delegation. > > > > ------------------------------------------------------ > > > > > >> > >> that was to MCI, it was split between C&W and Concert due to MCI selling its > >> internet business to C&W in the fall of 1998. > >> > >> -----Original Message----- > >> From: bmanning at vacation.karoshi.com > >> [mailto:bmanning at vacation.karoshi.com] > >> Sent: Monday, June 05, 2000 9:44 AM > >> To: John.Sweeting at cwusa.com > >> Cc: bmanning at vacation.karoshi.com > >> Subject: Re: split b > >> > >> > >> Hum, according to my database snapshots, 166.49.0.0/16 was delegated > >> in late 1996/early 1997. ARIN came into existance in 4q1997. I don't > >> know when the split in 166.49.0.0/16 occured. > >> > >> > >> > > >> > Bill, this does not predate ARIN, this was accomplished through ARIN. > >> > > >> > -----Original Message----- > >> > > >> > > >> > Since this delegation predates ARINs existance, it seems > >> > that ARIN could have very little to say other than they > >> > grandfathered > >> > it in. > >> > > >> > > >> > > > >> > > this seems to be missing from the documentation of allocation policy, or > >> i > >> > > am even more confused than usual. > >> > > > >> > > randy > >> > > > >> > > > >> > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 > >> > > Cable & Wireless USA (NETBLK-CW-NETCS) > >> > > 9000 Regency Parkway, Suite 200 > >> > > Cary, NC 27511 > >> > > US > >> > > > >> > > Netname: CW-NETCS20 > >> > > Netblock: 166.49.0.0 - 166.49.127.255 > >> > > > >> > > Coordinator: > >> > > Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net > >> > > 919-465-4160 > >> > > Fax- 919-465-4187 > >> > > > >> > > Domain System inverse mapping provided by: > >> > > > >> > > NS.CW.NET 204.70.128.1 > >> > > NS2.CW.NET 204.70.57.242 > >> > > NS3.CW.NET 204.70.25.234 > >> > > NS4.CW.NET 204.70.49.234 > >> > > > >> > > Record last updated on 16-Sep-1999. > >> > > Database last updated on 2-Jun-2000 17:47:08 EDT. > >> > > > >> > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 > >> > > Concert Communications Co. (NETBLK-CONCERTCOMM) > >> > > 81 Newgate Street > >> > > London, EC1A 7AJ > >> > > GB > >> > > > >> > > Netname: CONCERTCOMM > >> > > Netblock: 166.49.128.0 - 166.49.255.255 > >> > > > >> > > Coordinator: > >> > > Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET > >> > > +31 20 487 6584 (FAX) +31 20 487 6307 > >> > > > >> > > Domain System inverse mapping provided by: > >> > > > >> > > NS2.EU.CONCERT.NET 195.99.65.212 > >> > > NS1.EU.CONCERT.NET 195.99.66.211 > >> > > > >> > > Record last updated on 23-Oct-1998. > >> > > Database last updated on 2-Jun-2000 17:47:08 EDT. > >> > > > >> > > >> > > > > --- jerry at fc.net > Director Network Operations/Network Engineering, Wayport, Inc. > 512-519-6193 www.wayport.net > 8303 Mopac Expressway Suite A300, Austin Tx. > From hostmaster at verant.com Mon Jun 5 13:19:47 2000 From: hostmaster at verant.com (Hostmaster, Verant) Date: Mon, 5 Jun 2000 10:19:47 -0700 Subject: route filtering policies (from "split b" thread) Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B015EC003@mail-la.station.sony.com> Hello. I'm very interested in learning what are the route filtering policies of the larger ISPs. We're architecting our /18 now, and concerned that some of our smaller announcements (/22 or perhaps as small as /24) might not get carried throughout the entire Internet. What I would appreciate is that anyone on this list who restricts their learned routes to prefixes shorter than /24s please let me know what your policies are. Is there a standard that most adhere to? I am reading about "rirs" in Randy's below email.. what were rirs' allocation policies? We've recently discovered one large ISP blocking /23s and /24s from 24.*.*.* , since it is a classic class "A". After a few days of grief, they finally realized that since 24.*.*.* had been chopped up and given to cablemodem providers, it has announcements that small, and they now will accept as small as /24s coming from 24.*.*.*. Our block is 64.37.128.0/18, and I'm concerned that some old filters that were put in place long ago might harm us, in that 64.*.*.* only recently started being issued by ARIN, and that technically it is a class "A" block. ---- Dani D. Roisman Verant Interactive hostmaster at verant.com (310) 840-8753 > -----Original Message----- > From: Randy Bush [SMTP:rbush at bainbridge.verio.net] > Sent: Monday, June 05, 2000 7:38 AM > To: Tanya Hinman > Cc: arin-discuss at arin.net > Subject: RE: split b > > > This allocation was a transfer/merger issue. What policy are you > referring > > to? > > hi tanya (and john), > > a number of isps have route filters based on the rirs' allocation > policies. > 166.49.0.0 is in classic b space, where allocations are on a /16 boundary. > our noc received a report of problems reaching the two /17s now being > announced. i am trying to determine if arin has changed its allocation > policy in part of the classic b space, in which case we would change our > filters. i gather not. > > randy From kimh at arin.net Mon Jun 5 13:54:34 2000 From: kimh at arin.net (Kim Hubbard) Date: Mon, 05 Jun 2000 13:54:34 -0400 Subject: split b In-Reply-To: <200006051737.KAA02756@vacation.karoshi.com> References: <200006051643.LAA34700@freeside.fc.net> Message-ID: <4.1.20000605134442.01aff430@192.149.252.141> At 10:37 AM 6/5/00 -0700, bmanning at vacation.karoshi.com wrote: >> The problem becomes then, assuming ARIN did approve the rejustification, >> that there is no mechanism at ARIN or elsewhere to provide notifications >> of current "delegation models" which inidicate what size blocks are >> allocated out of what size ranges. ARIN does operate a Routing Registry >> in which this information could be stored programaticlly which could >> be queried programaticly or manually to check BGP announcements v. >> RIR assignment or allocation. > > ARINs use of registry technology post-dates this split. > One presumes that Mr. Bush pulled the relevent information > from the ARIN routing registry via whois. > >> I believe Randy is correct in his opinion that no policy decision was >> made with regard to making assignments out of "Classic B Space" of a >> prefix size of /17. (Which is what happened). However it seems clear >> to me that ARIN polices and guidelines allow for this to happen >> under the circumstances described. Thus it is important that >> we take this into consideration. > > Well, I beg to differ. A policy decision was made and the > split was done. This may have been done as a "one-off" but > it does provide a prior-use argument for future splits > to occur. I agree that existant ARIN policy (as I understand it) > will allow such splits to occur. Perhaps ISPs would begin > to realize that a blanket summarization of filtering is prone > to many errors, esp. due to historical delegations and policy > considerations that are now OBE but have been grandfathered in. I'm personally looking at this differently. If organizations want their Class B's split in our database knowing they may be filtered than that's their business. As Randy said, the organizations in question agreed to work out the specifics so filtering wasn't suppose to be an issue for them. I don't necessarily believe that we should (based on this one instance) move to make a formal policy change wherin ISPs would feel compelled to change their filtering policies....again. Kim > > > >> >> In message <200006051358.GAA02369 at vacation.karoshi.com>, >bmanning at vacation.karoshi >> .com writes: >> > >> > Its useful to send this to the arin-discuss list so that a correct >> > impression is made. The original delegation was made prior to ARIN >> > and ARIN simply approved the split of a pre-existing delegation. >> > >> > ------------------------------------------------------ >> > >> > >> >> >> >> that was to MCI, it was split between C&W and Concert due to MCI >selling its >> >> internet business to C&W in the fall of 1998. >> >> >> >> -----Original Message----- >> >> From: bmanning at vacation.karoshi.com >> >> [mailto:bmanning at vacation.karoshi.com] >> >> Sent: Monday, June 05, 2000 9:44 AM >> >> To: John.Sweeting at cwusa.com >> >> Cc: bmanning at vacation.karoshi.com >> >> Subject: Re: split b >> >> >> >> >> >> Hum, according to my database snapshots, 166.49.0.0/16 was delegated >> >> in late 1996/early 1997. ARIN came into existance in 4q1997. I don't >> >> know when the split in 166.49.0.0/16 occured. >> >> >> >> >> >> > >> >> > Bill, this does not predate ARIN, this was accomplished through ARIN. >> >> > >> >> > -----Original Message----- >> >> > >> >> > >> >> > Since this delegation predates ARINs existance, it seems >> >> > that ARIN could have very little to say other than they >> >> > grandfathered >> >> > it in. >> >> > >> >> > >> >> > > >> >> > > this seems to be missing from the documentation of allocation >policy, or >> >> i >> >> > > am even more confused than usual. >> >> > > >> >> > > randy >> >> > > >> >> > > >> >> > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.0.0 >> >> > > Cable & Wireless USA (NETBLK-CW-NETCS) >> >> > > 9000 Regency Parkway, Suite 200 >> >> > > Cary, NC 27511 >> >> > > US >> >> > > >> >> > > Netname: CW-NETCS20 >> >> > > Netblock: 166.49.0.0 - 166.49.127.255 >> >> > > >> >> > > Coordinator: >> >> > > Cable & Wireless USA (IA3-ORG-ARIN) ipadmin at cw.net >> >> > > 919-465-4160 >> >> > > Fax- 919-465-4187 >> >> > > >> >> > > Domain System inverse mapping provided by: >> >> > > >> >> > > NS.CW.NET 204.70.128.1 >> >> > > NS2.CW.NET 204.70.57.242 >> >> > > NS3.CW.NET 204.70.25.234 >> >> > > NS4.CW.NET 204.70.49.234 >> >> > > >> >> > > Record last updated on 16-Sep-1999. >> >> > > Database last updated on 2-Jun-2000 17:47:08 EDT. >> >> > > >> >> > > rip.psg.com:/usr/home/randy> whois -h whois.arin.net 166.49.128.0 >> >> > > Concert Communications Co. (NETBLK-CONCERTCOMM) >> >> > > 81 Newgate Street >> >> > > London, EC1A 7AJ >> >> > > GB >> >> > > >> >> > > Netname: CONCERTCOMM >> >> > > Netblock: 166.49.128.0 - 166.49.255.255 >> >> > > >> >> > > Coordinator: >> >> > > Koolen, Hans (HK45-ARIN) hkoolen at EU.CONCERT.NET >> >> > > +31 20 487 6584 (FAX) +31 20 487 6307 >> >> > > >> >> > > Domain System inverse mapping provided by: >> >> > > >> >> > > NS2.EU.CONCERT.NET 195.99.65.212 >> >> > > NS1.EU.CONCERT.NET 195.99.66.211 >> >> > > >> >> > > Record last updated on 23-Oct-1998. >> >> > > Database last updated on 2-Jun-2000 17:47:08 EDT. >> >> > > >> >> > >> >> >> > >> >> --- jerry at fc.net >> Director Network Operations/Network Engineering, Wayport, Inc. >> 512-519-6193 www.wayport.net >> 8303 Mopac Expressway Suite A300, Austin Tx. >> From dbernardi at adelphia.net Mon Jun 5 14:11:09 2000 From: dbernardi at adelphia.net (dave bernardi) Date: Mon, 05 Jun 2000 14:11:09 -0400 Subject: route filtering policies (from "split b" thread) In-Reply-To: <51EC05AE2DD6D111A0CF00805F6F410B015EC003@mail-la.station.s ony.com> Message-ID: <4.3.2.7.2.20000605133945.00d555f0@mail.cdp.adelphia.net> Dani, Verio will accept /20 and shorter out of "some" traditional class A space which is the most restrictive we've experienced from the big providers. Sprint says /24 but I've seen longer; and even longer from UUnet and Qwest. http://info.us.bb.verio.net/routing.html http://www.sprintlink.net/policy/bgp_filters.html Your 64.37.128.0/18 should be fine. Dave B> At 10:19 AM 6/5/00 -0700, Hostmaster, Verant wrote: >Hello. I'm very interested in learning what are the route filtering >policies of the larger ISPs. We're architecting our /18 now, and concerned >that some of our smaller announcements (/22 or perhaps as small as /24) >might not get carried throughout the entire Internet. What I would >appreciate is that anyone on this list who restricts their learned routes to >prefixes shorter than /24s please let me know what your policies are. > >Is there a standard that most adhere to? I am reading about "rirs" in >Randy's below email.. what were rirs' allocation policies? > >We've recently discovered one large ISP blocking /23s and /24s from 24.*.*.* >, since it is a classic class "A". After a few days of grief, they finally >realized that since 24.*.*.* had been chopped up and given to cablemodem >providers, it has announcements that small, and they now will accept as >small as /24s coming from 24.*.*.*. > >Our block is 64.37.128.0/18, and I'm concerned that some old filters that >were put in place long ago might harm us, in that 64.*.*.* only recently >started being issued by ARIN, and that technically it is a class "A" block. > >---- >Dani D. Roisman >Verant Interactive >hostmaster at verant.com >(310) 840-8753 > >> -----Original Message----- >> From: Randy Bush [SMTP:rbush at bainbridge.verio.net] >> Sent: Monday, June 05, 2000 7:38 AM >> To: Tanya Hinman >> Cc: arin-discuss at arin.net >> Subject: RE: split b >> >> > This allocation was a transfer/merger issue. What policy are you >> referring >> > to? >> >> hi tanya (and john), >> >> a number of isps have route filters based on the rirs' allocation >> policies. >> 166.49.0.0 is in classic b space, where allocations are on a /16 boundary. >> our noc received a report of problems reaching the two /17s now being >> announced. i am trying to determine if arin has changed its allocation >> policy in part of the classic b space, in which case we would change our >> filters. i gather not. >> >> randy -- Dave Bernardi From andy at XECU.NET Mon Jun 5 14:19:05 2000 From: andy at XECU.NET (Andy Dills) Date: Mon, 5 Jun 2000 14:19:05 -0400 (EDT) Subject: split b In-Reply-To: <4.1.20000605134442.01aff430@192.149.252.141> Message-ID: On Mon, 5 Jun 2000, Kim Hubbard wrote: > I'm personally looking at this differently. If organizations want their > Class B's split in our database knowing they may be filtered than that's > their business. As Randy said, the organizations in question agreed to > work out the specifics so filtering wasn't suppose to be an issue for them. > I don't necessarily believe that we should (based on this one instance) > move to make a formal policy change wherin ISPs would feel compelled to > change their filtering policies....again. I understand the historical reasons for filtering routers based on prefix and prefix length, but I can't figure out why this is still a common practice. I'm not even convinced it is a common practice any more. So, why would it be in a network's best interest to filter based on prefix/prefix length? Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access From hostmaster at verant.com Mon Jun 5 16:03:08 2000 From: hostmaster at verant.com (Hostmaster, Verant) Date: Mon, 5 Jun 2000 13:03:08 -0700 Subject: route filtering policies (from "split b" thread) Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B015EC00D@mail-la.station.sony.com> Thanks for the URL... hm.. /20 and shorter only in 64/8? That's a bit strict, no? We have different networks off our 64.34.128/18 block, which we would like to announce in /21 and /22 blocks. There's a good chance we won't aggregate, since the networks might each have OC3 or OC12 links to the Internet, but in some places as slow as T1 between the two networks, and I wouldn't want to backhaul accross the T1. Who should I contact at Verio to discuss losening the filtering policy? Also, is there a Verio looking glass, so that I can test whether my routes are visible? If you'd like to test, try 64.37.160.1 - it's pingable, and announced on 64.37.160.0/24. For a longer prefix, pls try 64.37.128.5, announced on 64.37.128.0/20 ---- Dani Roisman Sony Online Entertainment droisman at station.sony.com (310) 840-8753 > -----Original Message----- > From: Doug Junkins [SMTP:junkins at orcasisland.verio.net] > Sent: Monday, June 05, 00 10:52 AM > To: Hostmaster, Verant > Subject: Re: route filtering policies (from "split b" thread) > > See "http://info.us.bb.verio.net/routing.html#PeerFilter". > > -Doug > > On Mon, Jun 05, 2000 at 10:19:47AM -0700, Hostmaster, Verant wrote: > > Hello. I'm very interested in learning what are the route filtering > > policies of the larger ISPs. We're architecting our /18 now, and > concerned > > that some of our smaller announcements (/22 or perhaps as small as /24) > > might not get carried throughout the entire Internet. What I would > > appreciate is that anyone on this list who restricts their learned > routes to > > prefixes shorter than /24s please let me know what your policies are. > > > > Is there a standard that most adhere to? I am reading about "rirs" in > > Randy's below email.. what were rirs' allocation policies? > > > > We've recently discovered one large ISP blocking /23s and /24s from > 24.*.*.* > > , since it is a classic class "A". After a few days of grief, they > finally > > realized that since 24.*.*.* had been chopped up and given to cablemodem > > providers, it has announcements that small, and they now will accept as > > small as /24s coming from 24.*.*.*. > > > > Our block is 64.37.128.0/18, and I'm concerned that some old filters > that > > were put in place long ago might harm us, in that 64.*.*.* only recently > > started being issued by ARIN, and that technically it is a class "A" > block. > > > > ---- > > Dani D. Roisman > > Verant Interactive > > hostmaster at verant.com > > (310) 840-8753 > > > > > -----Original Message----- > > > From: Randy Bush [SMTP:rbush at bainbridge.verio.net] > > > Sent: Monday, June 05, 2000 7:38 AM > > > To: Tanya Hinman > > > Cc: arin-discuss at arin.net > > > Subject: RE: split b > > > > > > > This allocation was a transfer/merger issue. What policy are you > > > referring > > > > to? > > > > > > hi tanya (and john), > > > > > > a number of isps have route filters based on the rirs' allocation > > > policies. > > > 166.49.0.0 is in classic b space, where allocations are on a /16 > boundary. > > > our noc received a report of problems reaching the two /17s now being > > > announced. i am trying to determine if arin has changed its > allocation > > > policy in part of the classic b space, in which case we would change > our > > > filters. i gather not. > > > > > > randy From hostmaster at verant.com Mon Jun 5 17:30:57 2000 From: hostmaster at verant.com (Hostmaster, Verant) Date: Mon, 5 Jun 2000 14:30:57 -0700 Subject: route filtering policies (from "split b" thread) Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> Our situation is that we are multihomed to a few providors at each location, but not necessarily with a backbone-grade link between each physical location. We do not resell connectivity, but use it all for our own Internet application serving. So it's not really that irresponsible, in that we cannot just take blocks from our providers. I know of providers that accept as small as /24s, and I know of networks that announce /23s and /24s and have no aggregate to fall back on. In fact in the case I described, we were able to affect a change, which was prohibiting many cablemodem customers from accessing not only us, but the network of a large ISP. But perhaps you can shed some light on the question asked by another on this thread - why exactly would you filter on anything shorter than a /24? RAM on your routers? CPU? On my network, I want to pick up as specific routes (well, up to /24) as the other network wants to announce to me - chances are I'll get a better connection using a more specific prefix. Follow up question - where do you come up with /20 as the magic length for class A's and B's, but /24 for class C's? Additionally, ARIN is now handing out 64.0.0.0/8 in smaller blocks. Perhaps someone on this list can speak to the smallest block being handed out in 64.0.0.0/8. ---- Dani Roisman Verant Interactive hostmaster at verant.com (310) 840-8753 > -----Original Message----- > From: Paul A Vixie [SMTP:vixie at mibh.net] > Sent: Monday, June 05, 00 2:04 PM > To: Hostmaster, Verant > Cc: 'arin-discuss at arin.net'; Network Operations > Subject: Re: route filtering policies (from "split b" thread) > > > Thanks for the URL... hm.. /20 and shorter only in 64/8? That's a bit > > strict, no? We have different networks off our 64.34.128/18 block, > which we > > would like to announce in /21 and /22 blocks. There's a good chance we > > won't aggregate, since the networks might each have OC3 or OC12 links to > the > > Internet, but in some places as slow as T1 between the two networks, and > I > > wouldn't want to backhaul accross the T1. > > that's an incredibly irresponsible way to build a net. if you're going to > be a transit aggregator, then by all means get small blocks your providers > and pay them extra to get cutouts. the expectation we all have when you > get > an address block is that you intend to advertise it, not carve it up. > > > Who should I contact at Verio to discuss losening the filtering policy? > > won't help. see http://www.mibh.net/mibh-peering.html and know that if > you > tried to get us to loosen it we would definitely not. there are dozens if > not hundreds of nets running with this policy. the thing to change is > your > plan, not the commonly implemented route filtering policy of the whole > 'net. From cwinter at communicationnation.com Mon Jun 5 18:18:21 2000 From: cwinter at communicationnation.com (Charles Winter) Date: Mon, 5 Jun 2000 15:18:21 -0700 Subject: route filtering policies (from "split b" thread) References: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> Message-ID: <032f01bfcf3b$f608b890$4d1dc9cf@javamail.com> Dani, At present there are about 40,000 some-odd CIDR routes being propagated. This takes just shy of 64meg. on a Cisco router - you can go to a publicly available route server to check this out - so we all order border routers with a minimum of 128 Meg. If no agriagation was done, it would be very easy to exceed the maximum available memory a Cisco router can handle - at present 256Meg. It does not take a lot of CPU to forward and receive route updates. EBGP - Exterior BGP (vs. IntereiorBGP) does not like to announce subnetted /24 - thank goodness. Good policy is to aggrigate as much as possible, and this is the force driving Router Arbiter Data Bases. To try to keep the Internet from "flyingh apart" as one company put it. A /20 is the smallest usuall allocation ARIN will make - there are a few exceptions ... Charles Winter cwinter at communicationnation.com ----- Original Message ----- From: Hostmaster, Verant To: 'Paul A Vixie' Cc: Sent: Monday, June 05, 2000 2:30 PM Subject: RE: route filtering policies (from "split b" thread) > Our situation is that we are multihomed to a few providors at each location, > but not necessarily with a backbone-grade link between each physical > location. We do not resell connectivity, but use it all for our own > Internet application serving. > > So it's not really that irresponsible, in that we cannot just take blocks > from our providers. I know of providers that accept as small as /24s, and I > know of networks that announce /23s and /24s and have no aggregate to fall > back on. In fact in the case I described, we were able to affect a change, > which was prohibiting many cablemodem customers from accessing not only us, > but the network of a large ISP. > > But perhaps you can shed some light on the question asked by another on this > thread - why exactly would you filter on anything shorter than a /24? RAM > on your routers? CPU? On my network, I want to pick up as specific routes > (well, up to /24) as the other network wants to announce to me - chances are > I'll get a better connection using a more specific prefix. > > Follow up question - where do you come up with /20 as the magic length for > class A's and B's, but /24 for class C's? > > Additionally, ARIN is now handing out 64.0.0.0/8 in smaller blocks. Perhaps > someone on this list can speak to the smallest block being handed out in > 64.0.0.0/8. > > ---- > Dani Roisman > Verant Interactive > hostmaster at verant.com > (310) 840-8753 > > > > -----Original Message----- > > From: Paul A Vixie [SMTP:vixie at mibh.net] > > Sent: Monday, June 05, 00 2:04 PM > > To: Hostmaster, Verant > > Cc: 'arin-discuss at arin.net'; Network Operations > > Subject: Re: route filtering policies (from "split b" thread) > > > > > Thanks for the URL... hm.. /20 and shorter only in 64/8? That's a bit > > > strict, no? We have different networks off our 64.34.128/18 block, > > which we > > > would like to announce in /21 and /22 blocks. There's a good chance we > > > won't aggregate, since the networks might each have OC3 or OC12 links to > > the > > > Internet, but in some places as slow as T1 between the two networks, and > > I > > > wouldn't want to backhaul accross the T1. > > > > that's an incredibly irresponsible way to build a net. if you're going to > > be a transit aggregator, then by all means get small blocks your providers > > and pay them extra to get cutouts. the expectation we all have when you > > get > > an address block is that you intend to advertise it, not carve it up. > > > > > Who should I contact at Verio to discuss losening the filtering policy? > > > > won't help. see http://www.mibh.net/mibh-peering.html and know that if > > you > > tried to get us to loosen it we would definitely not. there are dozens if > > not hundreds of nets running with this policy. the thing to change is > > your > > plan, not the commonly implemented route filtering policy of the whole > > 'net. From Mike at netwright.net Mon Jun 5 18:26:27 2000 From: Mike at netwright.net (Mike Lieberman) Date: Mon, 5 Jun 2000 16:26:27 -0600 Subject: route filtering policies (from "split b" thread) In-Reply-To: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> Message-ID: <001a01bfcf3d$17e23a80$fe00a9d8@SWEETNESS> This conversation about filter leaves me scratching my head. Some of you are making a specific assumption that only large bandwidth, large block users must multihome between various providers. While I do not argue that this is the most common situation, it is not the only situation. We support one company that is currently multi-homed between two providers and will likely be adding a third. No line is larger than a T1. The customer barely needs a /24. So we provide the customer a /24. He then announces this network to his other vendor as well as through us. If this customers routes get filtered because the company's address block isn't large enough, the only thing you are doing to placing pressure on the customer to fake the need for more IP addresses so that their network gets announced and carried by more networks. Am I the only one who thinks that such filtering policies are counter intuitive? The need to preserve IP space is at odds with the needs to hold down the size of the BPG announcements. ARIN members needs to make a choice. I don't like rules that force my customers to lie to me or suffer poor routing. /* Mike Lieberman Mike at NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net/ */ /* Voice and Fax: 307-857-1053 */ From repete at cncx.com Mon Jun 5 18:29:18 2000 From: repete at cncx.com (Pete Bowden) Date: Mon, 5 Jun 2000 15:29:18 -0700 (PDT) Subject: route filtering policies (from "split b" thread) In-Reply-To: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> from "Hostmaster, Verant" at Jun 05, 2000 02:30:57 PM Message-ID: <200006052229.PAA13587@skylab.eng.internex.net> Not speaking on behalf of my company or any policies which may or may not exist :-) -- just to give a background on how some companies view traffic and why some providers choose to filter at the largest block size. This gets into the argument of peer vs. provider. Most peering relationships between larger ISP's require that each peer in the relationship advertise the SAME announcement everywhere where they peer. Additionally, peering relationships usually have requirements for a minimum number of locations at the public exchanges, or alternatively direct connections between the providers. "Peers" are also at times (by some providers) expected to have a sizeable number of announcements (comparable to between the 'peers'). There may be policies which restrict who some providers might concider to be peers based on the similar traffic volumes, similar number of prefixes, and the difference between the traffic flow in each direction. If you don't have a backbone sufficient to carry your own traffic and only announce regionally then some larger providers will concider that not to be a peer relationship--"why should I have to pay to carry your traffic on my backbone or purchased transit pipes" is what one might hear. Larger providers, especially, have different policies for customers than they do with peers, and pay close attention to their definition of peer. The logic is that people should always be announcing/anchoring their LARGE agregate block somewhere in case the more specifics are not accepted -- this allows them to not have to carry what they concider to be your traffic across their backbone -- even though it may be their customers which are trying to reach your server. If you don't announce your large agregates then you are risking the connectivity of parts of your network from others in the global internet. > > Our situation is that we are multihomed to a few providors at each location, > but not necessarily with a backbone-grade link between each physical > location. We do not resell connectivity, but use it all for our own > Internet application serving. > > So it's not really that irresponsible, in that we cannot just take blocks > from our providers. I know of providers that accept as small as /24s, and I > know of networks that announce /23s and /24s and have no aggregate to fall > back on. In fact in the case I described, we were able to affect a change, > which was prohibiting many cablemodem customers from accessing not only us, > but the network of a large ISP. > > But perhaps you can shed some light on the question asked by another on this > thread - why exactly would you filter on anything shorter than a /24? RAM > on your routers? CPU? On my network, I want to pick up as specific routes > (well, up to /24) as the other network wants to announce to me - chances are > I'll get a better connection using a more specific prefix. > > Follow up question - where do you come up with /20 as the magic length for > class A's and B's, but /24 for class C's? > > Additionally, ARIN is now handing out 64.0.0.0/8 in smaller blocks. Perhaps > someone on this list can speak to the smallest block being handed out in > 64.0.0.0/8. > > ---- > Dani Roisman > Verant Interactive > hostmaster at verant.com > (310) 840-8753 > > > > -----Original Message----- > > From: Paul A Vixie [SMTP:vixie at mibh.net] > > Sent: Monday, June 05, 00 2:04 PM > > To: Hostmaster, Verant > > Cc: 'arin-discuss at arin.net'; Network Operations > > Subject: Re: route filtering policies (from "split b" thread) > > > > > Thanks for the URL... hm.. /20 and shorter only in 64/8? That's a bit > > > strict, no? We have different networks off our 64.34.128/18 block, > > which we > > > would like to announce in /21 and /22 blocks. There's a good chance we > > > won't aggregate, since the networks might each have OC3 or OC12 links to > > the > > > Internet, but in some places as slow as T1 between the two networks, and > > I > > > wouldn't want to backhaul accross the T1. > > > > that's an incredibly irresponsible way to build a net. if you're going to > > be a transit aggregator, then by all means get small blocks your providers > > and pay them extra to get cutouts. the expectation we all have when you > > get > > an address block is that you intend to advertise it, not carve it up. > > > > > Who should I contact at Verio to discuss losening the filtering policy? > > > > won't help. see http://www.mibh.net/mibh-peering.html and know that if > > you > > tried to get us to loosen it we would definitely not. there are dozens if > > not hundreds of nets running with this policy. the thing to change is > > your > > plan, not the commonly implemented route filtering policy of the whole > > 'net.. > -- Pete Bowden, Internet Network Engineer, Internet & Data Center Engineering rePete at concentric.com rePete at cncx.com pete at internex.net NIC:PB8 Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, CA 95126-3429 Voice: 408-808-6010 Fax: 408-808-6010 From rbush at bainbridge.verio.net Mon Jun 5 18:41:31 2000 From: rbush at bainbridge.verio.net (Randy Bush) Date: Mon, 05 Jun 2000 15:41:31 -0700 Subject: route filtering policies (from "split b" thread) References: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> <001a01bfcf3d$17e23a80$fe00a9d8@SWEETNESS> Message-ID: i suggest that this has been discussed to death on the nanog mailing list, and, like other internet discussions, is repeated every six to nine months. there is little need to repeat the discussion here when you read the archives over there. my original question was merely whether arin had changed policy or whether something else was going on. it turned out that, despite ill-considered comment to the contrary, arin has not changed policy, and the apparent problem was either a bug or a communication issue between private parties. we can all go back to sleep now, learn how to [un]subscribe to internet mailing lists, and other exciting things. randy From repete at cncx.com Mon Jun 5 19:06:13 2000 From: repete at cncx.com (Pete Bowden) Date: Mon, 5 Jun 2000 16:06:13 -0700 (PDT) Subject: route filtering policies (from "split b" thread) In-Reply-To: <001a01bfcf3d$17e23a80$fe00a9d8@SWEETNESS> from "Mike Lieberman" at Jun 05, 2000 04:26:27 PM Message-ID: <200006052306.QAA02104@skylab.eng.internex.net> Yes, but in your case you should be announcing your larger agregate... so... since your customer should still be reachable from you if the route is filtered they will not see the more specific and will see the agregate and route the block to you... you in turn will hand it over to your customer. No need for them to lie about anything.... you just need to make the case to them that this is how it works for technical reasons beyond your ability to control -- technical reasons being limiting bandwidth and other providers not feeling like they should be compelled to provide free passage of other peoples blocks. > > This conversation about filter leaves me scratching my head. > > Some of you are making a specific assumption that only large bandwidth, large > block users must multihome between various providers. While I do not argue > that this is the most common situation, it is not the only situation. > > We support one company that is currently multi-homed between two providers > and will likely be adding a third. No line is larger than a T1. The customer > barely needs a /24. So we provide the customer a /24. He then announces this > network to his other vendor as well as through us. > > If this customers routes get filtered because the company's address block > isn't large enough, the only thing you are doing to placing pressure on the > customer to fake the need for more IP addresses so that their network gets > announced and carried by more networks. Am I the only one who thinks that > such filtering policies are counter intuitive? > > The need to preserve IP space is at odds with the needs to hold down the size > of the BPG announcements. ARIN members needs to make a choice. I don't like > rules that force my customers to lie to me or suffer poor routing. > > /* Mike Lieberman Mike at NetWright.Net */ > /* President */ > /* Net Wright LLC */ > /* http://www.netwright.net/ */ > /* Voice and Fax: 307-857-1053 */ > -- Pete Bowden, Internet Network Engineer, Internet & Data Center Engineering rePete at concentric.com rePete at cncx.com pete at internex.net NIC:PB8 Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, CA 95126-3429 Voice: 408-808-6010 Fax: 408-808-6010 From Mike at netwright.net Mon Jun 5 19:37:38 2000 From: Mike at netwright.net (Mike Lieberman) Date: Mon, 5 Jun 2000 17:37:38 -0600 Subject: route filtering policies (from "split b" thread) In-Reply-To: <200006052306.QAA02104@skylab.eng.internex.net> Message-ID: <000001bfcf47$09c38760$dd0ca9d8@netwright.net> Let's start with the fact that my customer also has to be seen out the OTHER ROUTE that belongs to ANOTHER vendor. If we agregated the customer then we announce him even when his line to us is down. It has gone done once in the last year and it took the local ILEC over nine hours to fix it. His route to me MUST disappear when I am not carrying him so that all traffic will flow to the other vendor who is announcing the /24 as well. He can't afford to be down for nine hours - his line to the other Vendor has failed three times in the last years for a total out of server duration of four days - and that's Sprintlink. So indeed there is a need for him to lie so that he can get a block that will route if filters are going to drop him. /* Mike Lieberman Mike at NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ > -----Original Message----- > From: Pete Bowden [mailto:repete at cncx.com] > Sent: Monday, June 05, 2000 5:06 PM > To: Mike at netwright.net > Cc: arin-discuss at arin.net > Subject: Re: route filtering policies (from "split b" thread) > > > Yes, but in your case you should be announcing your larger agregate... > so... since your customer should still be reachable from you > if the route > is filtered they will not see the more specific and will see > the agregate > and route the block to you... you in turn will hand it over > to your customer. > No need for them to lie about anything.... you just need to > make the case to > them that this is how it works for technical reasons beyond > your ability to > control -- technical reasons being limiting bandwidth and > other providers > not feeling like they should be compelled to provide free > passage of other > peoples blocks. > > > > > This conversation about filter leaves me scratching my head. > > > > Some of you are making a specific assumption that only > large bandwidth, large > > block users must multihome between various providers. While > I do not argue > > that this is the most common situation, it is not the only > situation. > > > > We support one company that is currently multi-homed > between two providers > > and will likely be adding a third. No line is larger than a > T1. The customer > > barely needs a /24. So we provide the customer a /24. He > then announces this > > network to his other vendor as well as through us. > > > > If this customers routes get filtered because the company's > address block > > isn't large enough, the only thing you are doing to placing > pressure on the > > customer to fake the need for more IP addresses so that > their network gets > > announced and carried by more networks. Am I the only one > who thinks that > > such filtering policies are counter intuitive? > > > > The need to preserve IP space is at odds with the needs to > hold down the size > > of the BPG announcements. ARIN members needs to make a > choice. I don't like > > rules that force my customers to lie to me or suffer poor routing. > > > > /* Mike Lieberman Mike at NetWright.Net */ > > /* President */ > > /* Net Wright LLC */ > > /* http://www.netwright.net/ */ > > /* Voice and Fax: 307-857-1053 */ > > > > > -- > Pete Bowden, Internet Network Engineer, Internet & Data > Center Engineering > rePete at concentric.com rePete at cncx.com pete at internex.net NIC:PB8 > Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, > CA 95126-3429 > Voice: 408-808-6010 Fax: 408-808-6010 > From repete at cncx.com Mon Jun 5 20:21:21 2000 From: repete at cncx.com (Pete Bowden) Date: Mon, 5 Jun 2000 17:21:21 -0700 (PDT) Subject: route filtering policies (from "split b" thread) In-Reply-To: <000001bfcf47$09c38760$dd0ca9d8@netwright.net> from "Mike Lieberman" at Jun 05, 2000 05:37:38 PM Message-ID: <200006060021.RAA08480@skylab.eng.internex.net> A customer that has a /24 from you will have a hard time justifying a /20 or 21 to ARIN. You're right, in the case of a failure, there may be issues... and ARIN doesn't guarantee that routes of any size will be announced or accepted anywhere on the net. If you are willing to accept your own announcements from others then you might still have a route to your customer when your circuit goes down via their other provider... that's your choice... Announcing the entire internet as /24's just isn't scaleable, and the needs of the large players are sometimes at odds with the desires of smaller providers or collocation/server/hosting providers -- who are more likely to make that sale on the type of one-off or exception, where many of the larger players will just say that they can't guarantee that a dual homed connection will work in the case of either providers circuit failing. > > Let's start with the fact that my customer also has to be seen out the OTHER > ROUTE that belongs to ANOTHER vendor. If we agregated the customer then we > announce him even when his line to us is down. It has gone done once in the > last year and it took the local ILEC over nine hours to fix it. His route to > me MUST disappear when I am not carrying him so that all traffic will flow > to the other vendor who is announcing the /24 as well. > > He can't afford to be down for nine hours - his line to the other Vendor has > failed three times in the last years for a total out of server duration of > four days - and that's Sprintlink. > > So indeed there is a need for him to lie so that he can get a block that > will route if filters are going to drop him. > > /* Mike Lieberman Mike at NetWright.Net */ > /* President */ > /* Net Wright LLC */ > /* http://www.netwright.net */ > /* Voice and Fax: 307-857-1053 */ > > > -----Original Message----- > > From: Pete Bowden [mailto:repete at cncx.com] > > Sent: Monday, June 05, 2000 5:06 PM > > To: Mike at netwright.net > > Cc: arin-discuss at arin.net > > Subject: Re: route filtering policies (from "split b" thread) > > > > > > Yes, but in your case you should be announcing your larger agregate... > > so... since your customer should still be reachable from you > > if the route > > is filtered they will not see the more specific and will see > > the agregate > > and route the block to you... you in turn will hand it over > > to your customer. > > No need for them to lie about anything.... you just need to > > make the case to > > them that this is how it works for technical reasons beyond > > your ability to > > control -- technical reasons being limiting bandwidth and > > other providers > > not feeling like they should be compelled to provide free > > passage of other > > peoples blocks. > > > > > > > > This conversation about filter leaves me scratching my head. > > > > > > Some of you are making a specific assumption that only > > large bandwidth, large > > > block users must multihome between various providers. While > > I do not argue > > > that this is the most common situation, it is not the only > > situation. > > > > > > We support one company that is currently multi-homed > > between two providers > > > and will likely be adding a third. No line is larger than a > > T1. The customer > > > barely needs a /24. So we provide the customer a /24. He > > then announces this > > > network to his other vendor as well as through us. > > > > > > If this customers routes get filtered because the company's > > address block > > > isn't large enough, the only thing you are doing to placing > > pressure on the > > > customer to fake the need for more IP addresses so that > > their network gets > > > announced and carried by more networks. Am I the only one > > who thinks that > > > such filtering policies are counter intuitive? > > > > > > The need to preserve IP space is at odds with the needs to > > hold down the size > > > of the BPG announcements. ARIN members needs to make a > > choice. I don't like > > > rules that force my customers to lie to me or suffer poor routing. > > > > > > /* Mike Lieberman Mike at NetWright.Net */ > > > /* President */ > > > /* Net Wright LLC */ > > > /* http://www.netwright.net/ */ > > > /* Voice and Fax: 307-857-1053 */ > > > > > > > > > -- > > Pete Bowden, Internet Network Engineer, Internet & Data > > Center Engineering > > rePete at concentric.com rePete at cncx.com pete at internex.net NIC:PB8 > > Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, > > CA 95126-3429 > > Voice: 408-808-6010 Fax: 408-808-6010 > > > -- Pete Bowden, Internet Network Engineer, Internet & Data Center Engineering rePete at concentric.com rePete at cncx.com pete at internex.net NIC:PB8 Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, CA 95126-3429 Voice: 408-808-6010 Fax: 408-808-6010 From Mike at netwright.net Mon Jun 5 20:37:21 2000 From: Mike at netwright.net (Mike Lieberman) Date: Mon, 5 Jun 2000 18:37:21 -0600 Subject: route filtering policies (from "split b" thread) In-Reply-To: <200006060021.RAA08480@skylab.eng.internex.net> Message-ID: <000101bfcf4f$61351ce0$dd0ca9d8@netwright.net> In the cases we deal with it's an essential requirement for these companies. Lines in our neck of the world are unreliable and unless the customer falsifies a need for more IP we need to find a way to make this work. I am not saying that we shouldn't aggregate whenever possible. To suggest that /24 need to be routed, doesn't equate to we should route everything as a /24. To make such an argument doesn't serve the purpose of discussion. >Announcing the entire internet as /24's just isn't scaleable There are legitimate needs to be able to fully route a /24 on occasion and to say, well that's just the say it is, makes companies lie so that they can get the /20 that will route. These are not necessarily small companies by annual revenues. They just don't have a need for more than a /24. The policies of the large vendors who insist on filtering, do more to serve the business objectives of those vendors, than they do to protect the scalability of the Internet. /* Mike Lieberman Mike at NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ > -----Original Message----- > From: Pete Bowden [mailto:repete at cncx.com] > Sent: Monday, June 05, 2000 6:21 PM > To: Mike at netwright.net > Cc: arin-discuss at arin.net > Subject: Re: route filtering policies (from "split b" thread) > > > A customer that has a /24 from you will have a hard time > justifying a /20 or > 21 to ARIN. You're right, in the case of a failure, there > may be issues... > and ARIN doesn't guarantee that routes of any size will be > announced or > accepted anywhere on the net. If you are willing to accept your own > announcements from others then you might still have a route > to your customer > when your circuit goes down via their other provider... that's your > choice... Announcing the entire internet as /24's just isn't > scaleable, and > the needs of the large players are sometimes at odds with the > desires of > smaller providers or collocation/server/hosting providers -- > who are more > likely to make that sale on the type of one-off or exception, > where many of > the larger players will just say that they can't guarantee > that a dual homed > connection will work in the case of either providers circuit > failing. > > > > > Let's start with the fact that my customer also has to be > seen out the OTHER > > ROUTE that belongs to ANOTHER vendor. If we agregated the > customer then we > > announce him even when his line to us is down. It has gone > done once in the > > last year and it took the local ILEC over nine hours to fix > it. His route to > > me MUST disappear when I am not carrying him so that all > traffic will flow > > to the other vendor who is announcing the /24 as well. > > > > He can't afford to be down for nine hours - his line to the > other Vendor has > > failed three times in the last years for a total out of > server duration of > > four days - and that's Sprintlink. > > > > So indeed there is a need for him to lie so that he can get > a block that > > will route if filters are going to drop him. > > > > /* Mike Lieberman Mike at NetWright.Net */ > > /* President */ > > /* Net Wright LLC */ > > /* http://www.netwright.net */ > > /* Voice and Fax: 307-857-1053 */ > > > > > -----Original Message----- > > > From: Pete Bowden [mailto:repete at cncx.com] > > > Sent: Monday, June 05, 2000 5:06 PM > > > To: Mike at netwright.net > > > Cc: arin-discuss at arin.net > > > Subject: Re: route filtering policies (from "split b" thread) > > > > > > > > > Yes, but in your case you should be announcing your > larger agregate... > > > so... since your customer should still be reachable from you > > > if the route > > > is filtered they will not see the more specific and will see > > > the agregate > > > and route the block to you... you in turn will hand it over > > > to your customer. > > > No need for them to lie about anything.... you just need to > > > make the case to > > > them that this is how it works for technical reasons beyond > > > your ability to > > > control -- technical reasons being limiting bandwidth and > > > other providers > > > not feeling like they should be compelled to provide free > > > passage of other > > > peoples blocks. > > > > > > > > > > > This conversation about filter leaves me scratching my head. > > > > > > > > Some of you are making a specific assumption that only > > > large bandwidth, large > > > > block users must multihome between various providers. While > > > I do not argue > > > > that this is the most common situation, it is not the only > > > situation. > > > > > > > > We support one company that is currently multi-homed > > > between two providers > > > > and will likely be adding a third. No line is larger than a > > > T1. The customer > > > > barely needs a /24. So we provide the customer a /24. He > > > then announces this > > > > network to his other vendor as well as through us. > > > > > > > > If this customers routes get filtered because the company's > > > address block > > > > isn't large enough, the only thing you are doing to placing > > > pressure on the > > > > customer to fake the need for more IP addresses so that > > > their network gets > > > > announced and carried by more networks. Am I the only one > > > who thinks that > > > > such filtering policies are counter intuitive? > > > > > > > > The need to preserve IP space is at odds with the needs to > > > hold down the size > > > > of the BPG announcements. ARIN members needs to make a > > > choice. I don't like > > > > rules that force my customers to lie to me or suffer > poor routing. > > > > > > > > /* Mike Lieberman > Mike at NetWright.Net */ > > > > /* President > */ > > > > /* Net Wright LLC > */ > > > > /* http://www.netwright.net/ > */ > > > > /* Voice and Fax: 307-857-1053 > */ > > > > > > > > > > > > > -- > > > Pete Bowden, Internet Network Engineer, Internet & Data > > > Center Engineering > > > rePete at concentric.com rePete at cncx.com > pete at internex.net NIC:PB8 > > > Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, > > > CA 95126-3429 > > > Voice: 408-808-6010 Fax: 408-808-6010 > > > > > > > > -- > Pete Bowden, Internet Network Engineer, Internet & Data > Center Engineering > rePete at concentric.com rePete at cncx.com pete at internex.net NIC:PB8 > Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, > CA 95126-3429 > Voice: 408-808-6010 Fax: 408-808-6010 > From cjw at remarque.org Mon Jun 5 20:59:45 2000 From: cjw at remarque.org (cjw at remarque.org) Date: Mon, 05 Jun 2000 17:59:45 -0700 Subject: route filtering policies (from "split b" thread) In-Reply-To: Your message of "Mon, 05 Jun 2000 18:37:21 MDT." <000101bfcf4f$61351ce0$dd0ca9d8@netwright.net> Message-ID: <200006060059.RAA01610@pox.remarque.org> Mike, I hesitate to participate in this discussion because it has been beaten to death over and over again. But since I am on the ARIN Advisory Council and this is one of the things that we are trying to deal with, I have some questions for you. >Announcing the entire internet as /24's just isn't scaleable There are legitimate needs to be able to fully route a /24 on occasion and to say, well that's just the say it is, makes companies lie so that they can get the /20 that will route. How would you define exactly how to identify one of these organizations? One of the issues being dealt with by ARIN and the other registries is how to determine who has a legitimate need and who doesn't. Further when we can determine who has a legitimate need, then we could actually determine how many there might be and what the impact on the routing table would be. For example, ARIN would start seeing requests for people like me who have a sizable network in their home and want redundancy. Should I get a globally routable /24? My home network is important. (at least I think it is) What if I need a /28? Should that be routed as well? These are not necessarily small companies by annual revenues. They just don't have a need for more than a /24. The policies of the large vendors who insist on filtering, do more to serve the business objectives of those vendors, than they do to protect the scalability of the Internet. Most of the folks I know who filter do it to keep their networks working and for no other reason. Thanks for your input. ---CJ From hostmaster at verant.com Mon Jun 5 21:31:27 2000 From: hostmaster at verant.com (Hostmaster, Verant) Date: Mon, 5 Jun 2000 18:31:27 -0700 Subject: route filtering policies (from "split b" thread) Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBB1@mail-la.station.sony.com> I understand what you are saying, and I could accept it and be on my way if this was the consistent message from all. But there are many major ISPs that will accept any /24 and shorter. Why some would filter and many others would not does not make sense. The 78K routes on my router take up 13MB of space. Again, I can understand filtering some of the older class A's and B's, where it truley is a case of ISPs that lease pieces of their network space to customers, and an aggregate route is usually all that's needed to get to their customers efficiently. But in the case of 24.*.*.* and 64.*.*.*, where smaller blocks are given out. I'm looking through my bgp tables, and see hundreds of routes that are longer than /20 in both. One question has still not been answered is - what is the smallest block of 64/8 that ARIN will assign? But really my main point is - if many large ISPs are willing to simply accept all /24 and shorter, why won't the others that are in the minority follow suit? ---- Dani Roisman Verant Interactive hostmaster at verant.com (310) 840-8753 > -----Original Message----- > From: cwinter at communicationnation.com > [SMTP:cwinter at communicationnation.com] > Sent: Monday, June 05, 00 3:18 PM > To: Hostmaster, Verant; 'Paul A Vixie' > Cc: arin-discuss at arin.net; Brent Walters; Joe Murray > Subject: Re: route filtering policies (from "split b" thread) > > Dani, > > At present there are about 40,000 some-odd CIDR routes being propagated. > This takes just shy of 64meg. on a Cisco router - you can go to a publicly > available route server to check this out - so we all order border routers > with a minimum of 128 Meg. If no agriagation was done, it would be very > easy > to exceed the maximum available memory a Cisco router can handle - at > present 256Meg. It does not take a lot of CPU to forward and receive route > updates. > > EBGP - Exterior BGP (vs. IntereiorBGP) does not like to announce subnetted > /24 - thank goodness. Good policy is to aggrigate as much as possible, and > this is the force driving Router Arbiter Data Bases. To try to keep the > Internet from "flyingh apart" as one company put it. > > A /20 is the smallest usuall allocation ARIN will make - there are a few > exceptions ... > > Charles Winter > cwinter at communicationnation.com > > > ----- Original Message ----- > From: Hostmaster, Verant > To: 'Paul A Vixie' > Cc: > Sent: Monday, June 05, 2000 2:30 PM > Subject: RE: route filtering policies (from "split b" thread) > > > > Our situation is that we are multihomed to a few providors at each > location, > > but not necessarily with a backbone-grade link between each physical > > location. We do not resell connectivity, but use it all for our own > > Internet application serving. > > > > So it's not really that irresponsible, in that we cannot just take > blocks > > from our providers. I know of providers that accept as small as /24s, > and > I > > know of networks that announce /23s and /24s and have no aggregate to > fall > > back on. In fact in the case I described, we were able to affect a > change, > > which was prohibiting many cablemodem customers from accessing not only > us, > > but the network of a large ISP. > > > > But perhaps you can shed some light on the question asked by another on > this > > thread - why exactly would you filter on anything shorter than a /24? > RAM > > on your routers? CPU? On my network, I want to pick up as specific > routes > > (well, up to /24) as the other network wants to announce to me - chances > are > > I'll get a better connection using a more specific prefix. > > > > Follow up question - where do you come up with /20 as the magic length > for > > class A's and B's, but /24 for class C's? > > > > Additionally, ARIN is now handing out 64.0.0.0/8 in smaller blocks. > Perhaps > > someone on this list can speak to the smallest block being handed out in > > 64.0.0.0/8. > > > > ---- > > Dani Roisman > > Verant Interactive > > hostmaster at verant.com > > (310) 840-8753 > > > > > > > -----Original Message----- > > > From: Paul A Vixie [SMTP:vixie at mibh.net] > > > Sent: Monday, June 05, 00 2:04 PM > > > To: Hostmaster, Verant > > > Cc: 'arin-discuss at arin.net'; Network Operations > > > Subject: Re: route filtering policies (from "split b" thread) > > > > > > > Thanks for the URL... hm.. /20 and shorter only in 64/8? That's a > bit > > > > strict, no? We have different networks off our 64.34.128/18 block, > > > which we > > > > would like to announce in /21 and /22 blocks. There's a good chance > we > > > > won't aggregate, since the networks might each have OC3 or OC12 > links > to > > > the > > > > Internet, but in some places as slow as T1 between the two networks, > and > > > I > > > > wouldn't want to backhaul accross the T1. > > > > > > that's an incredibly irresponsible way to build a net. if you're > going > to > > > be a transit aggregator, then by all means get small blocks your > providers > > > and pay them extra to get cutouts. the expectation we all have when > you > > > get > > > an address block is that you intend to advertise it, not carve it up. > > > > > > > Who should I contact at Verio to discuss losening the filtering > policy? > > > > > > won't help. see http://www.mibh.net/mibh-peering.html and know that > if > > > you > > > tried to get us to loosen it we would definitely not. there are > dozens > if > > > not hundreds of nets running with this policy. the thing to change is > > > your > > > plan, not the commonly implemented route filtering policy of the whole > > > 'net. From Mike at netwright.net Mon Jun 5 22:16:26 2000 From: Mike at netwright.net (Mike Lieberman) Date: Mon, 5 Jun 2000 20:16:26 -0600 Subject: route filtering policies (from "split b" thread) In-Reply-To: <200006060059.RAA01610@pox.remarque.org> Message-ID: <000301bfcf5d$38a663c0$dd0ca9d8@netwright.net> > Mike, > > I hesitate to participate in this discussion because it has > been beaten to death over and over again. But since I am on > the ARIN Advisory Council and this is one of the things that > we are trying to deal with, I have some questions for you. > > >Announcing the entire internet as /24's just isn't scaleable > > There are legitimate needs to be able to fully route a > /24 on occasion and > to say, well that's just the say it is, makes companies > lie so that they can > get the /20 that will route. > > How would you define exactly how to identify one of these > organizations? Look I understand the frustration you are all having with this... but let's say ARIN sells /24's for $2.500/yr. You really need it for your home now? You need a router and bandwidth capable of full BGP. Vendors who will take your BGP. You're not going to use ISDN, cable modems, xDSL or a inexpensive router. The cost alone if structured correctly can provide a reasonable self-selective system by which most networks won't want the costs or the hassles. I actually attended a meeting as a consultant to a company that will go unnamed. They have a /21 and there was a disussion about putting everything behind a firewall and using private IP. The head of their IT group pointed out that they would lose their ability to router their network as they were doing via BGP and would put the company at risk. That was the end of the discussion. Like I said early on in this discussion. You have two competing needs. Address space and routing tables. By not making a rational choice, you simple produce decisions that have adverse impacts. I think you need to say OK, if have multiple paths, the right router, you are willing to pay, then you get X address space and that WILL route, whether you need that much space or not. Set it low enough so that you can live with the waste and high enough so that tables don't break for the few who will pay for it(I think a /24 fits if the cost to get it is high enough). And then don't make the user justify the network need for the size of the block. The only justifaction comes if the request if for more numbers. > One of the issues being dealt with by ARIN and the other registries > is how to determine who has a legitimate need and who doesn't. Further > when we can determine who has a legitimate need, then we > could actually > determine how many there might be and what the impact on the routing > table would be. For example, ARIN would start seeing requests for > people like me who have a sizable network in their home and want > redundancy. Should I get a globally routable /24? My home network > is important. (at least I think it is) What if I need a /28? Should > that be routed as well? > > These are not necessarily small companies by annual > revenues. They just > don't have a need for more than a /24. The policies of > the large vendors who > insist on filtering, do more to serve the business > objectives of those > vendors, than they do to protect the scalability of the Internet. > > Most of the folks I know who filter do it to keep their networks > working and for no other reason. > > Thanks for your input. > ---CJ > /* Mike Lieberman Mike at NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ From Mike at netwright.net Mon Jun 5 23:01:53 2000 From: Mike at netwright.net (Mike Lieberman) Date: Mon, 5 Jun 2000 21:01:53 -0600 Subject: route filtering policies (from "split b" thread) In-Reply-To: <200006060232.TAA02375@pox.remarque.org> Message-ID: <000401bfcf63$91efff80$dd0ca9d8@netwright.net> > > Mike, > > Thanks for your response. Note that it isn't necessarily true > that I have to have full internet routes on my router at home > in order to inject a /24 via BGP to two upstream providers. Yes I'm aware of this, but it is possible to limit this discussion to those networks that DO have that need. Others can limp along as they do now. > > Note also that ARIN cannot guarantee that any block assigned > is filtered or not filtered. ISPs set their own policies. > Those policies have up to this point been modified as ARIN > and other registries have changed their allocation policies > but there is no guarantee that that will continue to be the > case. There was a point in my not so distant past, where > the filtering policies of one very large ISP were not consistent > with ARIN policies and it made my address space unusable (and > we had much more than a /21) I understand this as well. The policies of various RRs can make for a frustrating time. Still most of that can be worked through. > > How many requests would be generated if, say, we say any > organization that meets your requirements below gets a /24? I think you already have them, they just have /21's right now :-) Further if you did a buy back program for those who have swamp addresses and could aggregate with new addresses and use the money you get from the sale of the /24's to support that, you might actually get more /24's back than you have to sell. > I suspect that you will get many many more than a "few". I > could be wrong, but the issue for ARIN and the other registries > is that the take rate for some of these things is not determinable. > Further once the policy is changed, it is almost impossible to > change it back. So, do the buy back first and limit the new /24's to the number of /24's you recoup. Then there's no harm done. > On average how many connections do you think that these folks > would have? (paths matter) > Well that gets hard to figure. Our customer is looking at going from two to three or four. We just about signed a contract with another company earlier this year that would have had three paths. > Thanks, > ---CJ > > Ps. and yes I might be interested in one of those /24s for my > house. > Yeh, well would you accept the proposition that we are not the normal net user? I had two T1s to my house when your local community college had a 56K lease line. > > From: "Mike Lieberman" > Subject: RE: route filtering policies (from "split b" thread) > > > Mike, > > > > I hesitate to participate in this discussion because it has > > been beaten to death over and over again. But since I am on > > the ARIN Advisory Council and this is one of the things that > > we are trying to deal with, I have some questions for you. > > > > >Announcing the entire internet as /24's just isn't > scaleable > > > > There are legitimate needs to be able to fully route a > > /24 on occasion and > > to say, well that's just the say it is, makes companies > > lie so that they can > > get the /20 that will route. > > > > How would you define exactly how to identify one of these > > organizations? > > Look I understand the frustration you are all having with > this... but let's > say ARIN sells /24's for $2.500/yr. You really need it > for your home now? > > You need a router and bandwidth capable of full BGP. > Vendors who will take > your BGP. You're not going to use ISDN, cable modems, > xDSL or a inexpensive > router. The cost alone if structured correctly can > provide a reasonable > self-selective system by which most networks won't want > the costs or the > hassles. > > I actually attended a meeting as a consultant to a > company that will go > unnamed. They have a /21 and there was a disussion about > putting everything > behind a firewall and using private IP. The head of their > IT group pointed > out that they would lose their ability to router their > network as they were > doing via BGP and would put the company at risk. That was > the end of the > discussion. Like I said early on in this discussion. You > have two competing > needs. Address space and routing tables. By not making a > rational choice, > you simple produce decisions that have adverse impacts. > > I think you need to say OK, if have multiple paths, the > right router, you > are willing to pay, then you get X address space and that > WILL route, > whether you need that much space or not. Set it low > enough so that you can > live with the waste and high enough so that tables don't > break for the few > who will pay for it(I think a /24 fits if the cost to get > it is high > enough). And then don't make the user justify the network > need for the size > of the block. The only justifaction comes if the request > if for more > numbers. > > > One of the issues being dealt with by ARIN and the > other registries > > is how to determine who has a legitimate need and who > doesn't. Further > > when we can determine who has a legitimate need, then we > > could actually > > determine how many there might be and what the impact > on the routing > > table would be. For example, ARIN would start seeing > requests for > > people like me who have a sizable network in their home and want > > redundancy. Should I get a globally routable /24? My > home network > > is important. (at least I think it is) What if I need > a /28? Should > > that be routed as well? > > > > These are not necessarily small companies by annual > > revenues. They just > > don't have a need for more than a /24. The policies of > > the large vendors who > > insist on filtering, do more to serve the business > > objectives of those > > vendors, than they do to protect the scalability of > the Internet. > > > > Most of the folks I know who filter do it to keep their networks > > working and for no other reason. > > > > Thanks for your input. > > ---CJ > > > > > > /* Mike Lieberman Mike at NetWright.Net */ > /* President */ > /* Net Wright LLC */ > /* http://www.netwright.net */ > /* Voice and Fax: 307-857-1053 */ > > > From ppopper at onramp.ca Mon Jun 5 23:14:32 2000 From: ppopper at onramp.ca (Paul Popper) Date: Mon, 05 Jun 2000 23:14:32 -0400 Subject: route filtering policies (from "split b" thread) In-Reply-To: <000301bfcf5d$38a663c0$dd0ca9d8@netwright.net> References: <200006060059.RAA01610@pox.remarque.org> Message-ID: <4.3.2.7.0.20000605224901.00aa0e40@pop.tor.onramp.ca> At 10:16 PM 6/5/00, Mike Lieberman wrote: >... >Look I understand the frustration you are all having with this... but let's >say ARIN sells /24's for $2.500/yr. You really need it for your home now? >... >I think you need to say OK, if have multiple paths, the right router, you >are willing to pay, then you get X address space and that WILL route, >whether you need that much space or not. Set it low enough so that you can >live with the waste and high enough so that tables don't break for the few >who will pay for it(I think a /24 fits if the cost to get it is high >enough). And then don't make the user justify the network need for the size >of the block. The only justifaction comes if the request if for more >numbers. Yes, the scarce resource, i.e. the implied BGP table usage, should be paid for by its consumer. I strongly agree that ARIN should start selling those /24s that are unlikely to be filtered for a price that strikes the kind of balance Mike describes. This will both increase Internet reliability and likely reduce ip space wastage. Paul. From cjw at remarque.org Mon Jun 5 23:46:02 2000 From: cjw at remarque.org (cjw at remarque.org) Date: Mon, 05 Jun 2000 20:46:02 -0700 Subject: route filtering policies (from "split b" thread) In-Reply-To: Your message of "Mon, 05 Jun 2000 21:01:53 MDT." <000401bfcf63$91efff80$dd0ca9d8@netwright.net> Message-ID: <200006060346.UAA02690@pox.remarque.org> From: "Mike Lieberman" Subject: RE: route filtering policies (from "split b" thread) > > Mike, > > Thanks for your response. Note that it isn't necessarily true > that I have to have full internet routes on my router at home > in order to inject a /24 via BGP to two upstream providers. Yes I'm aware of this, but it is possible to limit this discussion to those networks that DO have that need. Others can limp along as they do now. Sure if you can define who really has the need and criteria that can be used to determine one from another. I know of a number of companies that need to be multihomed that have no requirement for full BGP tables in their routers. > > How many requests would be generated if, say, we say any > organization that meets your requirements below gets a /24? I think you already have them, they just have /21's right now :-) Further if you did a buy back program for those who have swamp addresses and could aggregate with new addresses and use the money you get from the sale of the /24's to support that, you might actually get more /24's back than you have to sell. > I suspect that you will get many many more than a "few". I > could be wrong, but the issue for ARIN and the other registries > is that the take rate for some of these things is not determinable. > Further once the policy is changed, it is almost impossible to > change it back. So, do the buy back first and limit the new /24's to the number of /24's you recoup. Then there's no harm done. I doubt that the registries will be able to recoup much if any swamp space. THat is another issue all together. I also think that there are a lot more folks who will apply for this space than you think. Swamp folks have no requirement to apply since they have what they want. Again, it all comes down to coming up with criteria that will allow the registries to assess who gets them and who doesnt. From that we can get some idea of how many there might be assigned and then we will have to work with the community (including ISPs) to determine whether doing it will be good for the network as a whole. The registries have to have a policy that can be written down and applied fairly. They can't just pick who has a need on the fly. > > Ps. and yes I might be interested in one of those /24s for my > house. > Yeh, well would you accept the proposition that we are not the normal net user? I had two T1s to my house when your local community college had a 56K lease line. Maybe not, but my point is that everyone thinks that their connection and their application is critical and has to be redundant and have whatever that requires. A lot more than you think will probably pay. There are webhosting sites (should we give them portable /32s? ) These are the issues that we are facing. Opening the flood gates without some careful analysis of who gets the space and what it will do to the internet as a whole, is not a good idea. From Mike at netwright.net Tue Jun 6 00:14:29 2000 From: Mike at netwright.net (Mike Lieberman) Date: Mon, 5 Jun 2000 22:14:29 -0600 Subject: route filtering policies (from "split b" thread) In-Reply-To: <200006060346.UAA02690@pox.remarque.org> Message-ID: <000501bfcf6d$b619eb00$dd0ca9d8@netwright.net> > -----Original Message----- > From: cjw at remarque.org [mailto:cjw at remarque.org] > Sent: Monday, June 05, 2000 9:46 PM > To: Mike at netwright.net > Cc: arin-discuss at arin.net > Subject: Re: route filtering policies (from "split b" thread) > > > From: "Mike Lieberman" > Subject: RE: route filtering policies (from "split b" thread) > > > > Mike, > > > > Thanks for your response. Note that it isn't necessarily true > > that I have to have full internet routes on my router at home > > in order to inject a /24 via BGP to two upstream providers. > > Yes I'm aware of this, but it is possible to limit this > discussion to those > networks that DO have that need. Others can limp along as > they do now. > > Sure if you can define who really has the need and criteria that > can be used to determine one from another. I know of a number of > companies that need to be multihomed that have no requirement > for full BGP tables in their routers. I don't have to define that. You keep on trying to place the decision making within ARIN and I am arguing for a market approach where you don't need to apply the criteria. Assume the applicant WILL fully route. If the applicant doesn't where's the foul? > > > > > How many requests would be generated if, say, we say any > > organization that meets your requirements below gets a /24? > > I think you already have them, they just have /21's right > now :-) Further if > you did a buy back program for those who have swamp > addresses and could > aggregate with new addresses and use the money you get > from the sale of the > /24's to support that, you might actually get more /24's > back than you have > to sell. > > > I suspect that you will get many many more than a "few". I > > could be wrong, but the issue for ARIN and the other registries > > is that the take rate for some of these things is not > determinable. > > Further once the policy is changed, it is almost impossible to > > change it back. > > So, do the buy back first and limit the new /24's to the > number of /24's you > recoup. Then there's no harm done. > > I doubt that the registries will be able to recoup much if any swamp > space. THat is another issue all together. I also think that there > are a lot more folks who will apply for this space than you think. > Swamp folks have no requirement to apply since they have what they > want. Again, it all comes down to coming up with criteria that will > allow the registries to assess who gets them and who doesnt. From > that we can get some idea of how many there might be assigned and > then we will have to work with the community (including ISPs) to > determine whether doing it will be good for the network as a whole. It's hard to discuss other than to say I disagree. Make it worth enough to companies to trade in the swamp space and companies will. I don't mean to offend, but I just have to ask? Have you ever run a true commercial enterprise? Not just work for one? I have no doubt that the swamp space can be reclaimed at least in part. > > The registries have to have a policy that can be written down and > applied fairly. They can't just pick who has a need on the fly. Never suggested otherwise. Right now the rules are arbitrary and tilt to certain types of companies over others. That is the complaint. Things are not fair now. > > > > Ps. and yes I might be interested in one of those /24s for my > > house. > > > > Yeh, well would you accept the proposition that we are > not the normal net > user? > I had two T1s to my house when your local community > college had a 56K lease > line. > > Maybe not, but my point is that everyone thinks that their connection > and their application is critical and has to be redundant and have > whatever that requires. And who are you or me to say otherwise. This continues to be my point. You are laying values on others right now. > A lot more than you think will probably pay. I don't think you have any clue how much this is worth to some companies. > There are webhosting sites (should we give them portable /32s? ) > These are the issues that we are facing. Opening the flood gates > without some careful analysis of who gets the space and what it > will do to the internet as a whole, is not a good idea. > I suggest /24 and you come back with a facetious /32. Why? Are the sacred cows at risk? You know damned well that web hosting sites are just that, sites of hundreds of web sites on one network. We are talking about networks. Such arguments are not helpful in the development of sound public policy. /* Mike Lieberman Mike at NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ From jerry at fc.net Tue Jun 6 00:28:44 2000 From: jerry at fc.net (Jeremy Porter) Date: Mon, 05 Jun 2000 23:28:44 -0500 Subject: split b In-Reply-To: Your message of "Mon, 05 Jun 2000 10:37:55 PDT." <200006051737.KAA02756@vacation.karoshi.com> Message-ID: <200006060428.XAA23658@freeside.fc.net> In message <200006051737.KAA02756 at vacation.karoshi.com>, bmanning at vacation.karo shi.com writes: >> The problem becomes then, assuming ARIN did approve the rejustification, >> that there is no mechanism at ARIN or elsewhere to provide notifications >> of current "delegation models" which inidicate what size blocks are >> allocated out of what size ranges. ARIN does operate a Routing Registry >> in which this information could be stored programaticlly which could >> be queried programaticly or manually to check BGP announcements v. >> RIR assignment or allocation. > > ARINs use of registry technology post-dates this split. > One presumes that Mr. Bush pulled the relevent information > from the ARIN routing registry via whois. ARIN's use of "registry technology" i.e. the whois database? Their impelementation of a routing registry post dates it, but whois has been around for quite a while. I was only suggesting that a techical solution utilizing the ARIN Routing Registry might allow Randy to accomplish what he wants while allowing for a programatic way to generate his filters, as opposed to periodic emails from the various RIR with the lists of what is allocated where. >> I believe Randy is correct in his opinion that no policy decision was >> made with regard to making assignments out of "Classic B Space" of a >> prefix size of /17. (Which is what happened). However it seems clear >> to me that ARIN polices and guidelines allow for this to happen >> under the circumstances described. Thus it is important that >> we take this into consideration. > > Well, I beg to differ. A policy decision was made and the > split was done. This may have been done as a "one-off" but > it does provide a prior-use argument for future splits > to occur. I agree that existant ARIN policy (as I understand it) > will allow such splits to occur. Perhaps ISPs would begin > to realize that a blanket summarization of filtering is prone > to many errors, esp. due to historical delegations and policy > considerations that are now OBE but have been grandfathered in. > A policy decision here would imply that the ARIN Advisory Council voted on this, and I don't recall any such vote. The ARIN AC is specificly empowered to do this, but then we agree that we don't see any specific reason that would prevent this from reoccuring, and my suggestion of using the routing registries, or dns, or any such online database to store the policy info, would enable Randy and others to setup their filters in a way that reflects actual policy as opposed to blacket summarization which is prone to "error". I don't see this has a precedent for any "grandfathered" allocations. The only thing that has been grandfathered is the specific assignment was not required to be re-justified, until the split. I hate to say it Bill, but your agenda seems to be leaking through at least as much as Randy's. --- jerry at fc.net Director Network Operations/Network Engineering, Wayport, Inc. 512-519-6193 www.wayport.net 8303 Mopac Expressway Suite A300, Austin Tx. From noc at ultra.net Tue Jun 6 01:33:00 2000 From: noc at ultra.net (Stephen Griffin) Date: Tue, 6 Jun 2000 01:33:00 -0400 (EDT) Subject: route filtering policies (from "split b" thread) In-Reply-To: <000301bfcf5d$38a663c0$dd0ca9d8@netwright.net> from Mike Lieberman at "Jun 5, 2000 08:16:26 pm" Message-ID: <200006060533.BAA02158@elektra.ultra.net> In the referenced message, Mike Lieberman said: > > > Mike, > > > > How would you define exactly how to identify one of these > > organizations? > > Look I understand the frustration you are all having with this... but let's > say ARIN sells /24's for $2.500/yr. You really need it for your home now? Selling address space would be a _bad_ thing. Charging money to cover allocation record-keeping is fine, since it doesn't convey "ownership". We've already seen the perils with turning things into commodities (cf the domain naming system). > You need a router and bandwidth capable of full BGP. Vendors who will take > your BGP. You're not going to use ISDN, cable modems, xDSL or a inexpensive > router. The cost alone if structured correctly can provide a reasonable > self-selective system by which most networks won't want the costs or the > hassles. The costs of a cisco 25XX (which could handle 2 scaled-down bgp sessions quite happily), 2 modems, and 2 phone lines is hardly prohibitive. > I actually attended a meeting as a consultant to a company that will go > unnamed. They have a /21 and there was a disussion about putting everything > behind a firewall and using private IP. The head of their IT group pointed > out that they would lose their ability to router their network as they were > doing via BGP and would put the company at risk. That was the end of the > discussion. Like I said early on in this discussion. You have two competing > needs. Address space and routing tables. By not making a rational choice, > you simple produce decisions that have adverse impacts. The problem is that this entity runs the risk of forfeiture of _all_ of their address space. I saw somewhere in this thread someone mentioning a buy-back program for address space. That isn't necessary, since address space is delegated, not sold. Theoretically ICANN, the RIR's and the other registries (such as myself on behalf of my employer) have the right to rescind any allocation we have jurisdiction over. Hopefully, this is utilized extremely sparingly. > I think you need to say OK, if have multiple paths, the right router, you > are willing to pay, then you get X address space and that WILL route, > whether you need that much space or not. Set it low enough so that you can > live with the waste and high enough so that tables don't break for the few > who will pay for it(I think a /24 fits if the cost to get it is high > enough). And then don't make the user justify the network need for the size > of the block. The only justifaction comes if the request if for more > numbers. If you persist on BGP == redundancy, but that is hardly the only solution. > > One of the issues being dealt with by ARIN and the other registries > > is how to determine who has a legitimate need and who doesn't. Further > > when we can determine who has a legitimate need, then we > > could actually > > determine how many there might be and what the impact on the routing > > table would be. For example, ARIN would start seeing requests for > > people like me who have a sizable network in their home and want > > redundancy. Should I get a globally routable /24? My home network > > is important. (at least I think it is) What if I need a /28? Should > > that be routed as well? > > > > These are not necessarily small companies by annual > > revenues. They just > > don't have a need for more than a /24. The policies of > > the large vendors who > > insist on filtering, do more to serve the business > > objectives of those > > vendors, than they do to protect the scalability of the Internet. > > > > Most of the folks I know who filter do it to keep their networks > > working and for no other reason. > > > > Thanks for your input. > > ---CJ If someone has a need to have their allocation globally routed, and can justify a /24, they should request that it come from class C space to have the highest likelihood of the route being heard. However, a /24 from class A space (not counting like 24/8 64/8 etc) has a high likelihood of being dropped. If the entity _can't_ justify a /24, then they need to do something like colocate diverse machines with providers across the mesh, with something like a dns trick to direct people to the various colocations. 5 Providers 3 having service machines (web/mx/whatever) 2 having dns machines which check reachability of machines and services (dns boxes are supposed to be on different subnets anyways). If you _need_ redundancy, then you do the above, and pay the associated costs. It is highly unlikely that anyone is going to allow me to deaggregate 0/1 just so I can have redundancy at my house because I "need" it, or at the bar down the street, or the law-firm down the block. The size of the entity doesn't really matter much, whether it is just me, or Shodan Heavy Industries. You either can justify the address space, or you can not. If you can not, you still have options (number machines out of allocations provided by each of your upstreams and dns-twiddle), colocate around the mesh as noted above, where you even get geographical diversity to avoid things like a backhoe or terrorist taking out both of your redundant links by cutting close to your building or blowing it up. There are options which preserve engineering principles, conserve address space, and provide redundancy. These are the things which registries (whether RIRs or registries underneath them) should offer up to entities which require redundancy. Stephen -- Stephen A. Griffin RCN Senior Development Engineer Internet Planning & Design stephen.griffin at rcn.com Network Deployment & Management From Mike at netwright.net Tue Jun 6 10:01:06 2000 From: Mike at netwright.net (Mike Lieberman) Date: Tue, 6 Jun 2000 08:01:06 -0600 Subject: route filtering policies (from "split b" thread) In-Reply-To: <200006060533.BAA02158@elektra.ultra.net> Message-ID: <000601bfcfbf$a9a92140$dd0ca9d8@netwright.net> Stephen Griffin said: > > In the referenced message, Mike Lieberman said: > > > > > Mike, > > > > > > > How would you define exactly how to identify one of these > > > organizations? > > > > Look I understand the frustration you are all having with > this... but let's > > say ARIN sells /24's for $2.500/yr. You really need it for > your home now? > > Selling address space would be a _bad_ thing. Charging money to cover > allocation record-keeping is fine, since it doesn't convey > "ownership". > We've already seen the perils with turning things into commodities > (cf the domain naming system). > Well we disagree. ARIN is already charging a yearly fee for space and to make this argument now is goofy. As I said in an earlier email. All the current policy does is encourage some companies to lie about their needs. > > You need a router and bandwidth capable of full BGP. > Vendors who will take > > your BGP. You're not going to use ISDN, cable modems, xDSL > or a inexpensive > > router. The cost alone if structured correctly can provide > a reasonable > > self-selective system by which most networks won't want the > costs or the > > hassles. > > The costs of a cisco 25XX (which could handle 2 scaled-down > bgp sessions > quite happily), 2 modems, and 2 phone lines is hardly prohibitive. > Once again you're arguing a non-issue. Set the requirement at two full T1's with a CIsco 3640 and 128MB's if you like. > > I actually attended a meeting as a consultant to a company > that will go > > unnamed. They have a /21 and there was a disussion about > putting everything > > behind a firewall and using private IP. The head of their > IT group pointed > > out that they would lose their ability to router their > network as they were > > doing via BGP and would put the company at risk. That was > the end of the > > discussion. Like I said early on in this discussion. You > have two competing > > needs. Address space and routing tables. By not making a > rational choice, > > you simple produce decisions that have adverse impacts. > > The problem is that this entity runs the risk of forfeiture > of _all_ of > their address space. I saw somewhere in this thread someone mentioning > a buy-back program for address space. That isn't necessary, > since address > space is delegated, not sold. Theoretically ICANN, the RIR's and the > other registries (such as myself on behalf of my employer) > have the right > to rescind any allocation we have jurisdiction over. Hopefully, this > is utilized extremely sparingly. > Yes but the risk is forfeiture later or shutting down businesses today. Ever drive faster than the speed limit? How about when the limit was 55 on the interstates? Create unreasonable rules and you get rule breakers. Your hopes are forlorn and wrong. Not every or even most have a need to break the rules but those who do have a need, will. > > I think you need to say OK, if have multiple paths, the > right router, you > > are willing to pay, then you get X address space and that > WILL route, > > whether you need that much space or not. Set it low enough > so that you can > > live with the waste and high enough so that tables don't > break for the few > > who will pay for it(I think a /24 fits if the cost to get it is high > > enough). And then don't make the user justify the network > need for the size > > of the block. The only justifaction comes if the request if for more > > numbers. > > If you persist on BGP == redundancy, but that is hardly the > only solution. > Oh yes it is in some situtations. Your are arguing from an urban model not a rural one. > > > One of the issues being dealt with by ARIN and the other > registries > > > is how to determine who has a legitimate need and who > doesn't. Further > > > when we can determine who has a legitimate need, then we > > > could actually > > > determine how many there might be and what the impact on > the routing > > > table would be. For example, ARIN would start seeing requests for > > > people like me who have a sizable network in their home and want > > > redundancy. Should I get a globally routable /24? My > home network > > > is important. (at least I think it is) What if I need a > /28? Should > > > that be routed as well? > > > > > > These are not necessarily small companies by annual > > > revenues. They just > > > don't have a need for more than a /24. The policies of > > > the large vendors who > > > insist on filtering, do more to serve the business > > > objectives of those > > > vendors, than they do to protect the scalability of > the Internet. > > > > > > Most of the folks I know who filter do it to keep their networks > > > working and for no other reason. > > > > > > Thanks for your input. > > > ---CJ > > If someone has a need to have their allocation globally > routed, and can > justify a /24, they should request that it come from class C space to > have the highest likelihood of the route being heard. > However, a /24 from > class A space (not counting like 24/8 64/8 etc) has a high > likelihood of > being dropped. If the entity _can't_ justify a /24, then they need to > do something like colocate diverse machines with providers > across the mesh, > with something like a dns trick to direct people to the > various colocations. > Once again you are not looking at the rural model. If you ever worked in a region where a single fiber cut took ALL LD services away from 70% of the state subscribers for four hours, you'd start to appreciate how and why we use BGP to assure a messure of robustness. And you are assuming businesses which can, by their business model, colocate. This is not always the case. I agree with the concept of having just one region such as class C space where /24 is assured. It isn't now. > 5 Providers > 3 having service machines (web/mx/whatever) > 2 having dns machines which check reachability of machines > and services > (dns boxes are supposed to be on different subnets anyways). > > If you _need_ redundancy, then you do the above, and pay the > associated > costs. It is highly unlikely that anyone is going to allow me to > deaggregate 0/1 just so I can have redundancy at my house because > I "need" it, or at the bar down the street, or the law-firm > down the block. > The size of the entity doesn't really matter much, whether it is just > me, or Shodan Heavy Industries. You either can justify the > address space, > or you can not. If you can not, you still have options > (number machines > out of allocations provided by each of your upstreams and > dns-twiddle), > colocate around the mesh as noted above, where you even get > geographical > diversity to avoid things like a backhoe or terrorist taking out both > of your redundant links by cutting close to your building or > blowing it > up. There are options which preserve engineering principles, conserve > address space, and provide redundancy. These are the things which > registries (whether RIRs or registries underneath them) should offer > up to entities which require redundancy. This is a non-starter. A name will only resolve to one IP at a time and until that rule changes then those companies that require true always on technologies are going to get the ip space they need to assure routing. RIR's simply can't act fast enough and don't have a crisis emergency system for single networks. And even if they did, take a look at how long it takes cache to expire. There are very good reasons with the Rube Goldberg solutions you offer are not helpful and don't solve the fundamental problem. /* Mike Lieberman Mike at NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */