Peering Policy - AS203314

Policy at a Glance

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 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 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 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 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.

Operational Requirements

Peers must provide a 24×7 NOC 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 [email protected]; new peering requests should be sent to [email protected].

Capacity and Traffic

• There is no minimum traffic requirement for peering over an Internet Exchange.
• A Private Network Interconnect (PNI) 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

Peering Methods

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.