Summary
This page describes the policies of AS-O (OIJ) when evaluating requests for settlement-free selective peering/interconnection between AS56894 and other autonomous systems. The policy applies to IPv4 and IPv6.
PeeringDB AS56894
Background
OIJ will peer with other networks at internet exchange points, noting that OIJ peers with IX route servers where present.
Requesting peering
Networks wishing to establish peering with AS56894 on a settlement-free basis should email peering@oij.net and include the details of the peering being requested; peer ASN, IXP, and contact details for provisioning and operations.
Peering Requirements
– Use a registered public autonomous system (AS) number;
– Publish valid contact information on PeeringDB;
– Maintain valid AS and prefix records with a public Internet Routing Registry (IRR);
– A peer may only send traffic intended for a destination networks OIJ advertises; and
– Static and default routes towards OIJ are not allowed.
Maximum Prefixes
OIJ will announce a maximum of the following (subject to change):
IPv4 : 100 prefixes
IPv6 : 500 prefixes
Evaluation Criteria
OIJ will evaluate all peering requests against the below criteria. Some criteria are marked required: requests to peer are highly unlikely to be accepted without all such criteria being met.
Global Reachability required
Peers must demonstrate that all announced prefixes (or their aggregates) are visible in the Internet DFZ.
Operational Contacts required
Peers are required to operate a NOC (or equivalent) that is contactable on a 24x7x365 basis, staffed with suitably skilled network engineers, and available on a reasonable time-frame to jointly troubleshoot operational problems involving the peering interconnection. Operational contact details should be published on PeeringDB, along with other relevant peering details.
Congestion Free Interconnections required
Peers must maintain congestion free interconnections between themselves and AS56894 (or, in the case of IXP peering, between themselves and the IXP fabric). Aggregate interconnection capacity must be sufficient to operate congestion-free in the face of at least one failure. Peers must agree to upgrade interconnection capacity to meet growth in peak demand as and when required.
Traffic Volume required
OIJ does not require a minimum set threshold to consider peering at an IXP, although there should be sufficient traffic exchanged to warrant the administration of the peering relationship. For peering on PNI, OIJ requires a minimum 50 Mbps traffic exchange at the 95th percentile on a monthly basis. OIJ does not require traffic ingress/egress ratios in most cases.
Backbone Transport Capacity required
Peers operating an Internet backbone must ensure they maintain sufficient on-net capacity to provide congestion free transport of traffic, including in the face of the failure of at least one interconnection with AS56894.
Documented Routing Policy required
Peers should maintain a publicly accessible description of their external routing policy, in a form usable by OIJ to determine the correctness of the routing information received in BGP. At minimum, this should consist of the following RPSL objects, registered in one of the IRR databases mirrored by RADB:
autnum: An object describing the policy and contact details for the peer’s ASN
as-set: An object describing the set of ASNs for which the peer announces transit
route/route6: An object, for each prefix announced by the peer, specifying the ASN originating that prefix in BGP
OIJ will use the above information to build inbound prefix filters automatically. Peers must ensure that this information is kept up to date by themselves and their customers at all times.
Anti-spoofing required
Peers must take reasonable measures to prevent IP packets with a spoofed source address being sent to OIJ via any peering interconnection. OIJ will have regard to the nature of the network operated by peers when determining whether a particular measure is reasonable in this context.
Anti-leak Filtering
Peers should have mechanisms in place to ensure that only prefixes for which they are properly authorized to announce transit are exported to AS56894.
Announcement Consistency
Peers operating an Internet backbone or with a dominantly inbound traffic profile should ensure that a consistent set of prefixes are announced to AS56894 at all points of interconnection, unless otherwise agreed on a case-by-case basis.
RPKI ROA Signing
OIJ performs strict RPKI-based route origin validation, and prefers to peer with operators who maintain validly signed ROAs for their own prefixes, and who encourage their customers to do the same.