Summary

  • Ремко ван Мук и Марко Хогевонинг подготовили RIPE 2010-06. Местный интернет-регистратор мог записывать назначения IPv6 конечным пользователям отдельно либо объединять их в объекте inet6num со значениями AGGREGATED-BY-LIR и assignment-size. Назначение крупнее /48 требовало самостоятельной записи.
  • При аудите или запросе следующего блока регистратор обязан был показать фактическое число назначений, чтобы RIPE NCC мог проверить HD ratio. Предложение приняли 3 февраля 2011 года; к 15 февраля RIPE NCC сообщил о внедрении возможности в базу и сопутствующие процедуры.

Тысяча абонентов в одной карточке

Прежнее правило IPv6 требовало учитывать назначения конечным пользователям в базе, доступной региональным регистратурам. Оно оставляло открытым вопрос, что это за база и как подробно там записывать клиентов. Для оператора массового доступа такая инструкция похожа на требование заполнить форму, которой ещё никто не нарисовал. Окончательный текст 2010-06 перевёл туманную обязанность на язык полей базы данных.

В RIPE-513 есть учебный пример: тысяча назначений размера /56 помещается в пул /46. Для него создаётся публичный объект со строками status: AGGREGATED-BY-LIR и assignment-size: 56. Видны граница пула и размер отдельного назначения. Реальное количество выданных частей оператор считает в своих системах. Один объект описывает схему раздачи адресов, пока проверяемая статистика остаётся у того, кто адреса раздаёт.

Раздел 5.5 принятой политики разрешил также индивидуальную регистрацию. При выборе объединённого объекта LIR должен представить данные о числе назначений, если приходит аудит или заявка на дополнительные ресурсы. RIPE NCC использует эти данные для расчёта и проверки HD ratio, показателя эффективности использования выделенного IPv6-пространства. Если одной организации назначено больше /48, запись создаётся отдельно со статусом ASSIGNED. Упрощение публичной базы не отменяло обязанность вести точный внутренний счёт.

Даже крупная карточка открывает часть устройства сети. Поле assignment-size показывает, какие куски адресов оператор выдаёт клиентам. Авторы проекта прямо упоминали деловые и технические риски такой публикации. Поэтому решение заключалось в выборе зернистости: сколько показать каждому посетителю базы и сколько предоставить RIPE NCC в момент проверки. За красивым словом «прозрачность» здесь стояла вполне конкретная таблица.

Архив RIPE указывает принятие 3 февраля 2011 года. RIPE-513 опубликовали 7 февраля, а сообщение RIPE NCC от 15 февраля подтверждало работу новой функции базы и необходимых процедур. Названия полей выглядят буднично, но они определили, где заканчивается публичный реестр и начинается проверка собственных записей провайдера.

Первоисточники RIPE