HyperLink AS208915

HyperLink (AS208915) carries traffic for services where availability and integrity matter, so we run a routing-secure, resilient network that is monitored around the clock. Within that, our peering stance is open — we welcome settlement-free peering with networks of any size, at internet exchanges and over private interconnect, and we peer with IXP route servers wherever they are available. The goal is to keep traffic local, lower latency, and reduce dependence on transit, without compromising on security.

At a glance

ASN

AS208915

Posture

Open peering · routing-secure operations

AS-SET

AS208915:AS-HYPERSET

IRR records

registered in a recognised IRR (RIPE, RADB, ARIN, APNIC, ALTDB, …)

RPKI

all prefixes have valid ROAs; we run ROV and drop invalids

ASPA

published, for AS-path validation

MANRS

actions implemented

Smallest accepted

IPv4 /24 · IPv6 /48

Max-prefix (v4 / v6)

100 / 100

NOC

staffed 24×7×365

PeeringDB

peeringdb.com/asn/208915

Contact

[email protected]

What we expect from a peer

• A globally routable ASN and your own RIR-assigned address space.
• BGP sessions over both IPv4 and IPv6 where both parties are dual-stacked.
• Current PeeringDB and IRR (RPSL) records in any recognised registry — RIPE, RADB, ARIN, APNIC, ALTDB or equivalent — so your prefixes can be filtered against your AS-SET.
• Signed ROAs (RPKI) for the prefixes you originate. We run Route Origin Validation and drop RPKI-invalid routes; ASPA-based path checks are applied where data exists.
• A staffed NOC reachable for operational and security issues — minimum 12×5, with 24×7 strongly preferred given the nature of the networks we serve.
• Alignment with MANRS norms.

NOC, contact and the right to withdraw

• A reachable operational contact is a hard requirement, not a courtesy. We maintain a 24×7×365 NOC and a security contact at [email protected].
• If we cannot reach you to resolve an operational or security incident affecting a shared session, we reserve the right to withdraw or suspend that session until contact is re-established. We accept the same in reverse: if you cannot reach us, you may do likewise.
• Both parties should keep an escalation path current in PeeringDB so issues can be raised quickly at any hour.

What we will and won't announce

• We announce only our own prefixes and those of our customers — never routes learned from other peers or upstreams (no transit via a peering session).
• We do not announce a default route, martians, bogons, or RFC1918 space.
• We will not point a static or default route at a peer for anything not exchanged over BGP.
• We accept prefixes of IPv4 /24 and larger, and IPv6 /48 and larger — a /24 (256 addresses) and a /48 are the smallest blocks we accept; bigger aggregates such as a /22 or /16 are fine. Anything smaller than that (IPv4 /25–/32, IPv6 /49–/128) is rejected on receive, except host routes carrying a recognised BLACKHOLE community.

Routing security & resilience

• RPKI ROV on all sessions; RPKI-invalid routes are dropped, not de-preferred.
• AS-path sanity checks: strict first-AS enforcement, AS-path length limits, and Tier-1/large-network ("peerlock"-style) filters to catch route leaks.
• RTBH / BGP BLACKHOLE (RFC 7999, 65535:666) supported for rapid DDoS mitigation; graceful-shutdown (65535:0, RFC 8326) honoured for planned maintenance.
• Source-address validation (uRPF / ACLs) toward edges to limit spoofing.
• Our practices follow MANRS and the guidance in NIST SP 800-189 (BGP security & resilience).

Technical defaults

• The first AS in the path must match the peer ASN, or the prefix is dropped.
• MED is reset on receive unless evaluation is agreed in advance.
• Well-known communities are passed through; non-transitive communities are scrubbed at the edge.
• BFD is available on request to speed up failure detection.
• MD5/TCP-AO session authentication available on request.

Our rights

• We may accept or decline any peering request, and may revise this policy, at any time.
• We may suspend a session without notice to protect service integrity (severe loss, latency, abuse, suspected hijack, or loss of contact), and selectively withdraw prefixes as needed.