Re: TCP receive window set to 0; DoS or not?
Richard A Steenbergen [EMAIL PROTECTED] writes: Advertising a window of 0 is a perfectly valid way of telling the other side that you are temporarily out of resoruces, and would like them to stop sending you data Except that that's not what's going on here. This message appears when the TCP peer shrinks the window, withdrawing a previously granted permission to send bytes -- a protocol violation. For example, you're free to tell me (with your window advertisement) that you're authorizing me to send you 32K bytes, and then, after I've sent you 32K bytes, to close the window until you're ready to accept more. You're not free to tell me it's OK to send 32K bytes, then change your mind and advertise a window size of 0 after I've sent you only 16K bytes. To address the DoS question, I don't see how this protocol violation enables a DoS attack. More likely, it's simply somebody's buggy TCP stack misbehaving. That somebody is unlikely to be Windows, MacOS, FreeBSD, or Linux. My money is on some flavor of $50 NAT/home router box. Jim Shankland
Re: TCP receive window set to 0; DoS or not?
On Thu, Sep 07, 2006 at 11:28:47PM -0700, Jim Shankland wrote: Richard A Steenbergen [EMAIL PROTECTED] writes: Advertising a window of 0 is a perfectly valid way of telling the other side that you are temporarily out of resoruces, and would like them to stop sending you data Except that that's not what's going on here. This message appears when the TCP peer shrinks the window, withdrawing a previously granted permission to send bytes -- a protocol violation. For example, you're free to tell me (with your window advertisement) that you're authorizing me to send you 32K bytes, and then, after I've sent you 32K bytes, to close the window until you're ready to accept more. You're not free to tell me it's OK to send 32K bytes, then change your mind and advertise a window size of 0 after I've sent you only 16K bytes. Ok, looking at the error condition in further detail I do believe that you're righ. So, per RFC1122: 4.2.2.16 Managing the Window: RFC-793 Section 3.7, page 41 A TCP receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left. However, a sending TCP MUST be robust against window shrinking, which may cause the useable window (see Section 4.2.3.4) to become negative. It is a warning message generated by a SHOULD NOT violation, during the MUST be robust against this behavior section of code. Looking at other such messages in the Linux kernel which are wrapped in #ifdef TCP_DEBUG, they all appear to be equally esoteric and probably not worth mentioning to the end user. However it looks like TCP_DEBUG is enabled by default (don't ask me why), which when combined with a relatively inane message using alarm provoking words, serves only to confuse. :) To address the DoS question, I don't see how this protocol violation enables a DoS attack. More likely, it's simply somebody's buggy TCP stack misbehaving. That somebody is unlikely to be Windows, MacOS, FreeBSD, or Linux. My money is on some flavor of $50 NAT/home router box. Did a little poking into this condition on other platforms as well, and as previously mentioned it does appear to be fairly contained to mobile devices (not sure which ones though). I guess if you have a small portable device with limited memory, this may be an issue. -- Richard A Steenbergen [EMAIL PROTECTED] http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
FreeBSD Security Advisory FreeBSD-SA-06:20.bind (fwd)
-- Forwarded message -- Date: Wed, 6 Sep 2006 21:59:43 GMT From: FreeBSD Security Advisories [EMAIL PROTECTED] Reply-To: freebsd-security@freebsd.org To: Bugtraq bugtraq@securityfocus.com Subject: FreeBSD Security Advisory FreeBSD-SA-06:20.bind -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 = FreeBSD-SA-06:20.bind Security Advisory The FreeBSD Project Topic: Denial of Service in named(8) Category: contrib Module: bind Announced: 2006-09-06 Credits:The Measurement Factory Affects:FreeBSD 5.3 and later. Corrected: 2006-09-06 21:18:26 UTC (RELENG_6, 6.1-STABLE) 2006-09-06 21:19:21 UTC (RELENG_6_1, 6.1-RELEASE-p6) 2006-09-06 21:20:08 UTC (RELENG_6_0, 6.0-RELEASE-p11) 2006-09-06 21:20:54 UTC (RELENG_5, 5.5-STABLE) 2006-09-06 21:21:50 UTC (RELENG_5_5, 5.5-RELEASE-p4) 2006-09-06 21:22:39 UTC (RELENG_5_4, 5.4-RELEASE-p18) 2006-09-06 21:23:16 UTC (RELENG_5_3, 5.3-RELEASE-p33) CVE Name: CVE-2006-4095, CVE-2006-4096 For general information regarding FreeBSD Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit URL:http://security.freebsd.org/. I. Background BIND 9 is an implementation of the Domain Name System (DNS) protocols. The named(8) daemon is an Internet domain name server. DNS Security Extensions (DNSSEC) are additional protocol options that add authentication and integrity to the DNS protocols. II. Problem Description For a recursive DNS server, a remote attacker sending enough recursive queries for the replies to arrive after all the interested clients have left the recursion queue will trigger an INSIST failure in the named(8) daemon. Also for a a recursive DNS server, an assertion failure can occour when processing a query whose reply will contain more than one SIG(covered) RRset. For an authoritative DNS server serving a RFC 2535 DNSSEC zone which is queried for the SIG records where there are multiple SIG(covered) RRsets (e.g. a zone apex), named(8) will trigger an assertion failure when it tries to construct the response. III. Impact An attacker who can perform recursive lookups on a DNS server and is able to send a sufficiently large number of recursive queries, or is able to get the DNS server to return more than one SIG(covered) RRsets can stop the functionality of the DNS service. An attacker querying an authoritative DNS server serving a RFC 2535 DNSSEC zone may be able to crash the DNS server. All of the above issues will result in a Denial of Service situation. IV. Workaround A possible workaround is to only allow trusted clients to perform recursive queries. V. Solution Perform one of the following: 1) Upgrade your vulnerable system to 5-STABLE, or 6-STABLE, or to the RELENG_6_1, RELENG_6_0, RELENG_5_5, RELENG_5_4, or RELENG_5_3 security branch dated after the correction date. 2) To patch your present system: The following patches have been verified to apply to FreeBSD 5.3, 5.4, 5.5, 6.0, and 6.1 systems. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch http://security.FreeBSD.org/patches/SA-06:20/bind.patch # fetch http://security.FreeBSD.org/patches/SA-06:20/bind.patch.asc b) Execute the following commands as root: # cd /usr/src # patch /path/to/patch # cd /usr/src/lib/bind # make obj make depend make make install # cd /usr/src/usr.sbin/named # make obj make depend make make install c) Restart the named application: # /etc/rc.d/named restart VI. Correction details The following list contains the revision numbers of each file that was corrected in FreeBSD. Branch Revision Path - - RELENG_5 src/contrib/bind9/bin/named/query.c 1.1.1.1.2.3 src/contrib/bind9/lib/dns/resolver.c1.1.1.1.2.5 RELENG_5_5 src/UPDATING 1.342.2.35.2.4 src/sys/conf/newvers.sh 1.62.2.21.2.6 src/contrib/bind9/bin/named/query.c 1.1.1.1.2.2.2.1 src/contrib/bind9/lib/dns/resolver.c1.1.1.1.2.4.2.1 RELENG_5_4 src/UPDATING1.342.2.24.2.27 src/sys/conf/newvers.sh 1.62.2.18.2.23 src/contrib/bind9/bin/named/query.c 1.1.1.1.2.1.4.1 src/contrib/bind9/lib/dns/resolver.c1.1.1.1.2.2.2.1 RELENG_5_3 src/UPDATING1.342.2.13.2.36
Re: Multiple BGP Routes in FIB
Hi Glenn,
Glen Kent wrote:
Hi,
There is an interesting discussion going on in the IDR WG and i am
cross posting a mail on Nanog to hear from the operators, if what is
described below, a common practise followed by them:
I don't think its correct to advertise one while using both for
forwarding.
NOTE: I am assuming that the routes share the same path length but
have
different AS Paths (as mentioned by you earlier in this mail)
I think this is being done by many providers.
Consider two paths for nlri X
as_path 1 {x y z} next_hop n1
as_path 2 {m n z} next_hop n2
Are you suggesting that providers are installing ecmp routes for X with
next-hops n1 and n2, while advertising only one of the paths to their
IBGP
peers?
Yes.
Do providers really do this? Would they install multiple BGP Paths
with different AS Paths (but same length) in their FIB, and yet
advertise only one?
Is the the right thing to do?
I believe the problem is with the BGP withdrawal mechanism. When BGP
withdraws a route it only specifies the prefix being withdrawn and not
the path. In this case, if the peer advertised both paths {x y z} and {m
n z} for a single prefix it would be impossible to withdraw only one of
the paths. I guess, even when using ECMP, BGP still really only
considers there to be one best route. Everything else is local FIB
manipulations based on local policy (in a similar vein to policy routing
- the BGP advertisements don't always reflect which way the traffic will
actually be routed).
Sam
[Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
I am looking for anyone who has input on possibly the largest case regarding internet numbering ever. This lawsuit may change the way IP's are governed and adminstered. Comments on or off list please. Anyone have experiences like are said in the lawsuit? I would love to know if this is true or not. Anyone with negative ARIN experiences that relate to the lawsuit, please let me know, thanks! For thos interested, you may read this lawsuit here: http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARINhl=engl=usct=clnkcd=1 Or google for Kremen VS Arin Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506 Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506 NOTICE - This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply immediately by way of advice to us. It is the addressee/recipient duty to virus scan and otherwise test the information provided before loading onto any computer system. Suavemente, INC. does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Suavemente, INC.
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Chris Jester wrote: I am looking for anyone who has input on possibly the largest case regarding internet numbering ever. This lawsuit may change the way IP's are governed and adminstered. Comments on or off list please. Anyone have experiences like are said in the lawsuit? I would love to know if this is true or not. Anyone with negative ARIN experiences that relate to the lawsuit, please let me know, thanks! For thos interested, you may read this lawsuit here: http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARINhl=engl=usct=clnkcd=1 Or google for Kremen VS Arin Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506 Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506 NOTICE - This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply immediately by way of advice to us. It is the addressee/recipient duty to virus scan and otherwise test the information provided before loading onto any computer system. Suavemente, INC. does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Suavemente, INC. This could be fairly interesting. One bit that did stick out is II. A. 25 (I don't know what the proper notation for this should be), Recently a new form of Internet addressing has emerged, called Classless Inter-Domain Routing (CIDR). In this new addressing protocol, a CIDR network address could look like this: 190.30.250.00/21. The prefix is the address of the network, or gateway, and the number after the slash indicates the size of the network. The higher the number, the more host space that is in the network. Well, last I checked, 1993 wasn't recent, and those last two sentences were quite a mistake. Cheers, jonathan
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Two questions regarding thisfor the list (slightly OT):1) Has any sort of IP address ownership precedence been set in a US court?2) Isn't ARIN considered a non-profit resource management/allocation organization? To my knowledge, there is no marketplace for IPs. Thanks!-brandonOn 9/8/06, Chris Jester [EMAIL PROTECTED] wrote: I am looking for anyone who has input on possibly the largest caseregarding internet numbering ever. This lawsuit may change the wayIP's are governed and adminstered. Comments on or off list please. Anyone have experiences like are said in the lawsuit? I would loveto know if this is true or not.Anyone with negative ARIN experiencesthat relate to the lawsuit, please let me know, thanks!For thos interested, you may read this lawsuit here: http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARINhl=engl=usct=clnkcd=1 Or google for Kremen VS ArinChris JesterSuavemente, INC.SplitInfinity Networks619-227-8845AIM: NJesterCQ: 64791506Chris JesterSuavemente, INC.SplitInfinity Networks 619-227-8845AIM: NJesterCQ: 64791506NOTICE - This e-mail and any files transmitted with it are confidential andare only for the use of the person to whom they are addressed. If you arenot the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any waywhatsoever with this e-mail is strictly prohibited. If you have receivedthis e-mail in error, please reply immediately by way of advice to us. It is the addressee/recipient duty to virus scan and otherwise test theinformation provided before loading onto any computer system. Suavemente,INC.does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of theindividual sender, except where the sender specifically states them to bethe views of Suavemente, INC. -- Brandon GalbraithEmail: [EMAIL PROTECTED]AIM: brandong00Voice: 630.400.6992A true pirate starts drinking before the sun hits the yard-arm. Ya. --thelost
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Interesting read. http://www.internetgovernance.org/pdf/kremen.pdf#search=%22kremen%20vs%20arin%22 I found this little gem in the The Internet, IP addresses and Domain Names section: --- Recently a new form of Internet addressing has emerged, called Classless Inter-Domain Routing (CIDR). In this new addressing protocol, a CIDR network address could look like this: 193.30.250.00/21. The prefix is the address of the network, or gateway, and the number after the slash indicates the size of the network. The higher the number, the more host space that is in the network(2). ... --- (2) later contradicts this statement. Maybe I should sell them some /32's, or why not a few /128's. Or maybe I just have too much time on my hands. /Tony On 08/09/06, Chris Jester [EMAIL PROTECTED] wrote: I am looking for anyone who has input on possibly the largest caseregarding internet numbering ever. This lawsuit may change the wayIP's are governed and adminstered. Comments on or off list please. Anyone have experiences like are said in the lawsuit? I would loveto know if this is true or not.Anyone with negative ARIN experiencesthat relate to the lawsuit, please let me know, thanks!For thos interested, you may read this lawsuit here: http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARINhl=engl=usct=clnkcd=1 Or google for Kremen VS ArinChris JesterSuavemente, INC.SplitInfinity Networks619-227-8845AIM: NJesterCQ: 64791506Chris JesterSuavemente, INC.SplitInfinity Networks 619-227-8845AIM: NJesterCQ: 64791506NOTICE - This e-mail and any files transmitted with it are confidential andare only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any waywhatsoever with this e-mail is strictly prohibited. If you have receivedthis e-mail in error, please reply immediately by way of advice to us. It is the addressee/recipient duty to virus scan and otherwise test theinformation provided before loading onto any computer system. Suavemente,INC.does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of theindividual sender, except where the sender specifically states them to bethe views of Suavemente, INC. -- Tony Sarendal - [EMAIL PROTECTED]IP/Unix -= The scorpion replied, I couldn't help it, it's my nature =-
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
I am looking for anyone who has input on possibly the largest case regarding internet numbering ever. This lawsuit may change the way IP's are governed and adminstered. Comments on or off list please. My personal opinion is that this is yet another example of ignorance leading to anger leading to a stupid waste of court time. The case is filled with incorrect statements of fact which ARIN can easily demolish. But at the bottom line, these people are complaining because ARIN didn't let them use some IP addresses that were assigned to a different company. Since IP addresses are basically available free from any ISP who sells Internet access services, this seems like a severe error in judgement on the part of the plaintiff. A smart businessperson would have used the free IP addresses to keep their business online even if they did decide to dispute ARIN's decision. But in the end, IP addresses are not property, therefore they cannot be assets and cannot be transferred. They can only be kept if they are in use on network assets which are transferred and which continue to be operational. And even then, most people have no choice as to which specific address block they use. They simply take what the ISP gives them. I personally suspect that ARIN will have this thrown out of court in fairly short order. Even if it did go much further, the parallels with NANPA would see it fade away quite quickly. This discussion really belongs on http://www.groklaw.net/ where I note it has not yet appeared. Perhaps another indication that this is a tempest in a teapot. --Michael Dillon
RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
If it gets to trial, I can see all kinds of stunts.. A jury trial on a highly technical issue? We hope that ma and pa non-computer literate owners are not on the jury But I think Michael is right, too many technical errors and less than accurate statements. Someone does not understand what is going on and wrote an interesting read of a case... Later, J -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, September 08, 2006 7:36 AM To: [EMAIL PROTECTED] Subject: Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?] I am looking for anyone who has input on possibly the largest case regarding internet numbering ever. This lawsuit may change the way IP's are governed and adminstered. Comments on or off list please. My personal opinion is that this is yet another example of ignorance leading to anger leading to a stupid waste of court time. The case is filled with incorrect statements of fact which ARIN can easily demolish. But at the bottom line, these people are complaining because ARIN didn't let them use some IP addresses that were assigned to a different company. Since IP addresses are basically available free from any ISP who sells Internet access services, this seems like a severe error in judgement on the part of the plaintiff. A smart businessperson would have used the free IP addresses to keep their business online even if they did decide to dispute ARIN's decision. But in the end, IP addresses are not property, therefore they cannot be assets and cannot be transferred. They can only be kept if they are in use on network assets which are transferred and which continue to be operational. And even then, most people have no choice as to which specific address block they use. They simply take what the ISP gives them. I personally suspect that ARIN will have this thrown out of court in fairly short order. Even if it did go much further, the parallels with NANPA would see it fade away quite quickly. This discussion really belongs on http://www.groklaw.net/ where I note it has not yet appeared. Perhaps another indication that this is a tempest in a teapot. --Michael Dillon
BGP Update Report
BGP Update Report Interval: 25-Aug-06 -to- 07-Sep-06 (14 days) Observation Point: BGP Peering with AS4637 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS413437938 2.8% 61.8 -- CHINANET-BACKBONE No.31,Jin-rong Street 2 - AS17974 18693 1.4% 36.9 -- TELKOMNET-AS2-AP PT TELEKOMUNIKASI INDONESIA 3 - AS868513836 1.0% 406.9 -- DORUKNET DorukNet Istanbul / Turkey 4 - AS619711668 0.9% 11.3 -- BATI-ATL - BellSouth Network Solutions, Inc 5 - AS912111449 0.8% 97.0 -- TTNET TTnet Autonomous System 6 - AS15464 11391 0.8% 474.6 -- IHLASNET IHLASNET Autonomous System 7 - AS838610412 0.8% 433.8 -- KOCNET KOCNET-AS 8 - AS17557 10189 0.8% 28.4 -- PKTELECOM-AS-AP Pakistan Telecom 9 - AS15611 10017 0.7% 88.6 -- Iranian Research Organisation 10 - AS855 9974 0.7% 17.7 -- CANET-ASN-4 - Aliant Telecom 11 - AS341049297 0.7% 464.9 -- TELETEK-AS TELETEK TELEKOMINIKASYON HIZMETLERI A.S 12 - AS124978715 0.6% 174.3 -- SANET-GE SANET NETWORK (AS) 13 - AS7011 8589 0.6% 12.8 -- FRONTIER-AND-CITIZENS - Frontier Communications, Inc. 14 - AS337838176 0.6% 76.4 -- EEPAD 15 - AS4621 8164 0.6% 60.9 -- UNSPECIFIED UNINET-TH 16 - AS4787 8063 0.6% 30.2 -- ASN-CBN ASN CBNnet 17 - AS9394 8062 0.6% 17.6 -- CRNET CHINA RAILWAY Internet(CRNET) 18 - AS9021 7775 0.6% 555.4 -- ISNET ISBANKASI Autonomous System 19 - AS6198 7755 0.6% 15.0 -- BATI-MIA - BellSouth Network Solutions, Inc 20 - AS346957252 0.5% 164.8 -- E4A-AS E4A Primary AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS3043 3039 0.2%3039.0 -- AMPHIB-AS - Amphibian Media Corporation 2 - AS30298 988 0.1% 988.0 -- FIRST-AMERICAN-BANK-SSB - First American Bank 3 - AS34378 900 0.1% 900.0 -- RUG-AS Razguliay-UKRROS Group 4 - AS12922 842 0.1% 842.0 -- MULTITRADE-AS Bank Outsourcer 5 - AS34984 794 0.1% 794.0 -- BITEL-AS BILISIM TELEKOM 6 - AS35080 784 0.1% 784.0 -- OYAK-TELEKOM-AS Oyak Telekom Hizm. BGP AS 7 - AS39298 762 0.1% 762.0 -- SERI Seri Bilgi Teknolojileri ve Destek Hizmetleri 8 - AS4271 1493 0.1% 746.5 -- WORX - Networx 9 - AS31526 745 0.1% 745.0 -- TEKOFAKS-AS TEKOFAKS 10 - AS29666 725 0.1% 725.0 -- TRHENKEL Turk Henkel Kimya Sanayi 11 - AS39080 721 0.1% 721.0 -- SIMETRI-AS SIMETRI YAZILIM 12 - AS313651432 0.1% 716.0 -- SGSTELEKOM SGS Telekom Autonomous System 13 - AS31085 711 0.1% 711.0 -- VIKINGNET-AS VIKING TUR 14 - AS29635 700 0.1% 700.0 -- BANVIT-AS Banvit A.S 15 - AS30734 682 0.1% 682.0 -- METISBILG-AS Metis Bilgi Sistemleri A.S 16 - AS31704 677 0.1% 677.0 -- ROBERTCOLLEGE-AS Robert College 17 - AS38920 676 0.1% 676.0 -- MNGBANK-TR Mng Turkiye 18 - AS39328 668 0.1% 668.0 -- BOTO-AS Borusan Oto 19 - AS31307 668 0.1% 668.0 -- YKYATIRIM YAPI KREDI YATIRIM 20 - AS295492646 0.2% 661.5 -- ZIRAATBANK-AS T.C. Ziraat Bankasi A.S. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.125.147.0/24 3980 0.2% AS17557 -- PKTELECOM-AS-AP Pakistan Telecom 2 - 208.0.225.0/24 3068 0.2% AS11139 -- CWRIN CW BARBADOS 3 - 209.140.24.0/243039 0.2% AS3043 -- AMPHIB-AS - Amphibian Media Corporation 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 5 - 143.81.0.0/21 1618 0.1% AS6034 -- DDN-ASNBLK - DoD Network Information Center 6 - 205.98.32.0/20 1147 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 7 - 195.46.34.0/23 1013 0.1% AS31200 -- NTK Novotelecom ltd. 8 - 216.85.162.0/231001 0.1% AS6467 -- ESPIRECOMM - Xspedius Communications Co. 9 - 209.189.231.0/24988 0.1% AS30298 -- FIRST-AMERICAN-BANK-SSB - First American Bank 10 - 205.97.69.0/24 933 0.1% AS5839 -- DDN-ASNBLK - DoD Network Information Center 11 - 130.36.88.0/21 931 0.1% AS2686 -- ATT Global Network Services - EMEA 12 - 205.97.70.0/24 930 0.1% AS5839 --
The Cidr Report
This report has been generated at Fri Sep 8 21:45:01 2006 AEST.
The report analyses the BGP Routing Table of an AS4637 (Reach) router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/as4637 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
01-09-06193923 126440
02-09-06194021 126509
03-09-06193976 126474
04-09-06194001 126621
05-09-06194218 126743
06-09-06194352 126801
07-09-06194163 127028
08-09-06194527 126877
AS Summary
22992 Number of ASes in routing system
9655 Number of ASes announcing only one prefix
1471 Largest number of prefixes announced by an AS
AS7018 : ATT-INTERNET4 - ATT WorldNet Services
91398144 Largest address span announced by an AS (/32s)
AS721 : DISA-ASNBLK - DoD Network Information Center
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 08Sep06 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 194400 1268546754634.7% All ASes
AS4134 1272 269 100378.9% CHINANET-BACKBONE
No.31,Jin-rong Street
AS4755 978 69 90992.9% VSNL-AS Videsh Sanchar Nigam
Ltd. Autonomous System
AS18566 959 126 83386.9% COVAD - Covad Communications
Co.
AS4323 994 292 70270.6% TWTC - Time Warner Telecom,
Inc.
AS9498 849 155 69481.7% BBIL-AP BHARTI BT INTERNET
LTD.
AS721974 308 66668.4% DISA-ASNBLK - DoD Network
Information Center
AS22773 697 52 64592.5% CCINET-2 - Cox Communications
Inc.
AS6197 1028 487 54152.6% BATI-ATL - BellSouth Network
Solutions, Inc
AS7018 1471 953 51835.2% ATT-INTERNET4 - ATT WorldNet
Services
AS19262 694 189 50572.8% VZGNI-TRANSIT - Verizon
Internet Services Inc.
AS17488 529 41 48892.2% HATHWAY-NET-AP Hathway IP Over
Cable Internet
AS19916 565 94 47183.4% ASTRUM-0001 - OLM LLC
AS855553 86 46784.4% CANET-ASN-4 - Aliant Telecom
AS11492 731 287 44460.7% CABLEONE - CABLE ONE
AS17676 498 62 43687.6% JPNIC-JP-ASN-BLOCK Japan
Network Information Center
AS18101 447 23 42494.9% RIL-IDC Reliance Infocom Ltd
Internet Data Centre,
AS3602 511 104 40779.6% AS3602-RTI - Rogers Telecom
Inc.
AS4766 703 310 39355.9% KIXS-AS-KR Korea Telecom
AS812416 30 38692.8% ROGERS-CABLE - Rogers Cable
Inc.
AS15270 460 77 38383.3% AS-PAETEC-NET - PaeTec.net -a
division of
PaeTecCommunications, Inc.
AS22047 454 94 36079.3% VTR BANDA ANCHA S.A.
AS4812 395 60 33584.8% CHINANET-SH-AP China Telecom
(Group)
AS6467 396 61 33584.6% ESPIRECOMM - Xspedius
Communications Co.
AS16852 366 53 31385.5% FOCAL-CHICAGO - Focal Data
Communications of Illinois
AS16814 329 47 28285.7% NSS S.A.
AS19115 375 97 27874.1% CHARTER-LEBANON - Charter
Communications
AS9583 952 678 27428.8% SIFY-AS-IN Sify Limited
AS14654 284 15 26994.7% WAYPORT - Wayport
AS17849 423 157 26662.9% GINAMHANVIT-AS-KR hanvit ginam
broadcasting comm.
AS6167 369 106 26371.3% CELLCO-PART - Cellco
Partnership
Total
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Fri, 8 Sep 2006 [EMAIL PROTECTED] wrote: Since IP addresses are basically available free from any ISP who sells Internet access services, this seems In small quantities, and which tie you to particular providers. Shells of companies have been bought (or just claimed) for their large, especially pre-ARIN, PI-IP assignments. To a young ISP, a /16 for example may seem like a lifetime supply of IP space, and save the company many thousands of dollars (ARIN registration fees) and paperwork hassles. News of this case has been sent here before (by [EMAIL PROTECTED] back in July). Is anything really happening with the case? -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
This is Gary Kremen owner of SEX dot com.cohen stole sex.com from kremen and kremen sued and got it back - it looks like he is trying to force arin to give him cohen's IP assignments sounds like a grudge match - but it is a shame that he might do arin collateral damage =The COOK Report on Internet Protocol, 609 882-2572 (PSTN) 415 651-4147 (Lingo) Back Issues: http://www.cookreport.com/browse_past_free2.shtml Cook's Collaborative Edge Blog http://gordoncook.net/wp/ Subscription info: http://cookreport.com/subscriptions.shtml= On Sep 8, 2006, at 5:36 AM, tony sarendal wrote: Interesting read. http://www.internetgovernance.org/pdf/kremen.pdf#search=%22kremen%20vs%20arin%22I found this little gem in the "The Internet, IP addresses and Domain Names" section: --- Recently a new form of Internet addressing has emerged, called Classless Inter-Domain Routing (CIDR). In this new addressing protocol, a CIDR network address could look like this: 193.30.250.00/21. The prefix is the address of the network, or gateway, and the number after the slash indicates the size of the network. The higher the number, the more host space that is in the network(2). ... --- (2) later contradicts this statement. Maybe I should sell them some /32's, or why not a few /128's. Or maybe I just have too much time on my hands. /Tony On 08/09/06, Chris Jester [EMAIL PROTECTED] wrote: I am looking for anyone who has input on possibly the largest caseregarding internet numbering ever. This lawsuit may change the wayIP's are governed and adminstered. Comments on or off list please. Anyone have experiences like are said in the lawsuit? I would loveto know if this is true or not. Anyone with negative ARIN experiencesthat relate to the lawsuit, please let me know, thanks!For thos interested, you may read this lawsuit here: http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARINhl=engl=usct=clnkcd=1 Or google for Kremen VS ArinChris JesterSuavemente, INC.SplitInfinity Networks619-227-8845AIM: NJesterCQ: 64791506Chris JesterSuavemente, INC.SplitInfinity Networks 619-227-8845AIM: NJesterCQ: 64791506NOTICE - This e-mail and any files transmitted with it are confidential andare only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any waywhatsoever with this e-mail is strictly prohibited. If you have receivedthis e-mail in error, please reply immediately by way of advice to us. It is the addressee/recipient duty to virus scan and otherwise test theinformation provided before loading onto any computer system. Suavemente,INC.does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of theindividual sender, except where the sender specifically states them to bethe views of Suavemente, INC. -- Tony Sarendal - [EMAIL PROTECTED]IP/Unix -= The scorpion replied, "I couldn't help it, it's my nature" =-
Re: TCP receive window set to 0; DoS or not?
[EMAIL PROTECTED] writes: On Thu, 7 Sep 2006, Joshua Brewer wrote: What about when we're seeing this on port 25? Sand worms. In all seriousness, your guess is as good as mine, at that point. If memory serves, the platforms we saw this on most, with web browsers, were mobile devices. What kind of volume are you seeing this in? Since the error message is within a debug statement, it seems appropriate to repeat the words of advice an old pilot friend of mine once gave on making emergency landings at night in small aircraft: First, turn off your strobes and landing lights - you want to be able to see well outside the aircraft. Find a road. Fly a normal left-hand pattern, and as you turn base to final, turn your landing lights back on. If you don't like what you see, turn them back off again. ---rob
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Jon Lewis wrote: In small quantities, and which tie you to particular providers. Shells of companies have been bought (or just claimed) for their large, especially pre-ARIN, PI-IP assignments. To a young ISP, a /16 for example may seem like a lifetime supply of IP space, and save the company many thousands of dollars (ARIN registration fees) and paperwork hassles. Actually, their issue is that ARIN would only transfer the netblock to them under the condition of them signing the contract (which effectively states that ARIN controls the netblocks). They would also be liable for the annual fees. They are trying to treat IP address space as property which they own, and refuse to agree to ARIN registration/fees to obtain what they feel is their property. Unfortunately, while ARIN is a steward and technically does not *own* the IP address space, neither does the ISP that uses the space. The defendant apparently misses the fact that IP space is a community asset and is thus handled by the community. IANAL, but I doubt they can prove Antitrust in this case. If only we could handle other limited resources in the world as effectively; including BGP routing table bloat. -Jack
Wiltel contact
Can someone at wcg.net contact me offlist to discuss a security incident. --
Market Share of broadband provider in Scandidavia
Could anyone point me to a market-share by-country overview of broadband provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any help would be appreciated. Regards, Fredy
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Thus spake Brandon Galbraith Two questions regarding thisfor the list (slightly OT): 1) Has any sort of IP address ownership precedence been set in a US court? Not that I'm aware of, but I've never looked. I'm sure ARIN's lawyers have. 2) Isn't ARIN considered a non-profit resource management/allocation organization? To my knowledge, there is no marketplace for IPs. The entire suit is predicated on the concept that IP addresses can be owned and traded like other property. The rest is a house of cards that will fall if ARIN can prove that to be incorrect -- and will probably stand if they can't. Also, any technical expert can rip about half of the house down without breaking a sweat because it's so flawed to the point of being entertaining. It'd be fun to read the transcripts if this ever goes to trial, but my money says it'll be decided one way or the other before it actually makes it into a courtroom. The wording of Kremen's argument made me understand why ARIN is so resistant to using the term rent for their activities, because that implies that there is property exchanging hands. Courts have jurisdiction over property, though it's a minefield to try to dictate who someone must rent to. Keeping the words in registry-speak allows them to differentiate the situation and insist that addresses are not property at all. The anti-trust angle is interesting, but even if ARIN were found to be one, it's hard to convince people that a _non-profit_ monopoly acting in the public interest is a bad thing. The debate there will be around the preferential treatment that larger ARIN members get (in terms of larger allocations, lower per address fees, etc), which Kremen construes as being anticompetitive via creating artificial barriers to entry. That may end up being changed. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: [routing-wg]BGP Update Report
On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation? TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 4 - 83.210.15.0/24 1843 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS29257 -- CBB-IE-AS Connexion by Boeing Ireland, Ltd. AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing 17 - 60.253.32.0/24 822 0.1% AS23918 -- CBB-BGP-IBARAKI Connexion By Boeing Ibaraki AS AS30533 -- CONNEXION-BY-BOEING-LTN - Connexion by Boeing AS31050 -- CBB-RU-ASN Connexion by Boeing Eastern Europe, Ltd. AS33697 -- CONNEXION-BY-BOEING-VBC - Connexion by Boeing Hank Nussbacher http://www.interall.co.il
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
The debate there will be around the preferential treatment that larger ARIN members get (in terms of larger allocations, lower per address fees, etc), which Kremen construes as being anticompetitive via creating artificial barriers to entry. That may end up being changed. Your statement about preferential treatment is factually incorrect. Larger ARIN members do not get larger allocations. It is the larger network infrastructures that get the larger allocations which is not directly tied to the size of the company. Yes, larger companies often have larger infrastructures. However, ARIN gives the addresses based primarily on the number of hosts attached to the network infrastructure. It has been argued in the past that ARIN's policies are prejudiced AGAINST larger organizations because the rules do not properly allow for the scaling overhead necessary due to the complexity of larger networks. As for fees, there are no per-address fees and there never have been. When we created ARIN, we paid special attention to this point because we did not want to create the erroneous impression that people were buying IP addresses. The fees are related to the amount of effort required to service an organization and that is not directly connected to the number of addresses. --Michael Dillon (no longer in any official ARIN capacity. Just another member)
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
[EMAIL PROTECTED] wrote: But in the end, IP addresses are not property, therefore they cannot be assets and cannot be transferred. They can only be kept if they are in use on network assets which are transferred and which continue to be operational. And even then, most people have no choice as to which specific address block they use. They simply take what the ISP gives them. One could probably debate that statement for a long time. Saying they are free to me is technically inaccurate. If you are getting PI space, you have to pay registration fees, which incurs cost on behalf of the party. A growing number of ISPs are now charging leasing fees or similar fees for the usage of PA addresses. As IP address scarcity goes up, I wouldn't be surprised if leasing fees become higher and/or if ARIN fees become more steep as an attempt to weed out people who are trying to horde address space. While IP addresses certainly are not a tangible asset, and a defined intrinsic value can not be determined, there does seem to be a value to them, if only speculative at best. Best Regards, -Michael -- Michael Nicks Network Engineer KanREN e: [EMAIL PROTECTED] o: +1-785-856-9800 x221 m: +1-913-378-6516
Re: [routing-wg]BGP Update Report
On Sep 8, 2006, at 10:57 AM, Hank Nussbacher wrote: On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation? They presented at NANOG saying they would be re-announcing a /24 per plane as it crosses the ocean. I can't recall if the originating (or transit) ASNs were going to change, but it doesn't seem wholly unreasonable. IMHO, of course. -- TTFN, patrick
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
-- [EMAIL PROTECTED] wrote: I am looking for anyone who has input on possibly the largest case regarding internet numbering ever. This lawsuit may change the way IP's are governed and adminstered. Comments on or off list please. My personal opinion is that this is yet another example of ignorance leading to anger leading to a stupid waste of court time. [...] On this, we agree. :-) - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Market Share of broadband provider in Scandidavia
On Friday 08 Sep 2006 15:21, you wrote: Could anyone point me to a market-share by-country overview of broadband provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any help would be appreciated. Ovum use to do reports on European ISP market share, I think it covered Scandinavia (I don't think we worried too much given that the entire population of Scandinavia is about the same as greater London, we were focused on larger countries - by population - mostly). Included best guess at future changes at the time as well. The report wasn't cheap, but the people I was working with just bought large chunks of such intelligence in order to assess big investment decisions.
Re: Market Share of broadband provider in Scandidavia
On Fri, 8 Sep 2006, Fredy Kuenzler wrote: Could anyone point me to a market-share by-country overview of broadband provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any help would be appreciated. For Sweden, you can go to www.pts.se, more exactly http://www.pts.se/Sidor/sida.asp?Sectionid=1341Itemid=Languageid=EN. They publish both in Sweden and English as far as I can discern. PTS is the regulatory entity in Sweden for Telecommunications (and Post, but that's beside the point here :) ). -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Fri, 8 Sep 2006, Gordon Cook wrote: This is Gary Kremen owner of SEX dot com. cohen stole sex.com from kremen and kremen sued and got it back - it looks like he is trying to force arin to give him cohen's IP assignments sounds like a grudge match - but it is a shame that he might do arin collateral damage Yes, at the least, wasting huge piles of ARIN's money on legal fees; which is likely Kremen's entire intent, to teach them a lesson for not handing over what he wanted. People who use the courts as a way to bleed their targets like this are vermin. Not surprising at all that this is all about some domain-squatting nonsense. I do hope that ARIN can convince the judge to issue a summary judgement to throw this entire case out. matto [EMAIL PROTECTED]darwin Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Hopefully ARIN can recover their legal fees, so cash from members can be spent on IP space management.-brandonOn 9/8/06, Matt Ghali [EMAIL PROTECTED] wrote:On Fri, 8 Sep 2006, Gordon Cook wrote: This is GaryKremen owner of SEX dot com. cohen stole sex.com from kremen and kremen sued and got it back - it looks like he is trying to force arin to give him cohen's IP assignmentssounds like a grudge match - but it is a shame that he might do arin collateral damageYes, at the least, wasting huge piles of ARIN's money on legal fees;which is likely Kremen's entire intent, to teach them a lesson fornot handing over what he wanted.People who use the courts as a way to bleed their targets like this are vermin. Not surprising at all that this is all about somedomain-squatting nonsense.I do hope that ARIN can convince the judge to issue a summaryjudgement to throw this entire case out.matto [EMAIL PROTECTED]darwin Moral indignation is a technique to endow the idiot with dignity. - Marshall McLuhan -- Brandon GalbraithEmail: [EMAIL PROTECTED]AIM: brandong00Voice: 630.400.6992A true pirate starts drinking before the sun hits the yard-arm. Ya. --thelost
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Matt Ghali wrote: Yes, at the least, wasting huge piles of ARIN's money on legal fees; which is likely Kremen's entire intent, to teach them a lesson for not handing over what he wanted. Correction. Wasting huge piles of our money. I was hoping the money would go towards a new template, too! -Jack
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
The complaint was, at best, an entertaining read. IANAL. As was mentioned earlier, it looks like Kremen's whole case is built on a number of false assumptions: 1. Netblocks are the property of the organization once their assignment request is approved by ARIN or other RIR. Since this is false, the none of the parties involved in Kremen v. Cohen would have legal standing to make the transfer of Cohen's netblocks a condition of satisfying the judgment in that case. 2. There is an open market for buying and selling IP addresses. While ISPs can and sometimes do charge fees to their customers to use a block of PA space, they cannot do the same on an 'open' market. The customer normally may use the PA space until their business relationship with the ISP is terminated, i.e. the space is non-portable. 3. ARIN's policies discriminate against smaller providers by preventing them from getting larger netblocks. Going back to 1997 from what I can find, ARIN's address assignment policies have always advocated a pay-as-you-go model. If an organization gets close to using all of their assigned addresses, they can request another block once they've provided justification that the first assignment has been efficiently used. The complaint acknowledges that IP addresses are finite resources and that macro-allocation of address ranges is handled by ICANN. 4. Recently... Classless Inter-Domain Routing or CIDR... As others have mentioned, this is hilarious. I guess I'll have to upgrade my routers to use that newfangled routing protocol, BGP4 CIDR had a huge impact in putting the brakes on wasteful IP address allocation. The days of /16s being available pretty much for the asking are long gone. 5. Providing information to justify an assignment or transfer request will force the requestor to reveal information that is confidential and proprietary. The way I see it, this helps maintain some degree of transparency of ARIN's policies, customer business names and addresses are items that are probably already matters of public record from domain name registrations and so forth. Also, the information provided to ARIN when requesting more space is normally more detailed than what is required to be made public through SWIP or RWHOIS. The information specifically submitted to ARIN for proving a request is justified is not released to the public. jms
Re: [routing-wg]BGP Update Report
On Fri, 8 Sep 2006, Hank Nussbacher wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Yes, that was their architecture, originally. My understanding was that they'd subsequently moved to a more complicated system of NATing, but my understanding may be incorrect, or they may not have done so entirely. -Bill
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
-- Stephen Sprunk [EMAIL PROTECTED] wrote: The entire suit is predicated on the concept that IP addresses can be owned and traded like other property. The rest is a house of cards that will fall if ARIN can prove that to be incorrect -- and will probably stand if they can't. [snip] I like how Jack Bates framed it: The IP address space is a community asset and as such, the allocation of it needs to be done in a way which serves benefits the Internet community at-large. That said, we have had this discussion many times over the years, especially within IEPG discussions, and punching holes in CIDR blocks, for the sake of alighning address space w.r.t. special interests (as opposed to some sanity in allocation policy which attempts to preserve allocation to allow CIDR aggregation) is a Bad Thing. It will be interesing to see how this plays out... - ferg -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Market Share of broadband provider in Scandidavia
On (2006-09-08 18:03 +0200), Mikael Abrahamsson wrote: Could anyone point me to a market-share by-country overview of broadband provider in Scandinavia (Denmark, Sweden, Norway, Finland, Iceland). Any help would be appreciated. For Sweden, you can go to www.pts.se, more exactly http://www.pts.se/Sidor/sida.asp?Sectionid=1341Itemid=Languageid=EN. For Finland, from ~same govertment body: http://www.ficora.fi/englanti/tele/marketreview.htm Or direct URL to the PDF itself: http://www.ficora.fi/englanti/document/Markkinakatsaus_2_2006_EN.pdf Page 9 should answer your question. -- ++ytti
Re: [routing-wg]BGP Update Report
If I recall correctly, Todd Underwood over at Renesy did a pretty interesting write-up on this a while back [Later] Here it is: http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml - ferg -- Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Sep 8, 2006, at 10:57 AM, Hank Nussbacher wrote: On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation? They presented at NANOG saying they would be re-announcing a /24 per plane as it crosses the ocean. I can't recall if the originating (or transit) ASNs were going to change, but it doesn't seem wholly unreasonable. IMHO, of course. -- TTFN, patrick -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: [routing-wg]BGP Update Report
On Fri, Sep 08, 2006 at 05:57:10PM +0300, Hank Nussbacher wrote: On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation? Detailed at nanog 31 (among other meetings): http://www.nanog.org/mtg-0405/abarbanel.html 2005 detail from a blogger: http://bayosphere.com/node/879 2006 detail from another blogger: http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
I read the complaint. I don't like the fact that a lot of my friends are named in the suit, but I think there are somepoints worth discussing within the community:1) IP address blocks are not 'property' "Domains are not property. The assignee of a domain has no ownership interest" Network Solutions made this same argument years ago. That was their shield against lawsuits when negligence (or worse) on NetSols part would cause a domain to be erroneously transferred. When mistakes were made, Network Solutions was notoriously unwilling to reverse the transaction to correct the error. Then they got sued for refusing to reverse a fradulent domain transfer, and they lost. The case had the side effect of setting the precedent that domains *are* in fact tangible property. Now when a registrar or registry makes a mistake, they can be legally held responsible. (What case was that? Kremen v. Network Solutions) I would say that's an improvement.2) Why does ARIN believe that it can ignore a court order?3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best use of it.Joe McGuckinViaNet Communications[EMAIL PROTECTED]650-207-0372 cell650-213-1302 office650-969-2124 fax
RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best use of it. I think you're dead-on there, but you forget who you're really trying to convince. It'll happen eventually but in the meantime the greybeards who were largely responsible for theInternet as we know it (and who by and large still wieldsignificant influence if not still stewardship) will be dragged there kicking and screaming from their academic/pseudo-Marxist ideals, some of whom seem to still resent the commercialization of the Internet. It's also hard to see the faults in the system when you are insulated by your position as member of the politburo. The flip side of the coin of course is that if you let the free market reign on IP's, you may price developing countries right off the Internet which I don't think anyone sees as a desirable outcome. There's sure to be a happy middle ground that people smarter than I will figure out, and maybe it takes a silly lawsuit such as this to kick things off. Andrew Cruse
RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best use of it. I think you're dead-on there, but you forget who you're really trying to convince. It'll happen eventually but in the meantime the greybeards who were largely responsible for theInternet as we know it (and who by and large still wieldsignificant influence if not still stewardship) will be dragged there kicking and screaming from their academic/pseudo-Marxist ideals, some of whom seem to still resent the commercialization of the Internet. It's also hard to see the faults in the system when you are insulated by your position as member of the politburo. The flip side of the coin of course is that if you let the free market reign on IP's, you may price developing countries right off the Internet which I don't think anyone sees as a desirable outcome. There's sure to be a happy middle ground that people smarter than I will figure out, and maybe it takes a silly lawsuit such as this to kick things off. Andrew Cruse Another somewhat important point is thatwe also needto conserve routing entries. If you make a market for addresses without regard to routability, you risk creating a situation where you flood the world with /32's. No thanks. Tony
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. Daily listings are sent to [EMAIL PROTECTED] For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith [EMAIL PROTECTED]. Routing Table Report 04:00 +10GMT Sat 09 Sep, 2006 Analysis Summary BGP routing table entries examined: 197313 Prefixes after maximum aggregation: 107623 Unique aggregates announced to Internet: 95918 Total ASes present in the Internet Routing Table: 23078 Origin-only ASes present in the Internet Routing Table: 20103 Origin ASes announcing only one prefix:9652 Transit ASes present in the Internet Routing Table:2975 Transit-only ASes present in the Internet Routing Table: 64 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 29 Max AS path prepend of ASN (36728) 27 Prefixes from unregistered ASNs in the Routing Table: 2 Unregistered ASNs in the Routing Table: 2 Special use prefixes present in the Routing Table:1 Prefixes being announced from unallocated address space: 9 Number of addresses announced to Internet: 1580431436 Equivalent to 94 /8s, 51 /16s and 120 /24s Percentage of available address space announced: 42.6 Percentage of allocated address space announced: 60.5 Percentage of available address space allocated: 70.5 Total number of prefixes smaller than registry allocations: 98476 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes:43293 Total APNIC prefixes after maximum aggregation: 17399 Prefixes being announced from the APNIC address blocks: 40913 Unique aggregates announced from the APNIC address blocks:18468 APNIC Region origin ASes present in the Internet Routing Table:2696 APNIC Region origin ASes announcing only one prefix:764 APNIC Region transit ASes present in the Internet Routing Table:404 Average APNIC Region AS path length visible:3.5 Max APNIC Region AS path length visible: 24 Number of APNIC addresses announced to Internet: 262062176 Equivalent to 15 /8s, 158 /16s and 192 /24s Percentage of available APNIC address space announced: 81.9 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911 APNIC Address Blocks 58/7, 60/7, 121/8, 122/7, 124/7, 126/8, 202/7 210/7, 218/7, 220/7 and 222/8 ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes: 99748 Total ARIN prefixes after maximum aggregation:58992 Prefixes being announced from the ARIN address blocks:73259 Unique aggregates announced from the ARIN address blocks: 27654 ARIN Region origin ASes present in the Internet Routing Table:10953 ARIN Region origin ASes announcing only one prefix:4147 ARIN Region transit ASes present in the Internet Routing Table:1011 Average ARIN Region AS path length visible: 3.3 Max ARIN Region AS path length visible: 29 Number of ARIN addresses announced to Internet: 296980224 Equivalent to 17 /8s, 179 /16s and 143 /24s Percentage of available ARIN address space announced: 77.0 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959 ARIN Address Blocks24/8, 63/8, 64/5, 72/6, 76/8, 199/8, 204/6, 208/7 and 216/8 RIPE Region Analysis Summary Prefixes being announced by RIPE Region ASes: 39668 Total RIPE prefixes after maximum aggregation:26501 Prefixes being announced from the RIPE address blocks:36571 Unique aggregates announced from the RIPE address blocks: 24728 RIPE Region origin ASes present in the Internet Routing Table: 8485 RIPE Region origin ASes announcing only one prefix:4455 RIPE Region transit ASes present in the
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Thus spake [EMAIL PROTECTED] [ I said ] The debate there will be around the preferential treatment that larger ARIN members get (in terms of larger allocations, lower per address fees, etc), which Kremen construes as being anticompetitive via creating artificial barriers to entry. That may end up being changed. Your statement about preferential treatment is factually incorrect. Larger ARIN members do not get larger allocations. It is the larger network infrastructures that get the larger allocations which is not directly tied to the size of the company. Yes, larger companies often have larger infrastructures. And that's the point: A company that is established gets preferential treatment over one that is not; that is called a barrier to entry by the anti-trust crowd. You may feel that such a barrier is justified and fair, but those on the other side of it (or more importantly, their lawyers) are likely to disagree. As for fees, there are no per-address fees and there never have been. When we created ARIN, we paid special attention to this point because we did not want to create the erroneous impression that people were buying IP addresses. The fees are related to the amount of effort required to service an organization and that is not directly connected to the number of addresses. Of course it's directly connected; all you have to do is look at the current fee schedule and you'll see: /24 = $4.88/IP /23 = $2.44/IP /22 = $1.22/IP /21 = $0.61/IP /20 = $0.55/IP /19 = $0.27/IP /18 = $0.27/IP /17 = $0.137/IP /16 = $0.069/IP /15 = $0.069/IP /14 = $0.034/IP So, just between the two ends of the fee schedule, we have a difference of _two orders of magnitude_ in how much an registrant pays divided by how much address space they get. Smaller folks may use this to say that larger ISPs, some of whose employees sit on the ARIN BOT/AC, are using ARIN to make it difficult for competitors to enter the market. Since that argument appears to be true _on the surface_, ARIN will need to show how servicing smaller ISPs incurs higher costs per address and thus the lower fees for large allocations are simply passing along the savings from economy of scale. Doable, but I wouldn't want to be responsible for coming up with that proof. Besides the above, Kremen also points out that larger prefixes are more likely to be routed, therefore refusing to grant larger prefixes (which aren't justified, in ARIN's view) is another barrier to entry. Again, since the folks deciding these policies are, by and large, folks who are already major players in the market, it's easy to put an anticometitive slant on that. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
The real fundamental flaw with this free-market approach to handling IP assignments is the fact that it will further create an environment where smaller (start-ups, small businesses) entities trying to acquire PI space will face insurmountable challenges (eg, financial). While I think the majority of people these days would agree that the free-market approach to economics is definitely the best, certain resources are not very applicable to be traded in a free-market environment. I myself do not like over-bureaucratic processes, and while all of us at one time or another have complained about ARIN's procedures, policies, and practices, the purpose they serve is a needed one. Best Regards, -Michael -- Michael Nicks Network Engineer KanREN e: [EMAIL PROTECTED] o: +1-785-856-9800 x221 m: +1-913-378-6516 [EMAIL PROTECTED] wrote: 3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best use of it. I think you're dead-on there, but you forget who you're really trying to convince. It'll happen eventually but in the meantime the greybeards who were largely responsible for the Internet as we know it (and who by and large still wield significant influence if not still stewardship) will be dragged there kicking and screaming from their academic/pseudo-Marxist ideals, some of whom seem to still resent the commercialization of the Internet. It's also hard to see the faults in the system when you are insulated by your position as member of the politburo. The flip side of the coin of course is that if you let the free market reign on IP's, you may price developing countries right off the Internet which I don't think anyone sees as a desirable outcome. There's sure to be a happy middle ground that people smarter than I will figure out, and maybe it takes a silly lawsuit such as this to kick things off. Andrew Cruse
RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best use of it. I think you're dead-on there, but you forget who you're really trying to convince. It'll happen eventually but in the meantime the greybeards who were largely responsible for theInternet as we know it (and who by and large still wieldsignificant influence if not still stewardship) will be dragged there kicking and screaming from their academic/pseudo-Marxist ideals, some of whom seem to still resent the commercialization of the Internet. It's also hard to see the faults in the system when you are insulated by your position as member of the politburo. The flip side of the coin of course is that if you let the free market reign on IP's, you may price developing countries right off the Internet which I don't think anyone sees as a desirable outcome. There's sure to be a happy middle ground that people smarter than I will figure out, and maybe it takes a silly lawsuit such as this to kick things off. Andrew Cruse Another somewhat important point is thatwe also needto conserve routing entries. If you make a market for addresses without regard to routability, you risk creating a situation where you flood the world with /32's. No thanks. Tony I would think that would tend to police itself. Even now with things as they are you're going to have serious reachability problems if you try to announce anything smaller than a /24. And if routing tables suddenly explode, I'd expect that threshold to quickly move in reaction. Andrew Cruse
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Sep 8, 2006, at 10:33 AM, Stephen Sprunk wrote: Thus spake [EMAIL PROTECTED] [ I said ] The debate there will be around the preferential treatment that larger ARIN members get (in terms of larger allocations, lower per address fees, etc), which Kremen construes as being anticompetitive via creating artificial barriers to entry. That may end up being changed. Your statement about preferential treatment is factually incorrect. Larger ARIN members do not get larger allocations. It is the larger network infrastructures that get the larger allocations which is not directly tied to the size of the company. Yes, larger companies often have larger infrastructures. And that's the point: A company that is established gets preferential treatment over one that is not; that is called a barrier to entry by the anti-trust crowd. You may feel that such a barrier is justified and fair, but those on the other side of it (or more importantly, their lawyers) are likely to disagree. As for fees, there are no per-address fees and there never have been. When we created ARIN, we paid special attention to this point because we did not want to create the erroneous impression that people were buying IP addresses. The fees are related to the amount of effort required to service an organization and that is not directly connected to the number of addresses. Of course it's directly connected; all you have to do is look at the current fee schedule and you'll see: /24 = $4.88/IP /23 = $2.44/IP /22 = $1.22/IP /21 = $0.61/IP /20 = $0.55/IP /19 = $0.27/IP /18 = $0.27/IP /17 = $0.137/IP /16 = $0.069/IP /15 = $0.069/IP /14 = $0.034/IP While the price points quoted may be accurate, they don't really reflect the pricing tiers in use at ARIN and I notice you completely ignore the fact that no matter how much more than a /14 you have, you pay $18,000 and additional allocations don't really cost anything. Further, the prices you suggest refer to registration fees for ISPs, but, the current fee schedule if you are NOT an ISP is a bit different (end user subscriber): /24 = $100/year /23 = $100/year /22 = $100/year /21 = $100/year ... /8 = $100/year etc. So, just between the two ends of the fee schedule, we have a difference of _two orders of magnitude_ in how much an registrant pays divided by how much address space they get. Smaller folks may use this to say that larger ISPs, some of whose employees sit on the ARIN BOT/AC, are using ARIN to make it difficult for competitors to enter the market. Since you are paying for registration services and not for the IPs themselves, that is perfectly reasonable. End users registration needs are simple, thus, the $100/year flat fee. ISPs do some volume of sub-assignment registration and as a result, the larger the network, the more registration effort involved. However, the effort does not scale linearly with the address space and the fee structure reflects this. Since that argument appears to be true _on the surface_, ARIN will need to show how servicing smaller ISPs incurs higher costs per address and thus the lower fees for large allocations are simply passing along the savings from economy of scale. Doable, but I wouldn't want to be responsible for coming up with that proof. I don't even think it is all that difficult. Especially given the end-user fees. Besides the above, Kremen also points out that larger prefixes are more likely to be routed, therefore refusing to grant larger prefixes (which aren't justified, in ARIN's view) is another barrier to entry. Again, since the folks deciding these policies are, by and large, folks who are already major players in the market, it's easy to put an anticometitive slant on that. It is my experience that any prefix within ARIN policy is generally equally routable. I would say that in my experience, Kremen's assertion in this area is false. Additionally, the characterization of the ARIN policy process is largely detached from reality. While the BoT technically has final and complete authority, I cannot recall a situation in which a policy with consensus was not accepted by the board, nor can I recall a situation where the board adopted a policy without consensus. Since the public policy meetings and mailing lists where consensus is judged are open to any interested party, it is very hard to view this as an anti-competitive act in my opinion. Owen PGP.sig Description: This is a digitally signed message part
RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Don't be so sure. What probably _would_ police these willy-nilly announcements, however, are prefix-length filters on the various ISP routers. :-) And again, this could certainly lend itself to folks sic'ing their lawyers on eacvh other in the name of anti-competitive lawsuits. A mess ensues that I don't think any of us wishes to see happen. - ferg -- [EMAIL PROTECTED] wrote: Another somewhat important point is that we also need to conserve routing entries. If you make a market for addresses without regard to routability, you risk creating a situation where you flood the world with /32's. No thanks. Tony I would think that would tend to police itself. Even now with things as they are you're going to have serious reachability problems if you try to announce anything smaller than a /24. And if routing tables suddenly explode, I'd expect that threshold to quickly move in reaction. -- Fergie, a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/
Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
Joe McGuckin typed: 2) Why does ARIN believe that it can ignore a court order? Maybe because ARIN wasn't a party to the original proceedings that generated that order? Let's say you're eating lunch one day, minding your own business, and a sheriff comes up with an official looking document and says You need to hand your car over to Fred... because, unknown to you, Fred and Barney just finished court proceedings where the judge ruled that Barney had to give Fred his car, even though that car was owned by you and just loaned to Barney. Not a great analogy, because of the whole pink slip thing, but you get the point. -mark
RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
Joe McGuckin typed: 2) Why does ARIN believe that it can ignore a court order? Maybe because ARIN wasn't a party to the original proceedings that generated that order? Let's say you're eating lunch one day, minding your own business, and a sheriff comes up with an official looking document and says You need to hand your car over to Fred... because, unknown to you, Fred and Barney just finished court proceedings where the judge ruled that Barney had to give Fred his car, even though that car was owned by you and just loaned to Barney. Not a great analogy, because of the whole pink slip thing, but you get the point. You comply with the court order to the extent that it will not do irreversible damage to you, and you contest the order in court. To the extent that the court order will do irreversible damage, you stall compliance until you can get a court to suspend the order until you have time to fully contest it. What you don't do is flat out refuse to comply with the court order with the beneficiary of the court order and make them go to court to enforce it. If you assume that all Kremen's accusations are true (and correct the obvious errors) his case seems very strong. ARIN should not have refused to comply with a court order or insisted on conditioning its reply. Even if you assume that allocations made by ARIN are not property, it's hard to argue that pre-ARIN allocations are not. They're not subject to revocation and their grant wasn't conditioned on compliance with policies. DS
Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
Mark,A more 'correct' analogy would be as follows: Let's say you win a judgement against another party where the court essentially awards you all the assets of the defendant. One of the assets is a paging company. So, you hike down to the FCC and want the radio licenses for the business re-registered in your name, you present a valid court order to show that the court has awarded you title to the assets. In fact, you present a court order specifically ordering the FCC to re-register the licensed spectrum to you.How can the FCC refuse? Any court with proper jurisdiction certainly has the ability to assess damages and specify remedies for thosedamages. A station license or spectrum - even though is not actual ownership, but a lease or license - is an asset and routinely are soldfor millions, even billions of dollars.More to the point, how can ARIN refuse such an order?Joe McGuckinViaNet Communications[EMAIL PROTECTED]650-207-0372 cell650-213-1302 office650-969-2124 fax On Sep 8, 2006, at 11:57 AM, Mark Kent wrote:Joe McGuckin typed: 2) Why does ARIN believe that it can ignore a court order? Maybe because ARIN wasn't a party to the original proceedingsthat generated that order?Let's say you're eating lunch one day, minding your own business,and a sheriff comes up with an official looking document andsays "You need to hand your car over to Fred..." because,unknown to you, Fred and Barney just finished court proceedingswhere the judge ruled that Barney had to give Fred "his" car,even though that car was owned by you and just loaned to Barney.Not a great analogy, because of the whole pink slip thing,but you get the point.-mark
Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
On Fri, 8 Sep 2006, Mark Kent wrote: Joe McGuckin typed: 2) Why does ARIN believe that it can ignore a court order? Maybe because ARIN wasn't a party to the original proceedings that generated that order? Let's say you're eating lunch one day, minding your own business, and a sheriff comes up with an official looking document and says You need to hand your car over to Fred... because, unknown to you, Fred and Barney just finished court proceedings where the judge ruled that Barney had to give Fred his car, even though that car was owned by you and just loaned to Barney. Not a great analogy, because of the whole pink slip thing, but you get the point. Actually that is pretty good analogy. Unfortunately in this case, the block appears to be one of legacy /16s that ARIN did not assign but IANA or Internic probably did. We're actually lucky they decided to not sue IANA or NSI because then the whole thing would have been ever messier and judge even more confused. IANAL, but I doubt it this will quickly end with summary judgment though (you need similar cases for judge to compare and see decisions there, otherwise detailed investigation of case will be required). Don't worry about costs though, I think ARIN has enough extra and do have a lawyer, so I hope they spend it what is necessary to get good results which can also be cited in the future. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
* [EMAIL PROTECTED] (David Schwartz) [Fri 08 Sep 2006, 21:20 CEST]: Even if you assume that allocations made by ARIN are not property, it's hard to argue that pre-ARIN allocations are not. They're not subject to revocation and their grant wasn't conditioned on compliance with policies. Some people here are on crack. Comparing IP addresses to mining rights? They're just numbers, not actual physical property. Do you also propose to take allocations away again when they're not announced on the Internet? Address space policy has always been the result of a community consensus. Just because that consensus has shifted over the years does not mean that older entries in some database have suddenly developed into property. All it means is that the community is very friendly for not applying the new rules retroactively. -- Niels.
Tragedy of the Commons; was Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Amazing how many people fail to trim quoted material, but at least they aren't top-posting. Sounds a lot like tragedy of the commons. To wit, the benefits of having the IP space is given to the owner, whereas the resources are finite, and the cost of a new allocation is borne by all (roughly proportional to the number of routers that need large routing tables). http://en.wikipedia.org/wiki/Tragedy_of_the_commons This is always a formula for disaster, but I'm surprised it has taken this long to metastasize into anything obvious. If search engine page rank was indifferent to number of netblocks, I don't think it would be an issue. And then maybe people would go back to making sites that people want to link to, instead of trying to game the engines for personal profit. Note the similarity to phone numbers, and how the telcos are being dragged kicking and screaming towards portable numbers by the FCC (I think). BTW: When I started using this Innernet thingy, you could buy /24's and they were portable, IIRC. - -- The whole point of the Internet is that different kinds of computers can interoperate. Every time you see a web site that only supports certain browsers or operating systems, they clearly don't get it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAdasPlSPhv5tocwRAlrqAJ4+XgYyZixIHoGMGOFhXDb0WL2BOQCfYw09 BWq6GRVlUZfBZbMN0QhGR2g= =Xn9r -END PGP SIGNATURE-
Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
On Fri, Sep 08, 2006 at 12:18:59PM -0700, David Schwartz wrote: ... Even if you assume that allocations made by ARIN are not property, it's hard to argue that pre-ARIN allocations are not. They're not subject to revocation and their grant wasn't conditioned on compliance with policies. ... I don't understand how you can assert this. Use of IP addresses follows the current policies, whatever they are. They have no grandfathered rights. Oops, here I am sounding like I know something about lawyering. ;-) I think we all need to either wait for the results, or if so moved, send in amicus curiae briefs. Not a lot else we can do, since few if any of us are lawyers, except pray that the judge is enlightened. -- Joe Yao --- This message is not an official statement of OSIS Center policies.
Re: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
Niels Bakker wrote: Address space policy has always been the result of a community consensus. Just because that consensus has shifted over the years does not mean that older entries in some database have suddenly developed into property. All it means is that the community is very friendly for not applying the new rules retroactively. The worst part of the filing was the fact that it asserted that by allowing the previous owner to retain ownership of the netblock, they were able to allocate addresses to customers and stay in business (as if they couldn't ask ARIN for more IP addresses). The purpose of the transfer, if I read the filing correctly, was to give Kremen the right to force all routing of the block to stop to the various people using it to extort money out of them (based on the wording in the filing, that apparently is money Kremen lost). Many of the suballocated users of the netblock would probably have been innocent bystanders that are using a cheap ISP. Of course, in reality, even with the transfer of the netblock, new allocations would have been requested and granted for networks requiring them. However, how many people would have been requested to pay or forced to immediately renumber? I've had to renumber a /18 when CW decided to drop customers here. If they had forced them unroutable (claiming ownership) while I was trying to renumber, we wouldn't be questioning the status of IP addresses as property. -Jack
Re: TCP receive window set to 0; DoS or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Shankland wrote: To address the DoS question, I don't see how this protocol violation enables a DoS attack. More likely, it's simply somebody's buggy TCP stack misbehaving. That somebody is unlikely to be Windows, MacOS, FreeBSD, or Linux. My money is on some flavor of $50 NAT/home router box. The part where it becomes a DoS is when they tie up all the listeners on a socket (e.g. apache), and nothing happens for several minutes until their connections time out. Whether intentional or not, it does have a negative effect. It's insidious in that it leaves no traces in the application logs; in particular, apache never logs anything because they never complete a transaction (it logs when they finish). - -- The whole point of the Internet is that different kinds of computers can interoperate. Every time you see a web site that only supports certain browsers or operating systems, they clearly don't get it. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFAeGPPlSPhv5tocwRAgSVAJ4qGEo/aR4CMaBcnsu+H6DyGpN7iACfcMAM FGvZWaAY2GYVSDLf37YUwbw= =RZ/F -END PGP SIGNATURE-
Data Center Wiring Standards
Heya folks, I hope this is on-topic. I read the charter, and it falls somewhere along the fuzzy border I think... Can anyone tell me the standard way to deal with patch panels, racks, and switches in a data center used for colocation? I've a sneaking suspicion that we're doing it in a fairly non-scalable way. (I am not responsible for the current method, and I think I'm glad to say that.) Strangely enough, I can find like NO resources on this. I've spent the better part of two hours looking. Right now, we have a rack filled with nothing but patch panels. We have some switches in another rack, and colocation customers scattered around other racks. When a new customer comes in, we run a long wire from their computer(s) and/or other device(s) to the patch panel. Then, from the appropriate block connectors on the back of the panel, we run another wire that terminates in a RJ-45 to plug into the switch. Sounds bonkers I think, doesn't it? My thoughts go like this: We put a patch panel in each rack. Each of these patch panels is permanently (more or less) wired to a patch panel in our main patch cabinet. So, essentially what you've got is a main patch cabinet with a patch panel that corresponds to a patch panel in each other cabinet. Making connection is cinchy and only requires 3-6 foot off-the-shelf cables. Does that sound more correct? I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. If you're running 802.1q trunks between a bunch of switches (no patch-panels needed), I can see that working too, I suppose. Any standards? Best practices? Suggestions? Resources, in the form of books, web pages, RFCs, or white papers? Thanks! Rick Kunkel
Re: TCP receive window set to 0; DoS or not?
Travis Hassloch [EMAIL PROTECTED] writes: The part where it becomes a DoS is when they tie up all the listeners on a socket (e.g. apache), and nothing happens for several minutes until their connections time out. Whether intentional or not, it does have a negative effect. Ah, that makes sense. I was assuming a deliberate attack, which is not actually implicit in the term DoS. A deliberate denial of service is not made easier by shrinking the window. But an implementation that advertises a 0 window in lieu of sending FIN or RST can certainly deny service inadvertently by tying up resources that should have been freed. Jim Shankland
Re: Data Center Wiring Standards
Hello Rick, Does that sound more correct? I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. If you're running 802.1q trunks between a bunch of switches (no patch-panels needed), I can see that working too, I suppose. Thats the best solution I think. Less cables, less work for precabling. Build 1gige or 2x1gige fiber uplinks. Perhaps wheels on the racks (then you can play google). You have check what switches you use in the racks and in the core. Number of vlans supported is the main goal. Perhaps some hp procurve in the racks and some real coreswitches in the backbone. When you reach 4096 vlans you could use vlan in vlan or mpls to grow more. Kind regards, Ingo Flaschberger
Re: Data Center Wiring Standards
[ Disclaimer - my experience is as someone who has setup lots of racks, dealt with a number of colocation facilities and cabling contractors. However, I haven't ever run a colo. ] On Fri, Sep 08, 2006 at 05:36:09PM -0700, Rick Kunkel wrote: Can anyone tell me the standard way to deal with patch panels, racks, and switches in a data center used for colocation? Right now, we have a rack filled with nothing but patch panels. We have some switches in another rack, and colocation customers scattered around other racks. When a new customer comes in, we run a long wire from their computer(s) and/or other device(s) to the patch panel. Then, from the appropriate block connectors on the back of the panel, we run another wire that terminates in a RJ-45 to plug into the switch. This way of doing things *can* be done neatly in some cases - it really depends on how you have things setup, your size, and what your customers' needs are. For large carrier neutral places like Equinix, Switch and Data, etc., where each customer usually has a small number of links coming into their cage, and things are pretty non-standard (i.e., customers have stuff other than a few ethernet cables going to their equipment), that's pretty much what they do - run a long cable through overhead cable trough or fiber tray, and terminate it in a patch panel in the customer's rack. My thoughts go like this: We put a patch panel in each rack. Each of these patch panels is permanently (more or less) wired to a patch panel in our main patch cabinet. So, essentially what you've got is a main patch cabinet with a patch panel that corresponds to a patch panel in each other cabinet. Making connection is cinchy and only requires 3-6 foot off-the-shelf cables. This is a better way to do it IF your customers have pretty standard needs. One facility I've worked at has 6 cables bundled together (not 25 pr cable, but similar - 6 cat5 or cat6 cables bundled within some sort of jacket), going into a patch panel. 25 pair or bundled cabling will make things neater, but usually costs more. Obviously, be SUPER anal retentive about labelling, testing, running cables, etc., or it's not worth doing at all. Come up with a scheme for labelling (in our office, it's a.b.c where a is the rack number, b is the rack position, and c is the port number) and stick to it. Get a labeller designed for cables if you don't already have one (a Brady, industrial P-Touch, Panduit, or something similar). Make sure there is a standard way for everything, and document / enforce the standard. Someone has to be the cable n**i (does that count as a Godwin?) or things will get messy fast. If you're doing a standard setup to each rack, hire someone to do it for you if you can afford it. It will be expensive, but probably worth it unless you're really good (and fast) at terminating cable. Either way, use (in the customer's rack) one of the patch panels that's modular, so you can put a different kind of connector in each slot. That gives you more flexibility later. In terms of whether patch panels / switches should be mixed in the same rack; opinions differ. It's of course difficult to deal with terminating patch panels when there are also big fat switches in the same rack. I've usually done a mix anyway, but for your application, it might be better to alternate, running the connections sideways. Invest in lots of cable management, the bigger, the better. I assume you already have cable management on these racks? I like the Panduit horizontal ones, and either the Panduit vertical ones, or the CPI MCS ones. If you're doing a new buildout, or can start a new set of racks, put extra space between them and do 10 wide cable management sections (or bigger). I can give you some suggestions in terms of vendors and cabling outfits, though most of the people I know of are in the Southern California area. I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. Ok, so if most of your customers have a full rack or half rack, I would suggest not putting a switch in each rack. In that case, you should charge them a port fee for each uplink, which should encourage them to use their own networking equipment. Now if most of your customers are using 1/2 rack, and aren't setting up their own network equipment, and you're managing everything for them, then you might want to put 1 48 port / 2 24 port switch in each individual rack, with two uplinks from some central aggregation switches to each. I really don't think you want more than 4-6 cables going to any one rack. Maybe you can clarify your typical customer setup? Any standards? Best practices? Suggestions? Resources, in the form of books, web pages, RFCs, or white papers? I think the best thing is just to look around as much as possible, and then see what works (and doesn't work)
Re: Data Center Wiring Standards
My thoughts go like this: We put a patch panel in each rack. Each of these patch panels is permanently (more or less) wired to a patch panel in our main patch cabinet. So, essentially what you've got is a main patch cabinet with a patch panel that corresponds to a patch panel in each other cabinet. Making connection is cinchy and only requires 3-6 foot off-the-shelf cables. Does that sound more correct? I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. If you're running 802.1q trunks between a bunch of switches (no patch-panels needed), I can see that working too, I suppose. Any standards? Best practices? Suggestions? Resources, in the form of books, web pages, RFCs, or white papers? Theres a series of ISO Standard for data cabling but nothing is yet set in stone around datacentres. I think the issue of Standards in datacentres was touched on here some time back? Ok, a quick google later, TIA-942 Telecommunications Infrastructure Standards for Data Centres covers off a lot of the details. Its pretty new and I don't know if its fully ratified yet? I quote... --8-- Based on existing cabling standards, TIA-942 covers cabling distances, pathways and labeling requirements, but also touches upon site selection, demarcation points, building security and electrical considerations. As the first standard to specifically address data centres, TIA-942 is a valuable tool for the proper design, installation and management of data centre cabling. The standard provides specifications for pathways, spaces and cabling media, recognizing copper cabling, multi-mode and single-mode fiber, and 75-ohm coaxial cable. However, much of TIA-942 deals with facility specifications. For each space within a data centre, the standard defines equipment planning and placement based on a hierarchical star topology for backbone and horizontal cabling. The standard also includes specifications for arranging equipment and racks in an alternating pattern to create ìhotî and ìcoldî aisles, which helps airflow and cooling efficiency. To assist in the design of a new data centre and to evaluate the reliability of an existing data centre, TIA-942 incorporates a tier classification, with each tier outlining guidelines for equipment, power, cooling and redundant components. These guide-lines are then tied to expectations for the data centre to maintain service without interruption. --8-- The source url for the above was http://www.networkcablingmag.ca/index.php?option=com_contenttask=viewid=432Itemid=2. You may like to see if you can track down a copy of the referenced standard. From my personal POV - You have a couple of options depending on your switching infrastructure and required cabling density - and bandwidth requirements. One way would be to have a decent switch at the top of each cabinet along with a Fibre tie to your core patch / switching cabinet. All devices in that rack feed into the local switch, which could be VLAN'd as required to cater for ILO or any other IP management requirements. Uplink would be a trunk of 1000SX, 1000LX, MultiLink Trunk combinations of same, or perhaps even 10Gig Fibre. The other option would be to preconfigure each rack with a coupla rackunits of fixed copper or fibre ties to a core cabinet and just patch things around as you need to. Useful if you are in a situation where bringing as much as possible direct into your core switch is appropriate, and cheaper from a network hardware pov - if not from a structure cabling pov. Good luck. I know what a prick it is to inhereit someone elses shoddy cable work - I find myself accumulating lots of after-hours overtime, involving essentially ripping out everything and putting it all back _tidily_ - and hoping that I don't overlook some un-documented 'feature'... Mark.
Re: Data Center Wiring Standards
Rick Kunkel wrote: Heya folks, I hope this is on-topic. I read the charter, and it falls somewhere along the fuzzy border I think... Can anyone tell me the standard way to deal with patch panels, racks, and switches in a data center used for colocation? I've a sneaking suspicion that we're doing it in a fairly non-scalable way. (I am not responsible for the current method, and I think I'm glad to say that.) Strangely enough, I can find like NO resources on this. I've spent the better part of two hours looking. Right now, we have a rack filled with nothing but patch panels. We have some switches in another rack, and colocation customers scattered around other racks. When a new customer comes in, we run a long wire from their computer(s) and/or other device(s) to the patch panel. Then, from the appropriate block connectors on the back of the panel, we run another wire that terminates in a RJ-45 to plug into the switch. Sounds bonkers I think, doesn't it? My thoughts go like this: We put a patch panel in each rack. Each of these patch panels is permanently (more or less) wired to a patch panel in our main patch cabinet. So, essentially what you've got is a main patch cabinet with a patch panel that corresponds to a patch panel in each other cabinet. Making connection is cinchy and only requires 3-6 foot off-the-shelf cables. Does that sound more correct? I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. If you're running 802.1q trunks between a bunch of switches (no patch-panels needed), I can see that working too, I suppose. Any standards? Best practices? Suggestions? Resources, in the form of books, web pages, RFCs, or white papers? Thanks! Rick Kunkel Ideally from each core router would go to a two distribution-a switch (Cat 4900 or something similar), from both dist-a switch then go to two bigger distribution (dist-b) switches (cat 6500 etc) Then from each 6500 go to there own patch panels. Then from the two patch panels run a cables to access level (2900's etc) switches in each rack / shelf. This way you have full redundancy in each shelf for your co-located / dedicated customers. My .02 cents -Bill Sehmel -- Bill Sehmel - [EMAIL PROTECTED] -- 1-703-288-3081 Systems Administrator, HopOne Internet Corp. DCA2 NOC Bandwidth full range of carrier/web host colo + networking services: http://www.hopone.netASN 14361
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Chris, The first item they need is a Network Engineer. You do not have actual IP addresses for servers you have DNS entries. In my non legal opinion the individual filling suit is out money because of there lack of understanding of DNS entries versus IP addresses. You can resolve thousands of web sites to one IP address if you want to or get another block of IP addresses from ARIN and resolve the other addresses to the newly assigned addresses. It appears from the filing that they do not understand how DNS works since with an appropriately designed zone structure there would be no issues. This lawsuit is about the stupidity of the plaintiff and not about IP address management. If any organization owns the IP addresses it is the registries and they only lease them out to organizations for a nominal fee to provide order and security for the Internet. ICANN for other issues and ARIN for addresses bend over backwards to have large ISPs and multinationals go through the same short process as any other requester of IP addresses and have only one policy. And if you have ever attended an ARIN meeting point out of the 100 to several hundred high opinionated individuals who attend which ones control it for their own economic benefit. Send this legal team a copy of Comer's books on TCP/IP and Cricket Liu's book on DNS and BIND. I take the Comer books back they would not understand them so give them Uyless Black's books they are more clueless friendly. John (ISDN) Lee Chris Jester wrote: I am looking for anyone who has input on possibly the largest case regarding internet numbering ever. This lawsuit may change the way IP's are governed and adminstered. Comments on or off list please. Anyone have experiences like are said in the lawsuit? I would love to know if this is true or not. Anyone with negative ARIN experiences that relate to the lawsuit, please let me know, thanks! For thos interested, you may read this lawsuit here: http://72.14.209.104/search?q=cache:44uxmnEmJVkJ:www.internetgovernance.org/pdf/kremen.pdf+Kremen+Vs+ARINhl=engl=usct=clnkcd=1 Or google for Kremen VS Arin Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506 Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506 NOTICE - This e-mail and any files transmitted with it are confidential and are only for the use of the person to whom they are addressed. If you are not the intended recipient you have received this e-mail in error. Any use, dissemination, forwarding, printing, copying or dealing in any way whatsoever with this e-mail is strictly prohibited. If you have received this e-mail in error, please reply immediately by way of advice to us. It is the addressee/recipient duty to virus scan and otherwise test the information provided before loading onto any computer system. Suavemente, INC. does not warrant that the information is free of a virus or any other defect or error. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Suavemente, INC.
Re: Data Center Wiring Standards
Rick, The organization and standards you are looking for are: BICSI - http://www.bicsi.org/ and TIA/EIA 568 et al for structured cabling design for low voltage distribution. The BICSI organization has training and certification for RCDD Registered Communications Distribution Designer A BICSI article that is on there web site about data center design is http://www.bicsi.org/Content/Files/PDF/link2006/Kacperski.pdf. TIA/EIA 568(ab) how ever many they are up to discuss structured cabling design for UTP/STP/fiber/coax including patch cables single and multi pair UTP/STP/fiber patch panels, HVAC control, fire system control and security systems. John (ISDN) Lee Rick Kunkel wrote: Heya folks, I hope this is on-topic. I read the charter, and it falls somewhere along the fuzzy border I think... Can anyone tell me the standard way to deal with patch panels, racks, and switches in a data center used for colocation? I've a sneaking suspicion that we're doing it in a fairly non-scalable way. (I am not responsible for the current method, and I think I'm glad to say that.) Strangely enough, I can find like NO resources on this. I've spent the better part of two hours looking. Right now, we have a rack filled with nothing but patch panels. We have some switches in another rack, and colocation customers scattered around other racks. When a new customer comes in, we run a long wire from their computer(s) and/or other device(s) to the patch panel. Then, from the appropriate block connectors on the back of the panel, we run another wire that terminates in a RJ-45 to plug into the switch. Sounds bonkers I think, doesn't it? My thoughts go like this: We put a patch panel in each rack. Each of these patch panels is permanently (more or less) wired to a patch panel in our main patch cabinet. So, essentially what you've got is a main patch cabinet with a patch panel that corresponds to a patch panel in each other cabinet. Making connection is cinchy and only requires 3-6 foot off-the-shelf cables. Does that sound more correct? I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. If you're running 802.1q trunks between a bunch of switches (no patch-panels needed), I can see that working too, I suppose. Any standards? Best practices? Suggestions? Resources, in the form of books, web pages, RFCs, or white papers? Thanks! Rick Kunkel
Re: Data Center Wiring Standards
I would add to the recommendations already stated by Mark and John the folllowing: Depending on the dimensions of the colo in question and the length of the cabling runs you plan to install, take note of the distance limitations of STP for DS1 signals and the in-house coaxial connections for DS3 signals and higher, which are (were) governed by ANSI/Bellcore, the last time I looked. Fiber, likewise, must be coordinated with network element interfaces (GBICs, ST, etc.) and here again distance is a major consideration. The latter may become an issue in large structures, or in the event that you plan to run media between buildings, or if you plan to interconnect with service providers at the f-o level (Layer1). For your optical media and connection hardware (patch panels, raceways, etc.), have a long hard talk with at least two reputable fiber optic cable suppliers (e.g., Corning, CommScope, Sumitomo, etc.) and develop an understanding about the limitations and advantages of the various s-m and m-m options you have available to you, per the types of solutions you need to implement and the distances they dictate. Incoming fiber from the street (dark fiber providers, included) will be single-mode, primarily, but the preponderance of your in-house cabling between switches, routers and servers, if fiber distances are indicated, will be multi-mode, requiring a different patch bay selection. Where distances permit (100 meter channels) UTP should suffice for Ethernet speeds up to 10Gb/sec now, with 10Gb/sec (10GBASE-T) ratified only recently (I'm quite certain), but I suggest reading the following article from Cabling Installation Maintenance Magazine, just the same. http://tinyurl.com/mrack Note, Cat5e and vanilla Cat6 will not suffice (perhaps a Cat6A will, not sure at this stage, but do your homework before purchasing anyone's Cat7) for 10GbE (it may work, but your hardware vendors will not honor warranties when problems arise), so be prepared to make some long range planning decisions in coming to terms with a cabling plant that's going to last you a while. HTH. Frank A. Coluccio DTI Consulting Inc. 212-587-8150 Office 347-526-6788 Mobile On Fri Sep 8 23:31 , John L Lee sent: Rick, The organization and standards you are looking for are: BICSI - http://www.bicsi.org/ and TIA/EIA 568 et al for structured cabling design for low voltage distribution. The BICSI organization has training and certification for RCDD Registered Communications Distribution Designer A BICSI article that is on there web site about data center design is http://www.bicsi.org/Content/Files/PDF/link2006/Kacperski.pdf. TIA/EIA 568(ab) how ever many they are up to discuss structured cabling design for UTP/STP/fiber/coax including patch cables single and multi pair UTP/STP/fiber patch panels, HVAC control, fire system control and security systems. John (ISDN) Lee Rick Kunkel wrote: Heya folks, I hope this is on-topic. I read the charter, and it falls somewhere along the fuzzy border I think... Can anyone tell me the standard way to deal with patch panels, racks, and switches in a data center used for colocation? I've a sneaking suspicion that we're doing it in a fairly non-scalable way. (I am not responsible for the current method, and I think I'm glad to say that.) Strangely enough, I can find like NO resources on this. I've spent the better part of two hours looking. Right now, we have a rack filled with nothing but patch panels. We have some switches in another rack, and colocation customers scattered around other racks. When a new customer comes in, we run a long wire from their computer(s) and/or other device(s) to the patch panel. Then, from the appropriate block connectors on the back of the panel, we run another wire that terminates in a RJ-45 to plug into the switch. Sounds bonkers I think, doesn't it? My thoughts go like this: We put a patch panel in each rack. Each of these patch panels is permanently (more or less) wired to a patch panel in our main patch cabinet. So, essentially what you've got is a main patch cabinet with a patch panel that corresponds to a patch panel in each other cabinet. Making connection is cinchy and only requires 3-6 foot off-the-shelf cables. Does that sound more correct? I talked to someone else in the office here, and they believe that they've seen it done with a switch in each cabinet, although they couldn't remember is there was a patch panel as well. If you're running 802.1q trunks between a bunch of switches (no patch-panels needed), I can see that working too, I suppose. Any standards? Best practices? Suggestions? Resources, in the form of books, web pages, RFCs, or white papers? Thanks! Rick Kunkel
