Peering policy

Last changed on 8 September 2026

This applies to every BGP session with AS197658: IXP route servers, WireGuard tunnels and private sessions alike. If anything here is unclear, ask at noc@as197658.de before you request a session.

1. RPKI

Every prefix you announce to me needs a valid, signed ROA. Route origin validation is enforced on all sessions.

RPKI-invalid routes are rejected automatically.
RPKI-unknown routes may be rejected, depending on the type of session.

2. IRR

The address space you announce needs correct inetnum or inet6num objects, and every prefix needs a matching route or route6 object in a recognised IRR such as RIPE or RADB. Filters are built with bgpq4 from your AS-SET, so that has to be correct as well.

The objects must resolve for the exact ASN and prefixes you announce on the session. Stale, missing or mismatched objects will delay activation or block it entirely, and without valid route objects the session won't be brought up. If your upstreams support ASPA, please publish an ASPA object.

On my side, imports are checked against IRR, RPKI and ASPA, along with bogon and max-prefix filters. AS197658 takes part in MANRS.

3. What isn't allowed

I won't peer with networks used for any of the following:

Illegal activity. Illegal content, including CSAM and the illegal trade in weapons or drugs. Phishing, malware and botnet command-and-control. Fraud, scams and trading stolen data or credentials. Piracy and warez hosting.
Tor. Exit nodes, relays and bridges, and any anonymising proxy used to hide where abuse comes from.
Spam and attacks. Unsolicited bulk email. DDoS and amplification attacks, such as open resolvers or NTP and memcached reflection. Booter and stresser services. Unauthorised port or vulnerability scanning, and route hijacking.
Listed and unroutable ASNs. ASNs on the Spamhaus DROP list, and ASNs that shouldn't appear in the global routing table at all.

4. Enforcement

Anything from section 3 gets the session torn down immediately, without notice.
Missing or invalid ROA or IRR objects get a 48-hour grace period to fix them before the session is suspended.
Abuse reports sent to the NOC are acknowledged and handled within 24 hours.
After repeated or unresolved violations, future peering requests from that ASN are refused for good.

5. Requesting a session

Use the peering portal, or write to noc@as197658.de. My details are on PeeringDB, and the looking glass and bgp.tools show what I'm announcing right now.