- Test - lists.nanog.org

Looking for anyone from Cox Communications
by August Yang 26 Aug '22

26 Aug '22

Some Cox customers reported they were not able to reach one of our IPv6 prefixes, including more specifics announced by different ASNs. I suspect the whole range is blackholed or something. ``` mtr -r -c1 -w 2a12:dd44::1 Start: 2022-08-25T18:09:50-0700 HOST: ronsor-lg-arch Loss% Snt Last Avg Best Wrst StDev 1.|-- 2600:8800:3b80:3d70:424c:77ff:fe74:cf7a 0.0% 1 30.8 30.8 30.8 30.8 0.0 2.|-- 2600:8800:3bff:ffff::1111 0.0% 1 97.1 97.1 97.1 97.1 0.0 3.|-- 2001:578:801:fffc:600::2c 0.0% 1 15.3 15.3 15.3 15.3 0.0 4.|-- 2001:578:900:4::6 0.0% 1 13.8 13.8 13.8 13.8 0.0 5.|-- 2001:578:1:0:172:17:248:216 0.0% 1 73.5 73.5 73.5 73.5 0.0 6.|-- ??? 100.0 1 0.0 0.0 0.0 0.0 0.0 ``` 2a12:dd47:805e::1 originated from AS211233 dropped at the same router 2001:578:1:0:172:17:248:216. Feel free to contact me off list. Thanks August Yang

1 0

Re: Anyone here from Verizon keeping tabs on FiOS v6?
by Tomas Jonsson 25 Aug '22

25 Aug '22

I couldn't really figure out why things where behaving so weird today until now when you mentioned this and I had a look and realized my firewall also picked up an ipv6 address with broken routing. This is in the NJ area. /T On 2022-08-25 15:31, Rob Foehl wrote: > Maintenance outage last night, PD woke up shortly afterward and > collected a /56, no joy after that -- egress traffic gets where it's > going, ingress is dropped not far into 701. Only visible covering > route is the 2600:4000::/24 aggregate, both externally and via > Verizon's looking glass. > > It looks like there are several reports of the same issue in other > areas over the last couple months, where those that work have covering > /36s advertised externally and the broken ones don't, e.g. no > 2600:4041:2000::/36 here. > > Happy to follow up off-list, if so inclined. Thanks! > > -Rob

1 0

Anyone here from Verizon keeping tabs on FiOS v6?
by Rob Foehl 25 Aug '22

25 Aug '22

Maintenance outage last night, PD woke up shortly afterward and collected a /56, no joy after that -- egress traffic gets where it's going, ingress is dropped not far into 701. Only visible covering route is the 2600:4000::/24 aggregate, both externally and via Verizon's looking glass. It looks like there are several reports of the same issue in other areas over the last couple months, where those that work have covering /36s advertised externally and the broken ones don't, e.g. no 2600:4041:2000::/36 here. Happy to follow up off-list, if so inclined. Thanks! -Rob

1 0

BGP Visualization with Software Galaxies
by Jacques Latour 25 Aug '22

25 Aug '22

I was looking for a functional version of a BGP visualisation tool like the one at NTT http://as2914.net/, it does not seem to work or be updated. Is there a public facing functional tool somewhere? I like this tool to show the complexity of our internet from a spaceship point of view COOL 😊 * https://github.com/anvaka/pm/tree/master/about#software-galaxies-documentat… Thanks! Jacques

2 1

Yet another BGP hijacking towards AS16509
by Siyuan Miao 24 Aug '22

24 Aug '22

Hi folks, Recently I read a post regarding the recent incident of Celer Network and noticed a very interesting and successful BGP hijacking towards AS16509. The attacker AS209243 added AS16509 to their AS-SET and a more specific route object for the /24 where the victim's website is in ALTDB: (Below is our IRRd4 server NRTM logging, UTC timezone) irrd.log-20220817.gz:31106270-ADD 96126 irrd.log-20220817.gz:31106280- irrd.log-20220817.gz:31106281-as-set: AS-SET209243 irrd.log-20220817.gz:31106306-descr: quickhost set irrd.log-20220817.gz:31106332-members: AS209243, AS16509 irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK irrd.log-20220817.gz:31106392-changed: crussell(a)quickhostuk.net 20220816 irrd.log-20220817.gz:31106438-source: ALTDB irrd.log-20220817.gz:31147549-ADD 96127 irrd.log-20220817.gz:31147559- irrd.log-20220817.gz:31147560-route: 44.235.216.0/24 irrd.log-20220817.gz:31147588-descr: route irrd.log-20220817.gz:31147606-origin: AS16509 irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK irrd.log-20220817.gz:31147656-changed: crussell(a)quickhostuk.net 20220816 irrd.log-20220817.gz:31147702-source: ALTDB Then they started announcing the prefix ... under another AWS ASN (AS14618) I guess AS1299 Arelion doesn't check if the origin AS of an announcement is in the customer's AS-SET but it's pretty normal and understandable. https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24&w.ignoreRean… Type: A > announce Involving: 44.235.216.0/24 Short description: The new route 34854 1299 209243 14618 has been announced Path: 34854, 1299, 209243, 14618, Community: 1299:35000,34854:3001 Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1 Hjacking didn't last too long. AWS started announcing a more specific announcement to prevent hijacking around 3 hours later. Kudos to Amazon's security team :-) Type: A > announce Involving: 44.235.216.0/24 Short description: The new route 58057 34549 5511 1299 16509 has been announced Path: 58057, 34549, 5511, 1299, 16509, Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511 Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251 The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one seems to notice them ... irrd.log-20220819.gz:26517714-ADD 96196 irrd.log-20220819.gz:26517724- irrd.log-20220819.gz:26517725:as-set: AS-SET209243 irrd.log-20220819.gz:26517750-descr: quickhost set irrd.log-20220819.gz:26517776-members: AS209243, AS35437, AS37497 irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK irrd.log-20220819.gz:26517845-changed: crussell(a)quickhostuk.net 20220817 irrd.log-20220819.gz:26517891-source: ALTDB irrd.log-20220819.gz:26517910-DEL 96197 irrd.log-20220819.gz:26517920- irrd.log-20220819.gz:26517921-route: 44.235.216.0/24 irrd.log-20220819.gz:26517949-descr: route irrd.log-20220819.gz:26517967-origin: AS16509 irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK irrd.log-20220819.gz:26518017-changed: crussell(a)quickhostuk.net 20220816 irrd.log-20220819.gz:26518063-source: ALTDB Nowadays hijacking a service by forging AS path is pretty easy and RPKI won't be able to solve this (as it validates origin AS and prefixes only) :-( Regards, Siyuan

6 8

IMPORTANT – ARIN Election Deadline Approaching – and now relevant to many more organizations than previously...
by John Curran 24 Aug '22

24 Aug '22

NANOGers - For those who don’t closely follow ARIN, it’s important to know that in 2022 we made a substantial change to ARIN membership and ability to participate in ARIN’s elections – and as a result, many organizations that have never participated in ARIN elections in the past will be able to do so if they so wish. While previously one had to be an ARIN service provider (“ISP”) member to participate in ARIN’s elections, the recent change means that any organization with IPv4 or IPv6 number resources directly assigned and under contract with ARIN who is current with their ARIN fees may request ARIN General Member status, assign a voting contact & then participate in the upcoming elections for ARIN’s Board of Trustees, ARIN Advisory Council, etc. Please see the message below for further information - thanks! /John John Curran President and CEO American Registry for Internet Numbers Begin forwarded message: From: ARIN <info(a)arin.net<mailto:info@arin.net>> Subject: [arin-announce] Deadline Approaching — Make Sure Your Organization is Eligible to Vote in ARIN’s Upcoming Election! Date: 24 August 2022 at 11:17:26 AM EDT To: "arin-announce(a)arin.net<mailto:arin-announce@arin.net>" <arin-announce(a)arin.net<mailto:arin-announce@arin.net>> We hope you are excited to participate in ARIN Elections this October. Please note that a key deadline for the ARIN Elections process is coming up. All organizations who wish to vote in this year’s election must be a General Member in Good Standing before 5:00 PM ET on Monday, 5 September 2022. A General Member in Good Standing is defined as an entity that is current on all annual fees as well as having a valid Voting Contact on record. Only General Members in Good Standing are eligible to vote in ARIN Elections. If you are not sure what type of member your organization is, you may check its status in your ARIN Online account. If your organization is eligible to request General Membership, you can access the General Member request form through the ACTIONS drop down menu. If you are already a General Member, please make sure your account has no overdue invoices on file and that you have designated a Voting Contact in your account before 5:00 PM ET on 5 September. To learn more about how to designate or view your current Voting Contact, visit: https://www.arin.net/participate/oversight/membership/voting/ Don’t forget — General Members may also participate on ARIN’s General Member Mailing List. Subscription to the list is limited to General Members only, as well as Trustees and key ARIN staff, and it is intended for discussion of topics related to the governance of ARIN as well as ARIN Elections. For more information on ARIN’s Elections, including a calendar of important dates, visit https://www.arin.net/elections. To learn more about membership at ARIN, visit https://www.arin.net/membership. Voting in ARIN Elections helps steer the future of Internet number resource policy and Internet governance. We look forward to your organization being able to participate this October. Regards, John Sweeting Chief Customer Officer American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce You are receiving this message because you are subscribed to the ARIN Announce Mailing List (ARIN-announce(a)arin.net<mailto:ARIN-announce@arin.net>). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-announce Please contact info(a)arin.net<mailto:info@arin.net> if you experience any issues.

1 0

Looking for contact within Comcast Xfinity
by Michael Brown 24 Aug '22

24 Aug '22

If anyone from Comcast Xfinity is on this list, can you please reach out to me? We're getting increased reports of xFi Advanced Security customers being unable to access hosted sites and attempting to open tickets has had no success. Thanks, Michael Brown

4 3

Frontier Temecula CA outage
by James Laszko 23 Aug '22

23 Aug '22

Anyone able to give any insight into Frontier FIOS outage in the Temecula area? Our team can’t get past level 1 support with unknown ETTR times for hundreds of customers. Over 16 hours down so far. Any info appreciated! Thanks, James Laszko P 951-813-2674 F 951-252-6210 Helpdesk 951-813-2685 jamesl(a)mythostech.com mythostech.com

1 0

Re: Yet another BGP hijacking towards AS16509
by Siyuan Miao 23 Aug '22

23 Aug '22

Just noticed another thing: ➜ ~ whois -h whois.ripe.net -- "--list-versions AS1299" | tail -n10 2862 2022-07-11T14:44:49Z ADD/UPD 2863 2022-07-27T11:17:25Z ADD/UPD 2864 2022-08-02T08:43:02Z ADD/UPD 2865 2022-08-10T12:11:29Z ADD/UPD *2866 2022-08-17T10:47:43Z ADD/UPD2867 2022-08-18T12:53:37Z ADD/UPD* % This query was served by the RIPE Database Query Service version 1.103 (WAGYU) ➜ ~ whois -h whois.ripe.net -- "--show-version 2865 AS1299" | grep 209243 ➜ ~ whois -h whois.ripe.net -- "--show-version 2866 AS1299" | grep 209243 import: from AS209243 accept AS209243 mp-import: afi ipv6 from AS209243 accept AS209243 *➜ ~ whois -h whois.ripe.net <http://whois.ripe.net> -- "--show-version 2867 AS1299" | grep 209243import: from AS209243 accept AS-SET209243mp-import: afi ipv6 from AS209243 accept AS-SET209243* Looks like the first thing that AS209243 had done after they got AS1299 transit is ... hijacking an Amazon prefix ..? On Tue, Aug 23, 2022 at 1:51 AM Siyuan Miao <siyuan(a)misaka.io> wrote: > Hi folks, > > Recently I read a post regarding the recent incident of Celer Network and > noticed a very interesting and successful BGP hijacking towards AS16509. > > The attacker AS209243 added AS16509 to their AS-SET and a more specific > route object for the /24 where the victim's website is in ALTDB: > (Below is our IRRd4 server NRTM logging, UTC timezone) > > irrd.log-20220817.gz:31106270-ADD 96126 > > irrd.log-20220817.gz:31106280- > > irrd.log-20220817.gz:31106281-as-set: AS-SET209243 > > irrd.log-20220817.gz:31106306-descr: quickhost set > > irrd.log-20220817.gz:31106332-members: AS209243, AS16509 > > irrd.log-20220817.gz:31106362:mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220817.gz:31106392-changed: crussell(a)quickhostuk.net > 20220816 > > irrd.log-20220817.gz:31106438-source: ALTDB > > irrd.log-20220817.gz:31147549-ADD 96127 > > irrd.log-20220817.gz:31147559- > > irrd.log-20220817.gz:31147560-route: 44.235.216.0/24 > > irrd.log-20220817.gz:31147588-descr: route > > irrd.log-20220817.gz:31147606-origin: AS16509 > > irrd.log-20220817.gz:31147626:mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220817.gz:31147656-changed: crussell(a)quickhostuk.net > 20220816 > > irrd.log-20220817.gz:31147702-source: ALTDB > > > Then they started announcing the prefix ... under another AWS ASN (AS14618) > I guess AS1299 Arelion doesn't check if the origin AS of an announcement > is in the customer's AS-SET but it's pretty normal and understandable. > > > https://stat.ripe.net/widget/bgplay#w.resource=44.235.216.0/24&w.ignoreRean… > > > Type: A > announce Involving: 44.235.216.0/24 > Short description: The new route 34854 1299 209243 14618 has been > announced > Path: 34854, 1299, 209243, 14618, > Community: 1299:35000,34854:3001 > Date and time: 2022-08-17 19:39:50 Collected by: 00-2.56.11.1 > > Hjacking didn't last too long. AWS started announcing a more specific > announcement to prevent hijacking around 3 hours later. Kudos to Amazon's > security team :-) > > Type: A > announce Involving: 44.235.216.0/24 > Short description: The new route 58057 34549 5511 1299 16509 has been > announced > Path: 58057, 34549, 5511, 1299, 16509, > Community: 5511:521,5511:666,5511:710,5511:5511,34549:100,34549:5511 > Date and time: 2022-08-17 23:08:47 Collected by: 00-194.50.92.251 > > The attacker cleaned up the IRR objects on 17 Aug and surprisingly no one > seems to notice them ... > > irrd.log-20220819.gz:26517714-ADD 96196 > > irrd.log-20220819.gz:26517724- > > irrd.log-20220819.gz:26517725:as-set: AS-SET209243 > > irrd.log-20220819.gz:26517750-descr: quickhost set > > irrd.log-20220819.gz:26517776-members: AS209243, AS35437, AS37497 > > irrd.log-20220819.gz:26517815-mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220819.gz:26517845-changed: crussell(a)quickhostuk.net > 20220817 > > irrd.log-20220819.gz:26517891-source: ALTDB > > > > irrd.log-20220819.gz:26517910-DEL 96197 > > irrd.log-20220819.gz:26517920- > > irrd.log-20220819.gz:26517921-route: 44.235.216.0/24 > > irrd.log-20220819.gz:26517949-descr: route > > irrd.log-20220819.gz:26517967-origin: AS16509 > > irrd.log-20220819.gz:26517987-mnt-by: MAINT-QUICKHOSTUK > > irrd.log-20220819.gz:26518017-changed: crussell(a)quickhostuk.net > 20220816 > > irrd.log-20220819.gz:26518063-source: ALTDB > > > > Nowadays hijacking a service by forging AS path is pretty easy and RPKI > won't be able to solve this (as it validates origin AS and prefixes only) > :-( > > Regards, > Siyuan > > >

1 0

DNS-OARC 39 Call for Contributions
by John Todd 22 Aug '22

22 Aug '22

OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite part of the meeting will be colocated with RIPE 85. The Programme Committee is seeking contributions from the community. All DNS-related subjects and suggestions for discussion topics are welcome. For inspiration, we provide a non-exhaustive list of ideas: - Operations: Any operational gotchas, lessons learned from an outage, details/reasons for a recent outage (how to improve TTR, tooling). - Deployment: DNS config management and release process. - Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection. - Scaling: DNS performance management and metrics. Increasing DNS Server Efficiency - Security/Privacy: DNSSEC signing and validation, key storage, rollovers, qname minimization, DoH/DoT As it is a hybrid workshop, we'd like to encourage brevity; presentations should not be longer than 20 minutes (with additional time for questions). Workshop Milestones: 2022-09-06 Deadline for submission (23:59 UTC) 2022-09-08 Preliminary list of contributions published 2022-09-20 Full agenda published 2022-10-03 Deadline for slideset submission and Rehearsal 2022-10-22 OARC 39 Workshop - Day1 2022-10-23 OARC 39 Workshop - Day2 The Registration page and details for presentation submission are published at: <https://www.dns-oarc.net/oarc39> To allow the Programme Committee to make objective assessments of submissions, so as to ensure the quality of the workshop, submissions SHOULD include slides. Draft slides are acceptable on submission. Additional information for speakers at OARC 39: - Your talk will be broadcast live and recorded for future reference - Your presentation slides will be available for delegates and others to download and refer to, before, during and after the meeting - Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. It would be very useful to have your slides (even if draft) ready for this. Note: DNS-OARC provides registration fee waivers for the workshop to support those who are part of underrepresented groups to speak at and/or attend DNS-OARC. More details will be provided when registration opens. If you have questions or concerns you can contact the Programme Committee: https://www.dns-oarc.net/oarc/programme via <submissions(a)dns-oarc.net> John Todd, for the DNS-OARC Programme Committee OARC depends on sponsorship to fund its workshops and associated social events. Please contact <sponsor(a)dns-oarc.net> if your organization is interested in becoming a sponsor. (Please note that OARC is run on a non-profit basis, and is not in a position to reimburse expenses or time for speakers at its meetings.) -- John Todd - jtodd(a)quad9.net General Manager - Quad9 Recursive Resolve

1 0