Peering policy.
Open, free, and filtered in both directions.

Policy

This is a personal network operated to production standards rather than a commercial carrier, and the policy is written to say so plainly. What it lacks in scale it makes up for in a maintainer who reads his own logs.

Requirements

• A registered ASN and a public PeeringDB record. If we cannot look you up, we cannot filter you.
• Valid IRR objects and RPKI ROAs covering everything you announce. Routes that are RPKI-invalid, or that fail IRR validation, are rejected rather than deprioritized.
• No prefixes shorter than /24 for IPv4 or /48 for IPv6.
• A single, consistent AS path with no bogon and no private ASNs.
• No default and no transit through us. Do not point default at MARKVD-NET or forward transit traffic through it. We announce only our own address space and provide no transit to anyone.
• A reachable technical and NOC contact, kept current in PeeringDB. A stale contact is the most common reason a session stays down longer than it needed to.

Routing security

AS402766 is operated in accordance with the MANRS expected actions:

• Filtering. Inbound and outbound prefix filtering, built from IRR data and refreshed rather than set once.
• Origin validation. RPKI route origin validation applied to everything received. Invalid means dropped.
• Anti-spoofing. Source address validation per BCP 38 at the network edge.
• Coordination. Current contact information published in PeeringDB and in security.txt.
• Global validation. Routing data published publicly through IRR and RPKI. We announce only our own registered aggregates and originate no more-specifics.

Contact

To request peering, email peering@markvd.net with your ASN, the exchange and your peering addresses there, and your expected IPv4 and IPv6 prefix counts. Include your AS-SET if it differs from your ASN.