"Ensure the correctness of your own announcements and of announcements from your customers to adjacent networks with prefix and AS-path granularity"
"Enable source address validation for at least single-homed stub customer networks, your own end-users, and infrastructure"
"Maintain globally accessible up-to-date contact information"
Update your contact information in ARIN, RADb, etc. How long has it been since you checked your phone number? Is one of your contacts retired by now? Has your office moved? Would it be a good thing to put a listserv email address instead of a single person's email? Update your Admin-C, Tech-C, and Zone-C!
Also, remember to update your contact info in PeeringDB!
"Publish your data, so others can validate routing information on a global scale"
MANRS requires the following updated information in the following places.
Object | Source | Description |
---|---|---|
aut-num | IRR | Policy documentation |
route/route6 | IRR | NLRI/origin |
as-set | IRR | Customer cone |
ROA | RPKI | NLRI/origin |
https://www.manrs.org/isps/guide/global-validation/
Using an IRR to register your routes is a good thing. As major peers like Google and Hurricane Electric begin to use IRR information to inform their routing policies, this piece becomes more important. We encourage each of our members to work with their regional provider to ensure their information is correctly reflected in an IRR.
However, having your objects registered in an IRR does not mean you have provided irrefutable proof that you own these networks. Only signing your routes by creating ROAs, as part of the RPKI system, can provide irrefutable proof.