_____ ___ __ ___ ____ __ ___ /\ / ____|__ \/_ |/ _ \___ \/_ |__ \ / \ | (___ ) || | | | |__) || | ) | / /\ \ \___ \ / / | | | | |__ < | | / / / ____ \ ____) |/ /_ | | |_| |__) || |/ /_ /_/ \_\_____/|____||_|\___/____/ |_|____| 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.