- Test - lists.nanog.org

Rate-limiting BCOP?
by Bryan Holloway 31 May '20

31 May '20

I'm curious if the community would be willing to share their best-practices and/or recommendations and thoughts on how they handle situations where a customer buys X amount of bandwidth, but the physical link is capable of Y, where Y > X. (Yes, I speak of policy-maps, tx/rx-queues, etc.) For example, it might be arguably common to aggregate customer links Layer 2, and then push them upstream to where they anchor Layer 3. That Layer 2 <-> Layer 3 could be a couple of meters or several kilometers. So, as I see it, my options are: * Rate-limit at the Layer 2 switch for both customer ingress/egress, * Rate-limit at the Layer 3 router upstream, i/e, or * Some combination thereof? E.g.: Rate-limit my traffic towards the customer closer to the core, and rate-limit ingress closer to the edge? I've done all three on some level in my travels, but in the past it's also been oftentimes vendor-centric which hindered a scalable or "templateable" solution. (Some things police in only one direction, or only well in one direction, etc.) In case someone is interested in a tangible example, imagine an Arista switch and an ASR9k router. :) Thoughts?

5 8

Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Etienne-Victor Depasquale 31 May '20

31 May '20

Pascal, thank you, the draft at https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ is very informative. You hit the nail on the head with your suggestion of confusion between the congruence of link and subnet. However, I followed one of the references (RFC4903) in your draft and it does not help that it (RFC4903) points to RFC4291's assertion that: "Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link" RFC4903 further states that: "clearly, the notion of a multi-link subnet would be a change to the existing IP model.". I confess: your assertion in the draft that: "In Route-Over Multi-link subnets (MLSN) [RFC4903], routers federate the links between nodes that belong to the subnet, the subnet is not on-link and it extends beyond any of the federated links" is news to me. Best regards, Etienne On Sat, May 30, 2020 at 1:39 PM Pascal Thubert (pthubert) < pthubert(a)cisco.com> wrote: > Hello Etienne Victor > > Maybe you’re confusing link and a subnet? > > This is discussed at length here: > > https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/ > > RPL can route inside a subnet using host routes. This is how a multi link > subnet can be made to work... > > Please let me know if the draft above helped and whether it is clear > enough. The best way for that discussion would be to cc 6MAN. > > Keep safe, > > Pascal > > Le 30 mai 2020 à 10:03, Etienne-Victor Depasquale <edepa(a)ieee.org> a > écrit : > > > Thank you Carsten, and thank you Pacal. Your replies are valuable and > packed with insight. > > I'll wrap up with how I interpret RPL's behaviour in terms of IP hops. > > On one hand, RFC6775 defines a route-over topology as follows: > "A topology where hosts are connected to the 6LBR through the use of > intermediate layer-3 (IP) routing. > Here, hosts are typically multiple IP hops away from a 6LBR. > The route-over topology typically consists of a 6LBR, a set of 6LRs, and > hosts." > If RPL is route-over by definition, then RFC6775 would imply that there > are typically multiple IP hops between a leaf and the border router. > > On the other hand, there at least two contradictions (which I justify > after stating them): > (a) RFC6550 states that "RPL also introduces the capability to bind a > subnet together with a common prefix and to route within that subnet." > (b) Reduction of a DODAG to a single subnet prefix, albeit only only one > parent-child relationship deep, is clearly shown at Contiki-NG's Github > page (deep dive section). > > The hinge on which my understanding revolves is that an IP hop traverses a > router and ***results in a change of prefix of the link on which the packet > travels*** : > > --------<incoming packet; link prefix = p1>------><router> > --------<outgoing packet; link prefix = p2>------> > > With RPL, the "hop" would look like as shown below: > > --------<incoming packet; link prefix = p1>------<router> > --------<outgoing packet; link prefix = p1>------ > > There seems to be a change in the meaning associated with "IP hop". > I guess that I can reconcile both cases through the observation that RPL > actually does apply to a single, NBMA link and therefore the IP prefix > ***is*** the same. > Then again, calling the RPL device involved in the packet forwarding by > the name "router" feels like an uncomfortable stretch. > Don't routers sit at the meeting point of different layer 2 links? > > > Cheers, > > Etienne > > On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) < > pthubert(a)cisco.com> wrote: > >> Hello Etienne >> >> You may see ND as the host to * interface for any network and RPL as the >> router to router interface when the network is NBMA. >> >> Some of us cared about the interworking. >> >> Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure. >> >> Keep safe, >> >> Pascal >> >> > Le 29 mai 2020 à 20:28, Carsten Bormann <cabo(a)tzi.org> a écrit : >> > >> > Hi Etienne, >> > >> > I’m also not sure many of the classical network operators assembled in >> NANOG work with 6LoWPANs today, but I still can answer your question. >> > >> >> While trying to build a holistic view of LoWPANs, I'm consulting the >> IETF's informational and standards documents. >> >> >> >> I'm struck by the impression that, despite the significance of >> RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy >> networks (LLNs), >> >> it is largely ignored by RFC6550 (RPL), with little to no reference to >> the ontological plane created in RFC6775's terminology section. >> > >> > Yes, you could say that. >> > >> > ND (Neighbor discovery) describes interfaces between hosts and between >> hosts and routers. >> > 6LoWPAN-ND does not use host-to-host interfaces (different from >> Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in >> the L — on-link — bit, which isn’t set in 6LoWPAN-ND). >> > >> > RFC 6550 was completed at a time when many people who came in from the >> WSN (wireless sensor network) world thought they could get away with a >> network that is wholly composed of routers. >> > Even the “leaf” nodes in the RPL world were participating in the >> routing protocol and therefore didn’t really need a host-router interface. >> There was no separate host-router interface in that world, because there >> were no non-router hosts. >> > >> >> (a) router advertisements and router solicitations are substituted by >> DAG information objects (DIO) and DAG information solicitations (DIS) >> > >> > Right, DIO and DAO are router-to-router messages. If there are no >> hosts (and routers don’t bootstrap themselves as hosts), you don’t need ND. >> > >> >> (b) the terms "mesh-under" and "route-over" (widely cited), defined in >> RFC6775, are absent from RFC6550 >> > >> > RFC6550 is route over by definition. Actually, the term was coined by >> the people working closely with the RPL development; RFC 6775 does >> appropriate it as 6LoWPAN-ND is applicable in either case. >> > >> >> (c) jarringly: RFC6775 describes the route-over topologies as >> multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the >> same IPv6 prefix as their border router - no multiple IP hops. >> > >> > I’m not sure where you get this interpretation: RFC 6550 (RPL) is very >> much about IP hops. >> > Maybe you mean the address architecture that was defined explicitly in >> RFC 6775; RFC 6550 does not really say much about addresses. >> > >> > Note that the RPL people have since proceeded to (at least partially) >> embrace the host-router concept from the IP architecture; RFC 8505 is an >> update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people. >> > >> > I have CCed Pascal Thubert who, as a co-author to all three RFCs, >> certainly will have another perspective on this. >> > >> > Grüße, Carsten >> > >> > > > -- > Ing. Etienne-Victor Depasquale > Assistant Lecturer > Department of Communications & Computer Engineering > Faculty of Information & Communication Technology > University of Malta > Web. https://www.um.edu.mt/profile/etiennedepasquale > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale

1 0

Clueful Domain Name Expert from Network Solutions Needed
by james jones 30 May '20

30 May '20

Greetings, Hope everyone is staying healthy and safe. I am really looking for help from someone clueful at Network Solutions. I am having major issues with transferring a domain away from them. Turns out the primary contact on the account has been the same for over a 15+ years. That person has not been involved with the organization for decade and was never updated. I have been getting the run around from customer service to for 4 months trying to update the primary contact. I have provided all the information that has been requested multiple times . Is there anyone on the list that might be able to help. P.S. Sorry for have to do this here. -James

1 0

Re: RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Etienne-Victor Depasquale 30 May '20

30 May '20

Thank you Carsten, and thank you Pacal. Your replies are valuable and packed with insight. I'll wrap up with how I interpret RPL's behaviour in terms of IP hops. On one hand, RFC6775 defines a route-over topology as follows: "A topology where hosts are connected to the 6LBR through the use of intermediate layer-3 (IP) routing. Here, hosts are typically multiple IP hops away from a 6LBR. The route-over topology typically consists of a 6LBR, a set of 6LRs, and hosts." If RPL is route-over by definition, then RFC6775 would imply that there are typically multiple IP hops between a leaf and the border router. On the other hand, there at least two contradictions (which I justify after stating them): (a) RFC6550 states that "RPL also introduces the capability to bind a subnet together with a common prefix and to route within that subnet." (b) Reduction of a DODAG to a single subnet prefix, albeit only only one parent-child relationship deep, is clearly shown at Contiki-NG's Github page (deep dive section). The hinge on which my understanding revolves is that an IP hop traverses a router and ***results in a change of prefix of the link on which the packet travels*** : --------<incoming packet; link prefix = p1>------><router> --------<outgoing packet; link prefix = p2>------> With RPL, the "hop" would look like as shown below: --------<incoming packet; link prefix = p1>------<router> --------<outgoing packet; link prefix = p1>------ There seems to be a change in the meaning associated with "IP hop". I guess that I can reconcile both cases through the observation that RPL actually does apply to a single, NBMA link and therefore the IP prefix ***is*** the same. Then again, calling the RPL device involved in the packet forwarding by the name "router" feels like an uncomfortable stretch. Don't routers sit at the meeting point of different layer 2 links? Cheers, Etienne On Fri, May 29, 2020 at 10:39 PM Pascal Thubert (pthubert) < pthubert(a)cisco.com> wrote: > Hello Etienne > > You may see ND as the host to * interface for any network and RPL as the > router to router interface when the network is NBMA. > > Some of us cared about the interworking. > > Look at the RPL Unaware leaf I-draft and you’ll see that I’m sure. > > Keep safe, > > Pascal > > > Le 29 mai 2020 à 20:28, Carsten Bormann <cabo(a)tzi.org> a écrit : > > > > Hi Etienne, > > > > I’m also not sure many of the classical network operators assembled in > NANOG work with 6LoWPANs today, but I still can answer your question. > > > >> While trying to build a holistic view of LoWPANs, I'm consulting the > IETF's informational and standards documents. > >> > >> I'm struck by the impression that, despite the significance of > RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy > networks (LLNs), > >> it is largely ignored by RFC6550 (RPL), with little to no reference to > the ontological plane created in RFC6775's terminology section. > > > > Yes, you could say that. > > > > ND (Neighbor discovery) describes interfaces between hosts and between > hosts and routers. > > 6LoWPAN-ND does not use host-to-host interfaces (different from > Ethernet, all traffic goes over routers, which RFC 4861 already forsaw in > the L — on-link — bit, which isn’t set in 6LoWPAN-ND). > > > > RFC 6550 was completed at a time when many people who came in from the > WSN (wireless sensor network) world thought they could get away with a > network that is wholly composed of routers. > > Even the “leaf” nodes in the RPL world were participating in the routing > protocol and therefore didn’t really need a host-router interface. There > was no separate host-router interface in that world, because there were no > non-router hosts. > > > >> (a) router advertisements and router solicitations are substituted by > DAG information objects (DIO) and DAG information solicitations (DIS) > > > > Right, DIO and DAO are router-to-router messages. If there are no hosts > (and routers don’t bootstrap themselves as hosts), you don’t need ND. > > > >> (b) the terms "mesh-under" and "route-over" (widely cited), defined in > RFC6775, are absent from RFC6550 > > > > RFC6550 is route over by definition. Actually, the term was coined by > the people working closely with the RPL development; RFC 6775 does > appropriate it as 6LoWPAN-ND is applicable in either case. > > > >> (c) jarringly: RFC6775 describes the route-over topologies as > multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the > same IPv6 prefix as their border router - no multiple IP hops. > > > > I’m not sure where you get this interpretation: RFC 6550 (RPL) is very > much about IP hops. > > Maybe you mean the address architecture that was defined explicitly in > RFC 6775; RFC 6550 does not really say much about addresses. > > > > Note that the RPL people have since proceeded to (at least partially) > embrace the host-router concept from the IP architecture; RFC 8505 is an > update to RFC 6775 that makes 6LoWPAN-ND more palatable to RPL people. > > > > I have CCed Pascal Thubert who, as a co-author to all three RFCs, > certainly will have another perspective on this. > > > > Grüße, Carsten > > > -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale

1 0

Charter AS20115 Contact
by Jeff Waddell 29 May '20

29 May '20

Could a Charter network engineer reach out off list for an issue we are seeing when trying to reach any Charter customers under the AS20115 We don't peer with (or get transit) directly from AS20115 and traffic seems to be blocked at the border with our transit providers and AS20115 We have tried opening tickets with our transit providers - but that is going no where Thanks Jeff

1 0

Equinix Chicago Traffic Drop 5/29/2020
by Kevin McCormick 29 May '20

29 May '20

Last night between 5:20 am and 6:50 am UTC we noticed a large drop in traffic. Looking at flow data, Google had dropped traffic in same time period. We were wondering if anyone had noticed similar drop in traffic. Thank you, Kevin McCormick

1 0

RFC6550 (RPL) and RFC6775 (IPv6 Neighbor Discovery for 6LoWPANs)
by Etienne-Victor Depasquale 29 May '20

29 May '20

Hello folks, I'm not sure whether this is within scope as it regards LoWPANs ... please chastise freely and ignore if LoWPANs are out of scope. While trying to build a holistic view of LoWPANs, I'm consulting the IETF's informational and standards documents. I'm struck by the impression that, despite the significance of RFC6775's extension of Neighbor Discovery(ND) to low-power and lossy networks (LLNs), it is largely ignored by RFC6550 (RPL), with little to no reference to the ontological plane created in RFC6775's terminology section. For example: (a) router advertisements and router solicitations are substituted by DAG information objects (DIO) and DAG information solicitations (DIS) (b) the terms "mesh-under" and "route-over" (widely cited), defined in RFC6775, are absent from RFC6550 (c) jarringly: RFC6775 describes the route-over topologies as multi-IP-hop, while RFC6550 gathers DODAG nodes within the confines of the same IPv6 prefix as their border router - no multiple IP hops. Can anyone confirm or contradict this impression? Cheers, Etienne -- Ing. Etienne-Victor Depasquale Assistant Lecturer Department of Communications & Computer Engineering Faculty of Information & Communication Technology University of Malta Web. https://www.um.edu.mt/profile/etiennedepasquale

2 1

Weekly Routing Table Report
by cscora＠apnic.net 29 May '20

29 May '20

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, SANOG, PacNOG, SAFNOG TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG. Daily listings are sent to bgp-stats(a)lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith <pfsinoz(a)gmail.com>. Routing Table Report 04:00 +10GMT Sat 30 May, 2020 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 812240 Prefixes after maximum aggregation (per Origin AS): 308990 Deaggregation factor: 2.63 Unique aggregates announced (without unneeded subnets): 395869 Total ASes present in the Internet Routing Table: 68196 Prefixes per ASN: 11.91 Origin-only ASes present in the Internet Routing Table: 58588 Origin ASes announcing only one prefix: 24435 Transit ASes present in the Internet Routing Table: 9608 Transit-only ASes present in the Internet Routing Table: 318 Average AS path length visible in the Internet Routing Table: 4.4 Max AS path length visible: 42 Max AS path prepend of ASN ( 22394) 38 Prefixes from unregistered ASNs in the Routing Table: 1123 Number of instances of unregistered ASNs: 1125 Number of 32-bit ASNs allocated by the RIRs: 31801 Number of 32-bit ASNs visible in the Routing Table: 26265 Prefixes from 32-bit ASNs in the Routing Table: 121170 Number of bogon 32-bit ASNs visible in the Routing Table: 16 Special use prefixes present in the Routing Table: 1 Prefixes being announced from unallocated address space: 0 Number of addresses announced to Internet: 2841823488 Equivalent to 169 /8s, 98 /16s and 201 /24s Percentage of available address space announced: 76.8 Percentage of allocated address space announced: inf Percentage of available address space allocated: 0.0 Percentage of address space in use by end-sites: 99.5 Total number of prefixes smaller than registry allocations: 604309 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 213773 Total APNIC prefixes after maximum aggregation: 62542 APNIC Deaggregation factor: 3.42 Prefixes being announced from the APNIC address blocks: 0 Unique aggregates announced from the APNIC address blocks: 0 APNIC Region origin ASes present in the Internet Routing Table: 10585 APNIC Prefixes per ASN: 0.00 APNIC Region origin ASes announcing only one prefix: 2956 APNIC Region transit ASes present in the Internet Routing Table: 1569 Average APNIC Region AS path length visible: 4.7 Max APNIC Region AS path length visible: 27 Number of APNIC region 32-bit ASNs visible in the Routing Table: 5663 Number of APNIC addresses announced to Internet: 0 Equivalent to 0 /8s, 0 /16s and 0 /24s APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 63488-64098, 64297-64395, 131072-141625 APNIC Address Blocks ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 237172 Total ARIN prefixes after maximum aggregation: 109382 ARIN Deaggregation factor: 2.17 Prefixes being announced from the ARIN address blocks: 0 Unique aggregates announced from the ARIN address blocks: 0 ARIN Region origin ASes present in the Internet Routing Table: 18520 ARIN Prefixes per ASN: 0.00 ARIN Region origin ASes announcing only one prefix: 6784 ARIN Region transit ASes present in the Internet Routing Table: 1915 Average ARIN Region AS path length visible: 3.9 Max ARIN Region AS path length visible: 42 Number of ARIN region 32-bit ASNs visible in the Routing Table: 3258 Number of ARIN addresses announced to Internet: 0 Equivalent to 0 /8s, 0 /16s and 0 /24s ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 62464-63487, 64198-64296, 393216-399260 ARIN Address Blocks RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 230850 Total RIPE prefixes after maximum aggregation: 106822 RIPE Deaggregation factor: 2.16 Prefixes being announced from the RIPE address blocks: 0 Unique aggregates announced from the RIPE address blocks: 0 RIPE Region origin ASes present in the Internet Routing Table: 27115 RIPE Prefixes per ASN: 0.00 RIPE Region origin ASes announcing only one prefix: 11735 RIPE Region transit ASes present in the Internet Routing Table: 3839 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 39 Number of RIPE region 32-bit ASNs visible in the Routing Table: 9189 Number of RIPE addresses announced to Internet: 0 Equivalent to 0 /8s, 0 /16s and 0 /24s RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 56320-58367 59392-61439, 61952-62463, 64396-64495 196608-213403 RIPE Address Blocks LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 106533 Total LACNIC prefixes after maximum aggregation: 24819 LACNIC Deaggregation factor: 4.29 Prefixes being announced from the LACNIC address blocks: 0 Unique aggregates announced from the LACNIC address blocks: 0 LACNIC Region origin ASes present in the Internet Routing Table: 9888 LACNIC Prefixes per ASN: 0.00 LACNIC Region origin ASes announcing only one prefix: 2468 LACNIC Region transit ASes present in the Internet Routing Table: 1850 Average LACNIC Region AS path length visible: 5.0 Max LACNIC Region AS path length visible: 35 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 7465 Number of LACNIC addresses announced to Internet: 0 Equivalent to 0 /8s, 0 /16s and 0 /24s LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 61440-61951, 64099-64197, 262144-272796 + ERX transfers LACNIC Address Blocks AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 22788 Total AfriNIC prefixes after maximum aggregation: 4699 AfriNIC Deaggregation factor: 4.85 Prefixes being announced from the AfriNIC address blocks: 0 Unique aggregates announced from the AfriNIC address blocks: 0 AfriNIC Region origin ASes present in the Internet Routing Table: 1398 AfriNIC Prefixes per ASN: 0.00 AfriNIC Region origin ASes announcing only one prefix: 492 AfriNIC Region transit ASes present in the Internet Routing Table: 274 Average AfriNIC Region AS path length visible: 5.0 Max AfriNIC Region AS path length visible: 30 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 690 Number of AfriNIC addresses announced to Internet: 0 Equivalent to 0 /8s, 0 /16s and 0 /24s AfriNIC AS Blocks 36864-37887, 327680-329727 & ERX transfers AfriNIC Address Blocks APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 7545 5477 703 638 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4739 4192 73 ERX-CERNET-BKB China Education and Rese 7552 3430 1330 22 VIETEL-AS-AP Viettel Group, VN 45899 3153 1806 102 VNPT-AS-VN VNPT Corp, VN 7713 2712 831 510 TELKOMNET-AS-AP PT Telekomunikasi Indon 9808 2645 9043 61 CMNET-GD Guangdong Mobile Communication 9498 2271 434 224 BBIL-AP BHARTI Airtel Ltd., IN 4766 2269 11102 555 KIXS-AS-KR Korea Telecom, KR 4755 2136 441 194 TATACOMM-AS TATA Communications formerl 9394 2039 4914 20 CTTNET China TieTong Telecommunications Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 11492 4380 295 696 CABLEONE, US 7155 4036 264 27 VIASAT-SP-BACKBONE, US 16509 3951 8129 1807 AMAZON-02, US 22773 3554 2969 153 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3375 1324 91 SHAW, CA 16625 3103 1625 2211 AKAMAI-AS, US 209 2429 5075 532 CENTURYLINK-US-LEGACY-QWEST, US 30036 2390 364 281 MEDIACOM-ENTERPRISE-BUSINESS, US 5650 2304 2981 1621 FRONTIER-FRTR, US 26484 2184 137 201 IKGUL-26484, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 12479 5752 1657 141 UNI2-AS, ES 31334 4903 484 13 KABELDEUTSCHLAND-AS, DE 39891 3651 203 20 ALJAWWALSTC-AS, SA 8551 3161 379 45 BEZEQ-INTERNATIONAL-AS Bezeqint Interne 20940 3020 448 2050 AKAMAI-ASN1, EU 12389 2515 2251 732 ROSTELECOM-AS, RU 9009 2190 233 1210 M247, GB 34984 2130 353 563 TELLCOM-AS, TR 13188 1607 100 35 TRIOLAN, UA 61317 1215 142 528 ASDETUK http://www.heficed.com, GB Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6609 3323 603 Uninet S.A. de C.V., MX 10620 3358 530 506 Telmex Colombia S.A., CO 11830 2666 369 63 Instituto Costarricense de Electricidad 6503 1686 327 388 Axtel, S.A.B. de C.V., MX 7303 1519 988 255 Telecom Argentina S.A., AR 13999 1413 512 336 Mega Cable, S.A. de C.V., MX 28573 1368 2243 206 CLARO S.A., BR 6147 1151 379 39 Telefonica del Peru S.A.A., PE 3816 1104 571 149 COLOMBIA TELECOMUNICACIONES S.A. ESP, C 11172 954 111 67 Alestra, S. de R.L. de C.V., MX Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 24863 1467 393 22 LINKdotNET-AS, EG 24835 1112 574 28 RAYA-AS, EG 36992 1091 1539 76 ETISALAT-MISR, EG 36903 900 472 91 MT-MPLS, MA 29571 605 68 11 ORANGE-COTE-IVOIRE, CI 6713 553 1863 34 IAM-AS, MA 37342 479 32 1 MOVITEL, MZ 36935 397 521 44 Vodafone-, EG 23889 365 231 15 MauritiusTelecom, MU 15399 351 45 11 WANANCHI-, KE Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 6609 3323 603 Uninet S.A. de C.V., MX 12479 5752 1657 141 UNI2-AS, ES 7545 5477 703 638 TPG-INTERNET-AP TPG Telecom Limited, AU 31334 4903 484 13 KABELDEUTSCHLAND-AS, DE 4538 4739 4192 73 ERX-CERNET-BKB China Education and Rese 11492 4380 295 696 CABLEONE, US 7155 4036 264 27 VIASAT-SP-BACKBONE, US 16509 3951 8129 1807 AMAZON-02, US 39891 3651 203 20 ALJAWWALSTC-AS, SA 22773 3554 2969 153 ASN-CXA-ALL-CCI-22773-RDC, US Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggregation summary ----------------------------------------- ASN No of nets Net Savings Description 12479 5752 5611 UNI2-AS, ES 31334 4903 4890 KABELDEUTSCHLAND-AS, DE 7545 5477 4839 TPG-INTERNET-AP TPG Telecom Limited, AU 4538 4739 4666 ERX-CERNET-BKB China Education and Research Net 7155 4036 4009 VIASAT-SP-BACKBONE, US 11492 4380 3684 CABLEONE, US 39891 3651 3631 ALJAWWALSTC-AS, SA 7552 3430 3408 VIETEL-AS-AP Viettel Group, VN 22773 3554 3401 ASN-CXA-ALL-CCI-22773-RDC, US 6327 3375 3284 SHAW, CA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Net Originated Transit AS Transit AS Name 62828 UNALLOCATED 8.21.130.0/24 3356 LEVEL3, US 393266 UNALLOCATED 8.23.52.0/24 174 COGENT-174, US 62485 UNALLOCATED 8.23.229.0/24 3356 LEVEL3, US 32985 UNALLOCATED 8.28.31.0/24 3356 LEVEL3, US 394936 UNALLOCATED 8.33.224.0/24 174 COGENT-174, US 23061 UNALLOCATED 8.39.119.0/24 3356 LEVEL3, US 26584 UNALLOCATED 8.42.62.0/23 209 CENTURYLINK-US-LEGACY-QWEST, 395438 UNALLOCATED 8.42.206.0/24 3356 LEVEL3, US 46766 UNALLOCATED 8.44.208.0/24 3356 LEVEL3, US 40544 UNALLOCATED 12.0.33.0/24 6461 ZAYO-6461, US Complete listing at http://thyme.rand.apnic.net/current/data-badAS Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 192.88.99.0/24 6939 HURRICANE, US Complete listing at http://thyme.rand.apnic.net/current/data-dsua Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:9 /9:11 /10:38 /11:99 /12:286 /13:578 /14:1169 /15:1917 /16:13363 /17:8233 /18:13929 /19:25792 /20:41152 /21:48330 /22:100573 /23:83294 /24:472190 /25:1277 /26:0 /27:0 /28:0 /29:0 /30:0 /31:0 /32:0 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 12479 5591 5752 UNI2-AS, ES 8151 5232 6609 Uninet S.A. de C.V., MX 31334 4892 4903 KABELDEUTSCHLAND-AS, DE 11492 4100 4380 CABLEONE, US 7155 3903 4036 VIASAT-SP-BACKBONE, US 16509 3820 3951 AMAZON-02, US 39891 3651 3651 ALJAWWALSTC-AS, SA 7545 3465 5477 TPG-INTERNET-AP TPG Telecom Limited, AU 22773 3445 3554 ASN-CXA-ALL-CCI-22773-RDC, US 7552 3319 3430 VIETEL-AS-AP Viettel Group, VN Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:1777 2:1182 3:30 4:19 5:3351 6:52 8:1428 9:1 11:1 12:1778 13:507 14:2307 15:72 16:8 17:291 18:81 20:100 23:3638 24:2273 25:2 27:2511 31:3097 32:113 34:3 35:42 36:934 37:3250 38:2027 39:413 40:127 41:3592 42:902 43:2121 44:208 45:14332 46:3685 47:293 49:1460 50:1430 51:93 52:1057 54:235 55:671 56:6 57:52 58:1829 59:1170 60:736 61:2279 62:2076 63:1986 64:5132 65:2295 66:4965 67:2883 68:1188 69:3927 70:1413 71:680 72:2861 74:2605 75:1447 76:673 77:2897 78:1653 79:2344 80:1948 81:1627 82:1319 83:1311 84:1235 85:2529 86:540 87:1739 88:1050 89:2763 90:378 91:7951 92:1519 93:2505 94:2719 95:3895 96:1224 97:331 98:932 99:977 100:87 101:992 102:973 103:23751 104:3436 105:397 106:879 107:1985 108:712 109:3675 110:1822 111:2032 112:1609 113:1358 114:1509 115:1829 116:1793 117:2146 118:2137 119:1719 120:820 121:1041 122:2432 123:1988 124:1548 125:2038 128:1362 129:1183 130:640 131:1853 132:750 133:302 134:1312 135:289 136:616 137:851 138:2180 139:989 140:674 141:992 142:925 143:1220 144:1007 145:306 146:1502 147:1028 148:2118 149:1189 150:870 151:1316 152:1494 153:388 154:4692 155:1053 156:3110 157:1103 158:841 159:1971 160:1886 161:1042 162:3079 163:815 164:1460 165:1284 166:555 167:1626 168:3538 169:539 170:4206 171:778 172:1933 173:2550 174:985 175:1034 176:2688 177:4229 178:3056 179:1438 180:2265 181:2565 182:3086 183:1141 184:2420 185:16415 186:3753 187:2739 188:4120 189:2317 190:8710 191:1409 192:10357 193:7523 194:6191 195:4401 196:3215 197:1947 198:6089 199:5927 200:7236 201:5211 202:10527 203:10254 204:4578 205:3096 206:3214 207:3289 208:4080 209:4423 210:3994 211:1989 212:3378 213:3105 214:1190 215:62 216:6020 217:2424 218:847 219:614 220:2034 221:922 222:993 223:1482 End of report

1 0

LiquidWeb contact re phishing 24 days
by Jonathan M 29 May '20

29 May '20

Greetings, If anyone can help me reach a contact at LiquidWeb, there appears to be phishing on its network for 24 days now and I cannot get a response from them or an acknowledgement of receipt of our notices Yes, we filled our web forms as early as May 5. I can be reached at jonathan-m(a)riskiq.net or if Liquid Web can just respond to the notice, that would be great! They just need to email notice335282(a)irt.riskiq.net. Thanks for any help you can provide here! By the way, I could not find the phish myself, but I preserved it at https://perma.cc/LR8N-SMTH from a RiskIQ crawl that I just looked over internally. The snapshot was taken Fri May 29 05:38:44 PDT 2020 From Chrome Below is an example of what we are sending them: From RiskIQ Incident Response Team <notice335282(a)irt.riskiq.net> To abuse(a)liquidweb.com Sent At May 18, 2020 8:02 PM Subject Important Notice - Phishing Materials on Your Network / Incident ID: 54873584 / IP Address: 69.167.190.92 / ASN: LIQUID-WEB-INC - Liquid Web, Inc., US 2020-05-18 19:53:03 +0300 Team, please see the notice below from our incident response team beneath my signature block. However, I need to point out a few things here. I personally spoke with your team on 2020-03-19 12:49:00 +0200, where we discussed you purchased Nexcess, and that is why there is a different technical abuse contact. I had also re-submitted a ticket referencing the prior ticket and someone at LiquidWeb was opening a ticket on the call to make sure they are on top of this. On 2020-03-24 20:13:44 +0200, Scott at LiquidWeb was investigating this tenacious event. I was told that if this is a repeat offender, you will terminate the account all together, but you woouldn't be able to share that info with us for privacy reasons. However, your team was conducting at the moment an internal investigation to see if they need to take different measures. At that time, Scott put me on hold while he reached out to the security team. At 2020-03-24 20:35:13 +0200, the Security supervisor was looking this over and it was going to take some time for them to decide best course of action. The site was then down. I was told that if it re-surfaces, we can list the UTC date and time stamps that it came back online and your team might then be able to take further action without a court order. You said that if you check the logs, and it doesn’t match up, we would have to get the courts involved. We have preserved a lot of evidence that the phishing has gone back up again after you took it down. For example, for your reference, we have uploaded a screenshot at https://perma.cc/SL7L-6XUE This screenshot in the PERMA record captures hXXps://zionhighschools[.]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit&amp%3bid=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb&amp%3bsession=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb Load Date: Mon May 18 08:13:18 PDT 2020 IP Address: 69.167.190.92 HTTP Method: GET Response Code 200 Response Message OK Content Type text/htmlCharacter SetUTF-8Is HTML Page true Is From Cache false Local Content Length 2.00 K Overall Content Length 319.19 K Local Response Time 4.97 s Overall Response Time5.87 s CPU Time76 ms Dependent Requests 5 Window Name: TopLevelWindow@79c734a4 Please take appropriate action. See all the confirmed URLs in the notice below. Thanks, Jonathan Matkowsky , Vice President - Digital Risk (SME)* Incident Investigation & Intelligence (i3) Phone +1.888.415.4447 (USA) | +44 (0)203 282 7149 (UK) RiskIQ: World Leader in Attack Surface Management *GIAC-GLEG; IAPP-FIP; Active Attorney Admissions: NY, WA This email does not create an attorney-client relationship or constitute legal advice. ***We have defanged URLs in this notice. In the identity and location of the phishing materials, please substitute "." for "[dot]", "http" for "hxxp", and "https" for "hxxps"*** ******* ***** ***** ****** ******** *Summary* *Threat Activity Type*: Phishing *Industry Impact*: Financial *Spoofed Brand*: American Express *Date and Time of Abuse:*: 2020-05-05 06:32 AM PDT *IP Address*: 69.167.190.92 *ASN*: LIQUID-WEB-INC - Liquid Web, Inc., US *Identify and Location of Phishing Materials*: hxxps://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit&%3bid=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb&%3bsession=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb hxxp://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/ hxxps://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit&id=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb&session=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb hxxps://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit&id=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb&session=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb hxxp://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit&id=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb&session=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb (individually or collectively, “*Phishing Materials*”) ******* ***** ***** ****** ******** Greetings, Per the above summary, we write on behalf of American Express to request your assistance to mitigate a confirmed threat that appears to utilise your network resources for fraudulent purposes by hosting the Phishing Materials as identified above. We would appreciate it if you would take all reasonable and appropriate steps to ensure your network resources are no longer being used to facilitate or contribute to this confirmed threat, which may include temporarily suspending the account until the Phishing Materials have been removed. If you need any support or additional information during the course of your investigation, please let us know by reply email at your earliest convenience. Thank you for your support in safeguarding the public. Sincerely, Digital Threat Incident Response Team RiskIQ, Inc. 22 Battery St., 10th Floor, San Francisco CA 94111 USA www.riskiq.com Incident 54873584 -- ******************************************************************* This message was sent from RiskIQ, and is intended only for the designated recipient(s). It may contain confidential or proprietary information and may be subject to confidentiality protections. If you are not a designated recipient, you may not review, copy or distribute this message. If you receive this in error, please notify the sender by reply e-mail and delete this message. Thank you. *******************************************************************

2 1

LF Microsoft Bing/Cache (edge) contact?
by Austin, Jeremy H. 28 May '20

28 May '20

We have an (apparently now defunct) on-premise Microsoft Bing cache. Traffic has dropped off from it over the last few months. Unlike the other cache programs, we haven’t heard anything proactive from MS – the contact who set this up with us long ago moved on to other companies. It also appears that the program is now called Microsoft Edge Caching. We’d like to continue to host a Microsoft cache, no matter the name. Based on https://www.peeringdb.com/net/694 we could be looking to ioc(a)microsoft.com<mailto:ioc@microsoft.com> and peering(a)microsoft.com<mailto:peering@microsoft.com>, and per https://peering.azurewebsites.net/Peering/Caching we should be looking to ispnode(a)microsoft.com<mailto:ispnode@microsoft.com> for inquiries about the current cache program. However despite being listed as the address of record for peering inquiries, ispnode(a)microsoft.com<mailto:ispnode@microsoft.com> bounces external emails, apparently using a mailing list (member whitelist). The other two addresses haven’t produced any responses. Does anyone have a current contact for Microsoft’s edge caching program, or work there yourself? Regards, Jeremy Austin Alaska Communications ________________________________ This transmittal may contain confidential information intended solely for the addressee. If you are not the intended recipient, you are hereby notified that you have received this transmittal in error; any review, dissemination, distribution or copying of this transmittal is strictly prohibited. If you have received this communication in error, please notify us immediately by reply or by telephone at 907-297-3000 and ask to speak with the message sender. In addition, please immediately delete this message and all attachments. Thank you. Alaska Communications

1 0