НазадО РосНИИРОССетевой информационный центрПроекты

Политика распределения адресов IPv4 в Европейском регионе

Оригинал: ripe-530
Дата: 21 октября 2011 г.

В документе изложены действующие в настоящее время принципы распределения адресного пространства IPv4. Принципы были разработаны членами рабочей группы (Address Policy Working Group (AP WG) Европейского Интернет-сообщества RIPE на основе открытого процесса обсуждения членами сообщества. Координационный Цетр сообщества (RIPE NCC) следует данным принципам в пределах Европейского и других регионов, находящихся в ведении RIPE NCC.

Информацию о деятельности рабочей группы (Address Policy WG) см.:
http://www.ripe.net/ripe/groups/wg/ap


1.0 Введение
1.1 Сфера действия документа (Scope)
2.0 Адресное пространство IPv4
3.0 Цели регистрационной системы Интернета
3.1 Конфиденциальность
3.2 Языковые ограничения
4.0 Требования регистрации
5.0 Политика распределения блоков (Allocations)
5.1 Первый блок адресов
5.2 Механизм медленного старта (Slow-start Mechanism)
5.3 Получение последующих блоков адресов (Additional Allocations)
5.4 Подблоки (Sub-allocations)
5.5 Передача блоков (Transfers of Allocations)
5.6. Использование последнего блока /8 (Use of last /8 PA Allocations)
6.0 Указания по выделению адресов (Assignment Guidelines)
6.1 Документация по сетям (assignements)
6.2 Инфраструктура сети провайдера (LIR) и адреса для конечного пользователя (end user)
6.3 Расход адресов (Utilisation Rates)
6.4 Резервирование не поддерживается (Reservations Not Supported)
6.5 Адреса для административных целей (Administrative Ease)
6.6 Продолжительность пользования адресами (Validity of an Assignment)
6.7 Эффективность (Efficiency)
6.8 Перенумерция (Renumbering)
6.9 Адреса для Anycasting TLD и Tier 0/1 ENUM Nameservers
6.10. Провайдеро-независимые адреса IPv4 для Multihoming
7.0 Assignment Window (AW)
8.0 Провайдеро-независимые (Provider Independent) и аггрегатируемые (Provider Aggregatable Addresses) адреса
9.0 Ведение учета (Record Keeping)
10.0 Аудит (LIR Audit)
11.0 Закрытие LIR


1.0 Введение

Сетевой Кординационный Центр RIPE (RIPE NCC) является независимой ассоциацией, одной из пяти Региональных регистратур (Regional Internet Registry, или RIR). Регионы, находящиеся в ведении RIPE NCC - Европа, Ближний Восток, Центральная Азия. Как Региональная регистратура (RIR), RIPE NCC отвечает за распределение адресов, номеров автономных систем (AS), ведение обратных зон. РаспределениеIP-адресов происходит иерархически, согласно схеме, представленной в документе "Система регистрации в Интернет" ("Internet Registry System").

1.1 Сфера действия документа (Scope)

В данном документе описывается политика управления адресным пространством Интернета версии IPv4, выделяемым через Сетевой координационный центр RIPE (RIPE NCC). Документ касается всего адресного пространства IPv4, выделяемого (allocated and assigned) RIPE NCC. Политика, изложенная в данном документе, обязательна для всех членов RIPE NCC (LIRs).

Данный документ не касается номеров AS, адресов версии IPv6, private address space и multicast address space. Он также не затрагивает порядка распределения адресного пространства в сети Интернет другими региональными регистратурами (RIRs). Политика распределения номеров AS и адресов версии IPv6 изложена в других документах, см.
http://www.ripe.net/ripe/docs/policy

2.0 Адресное пространство IPv4

Под IP-адресами в данном документе подразумеваются 32-битовые числа, используемые как адреса в протоколах IPv4. Существует 3 типа IP-адресов: Публичные адреса (Public Addresses)

  1. Публичные адреса должны быть уникальными в соответствии с целями, указанными в главе 3 данного документа.
  2. Некоторые диапазоны IP-адресов были зарезервированы для приватных сетей, использующих IP. Эти адреса каждый может использовать в своей сети без всякой регистрации и согласования. Это адреса хостов, не имеющих прямой связи с Интернетом. Такой тип подключения характерен при использовании технологии Network Address Translation (NAT). Использование приватных адресов вносит определнные оганичения: хостам доступны не все услуги Интернета. Там, где необходим полный набор услуг, используются публичные адреса.

    За более подробным описанием private address space обратитесь к RFC 1918
    ftp://ftp.ripe.net/rfc/rfc1918.txt

    Технология NAT описана в документе RFC 2993:
    ftp://ftp.ripe.net/rfc/rfc2993.txt

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

3.0 Цели регистрационой системы Интернета

Распределение адресного пространства Интернета должно проводиться с учетом следующих условий:

  1. Уникальность (Uniqueness): Публичный адрес должен быть уникальным, что гарантирует возможность идентификации каждого хоста в сети Интернет.
  2. Aggregation (Аггрегатирование): Распределение адресного пространства по иерархическому принципу позволяет объединять маршруты. Этот принцип может быть назван "маршрутизационным".
  3. Conservation (Экономия адресов): Распределение адресного пространства Интернета должно соответствовать потребностям пользователей. В целях экономии ресурсов адреса должны распределяться по мере реальной в них необходимости; делать запасы не разрешается.
  4. Registration (Регистрация): Выделение адресного пространства должно подтверждаться документально. Это гарантирует уникальность адресов и обеспечивает необходимую информацию для диагностики на всех уровнях.

3.1 Конфиденциальность

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

3.2 Языковые ограничения

Общение с RIPE NCC должно вестись только на английском языке.

4.0 Требования регистрации

Все адреса (блоки и сети) должны быть зарегистрированы в базе данных RIPE. Это необходимо для обеспечения уникальности адресов и для поддержки работы сетей.

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

5.0 Политика распределения блоков (Allocations)

Под "Allocation" здесь понимается блок IPv4 адресов, из которого распределяются сети ("assignements").

Размер блока (Allocation) определяется в зависимости от количества адресов, которые будут необходимы LIR в течение 1 года (12 месяцев).

С 1 июля 2010 г. начинает действовать принцип постепенного уменьшения периода, на который запрашиваются адреса.

С 1 июля 2010 г. адреса будут выделяться на период до 9 месяцев.

С 1 января 2011 г. адреса будут выделяться на период до 6 месяцев.

С 1 июля 2011 г. адреса будут выделяться на период до 3 месяцев.

Все LIR'ы, получающие адресное пространство в RIPE NCC, должны следовать правилам, соответствующим политике, выработанной собществом RIPE и описанным в данном документе.

5.1 Первый блок адресов.

Минимальный размер блока (Allocation) - /21.

Подробнее о том, как стать членом RIPE NCC см. в документе "Procedure for Becoming a Member of the RIPE NCC"

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

5.2 Механизм медленного старта (Slow-start Mechanism)

Принцип медленного старта необходим для соблюдения равных прав всех организаций, зарегистрированных как LIR, при получении ими блоков адресов (allocations). Минимальный размер первоначального блока определяется в зависимости от потребностей LIR. Блоки больших размеров выделяются тем, кто в них обоснованно нуждается. Размер последующих блоков для LIR зависит от того, насколько активно идет расход уже имеющихся адресов (usage rate).

5.3 Получение последующих блоков адресов (Additional Allocations)

LIR может получить дополнительный блок (additional allocation) при условии, что 80% имеющегося адресного пространства использовано - как в виде выделенных сетей (assignments), так и в виде подблоков (sub-allocations). Новый блок может быть выделен в случае, если оставшихся у LIR адресов не хватает для новой заявки на сеть или подблок (sub-allocation).

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

Для получения нового блока LIR подает заявку по специальной форме "IPv4 Additional Allocation Request Form", см.
https://www.ripe.net/ripe/docs/add-allocation.html

Дополнительный блок может быть выдан только после проверки данных о распределенных адресах, приведенных в заявке.

RIPE NCC старается предоставить последовательное (contiguous) пространство, по возможности. Но такая последоватьльность не может быть всегда строго гарантирована, поскольку есть ряд причин, которые не зависят от RIPE NCC (количество новых LIR, быстрота использования полученных блоков и др.).

5.4 Подблоки (Sub-allocations)

При выделении подблоков учитывается принцип аггрегатирования. Подблоки выделяются только из блоков со статусом "ALLOCATED PA". LIR'ы, имеющие блоки "ALLOCATED PI" или "ALLOCATED UNSPECIFIED" должны поменять их статус на "ALLOCATED PA", прежде чем выделять из низ подблоки (sub-allocations) - что возможно только при условии, что в этих блоках не содержится сетей "ASSIGNED PI". Значения поля "статус" ("status") описаны в п. 9.0 данного документа.

Для изменения статуса блока на "PA" необходимо обратиться по адресу <lir-help@ripe.net>.

Минимальный размер подблока - /24. Это минимальный размер сети, на который возможно создать обратную зону. Этот размер достаточно удобен для того, чтобы его можно было разбить на более мелкие сети, которые могут быть переданы в управление downstream-операторам.

В течение года LIR может выделить какой-либо организации подблоков на /20 (4096 адресов).

Количество downstream-операторов, которым LIR может выделить подблоки, не ограничено.

Один downstream-оператор может получить подблоков более чем на /20, если они взяты более чем у одного LIR.

По договору с RIPE NCC, LIR отвечает за все адресное пространство, выделенное операторам, в соответствии с политикой, принятой сообществом RIPE. Рекомендуется ссылаться на эти правила в договорах с операторами, которым выделяются подблоки.

RIPE NCC считает адреса, выданные в качестве подблоков, как используемые (as "used"), при рассмотрении запроса нового блока для LIR. Если LIR выделил множество подблоков, но адреса в них используются в незначительном количестве, RIPE NCC попросит LIR пересмотреть основания для выделения подблоков.

Следует заметить, что оценка заявки на получение блока (allocation) отличается от заявки на сеть (assignement). В заявке на сеть можно видеть план использования адресов конкретной организацией. В заявке на блок присутствует общий план ведения дел в аспекте оказания услуг и маркетинга. Потребности в адресах каждого отдельного клиента в этом случае не могут быть рассмотрены.

При выделении подблоков рекомендуется использовать механизм медленного старта. Это дает два преимущества: уверенность, что подблок эффективно используется, и возможность проследить, насколько downstream-оператор, получивший подблок, следует политике распределения адресного пространства, принятой сообществом RIPE.

Подблоки составляют часть пространства, которое LIR аггрегатирует. LIR всегда может отследить работу клиентов своего downstream-оператора, владеющего подблоком. LIR, если не хочет потерять свое адресное пространство, должен четко прописать понятие "подблок" в договоре с downstream-оператором.

5.5 Передача блоков (Transfers of Allocations)

Блоки, полученные LIR от RIPE NCC или IANA, разрешается передавать другим организациям (полностью или частично). Передаваемые блоки не должны включать в себя сети, выделенные (assigned) конечным пользователям.

Блоки можно передавать только членам RIPE NCC, то есть LIR'ам. Передаваемый блок не должен быть меньше минимального размера блока (minimum allocation block size) на момент передачи. Процедура передачи блока включает в себя оценку и одобрение со стороны RIPE NCC, как при получении дополнительного блока (additional allocation) - см. часть 5.3 данного документа.

Передача блока должна быть отражена в базе данных RIPE. Она может производиться как на постоянной, так и на временной основе.

LIR, получивший блок путем передачи, не может передавать его (полностью или частично) другому LIR'у в течение 24 месяцев с момента получения.

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

Переданные блоки оформляются на нового владельца.

Переданные блоки для принимающей стороны ничем не отличаются от дополнительных блоков (additional allocations), выделенных напрямую RIPE NCC, и должны использоваться в соответствии с политикой, описанной в данном документе.

5.6 Использование последнего блока /8 (Use of last /8 for PA Allocations)

Когда RIPE NCC начнет выделять блоки адресов IPv4 из последнего блока /8, полученного от IANA, будет применяться политика, изложенная ниже.

  1. Выделение блоков для LIRs из последнего /8 (Allocations for LIRs from the last /8)
  2. Порядок удовлетворения заявок LIR на адреса IPv4 будет следующий:

    1. LIR может получить только один блок из последнего блока /8. Размер блока - /22.
    2. LIR получит только один блок /22, даже если потребность в адресах намного выше.
    3. LIR может запросить этот блок и получить его в соответствии с политикой распределения адресного пространства, которая действовала на момент запроса.
    4. Блоки IPv4 будет выданы только тем LIR'ам, которые получили адреса IPv6 от upstream LIR или от RIPE NCC.
  3. Непредвиденные обстоятельства (Unforeseen circumstances)

    1. Блок /16 будет зарезервирован для будущих непредвиденных целей. Если таковых не окажется, то к моменту, когда последний /8 будет израсходован, этот блок будет распределен в соответствии с п. 1.
  4. Повторное использование адресов (Post-depletion Address Recycling)

  5. Данные положения касаются только адресного пространства, возвращенного в RIPE NCC и не подлежащего возврату в IANA.

    1. Любое адресное пространство, возвращенное в RIPE NCC, будет распределяться по правилам, описанным в части 1.
    2. Минимальный размер блока, выделяемого из последнего /8, может быть при необходимости изменен.
  6. Если адресов недостаточно (Insufficient address space)

  7. Если адресов для выделения блока /22 будет недостаточно, адреса будут выделены несколькими блоками (multiple allocations), но в количестве, эквивалентном /22.

6.0 Указания по выделению адресов (Assignment Guidelines)

Поскольку цели conservation и aggregation часто конфликтуют между собой, каждый запрос IP-адресов должен быть тщательно взвешен (evaluated), чтобы выделенное количество адресов соответствовало одновременно и той, и другой цели. Правила, изложенные в данном документе, способствуют достижению приемлемого компромисса.

Конечным пользователям (end users) выделяется адресное пространство, необходимое для удовлетворения их нужд, на период 12 месяцев.

С 1 июля 2010 г. начинает действовать принцип постепенного уменьшения периода, на который запрашиваются адреса.

С 1 июля 2010 г. RIPE NCC или LIR будет выделять адреса пользователям на период до 9 месяцев.

С 1 января 2011 г.RIPE NCC или LIR будет выделять адреса пользователям на период до 6 месяцев.

С 1 июля 2011 г. RIPE NCC или LIR будет выделять адреса пользователям на период до 3 месяцев.

В RIPE NCC направляются заявки только на то количество адресов, которое не умещается в Assignment Window (см. 7.0). Но и в других случаях RIPE NCC приветствует желение LIR спросить совета относительно распределения адресов из своего блока.

6.1 Документация по сетям (assignements)

При запросе адресов необходимо предоставить информацию о сети, из которой ясно следует, в каком количестве адресов нуждается автор запроса. Эта информация включает в себя сведения об организации (End User), потребности в адресах, инфраструктуре сети, о планах использования адресного пространства в будущем. Необходимо также указать, какое количество адресов уже используется для данных целей к моменту запроса, чтобы избежать дублирования.

Эта информация необходима для принятия решения о выделении адресов в соответствии с общими правилами (п. 3.0 данного документа). Степень подробности информации пропорциональна сложности устройства сети. LIR необходимо убедиться в полноте предоставленной информации по данному запросу.

RIPE NCC предлагает набор форм (заявок) и пояснения по их заполнению. Заявки, содержащие информацию о сети, должны храниться у LIR. Эти формы LIR может использовать для заявок от своих клиентов, может вводить дополнительные поля и собирать дополнительные сведения.

Однако для тех случаев, когда требуется подтверждение RIPE NCC на выдачу адресов, или для целей аудита (при получении нового блока адресов, например), информация должна быть представлена в полном соответствии с действующей формой заявки:
http://www.ripe.net/ripe/docs/other-documents/request-forms-supporting-notes

6.2 Инфраструктура сети провайдера (LIR) и адреса для конечного пользователя (end user)

IP-адреса, используемые для подключения конечного пользователя к провайдеру (point-to-point links) считаются не "клиентскими" адресами, а частью провайдерской инфраструктуры. Такие адреса регистрируются не на пользователя, а на провайдера. В случае, если конечный пользователь имеет сеть публичных IP-адресов, регистрировать ее надо на пользователя, приводя его контакты. Если конечный пользователь - лицо, а не организация, контактные адреса провайдера могут быть заменены контактами пользователя.

Пояснения к процедуре регистрации объектов в базе данных RIPE можно найти в документе
http://www.ripe.net/data-tools/support/documentation/getting-started

6.3 Расход адресов (Utilisation Rates)

Запрашивать адреса надо с расчетом, что они будут сразу использованы не менее, чем на 50%.

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

6.4 Резервирование не поддерживается (Reservations Not Supported)

Конечным пользователям не разрешается запрашивать адресное пространство, основываясь на долгосрочных планах. Это противоречит принципу экономии адресного пространства и приводит к его фрагментации, если долгосрочные планы впоследствии не реализуются. Оценка запросов IP-адресов (evaluation of requests) должна быть основана на рассмотрении реальной потребности в адресах. Неиспользуемые или неэффективно используемые адреса должны быть учтены при оценке нового запроса. Либо они должны быть использованы для новых нужд, либо возвращены. Новые запросы от организаций могут быть удовлетворены только при условии использования ранее полученных адресов.

6.5 Адреса для административных целей (Administrative Ease)

Скорость расходования адресов Pv4 в Интернете такова, что это не позволяет выделять адреса данной версии для административных нужд (таких, как управление сетью (network management), биллинг и проч.).

6.6 Продолжительность пользования адресами (Validity of an Assignment)

Использование адресного пространства законно до тех пор, пока оно соответствует критериям выделения и пока в базе данных RIPE содержится соответствующий объект. Есди адреса были выданы для опреленной цели, и эта цель уже не существует, адреса необходимо вернуть. Если при выделении адресов была дана неверная информация относительно их предстоящего использования, пользование адресами не является законным.

Важно, чтобы адреса, на которые было получено подтверждение RIPE NCC, были зарегистрированы в базе RIPE. При создании объектов "inetnum:" на подтвержденные (approved) адреса необходимо указывать то же название сети (netname), которое фигурирует в заявке. Количество зарегистрированых адресов не должно превышать количество, указаное в заявке. Дата в первом поле "changed" не должна быть более ранней, чем дата письма с подтверждением RIPE NCC.

RIPE NCC проверяет выделенные сети при рассмотрении заявки на новый блок (см. п. 5.3). Кроме того, регулярно проводятся проверки на предмет обоснованности выделения зарегистрированных сетей. Подобные проверки являются частью аудита, подробнее см.
http://www.ripe.net/ripe/docs/audit

6.7 Эффективность (Efficiency)

В тех случаях, когда запрашивается большое количество адресов для целей, не требующих такого расхода, например, transient connections или virtual server hosting, RIPE NCC может проверить реальный расход адресов, прежде чем подтвердить заявку.

6.8 Перенумерция (Renumbering)

Как правило, замена адресов производится по принципу один к одному. Имеющееся к этому моменту количество адресов заменяется таким же количеством адресов, если критерии первоначального выделения все еще действуют. Если выделенные адреса используются только наполовину, конечный пользователь должен будет направить новую заявку. Если заявка на перенумерацию (renumbering request) превышает AW (см. п. 7.0), заявка направляется в RIPE NCC для подтверждения.

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

После того, как перенумерация была произведена, информация о старой сети удаляется из базы RIPE.

6.9 Адреса для Anycasting TLD и Tier 0/1 ENUM Nameservers

Данный пункт относится к организациям, ответственным за TLD, в соответствии с IANA's Root Zone Database, и администраторам ENUM, назначенным ITU. Эти организации могут получить до четырех /24 на TLD и четырех /24 на ENUM. Адреса могут быть использованы только для anycasting TLD/ENUM, как это описано в BCP126/RFC4786 (http://www.ietf.org/rfc/rfc4786.txt).

Распределение IP-адресов для anycasting подчиняется политике распределения PI (Provider Independent) адресного пространства, описанной в данном документе. Одновременно оно подчиняется политике, описанной в документе "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" .

Адреса имеют статус 'ASSIGNED ANYCAST' в базе данных RIPE и подлежат возврату в RIPE NCC в случае прекращения использования для указанных целей.

6.10. Провайдеро-независимые адреса IPv4 для Multihoming

RIPE NCC выделит дополнительные адреса IPv4 конечному пользователю для нескольких /24, если конечный пользователь продемонстрирует:

  • необходимость в адресах Provider Independent (PI)

  • намерение анонсировать эти адреса двум или более Автономным системам, которые не находятся под управлением данного пользователя.

В целом, не более 255 дополнительных IPv4 адресов может быть выделено конкретному конечному пользователю для целей, изложенных выше.

7.0 Assignment Window (AW)

AW - это максимальное количество адресов, которое LIR может выделять для собственных нужд или для нужд клиента без предварительного согласования с RIPE NCC. Оно имеет вид записи /nn ("CIDR notation").

Предоставление AW основано на признании опыта (квалификации) сотрудников LIR, их умения работать в соответствии с общепринятыми правилами распределения адресного пространства. RIPE NCC оставляет за собой право проверки использования AW, следуя принципам контроля за использованием адресного пространства с точки зрения его экономии, аггрегатирования, регистрации. На адреса, выделенные с учетом AW, должна быть составлена документация в виде заполненных заявок по утвержденным формам. Формы заявок опубликованы на
http://www.ripe.net/ripe/docs/other-documents/request-forms-supporting-notes

Все новые LIRs в начале своей деятельности имеют AW = 0. Через 6 месяцев после того, как LIR получит свой первый блок (allocation), AW автоматически поднимается до /21 (2048 адресов). До тех пор, пока AW не повысится, LIR должен запрашивать подтверждение RIPE NCC при выделении адресов из своего блока

AW применяется различно в зависимости от того, запрашиваются ли адреса для внутренней инфраструктуры LIR - или для клиентов.

LIR может использовать AW без временных ограничений, так часто, как это необходимо. Это означает, что, если имеется AW /25, LIR может использовать его столько раз, сколько будет нужно, не посылая запросы в RIPE NCC - если адреса берутся для собственной инфраструктуры LIR. Если же адреса для этих целей понадобятся в большем количестве (скажем, /24 за один раз), LIR обязан получить подтверждение от представителя RIPE NCC, отправив туда заявку согласно общей процедуре.

При оформлении в базе данных адресов для внутренних нужд LIR, выделенных с использованием AW, необходимо указать в поле "remarks:" объекта inetnum значение "INFRA-AW". (В строке с этим значением не должно быть более никакой информации. В случае необходимости можно ввести добавочные поля "remarks:").

LIR может оформить адреса в размере AW для одного и того же клиента без подтверждения RIPE NCC только один раз в течение одного года. Это означает, что, если в течение одного года один и тот же LIR или его клиент запрашивает адреса для своей организации во второй, третий и более раз, - причем их общее количество, включая текущий запрос, превышает размер AW, - запрос следует направить в RIPE NCC для подтверждения.

Размер AW регулярно пересматривается сотрудниками RIPE NCC. LIR может обратиться к ним с просьбой увеличить размер AW через 6 месяцев после того, как получит свой первый блок адресов (allocation), а также в любое время после этого. LIR может обратиться в RIPE NCC и в тех случаях, когда подтверждения на выдачу адресов не требуется, но есть дополнительные вопросы, нужен совет, и т.п.

По мере роста квалификации сотрудников LIR увеличивается размер AW. Это происходит при следующих условиях:

- заявки правильно составляются
- размеры запросов соответствуют реальным потребностям в адресах
- полученные адреса аккуратно регистрируются

Сотрудники LIR, имеющие опыт, должны обучать новых сотрудников. Если ошибки при распределении адресов становятся многочисленными, размер AW может быть уменьшен, с последующим восстановлением, как описано выше. AW может быть уменьшено также в случае указания аудита на его неверное использование.

8.0 Провайдеро-независимые (Provider Independent) и аггрегатируемые (Provider Aggregatable) адреса

LIR получают PA-адресное пространство, которое они выделяют пользователям или нижестоящим провайдерам (downstream networks). Если последние меняют провайдера, они должны вернуть полученные адреса и получить новые (перенумероваться).

Провайдеро-независимое (PI) адресное пространство выделяется пользователям (End Users) из пула адресов, находящегося под непосредственным управлением RIPE NCC. PI адреса не могут быть переданы в пользование другим организациям (other parties). PI адреса могут оставаться в пользовании до тех пор, пока сохраняются условия, на которых они были выделены. В дополнение, на все вновь выделяемые PI адреса распространяется политика, описанная в документе "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" .

Поскольку PI адреса не являются частью блоков PA адресов LIR, они не аггрегатируются в более крупные блоки. Соответственно, они требуют дополнительных затрат для маршрутизации (routing), а также могут оказаться "not globally routable".

Следует настоятельно рекомендовать выбор в пользу PA адресов.

В прошлом некоторые LIR'ы выделяли адресное пространство, которое было фактически агрегатировано (de facto aggregated), но не помечено как "PA", поскольку в контрактах не было четких условий прекращения использования выделенных адресов (termination of the assignment). LIR'ы должны были просить пользователей добровольно вернуть адреса после прекращения действия контракта. По возможности, необходимо обозначать в контрактах подобные адреса как "PA", а не как "PI". 

При заключении договора на PA сети необходимо давать такое пояснение:

Использование адресов возможно до тех пор, пока в них есть необходимость, в пределах срока действия данного договора. После его окончания LIR имеет право передать адресное пространство другому пользователю. В этом случае Вам будет необходимо перенумеровать свое оборудование после окончания действия договора.

При заключении договора на PI сети необходимо давать такое пояснение:

Использование адресов возможно до тех пор, пока сохраняются условия, на которых они были выделены. Получение адресов возможно только при условии соблюдения политики, описанной в документе "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region" .

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

Информация о LIR как организации хранится вместе с данными о блоке (блоках) адресов с указанием их типа. Диапазон блока указывается в объекте inetnum. Тип адресов указывается в поле "status:" и может иметь одно из следующих значений:

ALLOCATED PA: Эти блоки были выделены для LIR или для RIR (в даном случае для RIPE NCC); все сети из этих блоков являются аггрегатируемыми (provider aggregatable, или PA). Это наиболее распространенный тип адресов. ALLOCATED PI: Эти блоки были выделены для LIR как провайдеро-независимые (provider independent). Этот тип адресов распределяется крайне редко, и только после тщательного изучения запроса. Подблоки (sub-allocations) не могут быть выделены из блоков этого типа. ALLOCATED UNSPECIFIED: Эти блоки были выделены для LIR, и адреса из этих блоков могут быть как provider aggregatable (PA), так и provider independent (PI). Этот тип блоков выделялся давно, для новых блоков статус ALLOCATED UNSPECIFIED не используется. Подблоки (sub-allocations) не могут быть выделены из блоков этого типа.

SUB-ALLOCATED PA: подблоки, которые LIR выделяет своим операторам (network operator) для дальнейщего распределения среди клиентов. Все сети, выделенные из блока PA, имеют тот же статус. При переходе к другому провайдеру адреса должны быть возвращены.

LIR-PARTITIONED PA: этот статус дает возможность LIR задокументировать передачу части своего адресного пространства в управление другой организации. Адресное пространство со статусом LIR-PARTITIONED не считается полностью использованным. При использовании сетей из данного адресного пространства они должны быть зарегистрированы в базе данных.

LIR-PARTITIONED PI: этот статус дает возможность LIR задокументировать передачу части своего адресного пространства в управление другой организации. Адресное пространство со статусом LIR-PARTITIONED не считается полностью использованным. При использовании сетей из данного адресного пространства они должны быть зарегистрированы в базе данных.

EARLY-REGISTRATION: статус используется администрацией базы данных RIPE при перенесении блоков из базы данных ARIN. Только администрация базы RIPE может создавать объекты с этим статусом.

NOT-SET: указывает на то, что блок был выделен в те времена, когда еще не существовало понятия "статус" , либо когда указание статуса еще не было обязательным для объектов базы. С тех пор объект не обновлялся. Новые объекты не могут иметь этот статус. Значение поля "статус" может быть

ASSIGNED PA: для PA адресов, выделенных конечному пользователю. Все сети из блоков, имеющих отметку "PA", имеют тот же статус "PA". При

ASSIGNED PI: для PI адресов, выделенных конечному пользователю. Адреса передаются пользователю на период, пока действуют критерии, по которым он их получил.

ASSIGNED ANYCAST: адреса для использования в TLD anycast networks. Могут использоваться только для целей anycast.

Создание в базе объекта со статусом "ASSIGNED PA" или "ASSIGNED PI" возможно только в случае, если не создано других объектов, которые включают в себя часть пространства, входящего в эти объекты.

Адресное пространство, не имеющее указания на принадлежность к одному из упомянутых типов в поле "статус", по умолчанию считаются PI. Статус адресов при регистрации объектов в базе должен четко указываться.

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

9.0 Ведение учета (Record Keeping)

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

  • оригиналы заявок
  • сопроводительную документацию
  • переписку по теме
  • принятие решений, включая пояснения к нестандартным решениям о выделении адресов
  • данные на ответственных за принятие решений.

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

10. Аудит (LIR Audit)

Сообщество RIPE поручило RIPE NCC осуществлять контроль над деятельностью LIR с точки зрения соблюдения правил распределения адресного пространства. Подробнее об этом можно узнать из документа "RIPE NCC Consistency and Auditing Activity" по адресу:

http://www.ripe.net/ripe/docs/audit

11. Закрытие LIR

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

  • LIR перестает оплачивать счета за услуги RIPE NCC
  • LIR оказывается вне контакта с RIPE NCC на длительное время
  • LIR систематически нарушает правила, принятые сообществом и оформленные документально RIPE NCC.

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

Информацию об учебных курсах для LIR и учебные материалы см. на
http://www.ripe.net/training/



НазадУсловия пользования услугамиНа главную страницу