Hello everyone P.S .: I apologize, but I write for multiple email lists, precisely because it is a topic that interests multiple regions. P.S.2: The objective in this proposal is to make feasible the creation of validation mechanisms for the creation of IRR Route / Route6 Objects, without requiring any type of change in the protocols currently in use. Just adjusting the information already public and available. I am from Brazil, and Registro.BR (National Internet Registry) provides a file[1] of delegations in a format slightly different from the official NRO format [2]. In the link below [1] it is possible to see a list with an unequivocal association between the ASN and the IP block delegated to the owner. [1] ftp://ftp.registro.br/pub/numeracao/origin/nicbr-asn-blk-latest.txt Note: Registro.BR delegations are also published in the official NRO format, included in LACNIC's public archive [3] to which NIC.BR is linked. This unequivocal link allows us an extra layer of validation with respect to Hijack of prefixes, and also the creation of INVALID Route / Route6 objects in IRR. Inspired by this file format[1], I decided to take a closer look at the official NRO format. As expected, I was able to establish a link between the Owner of the ASN, and the Owner of the IPv4 / IPv6. However, this link is NOT unambiguous. The attribute that makes this link is Opaque-ID and is described on NRO oficial format file[2]. This attribute referred to an organization that holds some type of numerical resource on the Internet. In 90-95% of cases, the ASN <-> OpaqueID <-> InetNum link is assertive. However, there are cases in which this association is not sufficient to be assertive. A) Delegations of IPv4 and / or IPv6 blocks to end users without the delegation of an ASN to that institution. - These cases do not allow an assertive link between ASN and IPv4 / IPv6, so they ARE NOT THE FOCUS of my analysis. B) Organizations that own multiple sets of ASN <-> InetNum. B.1 - The cause that I believe to be the most common for this is mergers and acquisitions of organizations, where despite that OpaqueID referring to the same organization (CNPJ / EIN / RUC / Fiscal Number), the ASN sets <- > InetNum are from different Service Providers (sometimes even in geographically different regions). B.2 - But there are other examples of this, such as the need for specific segmentation of networks within the same organization. By consulting in the Whois databases some of these ASNs, it is possible to verify that the linking information between Autnum <-> Inetnum exists within the whois databases. fischer-mac-3: ~ fischerdouglas $ whois -h whois.lacnic.net AS28000 | grep num: aut-num: AS28000 inetnum: 179.0.156 / 22 inetnum: 200.7.84 / 23 inetnum: 2001: 13c7: 7001 :: / 48 The suggestion itself: --------------------- In the official format of the NRO [2], the "Extensions" column provides for the addition of data that was not yet foreseen. In this column, in the IPv4 and IPv6 resource lines, if that block is associated with any ASN, add the ASN to which that block is associated. The questions: ------------- - Any consideration about that? - What is the path to reach the right persons to make a official proposal? P.S.3: Yes, I know that we have entered the era of RPKI. Yes, I know that probably in 5-6 years we will have another 90% of DFZ as VALID. But I believe that such an action would require minimal effort, ample result, and would also serve as an incentive for the diversifying Owner of IP blocks to move and create their ROAs. Examples of organizations with multiple sets of AutNum<->InetNum: B.1.a "TELEFÔNICA BRASIL S.A" with 9 ASNs 10429, 11419, 16885, 16911, 18881, 19182, 22092, 26599, 27699. B.1.b "Telecom Argentina S.A." with 11 ASNs 7303, 7934, 10318, 10481, 10895, 10983, 11356, 12264, 21590, 26608, 27871. B.2.a "Núcleo de Inf. E Coord. Do Ponto BR - NIC.BR" with 16 ASNs 10906, 11284, 11431, 11644, 11752, 12136, 13874, 14026, 14650, 20121, 22548, 26162, 263044, 28345, 53035, 61580. B.2.b "LACNIC - Latin American and Caribbean IP address" with 7 ASNs. 28000, 28001, 28002, 28119, 52224, 264845, 264846 [2] https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt [3] ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest -- Douglas Fernando Fischer Engº de Controle e Automação