Standcore LLC

standards@standcore.com

Application email Applications such as e-mail track the reputation of the hosts that connect to them by IP address. Since the IPv6 address space is so large, a reputation system needs to aggregate the data for the IPs useded by a single entity. This document describes a file format a network operator can use to describe the sizes of the IP prefixes it allocates, for reputation systems to use to determine the aggregation boundaries. It also specifies an addition to the the Routing Policy Specification Language (RPSL) inetnum: class to refer to the location of the boundary file, and a method to sign boundary files.

Introduction Applications such as e-mail track the reputation of the hosts that connect to them by IP address. The IPv4 address space is small enough that it is practical to track individual addresses, but the IPv6 address space is far too large for that to be practical. Networks and hosting providers have widely varying allocation policies. Some may allocate a /48 to each customer, while others allocate individual /64's, and some hosting providers put multiple customers in a /64 making the allocation size for those customers in practice /128. This document provides a way for providers to publish a description of their allocation policies, to make it possible to tell reliably where the boundaries between allocations are.

Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Boundary file format The boundary file is a sequence of lines of UTF-8 text. Each line either starts with a '#' character indicating that it is a comment, or is a sequence of comma-separated (CSV) values as described in . Each CSV line has the form: ip_prefix,prefixsize,allocsize The ip_prefix and prefixsize define a range of IP addresses to which the allocation size applies. The ip_prefix is an IPv6 address . The prefixsize is a decimal integer in the range 32 to 64, inclusive. The allocsize is a decimal integer in the range 48 to 128, inclusive. It declares the prefix length of each suballocation within that range. Multiple lines can describe nested ranges, in which case the line with the longest prefix applies. Two lines MUST NOT have the same ip_prefix and prefixsize. For example: # allocations in the example network 2001:db8::,32,48 2001:db8:1234::,48,64 In this example, 2001:db8::/32 is allocated in /48 prefixes, except that 2001:db8:1234::/48 is allocated in /64 prefixes.

Authenticating the boundary files If desired, a network MAY sign a boundary file using the method described in . The signature is created and appended to the boundary file in exactly the same way that a signature is created and appended for a geoip file. Clients validate the signatures the same way the validate signatures for geoip files.

Locating the boundary files Routing Policy Specification Language (RPSL) is defined in several documents including and . This document proposes an update to the inet6num: class to identify the location of boundary files, and a workaround method until RPSL is updated. A new "boundary:" feed attribute would include the URL where the boundary file is located, e.g.: inet6num: 2001:0db8::/32 boundary: https://www.somenet.example/boundary.csv In the absence of that attribute, the boundary file is described in a remark: attribute including the word "boundary", a space, and the URL, e.g. inet6num: 2001:0db8::/32 remark: boundary https://www.somenet.example/boundary.csv When fetching boundary files, the most specific inet6num: object that has a boundary reference MUST be used. When processing files retrieved in this fashion, clients MUST ignore information for addresses outside the inet6num: range. If the range in the inet6num: range has been subdivided into smaller ranges, clients MUST use information from the smallest range that publishes a boundary file.

Security considerations The signature described in provides assurance that the contents of the boundary file describes the network's actual policy. In the absence of a signature, RDAP over https followed by https retrieval of the boundary file provide assurance that the data are accurate to the extent that the RPSL database correctly contains the network's information.

Acknowledgements This document was informed by discussions with Erik Nygren, Nick Buraglio, and George Michaelson.

Normative References Informative References