Полезная Информация в помощь по заполнению заявки на выделение адресов

При заполнении заявки ripe-488 на получении IP адресов предварительно мы рекомендуем Вам ознакомиться с Регламентом выделения и назначения адресов IPv4 в RIPE NCC.

Регламент выделения и назначения адресов IPv4 в сервисном регионе RIPE NCC (перевод).

Оригинал документа можно посмотреть здесь.

Преамбула
Этот документ описывает текущий регламент выделения адресов IPv4, разработанный в ходе восходящего открытого процесса разработки регламента, происходившего в Рабочей Группе Регламента Адресации (AP WG) RIPE. Центр Управления Сетью Европейской Интернет-Регистратуры (RIPE NCC) поддерживал и направлял этот процесс. Настоящий регламент применяется RIPE NCC и Локальными Интернет-Регистратурами (LIR) в сервисном регионе RIPE NCC.
Информация о Рабочей Группе Регламента Адресации доступна по ссылке:
http://www.ripe.net/ripe/wg/address-policy/index.html


Содержание
1.0 Введение
1.1 Область действия
2.0 Пространство адресов IPv4
3.0 Задачи системы Интернет-Регистратур
3.1 Конфиденциальность
3.2 Язык общения
4.0 Регистрационные требования
5.0 Регламент и руководство по выделению адресов
5.1 Первое выделение
5.2 Принцип медленного старта
5.3 Последующие выделения
5.4 Суб-выделения
6.0 Регламент и руководство по назначению адресов
6.1 Документирование назначений
6.2 Инфраструктура сети и сети конечных пользователей
6.3 Скорости использования
6.4 Резервирования не поддерживаются
6.5 Простота администрирования
6.6 Действительность назначения
6.7 Эффективность
6.8 Перенумерация
7.0 Окно назначения
8.0 Назначения для межсетевых экспериментов
9.0 Адресное пространство: независимое и агрегируемое
10.0 Ведение записей
11.0 Аудит LIR
12.0 Закрытие LIR по решению RIPE NCC


1.0 Введение
Центр управления сетью RIPE, основанный как независимая ассоциация, предоставляет услуги одной из трёх Региональных Интернет-Регистратур (RIR). Его сервисный регион включает в себя Европу, Ближний Восток, Центральную Азию и страны Африки, расположенные к северу от экватора. В качестве RIR RIPE NCC отвественен за назначения и выделения пространства адресов IP, номеров Автономных Систем (AS), а также управление обратными зонами доменных имён. Распределение адресного пространства IP следует иерархической съеме, описанной в документе <Система Интернет-Регистратур>, который доступен в Хранилище Документов RIPE по ссылке:
http://www.ripe.net/ripencc/about/regional/rir-system.html

1.1 Область действия.
Этот документ описывает регламент ответственного управления глобально уникальных адресов из пространства адресов Интернет IPv4 в сервисном регионе RIPE NCC. Регламент, установленный далее в этом документе, применяется ко всему пространству адресов IPv4, выделенному и назначенному RIPE NCC. Настоящий регламент является обязательным к исполнению всеми LIR, имеющими членство в RIPE NCC.
Этот документ не регламентирует номера автономных систем (AS), пространство адресов IPv6, адреса группового вещания или частное пространство адресов. Он также не описывает регламент распределения адресов, используемый другими RIR. Регламенты сообщества RIPE в отношении назначения номеров AS и IPv6 опубликованы в Хранилище Документов RIPE по ссылке:
http://www.ripe.net/ripe/docs/internet-registries.html#policy

2.0 Пространство адресов IPv4
Для целей настоящего документа под адресами IP понимаются 32-битные двочиные числа, используемые в качестве адресов протокола IPv4. Существует три основных типа адресов IPv4:
1. Публичные адреса
Публичные адреса IP назначаются так, чтобы быть глобально уникальными, в соответствии с задачами, описанными в разделе 3 настоящего документа.
2. Частные адреса
Некоторые диапазоны адресов были оставлены особо для работы частных сетей на базе IP. Кто угодно может использовать эти адреса в своих частных сетях безо всякой регистрации или координации. Узлы, использующие эти адреса, не могут быть доступны напрямую из Интернета. Связь с ними возможна с использованием техники известной как Трансляция Сетевых Адресов (NAT). Частные адреса ограничивают сеть, так что её узлы имеют только частичную связность с Интернетом. Там, где нужна полная связность с Интернетом, должны применяться уникальные публичные адреса.

За подробным описанием пространства частных адресов и оставленных для этой цели диапазонов обратитесь, пожалуйста, к RFC 1918 (Address Allocation for Private Internets) по ссылке (английский):
ftp://ftp.ripe.net/rfc/rfc1918.txt
За информацией по поводу <Архитектурных Особенностей NAT> (на английском языке) обратитесь к RFC 2993, доступному по ссылке:
ftp://ftp.ripe.net/rfc/rfc2993.txt

3. Специальные и зарезервированные адреса
Некоторые диапазоны адресов зарезервированы для целей специального использования. Они описаны в RFC 3330 и выходят за рамки настоящего документа. RFC 3330 доступен по ссылке:
ftp://ftp.ripe.net/rfc/rfc3330.txt

3.0 Задачи системы Интернет-Регистратур

Назначения публичных адресов IPv4 должны производиться с учётом следующих задач:
Уникальность
Каждый публичный адрес IPv4 в мире должен быть уникален. Это требование абсолютно, поскольку оно гарантирует, что каждый узел Интернета может быть однозначно идентифицирован.

Агрегация
Публичные адреса Интернет должны распределяться в иерархической манере, позволяя агрегацию маршрутной информации. Это необходимо для обеспечения нормальной работы маршрутизации в Интернете.

Сохранение
Пространство публичных адресов IPv4 должно распределяться непредвзято, в соответствии с операционными нуждами рабочих сетей конечных пользователей. Чтобы максимально увеличить срок жизни ресурса публичного пространства адресов IPv4, адреса должны распределяться в соответствии с нуждами, и накопление резервов должно быть предотвращено.

Регистрация
Должно существовать обеспечение публичной регистрации, документирующей выделение и назначение адресного пространства. Это необходимо с целью обеспечения уникальности, а также для предоставления информации для устранения неисправностей в Интернете на всех уровнях.

3.1 Конфиденциальность
Интернет-Регистратуры (IRы) имеют обязательство о конфиденциальности перед своими регистрантами. Информация, передаваемая IR, должна храниться безопасно и не должна распространяться внутри самой IR шире, чем это необходимо. По необходимости эта информация может быть передана вышестоящей IR с соблюдением тех же условий конфиденциальности.

3.2 Язык общения
Обратите внимание на то, что всё взаимодействие с RIPE NCC должны осуществляться на английском языке.

4.0 Регистрационные требования
Все назначения и выделения адресов должны быть зарегистрированы в базе данных RIPE. Это необходимо, чтобы гарантировать уникальность, а также для поддержки операционных нужд сети.
Действительными считаются только выделения и назначения адресов, зарегистрированные в базе данных RIPE, регистрация объектов в базе данных является финальным этапом производства выделения или назначения адресов. Регистрационные данные (диапазон, контактная информация, статус и т.д.) должны быть корректны в любое время (то есть, они должны поддерживаться).

5.0 Регламент и руководство по выделению адресов
Выделенным называется блок адресов IPv4, из которого производятся назначения.
Все LIRы, получая пространство адресов от RIPE NCC, обязаны придерживаться регламента, который соответствует сформулированному сообществом RIPE и описанному в настоящем документе.
Если LIR собирается обменять или передать пространство адресов, она обязана связаться с RIPE NCC, с тем чтобы изменения могли быть соответствующим образом протоколированы. Помните, что LIR всегда остаётся ответственной за все выделенные` адреса, которые она получает от RIPE NCC, до тех пор пока выделение не будет передано другой LIR или возвращено. LIR должна обеспечивать применение действующего регламента.

5.1 Первое выделение
Минимальный размер выделения в RIPE NCC составляет /20.
Чтобы получить изначальное выделение, LIR должна продемонстрировать существующее эффективное использование как минимум /22 или потребность в немедленном эффективном использовании как минимум /22 пространства адресов. Когда обоснование основывается на комбинации из немедленных нужд и существующего использования, все существующие назначения должны будут быть перенумерованы в новое выделение, сделанное для LIR. В обоих случаях принимаются во внимание нужды в пространстве адресов для собственной инфрастуктуры LIR и конечных пользователей, которые подключаются к LIR.
Проверка предыдущего эффективного использования основана на суб-выделениях и назначениях, зарегистрированных в базе данных RIPE. Только назначения, зарегистрированные в базе данных RIPE, признаются действительными.
Подробности о том, как получить членство в RIPE NCC, могут быть найдены в документе RIPE <Процедура получения членства в RIPE NCC> (на английском языке) по ссылке:
http://www.ripe.net/ripe/docs/new-lir.html

5.2 Принцип медленного старта
Принцип медленного старта занял своё место с целью обеспечения последовательного и непредвзятого применения регламента для всех LIR в отношении выделения адресов.
Пространство адресов выделяется LIRам со скоростью, с которой адреса суб-выделяются и назначаются LIRами. Выделение, превышающее минимальный размер, может быть сделано, если потребность в нём продемонстрирована. Размер последующих выделений основывается на скорости использования предыдущих выделений.

5.3 Дополнительные выделения
LIR может получить дополнительное выделение адресов, когда порядка 80 процентов (80%) всего пространства адресов, выделенного ей в данный момент, уже использовано в действительных назначениях или суб-выделениях. Новое выделение может быть сделано, если одно назначение или выделение требует большего количества адресов, нежели возможно удовлетворить из пространства адресов, которое содержит LIR в настоящий момент.
Резервирования не считаюся действительными назначениями или суб-выделениями. В целях внутренней агрегации может быть полезно сохранить некоторое пространство адресов свободным для будущего роста в дополнение к действующему назначению. Однако LIR должна принимать во внимание то, что такие внутренние резервирования не считаются действительным использованием. Пространство должно быть суб-выделено или назначено, до того как LIR сможет запросить ещё одно выделение.
Чтобы получить новое выделение, LIR должна направить запрос в RIPE NCC, используя <Форму запроса дополнительного выделения адресов IPv4>, доступную в Хранилище Документов RIPE (на английском языке) по ссылке:
http://www.ripe.net/ripe/docs/add-allocation.html
Дополнительное пространство адресов будет выделено только после того, как приложенная к запросу информация будет проверено, и новое выделение сочтено необходимым.
RIPE NCC сделает всё возможное, чтобы выделить непрерывное пространство адресов, в целях поддержания агрегации. Однако это не может быть гарантировано, поскольку зависит от факторов, на которые RIPE NCC не имеет влияния (например, количество новых LIR и время, потребное на использование выделения).

5.4 Суб-выделения
Суб-выделения предназначены для содействия задаче агрегации маршрутов и могут быть сделаны только из выделений со статусом . LIRы, поддерживающие выделения или , могут иметь возможность первратить их в выделения PA, если в них нету сетей в статусе . Смысл различных значений аттрибута : описаны в разделе 9.0.
LIRы, желающие преобразовать сделанные им выделения в статус PA, должны связаться с RIPE NCC посредством электронной почты по адресу .
Минимальный размер суб-выделения составляет /24. Это наименьшая длина префикса, для которого может быть делегирована обратная зона; кроме того, он позволяет сделать разумное число малых назначений нижестоящему сетевому оператору.
LIR может суб-выделить пространство адресов IPv4 вплоть до 400% от своего Окна назначения (AW) отдельно взятой организации каждые 12 месяцев. LIRы с AW, меньшим /26, не могут создавать суб-выделения, поскольку минимальный размер суб-выделения составляет /24. Регламент AW описан в разделе 7.0.
LIRы могут делать суб-выделения многим нижестоящим сетевым операторам.
Нижестоящие сетевые операторы, эффективно использующие суб-выделение /22, готовы к получению выделения PA /20 от RIPE NCC, если они принимают решение стать самостоятельными LIR.
Максимальный размер суб-выделения составляет /20, даже если это менее 400% от AW LIRы. Например, LIR с AW /21 не может суб-выделить /19 нижестоящей сети. Однако, нижестоящие сетевые операторы могут получить суб-выделения общим числом более /20 от более чем одной LIR.
LIR контрактно ответственна за обеспечение использования выделенного ей пространства адресов в соответствии с регламентом, установленным сообществом RIPE. LIRам рекомендуется иметь контракты, которые требуют от нижестоящих сетевых операторов следовать регламенту, принятому сообществом RIPE, при использовании полученных суб-выделений.
RIPE NCC считает, что суб-выделенное пространство адресов <использовано>, когда рассматривает запросы от LIR на дополнительне выделение IPv4. От LIR тем не менее требуется продемонстрировать порядка 80% использования всех сделанных ей выделений. Когда LIR делает много суб-выделений с малым количеством назначений внутри них, RIPE NCC запрашивает у LIR обоснование причин суб-выделений.
LIR следует заметить, что рассмотрение заявки на выделение адресов отличается от рассмотрения заявки на назначение. Для назначений рассмотритель может видеть планы сети для одной организации. Для выделений рассмотрителю часто представляют планы продаж и маркетинга. Потребности в адресах отдельных организаций не могут быть проверены.
LIRам рекомендуется применять принцип медленного старта при создании суб-выделений для нижестоящих сетевых операторов. В нём есть два основных преимущества: LIR может убедиться в том, что суб-выделенное пространство адресов используется эффективно, а также может определить способность нижестоящей организации оперировать в соответствии с регламентом, установленным сообществом RIPE.
Суб-выделения составляют часть агрегируемого пространства адресов LIR. Вследствие этого, LIR может захотеть убедиться в том, что пространство адресов не удерживается нижестоящей сетью, если её оператор отказывается от дальнейшего подключения к сети LIR. LIRы, не желающие терять пространство адресов подобным образом, ответственны за обеспечение того, что статус суб-выделения в любых контрактах между LIR и нижестоящим сетевым оператором чётко оговорен.

6.0 Регламент и руководство по назначению адресов
Сохранение и агрегация зачастую являются взаимоисключающими задачами. Когда задачи системы Интернет-Регистратур входят в противоречие с интересами отдельно взятых конечных пользователей или поставщиков услуг, требуется аккуратный анализ и суждение, с тем чтобы найти сооветствующий компромисс. Правила и руководства в настоящем документе предназначены для помощи LIRам и конечным пользователям в их поиске справедливых компромиссов.
Заметьте, что LIRы должны запросить утверждение в RIPE NCC для назначений, которые превышают размер AW LIR (Раздел 7.0). RIPE NCC всегда приветствует обращение LIR к RIPE NCC за ещё одним мнением по заявкам, даже если они подпадают под AW LIRы.

6.1 Документирование назначений
Чтобы определить потребности сети в пространстве адресов, должна быть собрана относящаяся к делу информация. Для вынесения суждения по каждому назначению адресов организациям как конечным пользователям необходимы подробности, включая требования по адресации, инфраструктуру сети и будущие планы. Текущее использование адресов организацией также должно быть определено, чтобы убедиться в том, что существующее назначние не повторяется.
Эта информация существенна для принятия соответствующих решений по назначению. Соблюдение баланса между общими задачами системы Интернет-Регистратур (раздел 3.0) и потребностями рассматриваемой сети необходимо для каждой сети. LIR должна удостовериться в том, что необходимая информация предоставлена, до назначения адресов.
RIPE NCC предоставляет формы для сбора необходимой информации. Информация, запрашиваемая в формах, должна быть собрана LIR. LIRы могут использовать эти формы для запросов своих клиентов либо разработать свои собственные формы. Локальные формы могут быть использованы, если они собирают все требуемые данные. Это очень важно, когда LIR производит назначения, используя своё AW.
Если запрос должен быть утверждён в RIPE NCC или если информация требуется в случае аудита, информация должна быть предоставлена в версии формы запроса, использованной на момент назначения адресов. Текущие версии всех форм запроса могут быть найдены (на английском языке) по ссылке:
http://www.ripe.net/ripe/docs/internet-registries.html#request

6.2 Инфраструктура сети и сети конечных пользователей
Адреса IP, используемые исключительно для соединений между конечным пользователем и поставщиком услуг (то есть для соединений точка-точка) считаются частью инфраструктуры поставщика услуг. Эти адреса не должны регистрироваться с контактными координатами конечного пользователя, но могут быть зарегистрированы как часть внутренней инфраструктуры поставщика услуг. Когда конечный пользователь имеет сеть, использующую публичное пространство адресов, оно должно быть зарегистрировано отдельно с контактными координатами конечного пользователя. Когда конечный пользователь является частным лицом, а не организацией, взамен может быть употреблена контактная информация поставщика услуг.
Инструкции о том, как зарегистрировать объекты в базе данных, могут быть найдены в документе <Руководство пользователя по Базе Данных RIPE: Начало работы>, доступном (на английском языке) по ссылке:
http://www.ripe.net/ripe/docs/db-start.html

6.3 Скорости использования
Немедленно использование назначенных адресов должно составлять по меньшей мере 25% от назначенного пространства. По истечении одного года оно должно быть не менее 50% пространства, если только не заданы особые обстоятельства. Назначения могут базироваться только на реалистических ожиданиях, записанных в документации.

6.4 Резервирования не поддерживаются
Конечным пользователям не позволяется резервировать пространство адресов, основываясь на долгосрочных планах. Это нарушает задачу сохранения адресов и фрагментирует пространство адресов, в случае если изначальные прогнозы не оправдываются. Рассмотрение запросов на пространство адресов IP должно базироваться на продемонстрированных нуждах. Неиспользуемое либо неэффективно используемое пространство адресов, назначенное в прошлом, должно быть использовано для удовлетворения нужд текущего запроса либо возвращено. Как скоро организация использовала всё назначенное ей пространство адресов, она может запросить дополнительное пространство адресов, основываясь на скорректированных ожиданиях по приросту своей сети.

6.5 Простота администрирования
Текущая скорость потребления остающегося неназначенным пространства адресов IPv4 не позволяет назначение адресов для простоты администрирования. Примерами этого, в частности, могут служить простота обсчёта или управления сетью.

6.6 Действительность назначения
Все назначения остаются действительными, до тех пор исходные критерии, на которых основывалось это назначение, всё ещё действительны, и назначение соответствующим образом зарегистрировано в базе данных RIPE. Если назначение было сделано со специфической целью, и эта цель более не существует, назначение более не является действительным. Если назначение основано на информации, которая оказывается недействительной, назначение более не является действительным.
По этим причинам важно, чтобы LIRы удостоверялись в том, чтобы назначения были соответствующим образом зарегистрированы в базе данных RIPE. Объект inetnum или объекты для утверждённых назначений должны использовать названия сетей (netname), утверждённые RIPE NCC и не должны быть более утверждённого размера. Кроме того, дата в первом аттрибуте : должна быть не ранее даты утвердительного сообщения от RIPE NCC.
RIPE NCC проверяет назначения, сделанные LIRами, когда рассматривает запросы на дополнительные выделения (см. раздел 5.3). Он также производит проверки соответствия как часть деятельности по аудиту, требуемой сообществом, как описано в документе RIPE <Деятельность RIPE по обеспечению соответствия данных и аудита>, доступном (на английском языке) по ссылке:
http://www.ripe.net/ripe/docs/audit.html

6.7 Эффективность
Когда большие объёмы пространства адресов назначаются с целью, которая часто могла бы быть достигнута с меньшими объёмами (например, временные соединения или хостинг виртуальных серверов), RIPE NCC может проверить текущее использование до утверждения дополнительных назначений.

6.8 Перенумерация
В общем случае адреса могут быть заменены по принципу один к одному. Действительные назначения могут быть заменены тем же количеством адресов, если исходные критерии назначения всё ещё действительны. Заменяемые адреса должны всё ещё использоваться. Если более половины исходных адресов не используется, от конечного пользователя потребуется прислать новую заявку. Если запрос на перенумерацию превышает AW новой LIR (см. раздел 7.0), запрос должен быть отослан в RIPE NCC на утверждение.
Сообщество RIPE в общем случае принимает период длиной три месяца как достаточное время для переноса сети на новое пространство адресов. Когда конечный пользователь хочет сохранить оба назначения на большее время, от RIPE NCC должно быть получено согласие на предложенный интервал времени.
Когда перенумерация сети заканчивается, старое назначение должно быть удалено из базы данных RIPE.

7.0 Окно назначения
Окно назначения (AW) представляет собой максимальное количество адресов, которые LIR может назначить либо для своей собственной сети, либо для сети конечного пользователя без предварительного утверждения в RIPE NCC. Размер AW выражен в нотации CIDR.
Процедура выделения Окна назначения появилась, чтобы создать различные уровни поддежки, основываясь на уровне опыта LIRы. RIPE NCC может перепроверить назначения, сделанные LIRой в пределах AW, чтобы удостовериться в том, что LIR назначает адреса в соответствии с регламентом. Это важно для обеспечения беспристрастного распределения адресного пространства и выполнения задач агрегации, консервации и регистрации. Документация о назначениях, сделанных в пределах AW, должна содержать информацию, эквивалентную заполненной форме запроса, доступной по ссылке:
http://noc.rt.ru/registry/ip-reg/ip/iprequestform.shtml
Все новые LIRы начинают работу с Окном назначения равным нулю (0). Это означает, что каждое назначение требует предварительного утверждения в RIPE NCC.
AW применяется по-разному в зависимости от того, назначение ли это для конечного пользователя или для инфраструктуры собственно LIR.
Не существует ограничения на то, как часто LIR использует своё AW для своей собственной инфраструктуры. Эти назначения просто не могут превышать AW LIR. Это означает, что LIR с AW /25 может сделать множественные отдельные назначения /25 для инфраструктуры своей сети, не посылая запрос на каждое из них в RIPE NCC. Однако если одно назначение будет превышать /25, LIRе понадобиться подтверждение запроса на это назначение в RIPE NCC.
LIRы должны обозначать, какие назначения для своей собственной инфраструктуры использовали AW. Такие назначения должны иметь аттрибут "remarks:" со значением в объекте inetnum, зарегистрированном в базе данных RIPE. Важно, чтобы отдельный аттрибут : использовался исключительно для этой цели.
AW может применяться к сети конечного пользователя единожды в 12-месячный период. Это означает, что LIR может сделать более одного назначения конечному пользователю в любой 12-месячный период, но общий объём пространства адресов не может быть больше, чем AW LIR. Сброс окна производится в годовщину назначения адресов. Если LIR сделала несколько назначений организации в течение года, её AW для этой организации полностью восстанавливается через год после последнего назначения. LIR может назначить дополнительные адреса тому же конечному пользователю после утверждения в RIPE NCC.
Размер AW регулярно пересматривается хостмастерами RIPE NCC. LIRы могут связаться с RIPE NCC по оценке своего AW в любое время. Примите на заметку, что RIPE NCC всегда приветствует обращение LIR за дополнительным мнением по поводу заявок, даже если они подпадают под AW LIR.
Как скоро опытность контактных персон LIR возрастает, размер их AW может быть увеличен. Это определяется на основе:

• корректно заполненной документации, представленной в RIPE NCC
• хороших суждений, проявленных при оценке запросов на пространство адресов
• соответствующим образом зарегистрированных прошлых назначений

Действующая LIR ответственна за обучение своих новых контактных персон обращению с назначениями пространства адресов в соответствии с регламентом, описанным в настоящем документе, и соответствующими процедурами. Менее опытные контактные персоны LIR могут совершить ошибки как в суждениях, так и в процедуре. Если ошибки начинают повторяться, AW для данной LIR может быть уменьшено, чтобы предотвратить совершение LIRой недействительных назначений. AW может быть впоследствии увеличено вновь на основе вышеперечисленных критериев.
AW может также быть понижено после или в процессе аудита, если замечены недействительные назначения.
Информация о подготовительных курсах и учебном материале (на английском языке) может быть найдена по ссылке:
http://www.ripe.net/training/

8.0 Назначения для межсетевых экспериментов
Организациям часто необходимо осуществить тестирование новых Интернет-услуг и технологий. Это требует ресурсов по нумерации на период теста. Регламентная задача сохранения ресурсов имеет меньшее значение, когда ресурсы выделяются на временной основе.
Организация, получающая ресурс адресов, должна документировать эксперимент. Это может быть сделано в форме текущих Экспериментальных RFC IETF (см. раздел 4.2.1 документа RFC 2026) или "предлагаемого эксперимента" с описанием потребных ресурсов и планируемой деятельности.
Размер назначения будет равен существующему минимальному размеру выделения на момент получения запроса. Когда эксперимент требует изменения этого правила, это должно быть отмечено в запросе на ресурс.
Предполагаемый эксперимент должен быть сделан публичным (то есть опубликован на веб-сайте) на момент регистрации ресурсов в RIPE NCC. Вслед за завершением эксперимента его результаты должны быть опубликованы бесплатно и без ограничений на разглашение.
Выделенные ресурсы не должны использоваться для коммерческих целей во время или по завершению эксперимента.
Ресурсы будут выделены на временной основе на период длиной в год. Продление регистрации ресурсов возможно по получению нового запроса, который детализирует продолжение эксперимента на протяжении расширенного периода.
RIPE NCC зарегистрирует выделенные ресурсы в базе данных Whois RIPE.
Запрос должен быть сделан LIR с использованием соответствующей формы запроса. Подробности эксперимента должны быть отмечены в форме, доступной (на английском языке) по ссылке:
http://www.ripe.net/ripe/docs/internet-registries.html#request

9.0 Адресное пространство: независимое и агрегируемое
LIRам выделяется агрегируемое пространство адресов (PA). Они суб-выделяют и назначают его нижестоящим сетям. Если нижестоящая сеть конечного пользователя меняет своего поставщика услуг, пространство адресов, назначенное или суб-выделенное предыдущим поставщиком услуг, должно будет возвращено, и сеть перенумерована.
По контрасту, независимое (PI) пространство адресов не может быть агрегировано. Оно остаётся назначенным сети так долго, пока исходные критерии назначения действительны. Однако адреса PI расточительно маршрутизировать в силу невозможности их агрегировать. Они могут быть не маршрутизированы глобально.
Всегда должно рекомендоваться использование пространства адресов PA.
LIRы обязаны разъяснить конечным пользователям, какой тип пространства адресов назначается. Чёткие условия договора рекомендуются и обязательны для пространства адресов PA. В прошлом некоторые LIRы назначили пространство адресов, которое было де-факто агрегировано, но формально не является PA, поскольку не были сделаны чёткие положения договора по завершению срока действия назначения. LIRы должны просить уходящих клиентов добровольно освободить это пространство адресов по завершению предоставления услуг. Там, где это возможно, LIRы должны проводить работу по созданию договорных условий с целью преобразования адресов PI в адреса PA.
Конечные пользователи, запрашивающие пространство адресов PA, должны получать это или аналогичное предупреждение:
Назначение этого пространства адресов IP действительно до тех пор, пока критерий исходного назначения удовлетворяется, и только на период сервисного соглашения между нами и вами. Мы имеем право переназначить это пространство адресов другому пользователю по окончании срока действия договора или по истечении оговоренного периода после того. Это означает, что вы должны будете переконфигурировать адреса всего оборудования, использующего эти адреса IP, если вам по-прежнему нужна будет глобальная уникальность этих адресов.
Конечным пользователям, запращивающим пространство PI, следует давать аналогичное предупреждение:
Назначение этого пространства адресов IP действительно до тех пор, пока критерий исходного назначения удовлетворяется. Однако назначение этого пространства адресов не означает, что это пространство адресов будет маршрутизируемо в любой части Интернета. Ожидается, что пользователям придётся платить дополнительно за действительную маршрутизацию адресов PI в отличие от адресов PA. В некоторых случаях может стать невозможно получить маршрутизируемость относительно малых объёмов адресов PI в большей части Интернета. Мы настойчиво советуем вам связаться с каждым предполагаемым поставщиком услуг по поводу особенностей обслуживания при использовании адресов PI.
LIRы зарегистрируют тип любого назначенного пространства адресов, используя аттрибут : объекта inetnum в базе данных RIPE.

Возможные значения этого аттрибута таковы:
ALLOCATED PA: Это пространство адресов было выделено LIR, и ни одно назначение или суб-выделение, сделанное из него, не является переносимым. Назначения и суб-выделения не могут быть сохранены при переходе к другому поставщику.
ALLOCATED PI: Это пространство адресов было выделено LIR или RIR, и все сделанные оттуда назначения являются переносимыми. Назначения могут быть сохранены, столь долго, сколь сохраняет действие исходный критерий назначения. Суб-выделения из этого типа адресного пространства производиться не могут.
ALLOCATED UNSPECIFIED: Это пространство адресов было выделено LIR или RIR. Назначения могут быть PA или PI. Этот статус предназначен для документирования прошлых выделений, где существуют назначения обоих типов. Он не употребляется для новых выделений. Суб-выделения из этого типа адресного пространства производиться не могут.
SUB-ALLOCATED PA: Это пространство адресов LIR суб-выделил для сетевого оператора, который будет производить из него назначения. Все сделанные оттуда назначения являются PA. Они не могут быть сохранены при переходе на обслуживание к другому поставщику.
LIR-PARTITIONED PA: Это позволяет LIR доументировать распределение и передать управление выделенным пространством внутри своей организации. Пространство адресов со статусом LIR-PARTITIONED не считается используемым. Когда адреса используются, более специфичный inetnum должен быть зарегистрирован.
LIR-PARTITIONED PI: Это позволяет LIR доументировать распределение и передать управление выделенным пространством внутри своей организации. Пространство адресов со статусом LIR-PARTITIONED не считается используемым. Когда адреса используются, более специфичный inetnum должен быть зарегистрирован..
EARLY-REGISTRATION: Это используется администрацией базы данных RIPE при передаче регистраций эпохи до RIR из базы данных ARIN. Это значение может быть изменено пользователями базы данных. Только администраторы базы данных RIPE могут создавать объекты с таким значением.
NOT-SET: Это означает, что регистрация была произведена, до того как аттрибут : стал обязателен для объектов inetnum. Объект не был с тех пор скорректирован. Новые объекты не могут быть созданы с таким значением. Значение может быть изменено пользователями базы данных.
ASSIGNED PA: Это пространство адресов было назначено конечному пользователю для пользования услугами, предоставляемыми выдающей LIR. Оно не может быть сохранено после завершения использования услуг, предоставляемых этой LIR.
ASSIGNED PI: Это пространство адресов было назначено конечному пользователю и может сохраняться за ним сколь угодно долго, пока исходный критерий назначения действителен.
Создание объекта inetnum со статусом или возможно, только если не существует меньшего или большего по размерам пересекающегося по пространству адресов (специфичного) объекта inetnum со статусом .
Пространство адресов без явно прописанного типа в аттрибуте : принимается за PI. LIRы должны чётко обозначать все новые назначения в базе данных RIPE как либо соответственно.
RIPE NCC более не выделяет пространство адресов PI. Следовательно, у многих LIR нету выделенных им адресов PI, из которых они могут назначать адреса PI. Если у LIR есть конечный пользователь, которому требуется пространство адресов PI, она может поддержать его, отправляя запросы в RIPE NCC от имени конечного пользователя. Эта поддержка включает в себя помошь конечным пользователям в подготовке соответствующим образом документированного запроса. RIPE NCC произведёт назначение адресов PI, когда это оправдано.

10.0 Ведение записей
Вся документация, относящаяся к запросам адресов IP, а также суб-выделениям или назначениям адресов, должна храниться в LIR для будущих проверок. Эти данные нужны для оценки последующих запросов от одной и той же организации, для аудитов, производимых RIR, а также для решения любых вопросов, которые могут возникнуть касательно назначения адресов. Записи должны включать:

• Оригинал запроса
• Всю сопроводительную документацию
• Всю сопутствующую переписку между LIR и конечным пользователем
• Решение о назначении, включая причины любого необычного решения
• Сведения о персоне, ответственной за принятие решения

Хронология событий и ответственные лица должны быть чётко записаны. С целью способствования обмену информацией, крайне рекомендуется, чтобы эти документы хранились в электронном виде и готовые к доступу. По запросу, любая вышеуказанная информация должна быть предоставлена в RIPE NCC на английском языке.

11.0 Аудит LIR
Сообщество RIPE запросило у RIPE NCC проведения аудита операций, производимых LIR, и обеспечивать последовательное и непредвзятое применение установленного сообществом регламента. Подробности этой деятельности описаны в документе RIPE <Деятельность RIPE NCC по проверке согласованности и аудиту>, доступному по ссылке:
http://www.ripe.net/ripe/docs/audit.html

12.0 Закрытие LIR по решению RIPE NCC
RIPE NCC может закрыть LIR по одной из следующих причин:

• LIR не оплачивает свою задолженность в RIPE NCC
• RIPE NCC не может связаться с LIR значительный период времени
• LIR постоянно нарушает регламент сообщества RIPE

RIPE NCC принимает на себя ответственность за пространство адресов, которое содержали закрываемые LIRы.

Данный документ содержит дополнения и уточнения к рекомендациям RIPE, известным как ripe-488, вызванные спецификой обработки заявок в ЗАО <Юго-Восток Транстелеком>.

Перед прочтением этого документа, пожалуйста, ознакомьтесь с оригиналами документов ripe-489, ripe-489.

Заявка на получение IP-адресов содержит большое количество цифр и технических подробностей, которые мы обязаны тщательно проверить при распределении адресного пространства. В значительной степени, добиваясь от клиента точного заполнения формы, мы заставляем его осознать, чего он хочет на самом деле. Чем точнее будет заполнена Ваша заявка сегодня, тем меньше проблем с администрированием сети возникнет у Вас в будущем.

Замечания:

1. Вся электронная почта на кириллице использует в Internet кодировку KOI8. Поэтому внимательно следите за тем, чтобы Ваши письма к нам приходили в виде обычного текста именно в кодировке KOI8. Мы не обрабатываем писем в формате Microsoft Word, Ami Pro, WordPerfect и в кодах base64 и UUENCODE.
2. Все шаблоны формы ripe-488 необходимо заполнять строго по-английски, так как обработанная заявка отсылается в RIPE.
3. Если Вы предполагаете получить IP адреса из блока ЗАО <Юго-Восток Транстелеком>, Вам необходимо указать идентификатор ( в поле x-ncc-regid в разделе #[GENERAL INFORMATION]#) значение ru.settc
4. Как указано в ripe-488, заявка состоит из отдельных частей, называемых шаблонами (templates). Каждый шаблон имеет заголовок, ограниченный квадратными скобками и знаками номера.
   Необходимо оставлять ВСЕ заголовки разделов в тексте заявки, даже если Вы не намерены заполнять какие-либо разделы.

Замечания по конкретным полям заявки