Re: Is there such a thing as a 10GBase-T SFP+ transciever
What I want to see is reasonably priced 40G single mode transceivers. I have no idea why 40G and now 100G wasn't rolled out with single mode as the preference. The argument that there's a large multimode install base doesn't hold water. For one thing, you're using enormous amounts of MM fiber to get at best 1/4 of the ports than you previously had. The best case is that you could get 12 ports where you used to have 48, but that's messy. The second issue is cost, if you're running and distance, you've got to go to OM4, because MM fiber has very limited range at 10G (you're multiplexing 10G links), and OM4 is insanely expensive. Single Mode on the other hand is 'cheap' in comparison. One pair of SM fiber will handle every speed from 10M to 100G, and over much longer distances than MM, no matter what grade. Unfortunately, since the manufacturers haven't seen fit to push the SM, the optics are extremely expensive, so we're stuck with 4-12 times the amount of installed fiber than we really need. Grumble. On Jan 30, 2014, at 6:25 PM, Chris Balmain ch...@team.dcsi.net.au wrote: You may wish to consider twinax for short distance 10G over copper with SFP+ at both ends http://en.wikipedia.org/wiki/Twinaxial_cabling#SFP.2B_Direct-Attach_Copper_.2810GSFP.2BCu.29 Typically marketed as direct-attach (you can't remove the cables from the transceivers, it's all integrated) On 31/01/14 12:26, james jones wrote: I would like to know if anyone has seen one of these? If so where? Also if they don't exist why? It would seem to me that it would make it a lot easier to play mix and match with fiber in the DC if they did. Would be so hard to make the 1G SFPs faster (trying to be funny here not arrogant). -James
Re: Updated ARIN allocation information
On Jan 30, 2014, at 3:58 PM, Mark Andrews ma...@isc.org wrote: In message 384bf687-ad8a-4919-9eab-723a09854...@puck.nether.net, Jared Mauch writes: On Jan 30, 2014, at 12:17 AM, Mark Andrews ma...@isc.org wrote: Or you could just accept that there needs to be more routing slots as the number of businesses on the net increases. I can see some interesting anti-cartel law suits happening if ISP's refuse to accept /28's from this block. i suspect it will be more sean doran style 'pay me for your slot'. A /8 slot costs as much as a /28 slot to hold process etc. A routing slot is a routing slot. The *only* reason this isn't a legal problems at the moment is people can still get /24s. The moment /24's aren't readily available and they are forced into using this range anyone filtering on /24 in this range is leaving themselves open to lawsuits. On what basis? How do you have the right to force me to carry your route on my network? Especially in light of the recent strike-down of the net neutrality rules? Now as this range is allocated for transition to IPv6 a defence for edge networks may be we can reach all their services over IPv6 but that doesn't work for transit providers. Eyeball networks would need to ensure that all their customers had access to IPv6 and even that may not be enough. Please point to the law which requires a transit provider to provide transit to every tiny corner of every internet. Please do so for all nations where this may be an issue. Owen
While on the subject of IRR and route objects
IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse. After a few hours of research, it seems that its dead since 2009 :(. There is some effort at http://irrtoolset.isc.org to reboot development, its pretty dead since 2012-07-31. Beside home made solutions, there seems to be no commercial package. Any lead will be appreciated. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443
Re: While on the subject of IRR and route objects
On Fri, Jan 31, 2014 at 08:58:06AM -0500, Alain Hebert wrote: IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse. After a few hours of research, it seems that its dead since 2009 :(. There is some effort at http://irrtoolset.isc.org to reboot development, its pretty dead since 2012-07-31. Beside home made solutions, there seems to be no commercial package. Any lead will be appreciated. I really like bgpq3 for prefix-filter generation. http://github.com/snar/bgpq3 http://snar.spb.ru/prog/bgpq3/ Kind regards, Job pgp9YkHYgor0y.pgp Description: PGP signature
Re: While on the subject of IRR and route objects
+1 Easiest to use by far. Only thing I see as lacking for easy adoption is canned solution for managing the push to the routers. On 1/31/2014 9:04 AM, Job Snijders wrote: On Fri, Jan 31, 2014 at 08:58:06AM -0500, Alain Hebert wrote: IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse. After a few hours of research, it seems that its dead since 2009 :(. There is some effort at http://irrtoolset.isc.org to reboot development, its pretty dead since 2012-07-31. Beside home made solutions, there seems to be no commercial package. Any lead will be appreciated. I really like bgpq3 for prefix-filter generation. http://github.com/snar/bgpq3 http://snar.spb.ru/prog/bgpq3/ Kind regards, Job
Re: Fiber Bypass Switch
There's also for example http://www.silicom-usa.com/Intelligent_Bypass_Switches/IBS10G-Intelligent_10G_Bypass_Switch_33 //jb 2014-01-27 Keyser, Philip pkey...@fibertech.com: Does anyone have any recommendations for a fiber bypass switch? I am looking for something capable of 10G that when there is a power hit will fail over to route traffic out the network ports and away from that site's with the customer handoff. Thanks, Phil Keyser
Re: While on the subject of IRR and route objects
On 31/01/2014 13:58, Alain Hebert wrote: IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse. of direct relevance to this: https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html tl;dr: rpsl itself is a mess = no point in fixing irrtoolset There is some work in progress to try to create a new policy description language which would be a replacement for rpsl. Very early stages so far, though. Nick
Re: Updated ARIN allocation information
On Jan 30, 2014, at 10:20 PM, Mark Andrews ma...@isc.org wrote: I figure there will be similar problem for other business in other countries and they will fight a similar battles. Eventually the regulators will step in because it is bad for small businesses to be shut out of the Internet. Mark - ISPS consciously breaking Internet services are bound to attract regulatory attention, but that does not necessarily mean that in the end there will be regulatory action. In the case of peering and route acceptance, it is fairly easy to show that there is a finite amount of routes that a given ISP can accept, and each of these routes has different value (i.e. some have large traffic flows, some are peer traffic engineering, some of required backup routes for shared multihomed corporate customers, etc.) The result is not simple to regulate, because you can't just mandate accept all routes offered - some ISPs are already trimming what they accept to accommodate their particular flavor of routing hardware. For last few decades, we've basically been relying on the IP allocation/assignment policies and their minimum block sizes as a proxy for the default worth accepting metric, but this may not prevail once there is serious pressure to fragment blocks to obtain better utilization. It would be nice if there was a way to fairly settle up for the imputed cost of adding a given route to the routing table, as this would provide some proportionate backpressure on growth, would create incentives for deaggregate cleanup, etc. We don't have such a system, so it falls to each ISP to decide what route is worth accepting based on type and the offering peer's business relationship... FYI, /John Disclaimer: My views alone. Note - I haven't had enable on any backbone routers in this _century_, so feel free to discount/discard if so desired. ;-)
Re: While on the subject of IRR and route objects
On 01/31/14 10:02, Nick Hilliard wrote: On 31/01/2014 13:58, Alain Hebert wrote: IRRToolset 5.0.1 (rtconfig really) finally gave out on a pretty messy RPSL parse. of direct relevance to this: https://lists.isc.org/pipermail/irrtoolset/2011-April/000736.html tl;dr: rpsl itself is a mess = no point in fixing irrtoolset There is some work in progress to try to create a new policy description language which would be a replacement for rpsl. Very early stages so far, though. Nick Well, Thanks to all. Job: bgpq3 works great the as-set that was borking rtlookup generate a ~183k long prefix list =D. ML: as for auto-deploying / auto-push to routers... I still prefer to do that manually myself. Nick: Yes, I saw those tidbits while looking for a replacement. If you're talking about RPSLng, it does not seems to gain any traction. From what I could see... - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443
Re: While on the subject of IRR and route objects
On Fri, Jan 31, 2014 at 11:32:17AM -0500, Alain Hebert wrote: bgpq3 works great the as-set that was borking rtlookup generate a ~183k long prefix list =D. I recommend using it like this, to enable aggregation where possible: bgpq3 -A Kind regards, Job pgpjISSQ47YFj.pgp Description: PGP signature
Re: While on the subject of IRR and route objects
Yes, its the first thing I tried. Iti's still ~82k =D The as-set included some of his peering as export too. We're both looking into it. - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 01/31/14 11:38, Job Snijders wrote: On Fri, Jan 31, 2014 at 11:32:17AM -0500, Alain Hebert wrote: bgpq3 works great the as-set that was borking rtlookup generate a ~183k long prefix list =D. I recommend using it like this, to enable aggregation where possible: bgpq3 -A Kind regards, Job
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. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 01 Feb, 2014 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 480599 Prefixes after maximum aggregation: 191158 Deaggregation factor: 2.51 Unique aggregates announced to Internet: 238143 Total ASes present in the Internet Routing Table: 46049 Prefixes per ASN: 10.44 Origin-only ASes present in the Internet Routing Table: 35565 Origin ASes announcing only one prefix: 16380 Transit ASes present in the Internet Routing Table:6011 Transit-only ASes present in the Internet Routing Table:168 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 53 Max AS path prepend of ASN ( 50404) 51 Prefixes from unregistered ASNs in the Routing Table: 1925 Unregistered ASNs in the Routing Table: 498 Number of 32-bit ASNs allocated by the RIRs: 5868 Number of 32-bit ASNs visible in the Routing Table:4473 Prefixes from 32-bit ASNs in the Routing Table: 14209 Number of bogon 32-bit ASNs visible in the Routing Table:12 Special use prefixes present in the Routing Table: 12 Prefixes being announced from unallocated address space:451 Number of addresses announced to Internet: 2666406948 Equivalent to 158 /8s, 238 /16s and 36 /24s Percentage of available address space announced: 72.0 Percentage of allocated address space announced: 72.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 95.7 Total number of prefixes smaller than registry allocations: 167446 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 114261 Total APNIC prefixes after maximum aggregation: 34379 APNIC Deaggregation factor:3.32 Prefixes being announced from the APNIC address blocks: 116741 Unique aggregates announced from the APNIC address blocks:49004 APNIC Region origin ASes present in the Internet Routing Table:4887 APNIC Prefixes per ASN: 23.89 APNIC Region origin ASes announcing only one prefix: 1222 APNIC Region transit ASes present in the Internet Routing Table:843 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 28 Number of APNIC region 32-bit ASNs visible in the Routing Table:817 Number of APNIC addresses announced to Internet: 730362496 Equivalent to 43 /8s, 136 /16s and 114 /24s Percentage of available APNIC address space announced: 85.4 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-63999, 131072-133631 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:164828 Total ARIN prefixes after maximum aggregation:82581 ARIN Deaggregation factor: 2.00 Prefixes being announced from the ARIN address blocks: 166122 Unique aggregates announced from the ARIN address blocks: 77099 ARIN Region origin ASes present in the Internet Routing Table:16105 ARIN
Level3 - Las Vegas - issues?
Are there anyone from Level3 here, who can tell me if there are issues with Level3 in Las Vegas area? We're hosted out of the Switch SuperNAP, and we're having high packet loss on two different Internet circuits. And at 9:30 AM PST we had no connectivity to all our 70+ remote locations spread all over US on different carriers, from our VPN hub hosted on Level3 Any feedback is much appreciated, thanks! -Petter Petter Bruland | Network Engineer Allegiant Travel Company
Question on DHCPv6 address assignment
Folks, I'm wondering about the following two aspects of different DHCPv6 implementations out there: 1) What's the pattern with which addresses are generated/assigned? Are they sequential (fc00::1, fc00::2, etc.)? Random? Something else? 2) What about their stability? Is there any intent/mechanism for them to be as stable as possible? Or is it usual for hosts to get a new address for each lease? P.S.: I understand this is likely to vary from one implementation to another... so please describe which implementation/version you're referring to. Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Ad Hoc BCOP Committee - Call for Volunteers
Hail NANOGers! Per approval of the NANOG Board in February 2013, a community effort to develop a NANOG sponsored regional BCOP effort was engaged. NANOG BCOP Tracks and updates were provided at RIPE, ARIN, NANOG 57, 58, and 59. In November of 2013, sufficient interest and momentum in the NANOG BCOP effort emerged. On November 21, 2013, the NANOG Board approved the appointment of an Ad Hoc Committee Chair who would report to the Board and direct the efforts of NANOG-BCOP. I have agreed to serve as Chair and am now seeking volunteers to continue with the important work of the committee. Please consider volunteering your time and effort in support of this important NANOG activity! To help guide you, please review the following committee expectations: Strategies and Goals: * Support an open, transparent, and bottom-up/grassroots process for the creation of current and living practical network operation documentation * Facilitate the development of mutually rewarding documents and guides * Maintain the sense of community and accessibility in BCOP materials * Develop and deploy a portfolio of guides that meet the needs of the broad range of NANOG operators Deliverables: * Responsible for recruiting a minimum of 1 shepard per calendar year. * Responsible for recruiting a minimum of 1 author per calendar year. * Required to attend at least 75% of all scheduled committee calls. * Expected to attend 66% of all NANOG meetings over the course of your two-year term. * A BCOP Ad Hoc Committee Member is expected to volunteer up to 10 hours in the 12 weeks Leading into a NANOG meeting and an additional 15 hours all year round Also see the website at http://bcop.nanog.org for more information. If you are interested in participating, please send your short bio to Betty Burke, NANOG Executive Director, be...@nanog.org. Betty can also answer any and all questions you may have. Betty or I will be sure to follow-up with each volunteer and get our important work underway as soon as possible. Cheers, ~Chris -- @ChrisGrundemann http://chrisgrundemann.com
Re: Question on DHCPv6 address assignment
Hi, Bill, On 01/31/2014 05:59 PM, bmann...@vacation.karoshi.com wrote: i in my bespoke version: Is there any reference I could use for it? 1- psudo-random within a /32 space 2- not stable, unless coded to a fixed address Regarding 2), do you mean they are only stable if you ahve a MAC-IPv6 mapping database, or something else? Cheers, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
Re: Updated ARIN allocation information
On Fri, Jan 31, 2014 at 11:09:43AM -0500, John Curran wrote: better utilization. It would be nice if there was a way to fairly settle up for the imputed cost of adding a given route to the routing table, as this would provide some proportionate backpressure on growth, would create incentives for deaggregate cleanup, etc. We don't have such a system, so it falls to each ISP to decide what route is worth accepting based on type and the offering peer's business relationship... I almost hesitate to mention this, just in case I put ideas into some beancounter's head, but it seems to me that the cost model of carrying packets isn't that different to carrying routes. In both cases, practically everyone is acting as a middleman, and money flows hither and yon and (presumably) balances out in the end, with everyone having their costs covered with a little left over for the shareholders. Imagine one of the big players saying, we're going to charge you $X per route you send to us (just like transit agreements that state, we will charge you $X/GB of traffic), or your contract allows you to send us N routes (just like, your contract allows you to send us N Gb of traffic). About 15 minutes later everyone else would start doing it, to recoup the costs of sending routes to that provider. Peering would be considered not only if the volume of traffic was mutually advantageous, but also if the routes exchanged were mutually advantageous. - Matt -- [the average computer user] has been served so poorly that he expects his system to crash all the time, and we witness a massive worldwide distribution of bug-ridden software for which we should be deeply ashamed. -- Edsger Dijkstra
Re: looking for good AU dedicated server providers..
I've used shared hosting from Rimuhosting (www.rimuhosting.com) for years. They have dedicated servers in Brisbane. Looks like they are colo'ed with Oz Servers. sam
The Cidr Report
This report has been generated at Fri Jan 31 21:13:37 2014 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org/2.0 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
24-01-14490385 274907
25-01-14490771 275139
26-01-14491167 275204
27-01-14491133 275651
28-01-14491297 275851
29-01-14490853 275986
30-01-14491565 275149
31-01-14491578 275863
AS Summary
46226 Number of ASes in routing system
18963 Number of ASes announcing only one prefix
4461 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
119428352 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
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').
--- 31Jan14 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 491735 275851 21588443.9% All ASes
AS28573 3341 80 326197.6% NET Serviços de Comunicação
S.A.
AS6389 3026 56 297098.1% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS7029 4461 1704 275761.8% WINDSTREAM - Windstream
Communications Inc
AS17974 2741 184 255793.3% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS22773 2328 207 212191.1% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS4766 2955 959 199667.5% KIXS-AS-KR Korea Telecom
AS1785 2156 406 175081.2% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS18881 1837 90 174795.1% Global Village Telecom
AS36998 1810 97 171394.6% SDN-MOBITEL
AS10620 2712 1122 159058.6% Telmex Colombia S.A.
AS18566 2047 565 148272.4% MEGAPATH5-US - MegaPath
Corporation
AS4323 2944 1515 142948.5% TWTC - tw telecom holdings,
inc.
AS7303 1745 415 133076.2% Telecom Argentina S.A.
AS4755 1814 598 121667.0% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7552 1260 153 110787.9% VIETEL-AS-AP Viettel
Corporation
AS7545 2162 1083 107949.9% TPG-INTERNET-AP TPG Telecom
Limited
AS22561 1261 227 103482.0% AS22561 - CenturyTel Internet
Holdings, Inc.
AS9829 1590 680 91057.2% BSNL-NIB National Internet
Backbone
AS18101 991 185 80681.3% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS35908 903 101 80288.8% VPLSNET - Krypt Technologies
AS4808 1168 393 77566.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS701 1499 769 73048.7% UUNET - MCI Communications
Services, Inc. d/b/a Verizon
Business
AS24560 1094 371 72366.1% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS8151 1384 666 71851.9% Uninet S.A. de C.V.
AS6983 1296 581 71555.2% ITCDELTA - ITC^Deltacom
AS7738 847 148 69982.5% Telemar Norte Leste S.A.
AS4788 930 237 69374.5% TMNET-AS-AP TM Net, Internet
Service Provider
AS855746 57 68992.4% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS13977 807 145 66282.0% CTELCO - FAIRPOINT
BGP Update Report
BGP Update Report Interval: 23-Jan-14 -to- 30-Jan-14 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS12301 41185 2.0% 352.0 -- INVITEL Invitel Tavkozlesi Zrt. 2 - AS840231749 1.5% 16.3 -- CORBINA-AS OJSC Vimpelcom 3 - AS982930959 1.5% 19.5 -- BSNL-NIB National Internet Backbone 4 - AS35181 29116 1.4%2426.3 -- PWC Autonomous System Number for Public WareHouse Company 5 - AS15467 25622 1.2% 915.1 -- ENTERNET-LIBERCOM-AS Enternet 2001 Ltd., Hungary 6 - AS13118 23046 1.1% 523.8 -- ASN-YARTELECOM OJSC Rostelecom 7 - AS477517722 0.9% 305.6 -- GLOBE-TELECOM-AS Globe Telecoms 8 - AS671315942 0.8% 27.0 -- IAM-AS 9 - AS24810 15918 0.8% 306.1 -- TELESET-KAZAN OJSC Rostelecom 10 - AS59217 14990 0.7% 14990.0 -- AZONNELIMITED-AS-AP Azonne Limited 11 - AS39649 14590 0.7% 70.8 -- VIALI-AS SC Viali Computers SRL 12 - AS28573 14465 0.7% 11.2 -- NET Serviços de Comunicação S.A. 13 - AS62904 14037 0.7% 159.5 -- SERVERHUB-DALLAS - Eonix Corporation 14 - AS41691 12726 0.6% 353.5 -- SUMTEL-AS-RIPE Summa Telecom LLC 15 - AS647 12172 0.6% 105.8 -- DNIC-ASBLK-00616-00665 - DoD Network Information Center 16 - AS11976 11632 0.6% 323.1 -- FIDN - Fidelity Communication International Inc. 17 - AS47331 11468 0.6% 4.7 -- TTNET TTNet A.S. 18 - AS40994 10695 0.5% 62.5 -- SKYLINE-AS Internet Network Vision SRL 19 - AS27738 10245 0.5% 17.8 -- Ecuadortelecom S.A. 20 - AS25780 10180 0.5% 212.1 -- HUGESERVER-NETWORKS - HugeServer Networks, LLC TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS59217 14990 0.7% 14990.0 -- AZONNELIMITED-AS-AP Azonne Limited 2 - AS129227084 0.3%7084.0 -- MULTITRADE-AS CEDACRI S.P.A. 3 - AS7202 8661 0.4%4330.5 -- FAMU - Florida A M University 4 - AS194063513 0.2%3513.0 -- TWRS-MA - Towerstream I, Inc. 5 - AS165613292 0.2%3292.0 -- ARIBANETWORK Ariba Inc. Autonomous System 6 - AS544658581 0.4%2860.3 -- QPM-AS-1 - QuickPlay Media Inc. 7 - AS35181 29116 1.4%2426.3 -- PWC Autonomous System Number for Public WareHouse Company 8 - AS304374060 0.2%2030.0 -- GE-MS003 - General Electric Company 9 - AS322445785 0.3%1928.3 -- LIQUID-WEB-INC - Liquid Web, Inc. 10 - AS624311910 0.1%1910.0 -- NCSC-IE-AS National Cyber Security Centre 11 - AS6629 8979 0.4%1795.8 -- NOAA-AS - NOAA 12 - AS142879402 0.5%1567.0 -- TRIAD-TELECOM - Triad Telecom, Inc. 13 - AS173003128 0.1%1564.0 -- 14 - AS350511484 0.1%1484.0 -- QWERTYNET-AS QwertyNet Ltd. 15 - AS443021444 0.1%1444.0 -- IECHU-AS NETregator Kft. 16 - AS575422010 0.1%1005.0 -- OOOP-AS LLC Neonovaya Company 17 - AS62751 942 0.1% 942.0 -- HSAUWC-AS - HSA-UWC 18 - AS15467 25622 1.2% 915.1 -- ENTERNET-LIBERCOM-AS Enternet 2001 Ltd., Hungary 19 - AS24959 894 0.0% 894.0 -- LINJEGODS-AS Schenker AS 20 - AS447894362 0.2% 872.4 -- HIRSAT-AS HIR-SAT 2000 Szolgaltato es Kereskedelmi Kft. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.239.28.0/2423060 1.1% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 2 - 109.161.64.0/20 22660 1.0% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 3 - 103.243.164.0/22 14990 0.7% AS59217 -- AZONNELIMITED-AS-AP Azonne Limited 4 - 192.58.232.0/248970 0.4% AS6629 -- NOAA-AS - NOAA 5 - 222.127.0.0/24 8768 0.4% AS4775 -- GLOBE-TELECOM-AS Globe Telecoms 7 - 206.152.15.0/248579 0.4% AS54465 -- QPM-AS-1 - QuickPlay Media Inc. 8 - 79.181.80.0/24 7183 0.3% AS8551 -- BEZEQ-INTERNATIONAL-AS Bezeqint Internet Backbone 9 - 89.221.206.0/247085 0.3% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 10 - 194.105.61.0/247084 0.3% AS12922 -- MULTITRADE-AS CEDACRI S.P.A. 11 - 216.109.107.0/24 6584 0.3% AS11486 -- COLO-PREM-VZB - Verizon Online LLC AS16561 -- ARIBANETWORK Ariba Inc. Autonomous System 12 - 67.210.190.0/236552 0.3% AS11976 -- FIDN - Fidelity Communication International Inc. 13 - 85.239.24.0/24 6010 0.3% AS35181 -- PWC Autonomous System Number for Public WareHouse Company 14 - 205.247.12.0/245521 0.2% AS6459 -- TRANSBEAM - I-2000, Inc. 15 - 85.249.160.0/205357 0.2% AS41691 -- SUMTEL-AS-RIPE Summa Telecom LLC 16 - 67.210.188.0/234928 0.2%
Re: Updated ARIN allocation information
In message 0a78151e-0fdb-4276-9b14-6a88e2941...@istaff.org, John Curran writes: On Jan 30, 2014, at 10:20 PM, Mark Andrews ma...@isc.org wrote: I figure there will be similar problem for other business in other countries and they will fight a similar battles. Eventually the regulators will step in because it is bad for small businesses to be shut out of the Internet. Mark - ISPS consciously breaking Internet services are bound to attract regulatory attention, but that does not necessarily mean that in the end there will be regulatory action. In the case of peering and route acceptance, it is fairly easy to show that there is a finite amount of routes that a given ISP can accept, and each of these routes has different value (i.e. some have large traffic flows, some are peer traffic engineering, some of required backup routes for shared multihomed corporate customers, etc.) The result is not simple to regulate, because you can't just mandate accept all routes offered - some ISPs are already trimming what they accept to accommodate their particular flavor of routing hardware. For last few decades, we've basically been relying on the IP allocation/assignment policies and their minimum block sizes as a proxy for the default worth accepting metric, but this may not prevail once there is serious pressure to fragment blocks to obtain better utilization. It would be nice if there was a way to fairly settle up for the imputed cost of adding a given route to the routing table, as this would provide some proportionate backpressure on growth, would create incentives for deaggregate cleanup, etc. We don't have such a system, so it falls to each ISP to decide what route is worth accepting based on type and the offering peer's business relationship... FYI, /John I understand this but this block changes the status quo. It is a policy changer. AFAIK ARIN hasn't done allocations to the /28 level like this in the past. This is all new territory. Concentrating the allocation is a good thing as it allow selective extentions of the filter lengths. This is about a potential 1.6% global growth of routes. It's not 1500% potential growth that a global /24 - /28 would give. Disclaimer: My views alone. Note - I haven't had enable on any backbone routers in this _century_, so feel free to discount/discard if so desired. ;-) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Updated ARIN allocation information
On Fri, Jan 31, 2014 at 4:29 PM, Matt Palmer mpal...@hezmatt.org wrote: Imagine one of the big players saying, we're going to charge you $X per route you send to us (just like transit agreements that state, we will charge you $X/GB of traffic), or your contract allows you to send us N routes (just like, your contract allows you to send us N Gb of traffic). About 15 minutes later everyone else would start doing it, to recoup the costs of sending routes to that provider. Peering would be considered not only if the volume of traffic was mutually advantageous, but also if the routes exchanged were mutually advantageous. Hi Matt, It doesn't work. Here's why not: First, there's an error in your bytes model. You express it as your contract allows you to send us N Gb of traffic but that's not accurate. It's send AND receive Gb of traffic. The two bottoms of the pyramid, sender and recipient both pay. Their fees combine with other fees as their ISP pays the next ISP up until it reaches two ISPs who peer with each other. The peers trade bytes which each has been paid by their endpoint to move to and from the other. This model works. We know it works because the Internet currently runs on it. Your route originator pays to have his route introduced into the system, and his ISP pays to have it introduced further up, and so on up to the top of the pyramid where two ISPs peer. Now you have a problem. How does the other side of the pyramid get paid carry the routes on the way back down? There are at least a couple of potential solutions to this problem. One solution is that you auction off the right to announce a covering route for each /8. Then your ISP deals with paying everybody in a reliable set of transit chains that announces your route to that aggregation carrier. The auction is sort upside down where instead of paying for the right to announce the covering route a company bids on offering the best price cross reliability guarantee on a RAND basis. Everybody is free to carry your specific route, of course, but those who choose not to will still be fully connected to you via the covering /8 route. Even if the packet starts its trip via the covering route, it won't necessarily reach the aggregator. As soon as it enters any network carrying your specific announcement, the packet veers off towards you. Another solution would be some kind of international route clearinghouse. Everybody operating BGP on the Internet joins the clearinghouse and specifies how much they charge to carry a route. Then for each route you wish to introduce, you pick all the ASes whose price you're willing to pay. You pay the clearinghouse. The clearinghouse does the accounting and provides each AS with their payment and the list of routes they're being paid to accept upon receiving an advertisement. Analysts with the clearinghouse evaluate all the ASes, their geography, size, connectedness and their required payments. They collect ASes into technically useful sets with an aggregate price which buyers can use instead of having to examine each AS for themselves. By design, these sets try to exclude small-time ASes asking for too much money (or any money) to carry your route. Finally, anybody who is not a tier-1 transit free provider adds a default route to one or several of their upstream transit providers to carry packets for the routes they chose not to accept. So, if the clearinghouse analysts did their jobs well and you bought the route sets which made sense, you remain fully connected. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Question on DHCPv6 address assignment
On Jan 31, 2014, at 12:40 PM, Fernando Gont ferna...@gont.com.ar wrote: Folks, I'm wondering about the following two aspects of different DHCPv6 implementations out there: 1) What's the pattern with which addresses are generated/assigned? Are they sequential (fc00::1, fc00::2, etc.)? Random? Something else? Depends on your DHCPv6 server implementation. I believe ISC defaults to random. I’m not sure if that’s configurable or not. 2) What about their stability? Is there any intent/mechanism for them to be as stable as possible? Or is it usual for hosts to get a new address for each lease? I believe they are generally stable in that once a DUID is associated with an address, that association is persistent, but that may also be implementation dependent. P.S.: I understand this is likely to vary from one implementation to another... so please describe which implementation/version you're referring to. I have limited experience with the ISC DHCPv6 server. Mostly I just use SLAAC. Owen
Re: Updated ARIN allocation information
On Jan 31, 2014, at 1:29 PM, Matt Palmer mpal...@hezmatt.org wrote: On Fri, Jan 31, 2014 at 11:09:43AM -0500, John Curran wrote: better utilization. It would be nice if there was a way to fairly settle up for the imputed cost of adding a given route to the routing table, as this would provide some proportionate backpressure on growth, would create incentives for deaggregate cleanup, etc. We don't have such a system, so it falls to each ISP to decide what route is worth accepting based on type and the offering peer's business relationship... I almost hesitate to mention this, just in case I put ideas into some beancounter's head, but it seems to me that the cost model of carrying packets isn't that different to carrying routes. In both cases, practically everyone is acting as a middleman, and money flows hither and yon and (presumably) balances out in the end, with everyone having their costs covered with a little left over for the shareholders. Meh, sort of… Imagine one of the big players saying, we're going to charge you $X per route you send to us (just like transit agreements that state, we will charge you $X/GB of traffic), or your contract allows you to send us N routes (just like, your contract allows you to send us N Gb of traffic). About 15 minutes later everyone else would start doing it, to recoup the costs of sending routes to that provider. Peering would be considered not only if the volume of traffic was mutually advantageous, but also if the routes exchanged were mutually advantageous. That’s the optimistic outcome. The pessimistic outcome is that they get rapidly depeered by everyone unwilling to pay $X/GB and then start losing customers because their customers can no longer reach anyone else’s customers through them. The reality probably lies somewhere in between. I suspect whoever chooses to conduct this little experiment first should be prepared for substantial pain. YMMV. Owen
Re: Updated ARIN allocation information
* Mark Andrews I understand this but this block changes the status quo. It is a policy changer. AFAIK ARIN hasn't done allocations to the /28 level like this in the past. This is all new territory. It's not exactly new. Like I've mentioned earlier in this thread, the RIPE NCC has granted assignments smaller than /24 to requestors since, well, forever. There are currently 238 such assignments listed in delegated-ripencc-extended-latest.txt. However, these microscopic assignments have proven hugely unpopular, amounting for only a fraction of a percent of the total (there are 27733 assignments equal to or larger than /24 in the same file). What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular. As I read the policy in question, the requestors may get a /24 instead. That's a pretty miniature block to begin with and trivial to justify, and given human nature of wanting to grab as much of something as you can (especially when you in all likelihood cannot get nearly as much as you actually need), coupled with the fact that a /24 is likely to be immensely more useful than anything smaller...well, I just don't see why we shouldn't realistically expect that pretty much all of the assignments being made from this block will be exactly /24, and that exceptions that prove the rule will amount for 1% of the total - just like we've seen happen in the RIPE region. Oh well. Time will tell, I suppose. Tore
Re: Updated ARIN allocation information
On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson t...@fud.no wrote: What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular. Hi Tore, There is every expectation that they will be unpopular. They're a hedge against the possibility of a grueling last-minute IPv6 conversion following a failed IPv4 market. They're something that can, with difficulty, be made to work. They serve no other purpose. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Updated ARIN allocation information
has it be clarified by arin on why they are going to allocate /28s? seems a faster way to waste ipv4 space with unusable ip addresses? The only thing I can think of is micro allocations for IX points. *Bryan Socha* Network Engineer 646.450.0472 | *br...@serverstack.com br...@serverstack.com* *ServerStack* | Scale Big On Fri, Jan 31, 2014 at 6:58 PM, William Herrin b...@herrin.us wrote: On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson t...@fud.no wrote: What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular. Hi Tore, There is every expectation that they will be unpopular. They're a hedge against the possibility of a grueling last-minute IPv6 conversion following a failed IPv4 market. They're something that can, with difficulty, be made to work. They serve no other purpose. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Updated ARIN allocation information
On Fri, Jan 31, 2014 at 05:10:51AM -0800, Owen DeLong wrote: A /8 slot costs as much as a /28 slot to hold process etc. A routing slot is a routing slot. The *only* reason this isn't a legal problems at the moment is people can still get /24s. The moment /24's aren't readily available and they are forced into using this range anyone filtering on /24 in this range is leaving themselves open to lawsuits. On what basis? How do you have the right to force me to carry your route on my network? Especially in light of the recent strike-down of the net neutrality rules? Now as this range is allocated for transition to IPv6 a defence for edge networks may be we can reach all their services over IPv6 but that doesn't work for transit providers. Eyeball networks would need to ensure that all their customers had access to IPv6 and even that may not be enough. Please point to the law which requires a transit provider to provide transit to every tiny corner of every internet. Speaking only with respect to the US: I am aware of no such law. However, I am aware of a law that makes it unlawful for a bunch of large providers who already have large blocks of space to collude to prevent new entrants into the market by refusing to carry their routes. If the guy with the /28 he can't route alleges that that's what's happening, there are lots of arguments on the other side the ISPs with the filters could make. They've been filtering at /24 for a lot longer than it started to seriosuly harm new entrants into the market ... there was never any formal agreement to filter at /24; it just happened (but everyone ended up filtering at /24 ... that wasn't just coincidence) ... there are real technical reasons for limiting FIB size ... and so on. I don't know who would win the anti-trust lawsuit, but I wouldn't consider it a slam dunk for the ISPs doing the filtering. I don't expect there to actually be such a lawsuit. Among other things, buying a /24 will likely be cheaper than litigating this, so the only way it gets to trial is an organization litigating on principle. And, as I said, I'm not convinced the filtering providers lose if there is one. But anytime the big guys collectively have a policy that keeps out the new entrants, there's anti-trust exposure. -- Brett
Re: Updated ARIN allocation information
I will attempt to clarify this once more... When I wrote the policy which created this set-aside space, it was, as Bill has said, intended as a hedge to provide minimal resources for organizations that are unable to obtain larger IPv4 blocks through any normal mechanism (standard allocation/assignment, transfer, market, etc.) and desperately need some space which they can hopefully get routed to support the bare minimum IPv4 connectivity for their IPv6 environment. I expect that if use of these blocks does become necessary, then routing them will almost certainly be the least of the problems we face in that circumstance. It is my sincere hope that we come to our senses and implement IPv6 sufficiently that these blocks are never needed. However, as the saying goes, I am hoping for the best and planning for the worst. The ARIN community overwhelmingly supported this idea at the time and that is why we set aside the block in question. In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment. Owen On Jan 31, 2014, at 7:38 PM, Bryan Socha br...@serverstack.com wrote: has it be clarified by arin on why they are going to allocate /28s? seems a faster way to waste ipv4 space with unusable ip addresses? The only thing I can think of is micro allocations for IX points. *Bryan Socha* Network Engineer 646.450.0472 | *br...@serverstack.com br...@serverstack.com* *ServerStack* | Scale Big On Fri, Jan 31, 2014 at 6:58 PM, William Herrin b...@herrin.us wrote: On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson t...@fud.no wrote: What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular. Hi Tore, There is every expectation that they will be unpopular. They're a hedge against the possibility of a grueling last-minute IPv6 conversion following a failed IPv4 market. They're something that can, with difficulty, be made to work. They serve no other purpose. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Updated ARIN allocation information
I get the idea behind it, but it really has no real world usage. I can still find 15 year old swips from people with /8s who keep getting more addresses. Break out the audits before their next blocks.
Re: Updated ARIN allocation information
Without making a policy proposal, (yet), it might make sense to have a suggestion to ARIN that if it *does* end up allocating multiple /28s from one /24 intermediate, that the /24 be regionally reserved so that all sub-blocks are physically nearby and could collaborate on a cooperative /24 global announcement and internal side split-out... -george william herbert george.herb...@gmail.com Sent from Kangphone On Jan 31, 2014, at 5:14 PM, Owen DeLong o...@delong.com wrote: I will attempt to clarify this once more... When I wrote the policy which created this set-aside space, it was, as Bill has said, intended as a hedge to provide minimal resources for organizations that are unable to obtain larger IPv4 blocks through any normal mechanism (standard allocation/assignment, transfer, market, etc.) and desperately need some space which they can hopefully get routed to support the bare minimum IPv4 connectivity for their IPv6 environment. I expect that if use of these blocks does become necessary, then routing them will almost certainly be the least of the problems we face in that circumstance. It is my sincere hope that we come to our senses and implement IPv6 sufficiently that these blocks are never needed. However, as the saying goes, I am hoping for the best and planning for the worst. The ARIN community overwhelmingly supported this idea at the time and that is why we set aside the block in question. In answer to Tore's statement, this block does not apply the standard justification criteria and I think you would actually be quite hard pressed to justify a /24 from this prefix. In most cases, it is expected that these would be the IPv4 address pool for the public facing IPv4 side of a NAT64 or 464xlat service. Most organizations probably only need one or two addresses and so would receive a /28. It is expected that each of these addresses likely supports several thousand customers in a service provider environment. Owen On Jan 31, 2014, at 7:38 PM, Bryan Socha br...@serverstack.com wrote: has it be clarified by arin on why they are going to allocate /28s? seems a faster way to waste ipv4 space with unusable ip addresses? The only thing I can think of is micro allocations for IX points. *Bryan Socha* Network Engineer 646.450.0472 | *br...@serverstack.com br...@serverstack.com* *ServerStack* | Scale Big On Fri, Jan 31, 2014 at 6:58 PM, William Herrin b...@herrin.us wrote: On Fri, Jan 31, 2014 at 6:45 PM, Tore Anderson t...@fud.no wrote: What I fail to understand from this thread is the apparent expectation that these smaller-than-/24 microscopic delegations from ARIN will be popular. Hi Tore, There is every expectation that they will be unpopular. They're a hedge against the possibility of a grueling last-minute IPv6 conversion following a failed IPv4 market. They're something that can, with difficulty, be made to work. They serve no other purpose. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Updated ARIN allocation information
On Fri, Jan 31, 2014 at 03:10:56PM -0800, Owen DeLong wrote: On Jan 31, 2014, at 1:29 PM, Matt Palmer mpal...@hezmatt.org wrote: Imagine one of the big players saying, we're going to charge you $X per route you send to us (just like transit agreements that state, we will charge you $X/GB of traffic), or your contract allows you to send us N routes (just like, your contract allows you to send us N Gb of traffic). About 15 minutes later everyone else would start doing it, to recoup the costs of sending routes to that provider. Peering would be considered not only if the volume of traffic was mutually advantageous, but also if the routes exchanged were mutually advantageous. That’s the optimistic outcome. The pessimistic outcome is that they get rapidly depeered by everyone unwilling to pay $X/GB and then start losing customers because their customers can no longer reach anyone else’s customers through them. That doesn't mean someone somewhere wouldn't try it. But I doubt it would be done in such a heavy-handed manner as to incur that sort of reaction. There are a bunch of ways it could be done quietly and without too much fuss. Vague language about reasonable route volume would be the easiest to slip under the radar, and if the cost of additional routes is below what your costs of changing providers would be, you'll almost certainly just wear it. Similar language could also be a big stick against excessive deagg, so there's a potential upside there, too. The blow could very easily be softened, too, by offering to pay all your customer for the routes they accept *from* you -- even setting it up so it was revenue neutral (in the beginning, at least...) so people get used to the idea. Hell, I could see it pitched as an up-sell: pay us $$$ and we'll accept your /28, and pass some of that moolah along to others so they'll do it too. Once it's in place for that, just keep shortening the masklen over time for what you can announce for free (presumably as fragmentation due to sale of blocks increases route volume). If Mark Andrews' assertion comes to pass, that legal action is taken against those unwilling to accept longer prefixes, I'd expect this sort of scheme to come to pass *very* quickly. If you're willing to accept routes from all comers, just in exchange for payment to cover costs incurred, then nobody can claim restraint of trade or cartel-like behaviour. If things got really hairy, providers could use their netflow data and some BigData(TM) analytics to work out the value vs the cost of every route they were carrying, and drop those who didn't make the grade (where you could increase the value of your route by paying for it). If there's one thing the commercial Internet has demonstrated, is that there isn't a business model so weird that *someone* won't try it. The reality probably lies somewhere in between. I suspect whoever chooses to conduct this little experiment first should be prepared for substantial pain. There's no possible upside unless there's some risk. I'm surprised nobody's tried this already, the more I think about it. Time to raise some VC, perhaps! - Matt -- Of course, I made the mistake of showing [a demo application] off to my boss, who showed it off to his boss, and suddenly I couldn't reboot my desktop box without getting a change control approved. -- Derick Siddoway, in a place that doesn't exist
Re: Updated ARIN allocation information
On Fri, 31 Jan 2014 15:10:56 -0800, Owen DeLong said: Thats the optimistic outcome. The pessimistic outcome is that they get rapidly depeered by everyone unwilling to pay $X/GB and then start losing customers because their customers can no longer reach anyone elses customers through them. Maybe I need to buy stock in General Mills, I forsee a run on Betty Crocker cake mixes... :) pgp_RHafvwUya.pgp Description: PGP signature
Re: Updated ARIN allocation information
On Jan 31, 2014, at 5:03 PM, Brett Frankenberger rbf+na...@panix.com wrote: On Fri, Jan 31, 2014 at 05:10:51AM -0800, Owen DeLong wrote: A /8 slot costs as much as a /28 slot to hold process etc. A routing slot is a routing slot. The *only* reason this isn't a legal problems at the moment is people can still get /24s. The moment /24's aren't readily available and they are forced into using this range anyone filtering on /24 in this range is leaving themselves open to lawsuits. On what basis? How do you have the right to force me to carry your route on my network? Especially in light of the recent strike-down of the net neutrality rules? Now as this range is allocated for transition to IPv6 a defence for edge networks may be we can reach all their services over IPv6 but that doesn't work for transit providers. Eyeball networks would need to ensure that all their customers had access to IPv6 and even that may not be enough. Please point to the law which requires a transit provider to provide transit to every tiny corner of every internet. Speaking only with respect to the US: I am aware of no such law. However, I am aware of a law that makes it unlawful for a bunch of large providers who already have large blocks of space to collude to prevent new entrants into the market by refusing to carry their routes. Sure… The Sherman Anti-Trust act. However, in order to bring a successful action under that act, one must prove that they colluded on the decision, rather than simply arriving at that decision independently. Since the current status quo is not carrying longer routes in general, it would be pretty hard to show that they colluded to avoid changing their policy. If the guy with the /28 he can't route alleges that that's what's happening, there are lots of arguments on the other side the ISPs with the filters could make. They've been filtering at /24 for a lot longer than it started to seriosuly harm new entrants into the market ... there was never any formal agreement to filter at /24; it just happened (but everyone ended up filtering at /24 ... that wasn't just coincidence) ... there are real technical reasons for limiting FIB size ... and so on. I don't know who would win the anti-trust lawsuit, but I wouldn't consider it a slam dunk for the ISPs doing the filtering. In the current regulatory environment with the current US courts, I’d say it’s pretty close to a slam dunk. However, IANAL and YMMV definitely applies here. As a practical matter, it’s also awfully expensive for the little guy to bring enough lawyers to bear on one of the large providers to stand a chance of not being simply buried in procedural paperwork and discovery. The little guy would have to have pretty strong backing or pretty deep pockets to survive the process. I don't expect there to actually be such a lawsuit. Among other things, buying a /24 will likely be cheaper than litigating this, so the only way it gets to trial is an organization litigating on principle. And, as I said, I'm not convinced the filtering providers lose if there is one. But anytime the big guys collectively have a policy that keeps out the new entrants, there's anti-trust exposure. Only if you can prove collusion. For civil matters, it’s just by preponderance of the evidence, but if the DoJ or some District Attorney or Attorney General decides to take the matter up as a criminal case, then the burden shifts to beyond a reasonable doubt. As much as I wish there were a way to require the big guys to be nice to the little guys, the reality is that the precedent such a case would set (being able to require a network to carry arbitrary traffic whether or not doing so is in that networks own best interest and regardless of the cost/benefit ratio, etc.) is a very dangerous precedent. Once that one is on the books, imagine how the big guys could use it to bankrupt the little guys… The other option, of course, is that the big guys simply start charging the registered prefix holder for every route they accept. Then, they are free to offer discounts up to 100% to any providers they choose to offer such discounts to, but the little guys are still shafted. Bottom line, the big guys have enough resources and know how to play the regulatory and litigation games well enough that I just don’t see the little guy achieving anything but a pyrrhic victory at best. Owen
