Ripe і політика розподілу адресних ресурсів

Але спочатку трохи історії.

RIPE і RIPE NCC

З іншого боку, практичні вимоги існуючих користувачів мереж передачі даних, в основному університетів і науково-дослідних центрів, були досить прості - надайте нам канал передачі даних за розумну ціну, а з протоколами ми самі розберемося. У більшості випадків для передачі даних використовувалася більш проста система 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 виявилася занадто жорсткою і зарегульованій для іноваційного і бурхливо розвивається Інтернету.

Ripe і політика розподілу адресних ресурсів

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

  • Можливості підключення і маршрутизація (прообраз сьогоднішньої робочої групи по маршрутизації - routing-wg)
  • Мережеве управління і супровід (предтеча робочої групи по базі даних RIPE - database-wg)
  • Система доменних імен DNS (сьогодні - робоча група по DNS - dns-wg)
  • Формальна координація (адміністративна координація з організаціями-членами RIPE і з іншими організаціями, наприклад RARE)

І вже в той же місяць на розгляд учасників 6-го наради RIPE було винесено пропозицію про створення Мережевого Координаційного Центру RIPE (RIPE NCC) з наступними завданнями:

  • створення і обслуговування Європейської IP реєстратури в рамках архітектури, запропонованої в RFC1174;
  • інформаційне обслуговування мереж;
  • адміністративна підтримка RIPE.

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

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

Мінімальний розмір розподіляється простору. Чим більше мінімальний розмір, тим більша ймовірність невикористовуваних запасів. В даний час для IPv4 цей параметр дорівнює / 21, і / 32 для IPv6.

Що таке PDP і як в ньому брати участь

До деякого часу процес розробки правил розподілу АІР носив досить неформальний характер. Робота над певною політикою була відкритою, і будь-який бажаючий міг взяти в ній участь. Як правило, процес починався з підготовки проекту у вільному форматі, що описує проблему - наприклад, відсутність правил для певної ситуації, - і пропозицію щодо її вирішення.

В результаті подальшого обговорення, пропозиція або браковані (наприклад, внаслідок відсутності інтересу до представленої проблеми), або допрацьовувалося і, можливо, приймалося.

Хоча процес не був формалізований, він грунтувався на трьох принципах:

Відкритість. Будь-який бажаючий може запропонувати політику і брати участь в її обговоренні. При цьому в розрахунок приймається аргументація, а не ранги учасника або його роботодавця.

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

Консенсус. Рішення приймаються на основі консенсусу.

Обговорення пропозиції в основному відбувалося в відповідних списках розсилки, а конференції RIPE використовувалися для більш інтерактивного обміну думками. Найчастіше попереднє "зондування грунту" на предмет інтересу до передбачуваної проблеми відбувалося також на конференції RIPE.

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

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

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

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

Такою пропозицією може бути зміна або доповнення в існуючу політику, або зовсім нова політика RIPE.

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

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

Ripe і політика розподілу адресних ресурсів

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

У разі позитивного рішення - оголошується нова діюча політика. Якщо, на думку голів, консенсусу не було досягнуто, голови можуть вирішити виключити проект або направити його на повторне обговорення.

У ПРП існує кілька моментів, коли приймається рішення про подальшу долю пропозиції. Можливо, що учасники обговорення незгодні з цим рішенням. Для таких випадків передбачена спеціальна процедура вирішення спорів. Треба відзначити, що до розгляду приймаються розбіжності щодо процесу, а саме рішення про досягнення або відсутності консенсусу. Розбіжності щодо самого пропозиції, його технічних і інших якостей повинні вирішуватися в ході самого обговорення.

Можливо, що з точки зору учасника роботи над пропозицією, його погляди не були прийняті до розгляду в стадії Обговорення. Або рішення про досягнення консенсусу після закінчення стадії Рецензування здається неправомірним. У цьому випадку учасник повинен спробувати вирішити це питання з головою. Якщо це неможливо, завдання вирішення спору вирішується головами всіх робочих груп спільно шляхом голосування. Голова, залучений в суперечку, від голосування утримується. Рішення голів є остаточним.

Інший спірною ситуація може з'явитися рішення про досягнення консенсусу в Заключною стадії, яке, як ми знаємо, приймається головами всіх робочих груп спільно. В цьому випадку вищою інстанцією вирішення спору є голова RIPE. Знову ж таки, його рішення в цій суперечці є остаточним.

Рішення про виключення пропозиції не означає, що пропозиція поховано назавжди. У будь-який момент процес може бути початий наново. Це може бути те ж саме пропозицію, наприклад, якщо виявилися нові переконливі аргументи на його користь, або нова пропозиція, засноване на початковій ідеї.

Найбільш важливі політики

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

Перерахую поточні глобальні політики.

Три вже згадувані політики розподілу АІР від IANA Регіональним Інтернет реєстратура:

  • Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries
  • Internet Assigned Numbers Authority (IANA) Policy for Allocation of IPv6 Blocks to Regional Internet Registries
  • Internet Assigned Numbers Authority (IANA) Policies for Allocation of IPv4 Blocks to Regional Internet Registries

Загальні регіональні політики розподілу ІР

Ці політики були затверджені спільнотою RIPE і визначають принципи і правила, яких слід RIPE NCC при розподілі ресурсів Локальним Інтернет реєстратура - лірам. До цих політиків відносяться:

Спеціальні регіональні політики розподілу ІР

Ці політики охоплюють спеціальні випадки:

  • Розподіл АІР для використання самим RIPE NCC - Allocating / Assigning Resources to the RIPE NCC. Дана політика визначає, як сам RIPE NCC може запросити і, можливо, отримати ресурси від RIPE NCC.
  • Вимоги до договірних відносин для власників незалежних від провайдера ресурсів - Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region. Дана політика вимагає обов'язкової наявності договірних відносин між власниками таких ресурсів і "реєстратором" цих ресурсів. Як реєстратора може виступати або ЛІР (в більшості випадків це ЛІР, через яку і були отримані дані ресурси) або RIPE NCC.
  • Спеціальний випадок отримання ресурсів IPv6 для точок обмін трафіком - IPv6 Address Space Policy for Internet Exchange Points.
  • Спеціальний випадок отримання ресурсів IPv6 для серверів кореневої зони DNS - IPv6 Addresses for Internet Root Servers in the RIPE Region.

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

Поточні пропозиції в співтоваристві RIPE

У цій області в даний час обговорюються дві пропозиції.

висновок

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