Summary
This page describes the policies of AS-MAO (MAO) when evaluating requests for settlement-free peering/interconnection between AS39526 or AS212546 and other autonomous systems. The policy applies to IPv4 and IPv6.
Background
MAO will peer with other networks at internet exchange points, noting that MAO peers with IX route servers where present.
Requesting peering
Networks wishing to establish peering with AS39526 or AS212546 on a settlement-free basis should email peer@mao.org 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 MAO advertises; and
– Static and default routes towards MAO are not allowed.
Maximum Prefixes
MAO will announce a maximum of the following (subject to change):
IPv4 : 25 prefixes
IPv6 : 100 prefixes
Evaluation Criteria
MAO 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.
Multiple Locations Not required
Peers should be willing and able to interconnect in at least 1 location. Peers should furthermore be willing to interconnect within any location, or at any IXP, where they and MAO are both present.
Autonomous System Number required
Peers must operate a properly allocated, globally unique autonomous system number. AS39526 & AS212546 will not peer with reserved or special-purpose ASNs.
BGP Only Routing required
AS39526 & AS212546 will exchange routing information for Internet networks with external peers using version 4 of the Border Gateway Protocol only. Peers must only send traffic towards AS39526 or AS212546 destined to a prefix for which AS39526 or AS212546 has announced. Setting static routes towards AS39526 or AS212546 is expressly prohibited.
Non-customer required
MAO does not peer with IP transit customers, nor with customers’ customers.
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 AS39526 or AS212546 (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
MAO 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, MAO requires a minimum 50 Mbps traffic exchange at the 95th percentile on a monthly basis. MAO 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 AS39526 or AS212546.
Documented Routing Policy required
Peers should maintain a publicly accessible description of their external routing policy, in a form usable by MAO 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
MAO 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 MAO via any peering interconnection. MAO 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 AS39526 or AS212546.
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 AS39526 or AS212546 at all points of interconnection, unless otherwise agreed on a case-by-case basis.
Peering Contracts
MAO prefers not to sign contracts for peering. I will evaluate requests on a case-by-case basis, balancing the additional administration burden with the benefit from peering.
RPKI ROA Signing
MAO 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.
Operational Tools
MAO prefers to peer with network operators that maintain a set of publicly available troubleshooting tools (e.g. looking glass, route server, etc) that MAO can use to diagnose routing issues.