Publishing boundaries for IPv6 reputation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 17 April 2025.¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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.¶

2. Boundary file format

The boundary file is a sequence of lines of UTF-8 [RFC3629] 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 [RFC4180]. 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 [RFC5952]. 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.¶

3. Authenticating the boundary files

If desired, a network MAY sign a boundary file using the method described in Section 5 of [RFC9632]. 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.¶

4. Locating the boundary files

Routing Policy Specification Language (RPSL) is defined in several documents including [RFC2622] and [RFC4012]. 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.¶

5. Security considerations

The signature described in Section 3 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.¶

6. Acknowledgements

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

Author's Address