Routing policy
AS17290 BGP Routing Policy
This document sets out the BGP operational and peering requirements for AS17290. It applies to all inbound and outbound traffic and exists so that peers, transit providers, and prospective customers can evaluate route hygiene, security, and validation expectations before opening a request.
- ASN
- AS17290
- AS-SET
- AS-17290:AS-AUSTIN-HADLEY
- Operator
- Austin Hadley
Core identification and scope
- Autonomous System Number
- AS-17290
- Organizational name
- Austin Hadley
- Official AS-SET identifier
- AS-17290:AS-AUSTIN-HADLEY
The AS-SET is comprehensive and must include all immediate and downstream customer ASNs. It defines the permissible AS-Paths for routes associated with the AS17290 network structure, and it is the object peers should reference when building their filters.
Inbound route acceptance criteria
AS17290 accepts routes only from established peers or transit providers that strictly meet the prefix validation requirements below.
Every advertised IP prefix must be verifiable through at least one of the following methods. Routes that fail all validation checks are filtered and rejected automatically rather than being accepted and reviewed later.
| Requirement | Description |
|---|---|
| RPKI valid | The prefix origin is verifiably covered by a valid Resource Public Key Infrastructure (RPKI) Route Origin Authorization (ROA). |
| IRR valid | The prefix and its originating ASN are registered and verifiable within a recognized Internet Routing Registry (IRR) database. |
| LOA associated | A valid Letter of Authority (LOA) is on file with AS17290 specifically authorizing the advertised route. |
Peering and transit onboarding requirements
AS17290 welcomes requests for both mutual peering, which is settlement-free, and transit peering, which is a paid service. Both are subject to the mandatory conditions below, which exist to protect the stability of the routing table and of the wider internet.
The requesting network must ensure that its primary ASN, along with all of its downstream customer ASNs, has been properly validated and vetted — including registration, contact verification, and operational competence — and that every ASN involved in the proposed advertisements is correctly documented within the requesting network’s publicly registered AS-SETs.
Prefixes announced by the requesting network must meet the same standard of validation required for inbound routes: RPKI or IRR valid, an associated LOA, or verification by other mutually agreed means such as trusted regional Internet Registry documentation or contractual verification.
- ASN and downstream vetting completed for the primary ASN and every customer ASN behind it.
- AS-SET accuracy confirmed for all ASNs in the proposed route advertisements.
- Prefix validation satisfied through RPKI, IRR, an LOA, or mutually agreed verification.
Outbound route announcement policy
AS17290 announces only prefixes that it directly originates and those belonging to its validated customers. No third-party prefix is announced without the validation described above.
All announced prefixes are maintained with accurate IRR registrations in the form of route objects, and with valid, current RPKI ROAs. Peers are encouraged to filter on those objects rather than trusting announcements on receipt.
Requesting peering or transit
Send the requesting ASN, the AS-SET that documents it, the prefixes you intend to announce, and the validation method covering each one. Requests that already satisfy the criteria above are the fastest to process.
Operational and routing contact: [email protected]. For commercial or consulting questions, use the contact page.
The same routing and validation work is offered as a consulting engagement through BGP consulting and IPv6 consulting. If you are new to public routing, the guide What Is BGP and Why Does It Matter? explains the concepts referenced above.
Signed policy document
The text above is the authoritative policy. A PDF copy is provided for operators who need a document to attach to a peering request — you can open the routing policy PDF directly.
Policy maintained by Austin Hadley, operator of AS17290.