RIPE и политика распределения адресных ресурсов

В этом году (2009) RIPE отпраздновал свое 20-летие. Оглядываясь назад, мы видим двадцатилетнюю историю успешного развития европейского Интернета и связанного с ним сообщества RIPE. Это был также период становления и развития системы распределения адресного пространства IPv4 - фундаментального протокола сети Интернет. Глядя вперед, мы ожидаем грядущие изменения, связанные с опустошением пула свободных адресов IPv4 и внедрением IPv6. Изменения, которые могут затронуть основополагающие принципы архитектуры Сети, политику распределения адресных интернет ресурсов (АИР), и все сообщество в целом. Это неопределенное будущее рождается уже сегодня, в том числе и в оживленных обсуждениях новых политик, в которые каждый может внести свой вклад.

Что такое политика? Как принять участие в обсуждении? Какие вопросы волнуют сообщество сегодня? Эта статья делает попытку ответить на эти и другие вопросы.

Но сначала немного истории.



RIPE и RIPE NCC

Вторая половина 80-х прошлого века ознаменовалась быстрым развитием компьютерных сетей, основанных на протоколе IP. Надо сказать, что в то время IP в Европе был своего рода гадким утенком. Существующие телефонные компании, монополисты в своей стране, продвигали сети коммутации пакетов, основанные на сетевой модели OSI (Open System Interconnection - взаимодействие открытых систем) и связанной с ней системе протоколов. Эти протоколы, большинство из которых, кстати, кануло в лету, были документированы в тщательно разработанных стандартах, основывались на 7 уровневой модели (от физического до уровня Приложений), и позволяли сетям и приложениям различных операторов взаимодействовать друг с другом. Все это было хорошо, за исключением того, что эта работа носила теоретический характер, пыталась предвидеть и решить все будущие потребности пользователей и делала это с точки зрения телекоммуникационных компаний.

С другой стороны, практические требования существующих пользователей сетей передачи данных, в основном университетов и научно-исследовательских центров, были достаточно просты - предоставьте нам канал передачи данных за разумную цену, а с протоколами мы сами разберемся. В большинстве случаев для передачи данных использовалась более простая система TCP/IP, хорошо зарекомендовавшая себя в научно-исследовательских сетях США. Понятно, что такие запросы не встречали радушного отклика со стороны телекоммуникационных компаний и организаций, отвечающих за стандартизацию в этой области (Международная Организация по Стандартизации - ISO и Международный Союз Электросвязи - ITU).

Можно сказать, что развитие академических сетей в Европе во многом проходило под знаком борьбы демократичного и прагматичного TCP/IP с жесткой и дорогостоящей системой OSI. По своему характеру эта деятельность хорошо соответствовала процессам либерализации, происходившим в Европе - окончание холодной войны и падение железного занавеса, движения за независимость и демократию.

В это время создаются различные организации и сообщества для финансирования и координации развития академических сетей. Некоторые из них имеют французские названия с английскими акронимами - мода времени. Например, RARE - Réseaux Associés pour la Recherche Européenne (Европейское сообщество научно-исследовательских сетей). Или RIPE - Réseaux IP Européens (Европейские IP-сети).

Многие из этих организаций сыграли свою роль и стали частью истории Интернета. RIPE в этом году отпраздновал свое 20-летие и продолжает работать и развиваться. Победил и протокол IP - система OSI оказалась слишком жесткой и зарегулированной для иновационного и бурно развивающегося Интернета.

Европейские IP-сети в 1990 году (ftp://ftp.ripe.net/ripe/docs/ripe-026.ps)

История RIPE началась с совещания в мае 1989 года в Амстердаме, Нидерланды, хотя формальное определение RIPE появилось несколькими месяцами позже, на втором совещании RIPE. Тогда представители ведущих европейских академических сетей договорились о создании форума "для обмена технической информации и опытом в области построения IP-сетей". Тогда же были определены основные направления деятельности:

Надо заметить, что распределение IP адресов не являлось предметом обсуждения. В то время распределением адресного пространства занимался сетевой информационный центр научно-исследовательского института SRI International, игравший роль т.н. глобальной Интернет Регистратуры. Эту роль SRI получил от IANA (Internet Assigned Numbers Authority) - организации, в целом отвечающей за распределение различных числовых идентификаторов, необходимых для работы Интернета. Однако по мере развития и интернационализации Интернета, на повестку дня встал вопрос создания более развитой системы распределения адресного пространства. В августе 1990 года IETF (Internet Engineering Task Force - организация, занимающаяся разработкой стандартов Интернет) выпустил соответствующий документ за авторством Винта Серфа (Vint Cerf) "Рекомендуемая Политика Распределения Адресных Идентификаторов Интернет (IAB Recommended Policy on Distributing Internet Identifier Assignment) - RFC 1174 (http://tools.ietf.org/html/rfc1174).

И уже в тот же месяц на рассмотрение участников 6-го совещания RIPE было вынесено предложение о создании Сетевого Координационного Центра RIPE (RIPE NCC) со следующими задачами:

Назначение Даниела Карренберга (Daniel Karrenberg) генеральным директором RIPE NCC, а также размещение центра в нидерландском Национальном Институте Ядерной Физики и Физики Высоких Энергий NIKHEF было утверждено в январе 1992 года советом RARE, которое в то время обеспечивало юридическую платформу для новой организации. В апреле того же года RIPE NCC был формально представлен участникам 12-го совещания RIPE. RIPE NCC арендовал 2 комнаты в NIKHEF, а его штат насчитывал 3 человека.



Краткая история политики распределение адресных ресурсов

Одной из задач RIPE NCC являлось создание "делегированной" Интернет Регистратуры в рамках концепции, предложенной в RFC1174. Уже в сентябре 1992 года RIPE NCC начал обслуживать запросы на получение адресного пространства от европейских организаций.

Двумя месяцами раньше, в июле, был опубликован документ (RIPE NCC Internet Numbers Registration Procedures, ripe-065), который можно считать первой политикой распределения ресурсов. Правда назывался он Процедурой Регистрации Адресов, каковой, собственно, и являлся. Эта процедура содержала ряд требований:

Процедура являлась достаточно простой и неформальной. Немногим позже она была формализована с созданием форм запроса, в которых помимо контактных данных, заявитель был должен предоставить сведения о размере сети и перспективах ее роста на ближайшие 2 года. Обсуждение этих документов происходило в рамках образованной рабочей группы Local IR.

В то время разработка системы и политики распределения адресных ресурсов происходила в рамках IETF. Помимо упомянутого основополагающего документа RFC 1174, в мае 1993 года вышел более полный документ "Руководящие принципы Управления Адресным Пространством (Guidelines for Management of IP Address Space) - RFC1466 (http://tools.ietf.org/html/rfc1466). Этот документ, который активно обсуждался и был согласован с RIPE, явился основой политики распределения адресных ресурсов в Европе.

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

Существовала, правда, возможность получить адресное пространство непосредственно от РИР, которое являлось независимым от провайдера. Такие ресурсы так и назывались - Независимые от провайдера (Provider Independent, PI). Все остальные ресурсы получили название Агрегируемых (Provider Aggregatable, PA). Независимые ресурсы являлись более "дорогостоящими" для Интернета, поскольку не могли быть агрегированы в большие блоки и тем самым оказывали большую нагрузку на систему маршрутизации. Надо сказать, что в то время ресурсы маршрутизаторов были достаточно ограничены и рост маршрутизационных таблиц представлял серьезную проблему. Было даже предложено остановить выдачу ресурсов PI, однако RIPE выступил против, опасаясь необходимости усиления регулирующих функций RIPE NCC как последствие такого решения. В ответ было решено усилить разъяснительную работу среди запрашивающих ресурсы PI, акцентируя внимание, что данные ресурсы могут иметь проблемы с глобальной маршрутизацией.

Летом 1995 года концепция "агрегируемых" (Provider Aggregatable) и "независимых" от провайдера (Provider Independent) адресных ресурсов была включена в политику распределения адресных ресурсов и документирована в ripe-127.

В это же время перед Интернетом стояла еще одна проблема - проблема будущей нехватки адресного пространства. Хотя внедрение CIDR отсрочило опустошение пула свободных адресов, внимание общественности было привлечено к более бережливому распределению конечного ресурса. Надо отметить, что решение задачи сохранения адресных ресурсов, усугубляет решение проблемы роста таблиц маршрутизации и наоборот. Дело в том, что для сохранения адресного пространства желательно выделять как можно меньшие блоки адресов, минимизируя резервирование, в то время как для оптимальной маршрутизации важно, чтобы адресные блоки сервис провайдера были максимально агрегируемы. Вопрос верного баланса между этими взаимно противоречащими целями впервые появился на повестке дня 23-й конференции RIPE (январь 1996 года), и с тех пор является ключевым в обсуждении различных правил и параметров распределения.

Осенью 1996 года были опубликованы два документа. Один, традиционно подготовленный в рамках IETF, RFC2050 (http://tools.ietf.org/html/rfc2050), назывался Руководящие Принципы Распределения IP Адресов Интернет Регистратурой (Internet Registry IP Allocation Guidelines). По-существу, данный RFC документировал существовавшую до этого времени практику распределения, которая являлась основой политик RIPE. Второй назывался Политика и Процедуры Европейской Интернет Регистратуры (European Internet Registry Policies and Procedures, ripe-140) и являлся обобщением принципов, правил и процедур, связанный с распределением адресного пространства RIPE NCC. Этот документ явился плодом многомесячного обсуждения в рамках рабочей группы Local IR и явился вехой, обозначившей образование независимой региональной политики RIPE. С этого момента процесс разработки политик, связанных с распределением адресных ресурсов происходит в списках рассылки рабочей группы Local IR.

Этот документ представил основные принципы распределения адресного пространства:

Уникальность
- основополагающее требование для глобальной системы распределения АИР. Каждый присвоенный адрес должен быть уникальным в глобальной сети Интернет.
Агрегируемость
- иерархическое распределение адресов позволяющее оптимизировать глобальную систему маршрутизации. Распределение адресных ресурсов, учитывающее топологию сети и взаимоотношения провайдер-клиент позволяет оптимизировать маршруты и, как следствие, уменьшить нагрузку на глобальную системы маршрутизации.
>Сохранение
- распределение ресурсов "по потребностям", минимизация неиспользуемых запасов.
Регистрация
- регистрация распределенных и присвоенных АИР в общедоступной базе данных для поддержки уникальности и решения сетевых проблем на любом уровне.

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

Что такое PDP и как в нем участвовать

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

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

Хотя процесс не был формализован, он основывался на трех принципах:

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

Такая система прекрасно работала, когда сообщество RIPE было достаточно мало и однородно. Однако по мере роста сообщества усиливались требования по структуризации и формализации процесса.

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

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

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

В сентябре 2005 года был опубликован документ Процесс Разработки Политики в RIPE ("Policy Development Process in RIPE") под авторством Роба Блокзайла (Rob Blokzijl), описывающий основные принципы и элементы этого процесса. С тех пор документ прошел через две ревизии, но основа его сохранилась прежней.

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

Таким предложением может быть изменение или дополнение в существующую политику, или совершенно новая политика RIPE.

В случае, если такое предложение имеется, необходимо соответствующим образом оформить его (структура проекта политики приведена в документе). Проект политики обычно представляется через председателя соответствующей рабочей группы. В случае, когда неочевидно, к какой рабочей группе относится предложение, проект можно представить через председателя RIPE по адресу policy-proposal@ripe.net. Кстати, RIPE NCC может оказать помощь в подготовке проекта.

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

Сначала предложение проходит стадию Обсуждения (Discussion phase). Эта фаза начинается с анонсирования нового предложения. Для этого используется список policy-announce@ripe.net. Тогда же сообщается, в какой рабочей группе будет происходить обсуждение. Председатель рабочей группы устанавливает продолжительность периода Обсуждения - как минимум, 4 недели. По окончании этой стадии предложение может перейти в следующую стадию, отправлено на доработку с повторным обсуждением или вообще исключено. Это зависит от характера замечаний и комментариев и решается по согласованию между подателем предложения и председателем рабочей группы.

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

В стадии Рецензирования работа идет над фактическим текстом политики - таким, как он появится в окончательном варианте. Максимально отведенное время для этого - 4 недели. По прошествии этого времени председатель решает, был ли достигнут консенсус в отношении проекта. В случае положительного решения проект переходит в Заключительную стадию (Conclusion phase). В противном случае председатель может полностью исключить проект, отправить на доработку предложения или текста проекта (в зависимости от этого процесс начинается либо со стадии Обсуждения, или Рецензирования).

Заключительная стадия начинается с объявления "последнего звонка" (Last Call) в списках рабочей группы и policy-announce@ripe.net. В течение последующих 4 недель любой член сообщества может направить свои комментарии. Целью данной стадии является дать возможность противникам политики обозначить свою позицию, если они по каким-либо причинам не сделали этого в предыдущих стадиях. По прошествии 4 недель председатели всех рабочих групп совместно решают, был ли достигнут консенсус.


Схема процесса разработки политики (ПРП) RIPE

В случае положительного решения - объявляется новая действующая политика. Если, по мнению председателей, консенсус не был достигнут, председатели могут решить исключить проект или направить его на повторное обсуждение.

Все текущие предложения представлены на сайте http://www.ripe.net/ripe/policies/proposals/index.html. Там же можно узнать, в какой стадии находится то или иное предложение, дату окончания дискуссий и рабочую группу, в которой ведется обсуждение.

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

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

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

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



Наиболее важные политики

За годы существования RIPE сообществом были разработаны десятки различных политик, начиная с общих политик распределения АИР до специальных случаев и рекомендаций. Дюжина документов регламентируют процесс распределения АИР в RIPE сегодня. Все они доступны на сайте RIPE http://www.ripe.net/ripe/docs/index.html.

Текущие политики распределения АИР можно условно разделить на несколько категорий: глобальные политики, председаобщие и специальные региональные политики.

Глобальные политики.

Примерами глобальных политик являются политики распределения блоков IPv4, IPv6 и номеров Автономных Систем от IANA Региональным Интернет Регистратурам. Глобальной является политика, достигшая консенсуса во всех регионах (РИРах) и ICANN и требующая участия IANA или какой-либо внешней организации, связанной с ICANN, для ее осуществления. Процесс обсуждения и достижения консенсуса происходит во всех регионах более или менее независимо, следуя своим региональным правилам. Например, в RIPE обсуждение глобальной политики должно следовать ПРП. По достижению консенсуса во всех регионах, проект политики рассматривается Советом ASO - комитета ICANN по вопросам АИР. Если, по мнению Совета ASO результирующий текст адекватно представляет обсуждавшийся проект, процесс достижения консенсуса не был нарушен и мнения основных заинтересованных сторон были учтены, текст направляется в Совет ICANN для ратификации. При положительном решении новая глобальная политика вступает в действие. Полное описание процесса можно найти на сайте NRO http://www.nro.net/documents/nro4.html.

Перечислю текущие глобальные политики.

Три уже упоминавшиеся политики распределения АИР от IANA Региональным Интернет Регистратурам:

А также глобальная политика распределения оставшегося адресного пространства IPv4 Global Policy for the Allocation of the Remaining IPv4 Address Space

Общие региональные политики распределения ИР

Эти политики были утверждены сообществом RIPE и определяют принципы и правила, которым следует RIPE NCC при распределении ресурсов Локальным Интернет Регистратурам - ЛИРам. К этим политикам относятся:

Специальные региональные политики распределения ИР

Эти политики охватывают специальные случаи:

Надо заметить, что некоторые общие политики включают описание специальных случаев, например выдача адресных блоков операторам доменов верхнего уровня и ENUM в случае использования технологии аникаст (anycast) рассматривается в политике распределения адресного пространства IPv4.

Рекомендации, процедуры и формы

Наконец, в то время как политики определяют основополагающие принципы и правила, конкретное воплощение политики находит отражение в разработанных RIPE NCC процедурах и формах. Эти документы можно найти на сайте RIPE (http://www.ripe.net/ripe/docs/index.html) в разделе "Request Forms & Supporting Notes".



Текущие предложения в сообществе RIPE

Основные политики, обсуждаемые в настоящее время в RIPE, касаются АИР. Соответственно, дискуссии проводятся в списке рассылки рабочей группы Адресной Политики (Address Policy Working Group) - address-policy-wg@ripe.net.

Опустошение пула свободных адресов IPv4 является наиболее горячей темой, и ряд предложений направлены на решение связанных с этим проблем. Я постарался дать краткое описание и представить суть рассматриваемых предложений ниже. Однако для получения представления и различных позиций в обсуждении данных предложений, я рекомендую читателю самостоятельно сформировать свое мнение и принять участие в дискуссии, подписавшись на список address-policy-wg@ripe.net и прочитав соответствующие архивы этого списка.

В этой области уже существует одна утвержденная политика, о которой я уже упоминал - это глобальная политика распределения оставшегося адресного пространства IPv4 Global Policy for the Allocation of the Remaining IPv4 Address Spaces (http://www.ripe.net/ripe/docs/ripe-436.html). Суть ее заключается в следующем. IANA резервирует блок адресов IPv4, каждый размером /8, по одному для каждой РИР (на сегодняшний день - 5). Политика вступает в действие, когда очередной запрос на дополнительные адреса IPv4 от какой-либо РИР опустошает оставшийся свободный пул. В этом случае IANA объявит начало фазы “Исчерпанная” (Exhaustion) и распределит зарезервированные блоки по одному для каждой РИР.

В связи с этой политикой можно условно отметить три основных периода в системе распределения адресных ресурсов IPv4 в RIPE: текущий, период исчерпания, и период после окончательного распределения всех адресов IPv4.

На сегодняшний день проблема скорого опустошения пула адресов IPv4 не привела к каким-либо изменениям политики распределения этих ресурсов. В сообществе сильны опасения, что существенные изменения в этой области могут усугубить ситуацию - например, спровоцировать “золотую лихорадку” и только ускорить процесс опустошения. Наиболее распространенная позиция - опустошение пула IPv4 неизбежно и реальным решением этой проблемы является переход к протоколу IPv6.

Однако хотя опустошение пула неизбежно, некоторые члены сообщества выразили озабоченность, что по мере приближения к этому моменту распределение ресурсов в соответствии с текущей политикой может быть воспринято как несправедливое. Например, распределение последнего блока удовлетворит годовые потребности провайдера, запросившего его, в то время как последующие заявители останутся ни с чем. На решение этой проблемы направлен проект политики “Справедливое Опустошение Пула” - Run Out Fairly (http://www.ripe.net/ripe/policies/proposals/2009-03.html). Суть предложения заключается в постепенном уменьшении временного интервала планирования, который принимается во внимание при определении необходимого провайдеру адресного пространства. Данный интервал будет последовательно уменьшаться, начиная с принятых в настоящее время 12 месяцев до 3 месяцев по мере приближения к моменту опустошения.

К текущему периоду также относится проект, направленный на эффективное использование “исторических” ресурсов IPv4 - Ensuring Efficient Use of Historical IPv4 Resources (http://www.ripe.net/ripe/policies/proposals/2008-07.html). “Историческими” считаются ресурсы, полученные от глобальной Интернет Регистратуры до образования RIPE NCC. Суть его заключается в требовании предоставления уровня использования также и “исторического” адресного пространства при рассмотрении запроса на дополнительные адреса.

Период исчерпания рассматривается как буферный и предполагает, что распределение АИР IPv4 будет регулироваться специальной политикой. Напомню, что речь идет о распределении последнего блока размером /8. Этот период также является переходным к повсеместному внедрению IPv6. Следует отметить, что потребность в дополнительных адресах IPv4 будет продолжаться с развитием сетей и подключением новых клиентов, так как по-прежнему останется необходимость связности с Интернетом IPv4. Более подробно эти аспекты рассмотрены в моей статье “Из жизни IP адресов. Перспективы протокола IPv4 и перехода к адресации IPv6”.

В этой области в настоящее время обсуждаются два предложения.

Первое - “Use of Final /8” (http://www.ripe.net/ripe/policies/proposals/2008-06.html) - предоставляет возможность текущим и будущим ЛИРам получить один и только один блок адресов IPv4 максимальным размером равным минимальному размеру распределяемого пространства на момент исполнения данной политики (сегодня это /21). Как обычно требованием является демонстрация необходимости, но в любом случае размер полученного блока не может превышать установленный максимальный размер. Проект предполагает, что полученный блок поможет провайдеру “пережить” период исчерпания и внедрить протокол IPv6.

Второе предложение также направлено на поддержку сервис-провайдеров в переходный период исчерпания, но содержит дополнительные механизмы для стимуляции внедрения протокола IPv6 - “IPv4 Allocation and Assignments to Facilitate IPv6 Deployment (http://www.ripe.net/ripe/policies/proposals/2009-04.html)”. Еще одним отличием является то, что распределение адресов по-прежнему основано на принципе необходимости. Однако предполагается, что в этот период полученные адреса будут использоваться более эффективно с помощью технологий мультиплексирования (например, трансляторов NAT). Поэтому предлагается “смасштабировать” существующую политику распределения IPv4 с уменьшающим фактором 64. Например, в случае, если провайдер может продемонстрировать потребность в блоке /21, ему будет выделен блок /27. Соответственно, как и сегодня, провайдер может впоследствии запросить дополнительное адресное пространство при демонстрации потребности и, это является отличием от текущей политики, реального внедрения протокола IPv6 (например, показать, что ряд услуг и сетей провайдера доступны по протоколу IPv6).

Еще одним предложением, относящимся к этому периоду, является проект глобальной политики распределения блоков адресов IPv4 Региональным Интернет Регистратурам - Global Policy for the allocation of IPv4 blocks to Regional Internet Registries (http://www.ripe.net/ripe/policies/proposals/2009-01.html). Суть его заключается в глобальном распределении адресного пространства, возвращенного или рекламированного в рамках одной РИР. Например, адресное пространство, возвращенное RIPE NCC в результате добровольной акции ЛИРа, или в результате закрытия ЛИРа, будет помещено в специально созданный резервный пул IANA для последующего глобального распределения. Основной целью данного предложения является обеспечение справедливого распределения адресного пространства IPv4 в глобальном масштабе после опустошения пула свободных адресов IANA.

Заключение

Политики и стандарты, которые разрабатываются сегодня, во многом определят то, какой будет Сеть через несколько лет. Останется ли Интернет открытой системой, прозрачной для приложений, или распадется на островки с ограниченной связностью; будет ли распределение адресов основываться на потребностях, межгосударственных соглашений или адреса станут предметом торговли; изменится ли сама концепция управления Интернетом незнающая границ? Подчас трудно точно представить, какой эффект может иметь та или иная политика на ответ на эти или многие другие вопросы, и поэтому разработка этих политик требует знаний, времени, сил и главное – позиции. Но это, пожалуй, тема отдельной статьи.

Технический директор RIPE NCCАндрей Робачевский