Hi all, I found the following prefixes are often originated by many ASNs more than five, wonder if they provide global anycast service, if so what specific service they provide? 12.64.255.0/24 70.37.135.0/24 198.32.176.0/24 199.7.49.0/24 199.7.80.0/24 199.16.93.0/24 199.16.94.0/24 199.16.95.0/24 206.223.115.0/24 Thanks, Yaoqing
-----Original Message----- From: Yaoqing(Joey) Liu [mailto:joey.liuyq@gmail.com] Sent: Monday, May 02, 2011 2:17 PM To: nanog@nanog.org Subject: Suspecious anycast prefixes
Hi all,
I found the following prefixes are often originated by many ASNs more than five, wonder if they provide global anycast service, if so what specific service they provide?
12.64.255.0/24 70.37.135.0/24 198.32.176.0/24 199.7.49.0/24 199.7.80.0/24 199.16.93.0/24 199.16.94.0/24 199.16.95.0/24 206.223.115.0/24
Most of those are for Verisign's DNS resolution services. Definitely nothing to be suspicious about here. Move along. These aren't the droids you are looking for. Stefan Fouant
On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:
I found the following prefixes are often originated by many ASNs more than five, wonder if they provide global anycast service, if so what specific service they provide?
12.64.255.0/24
CERNET.
70.37.135.0/24
Microsoft/Hotmail.
198.32.176.0/24
Yahoo!
199.7.49.0/24
VeriSign.
199.7.80.0/24
VeriSign.
199.16.93.0/24
VeriSign.
199.16.94.0/24
VeriSign.
199.16.95.0/24
VeriSign.
206.223.115.0/24
Yahoo! These to me are all organisations that might reasonably be distributing services using anycast. It's difficult to tell whether all the origin ASes you see for those prefixes are legitimate, of course. It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable. Joe
On Mon, May 2, 2011 at 3:35 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:
I found the following prefixes are often originated by many ASNs more than five, wonder if they provide global anycast service, if so what specific service they provide?
12.64.255.0/24
CERNET.
70.37.135.0/24
Microsoft/Hotmail.
198.32.176.0/24
Yahoo!
as a note, this is bmanning/ep.net exchange space, no? so this could be just people leaking this into their table/global-table by mistake?
On Mon, May 02, 2011 at 08:40:01PM -0400, Christopher Morrow wrote:
On Mon, May 2, 2011 at 3:35 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:
I found the following prefixes are often originated by many ASNs more than five, wonder if they provide global anycast service, if so what specific service they provide?
12.64.255.0/24
CERNET.
70.37.135.0/24
Microsoft/Hotmail.
198.32.176.0/24
Yahoo!
as a note, this is bmanning/ep.net exchange space, no? so this could be just people leaking this into their table/global-table by mistake?
used to be. ep.net has fragmented into little bits. most of the prefixes have been transfered to the clients who were using them, the ones who are still around are outside the ARIN region and there is no clean way to move them given ARIN and other RIR policy. This particular prefix was used as a public exchange, operated by Switch & Data. Not sure what they have done w/ it since then. Switch and Data Management Company LLC NET-PAIX-V4 (NET-198-32-175-0-1) 198.32.175.0 - 198.32.177.255 EP.NET, LLC. NET-EP-176 (NET-198-32-176-0-1) 198.32.176.0 - 198.32.176.255 /bill
On Mon, May 2, 2011 at 23:20, <bmanning@vacation.karoshi.com> wrote:
198.32.176.0/24
Yahoo!
This particular prefix was used as a public exchange, operated by Switch & Data. Not sure what they have done w/ it since then.
Switch and Data Management Company LLC NET-PAIX-V4 (NET-198-32-175-0-1) 198.32.175.0 - 198.32.177.255 EP.NET, LLC. NET-EP-176 (NET-198-32-176-0-1) 198.32.176.0 - 198.32.176.255
Still in-use at the Equinix Palo Alto exchange (former PAIX) https://www.peeringdb.com/private/exchange_view.php?id=7 https://www.peeringdb.com/dns-scan/198-32-176-0-24.txt Andy
Thanks for clarifying this, actually I have a few more blocks with four origin ASNs that I'm not positive if they are anycast prefixes. Please help distinguish them if the provide anycast service. 27.130.0.0/16 58.147.0.0/20 58.147.0.0/17 58.147.16.0/20 58.147.64.0/20 58.147.80.0/20 58.147.96.0/20 58.147.112.0/20 61.237.224.0/20 65.61.188.0/24 69.20.95.0/24 110.164.0.0/16 110.164.48.0/20 110.164.64.0/20 110.164.80.0/20 110.164.176.0/20 112.142.0.0/16 112.143.0.0/16 180.183.0.0/16 198.32.64.0/24 198.32.136.0/24 198.32.175.0/24 202.69.136.0/21 202.99.58.0/24 202.122.116.0/24 203.119.30.0/24 204.79.195.0/24 204.79.197.0/24 206.51.38.0/24 206.223.116.0/24 207.231.241.0/24 208.67.239.0/24 222.35.0.0/18 222.35.248.0/21 222.123.0.0/16 223.204.0.0/16 223.205.0.0/16 Yaoqing On Mon, May 2, 2011 at 11:20 PM, <bmanning@vacation.karoshi.com> wrote:
On Mon, May 2, 2011 at 3:35 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-02, at 21:16, Yaoqing(Joey) Liu wrote:
I found the following prefixes are often originated by many ASNs more
On Mon, May 02, 2011 at 08:40:01PM -0400, Christopher Morrow wrote: than
five, wonder if they provide global anycast service, if so what specific service they provide?
12.64.255.0/24
CERNET.
Microsoft/Hotmail.
198.32.176.0/24
Yahoo!
as a note, this is bmanning/ep.net exchange space, no? so this could be just people leaking this into their table/global-table by mistake?
used to be. ep.net has fragmented into little bits. most of the prefixes have been transfered to the clients who were using them, the ones who are still around are outside the ARIN region and there is no clean way to move them given ARIN and other RIR policy.
This particular prefix was used as a public exchange, operated by Switch & Data. Not sure what they have done w/ it since then.
Switch and Data Management Company LLC NET-PAIX-V4 (NET-198-32-175-0-1) 198.32.175.0 - 198.32.177.255 EP.NET, LLC. NET-EP-176 (NET-198-32-176-0-1) 198.32.176.0 - 198.32.176.255
/bill
On 2011-05-04, at 23:11, Yaoqing(Joey) Liu wrote:
Thanks for clarifying this, actually I have a few more blocks with four origin ASNs that I'm not positive if they are anycast prefixes. Please help distinguish them if the provide anycast service.
You could probably get a good distance towards the answer to this by looking up the prefixes yourself using appropriate whois servers. Enumerating every prefix you see with more than one apparent origin and asking NANOG to type whois for you does not scale very well. Joe
On Wed, May 4, 2011 at 3:15 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-04, at 23:11, Yaoqing(Joey) Liu wrote:
Thanks for clarifying this, actually I have a few more blocks with four origin ASNs that I'm not positive if they are anycast prefixes. Please help distinguish them if the provide anycast service.
You could probably get a good distance towards the answer to this by looking up the prefixes yourself using appropriate whois servers. Enumerating every prefix you see with more than one apparent origin and asking NANOG to type whois for you does not scale very well.
This is definitely a good idea, I'll do it right now. Thanks. Yaoqing
Joe
Hi NANOG, I manually extracted the origins and their org info for the announced block of prefixes. All these prefixes were observed being originated by at most four ASNs simultaneously. I suspect they provide anycast or IXP service, but not positive. Please confirm my conjecture if you know them. Thanks! 27.130.0.0/16 58.147.0.0/20 58.147.0.0/17 58.147.16.0/20 58.147.64.0/20 58.147.80.0/20 58.147.96.0/20 58.147.112.0/20 110.164.0.0/16 110.164.48.0/20 110.164.64.0/20 110.164.80.0/20 110.164.176.0/20 112.143.0.0/16 180.183.0.0/16 202.69.136.0/21 223.204.0.0/16 223.205.0.0/16 AS24326: as-name:TTT-AS-AP|descr:Maxnet, Internet Service Provider, Bangkok|country:TH AS38550: as-name:TTGN-INTER-AS-AP|descr:TTGN , INTERNATIONAL INTERNET GATEWAY, THAILAND|country:TH AS45629: as-name:JASTEL-NETWORK-TH-AP|descr:Jasmine International Tower|country:TH AS45758: as-name:TRIPLETNET-AS-AP|descr:TripleT Internet Internet service provider Bangkok|country:TH 61.237.224.0/20 AS4808:as-name:CHINA169-BJ|descr:CNCGROUP IP network China169 Beijing Province Network|country:CN AS4847:as-name:CNIX-AP|descr:China Networks Inter-Exchange AS9819:as-name:BZNET|descr:Beijing Bozhiruihai Network Technology Co., Ltd.|country:CN AS17772:as-name:CHINACOM|descr:CHINA COMMUNICATIONS SYSTEM Co.,Ltd.|country:CN AS17964: as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network Technologies Co., Ltd.|country:CN AS24138:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong Telecommunication Corporation|CN AS38356:as-name:NETEON|descr:Beijing Neteon Tech Co, Ltd.|country:CN AS45114:as-name:CNNIC-SUNINFO-MDC-AP|descr:Beijing Sunrise Technology Co. Ltd.|country:CN 65.61.188.0/24 69.20.95.0/24 AS10532:ASName: RACKSPACE;OrgName:Rackspace Hosting AS15395:as-name:UNSPECIFIED|descr:UK Rackspace|descr:LONDON office AS27357:ASName: RACKSPACE;OrgName:Rackspace Hosting AS33070:ASName: RMH-14;OrgName:Rackspace Hosting 112.142.0.0/16 222.123.0.0/16 AS24326: as-name:TTT-AS-AP|descr:Maxnet, Internet Service Provider, Bangkok|country:TH AS38550: as-name:TTGN-INTER-AS-AP|descr:TTGN , INTERNATIONAL INTERNET GATEWAY, THAILAND|country:TH AS45629: as-name:JASTEL-NETWORK-TH-AP|descr:Jasmine International Tower|country:TH AS45758: as-name:TRIPLETNET-AS-AP|descr:TripleT Internet Internet service provider Bangkok|country:TH AS45626:as-name:TOPL-AU-AS|descr:Travelex Outsourcing Pty Ltd 5/504 Pacific Highway St Leonards NSW AUS 2065|country:AU 198.32.64.0/24 AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC. AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK AS20144:ASName: L-ROOT;Comment:distributed using Anycast. AS42909: as-name: COMMUNITYDNS;descr: Internet Computer Bureau Ltd 198.32.136.0/24 AS195:OrgName:San Diego Supercomputer Center AS293:OrgName:ESnet|OrgId:ENSN-Z AS1239:OrgName:Sprint AS2914:OrgName:NTT America, Inc. AS7018:OrgName:AT&T Services, Inc. 198.32.175.0/24 AS2497:as-name:IIJ|descr:Internet Initiative Japan Inc. AS2914:OrgName:NTT America, Inc.| AS4323:OrgName:tw telecom holdings, inc. AS5650:OrgName:Frontier Communications of America, Inc. AS6461:OrgName:Abovenet Communications, Inc 202.99.58.0/24 AS4808:as-name:CHINA169-BJ|descr:CNCGROUP IP network China169 Beijing Province Network|country:CN AS6619:as-name:SAMSUNGNETWORKS-AS-KR|descr:Samsung Networks Inc. AS17431:as-name:TONET|descr:Beijing TONEK Information Technology Development Company|country:CN AS17964:as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network Technologies Co., Ltd.|country:CN 202.122.116.0/24 AS17775:as-name:STN-CN|descr:SHANGHAI Guangdian Electronics Group Co.,Ltd|country:CN AS18118:as-name:CITICNET-AP|descr:CITIC Networks Management Co.,Ltd. AS24142:as-name:CNNIC-BennalongNet-AP|descr:Shanghai Bennalong Network Technology Co.,LTD AS38356:as-name:NETEON|descr:Beijing Neteon Tech Co, Ltd.|descr:Room203-204, No.1,737,CaoXi Road North,Shanghai,China|country:CN AS38814:as-name:ASIAMAX-HK-EA-AP|descr:Asiamax Technology Limited VPN Service Provider Hong Kong|country:HK 203.119.30.0/24 AS24151:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center AS24406:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center AS24408:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center AS24410:as-name:CNNIC-CRITICAL-AP|descr:China Internet Network Infomation Center 204.79.195.0/24 AS8068:OrgName:Microsoft Corp AS8069:OrgName:GRYPHON NETWORKS AS8071:OrgName:Microsoft Corp AS8075:OrgName:Microsoft Corp 204.79.197.0/24 AS8068:OrgName:Microsoft Corp AS8069:OrgName:GRYPHON NETWORKS AS8071:OrgName:Microsoft Corp AS8075:OrgName:Microsoft Corp AS12076:OrgName:Hotmail Corporation 206.51.38.0/24 AS3549:OrgName:Hotmail Corporation AS6453:OrgName:Tata Communications AS7911:OrgName:Level 3 Communications, Inc. AS25973:OrgName:Mzima Networks, Inc. 206.223.116.0/24 AS293:OrgName:ESnet AS1280:OrgName:Internet Systems Consortium, Inc. AS2914:OrgName:NTT America, Inc. AS6461:OrgName:Abovenet Communications, Inc AS23352:OrgName:Server Central Network 207.231.241.0/24 AS101:OrgName:University of Washington AS226:OrgName:Los Nettos AS293:OrgName:ESnet AS14221:OrgName:University of Washington 208.67.239.0/24 AS11588:OrgName:Highwinds Network Group, Inc. AS23148:OrgName:TERRENAP DATA CENTERS, INC. AS29045:IT ACTION - Managed Hosting AS40009:OrgName:BitGravity, Inc. 222.35.0.0/18 AS4808:as-name:CHINA169-BJ|descr:CNCGROUP IP network China169 Beijing Province Network|country:CN AS4847:as-name:CNIX-AP|descr:China Networks Inter-Exchange|descr:Using International Link at Beijing AS9819:as-name:BZNET|descr:Beijing Bozhiruihai Network Technology Co., Ltd.|country:CN AS17964:as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network Technologies Co., Ltd.|country:CN AS24138:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong Telecommunication Corporation|descr:Beijing branch IDC network|country:CN AS38356:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong Telecommunication Corporation|descr:Beijing branch IDC network|country:CN AS45114:as-name:CNNIC-SUNINFO-MDC-AP|descr:Beijing Sunrise Technology Co. Ltd. 222.35.248.0/21 AS4847:as-name:CNIX-AP|descr:China Networks Inter-Exchange|descr:Using International Link at Beijing AS9802:as-name:CHINA-ABITCOOL|descr:Abitcool(China) Inc.|country:CN AS9803:as-name:JINGXUN|descr:Beijing Jingxun Public Information Technology Co., Ltd|country:CN AS17964:as-name:DXTNET|descr:Beijing Dian-Xin-Tong Network Technologies Co., Ltd.|country:CN AS18118:as-name:CITICNET-AP|descr:CITIC Networks Management Co.,Ltd. AS24138:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong Telecommunication Corporation|descr:Beijing branch IDC network|country:CN AS38356:as-name:CRNET_BJ_IDC-CNNIC-AP|descr:China Tietong Telecommunication Corporation|descr:Beijing branch IDC network|country:CN: Yaoqing On Wed, May 4, 2011 at 3:20 PM, Yaoqing(Joey) Liu <joey.liuyq@gmail.com> wrote:
On Wed, May 4, 2011 at 3:15 PM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-04, at 23:11, Yaoqing(Joey) Liu wrote:
Thanks for clarifying this, actually I have a few more blocks with four origin ASNs that I'm not positive if they are anycast prefixes. Please help distinguish them if the provide anycast service.
You could probably get a good distance towards the answer to this by looking up the prefixes yourself using appropriate whois servers. Enumerating every prefix you see with more than one apparent origin and asking NANOG to type whois for you does not scale very well.
This is definitely a good idea, I'll do it right now. Thanks.
Yaoqing
Joe
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On May 4, 2011, at 8:23 PM, Yaoqing(Joey) Liu wrote:
Hi NANOG,
I manually extracted the origins and their org info for the announced block of prefixes. All these prefixes were observed being originated by at most four ASNs simultaneously. I suspect they provide anycast or IXP service, but not positive. Please confirm my conjecture if you know them.
The IXP subnets are here: http://www.pch.net/ixpdir/ip_city_country.pl -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJNwlM7AAoJEG+kcEsoi3+HXD8P/0Ufpu3KDRZsAzbV6PVcUjIU HtGl2aTTkPntLcaEZgItRA1m9GBbiIdDBRsQrR2IDU9K9py5MEhnllmC+JojJpJ9 xtrxEnisLNiZfCHhy0AHHhHZfbvu9UWpXbHVTuezL1HyRTCscmdyQWJtGYug59p6 beI9kVlP7laOY6pyrb2rXCDPs0zaVqof4XwWlD5HQMQJcdw5GyyON9ddz7WXROk5 Q4be9G7w79L164r4nkDDTreZ7yWGqUFSGwXYTRpkItbBgHQtW3fnWKIrVbRl5a3X t/3og2OmysYY5g05IjP7Afg0+IPopyS9Kwa1SvgVe+Qu0SX8nZAjhOcSKtMgmPwP CdzyK6Mv20+CkwcmAejG44dZ4NWY/Zog8iJ4fDDmgX8CxqGduoG0cLmvXPg9iqz9 qpxuD6EpqYOXKVFYRy3BOao72PJJgURpd2JGYHw2OiWkOTBP/KkJkOWb4pawDR2B q06Zt/XyHqQhFwu4oUq63wOFcsUHn3poEjEtG2kPyYH4R4gUsZJvdXGOXpw3kq52 z3437Nf0fMnGeu+SKpINQ14GXKWzpxTtwRxDrDBlxyweLsA8ZTgzDxgCljkmO4wc XF67uAGlHdu3eXCFHslW8tTrizjWl4fe95qej5oDuNi4okmkU6E6po6ohfphvxPP Uu2gSRvFtzCmZGUypu9P =BV20 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On May 5, 2011, at 12:35 AM, Bill Woodcock wrote:
I suspect they provide … IXP service, but not positive.
The IXP subnets are here: http://www.pch.net/ixpdir/ip_city_country.pl
It has been pointed out to me that not _all_ IXP subnets are there, which is quite true. That list is the subset of the full list of IXPs ( http://pch.net/ixpdir ) for which we have the IPv4/IPv6 subnet information. If anyone spots an IXP that's missing from that list, it's because we don't have the IP subnets. We would love to be as complete as possible, so if anyone has any corrections or additions, we'd be very grateful to hear them. Thanks, -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iQIcBAEBCAAGBQJNwlcLAAoJEG+kcEsoi3+H4P8P/Rp6y2Vtch2nEmfT1NwVgDlQ GaBG323c2P1yFSPxnbznunAi2em9nBMI9ub+ubBAAKVlTVTg4boFT5XeCHVbhN79 Y7IUZx9CUMNpPz1REMD3b5Vmox79zEwi8R43WGsohLkATClclujtNiE9IByjFhYH DmVI567HbV9VamcZMnoX8u78snJ580GXIbB2crq6skcCtml5xhsNgpTzC29vBuVN RQODgJOHa8zNVLvQWO4jvgGd2Uy7/lMfhy0qoe9TOizJ3oZOAKK5tPWnnhdo1Q30 /Jm49heT3HJ8RgT/i/Q7eFJYgLaecvRN9/F6UlYSK2OAyc/FIDg2IhGWiPHBu1v9 MgAgSa9fjY+oVzac3ZppcE9moyur1cajlUt3QVEMFXX7uaEeDKWvAuKqeH5qpw9l D5x8aIUSlXAHfPVVNhNiifX6RNQ/WEDxQBrW9FuKp77b0MPPjXK6DWSZfW07UMq1 T5mdvdIuXg5hodSYIvMGsiJ/B5U7pVmCmfZdCP9fWDQjyWs/cp2tJAJ71Wefr2cO QEDuJ+X9wEJBkfMuZiNZlJH25MncspBq7GtxaYNttUoZnOTD3apmwzZia4doJNJR bCa3P5SQNwyMLqTP08DHBEZQQTd29cY6ORCtuDxqrkYCTh6QpAIxDLVlHrAYPuBG 8GZ9yGcQ4pJXak+4KRbD =q4ag -----END PGP SIGNATURE-----
On Thu, May 5, 2011 at 2:35 AM, Bill Woodcock <woody@pch.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On May 4, 2011, at 8:23 PM, Yaoqing(Joey) Liu wrote:
Hi NANOG,
I manually extracted the origins and their org info for the announced block of prefixes. All these prefixes were observed being originated by at most four ASNs simultaneously. I suspect they provide anycast or IXP service, but not positive. Please confirm my conjecture if you know them.
The IXP subnets are here:
We're using these IXP prefixes and they are very helpful, but I'm afraid they are not complete. For example, I couldn't find any IXP prefix from the mainland of China, such as Beijing and Shanghai. Yaoqing
-Bill
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin)
iQIcBAEBCAAGBQJNwlM7AAoJEG+kcEsoi3+HXD8P/0Ufpu3KDRZsAzbV6PVcUjIU HtGl2aTTkPntLcaEZgItRA1m9GBbiIdDBRsQrR2IDU9K9py5MEhnllmC+JojJpJ9 xtrxEnisLNiZfCHhy0AHHhHZfbvu9UWpXbHVTuezL1HyRTCscmdyQWJtGYug59p6 beI9kVlP7laOY6pyrb2rXCDPs0zaVqof4XwWlD5HQMQJcdw5GyyON9ddz7WXROk5 Q4be9G7w79L164r4nkDDTreZ7yWGqUFSGwXYTRpkItbBgHQtW3fnWKIrVbRl5a3X t/3og2OmysYY5g05IjP7Afg0+IPopyS9Kwa1SvgVe+Qu0SX8nZAjhOcSKtMgmPwP CdzyK6Mv20+CkwcmAejG44dZ4NWY/Zog8iJ4fDDmgX8CxqGduoG0cLmvXPg9iqz9 qpxuD6EpqYOXKVFYRy3BOao72PJJgURpd2JGYHw2OiWkOTBP/KkJkOWb4pawDR2B q06Zt/XyHqQhFwu4oUq63wOFcsUHn3poEjEtG2kPyYH4R4gUsZJvdXGOXpw3kq52 z3437Nf0fMnGeu+SKpINQ14GXKWzpxTtwRxDrDBlxyweLsA8ZTgzDxgCljkmO4wc XF67uAGlHdu3eXCFHslW8tTrizjWl4fe95qej5oDuNi4okmkU6E6po6ohfphvxPP Uu2gSRvFtzCmZGUypu9P =BV20 -----END PGP SIGNATURE-----
On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
Hi NANOG,
198.32.64.0/24 AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC. AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK AS20144:ASName: L-ROOT;Comment:distributed using Anycast. AS42909: as-name: COMMUNITYDNS;descr: Internet Computer Bureau Ltd
according to Filip, this is -NOT- supposed to be anycast. the only legal origin ASN is 4555. these other ASNs have hijacked the prefix. /bill
On 2011-05-05, at 11:46, bmanning@vacation.karoshi.com wrote:
On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
198.32.64.0/24 AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC. AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK AS20144:ASName: L-ROOT;Comment:distributed using Anycast. AS42909: as-name: COMMUNITYDNS;descr: Internet Computer Bureau Ltd
according to Filip, this is -NOT- supposed to be anycast. the only legal origin ASN is 4555.
these other ASNs have hijacked the prefix.
The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it. Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false. Joe
On Thu, 5 May 2011 11:54:17 +0300 Joe Abley <jabley@hopcount.ca> wrote:
Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
Furthermore, that exchange prefixes may often appear to be anycast is not unusual. Those prefixes are often originated by multiple disparate networks who are connected to the exchange. In a lightning talk I did at NANOG 41, I talked about mapping peering relationships at exchanges. When I noted that these prefixes are often announced by exchange participants, Louie Lee explained that some of his participants often announce the space to their transit customers so that monitoring and troubleshooting tools don't cause confusion (e.g. traceroutes). John
On Thu, 5 May 2011 11:54:17 +0300 Joe Abley <jabley@hopcount.ca> wrote:
Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
Furthermore, that exchange prefixes may often appear to be anycast is not unusual. Those prefixes are often originated by multiple disparate networks who are connected to the exchange. You mean that many different exchange points are using the same set of
On Thu, May 5, 2011 at 8:10 AM, John Kristoff <jtk@cymru.com> wrote: prefixes as anycast service in different physical locations? That sounds interesting to me. Yaoqing In a lightning talk I did
at NANOG 41, I talked about mapping peering relationships at exchanges. When I noted that these prefixes are often announced by exchange participants, Louie Lee explained that some of his participants often announce the space to their transit customers so that monitoring and troubleshooting tools don't cause confusion (e.g. traceroutes).
John
On Thu, 5 May 2011 11:48:31 -0500 "Yaoqing(Joey) Liu" <joey.liuyq@gmail.com> wrote:
Furthermore, that exchange prefixes may often appear to be anycast is not unusual. Those prefixes are often originated by multiple disparate networks who are connected to the exchange.
You mean that many different exchange points are using the same set of prefixes as anycast service in different physical locations?
No, just that you see route announcements for the exchange prefix coming from multiple different origins and paths. So it may appear to be anycast, but in reality would function as if it were multihomed with the route originating from multiple providers. Additionally reachability to addresses within the prefix may differ as a result of the peering relationships from the perspective of the path taken to get there. John
On Thu, May 05, 2011 at 11:48:31AM -0500, Yaoqing(Joey) Liu wrote:
On Thu, 5 May 2011 11:54:17 +0300 Joe Abley <jabley@hopcount.ca> wrote:
Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
Furthermore, that exchange prefixes may often appear to be anycast is not unusual. Those prefixes are often originated by multiple disparate networks who are connected to the exchange. You mean that many different exchange points are using the same set of
On Thu, May 5, 2011 at 8:10 AM, John Kristoff <jtk@cymru.com> wrote: prefixes as anycast service in different physical locations? That sounds interesting to me.
that has been a fairly common practice for nearly 15 years. /bill
Yaoqing
In a lightning talk I did
at NANOG 41, I talked about mapping peering relationships at exchanges. When I noted that these prefixes are often announced by exchange participants, Louie Lee explained that some of his participants often announce the space to their transit customers so that monitoring and troubleshooting tools don't cause confusion (e.g. traceroutes).
John
On Thu, May 5, 2011 at 3:54 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-05, at 11:46, bmanning@vacation.karoshi.com wrote:
On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
198.32.64.0/24 AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC. AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK AS20144:ASName: L-ROOT;Comment:distributed using Anycast. AS42909: as-name: COMMUNITYDNS;descr: Internet Computer Bureau Ltd
according to Filip, this is -NOT- supposed to be anycast. the only legal origin ASN is 4555.
these other ASNs have hijacked the prefix.
The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
This is based on last four year's data(2007-2010)collected from more than 120 peers around the world. Today it may be not announced anymore, but it used to be announced by the four ASNs simultaneously. I just checked the detailed info about this prefix, here it is about the prefix: 198.32.64.0/24 (ASN: average peers announcing this prefix:existing period:total appearing days: MOAS period: total appearing days) 4555:4.94:20080318-20080506:50:20080318-20080506:50 9584:3.07:20080402-20080513:42:20080402-20080513:42 20144:79.44:20070101-20080501:487:20071215-20080501:138 42909:26.39:20071215-20080515:152:20071215-20080513:150
MY source data
Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
This needs to do further analysis to confirm if it was hijacked Yaoqing
Joe
On Thu, May 05, 2011 at 09:36:50AM -0500, Yaoqing(Joey) Liu wrote:
On Thu, May 5, 2011 at 3:54 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-05, at 11:46, bmanning@vacation.karoshi.com wrote:
On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
198.32.64.0/24 AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC. AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK AS20144:ASName: L-ROOT;Comment:distributed using Anycast. AS42909: as-name: COMMUNITYDNS;descr: Internet Computer Bureau Ltd
according to Filip, this is -NOT- supposed to be anycast. the only legal origin ASN is 4555.
these other ASNs have hijacked the prefix.
The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
This is based on last four year's data(2007-2010)collected from more than 120 peers around the world. Today it may be not announced anymore, but it used to be announced by the four ASNs simultaneously. I just checked the detailed info about this prefix, here it is about the prefix: 198.32.64.0/24 (ASN: average peers announcing this prefix:existing period:total appearing days: MOAS period: total appearing days) 4555:4.94:20080318-20080506:50:20080318-20080506:50 9584:3.07:20080402-20080513:42:20080402-20080513:42 20144:79.44:20070101-20080501:487:20071215-20080501:138 42909:26.39:20071215-20080515:152:20071215-20080513:150
MY source data
Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
This needs to do further analysis to confirm if it was hijacked
Yaoqing
Joe
in that period, it was originated by these parties, most of whom were authorized to announce it. at this time, only one ASN is authorized to announce, and its not. not sure how you expect to determine, with simple routing data, if the prefix was hijacked. you would need to see the letters of authorization or contracts of service/carriage to determine if an ASN was impropperly announcing. for that matter, why do you care what occured years ago? the Internet is an evolving, fluid media and things change all the time. if you want particulars on this prefix, i should have the authoritative data, since I was the registered contact for both the prefix and the ASN in that period and can pull the records. Contact me offline for details on access. /bill
On Thu, May 5, 2011 at 1:24 PM, <bmanning@vacation.karoshi.com> wrote:
On Thu, May 05, 2011 at 09:36:50AM -0500, Yaoqing(Joey) Liu wrote:
On Thu, May 5, 2011 at 3:54 AM, Joe Abley <jabley@hopcount.ca> wrote:
On 2011-05-05, at 11:46, bmanning@vacation.karoshi.com wrote:
On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
198.32.64.0/24 AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC. AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK AS20144:ASName: L-ROOT;Comment:distributed using Anycast. AS42909: as-name: COMMUNITYDNS;descr: Internet Computer Bureau Ltd
according to Filip, this is -NOT- supposed to be anycast. the only legal origin ASN is 4555.
these other ASNs have hijacked the prefix.
The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
This is based on last four year's data(2007-2010)collected from more than 120 peers around the world. Today it may be not announced anymore, but it used to be announced by the four ASNs simultaneously. I just checked the detailed info about this prefix, here it is about the prefix: 198.32.64.0/24 (ASN: average peers announcing this prefix:existing period:total appearing days: MOAS period: total appearing days) 4555:4.94:20080318-20080506:50:20080318-20080506:50 9584:3.07:20080402-20080513:42:20080402-20080513:42 20144:79.44:20070101-20080501:487:20071215-20080501:138 42909:26.39:20071215-20080515:152:20071215-20080513:150
MY source data
Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
This needs to do further analysis to confirm if it was hijacked
Yaoqing
Joe
in that period, it was originated by these parties, most of whom were authorized to announce it. at this time, only one ASN is authorized to announce, and its not.
not sure how you expect to determine, with simple routing data, if the prefix was hijacked. you would need to see the letters of authorization or contracts of service/carriage to determine if an ASN was impropperly announcing.
for that matter, why do you care what occured years ago? the Internet is an evolving, fluid media and things change all the time. if you want particulars on this prefix, i should have the authoritative data, since I was the registered contact for both the prefix and the ASN in that period and can pull the records. Contact me offline for details on access.
I might not explain the background clearly and confused people. We're doing research on multiple origin AS issue, and we want to confirm if our inference is correct based on history data we collected. For example, we found several hundreds of prefixes with multiple origins more than two, some of them were inferred as anycast using our methodology, but we're not positive with the conjecture, so we want to find the ground truth from operators. Thanks for the detailed explanations. Thanks, Yaoqing
/bill
I might not explain the background clearly and confused people. We're doing research on multiple origin AS issue, and we want to confirm if our inference is correct based on history data we collected. For example, we found several hundreds of prefixes with multiple origins more than two, some of them were inferred as anycast using our methodology, but we're not positive with the conjecture, so we want to find the ground truth from operators. Thanks for the detailed explanations.
the ucla obsession with multiple-origin announcements has a long history. the problem is that you think you can make something that looks forward. but how will you decide if tomorrow's announcement of P from A0 and A1 is anycast, ops kink, or an actual mis-announcement? randy
On Thu, May 05, 2011 at 11:54:17AM +0300, Joe Abley wrote:
On 2011-05-05, at 11:46, bmanning@vacation.karoshi.com wrote:
On Wed, May 04, 2011 at 10:23:12PM -0500, Yaoqing(Joey) Liu wrote:
198.32.64.0/24 AS4555:ASName: EP0-BLK-ASNBLOCK-5;OrgName:Almond Oil Process, LLC. AS9584:as-name:GENESIS-AP|descr:Diyixian.com Limited|country:HK AS20144:ASName: L-ROOT;Comment:distributed using Anycast. AS42909: as-name: COMMUNITYDNS;descr: Internet Computer Bureau Ltd
according to Filip, this is -NOT- supposed to be anycast. the only legal origin ASN is 4555.
these other ASNs have hijacked the prefix.
The source data above may be old, or simply wrong -- I don't see *any* AS originating that prefix right now, and I can confirm specifically AS20144 is not configured to originate it.
Perhaps I'm misunderstanding the original question, but the assertion that anybody is hijacking that particular prefix seems false.
Joe
back in the olden days, this prefix was in active use and for a period of time was anycast. methinks Joey was refering to routing -today-... one might ask the question, how can you tell when an un-authorized party originates routes (yours), from your ASN - their router of course.... /bill
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 2, 2011, at 12:35 PM, Joe Abley wrote:
It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable.
I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice for me to originate my address space from more than 8,000 different ASNs, when I currently do just fine advertising it from three. I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2/1jEACgkQGvQy4xTRsBH89wCfSD9h/1v/jNtKwk18XP4In6cE Z3wAniPsu6QvtMfHLlz/Jn7tGUwRzQvX =iuXT -----END PGP SIGNATURE-----
On 5/3/2011 6:17 AM, Bill Woodcock wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 2, 2011, at 12:35 PM, Joe Abley wrote:
It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see<http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable. I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice for me to originate my address space from more than 8,000 different ASNs, when I currently do just fine advertising it from three. I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common.
-Bill
+1 We are not convinced and are not planning on implementing this draft either. -DM
On May 3, 2011, at 6:17 AM, Bill Woodcock wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 2, 2011, at 12:35 PM, Joe Abley wrote:
It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable.
I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice
'A', not 'the', for the reasons conveyed in the draft (e.g., control plane discriminator, RPKI foundations, etc..). If you don't like it, don't do it, it's certainly easier to not do it.
for me to originate my address space from more than 8,000 different ASNs,
8000 is a very large number.
when I currently do just fine advertising it from three.
"You" as a service operator do just fine, and it's surely much simpler from a configuration and provisioning standpoint. But what about those folks that consume the service, and have no indication of which node they may be utilizing from an Internet control plane perspective, or all the associated derivatives?
I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common.
'clueless people' wouldn't care which node they utilize, where it resides, or what other attributes might exist and be associated with it. Providing a discriminator in the control plane for the consumer of critical network services might well be of utility to some. -danny
On 5/5/2011 8:59 AM, Danny McPherson wrote:
On May 3, 2011, at 6:17 AM, Bill Woodcock wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see<http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable. I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice 'A', not 'the', for the reasons conveyed in the draft (e.g., control
On May 2, 2011, at 12:35 PM, Joe Abley wrote: plane discriminator, RPKI foundations, etc..). If you don't like it, don't do it, it's certainly easier to not do it.
for me to originate my address space from more than 8,000 different ASNs, 8000 is a very large number.
when I currently do just fine advertising it from three. "You" as a service operator do just fine, and it's surely much simpler from a configuration and provisioning standpoint. But what about those folks that consume the service, and have no indication of which node they may be utilizing from an Internet control plane perspective, or all the associated derivatives?
In a properly functioning system - folks that consume the service don't need to know which node they are utilizing. Providing the capability for well behaved customers to select/prefer a particular node over another would also allow evildoers to select/prefer a particular node over others - thereby increasing the attack surface of this node, yes? Not a fan.
I'd much rather there not exist a document that clueless people can point at and claim is a "best common practice" when it's neither best nor common. 'clueless people' wouldn't care which node they utilize, where it resides, or what other attributes might exist and be associated with it. Providing a discriminator in the control plane for the consumer of critical network services might well be of utility to some.
-danny
On May 5, 2011, at 9:43 AM, David Miller wrote:
In a properly functioning system - folks that consume the service don't need to know which node they are utilizing.
Right, it doesn't matter IF things are functioning properly. If they're not, however...
Providing the capability for well behaved customers to select/prefer a particular node over another would also allow evildoers to select/prefer a particular node over others - thereby increasing the attack surface of this node, yes?
This isn't expressly about the capability to allow consumers to select one node of another, it's about transparency in which nodes they're using being visible in the control plane - there's no indication of that today. As for attack surface expanse, no. You could largely already accomplish something of this sort today in the elements of the forwarding path you influence if you were an evildoer aiming to do such a thing. -danny
On 5/5/2011 11:39 AM, Danny McPherson wrote:
On May 5, 2011, at 9:43 AM, David Miller wrote:
In a properly functioning system - folks that consume the service don't need to know which node they are utilizing. Right, it doesn't matter IF things are functioning properly. If they're not, however...
IF things are not functioning properly and the operator of the service is depending on end consumers of the service to notify them of which node is malfunctioning, then it is time for the operator of the service to go back to the drawing board and improve their monitoring and failure resolution systems.
Providing the capability for well behaved customers to select/prefer a particular node over another would also allow evildoers to select/prefer a particular node over others - thereby increasing the attack surface of this node, yes? This isn't expressly about the capability to allow consumers to select one node of another, it's about transparency in which nodes they're using being visible in the control plane - there's no indication of that today.
...but it *is* expressly about selection of nodes... From the Introduction of - http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00.txt : "Furthermore, control plane discriminators should exist to enable operators to know toward which of a given set of instances a query is being directed, and to enable detection and alerting capabilities when this changes. Such discriminators may also be employed to enable anycast node preference or filtering keys, should local operational policy require it."
As for attack surface expanse, no. You could largely already accomplish something of this sort today in the elements of the forwarding path you influence if you were an evildoer aiming to do such a thing.
I disagree (see above). -DM
On May 5, 2011, at 11:58 AM, David Miller wrote:
IF things are not functioning properly and the operator of the service is depending on end consumers of the service to notify them of which node is malfunctioning, then it is time for the operator of the service to go back to the drawing board and improve their monitoring and failure resolution systems.
Hehh.. As you well know, there are many folks that invest enormous time and money into this, and yet realize, that ultimately, there are influencers in the routing system and data path between the client and the service node that the service operators can't control. All they can do is best enable service consumers to identify and incorporate controls that are optimal for their operating environments.
...but it *is* expressly about selection of nodes...
It enables visibility and transparency which can be employed to inform measurement and detection systems. IF / how an operator chooses to apply controls based on that information (e.g., drop a prefix originated from an unauthorized origin AS or leaked via a known bad path) that's certainly their prerogative. -danny
On Thu, May 05, 2011 at 12:27:04PM -0400, Danny McPherson wrote:
On May 5, 2011, at 11:58 AM, David Miller wrote:
IF things are not functioning properly and the operator of the service is depending on end consumers of the service to notify them of which node is malfunctioning, then it is time for the operator of the service to go back to the drawing board and improve their monitoring and failure resolution systems.
Hehh.. As you well know, there are many folks that invest enormous time and money into this, and yet realize, that ultimately, there are influencers in the routing system and data path between the client and the service node that the service operators can't control. All they can do is best enable service consumers to identify and incorporate controls that are optimal for their operating environments.
...but it *is* expressly about selection of nodes...
It enables visibility and transparency which can be employed to inform measurement and detection systems. IF / how an operator chooses to apply controls based on that information (e.g., drop a prefix originated from an unauthorized origin AS or leaked via a known bad path) that's certainly their prerogative.
-danny
hum... from the service operator perspective, it seems that the operating mode is to reduce latency for the requesting client. from the client perspective, latency may not be the most important thing too bad the anycast fabrics only take the needs of the service operator into account... :( /bill
It's perhaps worth noting that there is work in the IETF to recommend that every prefix originated as part of an anycast cloud uses a unique origin AS (see <http://tools.ietf.org/html/draft-ietf-grow-unique-origin-as-00>). I'm not personally convinced of the arguments in the draft, but mentioning it in this thread seems reasonable. I'm also not convinced of the arguments in the draft, since it argues that it would be a best-practice 'A', not 'the', for the reasons conveyed in the draft (e.g., control plane discriminator, RPKI foundations, etc..).
danny, could you explain why this has anything to do with the rpki and origin validation? randy
participants (11)
-
Andrew Koch -
Bill Woodcock -
bmanning＠vacation.karoshi.com -
Christopher Morrow -
Danny McPherson -
David Miller -
Joe Abley -
John Kristoff -
Randy Bush -
Stefan Fouant -
Yaoqing(Joey) Liu