Рекомендации по оформлению заявки на получение IP-адресов, отсылаемой в Сетевой Координационный Центр РосНИИРОС.

Введение

Данный документ содержит дополнения и уточнения к рекомендациям RIPE, известным как ripe-142, вызванные как спецификой обработки заявок в РосНИИРОС, так и направленностью деятельности РосНИИРОС на Россию и государства Содружества.

Перед прочтением этого документа, пожалуйста, ознакомьтесь с оригиналами документов ripe-141, ripe-142.
Наиболее полно процесс составления правильной заявки описан в документе ripe-159 (см. также в русском переводе)

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

  1. Замечания по поводу кодировки отправляемых писем.

    Вся электронная почта на кириллице использует в Internet кодировку KOI8. Поэтому внимательно следите за тем, чтобы Ваши письма к нам приходили в виде обычного текста именно в кодировке KOI8.

    Если Вы используете dMail for DOS, Beauty Mail for DOS, dMail for Windows или любую проограмму для работы с почтой в операционной системе UNIX, проблем у Вас не возникнет. Однако, в случае использования Microsoft Mail, Microsoft Exchange, Pegasus Mail, Eudora, Lotus cc:Mail и другого почтового программного обеспечения под операционные системы DOS, OS/2 и Windows NT, пожалуйста, проконсультируйтесь у своего системного администратора, не возникнет ли у Вас проблем с перекодировкой.

    Мы также не приветствуем писем в формате Microsoft Word, Ami Pro, WordPerfect и в кодах base64 и UUENCODE.

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

  2. Общие замечания.

    Если Вы предполагаете получить IP адреса из блока какой-либо Local Internet Registry из числа поддерживаемых РосНИИРОС, Вам необходимо указать идентификатор Вашей Registry (поле X-NCC-RegID) в начале запроса. Например, если Вы абонент МАРК-ИТТ, данное поле заполняется так:

    X-NCC-RegID: ru.ccl

    Как Вы понимаете, если нам самим придется узнавать, из какого блока необходимо выделить для Вашей сети IP адреса, обработка запроса задержится.

    Как указано в ripe-141, заявка состоит из отдельных частей, называемых шаблонами (templates). Каждый шаблон имеет заголовок, ограниченный квадратными скобками и знаками номера, например:

    #[CURRENT ADDRESS SPACE USAGE TEMPLATE]#

    Просьба оставлять все заголовки разделов в тексте заявки, даже если Вы не намерены заполнять какие-либо разделы.


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

    1. #[OVERVIEW OF ORGANIZATION TEMPLATE]#

      Приведите по возможности полное описание Вашей организации в произвольной форме на английском языке.

      Желательно, чтобы в качестве пояснений к нижеследующему разделу #[ADDRESSINGPLAN TEMPLATE]# здесь были бы приведены краткие характеристики Вашей сети, как-то: способ подключения Вашей сети к узлу вышестоящего провайдера (используемые лини связи и оборудование), наличие/отсутствие удаленных узлов (в том числе расположенных в других географических точках), предоставляемые/используемые сервисы Internet и.т.п. Если структура Вашей сети предполагает подключение удаленных локальных сетей абонентов, стоит это отметить, так как в этом случае, возможно, понадобится представить дополнительную информацию для занесения в базу данных RIPE.

      Например, через оборудование, используемое Вашей организацией, осуществляется доступ в Internet для локальных сетей Ваших абонентов, и при этом локальной сети выделяются более 4-х постоянных IP адресов. В этом случае необходимо заполнять отдельные заявки ripe-141 каждой локальной сети организации с целью занести в базу данных RIPE информацию о том, кто (какая организация, администратор) распоряжается данными IP адресами.

    2. #[REQUESTER TEMPLATE]#

      Эта часть заполняется составителем заявки и должна быть заполнена, даже если эти данные полностью совпадают с следующей частью - #[USER TEMPLATE]#.

    3. #[USER TEMPLATE]#

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

      name:

      полное имя контактного лица.

      organization:

      Полное название организации.

      country:

      Код ISO 3166 Вашей страны: для России - RU, для Украины - UA, для Беларуси - BY, для Казахстана - KZ, для Молдовы - MD, и т.д.

      phone:

      fax:

      Телефон и факс контактного лица. Пожалуйста, указывайте полный международный код, начинающийся знаком "плюс", даже если Вы находитесь в Москве, и нам это доподлинно известно. В номере не следует использовать тире, скобок, точек, запятых и прочих разделителей, кроме пробела.

      e-mail:

      Адрес контактного лица в электронной почте. Пожалуйста, приводите адрес в общепринятой в Интернете форме: пользователь@домен, где "пользователь" и "домен" состоят из латинских букв и цифр, разделенных точками и тире. Не указывайте адресов в формате X400 (клиенты Sprint) и FidoNet.

    4. #[CURRENT ADDRESS SPACE USAGE TEMPLATE]#

      Заполняется в том случае, если Вы уже располагаете зарегистрованными IP адресами, причем не имеет значения, из блока какого сервис-провайдера они были получены. Так как данная часть практически не отличается от #[ADDRESSING PLAN TEMPLATE]#, основные пояснения будут даны ниже.

    5. #[REQUEST OVERVIEW TEMPLATE]#

      Возможно, сначала удобнее будет заполнить #[ADDRESSING PLAN TEMPLATE]#, то есть исходя из структуры Вашей сети, представить разбиение Вашей сети на адресные сегменты (подсети), что особенно важно при запросе большого блока адресов. Если же Ваша сеть будет представлять из себя единый адресный сегмент, например физически сеть построена на одном Ethernet'е, (что стоит отметить в колонке Descr: #[ADDRESSING PLAN TEMPLATE]#), можно сразу заполнять данный раздел.

      request-size:

      Требуемое количество IP адресов (в штуках). Допускается указывать также количество сетей класса "С": "N class C", где N - число сетей.

      Учтите, что далее под IP адресами понимаются адреса интерфейсов, и поэтому их количество всегда будет больше, например возможного количества host'ов в Вашей сети (из-за резервирования адресов, содержащих все нули или единицы в хостовой части адреса (первый и последний адрес) для задания адреса подсети и использования в качестве broadcast адресов)

      addresses-immediate:

      addresses-year-1:

      addresses-year-2:

      subnets-immediate:

      subnets-year-1:

      subnets-year-2:

      Данные, характеризующие рост Вашей сети - количество IP адресов и подсетей, которые будут задействованы в течении 2-х лет. Существует следующее условие выделения требуемого кол-ва IP адресов:

      addresses-immediate: > = 1/4 x request-size:
      addresses-year-1: > = 1/2 x request-size:

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

      Учтите, что в настоящее время возможна регистрация и использование classless addresses, (см. например CIDR FAQ), поэтому советуем Вам при определении необходимого количества адресов исходить в первую очередь из количества host'ов в Вашей сети и не резервировать адреса только лишь с целью получить classful address- такое решение приемлемо лишь в исключительных случаях.

      inet-connect:

      Почему-то большинство людей делает ошибки именно здесь. Поле может соответствовать одному из трех форматов:

      • Will never connect - Вы точно не планируете подключать свою сеть к Internet.
      • Already connected through - Вы уже подключены к указанному провайдеру.
      • Plan to connect <date> <provider-name> - Вы собираетесь подключиться к указанному провайдеру в срок <date>. Во всех полях, требующих указания даты, она должна указываться в формате YYMMDD.

      Что касается обозначения <provider-name> - если Вами уже был указан идентификатор Local Internet Registry в начале запроса, то как Вы назовете своего провайдера здесь - уже не столь важно (например, Вы можете использовать тот же идентификатор или название организации Вашего провайдера или название узла, через который осуществляется подключение)

      country-net:

      Код ISO-3166 страны, в которой будет размещена сеть (см. выше).

      private-considered:

      Рекомендуется (например в rfc1918) при назначении IP адресов использовать вместо public там где это возможно private addresses из диапазона: 

      ---- from RFC1597 ---------------------------------------------------
 
3. Private Address Space

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private networks:

        10.0.0.0        -   10.255.255.255
        172.16.0.0      -   172.31.255.255
        192.168.0.0     -   192.168.255.255

      Отвечая "Yes", Вы говорите, что private addresses могут быть использованы/используются в Вашей сети.

      request-refused:

      Видимо, в каких-то случаях, например, когда абонент одновременно пытается получить адреса из блоков различных провайдеров, но ему в силу определенных обстоятельств отказано, имеет смысл разобраться в ситуации. Так или иначе, Вы можете рассчитывать на наше содействие при наличии проблем с получением IP адресов. Как правило request-refused: No

      PI-requested:

      Это поле также должно содержать "Yes" или "No" в зависимости от того, какие адреса Вам нужны - Provider Independent (PI) или Provider Aggregateable (PA) соответственно. Если Вы собираетесь запрашивать PI адреса (то есть хотите сказать "Yes") - ознакомьтесь предварительно с этой страницей

      address-space-returned:

      Если Вы возвращаете IP адреса, то Вы сообщаете об этом в данном поле в следующем формате:

      xxx.xxx.xxx.xxx - xxx.xxx.xxx.xxx to <провайдер/Registry> before <ггммдд>

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

      Учтите, что существует установленный период возврата адресов в процессе перехода на использование адресов из других блоков (блоков других провайдеров) - в среднем 3 месяца (см. rfc2008.txt ).

    6. #[ADDRESSING PLAN TEMPLATE]#

      Строки этой части заявки образуют таблицу и имеют следующий формат: <Relative Prefix><Subnet Mask><Size><Immediate> <1yr><2yr><Description>

      Далее будут рассматриваться эквивалентные обозначения: <подсеть><маска><размер подсети><число адресов в данный момент><через год><через два><описание>

      <подсеть> и <маска> должны соответствовать друг другу таким образом, чтобы в номере <подсети> не было единичных битов, которым бы соответствовали нули в <маске>. Например:

      • 192.210.210.0 255.255.255.0 - верно
      • 192.210.210.128 255.255.255.192 - верно
      • 192.210.210.210 255.255.255.128 - неверно

      Адреса интерфейсов "точка-точка" (с маской 255.255.255.252) имеет смысл, очевидно, группировать при описании в небольшие <подсети>, а не перечислять по отдельности, однако при этом не забывайте указывать в <описании>, какое количество групп адресов интерфейсов обьеденены в данной <подсети>.

      <маска> должна также соответствовать указанному в третьей графе <размеру подсети> так, чтобы их 32-битная сумма равнялась 0:

      • 255.255.255.0 + 256 = 1.0.0.0.0 = 0 (по модулю 2**32) - верно
      • 255.255.255.128 + 256 = 1.0.0.0.128 <> 0 (по модулю 2**32) - неверно
      • 255.255.255.128 + 64 = 255.255.255.192 <> 0 (по модулю 2**32) - неверно

      Очевидно, <размер подсети> должен быть степенью числа 2.

      Ниже приведен список соответствия <маски> <размеру подсети>.

      255.255.255.0 256
      255.255.255.128 128
      255.255.255.192 64
      255.255.255.224 32
      255.255.255.240 16
      255.255.255.248 8
      255.255.255.252 4

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

      В последнем столбце таблицы должно идти краткое <описание> подсети. Оно является обязательным.

      В конце таблицы должны приводиться четыре суммы: <размер> всего имеющегося адресного пространства, суммарное <число адресов в данный момент>,<через год><через два> Пятым словом в этой строке должно быть "Totals". Обращаем внимание на то, что значения, получившиеся в "Totals", должны быть эквивалентны соответствующим значениям полей раздела #[REQUEST OVERVIEW TEMPLATE]#

    7. #[NETWORK TEMPLATE]#

      inetnum:

      Здесь необходимо указать диапазон адресов, который Вы хотите использовать. Как правило, остается пустым, поскольку о том, какой именно блок в данный момент распределяется для провайдера Вы можете и не знать, тем не менее здесь снова можно указать размер запрашиваемого блока адресов с помощью префиксов, например, необходим блок в 1 class C:

      inetnum:x.x.x.x/24

      netname:

      В этом поле указывается имя Вашей сети; желательно проверить в базе RIPE, не используется ли уже подобное имя.

      descr:

      Здесь даете краткое описание своей организации, включая адрес.

      country:

      Код ISO-3166 страны, в которой будет размещена сеть (см. выше)

      admin-c: и tech-с:

      В двух следующих строках Вам нужно определить ответственных лиц. В них Вы должны прописать идентификаторы (nic-handle), ссылающиеся на информацию о данных людях, содержащуюся в базе данных RIPE.

      status:

      Это поле подразумевает ASSIGNED PA или ASSIGNED PI.

      notify:

      Это поле очень полезное, хотя и необязательное. Если Вы проставите в этом поле e-mail адрес, на него будут приходить сообщения об изменениях (в том числе и несанкционированных) информации о Вашей сети в базе RIPE.

      mnt-by:

      Это поле, как и предыдущее, необязательно. Использование maintainer'а позволяеет защитить информацию о Вашей сети в базе RIPE при помощи различных способов авторизации. Как правило, это поле остается пустым или проставляется maintainer провайдера/Registry. (подробнее о maintainer'е см. здесь)

      changed:

      Здесь впишите e-mail адрес того, кто последний раз менял заявку и дату в формате <ггммчч>. Без разделительных точек! Например:

      changed: ovl@ripn.net 970915

      Обратите внимание на то, что при внесении последующих изменений (если потребуется) в данные, содержащиеся в базе RIPE, необходимо добавить новое поле changed:, а не заменять/удалять старое. Также существенно ставить дату именно того дня, в который производится изменение информации в базе данных RIPE

      source:

      Значение этого поля всегда одно - RIPE.

    8. #[PERSON TEMPLATE]#

      person:

      address:

      Сохраняйте пожалуйста, формат, требуемый ripe-142 при заполнении этих полей.

      phone:

      fax-no:

      e-mail:

      Порядок заполнения полей phone:, fax-no:, e-mail: обсуждался выше. Причем последние два являются необязательными, при наличии phone:.

      nic-hdl: Для того, чтобы получить nic-handle, Вам необходимо заполнить это поле так:

      nic-hdl: AUTO-1
      или так:
      nic-hdl: AUTO-1YourInitials

      причем, если в одной заявке Вы хотите получить 2 и более nic-hanl'а, используйте нумерацию AUTO-1, AUTO-2 и т.д.
      Если же nic-handle уже был присвоен Вам/Вашим абонентам ранее, Вы можете его использовать в полях admin-c: и tech-с: раздела #[NETWORK TEMPLATE]#, а раздел #[PERSON TEMPLATE]# можно не заполнять.

      notify:

      mnt-by:

      changed:

      source:

      Эти поля имеют тот же смысл, что и в предыдущем разделе.

to be continued ...

Last changes were made by ae@mark-itt.ru, ovl@ripn.net , bon@ripn.net , The first edition was by alkol@ripn.net