From owner-arin-discuss@arin.net Mon Aug 2 09:58:33 1999 Return-Path: Received: by ops.arin.net (8.9.0/8.9.0) id JAA29590 for arin-discuss-outgoing; Mon, 2 Aug 1999 09:49:24 -0400 (EDT) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id JAA29586 for ; Mon, 2 Aug 1999 09:49:23 -0400 (EDT) Message-Id: <4.1.19990802093820.01a12e10@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 02 Aug 1999 09:45:38 -0400 To: arin-discuss@arin.net From: Kim Hubbard Subject: Need show of support for ASO proposal Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Hello, The ICANN will be voting on whether to adopt the ASO proposal submitted by the RIRs during the Santiago, Chile ICANN meeting this month. It's very important that ICANN sees the support for this document from the ARIN members. Now personally, I think it'd be great if all of you just showed up in Santiago to show your support (we could have a great party) but since that's probably not going to happen I would appreciate those of you that do support this document to please send a short message to ICANN stating your support for the ASO proposal. Comments should be sent to comments@icann.org. BTW, for those of you that would like to go to the meeting in Santiago, info can be found at www.icann.org. Thanks for your help, Kim Hubbard ARIN From owner-arin-discuss@arin.net Mon Aug 30 12:29:30 1999 Return-Path: Received: by ops.arin.net (8.9.0/8.9.0) id MAA11222 for arin-discuss-outgoing; Mon, 30 Aug 1999 12:18:37 -0400 (EDT) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id MAA11218 for ; Mon, 30 Aug 1999 12:18:36 -0400 (EDT) Message-Id: <4.1.19990830120729.01a655e0@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 30 Aug 1999 12:12:44 -0400 To: arin-discuss@arin.net From: Kim Hubbard Subject: Need nominees for ARIN board and Advisory Seats Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_10875788==_.ALT" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR --=====================_10875788==_.ALT Content-Type: text/plain; charset="us-ascii" Please remember to submit nominations for open board and AC seats as soon as possible. We have questionnaires that we need all nominees to complete so they'll need some time to do this prior to nomcom review and posting of their names on our election webpage. To nominate an ARIN board member or Advisory Council member please see http://www.arin.net/members/ nominations99.htm Thanks, Kim --=====================_10875788==_.ALT Content-Type: text/html; charset="us-ascii"
Please remember to submit nominations for open board and AC seats as soon as possible. We have questionnaires that we need all nominees to complete so they'll need some time to do this prior to nomcom review and posting of their names on our election webpage.

To nominate an ARIN board member or Advisory Council member please see http://www.arin.net/members/nominations99.htm

Thanks,
Kim --=====================_10875788==_.ALT-- From owner-arin-discuss@arin.net Wed Sep 1 10:19:59 1999 Return-Path: Received: by ops.arin.net (8.9.0/8.9.0) id KAA04823 for arin-discuss-outgoing; Wed, 1 Sep 1999 10:12:49 -0400 (EDT) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id KAA04817 for ; Wed, 1 Sep 1999 10:12:47 -0400 (EDT) Message-Id: <4.1.19990901093515.01ac6eb0@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 01 Sep 1999 10:07:22 -0400 To: arin-discuss@arin.net From: Kim Hubbard Subject: ARIN MEMBER UPDATE: ASO APPROVED Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR MEMBER UPDATE: Last week in Santiago, Chile, the ICANN Board of Directors approved the ASO proposal submitted by the Regional Registries (ARIN, RIPE and APNIC). The next step is for the RIRs boards to draft the MOU. ICANN has given us a deadline of October 15 to nominate 3 ICANN Board of Directors from the ASO. Although the ASO proposal was approved there was a small contingent of organizations that opposed it on the basis that they should be represented directly in the ASO rather than through the RIRs. The major stated motivation of this group, which included AT&T, BT, France Telecom, Deutsche Telecom, ETSI and CIX, was to be sure that future allocation strategies take adequate recognition of the special requirements of telephony (especially mobile telephony) and IP convergence. In an attempt to satisfy the concerns raised by this contingent the ICANN Board approved the following resolution proposed by Hans Kraainjenbrink (ICANN Board member) to create an ad hoc committee: Formation of Ad Hoc Group "RESOLVED [99.__] that the Interim President and CEO, working with Director Kraaijenbrink, is directed to establish an ad hoc group to be charged with developing the objectives and proposing structures for future policies in the area of numbering, especially as required to meet global market needs and taking into account the convergence of information technology services and networks. The group will include representatives of businesses, including telecom operators and Internet service providers and trade organizations, the ASO Council, the ICANN Board, and other legitimately interested parties. The group will present an interim report before the second ICANN public meeting in 2000. A final report from the ad hoc group will be presented to the ICANN Board prior to the Annual Meeting in 2000." There is still some question as to exactly what the charter of this committee will be and who will be allowed to participate. Since the purpose of this committee is unclear, the RIR representatives suggested delaying a vote on creating this ad hoc committee until after the community had a chance to discuss it. The ICANN Board felt there had already been extensive discussion. Mike Roberts (Interim President of ICANN) has been tasked with determining a charter for the ad hoc committee and determining who will be allowed to participate. We hope that this charter will be available for public comment prior to committee members being appointed. In the meantime, I cannot stress enough how important it is for you and your organizations to get involved in this process. We will be discussing ICANN/ASO issues at the public policy meeting in Denver in October. If these issues are not listed in your job description :-) and there is someone else from your organization better suited to deal with the political side than please bring them along with you to the ARIN public policy meeting. If you have any comments or questions about the ICANN meeting I will be more than happy to discuss them with you. Fortunately, there were members of the ARIN board and Advisory Council in attendance, specifically, Mike Straty, Ken Fockler, Don Telage (BoT), Cathy Wittbrodt and Jeremy Porter (AC). All of which I'm sure would be happy to participate in a discussion on this list. Thanks, Kim Hubbard ARIN From owner-arin-discuss@arin.net Thu Sep 16 10:38:12 1999 Return-Path: Received: by ops.arin.net (8.9.0/8.9.0) id KAA13234 for arin-discuss-outgoing; Thu, 16 Sep 1999 10:22:29 -0400 (EDT) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id KAA13230 for ; Thu, 16 Sep 1999 10:22:28 -0400 (EDT) Message-Id: <4.1.19990916101026.01b51960@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 16 Sep 1999 10:16:14 -0400 To: arin-discuss@arin.net From: Kim Hubbard Subject: Show support for ASO nominees Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1021819==_.ALT" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR --=====================_1021819==_.ALT Content-Type: text/plain; charset="us-ascii" The current list of ASO Address Council nominees are on ARIN's webpage. To show support for one or more of these individuals just complete the form at http://www.arin.net/aso/aso.htm. You can also nominate someone new for the Address Council and ICANN Board of Directors. While you're at the ARIN website don't forget to sign up for the ARIN member and public policy meetings. See you in Denver... Kim --=====================_1021819==_.ALT Content-Type: text/html; charset="us-ascii"
The current list of ASO Address Council nominees are on ARIN's webpage. To show support for one or more of these individuals just complete the form at http://www.arin.net/aso/aso.htm. You can also nominate someone new for the Address Council and ICANN Board of Directors.

While you're at the ARIN website don't forget to sign up for the ARIN member and public policy meetings.

See you in Denver...

Kim --=====================_1021819==_.ALT-- From owner-arin-discuss@arin.net Tue Oct 26 16:41:58 1999 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id QAA24426 for arin-discuss-outgoing; Tue, 26 Oct 1999 16:39:10 -0400 (EDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with SMTP id QAA24422 for ; Tue, 26 Oct 1999 16:39:09 -0400 (EDT) Received: (qmail 24227 invoked from network); 26 Oct 1999 20:39:08 -0000 Received: from poptart.svr.home.net (HELO poptart.corp.home.net) (24.0.26.24) by rs1.arin.net with SMTP; 26 Oct 1999 20:39:08 -0000 Received: from groovy.eos.home.net ([24.0.16.187]) by poptart.corp.home.net (Netscape Messaging Server 3.54) with ESMTP id AAA73A8 for ; Tue, 26 Oct 1999 13:38:58 -0700 Received: from groovy.eos.home.net (cathy@localhost [127.0.0.1]) by groovy.eos.home.net (8.8.5/8.8.5) with ESMTP id NAA08804 for ; Tue, 26 Oct 1999 13:38:57 -0700 (PDT) Message-Id: <199910262038.NAA08804@groovy.eos.home.net> X-Mailer: exmh version 1.6.5 12/11/95 Subject: Announcing appointments of ICANN Board Members From: "CJ Wittbrodt" To: arin-discuss@arin.net Reply-to: cjw@corp.home.net Office: 425 Broadway, Redwood City, CA 94063 Phone: 650-569-5483 Fax: 650-569-5483 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Oct 1999 13:38:55 -0700 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR The address council of the Address Supporting Organisation of ICANN has has performed its first important task. Following the regional open calls for nominations, three members for the ICANN board have been selected. Congratulations go to: Ken Fockler (ARIN region) for a 1 year term Rob Blokzijl (RIPE NCC region) for a 3 years term Pindar Wong (APNIC region) for a 2 years term The terms may be reconsidered at the upcoming ICANN meeting in Los Angeles, but for formal reasons we had to decide on the terms without having time to meet or consult with the candidates. ---CJ From owner-arin-discuss@arin.net Mon Feb 14 14:53:59 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id OAA06785 for arin-discuss-outgoing; Mon, 14 Feb 2000 14:29:36 -0500 (EST) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id OAA06781 for ; Mon, 14 Feb 2000 14:29:35 -0500 (EST) Message-Id: <4.1.20000214140539.00c67d50@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 14 Feb 2000 14:18:58 -0500 To: arin-discuss@arin.net From: Kim Hubbard Subject: New ICANN/USG contract for IANA services Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Hello, I thought you might be interested in reading the newly signed contract between ICANN and USG pertaining to IANA services, particularly interesting is the section relating to IP numbers. The ICANN responded to a USG RFQ on 2/2/00 and the contract was signed 2/9/00. The ICANN proposal is located at: http://www.icann.org/general/iana-proposal-02feb00.htm And the signed contract can be found at: http://www.icann.org/general/iana-contract-09feb00.htm Let me know if you have any comments. Thanks, Kim From owner-arin-discuss@arin.net Tue Feb 15 00:02:47 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id XAA26732 for arin-discuss-outgoing; Mon, 14 Feb 2000 23:55:06 -0500 (EST) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id XAA26720; Mon, 14 Feb 2000 23:54:57 -0500 (EST) Received: from freeside.fc.net (freeside.fc.net [207.170.70.2]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id XAA03025; Mon, 14 Feb 2000 23:54:56 -0500 (EST) Received: from freeside.fc.net (localhost [127.0.0.1]) by freeside.fc.net (8.9.3/8.8.8) with ESMTP id WAA35832; Mon, 14 Feb 2000 22:54:50 -0600 (CST) Message-Id: <200002150454.WAA35832@freeside.fc.net> To: Kim Hubbard cc: arin-discuss@arin.net Subject: Re: New ICANN/USG contract for IANA services In-reply-to: Your message of "Mon, 14 Feb 2000 14:18:58 EST." <4.1.20000214140539.00c67d50@192.149.252.141> Date: Mon, 14 Feb 2000 22:54:50 -0600 From: Jeremy Porter Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR One wonders if the following wording was deliberate: The ASO has three members: the three Regional Internet Registries (APNIC, ARIN, and RIPE NCC) that have been delegated responsibility by the IANA for routine allocation and assignment within their respective regions. These three organizations select members of the ASO's Address Council, which is responsible for developing consensus-based recommended policies concerning the operation, assignment and management of Internet (IP) addresses. i.e. with respect to "routine" assignments. Further: - Allocation of IP address blocks. This involves overall responsibility for the allocation of IPv4 and IPv6 address space. It includes delegations of IP address blocks to regional registries for routine allocation, typically through downstream providers, to Internet end-users within the regions served by those registries. It also includes reservation and direct allocation of space for special purposes, such as multicast addressing, cable blocks, addresses for private networks as described in RFC 1918, and globally specified applications. Presumable the wording of this is only a little lacking, in the term "cable blocks", because I'd like to get address from those special blocks since my address come over a "wire" or "cable". Sigh. Ok thats a red herring of sorts, as I'd guess the intent was to include the situtation where blocks for cable televions providers who are providing service over their HFC cable plants, are coming out of a different address range than other providers. But these "globally specified applications" worry me a bit. After the last ICANN meeting in LA, I thought the pretty clear consesous from everyone except the telephone companies, was that IP assignment was application neutral as far as policy was concerned, and that the ad-hoc committee as formed by the Santigio meeting was only to review and recommened new changes providing that they are merited, and the the IAB's concernces about non application neutrality were addressed. This response to RFC and contract seem to violate the spirit if not the letter of the agreements at these meetings, and that the US Governement has allowed ICANN to piggy back into a narrow window from a period of Feb 02 to Feb 09, is a cause if significant interest. The forces that want to staticly assign an IP address to every telephone handset, because that is the easly solution, as opposed to the correct solution, may already have won. This clearly needs to be discussed at the ICANN meeting in Cairo and and the next ARIN public policy meeting. Needless to say, I will be bringing this up in both forums. In message <4.1.20000214140539.00c67d50@192.149.252.141>, Kim Hubbard writes: >Hello, > >I thought you might be interested in reading the newly signed contract >between ICANN and USG pertaining to IANA services, particularly interesting >is the section relating to IP numbers. > >The ICANN responded to a USG RFQ on 2/2/00 and the contract was signed >2/9/00. > >The ICANN proposal is located at: >http://www.icann.org/general/iana-proposal-02feb00.htm > >And the signed contract can be found at: > > http://www.icann.org/general/iana-contract-09feb00.htm > >Let me know if you have any comments. > >Thanks, >Kim > --- jerry@fc.net Failure is a natural consequence of any nonscalable activity. -- Paul Vixie From owner-arin-discuss@arin.net Sun Jun 4 19:14:36 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA16494 for arin-discuss-outgoing; Sun, 4 Jun 2000 18:56:43 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA16490 for ; Sun, 4 Jun 2000 18:56:42 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id SAA17897 for ; Sun, 4 Jun 2000 18:56:41 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12yjJw-000Bcs-00 for arin-discuss@arin.net; Sun, 04 Jun 2000 15:56:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: arin-discuss@arin.net Subject: split b Message-Id: Date: Sun, 04 Jun 2000 15:56:40 -0700 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@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@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 owner-arin-discuss@arin.net Sun Jun 4 21:36:24 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id VAA18340 for arin-discuss-outgoing; Sun, 4 Jun 2000 21:28:49 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id VAA18336 for ; Sun, 4 Jun 2000 21:28:48 -0400 (EDT) From: bmanning@vacation.karoshi.com Received: from vacation.karoshi.com (vacation.karoshi.com [128.9.104.5]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id VAA25529 for ; Sun, 4 Jun 2000 21:28:47 -0400 (EDT) Received: (from bmanning@localhost) by vacation.karoshi.com (8.9.3/8.9.3) id TAA01893; Sun, 4 Jun 2000 19:11:32 -0700 Message-Id: <200006050211.TAA01893@vacation.karoshi.com> Subject: Re: split b To: rbush@bainbridge.verio.net (Randy Bush) Date: Sun, 4 Jun 2000 19:11:32 -0700 (PDT) Cc: arin-discuss@arin.net In-Reply-To: from "Randy Bush" at Jun 04, 2000 03:56:40 PM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@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@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 owner-arin-discuss@arin.net Mon Jun 5 08:26:14 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id IAA15185 for arin-discuss-outgoing; Mon, 5 Jun 2000 08:17:25 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA15163 for ; Mon, 5 Jun 2000 08:17:23 -0400 (EDT) Received: from rottweiler.cwusa.com (rottweiler-dmz.cwusa.com [146.135.88.50]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id IAA25701 for ; Mon, 5 Jun 2000 08:17:22 -0400 (EDT) Received: from us-cwi-exc-a04.cwusa.com (us-cwi-exc-a04.cwusa.com [146.135.85.81]) by rottweiler.cwusa.com (8.9.1/8.9.1) with ESMTP id IAA05505; Mon, 5 Jun 2000 08:16:20 -0400 (EDT) Received: from thinman (204.71.37.36 [204.71.37.36]) by us-cwi-exc-a04.cwusa.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id M2BD7F9C; Mon, 5 Jun 2000 08:16:19 -0400 Reply-To: From: "Tanya Hinman" To: "Randy Bush" , Subject: RE: split b Date: Mon, 5 Jun 2000 08:16:15 -0400 Message-ID: <000101bfcee7$d84793c0$242547cc@thinman.cary.cw.netcw.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Importance: Normal Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Randy, This allocation was a transfer/merger issue. What policy are you referring to? Tanya -----Original Message----- From: owner-arin-discuss@arin.net [mailto:owner-arin-discuss@arin.net]On Behalf Of Randy Bush Sent: Sunday, June 04, 2000 6:57 PM To: arin-discuss@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@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@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 owner-arin-discuss@arin.net Mon Jun 5 09:00:48 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id IAA22357 for arin-discuss-outgoing; Mon, 5 Jun 2000 08:53:59 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA22331 for ; Mon, 5 Jun 2000 08:53:58 -0400 (EDT) Received: from doberman.cwusa.com (doberman-dmz.cwusa.com [146.135.88.56]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id IAA06034 for ; Mon, 5 Jun 2000 08:53:57 -0400 (EDT) Received: from us-cwi-exc-a10.cwusa.com (us-cwi-exc-a10.cwusa.com [146.135.85.143]) by doberman.cwusa.com (8.9.1/8.9.1) with ESMTP id IAA25598; Mon, 5 Jun 2000 08:52:18 -0400 (EDT) Received: by us-cwi-exc-a10.cwi.cablew.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 08:52:16 -0400 Message-ID: <3FD40150593CD2119D5200805FA7D965050A7F8D@us-cwi-exc-a07.cwi.cablew.com> From: "Sweeting, John" To: "'bmanning@vacation.karoshi.com'" , rbush@bainbridge.verio.net Cc: arin-discuss@arin.net Subject: RE: split b Date: Mon, 5 Jun 2000 08:52:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Bill, this does not predate ARIN, this was accomplished through ARIN. -----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Sunday, June 04, 2000 10:12 PM To: rbush@bainbridge.verio.net Cc: arin-discuss@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@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@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 owner-arin-discuss@arin.net Mon Jun 5 09:24:23 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id JAA26697 for arin-discuss-outgoing; Mon, 5 Jun 2000 09:17:42 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA26686 for ; Mon, 5 Jun 2000 09:17:41 -0400 (EDT) From: bmanning@vacation.karoshi.com Received: from vacation.karoshi.com (vacation.karoshi.com [128.9.104.5]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id JAA17528 for ; Mon, 5 Jun 2000 09:17:40 -0400 (EDT) Received: (from bmanning@localhost) by vacation.karoshi.com (8.9.3/8.9.3) id GAA02369; Mon, 5 Jun 2000 06:58:26 -0700 Message-Id: <200006051358.GAA02369@vacation.karoshi.com> Subject: Re: split b To: John.Sweeting@cwusa.com (Sweeting, John) Date: Mon, 5 Jun 2000 06:58:25 -0700 (PDT) Cc: arin-discuss@arin.net In-Reply-To: <3FD40150593CD2119D5200805FA7D965050A7F93@us-cwi-exc-a07.cwi.cablew.com> from "Sweeting, John" at Jun 05, 2000 09:11:01 AM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@vacation.karoshi.com > [mailto:bmanning@vacation.karoshi.com] > Sent: Monday, June 05, 2000 9:44 AM > To: John.Sweeting@cwusa.com > Cc: bmanning@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@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@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 owner-arin-discuss@arin.net Mon Jun 5 10:47:02 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id KAA11263 for arin-discuss-outgoing; Mon, 5 Jun 2000 10:40:30 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA11251 for ; Mon, 5 Jun 2000 10:40:26 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id KAA10714 for ; Mon, 5 Jun 2000 10:40:25 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12yy0f-000G8Y-00; Mon, 05 Jun 2000 07:37:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: Tanya Hinman Cc: Subject: RE: split b References: <000101bfcee7$d84793c0$242547cc@thinman.cary.cw.netcw.net> Message-Id: Date: Mon, 05 Jun 2000 07:37:45 -0700 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR > 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 owner-arin-discuss@arin.net Mon Jun 5 10:56:54 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id KAA13205 for arin-discuss-outgoing; Mon, 5 Jun 2000 10:50:13 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA13200 for ; Mon, 5 Jun 2000 10:50:11 -0400 (EDT) Received: from doberman.cwusa.com (doberman-dmz.cwusa.com [146.135.88.56]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id KAA29261 for ; Mon, 5 Jun 2000 10:50:06 -0400 (EDT) Received: from us-cwi-exc-a10.cwusa.com (us-cwi-exc-a10.cwusa.com [146.135.85.143]) by doberman.cwusa.com (8.9.1/8.9.1) with ESMTP id KAA13989; Mon, 5 Jun 2000 10:47:09 -0400 (EDT) Received: by us-cwi-exc-a10.cwi.cablew.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 10:47:06 -0400 Message-ID: <3FD40150593CD2119D5200805FA7D965050A7F97@us-cwi-exc-a07.cwi.cablew.com> From: "Sweeting, John" To: "'Peter Schroebel'" , "Sweeting, John" , bmanning@vacation.karoshi.com, rbush@bainbridge.verio.net Cc: arin-discuss@arin.net Subject: RE: split b Date: Mon, 5 Jun 2000 10:47:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@fullport.com] Sent: Monday, June 05, 2000 10:32 AM To: Sweeting, John; bmanning@vacation.karoshi.com; rbush@bainbridge.verio.net Cc: arin-discuss@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 owner-arin-discuss@arin.net Mon Jun 5 12:11:53 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id MAA29321 for arin-discuss-outgoing; Mon, 5 Jun 2000 12:05:07 -0400 (EDT) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id MAA29312; Mon, 5 Jun 2000 12:05:05 -0400 (EDT) Message-Id: <4.1.20000605115028.01ad13c0@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 05 Jun 2000 11:51:46 -0400 To: Randy Bush , Tanya Hinman From: Kim Hubbard Subject: RE: split b Cc: In-Reply-To: References: <000101bfcee7$d84793c0$242547cc@thinman.cary.cw.netcw.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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 owner-arin-discuss@arin.net Mon Jun 5 12:35:01 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id MAA02273 for arin-discuss-outgoing; Mon, 5 Jun 2000 12:23:47 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA02269 for ; Mon, 5 Jun 2000 12:23:46 -0400 (EDT) Received: from postino4.prima.com.ar (postino4.prima.com.ar [200.42.0.162]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id MAA20369 for ; Mon, 5 Jun 2000 12:23:43 -0400 (EDT) Received: from prima28.admin ([172.16.1.8]) by postino4.prima.com.ar (8.9.3/8.9.1) with ESMTP id NAA11797; Mon, 5 Jun 2000 13:23:22 -0300 (ART) Received: from mail pickup service by prima28.admin with Microsoft SMTPSVC; Mon, 5 Jun 2000 13:05:54 -0300 Received: from postino1.prima.com.ar ([200.42.0.132]) by prima28.admin with Microsoft SMTPSVC(5.5.1877.417.41); Mon, 5 Jun 2000 10:03:20 -0300 Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by postino1.prima.com.ar (8.9.1a/8.9.1) with ESMTP id KAA20739 for ; Mon, 5 Jun 2000 10:03:35 -0300 (ART) Received: from ops.arin.net (ops.arin.net [192.149.252.141]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id JAA08191; Mon, 5 Jun 2000 09:01:43 -0400 (EDT) Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id IAA22357 for arin-discuss-outgoing; Mon, 5 Jun 2000 08:53:59 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id IAA22331 for ; Mon, 5 Jun 2000 08:53:58 -0400 (EDT) Received: from doberman.cwusa.com (doberman-dmz.cwusa.com [146.135.88.56]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id IAA06034 for ; Mon, 5 Jun 2000 08:53:57 -0400 (EDT) Received: from us-cwi-exc-a10.cwusa.com (us-cwi-exc-a10.cwusa.com [146.135.85.143]) by doberman.cwusa.com (8.9.1/8.9.1) with ESMTP id IAA25598; Mon, 5 Jun 2000 08:52:18 -0400 (EDT) Received: by us-cwi-exc-a10.cwi.cablew.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 08:52:16 -0400 Message-ID: <3FD40150593CD2119D5200805FA7D965050A7F8D@us-cwi-exc-a07.cwi.cablew.com> From: "Sweeting, John" To: "'bmanning@vacation.karoshi.com'" , rbush@bainbridge.verio.net Cc: arin-discuss@arin.net Subject: RE: split b Date: Mon, 5 Jun 2000 08:52:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Bill, this does not predate ARIN, this was accomplished through ARIN. -----Original Message----- From: bmanning@vacation.karoshi.com [mailto:bmanning@vacation.karoshi.com] Sent: Sunday, June 04, 2000 10:12 PM To: rbush@bainbridge.verio.net Cc: arin-discuss@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@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@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 owner-arin-discuss@arin.net Mon Jun 5 12:53:22 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id MAA04563 for arin-discuss-outgoing; Mon, 5 Jun 2000 12:46:42 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA04556 for ; Mon, 5 Jun 2000 12:46:36 -0400 (EDT) Received: from freeside.fc.net (freeside.fc.net [207.170.70.2]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id MAA00611 for ; Mon, 5 Jun 2000 12:46:36 -0400 (EDT) Received: from freeside.fc.net (localhost [127.0.0.1]) by freeside.fc.net (8.9.3/8.8.8) with ESMTP id LAA34700; Mon, 5 Jun 2000 11:43:49 -0500 (CDT) Message-Id: <200006051643.LAA34700@freeside.fc.net> To: bmanning@vacation.karoshi.com cc: John.Sweeting@cwusa.com (Sweeting, John), arin-discuss@arin.net Subject: Re: split b In-reply-to: Your message of "Mon, 05 Jun 2000 06:58:25 PDT." <200006051358.GAA02369@vacation.karoshi.com> Date: Mon, 05 Jun 2000 11:43:48 -0500 From: Jeremy Porter Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@vacation.karoshi.com>, bmanning@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@vacation.karoshi.com >> [mailto:bmanning@vacation.karoshi.com] >> Sent: Monday, June 05, 2000 9:44 AM >> To: John.Sweeting@cwusa.com >> Cc: bmanning@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@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@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@fc.net Director Network Operations/Network Engineering, Wayport, Inc. 512-519-6193 www.wayport.net 8303 Mopac Expressway Suite A300, Austin Tx. From owner-arin-discuss@arin.net Mon Jun 5 13:04:30 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id MAA05680 for arin-discuss-outgoing; Mon, 5 Jun 2000 12:57:44 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA05673 for ; Mon, 5 Jun 2000 12:57:41 -0400 (EDT) From: bmanning@vacation.karoshi.com Received: from vacation.karoshi.com (vacation.karoshi.com [128.9.104.5]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id MAA02312 for ; Mon, 5 Jun 2000 12:57:33 -0400 (EDT) Received: (from bmanning@localhost) by vacation.karoshi.com (8.9.3/8.9.3) id KAA02756; Mon, 5 Jun 2000 10:37:55 -0700 Message-Id: <200006051737.KAA02756@vacation.karoshi.com> Subject: Re: split b To: jerry@fc.net (Jeremy Porter) Date: Mon, 5 Jun 2000 10:37:55 -0700 (PDT) Cc: John.Sweeting@cwusa.com (Sweeting John), arin-discuss@arin.net In-Reply-To: <200006051643.LAA34700@freeside.fc.net> from "Jeremy Porter" at Jun 05, 2000 11:43:48 AM X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR > 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@vacation.karoshi.com>, bmanning@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@vacation.karoshi.com > >> [mailto:bmanning@vacation.karoshi.com] > >> Sent: Monday, June 05, 2000 9:44 AM > >> To: John.Sweeting@cwusa.com > >> Cc: bmanning@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@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@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@fc.net > Director Network Operations/Network Engineering, Wayport, Inc. > 512-519-6193 www.wayport.net > 8303 Mopac Expressway Suite A300, Austin Tx. > From owner-arin-discuss@arin.net Mon Jun 5 13:26:43 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id NAA11162 for arin-discuss-outgoing; Mon, 5 Jun 2000 13:20:08 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA11156 for ; Mon, 5 Jun 2000 13:20:06 -0400 (EDT) Received: from mail-la.station.sony.com (mail-la.station.sony.com [209.0.234.32]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id NAA17568 for ; Mon, 5 Jun 2000 13:20:06 -0400 (EDT) Received: by mail-la.station.sony.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 10:19:52 -0700 Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B015EC003@mail-la.station.sony.com> From: "Hostmaster, Verant" To: "'arin-discuss@arin.net'" Subject: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 10:19:47 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@verant.com (310) 840-8753 > -----Original Message----- > From: Randy Bush [SMTP:rbush@bainbridge.verio.net] > Sent: Monday, June 05, 2000 7:38 AM > To: Tanya Hinman > Cc: arin-discuss@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 owner-arin-discuss@arin.net Mon Jun 5 14:14:32 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id OAA17470 for arin-discuss-outgoing; Mon, 5 Jun 2000 14:07:54 -0400 (EDT) Received: from jazz (jazz.arin.net [192.149.252.195]) by ops.arin.net (8.9.0/8.9.0) with SMTP id OAA17466; Mon, 5 Jun 2000 14:07:52 -0400 (EDT) Message-Id: <4.1.20000605134442.01aff430@192.149.252.141> X-Sender: kimh@192.149.252.141 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 05 Jun 2000 13:54:34 -0400 To: bmanning@vacation.karoshi.com, jerry@fc.net (Jeremy Porter) From: Kim Hubbard Subject: Re: split b Cc: John.Sweeting@cwusa.com (Sweeting John), arin-discuss@arin.net In-Reply-To: <200006051737.KAA02756@vacation.karoshi.com> References: <200006051643.LAA34700@freeside.fc.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR At 10:37 AM 6/5/00 -0700, bmanning@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@vacation.karoshi.com>, >bmanning@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@vacation.karoshi.com >> >> [mailto:bmanning@vacation.karoshi.com] >> >> Sent: Monday, June 05, 2000 9:44 AM >> >> To: John.Sweeting@cwusa.com >> >> Cc: bmanning@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@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@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@fc.net >> Director Network Operations/Network Engineering, Wayport, Inc. >> 512-519-6193 www.wayport.net >> 8303 Mopac Expressway Suite A300, Austin Tx. >> From owner-arin-discuss@arin.net Mon Jun 5 14:25:16 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id OAA18948 for arin-discuss-outgoing; Mon, 5 Jun 2000 14:18:44 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA18943 for ; Mon, 5 Jun 2000 14:18:42 -0400 (EDT) Received: from alpha.cdp.adelphia.net (alpha.cdp.adelphia.net [24.48.64.2]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id OAA21258 for ; Mon, 5 Jun 2000 14:18:41 -0400 (EDT) Received: from dave.adelphia.net ([24.48.58.57]) by alpha.cdp.adelphia.net (8.9.2/8.9.2) with ESMTP id OAA10554; Mon, 5 Jun 2000 14:13:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20000605133945.00d555f0@mail.cdp.adelphia.net> X-Sender: dbernardi@mail.cdp.adelphia.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jun 2000 14:11:09 -0400 To: "Hostmaster, Verant" , "'arin-discuss@arin.net'" From: dave bernardi Subject: Re: route filtering policies (from "split b" thread) In-Reply-To: <51EC05AE2DD6D111A0CF00805F6F410B015EC003@mail-la.station.s ony.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@verant.com >(310) 840-8753 > >> -----Original Message----- >> From: Randy Bush [SMTP:rbush@bainbridge.verio.net] >> Sent: Monday, June 05, 2000 7:38 AM >> To: Tanya Hinman >> Cc: arin-discuss@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 owner-arin-discuss@arin.net Mon Jun 5 14:25:48 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id OAA19029 for arin-discuss-outgoing; Mon, 5 Jun 2000 14:19:18 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id OAA19020 for ; Mon, 5 Jun 2000 14:19:16 -0400 (EDT) Received: from post.xecu.net (post.xecu.net [216.127.136.211]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id OAA21575 for ; Mon, 5 Jun 2000 14:19:16 -0400 (EDT) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by post.xecu.net (Postfix) with ESMTP id 19FD648E8 for ; Mon, 5 Jun 2000 14:17:09 -0400 (EDT) Received: from localhost (andy@localhost) by shell.xecu.net (8.8.8+Sun/8.8.8) with ESMTP id OAA13414 for ; Mon, 5 Jun 2000 14:19:05 -0400 (EDT) X-Authentication-Warning: shell.xecu.net: andy owned process doing -bs Date: Mon, 5 Jun 2000 14:19:05 -0400 (EDT) From: Andy Dills To: arin-discuss@arin.net Subject: Re: split b In-Reply-To: <4.1.20000605134442.01aff430@192.149.252.141> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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 owner-arin-discuss@arin.net Mon Jun 5 16:09:37 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id QAA00942 for arin-discuss-outgoing; Mon, 5 Jun 2000 16:03:44 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA00926 for ; Mon, 5 Jun 2000 16:03:32 -0400 (EDT) Received: from mail-la.station.sony.com (mail-la.station.sony.com [209.0.234.32]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id QAA19766 for ; Mon, 5 Jun 2000 16:03:31 -0400 (EDT) Received: by mail-la.station.sony.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 13:03:16 -0700 Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B015EC00D@mail-la.station.sony.com> From: "Hostmaster, Verant" To: "'arin-discuss@arin.net'" Cc: Network Operations Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 13:03:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@station.sony.com (310) 840-8753 > -----Original Message----- > From: Doug Junkins [SMTP:junkins@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@verant.com > > (310) 840-8753 > > > > > -----Original Message----- > > > From: Randy Bush [SMTP:rbush@bainbridge.verio.net] > > > Sent: Monday, June 05, 2000 7:38 AM > > > To: Tanya Hinman > > > Cc: arin-discuss@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 owner-arin-discuss@arin.net Mon Jun 5 17:36:23 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id RAA09589 for arin-discuss-outgoing; Mon, 5 Jun 2000 17:31:13 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA09585 for ; Mon, 5 Jun 2000 17:31:12 -0400 (EDT) Received: from mail-la.station.sony.com (mail-la.station.sony.com [209.0.234.32]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id RAA07301 for ; Mon, 5 Jun 2000 17:31:11 -0400 (EDT) Received: by mail-la.station.sony.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 14:30:58 -0700 Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> From: "Hostmaster, Verant" To: "'Paul A Vixie'" Cc: "'arin-discuss@arin.net'" Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 14:30:57 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@verant.com (310) 840-8753 > -----Original Message----- > From: Paul A Vixie [SMTP:vixie@mibh.net] > Sent: Monday, June 05, 00 2:04 PM > To: Hostmaster, Verant > Cc: 'arin-discuss@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 owner-arin-discuss@arin.net Mon Jun 5 18:24:17 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA12316 for arin-discuss-outgoing; Mon, 5 Jun 2000 18:18:36 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA12312 for ; Mon, 5 Jun 2000 18:18:30 -0400 (EDT) Received: from mx01.cafemail.com (mx01.cafemail.com [207.201.29.131]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id SAA01339 for ; Mon, 5 Jun 2000 18:18:24 -0400 (EDT) Received: from mx10 ([207.201.29.77]) by mx01.cafemail.com (post.office MTA v2.0 0813 ID# 0-18505) with SMTP id AAA47; Mon, 5 Jun 2000 15:18:22 -0700 Message-ID: <032f01bfcf3b$f608b890$4d1dc9cf@javamail.com> Reply-To: "Charles Winter" From: cwinter@communicationnation.com (Charles Winter) To: "Hostmaster, Verant" , "'Paul A Vixie'" Cc: , "Brent Walters" , "Joe Murray" References: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> Subject: Re: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 15:18:21 -0700 Organization: Communication Nation MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@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@verant.com > (310) 840-8753 > > > > -----Original Message----- > > From: Paul A Vixie [SMTP:vixie@mibh.net] > > Sent: Monday, June 05, 00 2:04 PM > > To: Hostmaster, Verant > > Cc: 'arin-discuss@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 owner-arin-discuss@arin.net Mon Jun 5 18:31:54 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA12513 for arin-discuss-outgoing; Mon, 5 Jun 2000 18:26:41 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA12504 for ; Mon, 5 Jun 2000 18:26:40 -0400 (EDT) Received: from mail.NetWright.Net (MAIL.NETWRIGHT.NET [216.169.0.242]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id SAA05592 for ; Mon, 5 Jun 2000 18:26:39 -0400 (EDT) Received: from SWEETNESS ([216.169.0.254]) by mail.NetWright.Net (Post.Office MTA v3.5.3 release 223 ID# 0-53597U1000L100S0V35) with SMTP id Net for ; Mon, 5 Jun 2000 16:26:29 -0600 Reply-To: From: "Mike Lieberman" To: Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 16:26:27 -0600 Message-ID: <001a01bfcf3d$17e23a80$fe00a9d8@SWEETNESS> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net/ */ /* Voice and Fax: 307-857-1053 */ From owner-arin-discuss@arin.net Mon Jun 5 18:35:06 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA13432 for arin-discuss-outgoing; Mon, 5 Jun 2000 18:29:56 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA13337 for ; Mon, 5 Jun 2000 18:29:52 -0400 (EDT) Received: from b5.eng.internex.net (b5.eng.internex.net [207.88.8.14]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id SAA20597 for ; Mon, 5 Jun 2000 18:29:50 -0400 (EDT) Received: from skylab.eng.internex.net (skylab.eng.internex.net [207.88.8.15]) by b5.eng.internex.net (8.9.1/8.9.1) with ESMTP id PAA26799; Mon, 5 Jun 2000 15:29:18 -0700 (PDT) From: Pete Bowden Received: (from pete@localhost) by skylab.eng.internex.net (8.9.3/8.9.3) id PAA13587; Mon, 5 Jun 2000 15:29:19 -0700 (PDT) Message-Id: <200006052229.PAA13587@skylab.eng.internex.net> Subject: Re: route filtering policies (from "split b" thread) To: hostmaster@verant.com (Hostmaster, Verant) Date: Mon, 5 Jun 2000 15:29:18 -0700 (PDT) Cc: vixie@mibh.net ('Paul A Vixie'), arin-discuss@arin.net ('arin-discuss@arin.net') In-Reply-To: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> from "Hostmaster, Verant" at Jun 05, 2000 02:30:57 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@verant.com > (310) 840-8753 > > > > -----Original Message----- > > From: Paul A Vixie [SMTP:vixie@mibh.net] > > Sent: Monday, June 05, 00 2:04 PM > > To: Hostmaster, Verant > > Cc: 'arin-discuss@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@concentric.com rePete@cncx.com pete@internex.net NIC:PB8 Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, CA 95126-3429 Voice: 408-808-6010 Fax: 408-808-6010 From owner-arin-discuss@arin.net Mon Jun 5 18:46:57 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA15091 for arin-discuss-outgoing; Mon, 5 Jun 2000 18:41:36 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA15087 for ; Mon, 5 Jun 2000 18:41:35 -0400 (EDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id SAA13179 for ; Mon, 5 Jun 2000 18:41:34 -0400 (EDT) Received: from randy by rip.psg.com with local (Exim 3.13 #1) id 12z5Yp-000J92-00; Mon, 05 Jun 2000 15:41:31 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Randy Bush To: "Mike Lieberman" Cc: Subject: RE: route filtering policies (from "split b" thread) References: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBA3@mail-la.station.sony.com> <001a01bfcf3d$17e23a80$fe00a9d8@SWEETNESS> Message-Id: Date: Mon, 05 Jun 2000 15:41:31 -0700 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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 owner-arin-discuss@arin.net Mon Jun 5 19:17:42 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id TAA16505 for arin-discuss-outgoing; Mon, 5 Jun 2000 19:06:48 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA16501 for ; Mon, 5 Jun 2000 19:06:46 -0400 (EDT) Received: from b5.eng.internex.net (b5.eng.internex.net [207.88.8.14]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id TAA24398 for ; Mon, 5 Jun 2000 19:06:45 -0400 (EDT) Received: from skylab.eng.internex.net (skylab.eng.internex.net [207.88.8.15]) by b5.eng.internex.net (8.9.1/8.9.1) with ESMTP id QAA29394; Mon, 5 Jun 2000 16:06:13 -0700 (PDT) From: Pete Bowden Received: (from pete@localhost) by skylab.eng.internex.net (8.9.3/8.9.3) id QAA02104; Mon, 5 Jun 2000 16:06:13 -0700 (PDT) Message-Id: <200006052306.QAA02104@skylab.eng.internex.net> Subject: Re: route filtering policies (from "split b" thread) To: Mike@netwright.net Date: Mon, 5 Jun 2000 16:06:13 -0700 (PDT) Cc: arin-discuss@arin.net In-Reply-To: <001a01bfcf3d$17e23a80$fe00a9d8@SWEETNESS> from "Mike Lieberman" at Jun 05, 2000 04:26:27 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@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@concentric.com rePete@cncx.com pete@internex.net NIC:PB8 Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, CA 95126-3429 Voice: 408-808-6010 Fax: 408-808-6010 From owner-arin-discuss@arin.net Mon Jun 5 19:46:40 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id TAA17389 for arin-discuss-outgoing; Mon, 5 Jun 2000 19:37:59 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA17385 for ; Mon, 5 Jun 2000 19:37:57 -0400 (EDT) Received: from mail.NetWright.Net (MAIL.NETWRIGHT.NET [216.169.0.242]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id TAA07114 for ; Mon, 5 Jun 2000 19:37:51 -0400 (EDT) Received: from Traveler ([216.169.12.221]) by mail.NetWright.Net (Post.Office MTA v3.5.3 release 223 ID# 0-53597U1000L100S0V35) with SMTP id Net; Mon, 5 Jun 2000 17:37:44 -0600 Reply-To: From: "Mike Lieberman" To: "'Pete Bowden'" Cc: Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 17:37:38 -0600 Message-ID: <000001bfcf47$09c38760$dd0ca9d8@netwright.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200006052306.QAA02104@skylab.eng.internex.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ > -----Original Message----- > From: Pete Bowden [mailto:repete@cncx.com] > Sent: Monday, June 05, 2000 5:06 PM > To: Mike@netwright.net > Cc: arin-discuss@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@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@concentric.com rePete@cncx.com pete@internex.net NIC:PB8 > Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, > CA 95126-3429 > Voice: 408-808-6010 Fax: 408-808-6010 > From owner-arin-discuss@arin.net Mon Jun 5 20:30:47 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id UAA19175 for arin-discuss-outgoing; Mon, 5 Jun 2000 20:21:56 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA19171 for ; Mon, 5 Jun 2000 20:21:55 -0400 (EDT) Received: from b5.eng.internex.net (b5.eng.internex.net [207.88.8.14]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id UAA28634 for ; Mon, 5 Jun 2000 20:21:54 -0400 (EDT) Received: from skylab.eng.internex.net (skylab.eng.internex.net [207.88.8.15]) by b5.eng.internex.net (8.9.1/8.9.1) with ESMTP id RAA03829; Mon, 5 Jun 2000 17:21:21 -0700 (PDT) From: Pete Bowden Received: (from pete@localhost) by skylab.eng.internex.net (8.9.3/8.9.3) id RAA08480; Mon, 5 Jun 2000 17:21:22 -0700 (PDT) Message-Id: <200006060021.RAA08480@skylab.eng.internex.net> Subject: Re: route filtering policies (from "split b" thread) To: Mike@netwright.net Date: Mon, 5 Jun 2000 17:21:21 -0700 (PDT) Cc: arin-discuss@arin.net In-Reply-To: <000001bfcf47$09c38760$dd0ca9d8@netwright.net> from "Mike Lieberman" at Jun 05, 2000 05:37:38 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@NetWright.Net */ > /* President */ > /* Net Wright LLC */ > /* http://www.netwright.net */ > /* Voice and Fax: 307-857-1053 */ > > > -----Original Message----- > > From: Pete Bowden [mailto:repete@cncx.com] > > Sent: Monday, June 05, 2000 5:06 PM > > To: Mike@netwright.net > > Cc: arin-discuss@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@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@concentric.com rePete@cncx.com pete@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@concentric.com rePete@cncx.com pete@internex.net NIC:PB8 Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, CA 95126-3429 Voice: 408-808-6010 Fax: 408-808-6010 From owner-arin-discuss@arin.net Mon Jun 5 20:46:15 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id UAA19714 for arin-discuss-outgoing; Mon, 5 Jun 2000 20:37:39 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA19710 for ; Mon, 5 Jun 2000 20:37:37 -0400 (EDT) Received: from mail.NetWright.Net (MAIL.NETWRIGHT.NET [216.169.0.242]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id UAA26852 for ; Mon, 5 Jun 2000 20:37:31 -0400 (EDT) Received: from Traveler ([216.169.12.221]) by mail.NetWright.Net (Post.Office MTA v3.5.3 release 223 ID# 0-53597U1000L100S0V35) with SMTP id Net; Mon, 5 Jun 2000 18:37:25 -0600 Reply-To: From: "Mike Lieberman" To: "'Pete Bowden'" Cc: Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 18:37:21 -0600 Message-ID: <000101bfcf4f$61351ce0$dd0ca9d8@netwright.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200006060021.RAA08480@skylab.eng.internex.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ > -----Original Message----- > From: Pete Bowden [mailto:repete@cncx.com] > Sent: Monday, June 05, 2000 6:21 PM > To: Mike@netwright.net > Cc: arin-discuss@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@NetWright.Net */ > > /* President */ > > /* Net Wright LLC */ > > /* http://www.netwright.net */ > > /* Voice and Fax: 307-857-1053 */ > > > > > -----Original Message----- > > > From: Pete Bowden [mailto:repete@cncx.com] > > > Sent: Monday, June 05, 2000 5:06 PM > > > To: Mike@netwright.net > > > Cc: arin-discuss@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@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@concentric.com rePete@cncx.com > pete@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@concentric.com rePete@cncx.com pete@internex.net NIC:PB8 > Concentric Network Corporation, 1400 Parkmoor Ave., San Jose, > CA 95126-3429 > Voice: 408-808-6010 Fax: 408-808-6010 > From owner-arin-discuss@arin.net Mon Jun 5 21:10:36 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id VAA20452 for arin-discuss-outgoing; Mon, 5 Jun 2000 21:01:06 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id VAA20447 for ; Mon, 5 Jun 2000 21:01:04 -0400 (EDT) From: cjw@remarque.org Received: from pox.remarque.org (pox.remarque.org [209.209.13.172]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id VAA05440 for ; Mon, 5 Jun 2000 21:01:04 -0400 (EDT) Received: from pox.remarque.org (localhost [127.0.0.1]) by pox.remarque.org (8.9.3/8.9.1) with ESMTP id RAA01610; Mon, 5 Jun 2000 17:59:46 -0700 (PDT) Message-Id: <200006060059.RAA01610@pox.remarque.org> To: Mike@netwright.net cc: "'Pete Bowden'" , arin-discuss@arin.net Subject: Re: 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> Reply-to: cjw@remarque.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1607.960253185.1@pox.remarque.org> Date: Mon, 05 Jun 2000 17:59:45 -0700 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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 owner-arin-discuss@arin.net Mon Jun 5 21:40:06 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id VAA21097 for arin-discuss-outgoing; Mon, 5 Jun 2000 21:31:29 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id VAA21093 for ; Mon, 5 Jun 2000 21:31:28 -0400 (EDT) Received: from mail-la.station.sony.com (mail-la.station.sony.com [209.0.234.32]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id VAA17476 for ; Mon, 5 Jun 2000 21:31:27 -0400 (EDT) Received: by mail-la.station.sony.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Jun 2000 18:31:28 -0700 Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFBBB1@mail-la.station.sony.com> From: "Hostmaster, Verant" To: "'Charles Winter'" Cc: arin-discuss@arin.net Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 18:31:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@verant.com (310) 840-8753 > -----Original Message----- > From: cwinter@communicationnation.com > [SMTP:cwinter@communicationnation.com] > Sent: Monday, June 05, 00 3:18 PM > To: Hostmaster, Verant; 'Paul A Vixie' > Cc: arin-discuss@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@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@verant.com > > (310) 840-8753 > > > > > > > -----Original Message----- > > > From: Paul A Vixie [SMTP:vixie@mibh.net] > > > Sent: Monday, June 05, 00 2:04 PM > > > To: Hostmaster, Verant > > > Cc: 'arin-discuss@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 owner-arin-discuss@arin.net Mon Jun 5 22:25:35 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id WAA23789 for arin-discuss-outgoing; Mon, 5 Jun 2000 22:16:34 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA23781 for ; Mon, 5 Jun 2000 22:16:33 -0400 (EDT) Received: from mail.NetWright.Net (MAIL.NETWRIGHT.NET [216.169.0.242]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id WAA04088 for ; Mon, 5 Jun 2000 22:16:32 -0400 (EDT) Received: from Traveler ([216.169.12.221]) by mail.NetWright.Net (Post.Office MTA v3.5.3 release 223 ID# 0-53597U1000L100S0V35) with SMTP id Net; Mon, 5 Jun 2000 20:16:29 -0600 Reply-To: From: "Mike Lieberman" To: "'Pete Bowden'" , Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 20:16:26 -0600 Message-ID: <000301bfcf5d$38a663c0$dd0ca9d8@netwright.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200006060059.RAA01610@pox.remarque.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR > 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@NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ From owner-arin-discuss@arin.net Mon Jun 5 23:10:41 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id XAA01294 for arin-discuss-outgoing; Mon, 5 Jun 2000 23:02:07 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id XAA01290 for ; Mon, 5 Jun 2000 23:02:06 -0400 (EDT) Received: from mail.NetWright.Net (MAIL.NETWRIGHT.NET [216.169.0.242]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id XAA21792 for ; Mon, 5 Jun 2000 23:02:05 -0400 (EDT) Received: from Traveler ([216.169.12.221]) by mail.NetWright.Net (Post.Office MTA v3.5.3 release 223 ID# 0-53597U1000L100S0V35) with SMTP id Net; Mon, 5 Jun 2000 21:02:01 -0600 Reply-To: From: "Mike Lieberman" To: Cc: Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 21:01:53 -0600 Message-ID: <000401bfcf63$91efff80$dd0ca9d8@netwright.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200006060232.TAA02375@pox.remarque.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR > > 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@NetWright.Net */ > /* President */ > /* Net Wright LLC */ > /* http://www.netwright.net */ > /* Voice and Fax: 307-857-1053 */ > > > From owner-arin-discuss@arin.net Mon Jun 5 23:23:16 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id XAA03319 for arin-discuss-outgoing; Mon, 5 Jun 2000 23:14:53 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id XAA03315 for ; Mon, 5 Jun 2000 23:14:52 -0400 (EDT) Received: from knight.uni.onramp.ca (knight.uni.onramp.ca [198.161.182.8]) by rs2.arin.net (8.9.3/8.9.3) with SMTP id XAA15297 for ; Mon, 5 Jun 2000 23:14:37 -0400 (EDT) Received: (qmail 28858 invoked from network); 6 Jun 2000 03:14:35 -0000 Received: from ppopper.dialup.onramp.ca (HELO lhm12.tor.onramp.ca) (199.246.72.134) by smtp.onramp.ca with SMTP; 6 Jun 2000 03:14:35 -0000 Message-Id: <4.3.2.7.0.20000605224901.00aa0e40@pop.tor.onramp.ca> X-Sender: ppqmt@pop.tor.onramp.ca X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 05 Jun 2000 23:14:32 -0400 To: From: Paul Popper Subject: RE: route filtering policies (from "split b" thread) Cc: In-Reply-To: <000301bfcf5d$38a663c0$dd0ca9d8@netwright.net> References: <200006060059.RAA01610@pox.remarque.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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 owner-arin-discuss@arin.net Mon Jun 5 23:54:52 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id XAA07916 for arin-discuss-outgoing; Mon, 5 Jun 2000 23:46:07 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id XAA07912 for ; Mon, 5 Jun 2000 23:46:05 -0400 (EDT) From: cjw@remarque.org Received: from pox.remarque.org (pox.remarque.org [209.209.13.172]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id XAA08124 for ; Mon, 5 Jun 2000 23:46:05 -0400 (EDT) Received: from pox.remarque.org (localhost [127.0.0.1]) by pox.remarque.org (8.9.3/8.9.1) with ESMTP id UAA02690; Mon, 5 Jun 2000 20:46:02 -0700 (PDT) Message-Id: <200006060346.UAA02690@pox.remarque.org> To: Mike@netwright.net cc: arin-discuss@arin.net Subject: Re: 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> Reply-to: cjw@remarque.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2687.960263161.1@pox.remarque.org> Date: Mon, 05 Jun 2000 20:46:02 -0700 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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 owner-arin-discuss@arin.net Tue Jun 6 00:23:08 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id AAA21910 for arin-discuss-outgoing; Tue, 6 Jun 2000 00:14:37 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA21900 for ; Tue, 6 Jun 2000 00:14:35 -0400 (EDT) Received: from mail.NetWright.Net (MAIL.NETWRIGHT.NET [216.169.0.242]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id AAA29564 for ; Tue, 6 Jun 2000 00:14:35 -0400 (EDT) Received: from Traveler ([216.169.12.221]) by mail.NetWright.Net (Post.Office MTA v3.5.3 release 223 ID# 0-53597U1000L100S0V35) with SMTP id Net; Mon, 5 Jun 2000 22:14:32 -0600 Reply-To: From: "Mike Lieberman" To: Cc: Subject: RE: route filtering policies (from "split b" thread) Date: Mon, 5 Jun 2000 22:14:29 -0600 Message-ID: <000501bfcf6d$b619eb00$dd0ca9d8@netwright.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200006060346.UAA02690@pox.remarque.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR > -----Original Message----- > From: cjw@remarque.org [mailto:cjw@remarque.org] > Sent: Monday, June 05, 2000 9:46 PM > To: Mike@netwright.net > Cc: arin-discuss@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@NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ From owner-arin-discuss@arin.net Tue Jun 6 00:40:10 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id AAA23666 for arin-discuss-outgoing; Tue, 6 Jun 2000 00:31:36 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id AAA23626 for ; Tue, 6 Jun 2000 00:31:23 -0400 (EDT) Received: from freeside.fc.net (freeside.fc.net [207.170.70.2]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id AAA24237 for ; Tue, 6 Jun 2000 00:31:22 -0400 (EDT) Received: from freeside.fc.net (localhost [127.0.0.1]) by freeside.fc.net (8.9.3/8.8.8) with ESMTP id XAA23658; Mon, 5 Jun 2000 23:28:44 -0500 (CDT) Message-Id: <200006060428.XAA23658@freeside.fc.net> To: bmanning@vacation.karoshi.com cc: John.Sweeting@cwusa.com (Sweeting John), arin-discuss@arin.net Subject: Re: split b In-reply-to: Your message of "Mon, 05 Jun 2000 10:37:55 PDT." <200006051737.KAA02756@vacation.karoshi.com> Date: Mon, 05 Jun 2000 23:28:44 -0500 From: Jeremy Porter Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR In message <200006051737.KAA02756@vacation.karoshi.com>, bmanning@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@fc.net Director Network Operations/Network Engineering, Wayport, Inc. 512-519-6193 www.wayport.net 8303 Mopac Expressway Suite A300, Austin Tx. From owner-arin-discuss@arin.net Tue Jun 6 01:40:47 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id BAA00680 for arin-discuss-outgoing; Tue, 6 Jun 2000 01:33:04 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id BAA00676 for ; Tue, 6 Jun 2000 01:33:03 -0400 (EDT) Received: from elektra.ultra.net (elektra.ultra.net [146.115.9.13]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id BAA13109 for ; Tue, 6 Jun 2000 01:33:02 -0400 (EDT) Received: (from u-steve@localhost) by elektra.ultra.net (8.8.8/ult.n26500) id BAA02158; Tue, 6 Jun 2000 01:33:00 -0400 (EDT) Message-Id: <200006060533.BAA02158@elektra.ultra.net> Subject: Re: 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" To: Mike@netwright.net Date: Tue, 6 Jun 2000 01:33:00 -0400 (EDT) From: Stephen Griffin Cc: arin-discuss@arin.net X-Mailer: ELM [version 2.4ME+ PL51 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@rcn.com Network Deployment & Management From owner-arin-discuss@arin.net Tue Jun 6 10:10:54 2000 Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id KAA01272 for arin-discuss-outgoing; Tue, 6 Jun 2000 10:01:39 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA01268 for ; Tue, 6 Jun 2000 10:01:37 -0400 (EDT) Received: from mail.NetWright.Net (MAIL.NETWRIGHT.NET [216.169.0.242]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id KAA04300 for ; Tue, 6 Jun 2000 10:01:19 -0400 (EDT) Received: from Traveler ([216.169.12.221]) by mail.NetWright.Net (Post.Office MTA v3.5.3 release 223 ID# 0-53597U1000L100S0V35) with SMTP id Net; Tue, 6 Jun 2000 08:01:10 -0600 Reply-To: From: "Mike Lieberman" To: "'Stephen Griffin'" Cc: Subject: RE: route filtering policies (from "split b" thread) Date: Tue, 6 Jun 2000 08:01:06 -0600 Message-ID: <000601bfcfbf$a9a92140$dd0ca9d8@netwright.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200006060533.BAA02158@elektra.ultra.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR 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@NetWright.Net */ /* President */ /* Net Wright LLC */ /* http://www.netwright.net */ /* Voice and Fax: 307-857-1053 */ From owner-arin-discuss@arin.net Thu Jul 13 11:13:26 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id LAA23770 for arin-discuss-outgoing; Thu, 13 Jul 2000 11:00:57 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA23766 for ; Thu, 13 Jul 2000 11:00:55 -0400 (EDT) Received: from tcb.net (tcb.net [205.168.100.1]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id LAA06325 for ; Thu, 13 Jul 2000 11:00:57 -0400 (EDT) Received: from sofos.tcb.net (sofos.tcb.net [127.0.0.1]) by tcb.net (8.9.3/8.9.3) with ESMTP id JAA19327 for ; Thu, 13 Jul 2000 09:01:53 -0600 Message-Id: <200007131501.JAA19327@tcb.net> X-Mailer: exmh version 2.0.3 To: arin-discuss@arin.net From: Danny McPherson Reply-To: danny@tcb.net Subject: FYI: 31-bits draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jul 2000 09:01:53 -0600 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR [] To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-retana-31bits-01.txt Date: Thu, 13 Jul 2000 06:28:35 -0400 Sender: nsyracus@cnri.reston.va.us - --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using 31-Bit Prefixes on IPv4 Point-to-Point Links Author(s) : A. Retana, R. White, V. Fuller, D. McPherson Filename : draft-retana-31bits-01.txt Pages : 9 Date : 12-Jul-00 With ever-increasing pressure to conserve IP address space on the Internet, it makes sense to consider where relatively minor changes can be made to fielded practice to improve numbering efficiency. One such change, proposed by this document, is to halve the amount of address space assigned to point-to-point links (common throughout the Internet infrastructure) by allowing the use of 31-bit subnet masks in a very limited way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-retana-31bits-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-retana-31bits-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-retana-31bits-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000712140550.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-retana-31bits-01.txt - --OtherAccess Content-Type: Message/External-body; name="draft-retana-31bits-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000712140550.I-D@ietf.org> - --OtherAccess-- - --NextPart-- From owner-arin-discuss@arin.net Mon Jul 31 17:26:26 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id RAA05559 for arin-discuss-outgoing; Mon, 31 Jul 2000 17:22:21 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA05542; Mon, 31 Jul 2000 17:22:19 -0400 (EDT) Received: from post.xecu.net (post.xecu.net [216.127.136.211]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id RAA04021; Mon, 31 Jul 2000 17:22:42 -0400 (EDT) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by post.xecu.net (Postfix) with ESMTP id B589F47D3; Mon, 31 Jul 2000 17:18:55 -0400 (EDT) Received: from localhost (andy@localhost) by shell.xecu.net (8.8.8+Sun/8.8.8) with ESMTP id RAA01901; Mon, 31 Jul 2000 17:21:21 -0400 (EDT) X-Authentication-Warning: shell.xecu.net: andy owned process doing -bs Date: Mon, 31 Jul 2000 17:21:21 -0400 (EDT) From: Andy Dills To: Bruce Robertson Cc: hostmaster@arin.net, arin-discuss@arin.net Subject: Re: Address block problem In-Reply-To: <200007311831.LAA00950@roo.greatbasin.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR On Mon, 31 Jul 2000, Bruce Robertson wrote: > It was my understanding that 216.82.160.0/19 was reserved for our future > expansion past the end of 216.82.128.0/19. I find that this block has > been assigned to someone else. Why was this allowed to happen without > any notification? > > Once again I find that I am penalized for being frugal with IP addresses. All > of the ARIN policies are such that people who waste IP addresses are > rewarded for that behavior, and people who manage to slow their address > consumption to almost zero are penalized. On top of that, this action just > added to fragmentation, since when I need another /19, it will now no longer > be contiguous with an existing block. While I'm happy to note that my contiguous /19 is still available for me to grab (which will be happening pretty soon), I fail to see what the big deal is. What does having the contiguous /19 really get you? I mean, 7 times out of 10 there will be two routes for the given CIDR block...different prefix lengths for managing inbound traffic, multi-homed customers, etc. So number of routes isn't a large consideration, at least to me. Is it just an annoyance thing? Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access From owner-arin-discuss@arin.net Mon Jul 31 17:48:16 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id RAA07043 for arin-discuss-outgoing; Mon, 31 Jul 2000 17:43:54 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id RAA07038 for ; Mon, 31 Jul 2000 17:43:52 -0400 (EDT) Received: from mail.greatbasin.net (mail.greatbasin.net [207.228.35.39]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id RAA01202 for ; Mon, 31 Jul 2000 17:43:49 -0400 (EDT) Received: from roo.greatbasin.net (IDENT:root@roo.greatbasin.net [207.228.31.16]) by mail.greatbasin.net (8.9.3/8.9.3) with ESMTP id OAA29361; Mon, 31 Jul 2000 14:43:50 -0700 (PDT) Received: from roo.greatbasin.net (IDENT:bruce@localhost.localdomain [127.0.0.1]) by roo.greatbasin.net (8.9.3/8.9.3) with ESMTP id OAA01210; Mon, 31 Jul 2000 14:43:22 -0700 Message-Id: <200007312143.OAA01210@roo.greatbasin.net> X-Mailer: exmh version 2.1.1 10/15/1999 To: Andy Dills cc: arin-discuss@arin.net Subject: Re: Address block problem In-Reply-To: Message from Andy Dills of "Mon, 31 Jul 2000 17:21:21 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Jul 2000 14:43:22 -0700 From: Bruce Robertson Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR > I mean, 7 times out of 10 there will be two routes for the given CIDR > block...different prefix lengths for managing inbound traffic, multi-homed > customers, etc. So number of routes isn't a large consideration, at least > to me. Hmmm, I must be one of the 3 out of 10... I would never use anything but a single advertisement for the entire block. All of my inbound traffic is considered equivalent, and I force my multihomed customers to get their own address space. > Is it just an annoyance thing? Mostly, yes. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 For PGP key: finger bruce@greatbasin.net From owner-arin-discuss@arin.net Mon Jul 31 18:10:35 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA08464 for arin-discuss-outgoing; Mon, 31 Jul 2000 18:06:50 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA08448 for ; Mon, 31 Jul 2000 18:06:48 -0400 (EDT) Received: from post.xecu.net (post.xecu.net [216.127.136.211]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id SAA27428 for ; Mon, 31 Jul 2000 18:07:11 -0400 (EDT) Received: from shell.xecu.net (shell.xecu.net [216.127.136.216]) by post.xecu.net (Postfix) with ESMTP id 2B34E4752; Mon, 31 Jul 2000 18:04:21 -0400 (EDT) Received: from localhost (andy@localhost) by shell.xecu.net (8.8.8+Sun/8.8.8) with ESMTP id SAA03771; Mon, 31 Jul 2000 18:06:46 -0400 (EDT) X-Authentication-Warning: shell.xecu.net: andy owned process doing -bs Date: Mon, 31 Jul 2000 18:06:46 -0400 (EDT) From: Andy Dills To: Bruce Robertson Cc: arin-discuss@arin.net Subject: Re: Address block problem In-Reply-To: <200007312143.OAA01210@roo.greatbasin.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR On Mon, 31 Jul 2000, Bruce Robertson wrote: > > I mean, 7 times out of 10 there will be two routes for the given CIDR > > block...different prefix lengths for managing inbound traffic, multi-homed > > customers, etc. So number of routes isn't a large consideration, at least > > to me. > > Hmmm, I must be one of the 3 out of 10... I would never use anything but > a single advertisement for the entire block. Here's an example of why one would do this: we have transit with UUnet and Abovenet. We service some customers from our colo'ed pop at Abovenet. Thus, I announce an additional /22 to get traffic to return directly to our customers via Abovenet, instead of UUnet-us-Abovenet. BTW, my 7 out of 10 figure was wildly OOMA. I just remember seeing the number of needless routes leaked by UUnet (over 200), and at that point I realized that as long as all of my routes have a purpose, things will be ok. You need 128MB to reliably take 2 full views nowadays anyhow... > All of my inbound traffic is considered equivalent, and I force my > multihomed customers to get their own address space. Why do you force multihomed customers to get their own address space? You need to be using 8 /24's to get PI space. None of my multihomed customers come anywhere near qualifying. De-aggregate routes are not an implication of sloppy routing, but sloppy routing will often utilize de-aggregate routes. > > Is it just an annoyance thing? > > Mostly, yes. That's cool, I can feel for you. I certainly can imagine that finding out this information would put a sour note onto the end of your day... Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access From owner-arin-discuss@arin.net Mon Jul 31 18:24:18 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA09364 for arin-discuss-outgoing; Mon, 31 Jul 2000 18:20:23 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA09360 for ; Mon, 31 Jul 2000 18:20:22 -0400 (EDT) Received: from mail.greatbasin.net (mail.greatbasin.net [207.228.35.39]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id SAA12291 for ; Mon, 31 Jul 2000 18:20:45 -0400 (EDT) Received: from roo.greatbasin.net (IDENT:root@roo.greatbasin.net [207.228.31.16]) by mail.greatbasin.net (8.9.3/8.9.3) with ESMTP id PAA21182; Mon, 31 Jul 2000 15:20:19 -0700 (PDT) Received: from roo.greatbasin.net (IDENT:bruce@localhost.localdomain [127.0.0.1]) by roo.greatbasin.net (8.9.3/8.9.3) with ESMTP id PAA01251; Mon, 31 Jul 2000 15:19:52 -0700 Message-Id: <200007312219.PAA01251@roo.greatbasin.net> X-Mailer: exmh version 2.1.1 10/15/1999 To: Andy Dills cc: arin-discuss@arin.net Subject: Re: Address block problem In-Reply-To: Message from Andy Dills of "Mon, 31 Jul 2000 18:06:46 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 31 Jul 2000 15:19:51 -0700 From: Bruce Robertson Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR > Why do you force multihomed customers to get their own address space? You > need to be using 8 /24's to get PI space. None of my multihomed customers > come anywhere near qualifying. Hmmm... mine do. A couple have single /24s from the swamp that I'm advertising under protest, but the rest have large blocks. -- Bruce Robertson, President/CEO +1-775-348-7299 Great Basin Internet Services, Inc. fax: +1-775-348-9412 For PGP key: finger bruce@greatbasin.net From owner-arin-discuss@arin.net Mon Jul 31 18:38:58 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA10000 for arin-discuss-outgoing; Mon, 31 Jul 2000 18:35:00 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA09996 for ; Mon, 31 Jul 2000 18:34:59 -0400 (EDT) Received: from mail-la.station.sony.com (mail-la.station.sony.com [209.0.234.32]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id SAA23252 for ; Mon, 31 Jul 2000 18:34:55 -0400 (EDT) Received: by mail-la.station.sony.com with Internet Mail Service (5.5.2650.21) id ; Mon, 31 Jul 2000 15:34:37 -0700 Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFC01C@mail-la.station.sony.com> From: "Hostmaster, Verant" To: arin-discuss@arin.net Cc: "Hostmaster, Verant" Subject: RE: Address block problem Date: Mon, 31 Jul 2000 15:34:30 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Yeah, /24's are fine as long as you're not a recent recipient of address space, like us. We have a block from the 64.0.0.0/8 space, but we can't advertise /24's out of that block because some stick-in-the-mud ISPs out there still consider them from the "class A" address space, and filter them out. ---- Dani Roisman Verant Interactive hostmaster@verant.com > -----Original Message----- > From: Bruce Robertson [SMTP:bruce@greatbasin.net] > Sent: Monday, July 31, 00 3:20 PM > To: Andy Dills > Cc: arin-discuss@arin.net > Subject: Re: Address block problem > > > Why do you force multihomed customers to get their own address space? > You > > need to be using 8 /24's to get PI space. None of my multihomed > customers > > come anywhere near qualifying. > > Hmmm... mine do. A couple have single /24s from the swamp that I'm > advertising under protest, but the rest have large blocks. > > -- > Bruce Robertson, President/CEO > +1-775-348-7299 > Great Basin Internet Services, Inc. fax: +1-775-348-9412 > For PGP key: finger bruce@greatbasin.net > From owner-arin-discuss@arin.net Mon Jul 31 18:43:55 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA10262 for arin-discuss-outgoing; Mon, 31 Jul 2000 18:40:16 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA10249; Mon, 31 Jul 2000 18:40:15 -0400 (EDT) Received: from flood.goldengate.net (flood.goldengate.net [209.240.87.82]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id SAA25354; Mon, 31 Jul 2000 18:40:11 -0400 (EDT) Received: from dew.goldengate.net (mury@dew.goldengate.net [209.240.87.78]) by flood.goldengate.net (8.9.3/8.9.3) with ESMTP id RAA02459; Mon, 31 Jul 2000 17:34:36 -0500 (CDT) Date: Mon, 31 Jul 2000 17:40:07 -0500 (CDT) From: Mury To: Andy Dills cc: Bruce Robertson , hostmaster@arin.net, arin-discuss@arin.net Subject: Re: Address block problem In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR I'll tell you why it's annoying. If you are managing multiple routers and multiple IP blocks every time you have to make a global change (for example in an access-list) it just gets to be that much more work. I know there are a ton of ISPs that do not filter traffic, and I don't want to get into a discussion on why you should or should not filter traffic. The point is there are a lot of ISPs and many more companys that do filter traffic on their core routers. If I need to make a change to my access-lists in general it causes my list to be a multiple of however many blocks I have longer than it needs to be. And for the person who is going to say just do a "permit any", that doesn't work because I do have one small chunk that I treat differently, even at the core. Everything is more difficult to manage. You have to put more blocks into your network statements. You have that many more blocks to change contact info for, and I for one have never found dealing with Arin's contact info templates the easiest thing in the world. You have more lines for sendmail to check through to allow or deny mail relay. The examples could go on for quite awhile. No, it's not going to cost me $10K more money to deal with it, but it is a pain. And to Bruce, I was told by Arin that they no longer do any block reservations. And if someone else out there is able to reserve IP space, and I wasn't able to, I'm going to be incredibly unhappy with Arin. I don't think any court of law would take kindly to them playing favorites. Mury GoldenGate Internet Services On Mon, 31 Jul 2000, Andy Dills wrote: > On Mon, 31 Jul 2000, Bruce Robertson wrote: > > > It was my understanding that 216.82.160.0/19 was reserved for our future > > expansion past the end of 216.82.128.0/19. I find that this block has > > been assigned to someone else. Why was this allowed to happen without > > any notification? > > > > Once again I find that I am penalized for being frugal with IP addresses. All > > of the ARIN policies are such that people who waste IP addresses are > > rewarded for that behavior, and people who manage to slow their address > > consumption to almost zero are penalized. On top of that, this action just > > added to fragmentation, since when I need another /19, it will now no longer > > be contiguous with an existing block. > > While I'm happy to note that my contiguous /19 is still available for me > to grab (which will be happening pretty soon), I fail to see what > the big deal is. > > What does having the contiguous /19 really get you? > > I mean, 7 times out of 10 there will be two routes for the given CIDR > block...different prefix lengths for managing inbound traffic, multi-homed > customers, etc. So number of routes isn't a large consideration, at least > to me. > > Is it just an annoyance thing? > > Andy > > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Andy Dills 301-682-9972 > Xecunet, LLC www.xecu.net > xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > Dialup * Webhosting * E-Commerce * High-Speed Access > From owner-arin-discuss@arin.net Mon Jul 31 19:03:31 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id SAA11305 for arin-discuss-outgoing; Mon, 31 Jul 2000 18:59:28 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id SAA11301 for ; Mon, 31 Jul 2000 18:59:26 -0400 (EDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by rs1.arin.net (8.9.3/8.9.3) with SMTP id SAA25646 for ; Mon, 31 Jul 2000 18:59:49 -0400 (EDT) Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 31 Jul 2000 16:58:48 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Mon, 31 Jul 2000 16:57:53 -0600 From: "Hilarie Orman" To: Subject: Re: Address block problem Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ops.arin.net id SAA11302 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR ARIN policies are based, in large part, on the principle of avoiding fragmentation. The question is, what led to the expectation of reserved space for the block in question, did the holder of it meet the conditions for holding the space? There's no secrecy about the policies, so it should be easy to resolve the question. Hilarie Orman ARIN AC From owner-arin-discuss@arin.net Tue Aug 1 09:17:56 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id JAA17487 for arin-discuss-outgoing; Tue, 1 Aug 2000 09:13:17 -0400 (EDT) Received: from snoopy (snoopy.arin.net [192.149.252.189]) by ops.arin.net (8.9.0/8.9.0) with SMTP id JAA17483; Tue, 1 Aug 2000 09:13:15 -0400 (EDT) Reply-To: From: "Richard Jimmerson" To: "'Bruce Robertson'" Cc: Subject: RE: Address block problem Date: Tue, 1 Aug 2000 09:22:33 -0400 Message-ID: <000101bffbbb$8dfc94e0$bdfc95c0@ARINNET> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200007311831.LAA00950@roo.greatbasin.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Hello Bruce, > It was my understanding that 216.82.160.0/19 was reserved > for our future expansion past the end of 216.82.128.0/19. > I find that this block has been assigned to someone else. > Why was this allowed to happen without any notification? ARIN does not guarantee the reservation of IP address space. There are times ARIN does hold a reservation for an organization who has been approved for IP address space, but that is an internal practice and is not guaranteed to the requesting organization. If ARIN finds a reservation has been held for more than one year, and in this case almost two, the reservation is removed for assignment elsewhere. Regards, Richard Jimmerson American Registry for Internet Numbers (ARIN) >-----Original Message----- >From: owner-arin-discuss@arin.net >[mailto:owner-arin-discuss@arin.net]On >Behalf Of Bruce Robertson >Sent: Monday, July 31, 2000 2:31 PM >To: hostmaster@arin.net >Cc: arin-discuss@arin.net >Subject: Address block problem > > >It was my understanding that 216.82.160.0/19 was reserved for >our future >expansion past the end of 216.82.128.0/19. I find that this block has >been assigned to someone else. Why was this allowed to happen without >any notification? > >Once again I find that I am penalized for being frugal with IP >addresses. All >of the ARIN policies are such that people who waste IP addresses are >rewarded for that behavior, and people who manage to slow their address >consumption to almost zero are penalized. On top of that, >this action just >added to fragmentation, since when I need another /19, it will >now no longer >be contiguous with an existing block. > >-- >Bruce Robertson, President/CEO >+1-775-348-7299 >Great Basin Internet Services, Inc. fax: >+1-775-348-9412 >For PGP key: finger bruce@greatbasin.net > From owner-arin-discuss@arin.net Tue Aug 1 13:54:14 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id NAA19382 for arin-discuss-outgoing; Tue, 1 Aug 2000 13:49:53 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA19372 for ; Tue, 1 Aug 2000 13:49:51 -0400 (EDT) Received: from mail-la.station.sony.com (mail-la.station.sony.com [209.0.234.32]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id NAA08468 for ; Tue, 1 Aug 2000 13:49:48 -0400 (EDT) Received: by mail-la.station.sony.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 10:49:37 -0700 Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFC035@mail-la.station.sony.com> From: "Hostmaster, Verant" To: "'arin-discuss@arin.net'" Subject: RE: Address block problem Date: Tue, 1 Aug 2000 10:49:27 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Joe, Problem with this setup - here's a hypothetical, ISP E is the one that is filtering anything longer than a /20. I'll announce the /21's and a /20 to my connections to ISPA, B, C, and D. ISPE. A, B, C, and D and their peers that to not filter will make routing decisions based upon most specific, and my network will be visible to ISP E. +--------------+ +--------------+ ISP A--| network | | network |--ISP C--ISP E | one |-------| two | ISP B--| 10.10.128/21 | DS3 | 10.10.136/21 |--ISP D +--------------+ +--------------+ That is all good while the connection between my distributed networks is up, but when that DS3 goes down, and I'm still announcing packets for the entire /20, I run a serious risk of blackholing network one from folks connected to ISP E, since it will still think that network two provides connectivity to network one. Here are the filtering policies that I could find, I look forwards to any additional ones that are known: http://www.mibh.net/mibh-peering.html http://info.us.bb.verio.net/routing.html#PeerFilter ---- Dani Roisman Verant Interactive hostmaster@verant.com > -----Original Message----- > From: Joe Gilbert [SMTP:joe@zyan.com] > Sent: Tuesday, August 01, 00 10:14 AM > To: Hostmaster, Verant; 'arin-discuss@arin.net' > Subject: RE: Address block problem > > Dani, > > There is another possible solution other than "wasting IP Address > space." Assuming that some larger ISPs filter BGP announcements smaller > than a /20 or /19 (which used to be ARIN's minimum allocation), there is a > > way to announce a smaller block for a geographically disparate network > without compromising routing. By the way, if anyone knows the ISPs that > specifically filter smaller announcements, it would be very handy to have > a > list of these ISPs and their policies. Is there possibly a web site > maintained with this information? > > In any case, here is a solution that I propose that I have worked with and > > is definitely workable in the real world Internet enviroment. What I have > > seen ISPs do to solve this problem is to announce the smaller block, i.e. > /22, that is being used at the geographically disparate network via BGP to > > the upstream providers in that location. Some ISPs will filter that > announcement but most will see it and route traffic within that CIDR block > > directly to your network. To get around the filtering, you should > announce > the /20 at a central location, hopefully where you are using the rest of > the aggregate. That way, even if an ISP is filtering your smaller > announcement, they will see your larger announcement and route the packets > > to the AS that they are receiving that announcement from. Hopefully, that > > AS is not filtering the smaller announcement and will route the traffic to > > the more specific announcement. However, even if some of the traffic does > > get all the way back to your central location without hitting an AS that > is > not filtering, I am sure you could handle that amount of traffic on your > internal links. In actual practice, you probably will not see any traffic > > hitting the AS where the aggregate route is being announced from if you > are > advertising a more specific route elsewhere. All in all, this is a > solution that leads to desirable results and does not greatly > overcomplicate your network. > > > -- > Joe Gilbert, Development Engineer > Zyan Communications > http://www.zyan.com mailto:joe@zyan.com > Toll Free 800-DSL SPEED 800-375-7733 Fax 213-488-6101 > Internet Access DSL T1 T3 VPN Hosting Ecommerce > > > > At 09:07 AM 8/1/00, Hostmaster, Verant wrote: > >Jason, I'd agree with you for most cases, but in our case, we have a /18, > >and have a few networks that are distributed geographically, and are > >multihomed. In some cases, there is an imbalance between our > connectivity > >to the Internet, and our connectivity within an AS. E.g. one network > might > >have 2 oc12's to 2 different ISPs, but only have a ds3 back to the rest > of > >our network for internal traffic. I only have a /22 worth of address > space > >on that network, but I have to waste and announce an entire /20, because > >that's all that Verio, mibh, and a few others, will accept from my > >64.37.128.0/18 block. > > > >Now, had I gotten into the game a year ago, my block's first octet would > >have been in the 200's, and I would be free to use /24's (which I > wouldn't, > >the smallest I will announce is a /22). > > > >So possbile solutions are: > >1) get in the game early (too late) > >2) waste tons of address space (I hate to do this, but it works) > >3) make enough noise, and tell my customers to change isp's when they > can't > >reach my network, and hope that these few ISP's realize that the rest of > the > >Internet is accepting /24's from all blocks, and their routers haven't > >suffered, so they better jump on the bandwagon. > > > >We're going with option 3 for now, and see where that takes us. > > > >Dani D. Roisman > >Verant Interactive > >hostmaster@verant.com > > > > > > > -----Original Message----- > > > From: Redisch, Jason [SMTP:JRedisch@virtela.com] > > > Sent: Tuesday, August 01, 2000 8:32 AM > > > To: arin-discuss@arin.net > > > Subject: RE: Address block problem > > > > > > Dani, > > > Many ISP's have IP Space from legacy Class A space. A check of > the > > > whois database would show that anyone still filtering on /8 on that > space > > > is > > > missing a large portion of the Internet. A simple call to their POC > > > should > > > fix any connectivity issues. > > > > > > However, several ISP's choose to filter all address space based > on > > > the ARIN min allocation size for that block. They feel that they can > > > reach > > > the entire Internet that way while keeping routing tables on their > > > networks > > > to a minimum size. This decision to filter or not is made by each ISP > > > individually. In doing so, these ISP's sometimes sacrifice more > optimal > > > paths, but in can still reach the entire Internet. Announcing /24's > for > > > multihomed customers should work for the portion of the Internet that > > > wants > > > to listen to them, and the larger aggregate blocks of the upstream can > be > > > used to direct traffic for those ISP's that do filter at the higher > bit > > > boundaries. > > > > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > > > /\ > > > /\/\/\/\/\/\/\ > > > Jason Redisch (V) 720.493.5533 ext 4120 > > > Virtela Communications (F) 720.493.5006 > > > Sr. IP Engineer > > > > > > > > > > > > > > > -----Original Message----- > > > From: Hostmaster, Verant [mailto:hostmaster@verant.com] > > > Sent: Monday, July 31, 2000 4:35 PM > > > To: arin-discuss@arin.net > > > Cc: Hostmaster, Verant > > > Subject: RE: Address block problem > > > > > > > > > Yeah, /24's are fine as long as you're not a recent recipient of > address > > > space, like us. We have a block from the 64.0.0.0/8 space, but we > can't > > > advertise /24's out of that block because some stick-in-the-mud ISPs > out > > > there still consider them from the "class A" address space, and filter > > > them > > > out. > > > > > > ---- > > > Dani Roisman > > > Verant Interactive > > > hostmaster@verant.com > > > > > > > -----Original Message----- > > > > From: Bruce Robertson [SMTP:bruce@greatbasin.net] > > > > Sent: Monday, July 31, 00 3:20 PM > > > > To: Andy Dills > > > > Cc: arin-discuss@arin.net > > > > Subject: Re: Address block problem > > > > > > > > > Why do you force multihomed customers to get their own address > space? > > > > You > > > > > need to be using 8 /24's to get PI space. None of my multihomed > > > > customers > > > > > come anywhere near qualifying. > > > > > > > > Hmmm... mine do. A couple have single /24s from the swamp that I'm > > > > advertising under protest, but the rest have large blocks. > > > > > > > > -- > > > > Bruce Robertson, President/CEO > > > > +1-775-348-7299 > > > > Great Basin Internet Services, Inc. fax: > +1-775-348-9412 > > > > For PGP key: finger bruce@greatbasin.net > > > > From owner-arin-discuss@arin.net Tue Aug 1 11:36:48 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id LAA04086 for arin-discuss-outgoing; Tue, 1 Aug 2000 11:32:09 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id LAA04081 for ; Tue, 1 Aug 2000 11:32:07 -0400 (EDT) Received: from mulder.regus.virtela.com (virtela50.ppp.frii.net [216.17.165.50]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id LAA23638 for ; Tue, 1 Aug 2000 11:32:03 -0400 (EDT) Received: from posthaus.virtela.cc (posthaus.virtela.cc [172.16.97.7]) by mulder.regus.virtela.com (8.9.3/8.9.3) with ESMTP id JAA12094 for ; Tue, 1 Aug 2000 09:32:03 -0600 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 09:31:58 -0600 Message-ID: From: "Redisch, Jason" To: arin-discuss@arin.net Subject: RE: Address block problem Date: Tue, 1 Aug 2000 09:31:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Dani, Many ISP's have IP Space from legacy Class A space. A check of the whois database would show that anyone still filtering on /8 on that space is missing a large portion of the Internet. A simple call to their POC should fix any connectivity issues. However, several ISP's choose to filter all address space based on the ARIN min allocation size for that block. They feel that they can reach the entire Internet that way while keeping routing tables on their networks to a minimum size. This decision to filter or not is made by each ISP individually. In doing so, these ISP's sometimes sacrifice more optimal paths, but in can still reach the entire Internet. Announcing /24's for multihomed customers should work for the portion of the Internet that wants to listen to them, and the larger aggregate blocks of the upstream can be used to direct traffic for those ISP's that do filter at the higher bit boundaries. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ /\/\/\/\/\/\/\ Jason Redisch (V) 720.493.5533 ext 4120 Virtela Communications (F) 720.493.5006 Sr. IP Engineer -----Original Message----- From: Hostmaster, Verant [mailto:hostmaster@verant.com] Sent: Monday, July 31, 2000 4:35 PM To: arin-discuss@arin.net Cc: Hostmaster, Verant Subject: RE: Address block problem Yeah, /24's are fine as long as you're not a recent recipient of address space, like us. We have a block from the 64.0.0.0/8 space, but we can't advertise /24's out of that block because some stick-in-the-mud ISPs out there still consider them from the "class A" address space, and filter them out. ---- Dani Roisman Verant Interactive hostmaster@verant.com > -----Original Message----- > From: Bruce Robertson [SMTP:bruce@greatbasin.net] > Sent: Monday, July 31, 00 3:20 PM > To: Andy Dills > Cc: arin-discuss@arin.net > Subject: Re: Address block problem > > > Why do you force multihomed customers to get their own address space? > You > > need to be using 8 /24's to get PI space. None of my multihomed > customers > > come anywhere near qualifying. > > Hmmm... mine do. A couple have single /24s from the swamp that I'm > advertising under protest, but the rest have large blocks. > > -- > Bruce Robertson, President/CEO > +1-775-348-7299 > Great Basin Internet Services, Inc. fax: +1-775-348-9412 > For PGP key: finger bruce@greatbasin.net > From owner-arin-discuss@arin.net Tue Aug 1 12:11:21 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id MAA08519 for arin-discuss-outgoing; Tue, 1 Aug 2000 12:07:29 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA08515 for ; Tue, 1 Aug 2000 12:07:28 -0400 (EDT) Received: from mail-la.station.sony.com (mail-la.station.sony.com [209.0.234.32]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id MAA12910 for ; Tue, 1 Aug 2000 12:07:52 -0400 (EDT) Received: by mail-la.station.sony.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 09:07:06 -0700 Message-ID: <51EC05AE2DD6D111A0CF00805F6F410B01CFC031@mail-la.station.sony.com> From: "Hostmaster, Verant" To: "'arin-discuss@arin.net'" Subject: RE: Address block problem Date: Tue, 1 Aug 2000 09:07:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Jason, I'd agree with you for most cases, but in our case, we have a /18, and have a few networks that are distributed geographically, and are multihomed. In some cases, there is an imbalance between our connectivity to the Internet, and our connectivity within an AS. E.g. one network might have 2 oc12's to 2 different ISPs, but only have a ds3 back to the rest of our network for internal traffic. I only have a /22 worth of address space on that network, but I have to waste and announce an entire /20, because that's all that Verio, mibh, and a few others, will accept from my 64.37.128.0/18 block. Now, had I gotten into the game a year ago, my block's first octet would have been in the 200's, and I would be free to use /24's (which I wouldn't, the smallest I will announce is a /22). So possbile solutions are: 1) get in the game early (too late) 2) waste tons of address space (I hate to do this, but it works) 3) make enough noise, and tell my customers to change isp's when they can't reach my network, and hope that these few ISP's realize that the rest of the Internet is accepting /24's from all blocks, and their routers haven't suffered, so they better jump on the bandwagon. We're going with option 3 for now, and see where that takes us. Dani D. Roisman Verant Interactive hostmaster@verant.com > -----Original Message----- > From: Redisch, Jason [SMTP:JRedisch@virtela.com] > Sent: Tuesday, August 01, 2000 8:32 AM > To: arin-discuss@arin.net > Subject: RE: Address block problem > > Dani, > Many ISP's have IP Space from legacy Class A space. A check of the > whois database would show that anyone still filtering on /8 on that space > is > missing a large portion of the Internet. A simple call to their POC > should > fix any connectivity issues. > > However, several ISP's choose to filter all address space based on > the ARIN min allocation size for that block. They feel that they can > reach > the entire Internet that way while keeping routing tables on their > networks > to a minimum size. This decision to filter or not is made by each ISP > individually. In doing so, these ISP's sometimes sacrifice more optimal > paths, but in can still reach the entire Internet. Announcing /24's for > multihomed customers should work for the portion of the Internet that > wants > to listen to them, and the larger aggregate blocks of the upstream can be > used to direct traffic for those ISP's that do filter at the higher bit > boundaries. > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > /\ > /\/\/\/\/\/\/\ > Jason Redisch (V) 720.493.5533 ext 4120 > Virtela Communications (F) 720.493.5006 > Sr. IP Engineer > > > > > -----Original Message----- > From: Hostmaster, Verant [mailto:hostmaster@verant.com] > Sent: Monday, July 31, 2000 4:35 PM > To: arin-discuss@arin.net > Cc: Hostmaster, Verant > Subject: RE: Address block problem > > > Yeah, /24's are fine as long as you're not a recent recipient of address > space, like us. We have a block from the 64.0.0.0/8 space, but we can't > advertise /24's out of that block because some stick-in-the-mud ISPs out > there still consider them from the "class A" address space, and filter > them > out. > > ---- > Dani Roisman > Verant Interactive > hostmaster@verant.com > > > -----Original Message----- > > From: Bruce Robertson [SMTP:bruce@greatbasin.net] > > Sent: Monday, July 31, 00 3:20 PM > > To: Andy Dills > > Cc: arin-discuss@arin.net > > Subject: Re: Address block problem > > > > > Why do you force multihomed customers to get their own address space? > > You > > > need to be using 8 /24's to get PI space. None of my multihomed > > customers > > > come anywhere near qualifying. > > > > Hmmm... mine do. A couple have single /24s from the swamp that I'm > > advertising under protest, but the rest have large blocks. > > > > -- > > Bruce Robertson, President/CEO > > +1-775-348-7299 > > Great Basin Internet Services, Inc. fax: +1-775-348-9412 > > For PGP key: finger bruce@greatbasin.net > > From owner-arin-discuss@arin.net Mon Aug 7 10:58:33 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id KAA23111 for arin-discuss-outgoing; Mon, 7 Aug 2000 10:45:22 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id KAA23103 for ; Mon, 7 Aug 2000 10:45:20 -0400 (EDT) Received: from mulder.regus.virtela.com (virtela50.ppp.frii.net [216.17.165.50]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id KAA06802 for ; Mon, 7 Aug 2000 10:45:51 -0400 (EDT) Received: from posthaus.virtela.cc (posthaus.virtela.cc [172.16.97.7]) by mulder.regus.virtela.com (8.9.3/8.9.3) with ESMTP id IAA20714 for ; Mon, 7 Aug 2000 08:45:12 -0600 Received: by posthaus.virtela.cc with Internet Mail Service (5.5.2650.21) id ; Mon, 7 Aug 2000 08:45:04 -0600 Message-ID: From: "Redisch, Jason" To: arin-discuss@arin.net Subject: Interesting Concept Date: Mon, 7 Aug 2000 08:45:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Hello All, http://www.zdnet.com/zdnn/stories/news/0,4586,2612074,00.html?chkpt=zdhpnews 01 In the article at the URL above there is an upcoming IP address issue that needs to be taken care soon. The summary of the article is that they want to protect children by reserving blocks of IP Space to be allocated to kid friendly sites. This seems to be in the idea stage and 'they' are still considering a DNS implementation. Please tell me that we have someone in ARIN or the ASO working on a recommendation not to implement this idea, or at least following it better with closer ties to the decision makers. I apologize if this is a topic already being discussed on another ARIN mailing list. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ /\/\/\/\/\/\/\ Jason Redisch (V) 720.493.5533 ext 4120 Virtela Communications (F) 720.493.5006 Sr. IP Engineer From owner-arin-discuss@arin.net Mon Sep 11 12:52:53 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id MAA05966 for arin-discuss-outgoing; Mon, 11 Sep 2000 12:32:23 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id MAA05962; Mon, 11 Sep 2000 12:32:21 -0400 (EDT) Received: from mail.norlight.com (mail.norlight.com [207.170.3.35]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id MAA07632; Mon, 11 Sep 2000 12:32:11 -0400 (EDT) Received: from lotus.norlight.com (lotus [89.87.145.18]) by mail.norlight.com (8.9.3/8.9.3) with ESMTP id LAA27889; Mon, 11 Sep 2000 11:29:34 -0500 Subject: guideline for name-based web hosting justification To: hostnamster@arin.net Cc: "arin-discuss@arin.net" X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: From: "Hyunseog Ryu" Date: Mon, 11 Sep 2000 11:29:03 -0500 X-MIMETrack: Serialize by Router on Lotus/Norlight(Release 5.0.4a |July 24, 2000) at 09/11/2000 11:29:02 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Dear Sir/Madam Good morning! I read new ARIN's policy regarding to web hosting. http://www.arin.net/announcements/policy_changes.html But what is the acceptable guideline - or ratio - for IP justification of web hosting? Currently we have heavy web hosting customer that they hosted more than 400 regular business web hosting customer, and more than 200 web hosting customer site to be live soon. According to me, it's not make sense to assign a couple of IP address to a couple of hundred web hosting. I think there is some standard measurement for this kind of name-based web hosting justification. Please let me know the standard ratio for name-based web hosting for IP justification. What is a ratio for IP justification for name-based web hosting justification that can be considered as acceptable justification? Everytime when we get additional IP address from web hosting service provider, do we need to contact with ARIN to get exceptiion warranty? Please make it easy to justify IP request. I think we need to have standard measurement for this. Thanks. Hyun ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hyunseog Ryu / CCDA, MCSE Network Engineer/Applications Engineering Norlight Telecommunications, Inc. The Guardians of Data 275 North Corporate Drive Brookfield, WI 53045-5818 Tel. +1.262.792.7965 Fax. +1.262.792.7733 From owner-arin-discuss@arin.net Mon Sep 11 13:44:29 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id NAA12042 for arin-discuss-outgoing; Mon, 11 Sep 2000 13:32:39 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id NAA12037 for ; Mon, 11 Sep 2000 13:32:37 -0400 (EDT) Received: from smtp.journey.com (postfix@smtp-temp.michix.net [207.241.134.28]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id NAA09639 for ; Mon, 11 Sep 2000 13:32:37 -0400 (EDT) Received: from matt (unknown [207.241.139.27]) by smtp.journey.com (Postfix) with SMTP id 3734A12C85F for ; Mon, 11 Sep 2000 13:32:39 -0400 (EDT) From: "Matt Bailey" To: Subject: RE: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 13:32:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR For those of us that do accounting via IP how do you expect us to us Name Based Virtuals? Until there is a method for accounting all traffic to a domain name without using IP I see this as totally unreasonable. We base all of our security filters and traffic filters on a customers IP assigned to them. We also have hardware that can not support name based virtuals and thus has a NIC card for each site? Explain IN DETAIL the method used to account for these in our requests. As example if I have 200,000 websites you want me to fit all of this into a /32 or even a /24 that is TOTALLY unreasonable. DETAILS please on how you are going to justify this? Also why not go through the aollocations and start retreiving numbers back from Companies and schools that have more than they need? All you are doing is slowing down the Internet's growth. Make web hosting companies get to the high %90 utils before allow more allocation. I would like some input on this as I am sure the rest of the planet would as well. Matthew S. Bailey -----Original Message----- From: owner-arin-discuss@arin.net [mailto:owner-arin-discuss@arin.net]On Behalf Of Hyunseog Ryu Sent: Monday, September 11, 2000 12:29 PM To: hostnamster@arin.net Cc: arin-discuss@arin.net Subject: guideline for name-based web hosting justification Dear Sir/Madam Good morning! I read new ARIN's policy regarding to web hosting. http://www.arin.net/announcements/policy_changes.html [SNIP] From owner-arin-discuss@arin.net Mon Sep 11 16:18:26 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id QAA05975 for arin-discuss-outgoing; Mon, 11 Sep 2000 16:06:58 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA05961 for ; Mon, 11 Sep 2000 16:06:56 -0400 (EDT) Received: from smtp.journey.com (postfix@smtp-temp.michix.net [207.241.134.28]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id QAA09246 for ; Mon, 11 Sep 2000 16:06:55 -0400 (EDT) Received: from matt (unknown [207.241.139.27]) by smtp.journey.com (Postfix) with SMTP id 0A11512C840 for ; Mon, 11 Sep 2000 16:07:12 -0400 (EDT) From: "Matt Bailey" To: Subject: RE: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 16:06:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <01C01BFF.89A869A0.sburns@rackspace.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Sounds like they are using a double edged sword to answer their own questions. Don't do that but its ok to continue if you want to. What is the point of the policy then? If that is the case the it should be stricken (SP?) fromt he records until better methods are found.. There might be Web hosting companies out there that do namebased virtuals.. But they already do that. If there were not other technical problems wih it everyone would have already switched. The fact they think we waste space on purpose is obsurd. So we can say 'I have more space that you' no we do this because our business need it.. --Matt -----Original Message----- From: sharon [mailto:sburns@rackspace.com] Sent: Monday, September 11, 2000 3:50 PM To: 'Matt Bailey'; arin-discuss@arin.net Subject: RE: guideline for name-based web hosting justification I have had several conversations with ARIN regarding this new policy. I was also told that(as asked earlier by Hyunseog Ryu), I have also been told that it is not necessary to forward each request for ARIN's approval or exception to the policy. I have been told that as long as it's not for IP based hosting it would be considered acceptable use. In fact this is the quote that was sent to me from ARIN: ".... Please continue to issue static IP addresses to your customers who state they are offering a service that is not technically complaint with name-based hosting...." Hope this helps to give some of you insite. Sharon Burns IP Administrator Rackspace Managed Hosting 112 East Pecan St. Ste. 600 San Antonio, TX 78240 210-892-4010 -----Original Message----- From: Matt Bailey [SMTP:mbailey@journey.net] Sent: Monday, September 11, 2000 12:32 PM To: arin-discuss@arin.net Subject: RE: guideline for name-based web hosting justification For those of us that do accounting via IP how do you expect us to us Name Based Virtuals? Until there is a method for accounting all traffic to a domain name without using IP I see this as totally unreasonable. We base all of our security filters and traffic filters on a customers IP assigned to them. We also have hardware that can not support name based virtuals and thus has a NIC card for each site? Explain IN DETAIL the method used to account for these in our requests. As example if I have 200,000 websites you want me to fit all of this into a /32 or even a /24 that is TOTALLY unreasonable. DETAILS please on how you are going to justify this? Also why not go through the aollocations and start retreiving numbers back from Companies and schools that have more than they need? All you are doing is slowing down the Internet's growth. Make web hosting companies get to the high %90 utils before allow more allocation. I would like some input on this as I am sure the rest of the planet would as well. Matthew S. Bailey -----Original Message----- From: owner-arin-discuss@arin.net [mailto:owner-arin-discuss@arin.net]On Behalf Of Hyunseog Ryu Sent: Monday, September 11, 2000 12:29 PM To: hostnamster@arin.net Cc: arin-discuss@arin.net Subject: guideline for name-based web hosting justification Dear Sir/Madam Good morning! I read new ARIN's policy regarding to web hosting. http://www.arin.net/announcements/policy_changes.html [SNIP] From owner-arin-discuss@arin.net Mon Sep 11 16:33:37 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id QAA09121 for arin-discuss-outgoing; Mon, 11 Sep 2000 16:23:33 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id QAA09096 for ; Mon, 11 Sep 2000 16:23:31 -0400 (EDT) Received: from longhorn.nvc.net (mailserver.nvc.net [209.74.73.237]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id QAA22190 for ; Mon, 11 Sep 2000 16:23:31 -0400 (EDT) Received: from nvc.net (unverified [127.0.0.1]) by longhorn.nvc.net (Rockliffe SMTPRA 4.2.4) with ESMTP id ; Mon, 11 Sep 2000 15:39:32 -0500 Message-ID: <2446420009111203932890@nvc.net> X-EM-Version: 5, 0, 0, 7 X-EM-Registration: #3053500714A91F039330 X-Priority: 3 Reply-To: brianj@nvc.net From: "brianj" To: mbailey@journey.net Cc: arin-discuss@arin.net Subject: RE: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 15:39:32 -0500 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR ---- Original Message ---- From: mbailey@journey.net To: arin-discuss@arin.net, Subject: RE: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 13:32:07 -0400 >For those of us that do accounting via IP how do you expect us to us >Name >Based Virtuals? Until there is a method for accounting all traffic >to a >domain name without using IP I see this as totally unreasonable. We >base all >of our security filters and traffic filters on a customers IP >assigned to >them. We also have hardware that can not support name based virtuals >and >thus has a NIC card for each site? Explain IN DETAIL the method used >to >account for these in our requests. If you currnetly use the web server's log files to account for traffic (which I'm sure is the standard method of throughput accounting for web-sites), you should easily be able to parse usage based on named sites. It shouldn't be significantly more difficult than parsing the logs for IP sites. > >As example if I have 200,000 websites you want me to fit all of this >into a >/32 or even a /24 that is TOTALLY unreasonable. DETAILS please on >how you >are going to justify this? You will always need at least a single IP address for each server, so this is not an issue, and will not be an issue with ARIN. > >Also why not go through the aollocations and start retreiving >numbers back >from Companies and schools that have more than they need? All you >are doing >is slowing down the Internet's growth. Make web hosting companies >get to the >high %90 utils before allow more allocation. > >I would like some input on this as I am sure the rest of the planet >would as >well. > >Matthew S. Bailey > > >-----Original Message----- >From: owner-arin-discuss@arin.net >[mailto:owner-arin-discuss@arin.net]On >Behalf Of Hyunseog Ryu >Sent: Monday, September 11, 2000 12:29 PM >To: hostnamster@arin.net >Cc: arin-discuss@arin.net >Subject: guideline for name-based web hosting justification > > >Dear Sir/Madam > >Good morning! >I read new ARIN's policy regarding to web hosting. >http://www.arin.net/announcements/policy_changes.html >[SNIP] > > From owner-arin-discuss@arin.net Mon Sep 11 19:11:59 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id TAA19566 for arin-discuss-outgoing; Mon, 11 Sep 2000 19:00:07 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA19528 for ; Mon, 11 Sep 2000 19:00:00 -0400 (EDT) Received: from jacobs.Geeks.ORG (jacobs.Geeks.ORG [209.98.1.1]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id SAA15010 for ; Mon, 11 Sep 2000 18:59:50 -0400 (EDT) Received: by jacobs.Geeks.ORG (Postfix, from userid 400) id 9642F3DC2; Mon, 11 Sep 2000 17:59:40 -0500 (CDT) Date: Mon, 11 Sep 2000 17:59:40 -0500 From: Mike Horwath To: Matt Bailey Cc: arin-discuss@arin.net Subject: Re: guideline for name-based web hosting justification Message-ID: <20000911175940.A89979@Geeks.ORG> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: ; from mbailey@journey.net on Mon, Sep 11, 2000 at 01:32:07PM -0400 X-PGP-Fingerprint: D8 24 CC E6 47 5F E4 60 BF B7 6E FA BF C7 6E C5 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR On Mon, Sep 11, 2000 at 01:32:07PM -0400, Matt Bailey wrote: > For those of us that do accounting via IP how do you expect us to us > Name Based Virtuals? Until there is a method for accounting all > traffic to a domain name without using IP I see this as totally > unreasonable. We base all of our security filters and traffic > filters on a customers IP assigned to them. We also have hardware > that can not support name based virtuals and thus has a NIC card for > each site? Explain IN DETAIL the method used to account for these in > our requests. I concur! We bill via bandwidth and we need a way to track usage over a period of time so we can bill for peak usage. -- Mike Horwath IRC: Drechsau drechsau@Geeks.ORG Home: 763-540-6815 1901 Sumter Ave N, Golden Valley, MN 55427 Opinions stated in this message, or any message posted by myself through my Geeks.ORG address, are mine and mine alone, period. From owner-arin-discuss@arin.net Mon Sep 11 19:38:08 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id TAA21354 for arin-discuss-outgoing; Mon, 11 Sep 2000 19:27:32 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA21308 for ; Mon, 11 Sep 2000 19:27:25 -0400 (EDT) Received: from ramirez.hilander.com (ramirez.hilander.com [216.241.32.34]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id TAA29704 for ; Mon, 11 Sep 2000 19:26:58 -0400 (EDT) Received: from gathering.hilander.com ([216.241.32.50] helo=hilander.com) by ramirez.hilander.com with esmtp (Exim 3.16 #6) id 13YcwE-0002H2-00; Mon, 11 Sep 2000 17:24:34 -0600 Message-ID: <39BD69B2.A7615A77@hilander.com> Date: Mon, 11 Sep 2000 17:24:34 -0600 From: "Alec H. Peterson" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Matt Bailey CC: arin-discuss@arin.net Subject: Re: guideline for name-based web hosting justification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Matt Bailey wrote: > > For those of us that do accounting via IP how do you expect us to us Name > Based Virtuals? Until there is a method for accounting all traffic to a > domain name without using IP I see this as totally unreasonable. We base all > of our security filters and traffic filters on a customers IP assigned to > them. We also have hardware that can not support name based virtuals and > thus has a NIC card for each site? Explain IN DETAIL the method used to > account for these in our requests. How about parsing access logs? Alec -- Alec H. Peterson - ahp@hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!" From owner-arin-discuss@arin.net Mon Sep 11 19:59:10 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id TAA23797 for arin-discuss-outgoing; Mon, 11 Sep 2000 19:50:19 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA23793 for ; Mon, 11 Sep 2000 19:50:17 -0400 (EDT) Received: from smtp.journey.com (postfix@smtp-temp.michix.net [207.241.134.28]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id TAA24862 for ; Mon, 11 Sep 2000 19:50:17 -0400 (EDT) Received: from matt (unknown [207.241.139.27]) by smtp.journey.com (Postfix) with SMTP id 3F71C12C847; Mon, 11 Sep 2000 19:50:34 -0400 (EDT) From: "Matt Bailey" To: "Alec H. Peterson" Cc: Subject: RE: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 19:49:59 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <39BD69B2.A7615A77@hilander.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR We parse at the physical IP layer as we track traffic for FTP/SMTP/POP/HTTP etc for each customer.. -----Original Message----- From: Alec H. Peterson [mailto:ahp@hilander.com] Sent: Monday, September 11, 2000 7:25 PM To: Matt Bailey Cc: arin-discuss@arin.net Subject: Re: guideline for name-based web hosting justification Matt Bailey wrote: > > For those of us that do accounting via IP how do you expect us to us Name > Based Virtuals? Until there is a method for accounting all traffic to a > domain name without using IP I see this as totally unreasonable. We base all > of our security filters and traffic filters on a customers IP assigned to > them. We also have hardware that can not support name based virtuals and > thus has a NIC card for each site? Explain IN DETAIL the method used to > account for these in our requests. How about parsing access logs? Alec -- Alec H. Peterson - ahp@hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!" From owner-arin-discuss@arin.net Mon Sep 11 20:08:05 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id TAA24593 for arin-discuss-outgoing; Mon, 11 Sep 2000 19:58:32 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id TAA24588 for ; Mon, 11 Sep 2000 19:58:21 -0400 (EDT) Received: from exchange.innerhost.com (EXCHANGE.CORP.INNERHOST.COM [216.87.0.198] (may be forged)) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id TAA16748 for ; Mon, 11 Sep 2000 19:58:05 -0400 (EDT) Received: by EXCHANGE.CORP.INNERHOST.COM with Internet Mail Service (5.5.1960.3) id ; Mon, 11 Sep 2000 19:56:37 -0400 Message-ID: <117FCA2AC143D4119B4800500411C0FFFD39@EXCHANGE.CORP.INNERHOST.COM> From: Joe Gonzalez To: "'brianj@nvc.net'" , Joe Gonzalez , joe@home.innerhost.com Cc: arin-discuss@arin.net Subject: RE: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 19:56:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Taking the IP accounting information from server log files is inefficient and is impossible with a large amount of high traffic sites. The size of logs generated is incredible and can take days to import. Most large service providers take the IP accounting information from the routers using Netflow accounting. The only way I know of matching Netflow information to a site is by IP address. Sincerely, Joe Gonzalez Chief Technology Officer http://www.innerhost.com -----Original Message----- From: brianj [mailto:brianj@nvc.net] Sent: Monday, September 11, 2000 4:40 PM To: joe@exchange.innerhost.com; joe@home.innerhost.com Cc: arin-discuss@arin.net Subject: RE: guideline for name-based web hosting justification If you currnetly use the web server's log files to account for traffic (which I'm sure is the standard method of throughput accounting for web-sites), you should easily be able to parse usage based on named sites. It shouldn't be significantly more difficult than parsing the logs for IP sites. From owner-arin-discuss@arin.net Mon Sep 11 20:41:09 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id UAA27124 for arin-discuss-outgoing; Mon, 11 Sep 2000 20:29:09 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA27120 for ; Mon, 11 Sep 2000 20:29:08 -0400 (EDT) Received: from shore.intercom.net (shore.intercom.net [204.183.208.11]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id UAA25098 for ; Mon, 11 Sep 2000 20:29:07 -0400 (EDT) Received: from cross (cross.intercom.net [216.240.106.249]) by shore.intercom.net (8.9.1/8.9.1) with SMTP id UAA16723; Mon, 11 Sep 2000 20:28:59 -0400 (EDT) Message-ID: <010a01c01c50$35be4fc0$f96af0d8@cross> From: "Ron Hensley" To: "Mike Horwath" , "Matt Bailey" Cc: References: <20000911175940.A89979@Geeks.ORG> Subject: Re: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 20:27:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Disposition-Notification-To: "Ron Hensley" X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Couldn't this be implemented on the WWW server however? With NT's IIS for example, or Apache under any platform you can of course have 1000 WWW domain sites all sharing one IP Address bound to the NIC Card. While some monitoring software my only look at the ip addresses and thus cant differentiate, the WWW server itself sorts the connections based, not on the IP Address, but rather on the content in the packets. More to the point, on the URL being requested. Based on that, each WWW site generates its own unique log files for that site. Thus software can be written to total the byte counts of the hits to that WWW site. WebTrends comes to mind though it doesn't produce billing data of course. Also any machine sitting on the network, like a firewall, that's gathering statistics on bandwidth by IP Address could just as easily inspect the data payload and generate statistics based on that content of the given WWW site. Yes I realize that would be processor intensive, however firewalls do that now to look for attack signatures and the like. To make it short, it sounds like your asking to use 30,000 ip addresses for 30,000 WWW sites, when you only need one, because your software vendor has written bad billing software that doesn't support virtual WWW hosts sharing the same ip address. Yes it would be nice if every toaster, watch, refrigerator, and virtual domain could have its own ip address, however were running out of ip space to get actual peoples computers online. IPV6 will obviously help, but even then it seems a complete and utter waste to use more then one ip address per WWW server or even WWW Cluster, when its not necessary. End Rant---- -------------------------------------------------------------------------- Ron Hensley (ronh@intercom.net) CCNA #10082337 Network Administrator - ICNet Internet Services -------------------------------------------------------------------------- > I concur! > > We bill via bandwidth and we need a way to track usage over a period > of time so we can bill for peak usage. > > -- > Mike Horwath IRC: Drechsau drechsau@Geeks.ORG > Home: 763-540-6815 1901 Sumter Ave N, Golden Valley, MN 55427 > Opinions stated in this message, or any message posted by myself > through my Geeks.ORG address, are mine and mine alone, period. > From owner-arin-discuss@arin.net Mon Sep 11 21:01:48 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id UAA28815 for arin-discuss-outgoing; Mon, 11 Sep 2000 20:51:13 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id UAA28810 for ; Mon, 11 Sep 2000 20:51:11 -0400 (EDT) Received: from smtp.journey.com (postfix@smtp-temp.michix.net [207.241.134.28]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id UAA12073 for ; Mon, 11 Sep 2000 20:51:11 -0400 (EDT) Received: from matt (unknown [207.241.139.27]) by smtp.journey.com (Postfix) with SMTP id 6B14A12C83D; Mon, 11 Sep 2000 20:51:28 -0400 (EDT) From: "Matt Bailey" To: "Ron Hensley" Cc: Subject: RE: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 20:50:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <010a01c01c50$35be4fc0$f96af0d8@cross> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Your missing the point completely. I can create a Netflow based usuage in 30 seconds to parse one customers 40Gigabytes worth of logs would take days let alone the machine dedicated to processing it.. Your telling me I should save the traffic log for all the sites would could be 100ish gigs per month and parse them? Why? I can use Netflow based accounting on an IP address and cough up an answer in real time anytime I want it. Obviously you don;t have much web hosting.. I would like to hear comments from some of the web hosting big boys (concentric, etc..) on what they view of this.. What gets tricky is when you have one site scattered over several machines because part of it uses a database/Part of it needs SSL etc.. This just can not happen yet. SSL requires and IP.. So I put a customer into the system. Your telling me I have to rip them out and re-add them to my systems because now they need an IP.. That is total BS. Log files are archaic forms of gathering data. Most of us gather data in Real Time rather than parsing logs. My Customers can get a second by second count of how their website is doing. Ohhh yes and that one website owner who is a total asshole to AOL and you get your 30,000 site IIS box blackholed. Is that fair to the 29,999 other customers? Have you ever tried to get out of an AOL blacklist? I have over 40 IP's I can not use for anything other than office machines as they are blackholed and the customers are LONG GONE.. Of course since we issue an FTP site based on their virtual websites IP we get away with using 30,000 IP's since there is no header in FTP... And of course the virtual mail server on the other box which requires an IP Nope no headers yet there either.. Guess what I burn two for every customer, and guess what ARIN can not stop it cause technically I use FTP and MAIL which can not yet run under one IP. IP Based websites are nothing more than a HACK in the protocol. If the WWC was smart for 1.2 or 2.0 whatever they are working on they would pull virtual headers back out since 60% or so of the people still send http/1.0 requests. I could not tell 30,000 web clients that if someone wants to visit their site they have to upgrade from netscape 2.0 (yes we still have customers using win 3.1 and netscape 2.0 with the netscape dialer.. I cringe but they are the customer they are always right..) I think ARIN needs to rethink what they are suggesting those of us that can not change the way we host websites will work the loopholes. Which I don't agree with. ARIN should have asked the community what we can do to help limit the waste. Rather than forcing it upon us. I would guess if they Asked MIT or GE or some of the other companies out there to give back unused space that they would.. I try very hard to convince my dedicated customers to use NAT and overload IP's as much as they can. If they have an absolute need then we assign them space. This is only fair. OK lets check this out.. We have 200 dedicated dial-ups we can use 200 IP's for this. We have 200 dedicated web sites we can only use 1? Why does that work.. OK Now lets say ARIN says they will not assign you more than 1 IP per piece of modem gear because you can use NAT.. Don't bitch if you support this on Virtual Webhosting as these are the equiv. infact more will work via NAT than with Virtual web.. Someone at ARIN please please tell me why that wasn't added to the policy? This would free up 75% of the IP's on the internet if you require NAT... OK I am getting a headache.. Some people just don;t understand why this is a bad idea. From owner-arin-discuss@arin.net Mon Sep 11 21:12:06 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id VAA29404 for arin-discuss-outgoing; Mon, 11 Sep 2000 21:01:16 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id VAA29400 for ; Mon, 11 Sep 2000 21:01:14 -0400 (EDT) Received: from flood.goldengate.net (flood.goldengate.net [209.240.87.82]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id VAA19584 for ; Mon, 11 Sep 2000 21:01:14 -0400 (EDT) Received: from dew.goldengate.net (mury@dew.goldengate.net [209.240.87.78]) by flood.goldengate.net (8.9.3/8.9.3) with ESMTP id TAA05602; Mon, 11 Sep 2000 19:54:00 -0500 (CDT) Date: Mon, 11 Sep 2000 20:01:10 -0500 (CDT) From: Mury To: "Alec H. Peterson" cc: Matt Bailey , arin-discuss@arin.net Subject: Re: guideline for name-based web hosting justification In-Reply-To: <39BD69B2.A7615A77@hilander.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Yikes! Have you ever tried to parse up to 1000 log files per system, with some of them around 500MB in size. It's not nearly as easy as it sounds. For some people it's feasable, but for most of us we *need* IP based accounting. By the way, we are setup to do a large number of URL's pointed at a single IP for some hosting applications, but for the majority of our sites, it is not an option. Mury GoldenGate Internet Services On Mon, 11 Sep 2000, Alec H. Peterson wrote: > > How about parsing access logs? > > Alec > > -- > Alec H. Peterson - ahp@hilander.com > Staff Scientist > CenterGate Research Group - http://www.centergate.com > "Technology so advanced, even _we_ don't understand it!" > From owner-arin-discuss@arin.net Mon Sep 11 21:52:40 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id VAA02517 for arin-discuss-outgoing; Mon, 11 Sep 2000 21:41:34 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id VAA02509 for ; Mon, 11 Sep 2000 21:41:33 -0400 (EDT) Received: from iohost.com (io001.iohost.com [209.189.124.99] (may be forged)) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id VAA20610 for ; Mon, 11 Sep 2000 21:41:32 -0400 (EDT) Received: from ntserver.virtualis.com (adsl-63-205-138-10.dsl.lsan03.pacbell.net [63.205.138.10]) by iohost.com (8.11.0/8.11.0) with ESMTP id e8C1fDe06403; Mon, 11 Sep 2000 18:41:13 -0700 Message-Id: <4.3.2.7.0.20000911183535.00b71f08@mail.ccsales.com> X-Sender: rkatzvs@mail.ccsales.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Sep 2000 18:38:43 -0700 To: "Matt Bailey" , "Ron Hensley" From: Randy Katz Subject: RE: guideline for name-based web hosting justification Cc: In-Reply-To: References: <010a01c01c50$35be4fc0$f96af0d8@cross> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR I am a major shareholder in a $7MM/year plus web hosting company, which I consider small, every word Matt says makes 100% sense. It seems there is this "wave" of biased opinions about web hosting stemming from the ISP vs. web host days and easy and relatively low cost to entry for the average web hosting business, but this is simply not an intellectual approach towards the problem and shows that while they might understand by now what an ISP does and the importance of it they are openly taking jabs at web hosting which show complete iqnorance in that area. Please answer the points. Thank you, Randy Katz At 08:50 PM 9/11/2000 -0400, Matt Bailey wrote: >Your missing the point completely. >I can create a Netflow based usuage in 30 seconds to parse one customers >40Gigabytes worth of logs would take days let alone the machine dedicated to >processing it.. Your telling me I should save the traffic log for all the >sites would could be 100ish gigs per month and parse them? Why? I can use >Netflow based accounting on an IP address and cough up an answer in real >time anytime I want it. > >Obviously you don;t have much web hosting.. I would like to hear comments >from some of the web hosting big boys (concentric, etc..) on what they view >of this.. What gets tricky is when you have one site scattered over several >machines because part of it uses a database/Part of it needs SSL etc.. This >just can not happen yet. > >SSL requires and IP.. So I put a customer into the system. Your telling me I >have to rip them out and re-add them to my systems because now they need an >IP.. That is total BS. > >Log files are archaic forms of gathering data. Most of us gather data in >Real Time rather than parsing logs. My Customers can get a second by second >count of how their website is doing. > >Ohhh yes and that one website owner who is a total asshole to AOL and you >get your 30,000 site IIS box blackholed. Is that fair to the 29,999 other >customers? Have you ever tried to get out of an AOL blacklist? I have over >40 IP's I can not use for anything other than office machines as they are >blackholed and the customers are LONG GONE.. > >Of course since we issue an FTP site based on their virtual websites IP we >get away with using 30,000 IP's since there is no header in FTP... >And of course the virtual mail server on the other box which requires an IP >Nope no headers yet there either.. Guess what I burn two for every customer, >and guess what ARIN can not stop it cause technically I use FTP and MAIL >which can not yet run under one IP. IP Based websites are nothing more than >a HACK in the protocol. If the WWC was smart for 1.2 or 2.0 whatever they >are working on they would pull virtual headers back out since 60% or so of >the people still send http/1.0 requests. I could not tell 30,000 web clients >that if someone wants to visit their site they have to upgrade from netscape >2.0 (yes we still have customers using win 3.1 and netscape 2.0 with the >netscape dialer.. I cringe but they are the customer they are always >right..) > >I think ARIN needs to rethink what they are suggesting those of us that can >not change the way we host websites will work the loopholes. Which I don't >agree with. ARIN should have asked the community what we can do to help >limit the waste. Rather than forcing it upon us. I would guess if they Asked >MIT or GE or some of the other companies out there to give back unused space >that they would.. I try very hard to convince my dedicated customers to use >NAT and overload IP's as much as they can. If they have an absolute need >then we assign them space. This is only fair. > >OK lets check this out.. We have 200 dedicated dial-ups we can use 200 IP's >for this. We have 200 dedicated web sites we can only use 1? >Why does that work.. OK Now lets say ARIN says they will not assign you more >than 1 IP per piece of modem gear because you can use NAT.. Don't bitch if >you support this on Virtual Webhosting as these are the equiv. infact more >will work via NAT than with Virtual web.. Someone at ARIN please please tell >me why that wasn't added to the policy? This would free up 75% of the IP's >on the internet if you require NAT... > >OK I am getting a headache.. Some people just don;t understand why this is a >bad idea. From owner-arin-discuss@arin.net Mon Sep 11 22:44:01 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id WAA08599 for arin-discuss-outgoing; Mon, 11 Sep 2000 22:31:47 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA08424; Mon, 11 Sep 2000 22:29:40 -0400 (EDT) Received: from ramirez.hilander.com (ramirez.hilander.com [216.241.32.34]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id WAA12088; Mon, 11 Sep 2000 22:29:30 -0400 (EDT) Received: from gathering.hilander.com ([216.241.32.50] helo=hilander.com) by ramirez.hilander.com with esmtp (Exim 3.16 #6) id 13Yfou-0002pN-00; Mon, 11 Sep 2000 20:29:12 -0600 Message-ID: <39BD94F7.DD143DBE@hilander.com> Date: Mon, 11 Sep 2000 20:29:11 -0600 From: "Alec H. Peterson" X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Mury CC: Matt Bailey , arin-discuss@arin.net, ppml@arin.net Subject: Re: guideline for name-based web hosting justification References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Mury wrote: > > Yikes! > > Have you ever tried to parse up to 1000 log files per system, with some of > them around 500MB in size. It's not nearly as easy as it sounds. It is if you change how you write and parse your logs. > > For some people it's feasable, but for most of us we *need* IP based > accounting. > > By the way, we are setup to do a large number of URL's pointed at a single > IP for some hosting applications, but for the majority of our sites, it is > not an option. Can't say that I have tried it. However at the same time I can think of quite a few ways to make the task far easier and faster. For example, don't do all of the parsing at once at the end of the day; modify the server to keep a running tally of a customer's usage and have it write that alone to a file on the disk every time it changes. Far more efficient. That's just off the top of my head, and probably not a really efficient way to do it. My point is that the Internet is made up of a lot of smart people who are more than capable of solving these issues if they feel like it. Whining about how today's methods of accounting won't work with tomorrow's methods of virtual hosting is a lot like complaining about how yesterday's chalk writes really poorly on today's white boards. If you don't want to be left behind you have to keep on evolving. After all, where would we be today if dial-up providers decided that it was too much work to use dynamically allocated IP addresses and kept on giving each user their own IP address? However, name-based virtual hosts aren't exactly a new thing. Many large web hosters have been using name-based virtual hosts for a while now, so would any of those companies mind sharing a little wisdom on how this can be done? Thanks, Alec -- Alec H. Peterson - ahp@hilander.com Staff Scientist CenterGate Research Group - http://www.centergate.com "Technology so advanced, even _we_ don't understand it!" From owner-arin-discuss@arin.net Mon Sep 11 22:49:56 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id WAA09160 for arin-discuss-outgoing; Mon, 11 Sep 2000 22:38:48 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id WAA09156 for ; Mon, 11 Sep 2000 22:38:46 -0400 (EDT) Received: from shore.intercom.net (shore.intercom.net [204.183.208.11]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id WAA04971 for ; Mon, 11 Sep 2000 22:38:46 -0400 (EDT) Received: from cross (cross.intercom.net [216.240.106.249]) by shore.intercom.net (8.9.1/8.9.1) with SMTP id WAA15323; Mon, 11 Sep 2000 22:38:33 -0400 (EDT) Message-ID: <011f01c01c62$4e72e820$f96af0d8@cross> From: "Ron Hensley" To: "Mury" , "Alec H. Peterson" Cc: "Matt Bailey" , References: Subject: Re: guideline for name-based web hosting justification Date: Mon, 11 Sep 2000 22:36:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Disposition-Notification-To: "Ron Hensley" X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR I agree log files of those sorts of magnitudes would be too much to deal with and wasn't suggesting that's the end all solution. However the internet is running out of ips,. and without the guidelines ARIN has, even the ipv6 would get blown out in a decade. Netflow was mentioned alot. Its a dedicated device with all traffic passing through it, doing accounting, however only on ip address. So if Cisco or some other vendor simply adds the functionality to produce its logs based not only on the ip address, but also on the TCP Packets where an URL request for instance is seen, then those needing the virtuals accounted are taken care of, and 30,000 ips for this one example ISP/WWW Hosting Site are cleared up. Noones arguing that you need a solution. I am just arguing that there are other solutions possible beyond having to tag every accessed resource with an individual ip address. ----- Original Message ----- From: "Mury" To: "Alec H. Peterson" Cc: "Matt Bailey" ; Sent: Monday, September 11, 2000 9:01 PM Subject: Re: guideline for name-based web hosting justification > > Yikes! > > Have you ever tried to parse up to 1000 log files per system, with some of > them around 500MB in size. It's not nearly as easy as it sounds. > > For some people it's feasable, but for most of us we *need* IP based > accounting. > > By the way, we are setup to do a large number of URL's pointed at a single > IP for some hosting applications, but for the majority of our sites, it is > not an option. > > Mury > GoldenGate Internet Services > > On Mon, 11 Sep 2000, Alec H. Peterson wrote: > > > > > How about parsing access logs? > > > > Alec > > > > -- > > Alec H. Peterson - ahp@hilander.com > > Staff Scientist > > CenterGate Research Group - http://www.centergate.com > > "Technology so advanced, even _we_ don't understand it!" > > > > From owner-arin-discuss@arin.net Tue Sep 12 03:04:11 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id CAA15104 for arin-discuss-outgoing; Tue, 12 Sep 2000 02:52:42 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id CAA15099; Tue, 12 Sep 2000 02:52:41 -0400 (EDT) Received: from flood.goldengate.net (flood.goldengate.net [209.240.87.82]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id CAA12450; Tue, 12 Sep 2000 02:52:40 -0400 (EDT) Received: from dew.goldengate.net (mury@dew.goldengate.net [209.240.87.78]) by flood.goldengate.net (8.9.3/8.9.3) with ESMTP id BAA31907; Tue, 12 Sep 2000 01:45:25 -0500 (CDT) Date: Tue, 12 Sep 2000 01:52:36 -0500 (CDT) From: Mury To: "Alec H. Peterson" cc: Matt Bailey , arin-discuss@arin.net, ppml@arin.net Subject: Re: guideline for name-based web hosting justification In-Reply-To: <39BD94F7.DD143DBE@hilander.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR Dear Alec, Since you basically called those of us pointing out some real issues "whiners," I took the liberty of finding out a little bit more about you. It looks like you are probably a fairly bright person, probably a lot smarter than me. From looking at your web site though and reading your comments below I question how much you really understand what you are talking about when you trivialize some of the issues that have been brought up. I also find it interesting that in your presentation to the 11th NANOG meeting that you did with Avi Freedman (Isn't he working for Digital Island now? Or one of the other distributed content providers) you are supporting a technology that not only assigns an IP address to a web site but assigns multiple IP addresses to a single site. Perhaps I didn't decipher your presentation correctly, but it sure seems like you are supporting performance/service level issues above and beyond IP conservation. Ah, I hear it coming, that each distributed node can handle multiple distributed sites off of a single IP. Very true. Do you know what the ratio of managed sites to in-service systems is? How many locations is Akamai in? I really don't know what the IP "waste" ratio is. But the point is you are supporting performance at the expense of IP addresses however large or small that may be. In addition, you even argue against yourself. You say, "For example, don't do all of the parsing at once at the end of the day; modify the server to keep a running tally of a customer's usage and have it write that alone to a file on the disk every time it changes. Far more efficient. That's just off the top of my head, and probably not a really efficient way to do it." What?! How can it be *far more efficient* and then in the next line it's *not a really efficient*" Can you see why I'm not very thrilled with your off the cuff and seemingly inexperienced comments? By making light of some real issues that were brought up it sure seems like your statements are hypocritical. Now like I said, I'm not the smartest guy out here, so if I've badly misrepresented things I apologize in advance. Bottom line, for every one out there saying it's no big deal to do single IP virtual hosting I would like to see a solution that does not sacrifice reliability, accountability, quality of service, and functionality. I hate it when people (even smart people) start voicing opinions on things they don't understand. I'm also not stubborn. I'm not running things the way I do because it's my way, but because they work, they are scalable, they are functionable, and we have zero down time. I've tried Microsoft IIS. It doesn't work. Well doh, of course it works, but not for a company that demands uptime and security and a fast and simple database. I have to reboot co-located IIS machines all the time. My BSDI/Apache/MySQL/Perl/PHP/Raven boxes have had zero downtime in the last 3 years. That is not an invitation to hack or DOS my network. But thanks for thinking about me. And like I said before, when appropriate we have assigned multiple sites to a single IP. We actually do it by sending all requests into a CGI script that grabs the HTTP_HOST env variable and creates the customized web site on the fly with MySQL. So yes, we are trying to conserve IP addresses, we are not greedy, whiny bastards trying to screw the Internet up for everyone else. For those of you running Apache that want to know how to do it the right way, go to: http://www.apache.org/docs/vhosts/name-based.html Cool! Now we all know how to do name based hosting... er, wait... what about all those HTTP/1.0 browsers!? You don't think they exist any more? Check this out. In fairness I sampled all my virtual hosts off of one server from a selective time period. All my logs files are in the www.domain.com format. Here are my commands and results: webserver3: {17} % grep 'HTTP/1.1' www.*.com | wc -l 400441 webserver3: {18} % grep 'HTTP/1.0' www.*.com | wc -l 375412 48.4% of the browsers out there that accessed my customers' sites used HTTP/1.0. For the uninitiated the 1.0 version of the HTTP protocol does NOT support name based hosting. Can I tell all my customers to call you when their online business drops by almost 50%. By the way, can you use a shared IP for secure server certificates? Some more thoughts... Look at some of the new comers to the tech scene, Keynote, Akamai, Speedera, Digital Island, etc. These company's success show how important it is to the world to have fast, reliable, and secure web sites. Quality of Service (in its broad definition) is paramount. And if you don't believe that you can make a fortune by shorting the stock in those companies. I don't want to see any more comments that I should be doing things smarter and better. I want to see explanations of how I can accomplish the things that you say are so easy. Like I said I'm not stubborn... show me the way. If you can't, then please refrain from making popular political statements that don't affect YOUR business and your customers' business. There's my not so bright, whiny, long-winded $10 worth. Mury GoldenGate Internet Services PS. If you are such an advocate for IP conservation why do you have a whole block? I can't tell how many IPs you are wasting because your provider has not swipped your block. But you have multiple web sites running on multiple IPs! What's your excuse? Name: gw1.hilander.com Address: 216.241.32.33 Name: virthost.hilander.com Address: 216.241.32.35 Name: ramirez.hilander.com Address: 216.241.32.34 Pretty interesting web sites I might add. If you are going to call someone a whiner you better have your own act together. The hypocrisy is killing me. Like I said, I'm sure you are smarter than me, but stick to what you know. On Mon, 11 Sep 2000, Alec H. Peterson wrote: > Mury wrote: > > > > Yikes! > > > > Have you ever tried to parse up to 1000 log files per system, with some of > > them around 500MB in size. It's not nearly as easy as it sounds. > > It is if you change how you write and parse your logs. > > > > > For some people it's feasable, but for most of us we *need* IP based > > accounting. > > > > By the way, we are setup to do a large number of URL's pointed at a single > > IP for some hosting applications, but for the majority of our sites, it is > > not an option. > > Can't say that I have tried it. However at the same time I can think of > quite a few ways to make the task far easier and faster. For example, don't > do all of the parsing at once at the end of the day; modify the server to > keep a running tally of a customer's usage and have it write that alone to a > file on the disk every time it changes. Far more efficient. > > That's just off the top of my head, and probably not a really efficient way > to do it. My point is that the Internet is made up of a lot of smart people > who are more than capable of solving these issues if they feel like it. > Whining about how today's methods of accounting won't work with tomorrow's > methods of virtual hosting is a lot like complaining about how yesterday's > chalk writes really poorly on today's white boards. If you don't want to be > left behind you have to keep on evolving. > > After all, where would we be today if dial-up providers decided that it was > too much work to use dynamically allocated IP addresses and kept on giving > each user their own IP address? > > However, name-based virtual hosts aren't exactly a new thing. Many large > web hosters have been using name-based virtual hosts for a while now, so > would any of those companies mind sharing a little wisdom on how this can be > done? > > Thanks, > > Alec > > -- > Alec H. Peterson - ahp@hilander.com > Staff Scientist > CenterGate Research Group - http://www.centergate.com > "Technology so advanced, even _we_ don't understand it!" > From owner-arin-discuss@arin.net Tue Sep 12 04:46:04 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id EAA24328 for arin-discuss-outgoing; Tue, 12 Sep 2000 04:35:50 -0400 (EDT) Received: from rs2.arin.net (rs2.arin.net [192.149.252.22]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id EAA24323; Tue, 12 Sep 2000 04:35:26 -0400 (EDT) Received: from freeside.fc.net (freeside.fc.net [207.170.70.2]) by rs2.arin.net (8.9.3/8.9.3) with ESMTP id EAA12365; Tue, 12 Sep 2000 04:35:21 -0400 (EDT) Received: from freeside.fc.net (localhost [127.0.0.1]) by freeside.fc.net (8.9.3/8.8.8) with ESMTP id DAA64586; Tue, 12 Sep 2000 03:34:57 -0500 (CDT) Message-Id: <200009120834.DAA64586@freeside.fc.net> To: Mury cc: "Alec H. Peterson" , Matt Bailey , arin-discuss@arin.net, ppml@arin.net Subject: Re: guideline for name-based web hosting justification In-reply-to: Your message of "Tue, 12 Sep 2000 01:52:36 CDT." Date: Tue, 12 Sep 2000 03:34:57 -0500 From: Jeremy Porter Sender: owner-arin-discuss@arin.net Precedence: bulk X-Status: Status: OR I don't think Alec has called anyone whiners. The policy has been discussed and as presented does not change the business climate for for existing users of addresses. For new assignments I quote: http://www.arin.net/announcements/policy_changes.html Exceptions may be made for ISPs that provide justification for requiring static addresses. ARIN will determine, on a case-by-case basis, whether an exception is appropriate. If you are sure that your use of one IP per Host is justfiable, then you should have no problem getting an exception approved. Perhaps if you are complaining maybe you don't feel that your use has technical merit? "Back in the day" when I ran an ISP and Web hosting business for a living, we used single IPs for WWW (http 1.1 didn't exist), assigned static IPs to all customers, etc. When new technologies came about and policies changed, we followed. We ended up renumber those static customers and some significiant business cost, because it was the right thing to do. It wasn't easy, the customers didn't like it, it made accounting and access control harder. With that said, theses issues were discussed at the ARIN policy meeting, and there weren't huge objections, so the conclusion was reached that there were significant objectors. Luckily there is a meeting in just a few weeks, where you are invited to discusse it more, and perhaps better wording can be determined that would allow existing operations to switch to more efficient technologies in a reasonable time frame, while still encouraging better utilization of IP addressing. I'm sure if several vocal www hosting business pushed for changed wording that still encouraged better utilization, that it would be considered. >From my recollection of the last ARIN meeting there was a significant lack of input from WWW hosting companies, as there were only a handful present. "Whining" (your words) about it on the mailing list might not be enough. Also I'd think you find Alec would be more than willing to help address any technical issues you might find, but telling him "math is hard" isn't likely to win you much, and personal attacks, will likely just be ignored, as he's been doing this long enough to not take the "bait". In message , Mury writes: > >Dear Alec, > >Since you basically called those of us pointing out some real issues >"whiners," I took the liberty of finding out a little bit more about >you. It looks like you are probably a fairly bright person, probably a >lot smarter than me. From looking at your web site though and reading >your comments below I question how much you really understand what you are >talking about when you trivialize some of the issues that have been >brought up. > >I also find it interesting that in your presentation to the 11th NANOG >meeting that you did with Avi Freedman (Isn't he working for Digital >Island now? Or one of the other distributed content providers) you are >supporting a technology that not only assigns an IP address to a web site >but assigns multiple IP addresses to a single site. Perhaps I didn't >decipher your presentation correctly, but it sure seems like you are >supporting performance/service level issues above and beyond IP >conservation. Ah, I hear it coming, that each distributed node can handle >multiple distributed sites off of a single IP. Very true. Do you know >what the ratio of managed sites to in-service systems is? How many >locations is Akamai in? I really don't know what the IP "waste" ratio is. >But the point is you are supporting performance at the expense of IP >addresses however large or small that may be. > >In addition, you even argue against yourself. You say, "For example, >don't do all of the parsing at once at the end of the day; modify the >server to keep a running tally of a customer's usage and have it write >that alone to a file on the disk every time it changes. Far more >efficient. That's just off the top of my head, and probably not a really >efficient way to do it." > >What?! How can it be *far more efficient* and then in the next line it's >*not a really efficient*" Can you see why I'm not very thrilled with your >off the cuff and seemingly inexperienced comments? > >By making light of some real issues that were brought up it sure seems >like your statements are hypocritical. Now like I said, I'm not the >smartest guy out here, so if I've badly misrepresented things I apologize >in advance. > >Bottom line, for every one out there saying it's no big deal to do single >IP virtual hosting I would like to see a solution that does not sacrifice >reliability, accountability, quality of service, and functionality. I >hate it when people (even smart people) start voicing opinions on things >they don't understand. > >I'm also not stubborn. I'm not running things the way I do because it's >my way, but because they work, they are scalable, they are functionable, >and we have zero down time. I've tried Microsoft IIS. It doesn't work. >Well doh, of course it works, but not for a company that demands uptime >and security and a fast and simple database. I have to reboot co-located >IIS machines all the time. My BSDI/Apache/MySQL/Perl/PHP/Raven boxes have >had zero downtime in the last 3 years. That is not an invitation to hack >or DOS my network. But thanks for thinking about me. > >And like I said before, when appropriate we have assigned multiple sites >to a single IP. We actually do it by sending all requests into a CGI >script that grabs the HTTP_HOST env variable and creates the customized >web site on the fly with MySQL. So yes, we are trying to conserve IP >addresses, we are not greedy, whiny bastards trying to screw the Internet >up for everyone else. > >For those of you running Apache that want to know how to do it the right >way, go to: http://www.apache.org/docs/vhosts/name-based.html > >Cool! Now we all know how to do name based hosting... er, wait... what >about all those HTTP/1.0 browsers!? You don't think they exist any >more? Check this out. In fairness I sampled all my virtual hosts off of >one server from a selective time period. All my logs files are in the >www.domain.com format. Here are my commands and results: > >webserver3: {17} % grep 'HTTP/1.1' www.*.com | wc -l > 400441 >webserver3: {18} % grep 'HTTP/1.0' www.*.com | wc -l > 375412 > >48.4% of the browsers out there that accessed my customers' sites used >HTTP/1.0. For the uninitiated the 1.0 version of the HTTP protocol does >NOT support name based hosting. > >Can I tell all my customers to call you when their online business drops >by almost 50%. By the way, can you use a shared IP for secure server >certificates? > >Some more thoughts... > >Look at some of the new comers to the tech scene, Keynote, Akamai, >Speedera, Digital Island, etc. These company's success show how important >it is to the world to have fast, reliable, and secure web sites. Quality >of Service (in its broad definition) is paramount. And if you don't >believe that you can make a fortune by shorting the stock in those >companies. > >I don't want to see any more comments that I should be doing things >smarter and better. I want to see explanations of how I can accomplish >the things that you say are so easy. Like I said I'm not stubborn... show >me the way. If you can't, then please refrain from making popular >political statements that don't affect YOUR business and your customers' >business. > >There's my not so bright, whiny, long-winded $10 worth. > >Mury >GoldenGate Internet Services > >PS. If you are such an advocate for IP conservation why do you have a >whole block? I can't tell how many IPs you are wasting because your >provider has not swipped your block. But you have multiple web sites >running on multiple IPs! What's your excuse? > >Name: gw1.hilander.com >Address: 216.241.32.33 > >Name: virthost.hilander.com >Address: 216.241.32.35 > >Name: ramirez.hilander.com >Address: 216.241.32.34 > >Pretty interesting web sites I might add. > >If you are going to call someone a whiner you better have your own act >together. The hypocrisy is killing me. > >Like I said, I'm sure you are smarter than me, but stick to what you know. > > >On Mon, 11 Sep 2000, Alec H. Peterson wrote: > >> Mury wrote: >> > >> > Yikes! >> > >> > Have you ever tried to parse up to 1000 log files per system, with some of >> > them around 500MB in size. It's not nearly as easy as it sounds. >> >> It is if you change how you write and parse your logs. >> >> > >> > For some people it's feasable, but for most of us we *need* IP based >> > accounting. >> > >> > By the way, we are setup to do a large number of URL's pointed at a single >> > IP for some hosting applications, but for the majority of our sites, it is >> > not an option. >> >> Can't say that I have tried it. However at the same time I can think of >> quite a few ways to make the task far easier and faster. For example, don't >> do all of the parsing at once at the end of the day; modify the server to > keep a running tally of a customer's usage and have it write that alone to a >> file on the disk every time it changes. Far more efficient. >> >> That's just off the top of my head, and probably not a really efficient way >> to do it. My point is that the Internet is made up of a lot of smart people >> who are more than capable of solving these issues if they feel like it. >> Whining about how today's methods of accounting won't work with tomorrow's >> methods of virtual hosting is a lot like complaining about how yesterday's >> chalk writes really poorly on today's white boards. If you don't want to be >> left behind you have to keep on evolving. >> >> After all, where would we be today if dial-up providers decided that it was >> too much work to use dynamically allocated IP addresses and kept on giving >> each user their own IP address? >> >> However, name-based virtual hosts aren't exactly a new thing. Many large >> web hosters have been using name-based virtual hosts for a while now, so >> would any of those companies mind sharing a little wisdom on how this can be >> done? >> >> Thanks, >> >> Alec >> >> -- >> Alec H. Peterson - ahp@hilander.com >> Staff Scientist >> CenterGate Research Group - http://www.centergate.com >> "Technology so advanced, even _we_ don't understand it!" >> > > --- jerry@fc.net 512-519-6193 www.wayport.net 8303 Mopac Expressway Suite A300, Austin Tx. From owner-arin-discuss@arin.net Tue Sep 12 09:30:53 2000 Return-Path: Received: (from majordom@localhost) by ops.arin.net (8.9.0/8.9.0) id JAA12374 for arin-discuss-outgoing; Tue, 12 Sep 2000 09:20:11 -0400 (EDT) Received: from rs1.arin.net (rs1.arin.net [192.149.252.21]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id JAA12364 for ; Tue, 12 Sep 2000 09:20:10 -0400 (EDT) Received: from jacobs.Geeks.ORG (jacobs.Geeks.ORG [209.98.1.1]) by rs1.arin.net (8.9.3/8.9.3) with ESMTP id JAA20253 for ; Tue, 12 Sep 2000 09:20:09 -0400 (EDT) Received: by jacobs.Geeks.ORG (Postfix, from userid 400) id 8EBA23DC2; Tue, 12 Sep 2000 08:20:08 -0500 (CDT) Date: Tue, 12 Sep 2000 08:20:08 -0500 From: Mike Horwath