MANRS Implementation Guide


Being a responsible network operator requires both publishing contact and routing policy information, and using the information published by others to verify the information in the routing table.

5.1. Publishing information – checklist

There are many places where information can be published. This summary can be used as a checklist when publishing and updating information, and can be included in your organisation’s processes and procedures.

  • For the AFRINIC, APNIC and RIPE NCC region:
    • Publish contact information for roles/departments as ROLE objects
      Optionally: create PERSON objects for staff members and link from the ROLE
    • Create IRR objects and refer to the correct POCs from those objects and document your routing policy:
      • INETNUM and INET6NUM
        • admin-c: refer to your IPAM administrators
        • tech-c: refer to the administrators of the systems on this network
      • AUT-NUM
        • admin-c: refer to your peering coordinators
        • tech-c: refer to your NOC
        • mp-import/mp-export: document your BGP connections
      • ROUTE and ROUTE6
        • remarks: document contacts for your NOC, abuse desk, etc.
        • ping-hdl: refer to your NOC
    • Create RPKI ROAs for all prefixes that you announce from your ASNs
    • Publish your peering locations, policy and contacts in PeeringDB
    • Publish your peering locations, policy and contacts on your website
    • Publish your NOC and abuse contacts on your website
  • For the LACNIC region:
    • Publish contact information for roles/departments as POC objects
    • Publish contact information for the Organizations holding resources (directly allocated by LACNIC or re-allocated by a LIR)
    • Publish the DNS that provides the reverse resolution for IP blocks
    • Refer to the correct POCs for you resources:
      • tech-c: refer to your IPAM administrators
      • abuse-c: refer to your network abuse desk
    • Create RPKI ROAs for all prefixes that you announce from your ASNs
    • Publish your peering locations, policy and contacts in PeeringDB
    • Publish your peering locations, policy and contacts on your website
    • Publish your NOC and abuse contacts on your website
  • For the ARIN region:
    • Publish contact information for roles/departments as POC objects
    • Refer to the correct POCs from your resources
      •  NET
        • NOC POC: refer to your NOC and optionally sysadmins
        • Tech POC: refer to your IPAM administrators
        • Abuse POC: refer to your systems abuse desk
      • ASN
        • NOC POC: refer to your NOC and peering coordinators
        • Tech POC: refer to your IPAM administrators
        • Abuse POC: refer to your network abuse desk
    • Create IRR objects and refer to the correct POCs from those objects and document your routing policy:
      • INETNUM and INET6NUM
        • admin-c: refer to your IPAM administrators
        • tech-c: refer to the administrators of the systems on this network
      • AUT-NUM
        • admin-c: refer to your peering coordinators
        • tech-c: refer to your NOC
        • mp-import/mp-export: document your BGP connections
      • ROUTE and ROUTE6
        • remarks: document contacts for your NOC, abuse desk, etc.
    • Create RPKI ROAs for all prefixes that you announce from your ASNs
    • Publish your peering locations, policy and contacts in PeeringDB
    • Publish your peering locations, policy and contacts on your website
    • Publish your NOC and abuse contacts on your website

5.2. Validating information – checklist

Operating a network in a responsible way requires validation of the traffic you and your customers send to the rest of the Internet, and validation of the routes that your upstreams, peers and customers announce to you. Failing to validate any of this makes your network vulnerable to route hijacks and a potential source of DDOS attack traffic.

  • Apply ACLs and/or uRPF filtering to your customers’ connections
  • Apply ACLs, uRPF and/or SAVI filtering to your own networks
  • Use the information in the IRRs to filter routes that your neighbours announce to you
  • Verify the routes in your routing table against the RPKI ROAs