_____ ___  __  ___ ____  __ ___  
     /\    / ____|__ \/_ |/ _ \___ \/_ |__ \ 
    /  \  | (___    ) || | | | |__) || |  ) |
   / /\ \  \___ \  / / | | | | |__ < | | / / 
  / ____ \ ____) |/ /_ | | |_| |__) || |/ /_ 
 /_/    \_\_____/|____||_|\___/____/ |_|____|
                                             

DaKnObNET - AS210312

+----------------+
| PEERING POLICY |
+----------------+

If you are interested in peering with AS210312 in any facility or Internet
Exchange, feel free to reach out to peering@daknob.gov, and replace gov with
net. Peering is as it should be: free and open. There's no cost, commitments,
requirements, etc. but is therefore subject to availability and best-effort
basis to try and help both networks. Remote peering will be considered but is
not preferred.

You can find the PeeringDB entry here.

Peering Policy:       Open
Multiple Locations:   Not required / Preferred
Ratio Requirement:    No
Contract Requirement: No

In order to calculate traffic estimates, you can use AS-SET-DNET in RIPE's
database. Some ports may not be available at all locations (i.e. ≤ 1G /
copper).

+------------------------+
| TECHNICAL REQUIREMENTS |
+------------------------+

You need to meet the following (very basic) technical requirements:

* Publicly routable ASN
* Publicly routable IP space (/24-/48 IPv6, /8-/24 IPv4)
* Up-to-date PeeringDB entry
* Up to date Maintainer, ASN, AS-SET, and Route/Route6 objects in an IRR DB
* Support for 32-bit ASNs

+-----+
| NOC |
+-----+

For network-related issues you can e-mail noc@daknob.gov, but first you need to
replace `gov' with `net' for it to work. If it is something more urgent, you
can escalate to daknob@daknob.gov, with the same replacement rule as above.

+-------+
| ABUSE |
+-------+

If there is a security issue, and you are in the receiving end of an attack
that is originating from AS210312 and it's something that you need assistance
with, please contact abuse@daknob.gov, making sure to replace `gov' with `net'
to ensure your e-mail will be delivered.

A response to your e-mail is not guaranteed, but action could be taken to
assist with your request.

+---------------+
| PREFIX LIMITS |
+---------------+

Up-to-date and recommended prefix limits for all BGP sessions are posted on the
PeeringDB entry for AS210312, which is linked above. Given the relatively small
number of prefixes originating or transiting currently there is a large and
adequate buffer built into the numbers that can accomodate for emergency
traffic engineering, should there is a need for it, without risking leaks of a
lot of routes to your network.

+----------------+
| ADDRESS FAMILY |
+----------------+

Obviously, IPv6 is preferred, but there's no requirement for peering. You can
be single-stacked or dual-stacked, it's all fine.

+------------------+
| ROUTING SECURITY |
+------------------+

Please make sure to follow industry best practices for the security of your
routing / control plane. Ideally practice good MANRS and try to use RPKI
with at least published ROAs, if you can't do origin validation. Also, please
implement some type of source and destination address spoofing prevention
mechanism so as not to send any bogous traffic via our peering sessions.
Finally, do not send any traffic (e.g. via static routes) via a peering link
to a destination that is not explicitly advertised to you over our BGP session.