V2024-03-17

0. TL;DR

  • This is a personal AS.
  • Peering via Wireguard.
  • I have a VPS at Hetzner Nürnburg or First Root Düsseldorf.
  • Only send your own prefixes.

1. Introduction

This policy outlines the terms for establishing peering connections while incorporating specific restrictions.

Please note: AS216427 is operated by me (a private individual) for educational purposes.

2. Peering Eligibility

I welcome peering requests from networks that meet the following criteria:

  • AS Number: Peering partners must have a valid, registered Autonomous System (AS) number.
  • WireGuard Capability: Peering sessions will be established via WireGuard tunnels.
  • Traffic Limits: To ensure fair resource utilization, I encourage peering partners to limit traffic within reasonable bounds. While I don’t impose strict bandwidth caps, I expect responsible usage.
  • Location: Location technically doesn’t matter. I have a VPS at Hetzner Nürnburg or First Root Düsseldorf, peering there could save some hops, compared to me getting the routes from my upstreams.

3. Technical Requirements

3.1 WireGuard Configuration

  • Both parties should configure their WireGuard tunnels with the following parameters:
    • IP Addresses: Assign unique IPv4 or IPv6 addresses for the tunnel endpoints.
    • Authentication: Optional: Use pre-shared keys (PSKs) for secure authentication.

3.2 Route Exchange

  • I will only send my own IPv6 prefixes via the BGP session. I expect the other peering party to do the same. I can’t / won’t serve as transit / upstream.

4. Traffic Management

4.1 Traffic Limits

  • While I don’t enforce strict bandwidth caps, I expect peering partners to:
    • Avoid Abuse: Refrain from saturating the link or causing congestion.
    • Notify in Advance: Inform me if significant traffic changes are anticipated.

4.2 Congestion Control

  • In case of congestion, both parties will collaborate to fix the issue.
  • If necessary, I may implement rate limiting or traffic shaping.

5. Specific Restrictions

To maintain network integrity and stability, the following restrictions apply:

5.1 Prefix Announcements

  • Default Route: Announcing the default route (0.0.0.0/0 or ::/0) is not allowed.
  • Bogus / Reserved Prefixes: Announcing prefixes that are reserved (relevant RFCs by the IETF) is not allowed.
  • Prefix Ownership: Or in other words: Only announce prefixes that you legitimately own and control.

5.2 AS Number Announcements

  • Reserved AS Numbers: Announcing AS numbers reserved for documentation or testing purposes (e.g., AS23456) is not allowed.

6. Rights and Responsibilities

  • Mutual Benefit: Peering is a cooperative endeavor, and both parties should benefit from the arrangement.
  • No SLA: I do not provide Service Level Agreements (SLAs) for peering.
  • Termination: Either party may terminate the peering agreement, an e-mail suffices.

7. Contact Information

For peering inquiries or to initiate a peering session, please contact me via the contact seen in the RIPE DB or on peeringdb.com. Information needed: AS Number (and RIR DB in which it is registered, if you want to save me some time), Wireguard tunnel details (endpoint, i.e. IP and port, public key, suggestions for internal tunnel addresses are welcome), prefixes you intend to send.