Re: The End-To-End Internet (was Re: Blocking MX query)
In message 108454.1346989...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: --==_Exmh_1346989445_1993P Content-Type: text/plain; charset=us-ascii On Fri, 07 Sep 2012 08:30:12 +1000, Mark Andrews said: In message 85250.1346959...@turing-police.cc.vt.edu, valdis.kletni...@vt.edu writes: My PS3 may want to talk to the world, but I have no control over Comcast's DNS. What point are you trying to make? Comcast's servers support SRV as do all general purpose name servers. For HTTP at least you need to be backwards compatible so there is no reason not to add SRV support. Sure, Comcast's servers will happily support an SRV entry for my PS3. However, Comcast's business processes don't support a way for me to request said SRV record be listed. Heck, I don't even get a static IP with my current service package. ;) There are plenty of companies that will serve whatever you want them to serve. Now *I* have the technical chops to talk to the guys at dyndns.org or other providers and get an SRV entry created under some domain name pointing back at my IP address. However, Joe Sixpack doesn't really have that option. And unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or whatever to request an SRV entry saying that the PS3 wants to do service foobar on port 34823, you can't use SRV like that. There is NOTHING stopping Sony adding code to the PS3 to perform dynamic updates to add the records. We have a well established protocol to do this securely. 100's of millions of records get updated daily using this protocol in the corporate environment. This is NOTHING Joe Sixpack can't do with a smidgen of help on behalf of product vendors. Home router vendors already have code to do this. domain name for the PS account name password account name and password form the TSIG information to secure the dynamic update. A better proposal would probably be having the NAT itself run a 'portmap' type service on a well known port like 111. Except that still doesn't do a very good job of disambiguating two instances of foobar behind a NAT... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: The End-To-End Internet (was Re: Blocking MX query)
Oliver wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. It's you who tries to change the meaning of end to end transparency. Masataka Ohta
Re: RPKI Pilot Participant Notice
If a relying party's use of PKI infrastructure legally equated to acceptance of the relying party agreement (RPA), then having an explicit record of acceptance of the RPA would not be necessary. Alas, it does not appear possible to equate use of PKI certificates with agreement to the associated RPA (and some might argue that this is a feature, as some folks would not want to be legally bound to an agreement which they did not explicitly review and accept.) do you have a rd group devoted to how much you can delay, damage, warp, half-assed implement, ... rpki? look around you at the real world, the other rirs (especiall ripe/ncc), etc. the only part of it where arin seems to be doing a serious job is bs generation. thanks. randy
Re: The End-To-End Internet (was Re: Blocking MX query)
Andrew Sullivan wrote: the DNS and won't discover anything about the DNS that can't be had via getaddrinfo() until long after its too late redefine the protocol in terms of seeking SRV records. Oh, sure, I get that. One of the problems I've had with the end to end NAT argument is exactly that I can't see how it's any more deployable than IPv6, for exactly this reason. The easiest part of the deployment is to modify end systems. Because of the 20-year problem, I think now would be an excellent time to start thinking about how to make usable all those nice features we already have in the DNS. Apple did it. See RFC6281. Masataka Ohta
Re: The End-To-End Internet (was Re: Blocking MX query)
On Sep 6, 2012, at 22:31 , Sean Harlow s...@seanharlow.info wrote: On Sep 6, 2012, at 23:44, valdis.kletni...@vt.edu wrote: However, Joe Sixpack doesn't really have that option. And unless you figure out a scalable and universal way for Joe Sixpack's Xbox or PS3 or whatever to request an SRV entry saying that the PS3 wants to do service foobar on port 34823, you can't use SRV like that. I think you missed the point on this one. Even if your PS3 has a public IP with no limitations on ports, how exactly are others going to find it to connect to it? I see three options here: 1. You have to give them the IP address, in which case it's not exactly rocket science to give them the port as well. The same Joe Sixpack who couldn't find the port couldn't likely figure out his IP either, so the PS3 would have to be able to identify its own public-facing IP and tell him, in which case it could also tell him the port. 2. DNS, which while many don't have this ability any that do should have no problem setting a SRV record. Obviously not all clients support the use of SRV records, but that's not the subject of this particular tangent. Anyone can set up free DNS from a variety of providers and get a domain name for ~$10/year. I'm not sure why you think there is anyone who can't get DNS. If you can operate a web browser and come up with $10/year or so, you can have forward DNS. The inability to influence Comcast's nameservers would only affect reverse lookups (which SRV goes forward, not reverse IIRC). 3. Intermediary directory server hosted at a known location. Pretty much the standard solution for actual PS3 titles as well as almost all other games since the late '90s. Rather than telling the user, the PS3 tells the central server its IP and port plus any useful metadata about the service being offered and the user just needs to give his friend a name or other identifier to find it in the list. Which becomes ugly and unnecessary with full transparency and useful DNS, which we get with IPv6 even without SRV records. To make SRV records meaningful, OTOH, virtually every client needs an update. None of these options are impacted by being behind a NAT as long as they have the ability to open a port via UPnP or equivalent, so if in an ideal world all client software understood SRV records this particular negative of NAT would be of minimal impact. Of course the real world is nowhere close to ideal and personally SIP phones and Jabber clients are the only things I've ever observed widely using SRV records, so at least for now I can't just do something like _http._tcp.seanharlow.info 86400 IN SRV 0 5 8080 my.home.fake. and host my personal site on my home server (Mozilla has had a bug open on this for over ten years, Chrome for three, and Webkit closed their bug as WONTFIX two years ago so I don't expect this to change any time soon). At this point we're coming back around to the already raised point about if we're going to have to change a lot of things, why not just put that effort in to doing it right with IPv6 rather than trying to keep address conservation via DNAT alive? +1 -- Address transparency is a good thing. Owen
Re: The End-To-End Internet (was Re: Blocking MX query)
This has been experimental with no forward progress since 2001. Any sane person would conclude that the experiment failed to garner any meaningful support. Is there any continuing active work on this experiment? Any running code? Didn't think so. Owen On Sep 6, 2012, at 23:23 , Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Oliver wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. It's you who tries to change the meaning of end to end transparency. Masataka Ohta
Re: RPKI Pilot Participant Notice
On Sep 7, 2012, at 7:31 AM, Randy Bush ra...@psg.com wrote: If a relying party's use of PKI infrastructure legally equated to acceptance of the relying party agreement (RPA), then having an explicit record of acceptance of the RPA would not be necessary. Alas, it does not appear possible to equate use of PKI certificates with agreement to the associated RPA (and some might argue that this is a feature, as some folks would not want to be legally bound to an agreement which they did not explicitly review and accept.) do you have a rd group devoted to how much you can delay, damage, warp, half-assed implement, ... rpki? look around you at the real world, the other rirs (especiall ripe/ncc), etc. the only part of it where arin seems to be doing a serious job is bs generation. thanks. Good morning Randy - Are you indicating that RPKI services should be offered without any RPA (and/or CPS) at all, or that these agreements should legally adhere without explicit agreement? There is an statement expressing that CPS or RPA might benefit from the latter treatment in section 3.4 of the Internet PKI framework (RFC 3647), but it does not actually hold legally true at the present time. If you have more insight or clarity on this matter, it would be most welcome. Thanks! /John John Curran President and CEO ARIN
Re: The End-To-End Internet (was Re: Blocking MX query)
Sean Harlow wrote: None of these options are impacted by being behind a NAT as long as they have the ability to open a port via UPnP or equivalent, so if in an ideal world all client software understood SRV records this particular negative of NAT would be of minimal impact. My point is that the impact can be minimized if 1) a set of port numbers is statically allocated to a host behind NAT without UPnP or PCP, just as allocating a static address to a host, which means there is no security concern w.r.t. dynamic assignment. Dynamic DNS update is not necessary, either. UPnP or PCP can still be used to collect information for reverse translation. 2) reverse translation can be performed by network and/or transport layer without involving applications, which makes modifications to application programs completely unnecessary. I have already confirmed that ftp PORT command work transparently. Of course the real world is nowhere close to ideal and personally SIP phones and Jabber clients are the only things I've ever observed widely using SRV records, As we can explicitly specify port numbers in URLs, support for SRV is not very essential. But, SRV will be more commonly used as PCP will be deployed. Masataka Ohta
Re: RPKI Pilot Participant Notice
Good morning Randy - it is late afternoon Are you indicating that RPKI services should be offered without any RPA (and/or CPS) at all, or that these agreements should legally adhere without explicit agreement? There is an statement expressing that CPS or RPA might benefit from the latter treatment in section 3.4 of the Internet PKI framework (RFC 3647), but it does not actually hold legally true at the present time. If you have more insight or clarity on this matter, it would be most welcome. does arin run an irr instance? how much legal bs have you wrapped around it? randy
Re: The End-To-End Internet (was Re: Blocking MX query)
Owen DeLong wrote: Then why is IPv6 deployment happening faster in the internet core than at the edge? The real world seems to defy your claims. Which world, are you talking about? Martian? This has been experimental with no forward progress since 2001. Obviously because it is a new protocol requiring new gateways, which is not the case with UPnP capable NAT. Moreover, it has nothing to do with the definition of the end to end transparency. Masataka Ohta
RE: Are people still building SONET networks from scratch?
Does anyone make a cheaper OC3 circuit emulation module or box? Maybe Cisco ME 3600X 24CX Switch or Cisco ASR 903 Router adam
Re: RPKI Pilot Participant Notice
On Sep 7, 2012, at 7:55 AM, Randy Bush ra...@psg.com wrote: Good morning Randy - it is late afternoon Indeed... that may contribute significantly to the difference in perspective. In the US, little details such as legal structures often take on greater importance than would be otherwise warranted. Are you indicating that RPKI services should be offered without any RPA (and/or CPS) at all, or that these agreements should legally adhere without explicit agreement? There is an statement expressing that CPS or RPA might benefit from the latter treatment in section 3.4 of the Internet PKI framework (RFC 3647), but it does not actually hold legally true at the present time. If you have more insight or clarity on this matter, it would be most welcome. does arin run an irr instance? Yes. how much legal bs have you wrapped around it? If we were establishing it today, I do not know what, if any, legal machinations would be needed. This is similar to RFCs, which were published first without any preamble but now have significant legal structure at the front. FYI, /John John Curran President and CEO ARIN
Re: Are people still building SONET networks from scratch?
On 07/09/12 02:38, Will Orton wrote: Having much more experience with ethernet/packet/MPLS setups, we are trying to get the client to admit that 1g/10g waves running ethernet with QoS would be as good as or better in terms of latency, jitter, and loss for their packet data. So far they will barely listen to the arguments. And then going the next leap and showing them that we could work towards 50ms protection switching with MPLS/BFD/etc packet-based protocols is another stretch. Am I missing something here that my customer isn't, or is it the other way around? A few of the engineers at $DAYJOB still try and claim SONET is easier to troubleshoot, but that hasn't been my practical experience. With ethernet it's something like: - Layer 1 - light levels (DoM on nearly everything) - Layer 1 - link pulse - Layer 2 - can I send frames SONET it's, in practice: - Layer 1 - light levels (DoM on newer kit, SOL on older) - Layer 2 - Seemingly random collection of alarms - Layer 2 - Is PPP up? Sure being able tell a provider that our kit is showing a particular alarm can sometimes be helpful, but for every time that's been helpful I've seen multiple circuits down for timing, often for no explainable reason (I have atomic standards at home, and still can't explain a few of the cases I've seen). As others have said doing a diverse 1/10g ethernet quote and a protected SONET quote may be worthwhile, and adding a 20% pad to the SONET one for staff training may also be perfectly justifiable. Also other then the ONS15300 series (which I'm amazed haven't been discontinued) I can see nothing that actually offers OC3 line ports, building something new using those today seems like using a 2500 as a console server, sure for a lab or demo perhaps, but otherwise I'm staying well away from them.
Re: The End-To-End Internet (was Re: Blocking MX query)
On Fri, 07 Sep 2012 16:01:10 +1000, Mark Andrews said: There is NOTHING stopping Sony adding code to the PS3 to perform dynamic updates to add the records. We have a well established protocol to do this securely. 100's of millions of records get updated daily using this protocol in the corporate environment. This is NOTHING Joe Sixpack can't do with a smidgen of help on behalf of product vendors. Home router vendors already have code to do this. domain name for the PS account name password account name and password form the TSIG information to secure the dynamic update. And my point was merely that you can't actually use SRV for this use case until the above is actually deployed, rather than in the nothing stopping SONY hand-waving state. pgp2oiZkBXqDM.pgp Description: PGP signature
Re: The End-To-End Internet (was Re: Blocking MX query)
On Friday 07 September 2012 15:23:30 Masataka Ohta wrote: Oliver wrote: All that necessary is local changes on end systems of those who want the end to end transparency. There is no changes on the Internet. You're basically redefining the term end-to-end transparency to suit your own Already in RFC3102, which restrict port number ranges, it is stated that: This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols. Just because something is documented in RFC does not automatically make it a standard, nor does it necessarily make anyone care. I refer you to RFC1149. Although, since you have such a hard-on for RFCs, you should check out RFC2460 - unlike 3102, it's standards-track and quite widely implemented. It's you who tries to change the meaning of end to end transparency. Denial: not just a river in Egypt. If the best rebuttal you can come up with is an experimental, unused RFC and a one-liner that basically amounts to NO U, I suggest you do everyone a favour and crawl back into the hole you came from. I realise that it must be a difficult and slow process coming to the realisation that everything you've advocated for and espoused is unmitigated garbage, but whilst you deal with that internal struggle, please save the rest of us from having to waste our time deconstructing the last vestiges of your folly. Regards, Oliver
Re: The End-To-End Internet (was Re: Blocking MX query)
On Tue, Sep 4, 2012 at 3:45 PM, William Herrin b...@herrin.us wrote: On Tue, Sep 4, 2012 at 2:22 PM, Jay Ashworth j...@baylink.com wrote: It is regularly alleged, on this mailing list, that NAT is bad *because it violates the end-to-end principle of the Internet*, where each host is a full-fledged host, able to connect to any other host to perform transactions. That's what firewalls *are for* Jay. They intentionally break end-to-end for communications classified by the network owner as undesirable. Whether a particular firewall employs NAT or not is largely beside the point here. Either way, the firewall is *supposed* to break some of the end to end communication paths. Exactly - talking about a *(subtle?)* difference here. 1) Breaking the E2E model because your security policy (effectively) dictates it. For the record, this is fine as it is your decision for your network. 2) Being forced to break that model by deficiencies in the underlying protocol/address-family. This is, shall we say, sub-optimal. /TJ
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 08 Sep, 2012 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 425836 Prefixes after maximum aggregation: 178207 Deaggregation factor: 2.39 Unique aggregates announced to Internet: 207327 Total ASes present in the Internet Routing Table: 42041 Prefixes per ASN: 10.13 Origin-only ASes present in the Internet Routing Table: 33589 Origin ASes announcing only one prefix: 15753 Transit ASes present in the Internet Routing Table:5599 Transit-only ASes present in the Internet Routing Table:135 Average AS path length visible in the Internet Routing Table: 4.6 Max AS path length visible: 32 Max AS path prepend of ASN ( 48687) 24 Prefixes from unregistered ASNs in the Routing Table: 715 Unregistered ASNs in the Routing Table: 248 Number of 32-bit ASNs allocated by the RIRs: 3235 Number of 32-bit ASNs visible in the Routing Table:2853 Prefixes from 32-bit ASNs in the Routing Table:7496 Special use prefixes present in the Routing Table:0 Prefixes being announced from unallocated address space:184 Number of addresses announced to Internet: 2593144332 Equivalent to 154 /8s, 144 /16s and 62 /24s Percentage of available address space announced: 70.0 Percentage of allocated address space announced: 70.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 93.5 Total number of prefixes smaller than registry allocations: 150194 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 102226 Total APNIC prefixes after maximum aggregation: 32992 APNIC Deaggregation factor:3.10 Prefixes being announced from the APNIC address blocks: 102840 Unique aggregates announced from the APNIC address blocks:42607 APNIC Region origin ASes present in the Internet Routing Table:4755 APNIC Prefixes per ASN: 21.63 APNIC Region origin ASes announcing only one prefix: 1245 APNIC Region transit ASes present in the Internet Routing Table:763 Average APNIC Region AS path length visible:4.6 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table:297 Number of APNIC addresses announced to Internet: 707762048 Equivalent to 42 /8s, 47 /16s and 151 /24s Percentage of available APNIC address space announced: 82.7 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 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:154235 Total ARIN prefixes after maximum aggregation:77982 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 155222 Unique aggregates announced from the ARIN address blocks: 69088 ARIN Region origin ASes present in the Internet Routing Table:15222 ARIN Prefixes per ASN:10.20 ARIN Region origin ASes
BGP Update Report
BGP Update Report Interval: 30-Aug-12 -to- 06-Sep-12 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS6517 143391 6.8% 279.0 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 2 - AS30137 130915 6.2%2146.1 -- SEA-BROADBAND - Sea Broadband, LLC 3 - AS10198 86716 4.1% 17343.2 -- CUP-AS-KR Catholic University of Pusan 4 - AS840243880 2.1% 30.5 -- CORBINA-AS OJSC Vimpelcom 5 - AS982936108 1.7% 29.2 -- BSNL-NIB National Internet Backbone 6 - AS22561 26219 1.2% 25.1 -- DIGITAL-TELEPORT - Digital Teleport Inc. 7 - AS24560 23941 1.1% 41.9 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS13118 20062 1.0% 418.0 -- ASN-YARTELECOM OJSC Rostelecom 9 - AS163716835 0.8% 189.2 -- DNIC-AS-01637 - Headquarters, USAISC 10 - AS28238 14083 0.7% 440.1 -- 11 - AS335614040 0.7% 12.8 -- LEVEL3 Level 3 Communications 12 - AS25620 11921 0.6% 56.5 -- COTAS LTDA. 13 - AS27947 11885 0.6% 16.5 -- Telconet S.A 14 - AS269711748 0.6% 94.0 -- ERX-ERNET-AS Education and Research Network 15 - AS19361 11314 0.5% 332.8 -- Atrium Telecomunicacoes Ltda 16 - AS28573 10642 0.5% 4.9 -- NET Servicos de Comunicao S.A. 17 - AS702910532 0.5% 3.0 -- WINDSTREAM - Windstream Communications Inc 18 - AS21599 10127 0.5% 81.7 -- NETDIRECT S.A. 19 - AS5800 9861 0.5% 38.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS389209159 0.4%4579.5 -- TURKLANDBANK-TR TURKLANDBANK TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS10198 86716 4.1% 17343.2 -- CUP-AS-KR Catholic University of Pusan 2 - AS389209159 0.4%4579.5 -- TURKLANDBANK-TR TURKLANDBANK 3 - AS146806671 0.3%2223.7 -- REALE-6 - Auction.com 4 - AS30137 130915 6.2%2146.1 -- SEA-BROADBAND - Sea Broadband, LLC 5 - AS444105228 0.2%1742.7 -- ENTEKHAB-AS ENTEKHAB INDUSTRIAL GROUP 6 - AS388571596 0.1%1596.0 -- ESOFT-TRANSIT-AS-AP e.Soft Technologies Ltd. 7 - AS369483143 0.1%1571.5 -- KENIC 8 - AS6629 8923 0.4%1274.7 -- NOAA-AS - NOAA 9 - AS131784286 0.2%1071.5 -- DIGCOMM Digital communications, LTD 10 - AS417338324 0.4%1040.5 -- ZTELECOM-AS JSC Z-Telecom 11 - AS29126 881 0.0% 881.0 -- DATIQ-AS Datiq B.V. 12 - AS46620 768 0.0% 768.0 -- WBH-ISC-RO - William Beaumont Hospital 13 - AS257151414 0.1% 707.0 -- UREACH-C - UREACH TECHNOLOGIES, INC. 14 - AS29398 503 0.0% 503.0 -- PETROBALTIC Petrobaltic S.A. 15 - AS32529 493 0.0% 493.0 -- CGI-FEDERAL-ASN-1 - CGI Federal 16 - AS56763 474 0.0% 474.0 -- INFOTELL-AS Infotell-Telecom Ltd 17 - AS28238 14083 0.7% 440.1 -- 18 - AS48696 436 0.0% 436.0 -- TEMP-AS TEMP Ltd. 19 - AS21023 432 0.0% 432.0 -- UPB-AS Joint Stock Company Ural Industrial Bank 20 - AS13118 20062 1.0% 418.0 -- ASN-YARTELECOM OJSC Rostelecom TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 109.161.64.0/19 20015 0.9% AS13118 -- ASN-YARTELECOM OJSC Rostelecom 2 - 110.9.62.0/23 17942 0.8% AS10198 -- CUP-AS-KR Catholic University of Pusan 3 - 110.9.64.0/23 17935 0.8% AS10198 -- CUP-AS-KR Catholic University of Pusan 4 - 110.9.61.0/24 17935 0.8% AS10198 -- CUP-AS-KR Catholic University of Pusan 5 - 203.232.208.0/21 16455 0.7% AS10198 -- CUP-AS-KR Catholic University of Pusan 6 - 210.93.62.0/2316449 0.7% AS10198 -- CUP-AS-KR Catholic University of Pusan 7 - 184.159.130.0/23 13806 0.6% AS22561 -- DIGITAL-TELEPORT - Digital Teleport Inc. 8 - 199.250.214.0/24 11293 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 9 - 199.250.206.0/24 11291 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 10 - 199.250.213.0/24 11290 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 11 - 199.250.204.0/24 11289 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 12 - 199.250.215.0/24 11289 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 13 - 199.250.207.0/24 11289 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 14 - 199.250.195.0/24 11288 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 15 - 199.250.205.0/24 11286 0.5% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 16 -
The Cidr Report
This report has been generated at Fri Sep 7 21:13:05 2012 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 for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
31-08-12426827 246600
01-09-12426662 246502
02-09-12426856 246667
03-09-12427078 246831
04-09-12426935 245691
05-09-12427098 246050
06-09-12427448 246019
07-09-12427365 246183
AS Summary
42141 Number of ASes in routing system
17590 Number of ASes announcing only one prefix
3459 Largest number of prefixes announced by an AS
AS7029 : WINDSTREAM - Windstream Communications Inc
113164512 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').
--- 07Sep12 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 428070 246197 18187342.5% All ASes
AS6389 3334 187 314794.4% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS28573 2141 58 208397.3% NET Servicos de Comunicao S.A.
AS17974 2342 537 180577.1% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS22773 1888 158 173091.6% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS7029 3459 1733 172649.9% WINDSTREAM - Windstream
Communications Inc
AS18566 2085 423 166279.7% COVAD - Covad Communications
Co.
AS4766 2954 1462 149250.5% KIXS-AS-KR Korea Telecom
AS2118 1401 14 138799.0% RELCOM-AS OOO NPO Relcom
AS10620 2132 785 134763.2% Telmex Colombia S.A.
AS4323 1582 389 119375.4% TWTC - tw telecom holdings,
inc.
AS7303 1564 451 111371.2% Telecom Argentina S.A.
AS1785 1914 824 109056.9% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4755 1618 546 107266.3% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7552 1121 207 91481.5% VIETEL-AS-AP Vietel
Corporation
AS8151 1570 695 87555.7% Uninet S.A. de C.V.
AS18101 941 157 78483.3% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS4808 1121 354 76768.4% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS6458 791 42 74994.7% Telgua
AS13977 848 121 72785.7% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS15557 1221 556 66554.5% LDCOMNET Societe Francaise du
Radiotelephone S.A
AS3356 1107 475 63257.1% LEVEL3 Level 3 Communications
AS855682 52 63092.4% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS36998 776 146 63081.2% SDN-MOBITEL
AS17676 711 85 62688.0% GIGAINFRA Softbank BB Corp.
AS22561 1034 428 60658.6% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS19262 1002 404 59859.7% VZGNI-TRANSIT - Verizon Online
LLC
AS24560 1040 442 59857.5% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS30036 1417 833 58441.2% MEDIACOM-ENTERPRISE-BUSINESS -
Mediacom Communications Corp
AS7545 1752 1182 57032.5% TPG-INTERNET-AP TPG Internet
Pty Ltd
AS3549 1001 438 56356.2% GBLX Global Crossing
Re: CAIDA's AS-rank project
No IPv6? On Thu, Sep 6, 2012 at 6:46 PM, Matthew Luckie m...@caida.org wrote: Hello, We have been working on refreshing the data and algorithms behind CAIDA's as-rank project. We have published AS-relationships and AS-rankings computed for June 2012. We are currently seeking further validation of our rankings and relationship inferences. http://as-rank.caida.org/ The core of the algorithm is the inference of business relationships. Over the past two years we have received a significant amount of ground truth from operators through the corrections facility provided within AS-rank: in particular we obtained 1200 p2p relationships as a result of our previous algorithm that assigned many more customer/provider (c2p) relationships than ASes had in reality. Our intuition is that network owners are a lot more concerned when we infer a provider relationship that is actually a peer relationship, but are less motivated to validate other inferences. We have validated our algorithm against available ground truth and find our relationship inferences have a 99.1% positive predictive value (PPV) for c2p and 94.7% for p2p for the validation data we have available. Because customer cone computation depends on the accuracy of our c2p inferences, we are reasonably confident in our computed rankings. We are now soliciting further feedback in any shape and form offered. The as-rank website provides the ability for operators to submit corrections through the right-most corrections button on an individual ASes information page, and relationships ground-truth is solicited through that channel, if at all possible. Other feedback, on or off-list, would also be appreciated. If you are curious as to why a particular relationship was inferred, please get in contact with me. Some ASes have advised of a particular business relationship in the past, but when I drill down into the data it turns out they have a misconfiguration and are leaking routes to a peer. At a minimum, this might be a useful sanity check for some ASes who may be providing free transit without realising it. In the future, we plan to annotate each relationship with examples as to why it was inferred the way it was, but we have not yet got that far yet. Thanks, Matthew Luckie CAIDA
time-b.netgear.com/time-c.netgear.com dns queries
Noticed lot of A record queries for time-b.netgear.com/time-c.netgear.comon dns servers. Has anyone noticed similar behavior on any of your dns servers? Anyone aware about a known issue with netgear home routers which can create bulk dns queries? -Basil
Re: time-b.netgear.com/time-c.netgear.com dns queries
Yo Basil! On Fri, 7 Sep 2012 20:22:29 -0400 Basil Baby basilb...@gmail.com wrote: Noticed lot of A record queries for time-b.netgear.com/time-c.netgear.comon dns servers. Has anyone noticed similar behavior on any of your dns servers? Anyone aware about a known issue with netgear home routers which can create bulk dns queries? https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#NETGEAR_and_the_University_of_Wisconsin.E2.80.93Madison RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588 signature.asc Description: PGP signature
Re: time-b.netgear.com/time-c.netgear.com dns queries
Hmm... Even though similar issue was identified in 2003, looks like still there are devices in market with those old firmwares or similar behavior. sheesh !! :( -Basil On Fri, Sep 7, 2012 at 8:30 PM, Gary E. Miller g...@rellim.com wrote: Yo Basil! On Fri, 7 Sep 2012 20:22:29 -0400 Basil Baby basilb...@gmail.com wrote: Noticed lot of A record queries for time-b.netgear.com/time-c.netgear.comon dns servers. Has anyone noticed similar behavior on any of your dns servers? Anyone aware about a known issue with netgear home routers which can create bulk dns queries? https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#NETGEAR_and_the_University_of_Wisconsin.E2.80.93Madison RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588
Re: time-b.netgear.com/time-c.netgear.com dns queries
On Sep 7, 2012, at 7:44 PM, Basil Baby wrote: Hmm... Even though similar issue was identified in 2003, looks like still there are devices in market with those old firmwares or similar behavior. sheesh !! :( -Basil While NETGEAR does have a history of issues like this, the UofW issue is likely not related to what you are seeing - that issue stemmed from them not using DNS and hardcoding the university's NTP server. The issue you are seeing seems to stem from their NTP code doing the Wrong Thing nonetheless... On Fri, Sep 7, 2012 at 8:30 PM, Gary E. Miller g...@rellim.com wrote: Yo Basil! On Fri, 7 Sep 2012 20:22:29 -0400 Basil Baby basilb...@gmail.com wrote: Noticed lot of A record queries for time-b.netgear.com/time-c.netgear.comon dns servers. Has anyone noticed similar behavior on any of your dns servers? Anyone aware about a known issue with netgear home routers which can create bulk dns queries? https://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse#NETGEAR_and_the_University_of_Wisconsin.E2.80.93Madison RGDS GARY --- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 g...@rellim.com Tel:+1(541)382-8588
Re: time-b.netgear.com/time-c.netgear.com dns queries
On Fri, 07 Sep 2012 20:44:44 -0400, Basil Baby said: Hmm... Even though similar issue was identified in 2003, looks like still there are devices in market with those old firmwares or similar behavior. sheesh !! :( A long long time ago in a network far far away, one of our campus NTP servers was a machine under my desk. That machine was shut down around 2002/06/30 22:49 and we didn't re-assign the IP address ever since *because* it kept getting hit with NTP packets.. Yes, a decade ago. A few months ago I ran a test of how many things were still using it. In the first 15 minutes, 234 different IP's tried to NTP to that address, which has been a black hole for a decade. After 3 hours, I had almost 2,000 IPs. Interestingly enough, the *hostname* is still in use (by another machine under my desk) - and it gets near zero hits. So it's all hardcoded IP addrs not hostnames. pgpyRicbEaGIe.pgp Description: PGP signature
Re: time-b.netgear.com/time-c.netgear.com dns queries
On Fri, Sep 7, 2012 at 7:36 PM, valdis.kletni...@vt.edu wrote: Interestingly enough, the *hostname* is still in use (by another machine under my desk) - and it gets near zero hits. So it's all hardcoded IP addrs not hostnames. And for NTP implementations that use DNS they also often only check DNS on startup too...and lots of people do not maintain their servers...well, except netgear, which just hammers the bugger out of everything (See OP) -- Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds. -- Samuel Butler
