TEXT   55

RIR Statistics Exchange Format

Guest on 3rd August 2022 01:55:21 AM

  1. RIR Statistics Exchange Format
  2.  
  3. This specification defines the file production cycle, naming and
  4. content for the RIR statistics files.
  5.  
  6. The RIR statistics files summarize the current state of allocations
  7. and assignments of Internet number resources. They are intended to
  8. provide a snapshot of the status of Internet number resources,
  9. without any transactional or historical details.
  10.  
  11. This format replaces the previous statistics exchange format, and
  12. differs from it in significant ways.
  13.  
  14. The details of this format are to be considered a published RIR
  15. standard, on which other parties are expected to rely. RIRs must
  16. comply with this standard in every respect.
  17.  
  18.  
  19. 1. Production Process
  20.  
  21.     Each RIR periodically produces a text file of records as
  22.     described below, representing all of the allocations and
  23.     assignments which have been made by that RIR to that date.
  24.  
  25.     This file is to be produced daily. The last time of any record
  26.     for the file is 23:59:59 in the local time zone of the producing
  27.     RIR.  (i.e. the last possible time on the specified calendar
  28.     day in that time zone)
  29.  
  30.     An MD5 checksum is to be computed on the file, and published
  31.     under a matching name, with file extension .md5 appended.
  32.  
  33.     A PGP or other cryptographically strong signature can also be
  34.     computed, and published under a matching name with suitable
  35.     extension.
  36.  
  37.  
  38. 2. File naming and exchange
  39.  
  40.     2.1 File name:
  41.  
  42.     Each file is called delegated-<registry>-yyyymmdd
  43.  
  44.     The <registry> value follows the internal record format and is
  45.     one of the specified strings from the set:
  46.  
  47.      {afrinic,apnic,arin,iana,lacnic,ripencc};
  48.  
  49.     This set may be altered to add, remove or modify registries.
  50.  
  51.     The yyyymmdd is the date, local not UCT, on which the file was
  52.     produced.
  53.  
  54.     The file is marked delegated-<registry> to discriminate it from
  55.     any other <registry> files produced in another context. These
  56.     would be expected to be named in a different file-tree, but if
  57.     accidentally placed in the same directory would cause no data loss.
  58.  
  59.     Data compression is optional. If compressed, the normal file
  60.     suffix is used to denote the compression algorithm. (.gz, .bz2, .zip etc)
  61.  
  62.     The most recent file (named as follows) must be available in
  63.     a non-compressed form.
  64.  
  65.     The most recent file will also be available under a name of
  66.     the form delegated-<registry>-latest. This can be a symbolic
  67.     or hard link to the delegated-<registry>-yyyymmdd file but must
  68.     be pointed at the most recent file when it is updated.
  69.  
  70.     This is to permit automatic fetching of the current data via
  71.     a persistent URL, in systems jobs, or in browser bookmarks or
  72.     other stored form.
  73.  
  74.     2.2 File exchange:
  75.  
  76.     Each RIR will make its files available in a standard ftp
  77.     directory, defined as /stats/<registry>/*. Data will be lodged
  78.     within 3 business days (locally for each RIR) of the date of
  79.     the file, in the source RIR location.
  80.  
  81.     The RIR may mirror each others data.  If an RIR does mirror
  82.     files from others RIRs, the standard path directory remains
  83.     the same, i.e., /stats/<registry>/* where <registry> is the
  84.     RIR being mirrored.
  85.  
  86.     2.3 File availability:
  87.  
  88.     Data will be available by FTP, and additionally by any other
  89.     access method the RIR chooses. This may include alternative
  90.     URLs, but these will reflect the common naming model. Data will
  91.     be publicly visible and will not require access control (world-
  92.     readable).
  93.  
  94.     Examples:
  95.  
  96.         http://www.afrinic.net/stats/<registry>/delegated-<registry>-latest
  97.         rsync www.afrinic.net::/stats/<registry>/delegated-<registry>-latest
  98.         ftp://ftp.afrinic.net/pub/stats/<registry>/delegated-<registry>-latest
  99.  
  100.     (The use of a standard prefix in a URL such as /pub/ in FTP
  101.     servers is not considered obligatory, and does not define the
  102.     URL for use in HTTP or other access methods. The defined URL
  103.     base is /stats/<registry>/ across all application-specific
  104.     access methods.)
  105.  
  106.  
  107. 3. File format
  108.  
  109.     The file consists of comments, file header lines, and records,
  110.     one record per line. Header and record lines are structured as
  111.     'comma separated fields' (CSV), with leading and trailing blank text
  112.     in fields not meaningful.
  113.  
  114.     The vertical line character '|' (ASCII code 0x7c) is used as the
  115.     CSV field separator.
  116.  
  117.     After the header lines, records are not sorted.
  118.  
  119.     3.1 Comments:
  120.  
  121.     Comments are denoted by # at the beginning of a line. No
  122.     line-embedded comments are permitted. Comments may occur at
  123.     any place in the file.
  124.  
  125.     Example:
  126.  
  127.          #optional comments.
  128.          #   any number of lines.
  129.  
  130.          #another optional comment.
  131.  
  132.     Blank lines are permitted, and may occur at any place in the file.
  133.  
  134.     3.2 File header:
  135.  
  136.     The file header consists of the version line and the summary
  137.     lines for each type of record. There must be only one version
  138.     line, which must be the first line of the header. There must
  139.     be at exactly one summary line for each type of record which
  140.     appears in the file.
  141.  
  142.     3.2.1 The Version line:
  143.  
  144.     Format:
  145.  
  146.  
  147.          version|registry|serial|records|startdate|enddate|UTCoffset
  148.  
  149.     version    = format version number of this file, currently 2;
  150.     registry   = as for records and filename (see below);
  151.     serial     = serial number of this file (within the creating RIR series);
  152.     records    = number of records in file, excluding blank lines,
  153.                      summary lines, the version line and comments;
  154.     startdate  = start date of time period, in yyyymmdd format;
  155.     enddate    = end date of period, in yyyymmdd format;
  156.     UTCoffset  = offset from UTC of local RIR producing file,
  157.                      in +/- HHMM format.
  158.  
  159.     3.2.2 The Summary line:
  160.  
  161.     The summary lines count the number of record lines of each type in the file.
  162.  
  163.     Format:
  164.  
  165.          registry|*|type|*|count|summary
  166.  
  167.     registry   = as for records (see below);
  168.     *          = an ASCII '*' (unused field, retained for spreadsheet purposes);
  169.     type       = as for records (defined below);
  170.     count      = the number of record lines of this type in the file;
  171.     summary    = the ASCII string 'summary' (to distinguish the record line).
  172.  
  173.  
  174.     Note that the count does not equate to the total amount of
  175.     resources for each class of record. This is to be computed from
  176.     the records themselves.
  177.  
  178.     3.3 Record format:
  179.  
  180.     After the defined file header, and excluding any space or
  181.     comments, each line in the file represents a single allocation
  182.     (or assignment) of a specific range of Internet number resources
  183.     (IPv4, IPv6 or ASN), made by the RIR identified in the record.
  184.  
  185.     In the case of IPv4 the records may represent non-CIDR ranges
  186.     or CIDR blocks, and therefore the record format represents a
  187.     beginning of range, and a count. This can be converted to
  188.     prefix/length using simple algorithms.
  189.  
  190.     In the case of IPv6 the record format represents the prefix
  191.     and the count of /128 instances under that prefix.
  192.  
  193.     Format:
  194.  
  195.          registry|cc|type|start|value|date|status[|extensions...]
  196.  
  197.     registry  = One value from the set of defined strings:
  198.  
  199.                         {afrinic,apnic,arin,iana,lacnic,ripencc};
  200.  
  201.     cc        = ISO 2-letter country code of the organization to which the
  202.                 allocation or assignment was made, and the enumerated
  203.                 variances of
  204.  
  205.                         {AP,EU,UK}
  206.  
  207.                 These values are not defined in ISO 3166 but are widely used.
  208.  
  209.     type      = Type of Internet number resource represented in this record,
  210.                 One value from the set of defined strings:
  211.  
  212.                         {asn,ipv4,ipv6}
  213.  
  214.     start     = In the case of records of type 'ipv4' or 'ipv6'
  215.                 this is the IPv4 or IPv6 'first address' of the range.
  216.  
  217.                 In the case of an 16 bit AS number  the format is
  218.                 the integer value in the range 0 to 65535, in the
  219.                 case of a 32 bit ASN the value is in the range 0
  220.                 to 4294967296. No distinction is drawn between 16
  221.                 and 32 bit ASN values in the range 0 to 65535.
  222.  
  223.     value     = In the case of IPv4 address the count of hosts for
  224.                 this range. This count does not have to represent a
  225.                 CIDR range.
  226.  
  227.                 In the case of an IPv6 address the value will be
  228.                 the CIDR prefix length from the 'first address'
  229.                 value of <start>.
  230.                 In the case of records of type 'asn' the number is
  231.                 the count of AS from this start value.
  232.  
  233.     date      = Date on this allocation/assignment was made by the
  234.                 RIR in the format YYYYMMDD;
  235.  
  236.                 Where the allocation or assignment has been
  237.                 transferred from another registry, this date
  238.                 represents the date of first assignment or allocation
  239.                 as received in from the original RIR.
  240.  
  241.                 It is noted that where records do not show a date of
  242.                 first assignment, this can take the 00000000 value.
  243.  
  244.     status    = Type of allocation from the set:
  245.  
  246.                         {allocated, assigned}
  247.  
  248.                 This is the allocation or assignment made by the
  249.                 registry producing the file and not any sub-assignment
  250.                 by other agencies.
  251.  
  252.    extensions = Any extra data on a line is undefined, but should conform
  253.                 to use of the field separator used above.
  254.  
  255.  
  256. 4. Validation/assumptions
  257.  
  258.     Validation is assisted by the file headers, using the "records"
  259.     field.  Also by checking the file name against its contents,
  260.     and by use of the detached MD5 and/or other checksum files.
  261.  
  262.     Within any one file. there should be no overlap of assigned
  263.     records by their base address and count or prefix length. During
  264.     the transfer of management of a resource from one RIR to another,
  265.     it is possible that there will be overlapping records when
  266.     comparing each file.
  267.  
  268.     It is assumed that any one file only contains records with
  269.     registry field set to the value of the file-producing RIR.
  270.  
  271.     Early Registration Transfers (ERX) do not have any special
  272.     tagging in this format. As resource management responsibility
  273.     moves between the RIR then resource records will move between
  274.     stats files. ERX records are expected to move from the old to
  275.     the new registry at the end of any defined transfer window.
  276.     This minimizes the risk of data overlap and avoids unnecessary
  277.     changes to data.
  278.  
  279.  
  280. 5.  Non-Registry allocated and assigned data
  281.  
  282.     Historical assignments which are not under regional Internet
  283.     registry management will not be included in the RIR produced files.
  284.  
  285.     An instance of the known state of these 'IANA' assignments will be
  286.     incorporated in the mirroring system if maintained by IANA.
  287.  
  288.  
  289. 6.  Extensions to the format
  290.  
  291.     Extensions to this format may be made by mutual agreement among
  292.     the participating registries.
  293.  
  294.  
  295. 7.  MD5 Hash File format
  296.  
  297.     As previously indicated, an MD5 checksum is to be computed on the file
  298.     and published under a matching name with the file extension .md5 appended.
  299.     The format of the hash file will be a single line formatted as follows:
  300.  
  301.         MD5 (<filename>) = <hash>
  302.  
  303.     where <filename> is the name of the file to which the hash applies
  304.     and <hash> is the calculated MD5 checksum.
  305.  
  306.     E.g.,  
  307.  
  308.         MD5 (delegated-afrinic-20031119) = 64175f7e728732743b3acc28c00c2179
  309.  
  310. 8.  Cryptographic signing
  311.  
  312.     As previously stipulated, a PGP or other cryptographically strong
  313.     signature may also be computed and published under a matching
  314.     name with suitable extension.
  315.  
  316.     8.1 Recommended method
  317.  
  318.     The recommended method at this time is to sign the file using GPG
  319.     and to publish the signature under a matching file name with the file
  320.     extension .asc appended.  An example of a file signed in this manner
  321.     follows:
  322.  
  323.         -----BEGIN PGP SIGNATURE-----
  324.         Version: GnuPG v1.0.6 (GNU/Linux)
  325.         Comment: For info see http://www.gnupg.org
  326.  
  327.         iEYEABECAAYFAj+6U64ACgkQyzQvAdFSThS5ZQCfcbE3+7UnaBe2SNysWrq+xpVB
  328.         rZEAmwRdPkylmvhCNnt5th5jxHBmIngF
  329.         =kxyA
  330.         -----END PGP SIGNATURE-----
  331.  
  332.     8.2 Publishing of public key
  333.  
  334.     If the RIR chooses to cryptographically sign the statistics file,
  335.     it is recommended that the public key needed to verify the signature
  336.     be published or a link to the public key be created in the same
  337.     directory location of the latest statistics and accompanying files.
  338.  
  339.     The name of the public key file (or link thereto) should follow the
  340.     form delegated-<rir>-key where <rir> conforms to the values identified
  341.     in section 2.1. This will prevent confusion in the event that an RIR
  342.     uses distinct keys for signing different sets of published files.
  343.  
  344.  
  345. 9.  Data retention
  346.  
  347.     There is no obligation on any registry to retain previous files, once
  348.     a new file is produced and lodged for public access.

Raw Paste


Login or Register to edit or fork this paste. It's free.