# Peering Policy - AS203314 > **Open Peering Policy** > > Hats Network Inc. (AS203314) maintains an **open peering policy**. We welcome peering requests from networks that meet the requirements below, subject to available capacity, route security, operational readiness, and mutual agreement. > > Current interconnection locations, addresses, and network statistics are maintained on our [PeeringDB record](https://www.peeringdb.com/asn/203314), which is the authoritative source for operational peering data. ## Policy at a Glance | Item | Policy | | --------------------- | ---------------------------------------------------------------------------------------- | | General policy | Open | | Autonomous system | AS203314 | | IRR AS-SET | `AS203314:AS-HATS` | | Address families | IPv4 and IPv6; dual-stack sessions are preferred where both are available | | Traffic ratio | No fixed ratio requirement | | Minimum IX traffic | None | | Multiple locations | Preferred for resilience | | Bilateral IX contract | Not normally required | | Operational source | [PeeringDB](https://www.peeringdb.com/asn/203314) for current IX, facility, and NOC data | ## Technical Requirements Networks requesting peering must: 1. Operate a publicly routable **Autonomous System Number (ASN)**. 2. Announce at least one globally routable **IPv4 /24** or **IPv6 /48** prefix. 3. Maintain a complete and current [PeeringDB](https://www.peeringdb.com/) profile, including routing, facility, and 24×7 NOC information. 4. Maintain accurate route or route-set objects in a public **Internet Routing Registry (IRR)**. 5. Connect at a shared Internet Exchange or data centre, or use a mutually approved [Layer 2/3 tunnel](/docs/peering/via-tunnel) endpoint. 6. Provide sufficient, stable interconnection capacity and avoid sustained congestion or packet loss. Dual-stack peering is preferred whenever both networks support IPv4 and IPv6 at the interconnection. Single-stack sessions may be accepted when an address family is unavailable at a specific location. ## Routing and Security Policy ### Route registration and validation * Peers must keep their IRR objects, RPKI Route Origin Authorizations (ROAs), and PeeringDB data accurate and up to date. * AS203314 builds inbound filters from public routing data and may reject unregistered routes, RPKI-invalid announcements, bogons, default routes, malformed AS paths, and prefixes more specific than IPv4 /24 or IPv6 /48. * Peers should announce only their own routes and customer routes represented by their published AS-SET. * Route-security practices should align with [MANRS](https://www.manrs.org/) principles. RPKI-valid announcements are strongly preferred; RPKI-invalid announcements are rejected. ### Route exchange * AS203314 generally advertises its eligible routes in all peering locations. Announcements may vary for maintenance, traffic engineering, security, or service-specific reasons. * We accept standard BGP communities where operationally supported. See our [BGP Communities reference](/docs/community) for available controls. * Peers must configure a reasonable maximum-prefix limit based on current PeeringDB and IRR data, with enough headroom for normal growth. Material changes should be coordinated with our NOC. * Do not rely on Multi-Exit Discriminator (MED) handling unless it has been agreed in advance. * Neither party may use a static route, a default route, or any other mechanism to send traffic for destinations not announced to that party through BGP. * Traffic may not be forwarded through a third party over the peering interconnection unless both networks have explicitly agreed to that service. > **Filtering and session protection** > > AS203314 may suspend a session that leaks routes, exceeds its agreed prefix limit, causes instability, or creates a security or operational risk. We will make a reasonable effort to notify the peer through its registered NOC contact. ## Operational Requirements Peers must provide a [**24×7 NOC**](/docs/about#contact-us) capable of working with us on routing incidents, performance degradation, denial-of-service attacks, abuse, and security events. * NOC email and telephone details must remain current on PeeringDB. * Both parties should communicate planned maintenance that may materially affect the interconnection. * Peers must investigate route leaks, session instability, abuse, or congestion promptly. * BGP MD5 and BFD may be enabled where supported and mutually agreed. * Operational issues should be reported to [noc@hatsnet.io](mailto:noc@hatsnet.io); new peering requests should be sent to [peering@hatsnet.io](mailto:peering@hatsnet.io). ## Capacity and Traffic * There is **no minimum traffic requirement** for peering over an Internet Exchange. * A [Private Network Interconnect (PNI)](/docs/peering/via-cross-connect) may be preferred when traffic is sustained above **1 Gbps**, when an IX path is congested, or when resilience and traffic engineering justify a dedicated interconnection. * PNI speed, optics, cross-connect, and redundancy are agreed per location. 10G and 100G single-mode fibre are preferred where available. * Peers should begin capacity-upgrade planning when sustained peak utilization exceeds **50%**, and complete the upgrade before congestion affects traffic. ## How to Peer ### Step 1: Verify eligibility Confirm the requirements above and review our current [PeeringDB record](https://www.peeringdb.com/asn/203314) for common locations, session addresses, and expected route counts. ### Step 2: Send a request Email [peering@hatsnet.io](mailto:peering@hatsnet.io) with your ASN, PeeringDB URL, requested location and address families, expected traffic, advertised prefix count, and preferred interconnection method. ### Step 3: Configure and validate After both parties confirm the session details, configure route filters, maximum-prefix protection, and any agreed MD5 or BFD settings. We will validate route exchange and reachability before considering the session operational. ## Peering Methods - [Internet Exchange](https://www.peeringdb.com/asn/203314) — Public peering at our current Internet Exchange locations. - [Private Interconnect (PNI)](/docs/peering/via-cross-connect) — Dedicated cross-connect or private VLAN at a supported facility. - [Tunnel Peering](/docs/peering/via-tunnel) — A mutually approved Layer 2 or Layer 3 tunnel interconnection. ## Policy Administration Meeting this policy does not guarantee a peering relationship. Hats Network may accept, decline, suspend, or terminate peering where capacity, security, commercial, legal, or operational considerations require it. We may update this policy as our network evolves; material session changes will be coordinated through the registered NOC contacts whenever practical. --- ## License and attribution - **Canonical source:** [View the human-readable HTML page](https://hatsnet.io/docs/peering). - **Original documentation:** © Hats Network Inc., licensed under [CC BY-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/). - **Full terms:** [Content and Data License](https://hatsnet.io/docs/legal/content-and-data-license) — includes attribution requirements, third-party material, trademarks, source code and other exclusions.