September 2024 - mice-discuss

Please welcome T-Mobile USA, Inc to MICE!
by Jeremy Lumby April 19, 2026

April 19, 2026

Name: T-Mobile USA, Inc Switch: MICE Main Port: Ethernet 6/15/1 ASN: 21928 IPv4: This is a port addition to an existing LAG, all IP info remains the same. The new connection will be 3x100G IPv6: Peering Contact: peering(a)t-mobile.com Route Servers: Yes BFD: No Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

2 9

Please welcome Hurricane Electric to MICE!
by Jeremy Lumby March 20, 2026

March 20, 2026

Name: Hurricane Electric Switch: MICE Main Port: E6/18/1 ASN: 6939 IPv4: This is a port upgrade, all IP info remains the same. The new connection will be 3x100G IPv6: Peering Contact: peering(a)he.net Route Servers: Partial BFD: No Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

2 2

Please welcome Hiawatha Broadband Communications to MICE!
by Jeremy Lumby Dec. 8, 2025

Dec. 8, 2025

Name: Hiawatha Broadband Communications Switch: MICE Core Port: E5/41 ASN: 14828 IPv4: IPs remain the same. This is a port addition bringing capacity to 40G on portchannel 32 IPv6: Peering Contact: noc(a)hbci.com Route Servers: YES BFD: YES Welcome Aboard Again! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

3 22

UG 46 Meeting & Election
by Richard Laager Oct. 8, 2025

Oct. 8, 2025

The MICE UG 46 meeting will be held Wednesday, October 9, 3:00 pm at UMN and via Zoom. Parking, etc. details same as before: https://lists.iphouse.net/cgi-bin/wa?A2=MICE-DISCUSS;2c503e19.2209 * * *Zoom Details* https://umn.zoom.us/j/97601658469?pwd=C6JWkmoYfB9WjZsnRPr9S5u1l4Zkuz.1 ID: 94910223662, passcode: Jp74Et 651-372-8299, meeting ID 97601658469, passcode 864193 * * *Nominations* We will be holding an election for a board seat. The board consists of three seats with staggered terms, such that one seat comes up for re-election each year (at the fall meeting). This year, Reid's seat is up for election. As in the past, we will close nominations in advance of the meeting so people have a chance to instruct a proxy appropriately. *Nominations will be open for two weeks, September 23 - October 6. *I plan to send reminder emails approximately at the start of and just after the nomination period. In the event that the election is uncontested, our practice is to elect by acclimation at the meeting. Proxies are unnecessary in that situation, assuming that the meeting makes quorum. *Proxies * The bylaws state that you send proxies to the Chief Manager (me, Richard Laager), and electronic means are acceptable. So a simple email is sufficient: rlaager(a)wiktel.com or chiefmanager(a)micemn.net. If you send me a /vote/ by email (e.g. "We vote for <X>."), I will treat it as an a proxy appointment, appointing me to vote on your behalf, but restricted to /only/ the election item and to /only/ vote for the candidate you expressed. If you send me a proxy with different instructions (e.g. "We appoint <Y> to vote for us."), obviously that will be honored as written. -- Richard

7 14

Please welcome Qwilt Inc. to MICE!
by Jeremy Lumby Oct. 7, 2025

Oct. 7, 2025

Name: Qwilt Inc. Switch: MICE Main Ports: 6/29/1 ASN: 20253 IPv4: 206.108.255.202/24 IPv6: 2001:504:27:0:0:4F1D::1/64 Peering Contact: peering(a)qwilt.com Route Servers: YES BFD: NO Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 Main: 612-355-7740 Direct: 612-392-6814 Fax: 952-873-7425 jlumby(a)mnvoip.com

4 51

Please welcome Express Data Solutions LLC to MICE!
by Jeremy Lumby Dec. 13, 2024

Dec. 13, 2024

Name: Express Data Solutions LLC Switch: MICE MAIN Port: Ethernet4/2 ASN: 31834 IPv4: 206.108.255.183/24 IPv6: 2001:504:27:0:0:7C5A::1/64 Peering Contact: peering(a)express-ds.com Route Servers- Yes BFD: Yes Welcome Aboard! Jeremy Lumby Minnesota VoIP 9217 17th Ave S #216 Bloomington, MN 55425 M: 612-355-7740 D: 612-392-6814 F: 952-873-7425 jlumby(a)mnvoip.com

3 10

Fwd: [arin-announce] Reminder of Upcoming Deadline for ARIN’s Multifactor Authentication (MFA) Enforcement for ARIN Online
by David Farmer Sept. 9, 2024

Sept. 9, 2024

If you still need to enable MFA on your ARIN Online Account, DO IT NOW! More than 15,000 ARIN Online Accounts have yet to enable MFA, which is nuts! Thanks. ---------- Forwarded message --------- From: ARIN <info(a)arin.net> Date: Mon, Sep 9, 2024 at 11:25 AM Subject: [arin-announce] Reminder of Upcoming Deadline for ARIN’s Multifactor Authentication (MFA) Enforcement for ARIN Online To: <arin-announce(a)arin.net> On 7 October 2024, ARIN will lock all remaining ARIN Online accounts that have not enabled multifactor authentication (MFA). As of 1 February 2023, ARIN requires MFA on all new ARIN Online accounts. Users with accounts created before February 2023 were notified and encouraged to log in at their earliest opportunity, where they would be prompted to set up MFA. This step was taken to provide stronger security for the registry, reduce the risk of fraud, and increase confidence in the integrity of their ARIN resources. On 17 July, we announced that ARIN was continuing to take steps to secure the registry by enforcing MFA. We engaged in direct communications with 19,853 account holders linked to organizations with direct allocations, detailed reassignments, and reallocations who had not yet enabled MFA on their accounts. These users were notified that they needed to set up MFA within 60 days or their accounts would be locked, As of 4 September 2024, 15,593 accounts have not completed MFA setup. We are extending this deadline by two weeks to allow more time for account holders to enable MFA on existing accounts. We strongly encourage ARIN Online account holders who have not set up MFA to do so before the 7 October deadline. Users with locked accounts can contact Registration Services during ARIN operating hours, 7:00 AM to 7:00 PM ET Monday through Friday, to unlock and set up MFA and regain access to ARIN Online. ARIN relies on the support of its customers to ensure the accuracy and security of the registry. We rely on all our customers to follow best practices for account security and to report any suspicious activity to us immediately. Regards, John Curran President and CEO American Registry for Internet Numbers (ARIN) --------- Helpful Resources: Need help setting up your MFA? Visit https://www.arin.net/MFA to get started. You’ll find guides on enabling MFA via an authenticator application, SMS, or security key hardware. We also provide information on how to receive and save your MFA recovery codes, as well as what to do if you’ve lost access to your authenticator app, SMS phone number, or security key. -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

1 0

Odd AWS transfer issue
by Danny Meister Sept. 7, 2024

Sept. 7, 2024

8 11

New QCIX Mailing Lists
by Jay Hanke Sept. 6, 2024

Sept. 6, 2024

For those that are interested, QCIX has just added mailing lists. https://qcix.mailman3.com/ -- Jay Hanke, President South Front Networks jayhanke(a)southfront.io Phone 507-327-2398 https://southfront.io/ <https://southfront.io/path.html>

1 0

Fwd: [Idr] [job@fastly.com: RFC 9234 route leak prevention in the wild!]
by David Farmer Sept. 4, 2024

Sept. 4, 2024

I think this is something we should add to our list Thanks ---------- Forwarded message --------- From: Job Snijders <job=40fastly.com(a)dmarc.ietf.org> Date: Mon, Sep 2, 2024 at 8:36 AM Subject: [Idr] [job(a)fastly.com: RFC 9234 route leak prevention in the wild!] To: <idr(a)ietf.org> Hello IDR, You might enjoy a report back from the field on route leak blocking based on RFC 9234. Please see below. Kind regards, Job ----- Forwarded message from Job Snijders <job(a)fastly.com> ----- Date: Mon, 2 Sep 2024 13:33:00 +0000 From: Job Snijders <job(a)fastly.com> To: nanog(a)nanog.org Subject: RFC 9234 route leak prevention in the wild! Dear all, I'd like to share an update on RFC 9234 deployment. RFC 9234 titled "BGP Open Policy" aka the "Only-To-Customer" (OTC) BGP Path Attribute is an anti-route-leak mechanism which is *NOT* based on RPKI! (yes ... routing security is more than just RPKI! :-) The basic idea of 9234 is that BGP routers (based on their role in the Gao-Rexford inter-domain routing model) attach a special BGP Path attribute, or take action based on the presence and contents of this BGP Path attribute - with the intention to constrain a route's propagation radius to just the downstream customer cone of the neighboring ASN. Most operators will intuitively understand that any route propagating through multiple IX route servers operated by different IXPs is a route leak: ``` IXP_1 IXP_2 / \ / \ / \ / \ ISP_A ISP_B ISP_C (receives) (leaker) (originates) ``` (figure 1. propagation from right to left; leak scenario) In the above example, ISP_A originates a route towards IXP_1's route servers, IXP_1 propagates the route to ISP_B (so far so good); but for one reason or another ISP_B subsequently continues propagation of the route towards IXP_2's route servers, who in turn propagate it to ISP_C. ISP_B is forwarding IP traffic between ISP_A and ISP_C for zero revenue. ISP_A and ISP_C are probably not expecting ISP_B to be in the middle. This situation can happen as a result of a misconfiguration in ISP_B's equipment, even when all participants use IRR & RPKI ROV to attempt to mitigate the worst routing incidents. What does it matter / impact ============================ Calgary-based YYCIX deployed RFC9234 support in late 2022/early 2023 using OpenBGPD; and FranceIX deployed support using BIRD in Q2 2024. Both IXPs configured their route servers to reject BGP routes that have an OTC attribute attached, and to attach an OTC attribute when propagating routes to the Route Server's peers. As it happens to be, currently (Mon Sep 2 12:26:50 UTC 2024) a small route leak is happening involving both YYCIX and FranceIX Route Servers via an ISP connected to both IXP's Route Servers; with the leak being stopped at YYCIX thanks to RFC 9234! Appendix A contains a table of leaked IPv4 routes. Let's zoom in on 1 entry: ``` $ bgpctl show rib 157.185.154.0/24 detail BGP routing table entry for 157.185.154.0/24 6939 38040 54994 Nexthop 206.126.225.20 (via 206.126.225.20) Neighbor 206.126.225.20 (216.218.252.194) Origin IGP, metric 1911, localpref 100, weight 0, ovs not-found, avs unknown, external, otc leak Last update: 11:58:08 ago Communities: 0:2906 0:16265 0:16276 0:18638 0:41690 0:48641 0:49029 Ext. Communities: ovs not-found Large Communities: 53339:11:1 53339:11:3 Aggregator: 54994 [163.171.131.254] OTC: 51706 ``` (figure 2. inspecting an leaked route using OpenBGPD's CLI) In figure 2. one can see the route is marked as 'otc leak', this was made possible because FranceIX's route server's attached the OTC attribute with the ASN value set to their Route Server's ASN (51706). ``` YYCIX FranceIX . x <adds OTC> \ . \ / \ ISP_A 6939_38040 54994 ``` (figure 3. right to left: real world example of blocked leak) In figure 3 AS 54994 originates 157.185.154.0/24 and propagates a route towards the FranceIX route servers. FranceIX accepts this route (probably because an IRR route object exists) and propagates it onward with the "Only-To-Customer" attribute set to 51706. The route is received by AS 38040, who appear to propagate the route to their upstream 6939. << An AS 38040 router is likely misconfigured! >> Then 6939 sends its customer's routes to the YYCIX route server, but the YYCIX route server recognizes that the route already passed through a 'valley' and thus considers this a leak; and blocks further propagation towards ISP_A. Impact with partial deployment ============================== RFC 9234 is an easy mechanism to configure and debug for both small & large network operators and IXP route server operators. In the above scenario YYCIX and FranceIX are likely the only 2 entities in the entire AS path which support RFC 9234; but we're already seeing leaks being blocked despite partial deployment! It's not hard to imagine that many IX-to-IX route leaks can be blocked with only the IXP operators themselves enabling RFC 9234 support. The world's most populair RS implementations (BIRD and OpenBGPD) already support RFC 9234! Tens of thousands of IX customers would enjoy the benefits of a few hundred IXPs taking action. RFC 9234 has no dependency on the RPKI, this means tha What can you do? ================ Just ask your vendors (your hardware routers and IXPs) to implement and deploy RFC 9234! :-) The more people ask, the more it'll bubble to the top of the priority list. The cost of implementing & deploying RFC 9234 is excellent bang for buck. Closing words ============= Shout out to our friends at FranceIX and MSK-IX for being amongst the first IXPs to deploy RFC 9234! Your effort helped reduce the potential impact of today's route leak! Kind regards, Job (YYCIX volunteer) Appendix A: ----------- Vantage point: YYCIX Route Server 1 (rs1.yycix.ca) Timestamp: Mon Sep 2 12:31:50 UTC 2024 Destination Prefix AS_PATH 102.164.129.0/24 6939 37613 6758 37649 i 102.164.139.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i 102.164.140.0/24 6939 37613 6758 37649 i 102.164.141.0/24 6939 37613 6758 37649 i 102.164.182.0/24 6939 37613 6758 37649 i 154.65.33.0/24 6939 37613 6758 37649 i 154.65.34.0/24 6939 37613 6758 37649 i 154.65.35.0/24 6939 37613 6758 37649 i 154.65.36.0/24 6939 37613 6758 37649 i 154.65.37.0/24 6939 37613 6758 37649 i 154.65.38.0/24 6939 37613 6758 37649 i 154.65.39.0/24 6939 37613 6758 37649 i 154.72.35.0/24 6939 37613 37100 37027 37063 327721 i 157.185.151.0/24 6939 38040 54994 i 157.185.154.0/24 6939 38040 54994 i 163.171.164.0/24 6939 38040 54994 i 192.150.250.0/23 6939 4651 4618 4618 63529 4621 3836 i 196.50.8.0/24 6939 37613 6758 37649 i 196.50.9.0/24 6939 37613 6758 37649 i 196.50.11.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i 196.50.13.0/24 6939 37613 6758 37649 37649 37649 37649 37649 i 196.50.14.0/24 6939 37613 6758 37649 i 2001:67c:15f4::/48 6939 41103 i 2401:c500:fd08::/48 6939 4637 38040 54994 i 2a01:53c0:ff03::/48 6939 4637 38040 54994 i 2a01:53c0:ff0f::/48 6939 4637 38040 54994 i 2a01:58c0::/32 6939 16347 42487 i 2a03:8920::/32 6939 41103 i 2a03:d602::/31 6939 16347 42487 i 2a03:d606::/31 6939 16347 42487 i 2a0d:ee00::/32 6939 16347 42487 i 2a0e:5b80::/29 6939 16347 42487 i 2a0e:e080::/32 6939 16347 42487 i 2a0f:c540::/29 6939 16347 42487 i ----- End forwarded message ----- _______________________________________________ Idr mailing list -- idr(a)ietf.org To unsubscribe send an email to idr-leave(a)ietf.org -- =============================================== David Farmer Email:farmer@umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 ===============================================

2 1