Coordination


MANRS Implementation Guide


4.1. Coordination – Facilitating global operational communication and coordination between network operators

Relevant MANRS expected actions:

  • Network operator maintains globally accessible up-to-date contact information

Publicly accessible and up-to-date contact information is essential to promoting communication and collaboration between network operators. Network operators are advised to maintain their contact data in common places such as the PeeringDB, on objects registered in RIR whois databases such as RADB and RIPE, and also on their public website. At a minimum, a network operator should register and maintain 24/7 contact information in at least one of these databases. This contact information should include the operator’s current point of contact information for the NOC of their ASN, all netblocks, and domain names. Additional information is also welcome and encouraged, such as, for example, documenting of route policy in an IRR and contact information on a public web page, providing a public looking glass URL in the appropriate field in their PeeringDB record, etc.

The following is a list of these common places along with recommendations on which information should be maintained and how it can be presented. At the minimum, a network operator should register and maintain 24/7 contact information in at least one of these resources.

4.1.1. Maintaining Contact Information in Regional Internet Registries (RIRs): AFRINIC, APNIC, RIPE

While all of the RIRs require their registrants to keep their primary contact information up-to-date, the RIRs also offer the capability to add additional contacts and contact information to records in their databases. Operators are encouraged to add/maintain the NOC contact information where they have RIR objects. Operators are also encouraged to make use of the ‘remarks’ field (where applicable) to further aid users in making contact information or other useful information easy to obtain.

AFRINIC, APNIC and RIPE maintain a whois system that combine Internet resource registration with their own Internet Route Registry. For objects in these databases, operators should create/maintain a NOC role object and include that object in the “tech-c” attribute of AUT-NUM, INETNUM, INET6NUM, AS-SET, and ROUTE-SET objects. The use of the ‘remarks’ attribute also allows for the documentation of contact information, and can be added to the above object types and also to ROUTE and ROUTE6 objects (discussed later).

4.1.1.1. MNTNER objects

A maintainer (or MNTNER) object in an IRR database is used for managing authorization and authentication. Other objects refer to maintainers using, for example, one or more “mnt-by” attributes. Such an attribute protects those objects by only allowing changes when the updater can authenticate themselves as one of the maintainers.

Maintainers always have to refer to a contact who is responsible for that maintainer. Therefore to create new maintainers it is necessary to also create a contact person.

4.1.1.1.1. Creating a new maintainer in the AFRINIC IRR

To create a new maintainer in the AFRINIC IRR you first need an existing person or role object to use as the contact for the maintainer. The AFRINIC IRR allows you to create a person and/or role object that is not protected by a maintainer. While not protecting your data in the IRR is highly discouraged, it does provide you with a starting point. First create a PERSON object in the database by sending an email with content like the following to auto-dbm@afrinic.net:


    person:   Some Random Person
    address:  Somewhere
              7300 XX  Apeldoorn
              The Netherlands         
    phone:    +31-55-0000000
    e-mail:   someone@example.com
    nic-hdl:  AUTO-1
    notify:   someone@example.com
    changed:  someone@example.com  
    source:   AFRINIC

The “nic-hdl” specifies the identifier that other objects can refer to. By specifying AUTO-1 during creation the system will automatically generate a unique identifier, which you will see in the confirmation email you receive from the database after the object has been created. In this example we’ll assume the new identifier is “SRP9999-AFRINIC”.

Now that you have a contact person in the database you can create a maintainer by sending an email with content like the following to auto-dbm@afrinic.net:


    mntner:   MAINT-AS64500
    descr:    Some Random Person’s maintainer        
    admin-c:  SRP9999-AFRINIC
    upd-to:   MD5-PW $1$cu/QEuCu$qKl69lv4c4t0by7XNQqRX.
    auth:     AUTO-1
    mnt-by:   MAINT-AS64500
    changed:  someone@example.com  
    source:   AFRINIC
    password: SomePassword

The “auth:” attribute contains a hashed password which you can create on http://www.afrinic.net/services/ip-tools/whoiscrypt. Never use the CRYPT-PW method, it is no longer secure.

This example uses a mnt-by attribute that references itself. This means that the data for this maintainer is protected by the maintainer itself. To prove that you are indeed authorized to create this maintainer you have to provide the password matching the auth attribute as an extra attribute when sending the update. This password attribute will not be stored in the IRR database.

Now that we have a MNTNER we need to protect our PERSON object with it. Otherwise anybody could submit changes to it. Updating an existing object is done by sending a modified version of the object to auto-dbm@afrinic.net:


    person:   Some Random Person
    address:  Somewhere
              7300 XX  Apeldoorn
              The Netherlands         
    phone:    +31-55-0000000
    e-mail:   someone@example.com
    nic-hdl:  SRP9999-AFRINIC
    notify:   someone@example.com
    mnt-by:   MAINT-AS64500
    changed:  someone@example.com  
    source:   AFRINIC
    password: SomePassword

In this example we added a mnt-by attribute to protect the person. Remember to use the real nic-hdl for the person when sending the update so that the IRR database knows to update the person object instead of creating a new one. To show that we are authorized to add this maintainer we also have to provide the maintainer’s password when sending the update. Again, this password attribute will not be stored in the IRR database.

Now we have a PERSON (nic-hdl: SRP9999-AFRINIC) and a maintainer (mntner: MAINT- AS64500) that we can use to publish further data in the IRR.

4.1.1.1.2. Creating a new maintainer in the APNIC IRR

APNIC automatically creates a maintainer and role object for all new members. If members wish to create a new maintainer object, they can create it through the MyAPNIC portal at https://myapnic.net: MyAPNIC -> Resources -> Whois updates -> Add -> Mntner

4.1.1.1.3. Creating a new maintainer in the RIPE IRR

The RIPE IRR does not permit objects to be unprotected. It is therefore not possible to create a PERSON object first and then create a MNTNER that references that person. It is also not possible to create a MNTNER first because it needs a reference to a PERSON.

To resolve this catch-22 situation, the RIPE NCC provides a web interface to create a person and maintainer together at https://apps.db.ripe.net/db-web-ui/#/webupdates/create/person/self. To be able to access that page you need to have a RIPE NCC Access account, which can be created at https://access.ripe.net/registration.

Your maintainer is automatically linked to your access account so that you are automatically authenticated as that maintainer when editing IRR objects through the web interface. You can also edit the maintainer and add an “auth: MD5-PW” attribute. That allows you to submit updates through the e-mail interface at auto-dbm@ripe.net in the same way as described above for the AFRINIC IRR.

4.1.1.2. ROLE objects

PERSON objects are important points of contact, especially in very small organisations. They are too limited for a more complex organisational structure though. In many cases the proper point of contact is a department, a job function or a group of people. For that the IRR system supports ROLE objects.

A ROLE object can be referenced everywhere a PERSON object can. Both are identified by their nic-hdl attribute. The advantage of using a ROLE object is that while people can change jobs and move to a different organisation, a role does not change. A ROLE object can, in fact, optionally refer to other PERSON objects, adding information about contact persons for a specific group or department.

This is an example of a typical role object which utilizes the ‘remarks’ attribute to provide additional information. In this example, the network operator provides contact details for the ‘role’ object, but also provides summary information in the ‘remarks’ attribute not just for their NOC information, but also for their abuse and security contacts, and a URL to the operator’s PeeringDB info page.


    role:             AS64500 NOC
    remarks:          NOC: noc@example.net
    remarks:          Security issues: security@example.net
    remarks:          https://as64500.peeringdb.com/
    e-mail:           noc@example.net
    abuse-mailbox:    abuse@example.net 
    nic-hdl:          AS64500NOC-RIPE
    mnt-by:           MAINT-AS64500
    created:          2012-10-27T12:14:23Z
    last-modified:    2016-02-27T12:33:15Z
    source:           RIPE

4.1.1.3. INETNUM and INET6NUM objects

IRRs are used to document information about resources such as IP address blocks and AS numbers. IPv4 ranges and IPv6 prefixes are documented using INETNUM and INET6NUM objects.

The ROLE object above is referenced in the ‘tech-c’ attribute of this INET[6]NUM object example. The ‘remarks’ attribute also provides additional information.


    inet6num:         2001:db8::/32
    netname:          EXAMPLE-NET
    descr:            An example allocation
    remarks:          NOC: noc@example.net
    remarks:          Security issues: security@example.net
    remarks:          https://www.peeringdb.com/asn/64500
    country:          CH
    status:           ALLOCATED PA
    org:              ORG-AS64500-RIPE
    admin-c:          AS64500NOC-RIPE
    tech-c:           AS64500NOC-RIPE
    mnt-by:           RIPE-NCC-HM-MNT
    mnt-lower:        MAINT-AS64500
    mnt-routes:       MAINT-AS64500
    created:          2012-10-27T12:14:23Z
    last-modified:    2016-02-27T12:33:15Z
    source:           RIPE

IRRs that are linked to the RIR database don’t allow users to create their own top-level allocations. Those are automatically created by the RIR and can often only be edited through their web portal.

In the example given above you can see that the maintainer for the object is RIPE-NCC-HM- MNT, the maintainer of RIPE NCC itself. As a user you are only allowed to maintain (create) lower level objects, such as the assignments you make from this allocation and ROUTE/ROUTE6 objects to document routing the prefix.

4.1.1.4. AUT-NUM objects

AS Numbers (ASNs) are documented using AUT-NUM objects. These objects contain information about the ASN and its peering policy. The level of detail that organisations publish in their AUT-NUM object varies. In this section we focus on the contact information. For information on publishing routing policies and using them for validation of routing information see sections 4.3 and 4.4.

An example of a minimal AUT-NUM object is:


    aut-num:          AS64500
    descr:            Provider 64500 
    mp-import:        from AS64510 accept ANY except FLTR-BOGONS
    mp-export:        to AS64510 announce AS64500:AS-ALL
    admin-c:          AS64500NOC-RIPE
    tech-c:           AS64500NOC-RIPE
    mnt-by:           MAINT-AS64500
    created:          2012-10-27T12:14:23Z
    last-modified:    2016-02-27T12:33:15Z
    source:           RIPE

4.1.2. Maintaining Contact Information in Regional Internet Registries (RIRs): LACNIC

LACNIC uses a different system where resource holders can update their contact information through the lacnic.net web interface. While the format of the information looks the same as for the IRRs, there are significant differences. For example there is no INET6NUM object type, both IPv4 and IPv6 address space uses INETNUMs. The possible attributes for the object types are different as well.

Contact information can be updated in LACNIC’s administrative system: http://lacnic.net/cgi-bin/lacnic/stini

Logging in with your userID you can access information about your personal user, organization information and resources information.

  • In the tab “ID UPDATE[userID]” you can update info about you personal user.
  • By clicking on any organization under the “Entities” section you will be able to change the POC’s of said entity (admin POC, billing POC and/or membership POC)
  • Finally, still in the selected organization, you will be able to change the technical or abuse POC of a specific resource associated to such organization by clicking on the ASN or IP block desired.

New POC’s must be previously created at www.lacnic.net/newid.
In order to change general information about the organization you must send an e-mail to hostmaster@lacnic.net

POC record example:


    nic-hdl:    SRA 
    person:     Sergio Rojas Astigarraga
    e-mail:     sergio@LACNIC.NET
    address:    Rambla Rep. de México, 6125,
    address:    1400 - Montevideo -
    country:    UY
    phone:      +598 2 6042222 []
    created:    20090904
    changed:    20161205

Org example:


    owner:          LACNIC DEBOGON TESTER
    ownerid:        UY-OPPL-LACNIC
    responsible:    Sergio Rojas
    address:        Rambla Republica de México, 1234,
    address:        11400 - Montevideo - MV
    country:        UY
    phone:          +598 2 6041111 []
    owner-c:        SRA
    created:        20100222
    changed:        20161205

    nic-hdl:        SRA
    person:         Sergio Rojas Astigarraga
    e-mail:         sergio@LACNIC.NET
    address:        Rambla Rep. de México, 6125,
    address:        1400 - Montevideo -
    country:        UY
    phone:          +598 2 6042222 []
    created:        20090904
    changed:        20161205

    aut-num:        64500
    inetnum:        2001:db8:1000::/36
    inetnum:        203.0.113.0/24

4.1.3. Maintaining Contact Information in Regional Internet Registries (RIRs): ARIN

For ARIN, the process is slightly different for creating contacts from the AFRINIC/APNIC/RIPE and LACNIC examples described above. For ARIN records, an operator must first create a Point of Contact (POC) record in the ARIN database. Once the POC record has been created, the operator can associate the POC record to their network resources (ASN, IP Addresses) as a NOC POC.

4.1.3.1. Point of Contact (POC) Object Example:

This is a typical example of what a POC record would look like for an ARIN POC record:


    Name:         Example ISP NOC
    Handle:       EXAMPLENOC-ARIN
    Company:      Example ISP 
    City:         123 X Street
    StateProv:    New York
    PostalCode:   NY
    Country:      10011
    RegDate:      2015-01-01
    Updated:      2015-01-01
    Phone:        +1-800-555-1212
    Email:        noc@example.net

4.1.3.2. OrgNOCHandle in Network Object Example:

The following would appear in whois query results for an operator’s ASN and Network resource(s) after the POC has been configured as a NOC contact:


    OrgNOCHandle:    EXAMPLENOC-ARIN
    OrgNOCName:      Example ISP NOC
    OrgNOCPhone:     +1-800-555-1212 
    OrgNOCEmail:     noc@example.net
    OrgNOCRef:       https://whois.arin.net/rest/poc/EXAMPLENOC-ARIN

4.1.4. Maintaining Contact Information in Internet Routing Registries

Since Internet Routing Registries are used to validate routing information, keeping contact information for those objects up-to-date is important as well.

To create/maintain a NOC contact and add it as a ‘tech-c’ attribute in AUT-NUM, AS-SET, and ROUTE-SET objects in a route registry, please refer to the AFRINIC/APNIC/LACNIC/RIPE example under Regional Internet Registries above.

The ROUTE/ROUTE6 objects do not allow for a ‘tech-c’ attribute. The recommended way to add/maintain contact information of a ROUTE object is to utilize the ‘remarks’ attribute to make the information easily accessible. For example:


    route6:           2001:db8:1000::/36 
    descr:            Provider 64500
    origin:           AS64500 
    remarks:          Abuse/UCE: abuse@example.net    
    remarks:          Network: noc@example.net   
    remarks:          Security issues:
                      security@example.net     
    remarks:          https://as64500.peeringdb.com/  
    mnt-by:           MAINT-AS64500   
    created:          2012-10-27T12:14:23Z   
    last-modified:    2016-02-27T12:33:15Z
    source:           RIPE

For debugging purposes it is useful to document an IP address that is pingable from the outside and a contact for questions about that address:


    route6:           2001:db8:1000::/36 
    descr:            Provider 64500
    origin:           AS64500 
    pingable:         2001:db8:1000::1   
    ping-hdl:         AS64500NOC-RIPE  
    mnt-by:           MAINT-AS64500     
    created:          2012-10-27T12:14:23Z 
    last-modified:    2016-02-27T12:33:15Z   
    source:           RIPE  

4.1.5. Maintaining Contact Information in PeeringDB

The PeeringDB (https://www.peeringdb.com) is an open resource for networks to share their peering information and other relevant information amongst each other. Networks are responsible for maintaining their records in the database. Having a PeeringDB record allows you to consolidate your network information in a single location, and as an operator, allows you to research other networks and obtain additional information such as links to an operator’s looking glass, what facilities they peer in, contact information, etc.

There are three main steps for setting up a new PeeringDB record:

  1. Setting up a user account
    1. Click “Register” from the header or visit https://www.peeringdb.com/register to begin the
      process.
  2. ASN Validation
    1. Associate your user account with an organization
    2. The association between user and organization will be validated by the PeeringDB team for new organizations.
    3. The PeeringDB admin team will attempt to validate your request to create
    4. A confirmation email will be sent when your organization has been approved.
  3. Setting up your initial PeeringDB record
    1. Login with the user account created.
    2. Click on the navigation icon ( ) located in the upper right hand corner and select your organization.
    3. Fill out and save your basic organization info.
    4. Navigate to the bottom of the screen to the “Manage” section and select “Add Network”
    5. Fill out the “Add Network” form and click “Submit Network”
    6. The network will be reviewed by the PeeringDB staff before it will be publically available
  4. Adding details to the PeeringDB record
    1. Login with the user account created.
    2. Click on the navigation icon ( ) located in the upper right hand corner and select your organization.
    3. Navigate to the bottom of the screen to the “Networks” section and select your network
    4. The standard PeeringDB view for a network will appear. Click the “Edit” button to update the data on the page.
    5. From the “Edit” view, you can do the following:
      1. Manage Contacts – Enter contact information for your important network contacts such as a NOC, Security Team, and Peering Policy contact
      2. Add Secondary Information – Information such as Looking Glass URL, number of routes, etc.
      3. ManagePrivatePeeringFacilities-Thesearelocationswhereanoperatorcanpeer with your network.
      4. Manage Exchange Points – These are Internet Exchanges where your network participates.

4.1.6. Company Website

Providing an additional source of contact and route policy information on a company website is beneficial for those operators who are not yet familiar with the PeeringDB or querying an RIR.

To help support open communication, below is a list of recommended items for network operators to consider publishing on their website:

Contact Info (RFC2142 mailboxes and phone numbers, if applicable)

  • Network Operations
  • Support
  • Abuse
  • Security
  • Other relevant contacts

Routing Policy

  • BGP Communities (Peer and Customer)
  • BGP Filtering Policy (Inbound and Outbound)
  • Route Dampening Policy
  • MED (Multi-Exit Discriminator) Support Policy