   |
RIPE-185 |
|
Европейская система регистрации
IP-адресов: Документ ID: ripe-185 26 октября 1998 г. Введение. В данном документе описывается Европейская
система регистрации распределения мирового
адресного пространства Интернет и ее
функционирование. особое внимание уделяется
общим директивам и правилам распределения
адресного пространства. Эти директивы и правила
касаются всего общественного адресного
пространства, выделяемого через Сетевой
координационный центр RIPE (RIPE NCC). Данный документ
не описывает private address space и multicast address space. Он также
не касается порядка распределения адресного
пространства сети Интернет другими
региональными регистратурами. Этот документ был
создан рабочей группой RIPE Local Internet Registry (LIR) при
содействии редакционного комитета,
представленного следующими именами: P. Caslav (RIPE NCC) 1.Обзор. Данный документ состоит из 8 основных частей следующего содержания. Часть 2 (Адресное пространство Интернета и система его регистрации) определяет различные типы IP-адресов и их предназначение. Здесь объясняются цели выделения адресного пространства и иерархическая природа регистрационной системы Интернета, необходимая для достижения этих целей. Указывается также главное различие между Provider Aggregatable address space и Provider Independent address space. Часть 3 (Процедура назначения адресного пространства) описывает порядок, которому должны следовать Европейские регистратуры при назначении адресного пространства пользователям. Главный упор делается на важности документального подтверждения этого процесса; дается детальное объяснение требуемой информации. Далее приводятся критерии и стандарты оценки запроса. Наконец, описывается выделение адресов регистратурой, как поэтапный процесс. Часть 4 (Allocations: правила и указания) показывает, как RIPE NCC выделяет адресное пространство регистратурам, следуя принципам эффективности и раноправия, и как данные об адресах становятся общедоступными в базе данных RIPE. Часть 5 (DNS и обратные адресные карты) говорит о роли RIPE NCC в регистрировании обратных зон и объясняет, как локальные регистратуры могут управлять регистрацией обратных зон для сетей, которым выделяются адреса. Часть 6 (Работа локальной регистратуры) описывает сферу услуг, предоставляемых RIPE NCC для обеспечения единства осуществляемой политики, изложенной в данном документе, и показывает порядок взаимодействия локальных регистратур с региональной регистратурой. Часть 7 (Политика и процедура назначения номеров автономных систем (AS)) объясняет, каким правилам должны следовать локальные регистратуры при назначении номера автономной системы. Часть 8 (Соглашения о внешнем роутинге - Interdomain (Exterior) Routing Consiserations). Здесь рассматриваются такие вопросы, как происхождение роутинговой информации, распространение анонсов, аггрегатрирование, регистрация маршрутов в базе данных и роль всех этих моментов при определении политики выделения адресного пространства, описанной в данном документе. 2.Адресное пространство Интернета и система его регистрации. 2.1.Типы IP-адресов Под IP-адресами в данном документе подразумеваются 32-битовые числа, используемые как адреса в протоколах IPv4. Существует 3 типа IP-адресов. Public addresses. Private addresses. 2.2.Общие принципы распределения адресного пространства. В предыдущей части документа мы говорили преимущественно об общественном (public) адресном пространстве, исключив из поля зрения private, special и reserved адреса. В дальнейшем мы будем следовать этому ограничению, придерживаясь определения адресного пространства, данного в разделе 2.1. Уникальность. 1.Aggregation (Аггрегатирование). 2.Conservation. 3.Registration (Регистрация). Следование этим принципам - в интересах всего сообщества Интернет. Aggregation и conservation часто противоречат друг другу, но это лишь означает, что выделение адресов должно быть каждый раз тщательно взвешено. Более того, вышеуказанные условия могут иногда не соответствовать интересам отдельных пользователей или провайдеров. В каждом подобном случае необходим тщательный анализ и взвешенный подход, чтобы найти приемлемый компромисс. Правила и рекомендации, изложенные в данном документе, помогут регистратуре и пользователям лучше понять друг друга. 2.3. Система регистрации в Интернете. Система регистрации в Интернете устанавливалась в соответствии с принципами, сформулированными выше. Она состоит из иерархически организованных регистратур Интернета (IRs). Адресное пространство пользователям назначается, как правило, локальными регистратурами (LIRs). Адресное пространство, выделенное (assigned) для конкретного пользователя, берется из блока адресов, выделенного (allocated) локальной регистратуре региональной регистратурой. Пользователи (end users) - это организации, которые используют выделенное им адресное пространство для работы своих сетей. Адреса могут быть запрошены также консультантами, действующими в интересах своих организаций. Как правило, локальными регистратурами управляют сервис-провайдеры. Assigned (выделенное пользователям) адресное пространство непосредственно используется в сетях, тогда как allocated (выделенное регистратурам) адресное пространство предназначено для будущего выделения адресов по мере поступления заявок от пользователей. Первое находится в ведении пользователей, второе - в ведении регистратур. Выделять адреса организациям-пользователям могут только регистратуры. IANA. IANA - The Internet Assigned Numbers Authority (Упраление назначением адресов в Интернете) ведает всем адресным пространством сети Интернет, включая IP-адреса. IANA назначает адресное пространство региональным регистратурам, в соответствии с их потребностями. Региональные регистратуры (RIRs). Региональные регистратуры действуют в пределах больших геополитических регионов, таких как континенты. В настоящее время существует три региональных регистратуры: ARIN(Северная Америка), AP-NIC (Азиатско-Тихоокеанский регион) и RIPE (Европа). Поскольку геополитический принцип не до конца соблюдается, региональные регистратуры обслуживают также часть пространства за пределами своих континентов. Предполагается, что в дальнейшем количество региональных регистратур останется небольшим. Региональные регистратуры учреждены под руководством IANA. Это требует консенсуса внутри регионального сообщества. Особенно это касается провайдеров. В обязанности региональной регистратуры входит координация и представительство локальных регистратур данного региона. Локальные регистратуры (LIRs). Локальные регистратуры устанавливаются под руководством региональной регистратуры. Они управляются, как правило, провайдерами и обслуживают как своих клиентов, так и клиентов более мелких провайдеров, подключенных через них к Интнрнету. Крупные предприятия, международные компании также часто становятся регистратурами. Большая часть данного документа касается процесса назначения адресного пространства как главной обязанности LIR. В некоторых случаях локальная регистратура, назначающая адресное пространство, не управляется провайдером, который будет обеспечивать подключение. Как уже было сказано, выделять адресное пространство пользователям могут только регистратуры. Пользователи (end-users). Строго говоря, пользователи не являются частью регистрационной системы. Однако они играют важную роль в осуществлении принципов, обозначенных нами как aggregation и conservation. К примеру, следуя принципу консервации, они должны стараться использовать минимальное количество адресного пространства при планировании устройства своих сетей. Они должны представлять документацию на свои адреса, как имеющиеся, так и планируемые, а также всю дополнительную информацию для принятия регистратурой решения о выделении адресов. Принцип аггрегатирования требует, чтобы пользователь выбирал наиболее подходящую для себя регистратуру. Пользователи дожны знать, что смена провайдеров может означать смену адресов в их сетях. Наконец, они должны своевременно представлять информацию об изменениях в их адресном пространстве. Requesters. В дополнение к этим ключевым фигурам регистрационной системы Интернета, существуют также консультанты, которые устанавливают и обслуживают сети пользователей. Они могут быть как работниками организации-пользователя, так и приглашенными лицами, действующими в интересах какой-либо организации. В любом случае лицо, делающее запрос (request), будет являться requesterом. Европейская система регистратур. Иерархия Европейской регистрационной системы строится таким образом (сверху вниз): IANA, RIPE NСС, LIRs. 2.4.Provider Independent vs Provider Aggregatable Addresses (Независимое и аггрегированное адресное пространство). Provider Aggregatable (PA) address space (Аггрегатированное адресное пространство). Локальные регистратуры, управляемые сервис-провайдерами, располагают PA-адресным пространством, которое они выделяют пользователям. Это делается таким образом, чтобы сведения о маршрутизации для многих пользователей данного провайдера могли быть объединены в пределах домена этого провайдера. Это позволяет сохранять минимум маршрутов как между пользователями, так и между провайдерами. Оперирование аггрегатированной таблицей для роутера значительно дешевле, чем оперирование подробной таблицей роутинга, включающей каждую пользовательскую машину. Если пользователь меняет сервис-провайдера, должно быть изменено и РА-адресное пространство. В этом случае потребуется переконфигурирование всех хостов и routerов организации-пользователя. Организация должна будет получить новые адреса, а прежние - вернуть. Регистратура должна иметь четкое соглашение с пользователем о том, что договор об адресном пространстве становится недействительным, и подключение к Интернет с использованием прежних адресов будет прекращено сразу же или через некоторое время. Цель подобного соглашения состоит в уменьшении нагрузки на систему глобального роутинга. Если организация продолжает использовать прежние адреса, подключившись к другому провайдеру, информация о ее роутинге не может быть аггрегатирована: она потребует отдельного маршрута в общесетевом роутинге. Provider Independent (PI) Addres Space В противоположность адресам РА, адреса PI могут оставаться у пользователя до тех пор, пока сохраняются основания для их выделения. Срок действия этих адресов не зависит от услуг конкретного провайдера. Очевидное Преимущество PI-адресов состоит в том, что при переходе к другому провайдеру пользователь не дожен переконфигурировать хостtы и роутеры. Однако маршрутизация адресов PI достаточно дорогая. Раньше в Интернете существовали только адреса PI. Многие адреса, выделенные локальными регистратурами, по-прежнему остаются формально PI-адресами из-за того, что в свое время регистратура не заключила с пользователями договор о сроках их действия. Срок действия договора о выделении адресов. Этот срок продолжается до тех пор, пока действуют критерии выделения адресного пространства. Если адреса были выделены для какой-либо цели, они действительны до тех пор, пока эта цель существует. Процедура выделения адресного пространства. 3.1 Введение. В этой главе описаны процедуры, которые должна выполнять локальная регистратура при выделении адресного пространства. В начале говорится о том, какая информация должна быть представлена пользователями. Сбор информации служит двум целям: принятию решения о выделении адресов, с учетом принципов aggregation и conservation, и регистрации. Далее мы рассматриваем, как эта информация должна быть оценена для принятия правильного решения, и приводим дополнительные критерии оценки. Наконец, определяем порядок назначения адресов, которому локальная регистратура должна следовать. Прежде чем углубляться в подробности этого процесса, наметим общие положения и политику, определяющие характер требуемой информации и порядок ее оформления. Регистратура выделяет адресное пространство пользователю в соответствии с его заявкой, в которой описана структура его сети. Регистратура гарантирует, что адресное пространство, назначенное пользователю, сохраняется за ним в течение всего срока назначения и не может быть передано другому пользователю до истечения этого срока. В соответствии с принципом "conservation" пользователям не разрешается резервировать адресное пространство. Решение о выделении адресного пространства должно быть основано на документации о его предполагаемом использовании в течение 1-го и 2-го года с момента подачи заявки, как это указано в адресном плане, и об использовании его в настоящее время (о чем говорится в следующей главе). Количество выделяемого пространства должно быть обосновано в этой документации. Для принятия решения о выделении дополнительных адресов необходимо, чтобы организация представила свдения об использовании адресов, выданных ей ранее. Решение о новом выделении принимается лишь в том случае, когда в них есть насущная необходимость, подтвержденная документально. 3.2.Документация. Для принятия правильного решения о выделении адресов должны быть собраны сведения об организации, о характере запроса, инфраструктуре сети, использовании имеющихся и запрашиваемых адресов. Часть информации является обязательной; другая ее часть может оказаться полезной для принятия решения о выделении адресов, хотя формально не требуется. Для оформления заявки RIPE NCC предлагает набор форм, которые надо заполнить, и инструкции по их заполнению. Хотя использование формы заявки настоятельно рекомендуется, каждая локальная регистратура, выделяя адреса в пределах своего AW (Local IRs Assignement Window - cм. раздел 3.6. данного документа), может составлять эту информацию наиболее удобным для себя способом, на родном языке. При этом обязательно должны быть представлены данные об использовании имеющихся адресов и адресный план запрашиваемой сети, включающий точное описание, какая подсеть для чего предназначена. Если RIPE NCC запросит эту информацию, она должна быть представлена в переводе на английский язык. Заявки, которые требуют утверждения RIPE NCC, должны быть оформлены в полном соответствии с ныне действующей версией European IP Address Space Request Form, описанной в ripe-141 [Caslav96a]. Каждая заявка заполняется одним пользователем: должно быть понятно, кому предназаначены выделяемые адреса. Коллективные заявки от A,B,C (например) не принимаются. Информация, полученная от пользователей для выделения адресов, должна постоянно поддерживаться локальной регистратурой и представляться в региональную регистратуру по первому ее требованию. Локальная регистратура отвечает за конфиденциальность этой информации. Все, что не предназначено для публикации в базе данных регистратуры (см. далее, пункт 3.2.1.5), должно держаться в строгом секрете. Локальная регистратура не уполномочена предоставлять информацию без согласия абонента никому, кроме представителей IANA и региональной регистратуры. 3.2.2. Требуемая информация. Каждая заявка должна содержать следующую информацию, необходимую как для решения о выделении адресов, так и для глобального поддержания адресных данных. За исключением части информации, описанной в пункте 3.2.1.2, все ниже сказанное относится к запрашиваемому адресному пространству. 3.2.1.1. Сведения об организации. Для наилучшего удовлетворения запроса какой-либо организации важно понять ее структуру и то, как будут в ней рапределяться адреса. Представим себе следующую ситуацию. Одно Бельгийское предприятие, производящее велосипеды, имеет различные отделения: производственные цеха, торговый отдел, отдел исследования и развития и т.п. Крупные подразделения - производственный отдел, торговый отдел и т.д.- подчиняются Центральному управлению, тогда как цеха по производству цепей, педалей, вилок и т.д. подчинены проиводственному отделу. Когда приходит заявка на выделение адресов, мы должны знать, какая часть организации будет их использовать. Предположим, что адреса были нужны производственному отделу для своих цехов. Если вскоре после этого будут запрошены адреса, скажем, для цеха по производству педалей, надо учесть, что адреса, выданные ранее, должны были покрыть потребности этого цеха. Подобная же ситуация может сложиться, если торговый отдел имеет группы представителей в других странах. Важно знать, будут ли выделенные адреса использоваться в Антверпене или Мадриде. Мы должны воспрепятствовать тому, чтобы адреса для одной и той же подсети запрашивались разными подразделениями одной организации. Тот факт, что одно подразделение расположено одновременно в разных, отдаленных друг от друга, местах, должен быть учтен регистратурой. Для этого вводится в качестве обязательного пункта Overview of Organisation. Оно должно включасть в себя сведения о главной компании, дочерних предприятиях или отделах и о контактных лицах. В случае с нашим производителем велосипедов необходимо, чтобы одно контактное лицо предоставляло информацию о структуре сети предприятия в Бельгии, и контактные лица по каждому из отделов (производственному, торговому и т.д.). Одно и то же контактное лицо не может предоставлять информацию, скажем, об отделе торговли, скажем, в Бельгии и в Риме. Понятно, что процесс обработки заявок значительно упрощается, если запросы на адреса для отдельных подразделений организации координируются и представляются одним ответственным контактным лицом от имени всей организации. Чтобы облегчить обработку запроса, требуется контактная информация о лице, делающем запрос, и о лице, представляющем организацию-пользователя. Эта информация должна быть указана в шаблонах Requester template и User Template, соответственно: имя, организация, страна, телефон, факс, e-mail. Номера телефона и факса должны включать полный международный код, начинающийся знаком плюс. Имя должно быть указано полностью. Контактная информация необходима только в целях облегчения обработки запроса. Она может включать, может не включать данные о контактных лицах, которые затем войдут в базу данных RIPE. 3.2.1.2.Current Assignement Space Usage В соответствии с принципом "conservation", необходимо иметь информацию об использовании уже имеющегося адресного пространства. Располагая этой информацией, мы можем избежать назначения нового адресного пространства там, где уже имеющееся может полностью удовлетворить потребности пользователя. Текущее использование этих адресов должно быть представлено в виде таблицы, подобной приведенной ниже. Каждая отдельная подсеть должна быть показана отдельной строкой. Подсети считаются отдельными, если между ними есть IP-роутер. Prefix Subnet Mask Size Current 1yr 2yr Description 193.1.193.0 255.255.255.192 64 28 34 50 Derailer 193.1.193.64 255.255.255.224 32 10 12 15 Chain(dynamic dial-up) 193.1.193.96 255.255.255.224 32 8 13 17 Front Fork 193.1.193.128 255.255.255.128 128 57 100 114 Main Office 193.1.194.0 255.255.255.0 256 132 170 210 Frame 193.1.195.0 255.255.254.0 512 317 350 380 Assembly LAN 1024 549 679 806 Totals
Каждая строка таблицы складывается из полей, показывающих использование адресного пространства в настоящее время и в течение предстоящих 1-го и 2-го года. Поле Description дает краткое, но семантически значимое описание роли подсети в организации пользователя. (В нашем примере оно относится к цехам по производству различных частей велосипеда). Вместе с указанием размера подсети Size оно дает полное представление о структуре сети организации. Количество интерфейсов в подсети в настоящее время вместе с количеством, которое потребуется в ближайшие 2 года, также должно быть указано: Current, 1yr, 2yr. Cюда входит количество интерфейсов для хостов, роутеров, шлюзов, принтеров и др., требующих одного или более сетевых интерфейсов. Поле Size служит дя указания размера подсети, которое определяет максимальное количество интерфейсов сети, которые могут быть объединены в одну подсеть. Это число должно быть степенью чиса 2 и, конечно, больше или равно количеству, указанному в поле 2yr. Если в заявке указано меньше, это должно быть объяснено. Поле Subnet Mаsk должно указывать на это; а в префиксном поле должно стоять то число, с которого адреса этой подсети начинаются. Так же, как и в приведенном нами примере, следует указать адресное пространство, которое в данный момент не используется. 3.2.1.3. Request Overview. Эта информация нужна для того, чтобы быстрее определить характер запроса, исходя из его размера. Для этого необходимы следующие сведения: Size of Request - Общее количество запрашиваемых адресов. Если это количество равно 512, пользователь должен мотивировать его необходимость. Раньше, до появления Сlassless Inter-Domain Routing (CIDR), пользователь в этом случае должен был бы запросить 2 класса С. Поскольку теперь существуют classless адреса, размер запроса может быть меньше 256 или вовсе выходить за пределы класса (32, 288, 384). Более подробно о CIDR см. (RFC 1519 [Fuller93a]) и (RFC 1518 [Rekhter93a]). Addresses to be Used. Чтобы получить представление о структуре будущей подсети, надо знать, сколько адресов будет задействовано в различные периоды времени. Соответствует количеству интерфейсов. В полях addresses-immediate, addresses -year-1, addresses-year-2 указывается, какое количество адресов будет использоваться сразу после их получения, через год и через два года. Number of subnets (Количество подсетей). Вместе с данными о количестве адресов, эта информация помогает представить общую инфраструктуру сети. Здесь также должны содержаться данные об использовани подсетей в текущем году, через год и через два года. Internet connection (Подключение к Internet).Прежде чем назначать IP-адреса, важно знать, был ли данный пользователь подключен к Internet. Если был, то выбор подходящего (appropriate) адресного пространства для этого пользователя может зависеть от того, какой провайдер или провайдеры его обслуживают в данный момент. Если пользователь не был раньше подключен, но собирается это сделать, это также необходимо отметить. Информация о подключении к Internet важна для "aggregation" и "conservation" адресного пространства в общественной сети. Подключение к Internet, как существующее, так и планируемое, указывается в поле inet-connect. Country. Страна должна быть указана с использованием 2-буквенного кода ISO 3166. Если код неизвестен, должно быть указано полное название страны. Private address Space. Использование "private"-адресов соответстсвует принципу "conservation". Пользователи должны быть информированы о том, что они могут их получить, в особенности если не все хосты их сети требуют подключения к Internet. Пользователи не обязаны запрашивать именно "private"-адреса, даже если это для них лучший вариант. Важно, чтобы они знали о возможности такого запроса. В пункте Private address space пользователь должен указать, могут ли такие адреса быть использованы в его сети. Request refused. Здесь надо отметить, было ли когда-либо отказано организации в получении IP-адресов. Если да, то по какой причине и в какой регистратуре. PI Requested. Если поступает запрос на Provider Independent (независимое) адресное пространство, регистратура должна предпринять особые шаги при его обработке. Пункт PI Requested указывает на это. Address Space Returned. Если пользователь возвращает адресное пространство в обмен на новое,RIPE NCC должен быть поставлен в известность. Эта информация должна быть указана в данном пункте. 3.2.1.4.Addressing Plan. Чтобы обеспечить соответствие выделяемого адресного пространства реальным нуждам пользователя, необходим адресный план. Он дает подробную информацию о том, как будет использовано полученное адресное пространство. Так же, как Addresses Used (см. 3.2.1.2), адресный план представляет собой таблицу, в которой указаны все адресные сегменты сети пользователя. Эта таблица почти полностью аналогична предыдущей. Addresses Used #Relative Prefix# Subnet Mask Size Immediate 1yr 2yr Description 0.0.0.0 255.255.255.192 64 8 16 60 Systems Groups (back-bone, dynamic dial-up) 0.0.0.64 255.255.255.224 32 17 22 26 Engineering 0.0.0.96 255.255.255.224 32 12 17 20 Manufacturing 0.0.0.128 255.255.255.224 32 10 15 27 Sales 0.0.0.160 255.255.255.240 16 5 9 12 Management 0.0.0.176 255.255.255.240 16 7 8 13 Finance 192 59 87 158 Totals Должно быть указано количество интерфейсов в сети для использования в настоящее время, а также в ближайшие 1 и 2 года. В поле Relative Prefix указывается относительная позиция в назначенном адресном пространстве, с которой адреса этой подсети будут начинаться. В первой подсети это всегда 0.0.0.0. В каждой следующей подсети начальная позиция соответствует общему количеству хостов в поле Size предшествующей подсети. В целях экономии адресного пространства начальные позиции подсетей должны выбираться так, чтобы можно было свести к минимуму перегрузку сети. В примере, приведенном выше, мы расположили ряды в порядке убывания в поле Size. Эта схема наиболее приемлема в смысле избежания траты адресного пространства между подсетями. Общее количество запрашиваемых адресов должно быть равно их общему количеству в подсетях (Totals) в адресном плане. В настоящее время возможно использование "classless" адресов. Это означает, что подсети могут быть любого размера. Если существуют какие-либо технические ограничения в использовании определенных диапазонов адресов или выборе оптимальных размеров подсети, они должны быть подробно указаны: характер ограничения, модель и версия аппаратного и программного обеспечения, являющиеся их причиной, а также их точное местонахождение в сети. В тех случаях, когда в заявке на целый класс (-ы) много адресов растрачивается впустую, заявка не удовлетворяется. 3.2.1.5. Информация для базы данных (Database Information) Для регистрации необходимы сведения об организации, приславшей запрос, и о ее контактных лицах. Часть этой информации может оказаться избыточной, поскольку одно и то же лицо может выступать в нескольких ролях. Тем не менее, каждая роль требует отдельного исполнителя, так чтобы информация была представлена полностью. Данные, о которых пойдет речь ниже, должны быть собраны локальной регистратурой и помещены в базу данных RIPE NCC; с этого момента они становятся общедоступны. (Более подробно о базе данных RIPE NCC см. (ripe-157[Magee97a]) Organisation. Краткая информация об организации, которая будет использовать адреса, помещается в базу данных RIPE. Для этого заполняется Network Template. Поле inetnum должно быть оставлено пустым; в нем будут проставлены IP-адреса. Чтобы облегчить их идентификацию в базе данных RIPE, в поле netname надо указать имя сети. Необходимо краткое описание организации, получающей адреса; оно помещается в 1 или более полях описания в Network Template. (Если, к примеру, адреса предназначены для кафедры нейрохирургии Кататонского Государственного университета, названия кафедры и университета могут быть указаны в двух полях описания (descr fields). Код страны ISO 3166 должен быть указан в поле country. Если код неизвестен, следует указать полное название страны. В полях admin-c и tech-c указывается NIC handle административного и технически-ответственного контактного лица. Административным лицом может быть только сотрудник организации; знание технических вопросов, связанных с обслуживанием сети, для него не является обязательным. Что касается технически-ответственного лица, то им может быть как постоянный сотрудник данной организации, так и приглашенное лицо. В этих полях можно указывать как по одному, так и более лиц. В поле tech-c можно указать role-object вместо person-object. Каждое контактное лицо должно иметь собственный NIC handle - уникальную запись в базе данных. Если имя контактного лица уже содержится в базе данных, необходимо указывать его NIC handle (идентификатор). Если не содержится, то его можно получить через заявку на адреса. См. ripe-157 [Magee97a] для получения дальнейшей информации по получению NIC handle. Если лицо имеет NIC handle, оформленный в б/д ARIN, оно может использовать его при обращении в б/д RIPE. В целях безопасности в пункте notify можно указать e-mail адрес, чтобы получать извещения об изменениях объекта в б/д, а в пункте mnt-by указать maintainer object, который определяет, кто имеет право вносить изменения в б/д. Personal Data. Необходима полная информация о контактных лицах, с которыми можно связаться при обработке запроса. Эти данные могут быть опущены, если такая информация уже содержится в базе данных RIPE и до настоящего времени не изменялась. Если в б/д вносится новая информация о новом контактном лице, это будет рассматриваться как обновление данных, и они будут переписаны. В Person Template указывается полное имя лица, его e-mail адрес; телефон и факс даются с указанием полного международного кода. Если лицо имеет идентификатор, его надо указать в поле nic-hdl. Как и в Network Template, в пункте notify надо указать e-mail адрес для сообщения об изменениях сведений об объекте в б/д RIPE и записать в пункте mnt-by имя лица, имеющего право вносить изменения. Порядок подачи информации. В Network Template и Person Template оставлено место для идентификации контактного лица в б/д регистратуры. В поле changed должен быть указан e-mail адрес заявителя, вместе с датой подачи заявки. Впоследствии, при внесении изменений в этот темплейт, первоначальная запись в поле changed должна сохраниться, вместе с новой записью, поскольку в ней указана первоначальная дата оформления сети. Поле source используется для указания базы данных регистратуры, где будет находиться информация о данном пользователе. В нашем случае это всегда RIPE. 3.2.2. Дополнительная информация. Дополнительная информация (Additional information) может оказаться полезной при оценке поданной заявки; иногда она даже запрашивается регистратурой. Развернутый план (Deployment plan). Предположим, мы имеем дело с новой организацией, желающей подключиться к Internet, которая запросила адреса в количестве 4000. В таких случаях может быть потребован развернутый план. В нем должны быть указаны причины, требующие именно такого количества адресов, и указаны даты, когда эти адреса будут использоваться. Это дает возможность понять, насколько реалистичны требования данного клиента. Топологическая карта (Topological Map). Здесь уместно вспомнить старую поговорку о том, что лучше раз увидеть, чем сто раз услышать. Топологическая карта инфраструктуры сети, как действующей, так и планируемой, может дать наиболее ясное представление об этой сети, особенно в соединении с адресным планом и таблицей использования имеющихся адресов. Карта может выслана как постскрипт-документ или по факсу (в этом случае просим включать ticket number заявки (см. 6.3). Special circumstances (особые обстоятельства). Иногда вследствие использования оборудования специального назначения или старых систем оказывается невозможным использование "classless" адресов. В этом случае следует сообщить об особенностях аппаратного или программного обеспечения, которые вызывают трудности. Полезно также указать, как долго еще будет использоваться это оборудование. Verification Information (Проверка информации). Когда заявку составляют пользователи, не имеющие достаточного опыта в работе с сетями, бывает трудно определить, насколько реалистичны его планы. В таких случаях бывает полезно запросить информацию, которая подскажет, в какой мере пользователь осведомлен в вопросах работы сети. Прежде всего надо спросить, как он представляет себе адресный план, и где он почерпнул эти сведения. Другим показателем его осведомленности является описание используемого адресного пространства. 3.3.Оценка запроса (Evaluation) Собрав всю вышеуказанную информацию, мы должны принять решение о выделении адресов, учитывая принципы "aggregation" и "conservation", о которых говорилось в 1 главе. Каждая заявка требует индивидуального рассмотрения с точки зрения ее соответствия существующим правилам. Решая, сколько адресов и какого типа будет выделено, следует помнить, что регистратура должна препятствовать их чрезмерному накоплению в руках одного пользователя. Использование"classless" адресов соответствует принципу "conservation". В то же время, обспечивая должную маршрутизацию, следует помнить об "aggregation". Эти положения определяют общий подход к оценке запроса. Оценка запроса (Evaluation) складывается из следующих этапов: 1.Current address space usage. Вначале надо сверить информацию пользователя о его адресном пространстве с подобной информацией других источников, доступных регистратуре. После сверки следует посмотреть, нет ли резерва IP-адресов у данного пользователя. 2.Network Overview. Далее надо сравнить общее количество запрашиваемых адресов с количеством адресов в данный момент и через 1 и 2 года. Здесь мы оцениваем пропорциональность их использования. Addresses-immediate должны составлять не менее 25% адресного пространства, addresses-yr-1 - не менее 50%. 3. Private Address Space. Если в сети данной организации могут быть использованы private адреса, надо ее об этом информировать. Ответ нет должен означать сознательный отказ. При этом пользователь должен знать, что, имея private адреса, он может значительно увеличить свое адресное пространство. 4.Very Small Enterprices (Очень маленькие организации). Организации, имеющие небольшое количество хостов (currently <24), получают "classless" адреса. Как и во всех других случаях, здесь следует избегать выделения большего адресного пространства, чем реально необходимо. Сети каждой из малых организаций должны быть оформлены в б/д отдельно. Организациям с небольшой сетью, не имеющим намерения подключаться к Internet, не следует назначать public адреса; им надо посоветовать использовать private адреса. Это особенно касается малых организаций, которые запрашивают PI-адреса в расчете на подключение к Internet в будущем. Им надо объяснить, что, получив private адреса, они почти не будут иметь проблем с перенумерацией. 5.Адресный план (Addressing plan). Во-первых, надо сверить общее количество имеющихся адресов в данный момент, через 1 и 2 года с цифрами, указанными в Overview. Затем проверить, соответствует ли маска размеру подсети. Иногда адресное пространство можно сэкономить, используя другую маску. В этом случае надо попросить пользователя переделать адресный план. В принципе, не должно быть большого расхождения между количеством адресов, которые запрашиваются, и тем, кототрое будет использовано. 6.Дополнительная информация (Additional information). Полезна любая информация, дающая представление об использовании адресов данной организацией. Это может быть план использования адресов, топологическая карта и др. - для сравнения их с адресным планом. 7. Резервирование адресов. Выделение адресов должно быть основано на реалистических ожиданиях. Пользователям не разрешается создавать резерва адресов для осуществления каких-либо долгосрочных проектов. Создание таких резервов в принципе бесплодно, поскольку в отдаленном будущем их количество, скорее всего, окажется либо излишним, либо недостаточным. 8. Static Dial-up (Абоненты Dial-up с фиксированными адресами). В связи с напряженностью со свободным пулом IPv4 адресов, использование фиксированной IP-адресации (один адрес на одного абонента) крайне нежелательно. Понятно, что такое использование адресов облегчает деятельность администрации; тем не менее, современная норма потребления адресного пространства не позволяет выделять адреса для подобной цели. Организации, использующие такие фиксированные адреса, должны искать пути для применения технологии динамического выделения адресов. Если все же фиксированная адресация необходима, это потребует проверки и специального разрешения. Для уточнения деталей обратитесб в RIPE NCC. 9. Virtual Hosts. Иногда для одного хоста на одном интерфейсе в одной сети назначается два и более адресов. Это делается для устранения дефектов в протоколах верхних уровней, таких как HTTP. Выделение большого диапазона для таких целей нежелательно по причинам, указанным выше. В настоящее время RIPE NCC выдает адреса для виртуальных серверов при условии, что эти адреса будут возвращены или использованы в других целях, когда будет широко применяться версия HTTP, использующая хостовую часть URL. Если выделение адресов для вышеозначенной цели и происходит, требуются некоторые специальные процедуры. Для уточнения деталей обратитесь в RIPE NCC. 3.4. Процедура выделения адресов. Теперь обратимся к конкретному описанию процесса выделения адресов, исходя из того, что мы собрали всю необходимую информацию и дали ей оценку. 3.4.1.Выделение адресов из блока LIR. Как только регистратура убедилась, что запрос заслуживает удовлетворения, она выбирает соответствующий диапазон адресов. Если адреса выделяются из блока регистратуры, она должна позаботиться об избежании фрагментации своего адресного пространства. Важно, чтобы каждый набор адресов начинался на границе CIDR (bit). Это означает, что начальные номера каждого диапазона адресов должны делиться без остатка на размер диапазона. Это соответствует принципу аггрегатирования. Предположим, что запрос может быть удовлетворен либо определенным количеством небольших отрезков адресов, либо одним большим. Например, если это запрос на 384 адреса (а в одной подсети не может быть больше 256), то выделяются /24 и /25, а не /23 - что позволит сэкономить следующий /25 для очередного запроса. В таких случаях предпочтительнее выдавать адреса частями. Так надо поступать всякий раз, когда есть возможность сэкономить адресное пространство. RIPE NCC всегда приветствует желание локальных регистратур обратиться за советом по выделению адресов. В некоторых случаях требуется подтверждение NCC, даже если выделяемое пространство берется из блока локальной регистратуры - например, если размер запроса выходит за пределы разрешенного для выделения локальной регистратурой. Максимальный размер запроса, который локальная регистратура может удовлетворить, зависит от размеров AW локальной регистратуры (Local IRs assignement window) - cм. раздел 3.6. данного документа. Если требуется выделить адреса из диапазона, который не принадлежит данной локальной регистратуре, пользователь должен обратиться к той регистратуре, которой он принадлежит. Это может быть и региональная регистратура. 3.4.2. PA и PI адресное пространство. Критерии выделения количества адресов одинаковы для запросов на РА и PI адреса. Например, и в том, и в другом случае может быть выделен диапазон /24 при запросе менее чем на 256 адресов. Локальная регистратура должна объяснить пользователю, какой тип адресов ему выделяется. В договоре на PA адреса должны быть обязательно указаны сроки их использования. То же желательно и для PI адресов, хотя это строго не требуется. Исходя из принципа аггрегирования, регистратуры должны, где только возможно, разъяснять преимущества использования РА-адресов и советовать пользователям выбирать именно этот вариант, если он подходит к их условиям. Различие между PA и PI адресами должно быть понятно пользователю. Для того, чтобы преимущество РА-адресов стало еще более очевидно, имеет смысл обратиться к пользователям с предупреждением наподобие следующего: Ваши адреса действительны до тех пор, пока действуют причины их выделения и пока остается в силе Ваш договор с сервис-провайдером. Провайдер имеет право передать Ваши адреса другому пользователю после окончания срока договора или спустя некоторое время. Если адреса становятся недействительными, Вы, очевидно, должны будете переконфигурировать все оборудование, использующее эти адреса. Переконфигурация необходима лишь в том случае, если Вы будете настаивать на сохранении уникальности IP-адресов для каждой машины. Важно понимать, что услуги, предоставляемые Internet, не всегда требуют уникальных адресов. Например, услуги, которые можно получить через NAT (Network address translator) или через брандмауэр, и пр. Разумеется, ограничения при использовании PI-адресов, также должны быть понятны. Здесь возможно такое предупреждение: Ваши адреса действительны до тех пор, пока действуют причины их выделения. Надо заметить, что получение PI-адресов не означает, что Вам будет доступна любая часть Internet. Маршрутизация этих адресов, возможно, потребует дополнительной платы. Со временем маршрутизация сравнительно небольшого PI-пространства в Internet может оказаться невозможной. Мы настоятельно советуем Вам выяснить у своего будущего провайдера, какие услуги могут быть предоставлены Вам при использовании PI-адресов и за какую плату. Тип назначенных адресов должен быть отмечен регистратурой в соответствующей строке заявки для б/д RIPE: ASSIGNED PA или ASSIGNED PI - в зависимости от того, какие адреса будут назначены пользователю. Все вновь назначенные адреса должны иметь пометку PI или РА в базе данных RIPE. Более того, желательно, чтобы регистратуры сделали такую пометку и для давно назначенных адресов. Адреса без такого указания по умлолчанию считаются PI-адресами. Поэтому особенно важно, чтобы были отмечены РА-адреса. Как правило, локальные регистратуры располагают РА адресами, которые они и выделяют пользователям. Если пользователь запрашивает адреса другого типа (как правило, PI), регистратура должна направить его в ту регистратуру, которая может удовлетворить его запрос. Если локальная регистратура хочет посодействовать кому-либо в получении адресов, которыми она не располагает, она должна обратиться к другой регистратуре, которая оказывает такие услуги. Она помогает своему клиенту оформить запрос и представить основную необходимую информацию в подходящую для него регистратуру, которую она же и подберет для него. Локальные регистратуры, которые, как правило, не имеют большого адресного пространства определенного типа (опять, скорее всего, PI), не обязаны его получать. Такие адреса могут быть запрошены в RIPE NCC, если это потребуется. Главная суть в том, что это неаггрегатируемые адреса. 3.5. Замена IP-адресов. Многие адреса, назначенные в прошлом, впоследствии были аггрегатированы, хотя формально они не относятся к типу РА. Формально адреса не относятся к типу РА, если это не отмечено в договоре, определяющем их предназначение и срок действия. Поэтому локальным регистратурам рекомендуется обращаться к пользователям с просьбой освободить не-РА адреса после окончания срока договора. Подобным же образом, если пользователь обращается к новой регистратуре за получением услуг, она должна убедить его отдать не-РА адреса, если такие у него имеются, и запросить адреса другого типа (новые регистратуры делают это охотно). Чтобы сделать использование PI-адресов минимальным в будущем, регистратуры должны заключать контрактные соглашения, формально превращающие аггрегатированные адреса в РА-адресное пространство. В то время как процедура нумерации и перенумерации хостов в IP сети все более упрощается, пользователи не всегда охотно откликаются на предложение о перенумерации. Процесс перенумерации обычно требует много времени и усилий как от пользователей, так и от провайдеров и локальных регистратур. В тех случаях, когда налицо явное желание поменять адреса, локальные регистратуры должны всеми силами этому содействовать. Наиболее важны случаи намерения пользователей заменить PI адреса, которые, в силу историчсеких причин, распределялись беспорядочно и не могут быть аггрегированы в РА адресное пространство. Такие замены играют важную роль в поддержании растущего числа маршрутизационных таблиц, что благоприятно для Internet в целом. Поскольку процесс перенумерации непрост, вся регистрационная системи Internet должна его поддерживать, насколько это возможно. В течение периода перехода на новые адреса могут возникнуть осложнения. В большинстве случаев может потребоваться связь с двумя или несколькими провай дерами, старые и новые адреса придется использовать параллельно. Помня о принципах "aggregation" и "conservation", а также о необходимости минимизировать дублирование материально-технического обеспечения, надо сделать этот период как можно менее продолжительным. Процедура замены IP-адресов. Как правило, замена производится по принципу один к одному. Замена PI-адресов на РА-адреса производится, если все еще действуют критерии их выделения, и если заменяемое адресное пространство продолжает использоваться в сети организации. В случае, если большой процент адресов (50% или же более 4096 адресов) не используется, организация должна будет представить всю необходимую документацию в новую регистратуру. Эта документация будет рассматриваться как обычная заявка на выделение дополнительного адресного пространства. Адреса, которые будут заменены (отдельные диапазоны и общее количество), должны быть соответствующим образом оформлены в соответствии со стандартом заявки на адреса; копия должна быть выслана регистратуре или регистратурам, выдавшим адреса, которые заменяются. Прежде чем назначить новые адреса, следует заключить соглашение, где будет указан срок возврата адресов выдавшей их регистратуре. По окончании замены адресов новая информация должна быть занесена в базу данных. Когда предполагается замена большого количества адресов (/20 и более), Региональная регистратура должна быть об этом информирована, как и о соглашении о максимальном периоде днйствия параллельных адресов. В самых сложных случаях она может решить отслеживать процесс замены. Замена адресов должна произойти в течение 3-х месяцев. RFC 2008 "Implications of Various Address Allocation Policies for Internet Routing" [Rekhter96a] рекомендует период от 30 дней до 6 месяцев. В исключительных случаях, когда пользователь просит 6 месяцев и более, необходимо разрешение RIPE NCC. Если адреса назначались не локальной регистратурой или регистратурой, которая больше не существует, их полномочия берет на себя Региональная регистратура. 3.5.1. Multihomed Users. Организация может иметь причины подключаться к Internet более чем через одного провайдера. В таком случае она может иметь основания получить адреса более чем от одной регистратуры для поддержания разных частей своей сети. Сеть этой организации будет называться multihomed. В таких случаях регистратуры должны быть особенно внимательны при рассмотрении заявок, особенно в части использования имеющегося адресного пространства (см. 3.2.1.2). Необходимо проконтролировать, чтобы пользователи не затребовали нескольких блоков адресов от разных регистратур для одной и той же части сети. Более того, следует удостовериться, что другая регистратура не отказывала данному пользователю в выделении адресов по какой-либо серьезной причине. 3.6. Информация для базы данных (Update the RIPE Database) Регистрация объектов, подлежащих занесению в б/д RIPE, дает возможность отслеживать использование адресного пространства, облегчает оперативные контакты и изучение возможностей выделения адресов локальным регистратурам. Эта деятельность очень важна для работы Internet. Занесение в базу данных - последний этап процесса выделения адресов. Он придает окончательную определенность этому процессу и делает информацию о новых назначениях адресов общедоступной. Поэтому необходимо обеспечить точность этой информации. Если количество выделяемых адресов превышает размеры AW (assignement window - см. 3.7.), локальная регистратура должна получить подтверждение RIPE NCC, прежде чем заносить объект в б/д. На основании данных о пользователе, собранных в Network Template (см. пункт 3.2.1.5), создается inetnum object базы данных. В него входит также диапазон выделенных адресов в виде 4-х целых чисел, разделенных точками. Например, если организация получает диапазон /22, состоящий из 1024 сетевых адресов, запись будет подобна следующей: 193.1.192.0 - 193.1.195.255. И, как было сказано выше, в поле status указывается тип адресов: PI или РА. В дополнение к inetnum object указываются данные о контактных лицах в полях tech-c и admin-c, если они еще не занесены в б/д. Эта информация сохраняется в базе данных в течение всего срока принадлежности адресов данному пользователю. При возврате адресов информация устраняется из базы данных. Занесение в б/д завершает процедуру обработки заявки. После этого регистратура может сообщить пользователю номера выделенных ему адресов и все необходимые сведения об их использовании. 3.7.Assignement Window (AW) Очень важно, чтобы регистратура следовала установленному порядку выделения адресов и применяла критерии контроля размера запроса так, как описано выше. Процедура оформления заявки достаточно проста; что же касается критериев оценки запроса, здесь могут быть некоторые трудности. Для соответствия принципам aggregation, conservation и registration мы должны последовательно применять принятые критерии оценки запроса и следовать порядку его оформления. По сути, это означает, что локальные регистратуры, не имеющие большого опыта работы, должны чаще обращаться за советами и рекомендациями к RIPE NCC, тогда как регистратуры со значительным опытом в большинстве случаев могут действовать самостоятельно. Запросы на большое адресное пространство, однако, всегда требуют согласования. Каждая локальная регистратура получает от RIPE NCC AW (assignement window). AW - это максимальное количество адресов, которое локальная регистратура может выдавать без предварительного согласования с RIPE NCC. Оно имеет вид записи /nn. Так, регистратура с окном /23 имеет право самостоятельно выделять пользователю до 512 адресов. По мере накопления опыта у сотрудников регистратуры AW увеличивается. Выделение количества адресов, превышающего размеры адресного окна данной локальной регистратуры, формально не является действительным, пока RIPE NCC его не подтвердит. Без подтверждения эти адреса не могут быть использованы, так как в дальнейшем они окажутся не уникальными в Internet. Количество выделяемых для одной организации адресов ограничено размером AW локальной регистратуры. Это количество остается неизменным в течение одного года независимо от того, сколько запросов поступило от данной организации. Дополнительное пространство может быть получено только с разрешения RIPE NCC. AW для новых регистратур, как правило, равно 0. Это означает, что удовлетворение каждого запроса на адресное пространство проходит через предварительное утверждение RIPE NCC. По мере роста квалификации сотрудников локальной регистратуры AW может увеличиваться. Как правило, изменение происходит в соответствии со средним размером запросов, присланных данной локальной регистратурой. Например, если присылаются запросы в основном на /25 или менее, AW будет повышено до /25. В этом случае, локальная регистратура сможет выделять простанство в 128 и менее адресов без подтверждения RIPE NCC. В дальнейшем регистратура может послать запрос о повышении имеющегося у нее AW. Принятие RIPE NCC решения об увеличении AW локальной регистратуры будет основываться на профессионализме ее сотрудников. Имеется в виду качество контроля за правильностью оформления запросов, степень точности их оценки и правильности регистрации, а также опыт в выделении большого адресного пространства. В настоящее время максимальный размер AW локальной регистратуры - /19, т.е. 8192 адреса. Запросы на большее пространство требуют обязательного согласования с RIPE NCC. Локальные регистратуры должны обучать своих сотрудников выделять адреса в соотвествии с правилами, описанными в данном документе. Если этому не уделяется достаточного внимания (чаще всего вследствие занятости опытных сотрудников), ошибки в оценке запросов и их оформлении неизбежны. Если такие ошибки будут повторяться, несмотря на многократные указания на них RIPE NCC, AW будет сокращено - во избежание выделения необоснованно большого адресного пространства неопытными сотрудниками. Впоследствии оно может быть снова увеличено, исходя из правил, изложенных выше. 4. Общие правила выделения адресного
пространства локальным регистратурам В 3 главе мы расматривали процедуру обработки запроса, включая решение о выделении адресов. В большинстве случаев адреса выделяются из блока регистратуры. То есть, у регистратуры имеется адресное пространство, из которого она может выбирать адреса для пользователей. Если она не располагает достаточным количеством адресов того типа, в котором нуждается пользователь, она может запросить их у RIPE NCC. Локальная регистратура, таким образом, получает адресное пространство от RIPE NCC. Только RIPE NCC имеет право выделять адресное пространство локальным регистратурам. Локальная регистратура может иметь "открытым" не более одного блока /16 (если израсходовано менее 80%). Локальная регистратура не имеет права на re-allocation, то есть на переадресацию своего пространства другой организации. Она не имеет права также обмениваться адресным пространством с другой регистратурой без предварительного согласования с RIPE NCC. В некоторых случаях локальная регистратура может выделять адреса клиентам другого провайдера, который сам не является регистратурой. Разумеется, регистратура отвечает за все назначения адресов из своего адресного пространства, даже если в процессе их назначения принимали участие представители другого провайдера. Участие разрешается, а соглашение между провайдером и локальной регистратурой о взаимной ответственности - нет. Если сервис-провайдер решает открыть- свою регистратуру вместо того, чтобы пользоваться услугами уже существующей, то адреса, которые он будет выделять своим клиентам, он должен получить от RIPE NCC. Кроме того, он должен будет вернуть все имеющиеся у его клиентов адреса той регистратуре, где он их получил, а своим клиентам дать новые. В следующих разделах мы рассмотрим, как локальная регистратура получает адресное пространство, и как она должна им управлять. 4.1.Механизм медленного старта Учитывая возможность выделения больших блоков адресов, которые не будут должным образом использоваться, RIPE NCC ввел понятие медленного старта. Идея состоит в том, чтобы локальные регистратуры получали столько адресов, сколько будет необходимо пользователям. Минимальный размер выделяемого регистратуре пространства - /19 (8182 адреса), максимальный - /16 (65536 адресов). Размер блока адресов для локальной регистратуры зависит исключительно от количества адресов, реально востребованного пользователями. Практика медленного старта наилучшим образом соответствует принципам стабильности и справедливости распределения адресного пространства. Механизм ее осуществления подобен механизму AW, описанного в разделе 3.6, но политика здесь иная. Размер каждого последующего блока зависит исключительно от нормы потребления адресного пространства данной регистратуры, тогда как размер окна зависит от профессионализма штата сотрудников при оценке запросов и порядке их оформления. 4.2. Выделение адресного пространства
регистратуре в начале ее деятельности Когда локальная регстратура начинает свою деятельность, она не имеет своего адресного пространства. Оно выделяется ей региональной регистратурой автоматически при первой необходимости. Поскольку информации о необходимом количестве адресов для пользователей еще нет, первый блок составит /19 (8192 адреса). Это не означает, что она может самостоятельно распределять адреса пользователям. Как уже говорилось в конце главы 3, вновь учрежденная регистратура должна обращаться за разрешением в RIPE NCC по поводу каждого запроса, до тех пор пока ее AW не будет увеличено. 4.3. Выделение адресного пространства
регистратуре в продолжение ее деятельности Локальная регистратура может получить дополнительное адресное пространство по запросу. Запрос подается в RIPE NCC, когда имеющееся адресное пространство почти исчерпано(около 90%), или если запрос какого-либо пользователя значительно превышает собственные возможности регистратуры. Исчерпанным оно считается только тогда, когда реально распределено, но не зарезервировано. Если адреса из блока регистратуры заканчиваются, необходимо отказаться от резевирования и распределить оставшиеся адреса между теми, кто в данный момент в них нуждается. Заявка локальной регистратуры на получение нового блока должна включать в себя полный список адресов, выделенных пользователям из последнего полученного ею блока. RIPE NCC сверяет основную информацию со своей б/д, после чего может потребовать дополнительной мотивировки получения нового блока, такую как, например, документация по оформлению той или иной сети. Новый блок адресов будет выделен по мере необходимости после изучения и сверки всех данных. К сожалению, распределяя адресное пространство между регистратурами, трудно соблюсти в полной мере принципы аггрегатирования и консервации одновременно. Следуя первому из них, RIPE NCC стремится выделять смежные блоки адресов для каждой отдельной регистратуры. Но, учитывая принцип консервации, это не всегда возможно. Во всяком случае, не следует ожидать, что новый блок адресов будет продолжением предыдущего. В то время как общая политика RIPE NCC направлена на аггрегатирование, т.е. последовательное выделение адресов, политика RIPE такова, что при всем желании не может этого гарантировать. 4.4. Регистрация (Allocation Registration) Новые адреса для регистратуры NCC направляет в б/д RIPE, используя inetnum. Данные о локальной регистратуре, так же, как данные о пользователях, хранятся вместе с записью диапазона адресов и их типа. Эти данные находятся в поле inetnum в виде разделенного точками октета ххх.ххх.ххх.ххх./nn, а тип адресов - в поле status: ALLOCATED PA. Все адреса, выданные регистратурой из РА-пространства, будут аггрегируемыми. Это наиболее часто выдаваемый регистратурам тип адресов. ALLOCATED PI. Все адреса из этого пространства - provider independent, т.е. независимые. ALLOCATED UNSPECIFIED. Это адресное пространство выдавалось регистратурам раньше, и адреса из него были либо РА, либо PI. Теперь адресное пространство без определенного типа выходит из употребления и не будет назначаться регистратурам. Все эти данные поддерживаются RIPE NCC. 5.DNS и система обратных доменов В таких приложениях, как ftp, e-mail, telnet используется доменное имя узла, например, ns.ripe.net. В этой записи полное имя узла строится по иерархическому принципу. В данном примере net - верхний уровень домена, ripe - субдомен, ns - имя узла в домене ripe.net. Эта иерархия похожа на файловую систему UNIXa. Она позволяет давать hostам уникальные имена в Internet. Для того, чтобы IP-пакеты прибывали по назначению, необходим IP-адрес. DNS - система доменных имен - это распределенная база данных, которая позволяет определять IP-адрес по символьному (доменному) имени. Обратное действие, то есть определение доменного имени по IP-адресу, возможно благодаря записи обратного соответствия адреса - имени (reverse address mapping). Об этом и пойдет речь в данной главе. Начнем с краткой характеристики DNS, поскольку обратная карта доменных имен - это не более чем приложение этой системы. Подробно о DNS Вы можете прочитать в [Albitz94a]. Здесь мы лишь хотим подвести базу для понимания процесса создания обратной карты адресов, которые выделяются локальным регистратурам RIPE NCC. 5.1. Запись прямого соответствия DNS - это система типа клиент-сервер. Если данные на сервере поддерживаются должным образом, то каждый общественный IP-адрес имеет соответствующее ему доменное имя. IP-адрес, соответствующий доменному имени, определяется при помощи транслятора доменных имен (resolver), который действует следующим образом. Проанализировав доменное имя, транслятор определяет, на каком сервере (nameserver) находится его адрес. Он посылает запрос на этот сервер и получает либо искомый IP-адрес, либо адрес сервера, на котором он может быть. Во втором случае он посылает запрос на новый сервер и т.д. - пока не получит IP-адрес или ответ о том, что такого адреса не существует.Этот процесс называется прямым поиском (forward mapping, или resolution). Разумеется, идентификация узла при помощи DNS возможна, только если данные о нем имеются на сервере. Отвественность за подмножество имен в определенном домене делегируется представителю организации группой, использующей пространство имен, подпадающих под данный домен. В предыдущем примере хозяином домена верхнего уровня являлся InterNIC. Он делегировал субдомен ripe представителю RIPE NCC, который назначил имя ns одному из узлов в своей сети. После внесения этого имени в сервер имен ripe.net доменное имя ns.ripe.net может быть использовано для поиска IP-адресов этого узла (его номер - 193.0.0.193). Самая правая часть доменного имени соответствует в DNS домену верхнего уровня, за который отвечает IANA. Как правило, это двухбуквенный ISO 3166 код страны: nl - Нидерланды, fr - Франция, us - США. Эти коды утвердила IANA (единственное исключение - домен .uk; на самом деле должно быть gb). Управление доменами стран делегируется представителям этих стран. Если этого еще не произошло, организация, представляющая страну, может обратиться в IANA за получением права делегирования. Ответственность за домен верхнего уровня данной страны возлагается на то лицо, которое соответствует условиям, указанным в RFC 1591 [Poste194a], если у общественности не будет возражений в течение некоторого периода после выдвижения данной кандидатуры. Когда DNS только внедрялась, в качестве имен доменов верхнего уровня использовалось лишь несколько кодов, состоящих из трех букв. Эти домены находятся в ведении InterNIC и до сих пор широко применяются в США. Исторически имена этих доменов соответствовали видам деятельности: академические учреждения назывались edu, военные - mil и т.д. Принципы делегирования определяются группой, ответственной за управление доменом. Например, принципы делегирования доменов 3-го уровня определяет та организация, которой был делегирован соответствующий домен 2-го уровня. Например, представитель Кататонского Государственного Университета может отвечать за делегирование субдоменов, которые подпадают под cat.edu. Очевидно, общая политика делегирования доменов будет по-прежнему оставаться в рамках основных положений RFC 1591 [Postel194a]. Запись соответствия доменного имени IP-адресу (mapping a domain name to an IP-address) находится на сервере имен, поддерживаемом организацией, ответственной за данный домен. Предположим, необходимо определить IP-адрес хоста bite.dog.cat.edu. Поскольку домен edu находится в ведении InterNIC, запрос может поступить прежде всего на сервер этой организации. Если домен cat.edu ,был делегирован серверу Кататонского Университета, сервер InterNICa, очевидно, направит запрос на университетский сервер, который, в свою очередь, перешлет его серверу соответствующего факультета. Если все файлы этого сервера в полном порядке, он и выдаст искомый IP-адрес. Это упрощенная модель использования DNS. Здесь не рассматривается кэширование (caching) и другие способы оптимизации DNS. Однако, она дает общее представление о том, какие группы за какую часть информации отвечают в общей системе определения IP-адреса по доменному имени. 5.2.Pегистрация обратных доменов В одних случаях необходимо определить IP-адрес по доменному имени, в других - имя по адресу. Простой авторизованный контроль (simple authorisation checks), используемый некоторыми приложениями, а также,например, некоторые диагностические службы требуют полного доменного имени узла в соединении с адресом. Процесс нахождения доменного имени по IP-адресу называется обратным поиском и требует записи обратного соответствия (reverse mapping). В DNS для этого создается обратный домен in-addr.arpa (исторически - аббревиатура от inverse addresses in the Arpanet - обратные адреса в Arpanet). Этим доменом управляют регистратуры, поскольку они распределяют адресное пространство. Например, RIPE NCC управляет доменом 193.in-addr.arpa, поскольку он отвечает за распределение адресов в пространстве 193/8 (наряду с прочими адресными пространствами). RIPE NCC делегирует полномочия управления именами в пределах домена 193.in-addr.arpa тем, кому он выделяет адресное пространство, подпадающее под этот домен. Предположим, нам надо определить доменное имя по адресу 193.3.20.100. Имя обратного домена будет выглядеть так: 100.20.3.193.in-addr.arpa, то есть числа изменят свой порядок на противоположный и прибавится суффикс .in-addr.arpa. По нему будет отыскиваться доменное имя, соответствующее IP-адресу в обратной записи имен. После того, как имя обратного домена создано, механизм обратного поиска становится аналогичным механизму прямого поиска. Хотя механизмы прямого и обратного поиска аналогичны, принципы управления прямым и обратным доменом различаются. В то время как ответственность за подмножество имен в прямых доменах несут организации (см. выше), ответственность за обратные домены несут те, кто распределяет адресное пространство. Термин обратное делегирование (reverse delegation) означает делегирование имен IP-адресов в обратном домене in-addr.arpa. Пример - обратное делегирование Координационному Центру RIPE (RIPE NCC) обратного домена 193.in-addr.arpa. Он обязан поддерживать информацию о соответствии имен адресам для всего адресного пространства 193/8. Важно отметить, что обратное делегирование не происходит автоматически при выделении адресов. Обратное делегирование в пределах всего адресного пространства, принадлежащего RIPE NCC, осуществляется в соответствии с запросами на адреса из этого пространства, направленными в RIPE NCC. Как сказано выше, имена обратных доменов записываются в виде разделенных точками октетов IP-адресов. Поэтому обратное делегирование тоже требует записи по октетам. Предположим, RIPE NCC выделил блок адресов /17 локальной регистратуре Eye-Pea, например, 193.1.0/17. Обратный домен 1.193.in-addr.arpa не будет делегирован регистратуре Eye-Pea, поскольку она отвечает только за часть адресного пространства, соответствующего обратному домену 1.193.in-addr.arpa. За делегирование обратного домена 1.193.in-addr.arpa будет отвечать сам RIPE NCC, как и за все пространство, подпадающее под этот обратный домен. Другой пример. Предположим, что адресное пространство /16 было выделено локальной регистратуре Aye-Queue, например, 193.2/16. Тогда зона (или домен) 2.193.in-addr.arpa может быть делегирована регистратуре Aye-Queue в соответствии с ее запросом, поскольку эта регистратура отвечает за все назначения адресов в диапазоне 193.2.0.0-193.2.255.255. В свою очередь, Aye-Queue потребуются данные о доменных именах адресов в диапазоне 193.2.0.0-193.2.255.255. Если запрос принят, Aye-Queue имеет право управлять доменом 2.193.in-addr.arpa. В соответствии с правилами, описанными в 3 части данного документа, Aye-Queue может выделить пространство /24, например, 193.2.40.0-193.2.40.255 некой Организации. Соответственно, Aye-Queue может дать право делегирования обратного домена 40.2.193.in-addr.arpa, и запросы на доменные имена для адресов диапазона 193.2.40.0-193.2.40.255 будут направлены к Организации. Отметим, что classless адреса находятся вне границ октета, тогда как обратное делегирование требует октетной записи, поскольку так строится имя обратного домена. Это означает, что выделение classless адресов требует несколько иного подхода, чем описанный выше. Этот вопрос будет рассмотрен отдельно. Основная же система остается неизменной. RIPE NCC и локальные регистратуры совместно контролируют процесс обратного делегирования и делают информацию о соответствии IP-адресов доменным именам общедоступной. Роль RIPE NCC и локальных регистратур в этом процессе рассматривается в следующем разделе. 5.3.Локальные регистратуры и делегирование обратных доменов. Если локальная регистратура получает полномочия в адресном пространстве, которое она выделяет пользователям, она должна выполнять связанные с этим обязанности - т.е. обеспечивать данные о соответствии IP-адресов именам для своих клиентов. В этом разделе мы рассмотрим, как получить полномочия. Начнем с обязанностей, которые вытекают из права делегирования зон доменных имен. Потом обсудим пути распространения и поддержки информации в б/д обратных соответствий при выделении адресов CIDR ("classless"). Получение права делегирования здесь имеет свои особенности. Наконец, поговорим о действиях локальных регистратур при назначении РА и PI адресов. 5.3.1.Обязанности (Responsibilities). При прямом делегировании лицо или организация, которым поручалась ответственность за зону, брали на себя обеспечение основных услуг, необходимых для поддержания доменных имен в данной зоне. При обратном делегировании необходим подобный же порядок, т.е. должны существовать лицо или организация, которые будут поддерживать данные о соответствии IP-адресов доменным именам. Когда обратная доменная зона (a reverse domain zone) делегируется локальной регистратуре, она должна позаботиться о соответствующем построении (construction) конфигурации файлов данных DNS для своей зоны. О возникающих при этом трудностях и способах их преодоления см. RFC [Beertema93a]. Чтобы обеспечить надежность базы данных, для каждой зоны должен быть установлен вторичный сервер имен. Он должен находиться в другой подсети, чем первичный.При делегировании локальной регистратуре адресного пространства /16, RIPE NCC предоставляет еще один вторичный сервер, чтобы обеспечить повышенную надежность сохранности данных. Для локальных регистратур и других организаций, отвечающих за обратные домены, характерно предоставление друг другу услуг своих вторичных серверов. Как первичный, так и вторичный сервера обратных доменных имен должны быть в равной мере доступны, поскольку это необходимо для сервера имен домена верхнего уровня. Если локальная регистратура является владельцем зоны обратного домена, она отвечает за последующие делегирования в этой зоне. Это значит, что локальная регистратура должна иметь уверенность в том, что организация, которой делегируется ответственность за подмножество имен, удовлетворяет требованиям, описанным в данном документе. В разделе 5.4 говорится о методах контроля за работой системы обратных доменных имен, применяемых RIPE NCC. Локальные регистратуры также должны применять их в отношении своих пользователей. 5.3.2. CIDR и обратное делегирование. Как было сказано выше, схема обратного делегирования при выделении "classless" (CIDR) адресов отличается от схемы при выделении адресов определенного класса. Когда выделяются не-октетные адреса, полномочия в зоне обратного домена локальная регистратура оставляет за собой. 5.3.2.1. Выделение блоков регистратурам и обратное
делегирование Если локальной регистратуре выделяется блок меньше /16,- как в примере с Eye-Pea (193.1.0/17), ответственность за обратный субдомен 193.in-addr.arpa не может быть отдана этой регистратуре, поскольку другая часть соответствующего адресного пространства может быть выделена другой локальной регистратуре. Выделяя локальным регистратурам блоки меньше /16 в пространстве 193/8, RIPE NCC каждый раз сохраняет за собой ответственность за обратный субдомен 193.in-addr.arpa, и обратное делегирование произойдет только когда часть этого адресного пространства будет выделена конкретному пользователю по его запросу. Тот же порядок обратного делегирования относится к любому блоку /8 из диапазона RIPE NCC. Если, скажем, у регистратуры Eye-Pea осталась часть блока, например, 193.1.128/17, она может подать запрос на обратное делегирование в 1.193.in-addr.arpa. Когда управление обратным доменом отдается локальной регистратуре, RIPE NCC предоставляет ей все соответствующие данные и полномочия на делегирование всех обратных зон. В нашем примере, если 1.193.in-addr.arpa было делегировано Eye-Pea, то она отвечает за все прошлые и будущие делегирования в пределах этого домена. С другой стороны, предположим, что локальной регистратуре выделен блок /16, как в примере с Aye-Queue, скажем, 193.2/16. Она может немедленно запросить себе полномочия на управление субдоменом 193.in-addr.arpa, т.е. 2.193.in-addr.arpa. Поскольку Aye-Queue отвечает за все адресное пространство, соответствующее этому обратному домену, она эти полномочия получит. 5.3.2.2. Выделение адресного пространства пользователям и обратное делегирование (Assignement and Reverse Delegations). По отношению к обратному делегированию, мы можем выделить две категории адресного пространства: включающее интегральное число /24 - или не включающее. Предположим, регистратура имеет пространство /16. Продолжая наш пример, представим, что Aye-Queue имеет пространство 193.2/16 и право на обратное делегирование 2.193.in-addr.arpa. Aye-Queue выделяет 64 адреса 193.2.0/26 пользователю Use-IQ. По тем же причинам, что и в случае с /17 у Eye-Pea, пользователь Use-IQ не получит полномочий в обратном домене 0.2.193.in-addr.arpa, т.к. часть соответствующего адресного пространства может быть выделена другим пользователям. В этом случае Aye-Queue делегирует 0.2.193.in-addr.arpa самой себе и поддерживает данные о соответствии IP-адресов доменным именам для Use-IQ и всех других подобных пользователей. Такое самоделегирование, конечно, не является строго необходимым, но оно помогает в управлении многочисленными доменами. Эта процедура подробно описана в [Eidnes98a]. Поэтому рекомендуется все же зарегистрировать эту обратную зону в б/д RIPE. Предположим, что Eye-Pea выделяет адреса из 193.1.0/17. Если она выделит 193.1.0.0/26, встанет такая же проблема. Более того: поскольку Eye-Pea не является хозяином для 1.193.in-addr.arpa, она не может делегировать себе 0.1.193.in-addr.arpa. Но Eye-Pea получит право делегирования в 0.1.193.in-addr.arpa по запросу, после того как выделит хотя бы один блок /24. Процедура получения полномочий описана в разделах 5.3.3 и ниже, в 5.5. Пользователь Use-IQ мог получить адреса, являющиеся интегральным числом для /24. Например, 768 адресов (193.2.0.0 - 193.2.2.255). Тогда регистратура могла бы делегировать ему {0,1,2}.2.193.in-addr.arpa. Процедуры, которые должна выполнить регистратура при делегировании обратного домена пользователю и услуги, которые она должна ему в этом случае предоставить, описаны в разделах 5.4 и 5.5. Теперь предположим, что Eye-Pea выделила 256 адресов (193.1.0.0 - 193.1.0.255) пользователю Use-IP. Тогда у регистратуры нет необходимости управлять обратным доменом 0.1.193.in-addr.arpa, поскольку Use-IP - единственный пользователь этого адресного пространства. В этом случае Eye-Pea должна поддержать его запрос в RIPE NCC на обратное делегирование (используя domain object) и обеспечить вторичную б/д, а также оказать все остальные необходимые услуги (подробности см. в след. разделе). Таким образом, когда локальная регистратура выделяет пользователям пространство меньше /24, она сама управляет соответствующим обратным доменом в пределах этого пространства, поскольку выделенные адреса являются лишь его частью. Она поддерживает данные о соответствии назначенных пользователям IP-адресов доменным именам. Подробную информацию о делегировании обратных доменов для адресного пространства CIDR см. в [Eidnes96a]. Ниже приводятся две таблицы, дающие представление о делегировании обратных зон пользователям и локальным регистратурам. Инструкции для пользователя: Allocation Size /16 </16 Assignement >=/24 LIR NCC Size </24 LIR LIR LIR = Запрос у локальной регистратуры Инструкции для локальной регистратуры: Allocatioon Size /16 </16 Assignement >=/24 DF FR Size </24 ML RR DF = Дальнейшее делегирование (Delegate further) FR = Разрешение RIPE NCC (Forward request to RIPE NCC) ML = Локальная поддержка б/д (Maintain locally) RR = Запрос в RIPE NCC на обратное делегирование и локальная поддержка б/д (Request delegation from the RIPE NCC and maintain locally). 5.3.3. Делегирование обратного домена (Obtaining a Reverse Delegation) В данном разделе орисывается процедура запроса локальной регистратурой права обратного делегирования у RIPE NCC. Как можно заключить из предыдущего раздела, локальная регистратуре всегда получает полномочия для диапазона /16; для /24 - только после того, как выделит из него часть адресов. Эти процедуры аналогичны. Но в этом разделе мы коснемся только диапазона /16; о диапазоне /24 см. раздел 5.5. Чтобы получить полномочия в зоне обратных имен, надлежит выполнить следующее: 1. Сконфигурировать файлы DNS для данной обратной
зоны. Следуя RFC 1537 [Beertema93a], для прямого субдомена
(direct subdomain) в доменах, управляемых RIPE NCC,
рекомендуются следующие установки: Мы рекомендуем уменьшить повтор (retry), если подключение недостаточно устойчиво. 2. Установить конфигурационные файлы (install the configuration files) на первичном и вторичном серверах. Удостоверьтесь, что с ваших name-серверов разрешен трансфер зон из локальных сетей данного диапазона: 193.0.0/24. 3. Собрать необходимую информацию о domain object для б/д RIPE. Имя обратного домена, например, 0.194.in-addr.arpa указать в поле domain. В полях descr дать описание организации, которая будет поддерживать зону. В полях admin-c, tech-c, zone-c указать контактных лиц, ответственных за первичный серевер, его техническую поддержку и управление зоной соответственно. В полях nserver, которых должно быть как минимум три, указать доменные имена первичного, вторичного и RIPE NCC серверов обратных имен. Наконец, как и во всех объектах б/д RIPE, в поле changed указать e-mail адрес лица, делающего запрос, и sorce - RIPE. Например, если локальная регистратура получила адресное пространство 194.0.0.0 - 194.0.255.255 для выделения пользователям, они пришлют следующие данные: domain: 0.194.in-addr.arpa Пожалуйста, отметьте, что один из серверов имен
должен быть ns.ripe.net. 4. Направить заявку на обратное делегирование по адресу <auto-inaddr@ripe.net>. Здесь подразумеваются те же требования, которые были описаны в разделе 5.3.1. Описанный нами domain object должен быть включен в заявку, так же, как и данные о зоне уровнем выше (zone file entries). Например, если обратное делегирование требуется для 1.193.in-addr.arpa, необходимо включить данные о 193.in-addr.arpa; если обратное делегирование требуется для 2.2.193.in-addr.arpa, надо включить данные о 2.193.in-addr.arpa. (Это один запрос для <auto-inaddr@ripe.net>) Как описано ниже, RIPE NCC будет контролировать работу первичного и вторичного серверов. Если локальная регистратура, сделавшая запрос на обратное делегирование, имеет соответствующее обратной зоне адресное пространство, и если сервера работают нормально,- запрос будет удовлетворен. В следующем разделе говорится об услугах, которые RIPE NCC в таких случаях оказывает. 5.3.4.Побочные эффекты для адресов PA/PI (Side Effects for
PA/PI assignements) В случае с РА-адресами, конкретное соглашение об обслуживании обратных доменов продолжается до тех пор, пока организация владеет выданными ей адресами. Ясно, что это одна из причин заинтересованности локальных регистратур и их пользователей в замене не-РА-адресов на РА-адреса. 5.4. Услуги RIPE NCC по обратному делегированию Поскольку RIPE NCC выдает локальным регистратурам адреса из 193/8 и других /8 блоков, полученных им от IANA, он же отвечает за обратное делегирование соответствующего адресного пространства. Поэтому все запросы на полномочия в этом пространстве присылаются в RIPE NCC. Если требуются данные об обратных зонах для адресов из пространства, принадлежащего неизвестно какой региональной регистратуре, запрос адресуется в RIPE NCC. Если адреса находятся в ведении другой региональной регистратуры, запрос возвращается с указанием ее данных. И, разумеется, не создаются данные об обратных доменах для адресов, которые не были выделены ни регистратурам (/16), ни пользователям (/24), и не были зарегистрированы в б/д. По получении запроса на делегирование обратного субдомена 193.in-addr.arpa, 194.in-addr.arpa, 195.in-addr.arpa, 62.in-addr.arpa или 212.in-addr.arpa RIPE NCC сначала удостоверится, что все соответствующее адресное пространство было выделено данной локальной регистратуре. Если это запрос для блока /24, будет выяснено, все ли адреса были выделены пользователю, или только часть. Если факт выделения адресов подтведится, то будет сделано следующее: - Протестирован доступ к первичному и
вторичному серверам указанного доменного
объекта. Если запрос для блока /16, будут выполнены еще две задачи: - Если запрос удовлетворен, RIPE NCC установит
вторичный сервер для обратного домена ns.ripe.net и
уведомит об этом локальную регистратуру. Все запросы на делегирование обратных зон в RIPE NCC теперь обрабатываются автоматически. Информация о зоне обрабатывается автоматом <auto-inaddr@ripe.net> mailbox. Робот в процессе проверки скачивает инфорнмацию о зоне, поэтому, пожалуйста, откройте трансфер для зоны 193.0.0/23 (диапазон адресов RIPE NCC). Если зона установлена верно, запрос поступит на утверждение ответственного работника RIPE NCC и, если все в порядке, будет удовлетворен. Более подробную информацию Вы можете найти на http://www.ripe.net/inaddr. Делегирование обратных зон позволяет локальной регистратуре управлять обратными данными для IP-адресов, выделенных пользователям. Поэтому пользователи могут быть уверены, что будут быстро и легко идентифицированы с хостов сети по своему IP-адресу. Из-за широты распространенности базы данных ее нормальное функционирование зависит от точности управления всеми зонами. Лишь в редких случаях организация, управляющая зоной, оказывается неспособной выполнять эту работу. Тогда RIPE NCC, как последняя инстанция поддержки б/д, может отменить делегирование. 5.5. Делегирование обратных зон пользователям
До сих пор мы говорили о процедурах, связанных с делегиованием обратных зон локальным регистратурам. Поскольку надежность данных, распространяемых при помощи DNS, увеличивается по мере приближения к источнику данных, делегирование обратной зоны может быть предоставлено также и пользователям, получившим блок /24. В этом контексте блок /22 - это многократный /24, для которого может быть многократно затребовано делегирование. Локальная регистратура должна поддерживать запросы на делегирование обратных зон от пользователей, которым выделяется один или более блоков /24. Пользователи должны быть уведомлены о возможности получения такого права, а также об обязанностях, которые из этого вытекают. По отношению к пользователям действуют, в основном, те же критерии, что и по отношению к локальным регистратурам. Пользователь, претендующий на управление определенной зоной, должен взять на себя обязанности, указанные в разделе 5.3.1. Но здесь есть некоторое отличие от процедур, описанных в разделе 5.3.3. В то время как пользователь отвечает за обратную зону и за все, что из этого следует, локальная регистратура, по традиции, помогает своим пользователям в получении и поддержке обратных зон в своем адресном пространстве. Например, она, как правило, предоставляет вторичный сервер обратных имен. Если локальная регистратура, как Eye-Peа, получит блоки /19, /18 или /17, то обратное делегирование производит RIPE NCC, а не локальная регистратура. В этом случае в базу данных RIPE заносится domain object на каждый /24 диапазон адресов. Заявка посылается на <auto-inaddr@ripe.net>. Пример inetnum-object для адресного пространства /24 приводится ниже. Если блок /24 поделен между несколькими пользователями, в базу данных и на <auto-inaddr@ripe.net> посылается domain object на весь блок. Например, если локальная регистратура выделила 194.0.0.0 - 194.0.0.127 пользователю А и 194.0.0.128 - 194.0.0.255 пользователю В, они посылают на <auto-inaddr@ripe.net> один domain object, как показано ниже: domain: 0.0.194.in-addr.arpa descr: our company Пожалуйста, отметьте, что ns.ripe.net здесь указывать не следует. Следует иметь в виду, что RIPE NCC делегирует обратную зону только после того, как адресное пространство выделяется пользователям (за исключением /16), т.е. делегирование производится не тогда, когда адреса выделяются регистратуре, а когда они выделяются пользователям через регистратуру. Локальным регистратурам рекомендуется сразу же отсылать domain object на <auto-inaddr@ripe.net>, поскольку RIPE NCC не сможет делегировать обратную зону для адресного пространства, не зарегистрированного в базе данных RIPE. В запросе на обратное делегирование в строке Subject заголовка письма могут быть использованы ключи (keywords) для контроля процесса проверки. Настоятельно рекомендуется использование ключа LONGACK. Он отошлет обратно слишком многословный запрос. Ключ HELP вышлет эту часть данного документа; CHANGE необходим при замене делегированной обратной зоны; TEST протестирует обратную зону без процедуры запроса. При запросах особого характера, при стирании файлов с данными об обратной зоне, заражении вирусом (bug reports), при наличии критических замечаний или в случае постороннего вмешательства локальная регистратура должна связаться с <inaddr@ripe.net>. Локальная регистратура, имеющая /16 адресное пространство, может сама производить делегирование обратных зон, но при этом желательно, чтобы domain object обратной зоны был занесен в б/д RIPE. В обоих случаях локальная регистратура должна сделать то же, что делает RIPE NCC, чтобы подтвердить, что обратная зона соответствует адресам, и что она управляется должным образом. Например, что выданное пользователям адресное пространство соответствует делегированной обратной зоне, что протестированы первичный и вторичный сервера. 6. Управление локальной регистратурой. Через локальные регистратуры проходит огромное количество адресного пространства, выделяемого пользователям. Большинство регистратур управляются сервис-провайдерами, предоставляющими своим абонентам услуги по регистрации IP-адресов. В этой главе мы описываем деятельность RIPE NCC, направленную на обеспечение единой политики, изложенной в данном документе. Здесь также говорится о процедурах, связанных с регистрационными услугами, которые локальные регистратуры должны выполнять, чтобы обеспечить это единство. 6.1. Регистрационные услуги RIPE NCC. RIPE NCC предоставляет действующим локальным регистратурам набор регистрационных услуг, большая часть которых описана выше. Заявки и вопросы относительно этих услуг направляются почти исключительно по электронной почте. Для этого существует набор почтовых ящиков. Почта регулярно принимается служащими RIPE NCC или поступает на автоматы. Почтовые адреса служащих NCC не используются для заявок. Использование обычной почты нежелательно. Телефонные переговоры должны сопровождаться отправкой документации по e-mail во избежание недоразумений. Большинство вопросов поступает по адресу <ncc@ripe.net>; но есть адреса для особых запросов. На auto-адресах работают автоматы, люди, как правило, не читают эту почту. По этим адресам выполняются специфические задания, принимаются особые сообщения или информация, закрытая для сотрудников NCC. RIPE NCC имеет следующие адреса: <hostmaster@ripe.net>. Этот адрес служит для оказания услуг по регистрации и является нашим первичным (primary) интерфейсом для локальных регистратур. По этому адресу отправляют запросы на выделение IP-адресов и номера автономных систем (AS). Всю эту информацию следует отправлять по электронной почте. Однако, такая информация, как топология сети и других документов, требующих hardcopy, может быть послана по факсу. Каждый документ, отправляемый по факсу, должен содержать ticket number запроса в поле subject или в каком-либо другом месте сообщения. Если эти документы возможны в формате PostScript, их лучше посылать по e-mail, чем по факсу. <auto-dbm@ripe.net>. По этому адресу можно посылать заявки и вопросы, ответы на которые требуют участия человека. <auto-inaddr@ripe.net>. Это робот, который обрабатывает запрос о делегировании домена in-addr.arpa (используя таблицу обратного соответствия IP-адресов именам хостов). Анализ и техническая проверка выполняются для того, чтобы убедиться, что DNS-сервера установлены правильно. Если запрос проходит проверку, он направляется по адресу <inaddr@ripe.net>. <inaddr@ripe.net>. Здесь производится дополнительная ручная проверка. NCC DNS конфигурация обновляется в соответствии с запросом. Нестандартные заявки и общие вопросы относительно обратного делегирования также адресуются сюда. <training@ripe/net>. Сюда направляются вопросы о курсах повышения квалификации работников регистратур. Все, кто желает прослушать курс, может обратиться по этому адресу. <billing@ripe.net>. Сюда обращаются по вопросам о счетах-фактурах, исполнении соглашений по обслуживанию; новые клиенты могут получить здесь общую информацию. Этот адрес служит также для обновления регистрационной информации. <ncc@ripe.net>. Сюда могут обратиться те, кто не знает точно, по какому адресу можно получить необходимую информациюпо тому или иному вопросу. Здесь либо ответят сами, либо направят по нужному адресу. <new-lir@ripe.net> служит для регистрации LIR. Подробнее об этой процедуре см. далее (6.2). Список локальных регистратур. RIPE NCC поддерживает список всех локальных регистратур своего региона. В нем имеется информация о каждой из них. Часть этой информации публикуется, чтобы ею могли воспользоваться другие регистратуры и пользователи. Открытые данные по каждой локальной регистратуре можно найти на http://www.ripe.net/lir/registries/indices/index.html 6.2.Открытие новой регистратуры. Открытие новой регистратуры осуществляется после подачи заявки в RIPE NCC. Из заявки должно явствовать, что будущие сотрудники ознакомились с правилами и указаниями, изложенными в этом и других подобных документах, и что эти правила будут исполняться. Процесс открытия LIR подробно объясняется в документе ripe-160 [Caslav98a] ("Guidelines for Setting up a Local Internet Registry") 6.3.Списки рассылки. RIPE NCC поддерживает серию списков рассылки на разные темы для локальных регистратур. Некоторые из них являются обязательными. Это означает, что регистратура должна выделить как минимум один e-mail адрес, который не может быть исключен из списка рассылки без замены его на другой e-mail адрес. <local-ir@ripe.net>. Здесь помещается информация, касающаяся работы регистратуры: объявления о начале работы очередных курсов повышения квалификации работников регистратур и др. Этот список закрытый, он доступен только для регистратур, уплативших взнос. Он является обязательным. Если понадобится заменить e-mail адрес, надо обратиться на <hostmaster@ripe.net> <lir-wg@ripe.net>. Это список рассылки рабочей группы LIR, к которой каждый может присоединиться. Набор тем не ограничен: от общих проблем ведения локальных регистратур до регистрационных услуг. Он не является обязательным, хотя участие локальных регистратур в подобных обсуждениях приветствуется.Для того, чтобы получать эту рассылку, регистратура должна обратиться по адресу <majordomo@ripe.net>. <ncc-co@terena.net>. Это список рассылки комитета вкладчиков RIPE NCC. Здесь публикуются все документы, касающиеся NCC,- например, план работы RIPE NCC и годовой бюджет. Список обязательный, для изменения e-mail адреса следует обратиться на <hostmaster@ripe.net>. <lst-provs@ripe.net> . Используется для распространения запросов на услуги, получаемые в RIPE NCC. Не является обязательным, однако открыт только для локальных регистратур. Для внесения в список рассылки или исключения из него обратитесь на <hostmaster@ripe.net>. Во всех списках публикуются объявления и текущая информация. Принято, чтобы по крайней мере один сотрудник LIR отслеживал эту рассылку и был в курсе текущих событий. Настоятельно рекомендуется, чтобы по крайней мере один сотрудник локальной регистратуры прослушал однодневный курс подготовки регистраторов. Это вводный курс, в котором говорится о правилах выделения адресов пользователям, о процедуре регистрации в Европе, а также о том, как работать с базой данных RIPE. Информацию о работе курсов можно найти в рассылке local-ir mailing list. 6.4.Работа регистратуры (Registry Operations). В этом разделе излагается набор правил, которым локальная регистратура должна следовать в своей практике. Большинство из них сложилось исторически, со всеобщего согласия работников локальных регистратур. Все локальные регистратуры должны твердо держаться этих правил, или стараться их усовершенствовать, открыв дискуссию в рассылке <local-ir@ripe.net> и активно сотрудничая в рабочей группе локальных регистратур. Ведение записей. Локальная регистратура должна поддерживать все записи, касающиеся процесса ее деятельности. Она должна иметь всю информацию о выделении адресов своим клиентам. Эти данные необходимы для оценки очередных запросов от одних и тех же клиентов, для проверок региональной регистратурой, а также для разрешения любых вопросов, которые могут возникнуть в процессе выделения адресов или после него. Эти записи должны включать следующее: -Оригинал заявки. -Всю сопроводительную документацию. -Всю переписку регистратуры с клиентом. -Решение о выделении адресов, включая: -особые причины в случае нестандартного решения; -лицо, ответственное за принятие решения. В записях должны четко указываться даты событий и ответственные лица. Эта информация должна храниться так, чтобы быть легко доступной при первой необходимости. Идентификатор (Registry Identifier) Идентификатор регистратуры следует указывать на каждом сообщении, отправляемом по адресу <hostmaster@ripe.net>. Он служит для упрощения обработки информации. По нему определяется, имеет ли регистратура право на услуги RIPE NCC, и ее ticket number (см. ниже). В соответствии с принципом, установленным комитетом вкладчиков (см. ripe-132 Kuehne95a), услуги могут быть оказаны только регистратурам, уплатившим взнос. Заявки, полученные от этих регистратур, обрабатываются в порядке очереди. Заявки от регистратур, не внесших плату своевременно, не обрабатываются до тех пор, пока положение не будет исправлено. Заявки без указания идентификатора не рассматриваются. Система тикетинга (Ticketing System). Эту систему RIPE NCC использует, чтобы отслеживать хронологию каждого запроса, присланного на <hostmaster@ripe.net>. Каждая заявка по этому адресу должна иметь ticket number, который был ей присвоен; он должен быть также указан на всех последующих сообщениях на тему данной заявки, пока она не будет окончательно удовлетворена. Каждая новая заявка получает новый ticket number. То есть, локальная регистратура не может прислать две заявки в одном сообщении. Более того: поскольку ticket number относится к одной-единственной заявке, он не может быть использован два и более раз. Более подробно см. в ripe-183[Karrenberg94a}. Контакты (Contact-persons) Каждая локальная регистратура должна представить в RIPE NCC список контактных лиц. Это лица, которые присылают заявки на выделение адресного пространства и номеров AS. Контактная информация должна своевременно обновляться. В сущности, заявки на адреса и номера AS принимаются только от сотрудников, чьи контактные данные зарегистрированы. Конфиденциальность. Информация, собираемая в процессе регистрации, должна храниться в строгом секрете. Она должна использоваться только для целей регистрации. Ее можно передавть только ркгистратуре высшего уровня и/или IANA вместе с заявкой. Гласность. Главное занятие локальных регистратур - выделение IP-адресов. Эта деятельность не имеет самостоятельной ценности, но очень важна для подключения к Internet. Выделение адресов должно производиться в разумных пределах, с учетом стратегии аггрегатирования и с соблюдением приципа равноправия по отношению к различным сервис-провайдерам. Собственное понимание своих целей и задач регистратура может сделать достоянием общественности. Для этого она должна изложить свои взгляды RIPE NCC,который их опубликует. Такая информация должна включать в себя как минимум следующее: 1. Кого регистратура обслуживает. кокальная регистратура должна представить краткое описание, какого типа клиентов она обслуживает. Достаточным будет, например, следующее описание: "Мы обслуживаем клиентов <...> компании и сервис-провайдеров, имеющих, в основном, <...> типа клиентов в таких-то странах". Регистратура также должна указать, согласна ли она оказывать только регистрационные услуги. 2. Необходимо также обнародовать свои принципы оплаты услуг. Основные положения относительно оплаты услуг определены в текущем проекте RIPE [Norris96a]: адресное пространство представляет собой исчерпаемый ресурс, не имеющий себестоимости, на который не может быть назначена продажная цена. Не взимая плату за адресное пространство, регистратура может взимать ее за свои административные и технические услуги. Регистратуры должны публиковать подробную информацию о том, какого рода услуги они оказывают и на каких условиях, включая тарифы, если они есть. 3. Условия выделения адресов. 6.5.Закрытие регистратуры Локальная регистратура может приостановить свою деятельность. Если она собирается впоследствии ее возобновить, она должна будет снова пройти все процедуры, связанные с открытием новой регистратуры. С того момента, когда принимается решение о закрытии, регистратура должна прекратить прием заявок на выделение IP-адресов и предоставить клиентам список других локальных регистратур. Это избавит их от необходимости последующей перенумерации. Список находится на http://www.ripe.net/lir/registries/indices/index.html Регистратуре в период ее закрытия не разрешается выделять адреса из своего блока. Для прекращения деятельности регистратура должна предпринять следующее:
Если регистратура прекращает свою регистрационную деятельность, но при этом продолжает оставаться сервис-провайдером, ее клиенты могут продолжать и спользовать выделенные им адреса,- поскольку сохраняются первоначальные критерии их выделения. Если регистратура прекращает также и провайдерскую деятельность, адреса, выделенные ею своим клиентам, будут возвращены по мере перенумерации. Оказывать клиентам содействие в этом процессе входит в обязанности закрывающейся регистратуры. 6.4.1. Когда регистратура закрывается по решению RIPE NCC. RIPE NCC может принять решение о закрытии локальной регистратуры, если она прекращает оплачивать счета RIPE NCC и/или если с ней оказывается невозможно связаться в течение продолжительного времени. Регистратура может быть закрыта также в случае нарушения ею принципов, установленных IANA или RIPE NCC, несмотря на многочисленные предупреждения. RIPE NCC высылает локальной регистратуре уведомление о ее закрытии. Регистратура должна представить документацию о своем адресном пространстве и далее проследовать через все процедуры, описанные выше. Если регистратура не предоставит положенную документацию, RIPE NCC самостоятельно определит, какие адреса должны быть возвращены. 7. Присвоение номера автономной системе (AS): политика и процедуры. Автономная система это система IP-сетей, управляемых одним или несколькими операторами, имеющими единую роутинговую политику. Каждая AS имеет уникальный номер, который служит ее идентификатором в обмене внешней роутинговой информацией (т.е. информацией доступа с различных AS друг к другу). Протоколы внешнего роутинга, такие как BGP (RFC 1771 [Rekhter95a]) используются для обмена роутинговой информацией между автономными системами. Для обмена информацией внутри AS используется какой-либо из протоколов внутреннего роутинга. Понятие AS часто неверно понимается как способ объединения сетей, находящихся под единым администрированием. Однако, если внутри одной группы сетей существует различная роутинговая политика, - значит, здесь не одна AS. С другой стороны, если две группы сетей имеют одинаковую роутинговую политику, значит, они принадлежат одной AS, несмотря на то, что у них разные администраторы. То есть, общность роутинговой политики, а не администрации является главным условием принадлежности сетей к одной AS. Для того, чтобы чрезмерно не усложнять глобальный роутинг, новая AS создается лишь при условии необходимости в новой роутинговой политике. Объединение в одну AS группы сетей, имеющих различных администраторов, иногда требует дополнительной договоренности между ними. В отдельных случаях может потребоваться некоторое переоборудование сетей. Однако, это единственный способ появлений новой AS. (См. RFC 1930 [Hawkinson96a]). 7.1. Получение номера AS RIPE NCC назначает номера AS в пределах принадлежащего ему адресного пространства. Так же, как и в случае заявок на IP-адреса, заявки на номера AS принимаются только от регистратур, сделавших взнос в RIPE NCC. Заявки направляются по адресу hostmaster@ripe.net. Для получения номера AS заполняется соответствующая заявка. Она состоит из 4-х частей: aut-num (номер автономной системы) object templtate, technical templtate, mntner (maintainer) template и один или более person templtate. Все поля заявки должны быть заполнены. В отдельных случаях NCC может затребовать дополнительную информацию для более четкого представления о планируемом роутинге и о том, действительно ли есть необходимость в появлении AS. Информация, представленная в заявке, будет занесена в базу данных и станет общедоступной. Более подробное описание заявки см. ниже. Aut-num Object В темплейте aut-num object даются сведения об организации и ее контактных лицах. Обязательными являются поля aut-num, descr, admin-c, tech-c, mnt-by. Поле aut-num служит для указания номера, который будет присвоен. В полях admin-c, tech-c указываются nic-hdls. В поле mnt-by указывается maintainer, служащий опознавательным знаком того, кто имеет право вносить изменения в записи базы данных. Mntner Object Maintainer обязателен для aut-num object базы данных RIPE. Он указывает, куда направлять и нформацию об изменениях в б/д. Если Ваш Maintainer еще не зарегистрирован, укажите его в заявке на Автономную Систему. Темплейт мntner object содержит, среди прочих, обязательные поля mntner, descr, admin-c, tech-c, auth, upd-to, mnt-by, notify, changed, source. Более подробно см. ripe-120 [Karrenberg94b]. Person Objects Эти темплейты содержат такие поля, как person, address, phone, fax-no, nic-hdl, e-mail. Имя персоны указывается полностью, номера телефона и факса - с кодом страны. Технические детали (Technical Details) Сеть может получить номер AS лишь в том случае, если Для того, чтобы облегчить процесс обработки заявки, а также для скорейшего разрешения проблем, которые могут возникнуть, когда заработает Автономная Система, необходимо, чтобы контакты (admin-c и tech-c) были зарегистрированы в б/д. Админитстративно-ответственное лицо должно быть постоянным сотрудником организации, приславшей заявку на присвоение номера AS. она multi-homed. При составлении заявки на номер AS необходимо изложить роутинговую политику будущей Автономной Системы. Для этого служат следующие поля aut-num object: as-in, as-out (в них дается информация о принимаемых и распространяемых анонсах), и default (запись о маршруте по умолчанию). Оценка запроса. Заполненная заявка направляется хостмастеру RIPE NCC. Ей будет дана оценка в соответствии с тем, действительно ли есть необходимость в прсвоении номера AS. Если решение будет положительным, NCC введет всю информацию в базу данных и известит локальную регистратуру о присвоении номера AS. 8. Соглашения о внешнем роутинге При выделении адресов важно, чтобы учитывалась возможность их маршрутизировать, - что способствует минимизации сложности роутинга в Интернете в целом. Поэтому принцип аггрегатирования играет главную роль в распределении адресного пространства. Каждый хост в Интернете имеет роутинговую таблицу с указанием пути, по которому направляются пакеты, чтобы достичь места назначения. В этой части документа мы обсудим, как используются анонсы о сетях для построения роутинговых таблиц, и как аггрегатирование позволяет сохранить их объем небольшим. Мы коснемся также вопроса о значении регистрации маршрутов для политики глобального роутинга и о методах анализа роутинговой политики различных сервис-провайдеров. Сервис-провайдеры могут принять участие в обсуждении этих проблем в дискуссионных группах, таких как routing-wg@ripe.net, eof@ripe.net, cidr@iepg.org. Информацию о первых двух можно получить по адресу majordomo@ripe.net, включив list в текст письма. Относительно последней можно обратиться по адресу cidrd-request@iepg.org. 8.1. Происхождение роутинговой информации Выделив адреса для сети пользователя, следует предоставить машинам этой сети возможность связываться со всеми другими машинами в Интернете. Это означает, что надо каким-либо образом объявить всем, куда посылать пакеты, предназначенные для этой сети. Информация о маршруте (route information) - это информация о том, каким образом можно связаться с хостами, использующими данное адресное пространство. На практике сети анонсируются через протоколы роутинга. Одна AS связывается с другой (другими) соседними AS благодаря анонсу своего блока адресов. Чаще всего для этой цели используется протокол BGP (см.RFC 1771 [Rekhter95a]). Информацию о том, как производится конфигурация аппаратного обеспечения, можно найти в [Nussbacher96a]. Разумеется, анонсируются только сети с Public адресами, сети с Private адресами не анонсируются. Прежде чем объявить о маршруте, следует удостовериться в том, что адреса зарегистрированы в б/д RIPE. По возможности, провайдеры должны формировать маршруты для выделенных им CIDR адресов. Не следует без особой необходимости анонсировать специфики. Если сеть не является multi-homed, более, чем один анонс вовне свидетельствует об ошибках конфигурации. 8.2. Распространение роутинговых анонсов Кроме оповещения о своих маршрутах, Автономные станции также распространяют чужие анонсы соседним с ними AS, что позволяет, если все в порядке, связываться друг с другом двум любым хостам в Интернете. Чтобы поддерживалось такое состояние работы Интернета, сервис-провайдеры, анонсирующие свои сети, должны следовать установленным правилам: Анонсировать только зарегистрированные в б/д адреса. Распространяя анонсы, заботиться о том, чтобы не помешать общей связи. Роутинговой политики, которая ограничивает возможности других провайдеров, следует избегать. Если провайдер использует роутинговую политику, согласно которой длина префикса принимаемых и распространяемых анонсов ограничена, он должен при любых обстоятельствах разрешать анонсы с префиксом равным минимальному размеру блока, из которого выделены анонсируемые адреса. Для адресного пространства, распределяемого RIPE NCC (193/8, 194/8 и 195/8), минимальный размер блока - /19. Таким образом, любая роутинговая политика, допускающая эту длину префикса в указанном диапазоне, гарантирует доступность адресов в сфере сервиса RIPE NCC . В противном случае могут возникнуть проблемы как для этих адресов, так и для множества других хостов в Интернете. Определяя свою роутинговую политику, сервис-провайдеры могут использовать базу данных RIPE. Там они могут получить информацию о зарегистрированных адресах и их типе (PI/PA). 8.3. Аггрегатирование. Очень важно, чтобы провайдеры при построении своей сети имели ясное представление о различии внешнего и внутреннего роутинга. Центральные роутеры Интернета значительно перегружены излишней информацией, что, как известно, может приводить к сбоям. Единственный способ обеспечить стабильное подключение к Интернету √ максимально аггрегатировать маршруты. В большинстве случаев нет необходимости показывать маршруты сетей клиентов. Однако, если через Вас подключены клиенты, использующие адреса не из Вашего блока, им следует настоятельно рекомендовать перенумерацию сетей и использование РА адресов. Только тогда их сети станут доступны без анонса специфик. Это относится как к клиентам с РI адресами, так и к клиентам с РА адресами, выданными другим сервис-провайдером. В первом случае РI адреса редко бывают в действительности нужны. Во втором сам факт, что адреса имеют статус РА, означает, что владелец готов их поменять при смене провайдера. 8.4. Регистрация маршрутов в б/д RIPE . Все вновь сформированные маршруты должны быть оформлены в роутинговой регистратуре. Это делается с целью создания route object, как это описано в ripe-181[Bates94a]) б/д RIPE. Поскольку каждый маршрут формируется в автономной системе (AS), cодержание полей в rout object соответствует содержанию полей в aut-num object, описывающем роутинговую политику AS. Существует несколько доступных и полезных приложений, которые используют информацию роутинговой регистратуры при определении роутинговой политики и для отладки. Имеются в виду следующие приложения: prtraceroute Отслеживает маршрут прохождения пакетов к заданному хосту, показывая каждому роутеру на своем пути номер As, к которой он принадлежит, и как маршрут соотносится с роутинговой политикой, хранящейся в роутинговой регистратуре. prpath Показывает все возможные пути между двумя любыми точками (адресами) согласно информации роутинговой регистратуры. prcheck Проверка семантики синтаксиса в aut-num object и факта действительности существования объекта. Для более подробной информации по Routing Registry см. [Bates94b]. |
