Ownership of Routers on Both Ends of Transnational Links

Tue Apr 16 13:13:30 UTC 2019

"company-ic" and "company-gw" are commonly used names for /30s used for
interconnection to a customer or another carrier. Those routers are likely
owned/managed by Telia/Verizon.

On Tue, Apr 16, 2019 at 8:54 AM Pengxiong Zhu <pzhu011 at ucr.edu> wrote:

> Howdy folks,
>
> We are a group of researchers at UC Riverside conducting some measurement
> about transnational networks. In particular, we are interested in studying
> the ownership of routers on the two sides of transnational links.
>
> We have some concrete questions which we hope someone can shed some light
> on. Basically when we send packets from US/Canada to China, through
> traceroute and the RTT of each hop, we can locate the last hop in the US
> before the packets enter China (*there is a large jump of RTT of 100+ms
> from this hop onwards*). Oftentimes the ownership of such routers is
> ambiguous.
>
> These hops whose IPs seem to belong to US or European ISPs (*according to
> BGP info*) but their reverse DNS names have *chinaunicom* in it, which is
> a Chinese ISP.
> AS1299 Telia Company AB
> 62.115.170.57    name = chinaunicom-ic-341501-sjo-b21.c.telia.net.
> 62.115.33.230    name = chinaunicom-ic-302366-las-bb1.c.telia.net.
> 213.248.73.190  name = chinaunicom-ic-127288-sjo-b21.c.telia.net.
>
> AS701 Verizon Business
> 152.179.103.254  name = chinaunicom-gw.customer.alter.net.
>
> While the following routers, they don't have a reverse DNS name at all,
> which seem to be uncommon if they were managed by US or European ISPs but
> quite common for Chinese ISPs.
> AS6453 TATA COMMUNICATIONS (AMERICA) INC
> 63.243.205.90
> 66.110.59.118
>
> Can anyone confirm that these are indeed managed by the Chinese ISPs (even
> though they are physically located in the US according to the traceroute
> and RTT analysis)?
>
>
> Best,
> Pengxiong Zhu
> Department of Computer Science and Engineering
> University of California, Riverside
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190416/f5a166ef/attachment.html>