Последнее изменение файла: 2007.02.08
Скопировано с www.bog.pp.ru: 2023.09.22
Bog BOS: Блоки IP адресов и их распределение
Типы адресов IP4
Общая иерархическая схема распределения IP пространства описана в RFC 1466.
IANA выделяет блоки адресов региональным регистраторам (RIR, Regional Internet Registry):
RIPE (Европа и окружающие области),
ARIN (Северная Америка),
APNIC (Азиатско-Тихоокеанский регион),
LACNIC (Латинская Америка).
Полученное адресное пространство распределяется (allocate) RIPE NCC по LIR (Local IR),
которые в дальнейшем назначают (assign) адреса конечным пользователям.
Некоторые блоки IP-адресов имеют специальное назначение (loopback, частные адреса)
и описаны в RFC 3330.
Текущее распределение пространства адресов IP4 с точностью до /8 можно узнать на сайте
IANA.
Списки недопустимых адресов в различных форматах для использования в
фильтрах можно получить здесь.
Адреса можно брать из разных мест: либо адреса выделяются LIR из
провайдерского блока адресов (Provider Aggregatable Address Space - PA),
либо заводится свое (Provider Independent Address Space -PI).
Можно также самому стать LIR (local internet registry). Для
клиентских машин адреса можно взять из пула
локальных адресов (RFC 1597, RFC 1627, RFC 1918).
В связи с ростом Интернет была введена CIDR (classless interdomain routing
- RFC1519), что позволяет
провайдеру объединять маршруты к своим
клиентам в один общий маршрут,
уменьшая таким образом нагрузку на
маршрутизаторы во всем мире. Адреса
берутся из блока
провайдера и их
приходится возвращать при
окончании контракта (должны давать 3 месяца - RFC 2008, но т.к.
канал отключен, то пользы от этого
никакой), что вызывает
значительные трудности при смене
провайдера, зато это дешево (или входит в
стоимость
минимального контракта) и проще сделать при
первоначальном
подключении. PI адреса остаются
навсегда (обычно их дает вовсе не
провайдер), но это
обходится дорого всему Интернет, т.к. такие
адреса невозможно
агрегировать. Операторы главных
транзитных маршрутов требуют
запретить выдачу PI адресов
конечным клиентам,
непонятно только как отделить
конечных клиентов от
провайдеров. Однако никто не может
гарантировать
маршрутизацию PI адресного
пространства
(неагрегируемого) на всем
протяжении интернет
(некоторые толстые
провайдеры вовсе не
принимают в свои таблицы
маршрутов блоки адресов меньше, чем скажем 2**13).
Предполагается, что
пользователи PA адресов должны платить
некоторую премию, чтобы их блоки
адресов
маршрутизировались.
Финансовая сторона вопроса.
При получении блока IP адресов от RIPE
подписывается договор об
обслуживании (ripe-191). Плата за
обслуживание
определяется ежегодно (ripe-188, ripe-189). На 1999:
регистрация малого ISP (кого считать малым
высчитывается ежегодно по хитрым схемам - ripe-187) - 2100 ECU,
плата за год - 2650 ECU (возможна
поквартальная оплата). Бюджет RIPE на 1999 г. - 4737kECU.
Опрос базы данных делается с помощью
WWW (есть даже
полнотекстовый поиск через glimpse) или whois -h whois.ripe.net
имя-объекта
Поиск делается по следующим ключам:
номер AS
имя AS-макро
имя community
имя домена (без точки на конце)
имя сети или интервал IP адресов
имя персоны или NIC handler или e-mail адрес
имя
маршрутизатора
имя mntner
имя, NIC-handle или e-mail адрес
ролевого объекта
маршрут
Был доступ через telnet, WAIS и e-mail, но
сейчас он закрыт. Правда можно
сказать telnet whois.ripe.net 43
и далее ввести ключи и строку поиска
(можно и так сделать: echo "-T тип-объекта имя-объекта" | nc -i 1 -s наш-адрес 193.0.0.135 43).
Есть версия
whois
от RIPE с
дополнительными
возможностями (поиск по
обратному ключу; поиск во всех БД,
которые дублирует RIPE (RIPNа в списке нет ;) ;
много других полезных
возможностей,
специфических для
маршрутизации и IP
интервалов). Если
используемая версия whois не
поддерживает данные ключи, то их можно
указать в строке
запроса: whois -h whois.ripe.net "-i notify имя"
-a
просматривать все
представленные в RIPE базы данных (RADB, InterNIC, ANS, MCI, CANET, APNIC)
-c показывать атрибуты changed
-i
список-атрибутов , где в список
атрибутов могут входить
admin-c
tech-c
zone-c
notify (=admin-c, tech-c и zone-c)
origin (кто входит в эту AS)
mnt-by (кого "держит" этот
управляющий)
author
поиск объектов, которые
ссылаются на данный объект в в
указанных атрибутах
-L найти менее
специфичные
соответствия, например
whois -h whois.ripe.net "-r -L 195.161.1.0" найти кто
владелец сетки и
ееохватывающих сеток
-m найти объекты на один уровень более
специфичные (т.е.
непосредственно входящие)
-M найти объекты более
специфичные (т.е. входящие на любом уровне
иерархии)
-t
тип-объекта выдает шаблон
объекта (all - шаблоны всех
объектов)
-v
тип-объекта выдает
детальное описание шаблона объекта (all -
шаблоны всех объектов)
-T
тип-объекта выдает
найденные объекты только
указанного типа
Изменение в базе данных только с
помощью email: auto-dbm@ripe.net.
Создание объекта mntner делается
вручную по адресу ripe-dbm@ripe.net
(провозглашается тезис, что
удобство
использования выше, чем
безопасность!) Дают только тем, кто
отвечает за
распределение
публичного IP
пространства, доменных имен или
маршрутизацией.
Предполагается, что данная
личность уже имеет объекты в БД RIPE.
Создание автономной системы вручную по
адресу: hostmaster@ripe.net.
Если в заголовке Subject указать слово NEW, то
предотвращается изменение старого
объекта. Измение объекта
предлагается делать так: запрос
текущего состояния,
изменение полей, создание объекта (старое
содержимое
затирается). ═Мда, хранить в такой базе
незащищенные объекты стремное дело. При
изменении или удалении объекта
проверяется
сохранение
целостности базы данных (не удаляем ли мы
объект, на который есть ссылки, или
создает объект,
ссылающийся на
несуществующие объекты).
Удаление делается в том же формате, что и
создание (так!), только в конце
добавляется строка: delete: причина
удаления
В базе данных хранится
информация о IP сетях, доменах и
маршрутизации, а также
вспомогательная
информация
(контактная
информация,
аутентификация и др.). База данных
состоит из объектов. Объект
представляет набор
атрибутов и значений
атрибутов.
Характеристики атрибутов: только один
атрибут/множество атрибутов данного типа в одном
объекте;
обязательный
атрибут/опциональный. Типы
объектов (A - all, I - IP address, D - domain, R - routing data base):
A mntner
A key-cert
A person - контактные
координаты личности
A role - играемая роль (например, sysadm)
I inetnum - адресное
пространство
I inet6num
D domain
R aut-num - номер
автономной системы (AS)
R as-macro - группа AS
R community - группа
маршрутов
R route - маршрут
R dom-prefix -
R inet-rtr - имя
маршрутизатора
Извещение об
изменении: каждый объект может иметь
атрибут notify (multiple, optional),
значением которого является e-mail адрес. При
каждом изменении объекта по этому адресу
(адресам) будет
направлено письмо с ябедой.
Право на
изменение объекта: каждый объект может быть
связан с одним или
несколькими
управителями (maintainers) с помощью
атрибута mnt-by (multiple, optional),
указывающего на объект типа mntner. Объект mntner
создается вручную
персоналом RIPE NCC :( ибо в
основном
предназначен для защиты таблиц
маршрутизации
(подозреваю, что выдается вместе с AS):
mntner: [mandatory] [single] - строка букв, цифр и
минусов
descr: [mandatory] [multiple]
admin-c: [mandatory] [multiple] - имя О
фамилия или nic-handle
менеджера
tech-c: [optional] [multiple] - имя О
фамилия или nic-handle
технического
специалиста
upd-to: [mandatory] [multiple] - e-mail адрес, на
который будет
отправляться сообщение при попытке
нарушения прав доступа к объекту,
управляемому данным mntner
mnt-nfy: [optional] [multiple] - e-mail адрес, на
который будет
отправляться сообщение при
успешном изменении объекта,
управляемого данным mntner
auth: [mandatory] [multiple] - схема
аутентификации, если
используется несколько схем, то
достаточно пройти хотя бы одну,
выдается по whois любому
желающему:
NONE
CRYPT-PW
шифрованный с помощью crypt(3) пароль (13
символов). В этом случае все письма с
изменениями закрытых данной схемой
объектов должны включать
строку
password:
нешифрованный-пароль
(действует до конца письма или
следующей строки "password:")
MAIL-FROM
регулярное-выражение
(которое
сравнивается с
заголовком From: из письма)
PGPKEY-ид-ключа
поддерживается DSS и RSA (письма с
изменением
защищенного объекта д.б.
подписаны данным ключом). Нужна
лицензия на
коммерческое
использование PGP.
remarks: [optional] [multiple]
notify: [optional] [multiple] - e-mail адрес
mnt-by: [optional] [multiple] - ссылка на mntner (м.б. на
себя самого)
changed: [mandatory] [multiple] - e-mail YYYYMMDD (в
старых объектах м.б. только две
последние цифры года)
source: [mandatory] [single] строка "RIPE"
Запрет на создание объектов уровнем ниже в
иерархии (для inetnum и domain)
осуществляется с
использованием атрибута mnt-lower в
котором
определяется mntner.
Для поддержки защиты PGP
используется объект key-cert:
key-cert: [mandatory] [single] [primary/look-up key]
имеет формат PGPKEY-ид, где ид - это 8
шестнадцатеричных цифр.
Адреса из блоков
некоторых
провайдеров СНГ
поддерживает РосНИИРОС. Другие
провайдеры делают это сами, но
процедуры очень похожи,
основываются на ripe-141, ripe-142 и
описаны у
РоснИИРОС. Почтовые адреса для
посылки заявок в формате ripe-141 (иногда
провайдер все делает сам, надо только иметь
DNS-сервер):
ip-reg@ripn.net - для
провайдера, LIR которого
поддерживается РосНИИРОС или Relarn
Обычно письма
принимаются только в koi8-r в формате
простого текста (без MIME и прочих
вложений). Все формы д.б.
заполнены только на
английском языке.
Комментарии - на русском. Заявку надо
составлять тщательно,
придираются ко всему, начиная с
формального
заполнениявсех граф и строчек.
Обработка занимает
значительное время (свой LIR надо пинать к тому же по
телефону).
Формат заявки,
посылаемой
пользователем своему
провайдеру (который
выступает здесь в качестве LIR),
который проверяет ее и
пересылает в RIR (в данном случае RIPE):
X-NCC-RegID:
идентификатор LIR, иэ
адресного
пространства которого д.б.
назначен блок адресов (например, ru.demos -
Демос/large, ru.rosprint - Глобал Один/large, ru.rostelecom -
Ростелеком/medium)
#[OVERVIEW OF ORGANIZATION
TEMPLATE]#
должна быть подробно описана
организация, ее структура и как
адресное
пространство будет
использовано в различных
подразделениях. Зачем такая
подробность?!
#[REQUESTER TEMPLATE]# с кем и как
контактировать в
организации,
посылающей запрос (LIR)
name: полное имя человека (без точек)
organisation: полное название
организации
country: RU
phone: +7 095 9327647
fax-no: +7 095 9327410
e-mail:
#[USER TEMPLATE]# с кем и как
контактировать в
организации, которая будет
использовать адреса
name:
organisation:
country:
phone:
fax-no: (optional)
e-mail:
#[CURRENT ADDRESS SPACE USAGE TEMPLATE]# какие
адреса были назначены
организации ранее и какие планы на их счет
(каждая физическая подсеть д.б. описана
отдельно! Зачем такая
подробность?!)
Prefix SubnetMask Size Current 1-yr 2-yr Description
prefix - адрес сетки (начало
адресного блока)
SubnetMask - маска
Size -
максимальное число хостов
Current -
используется сейчас
1-yr - будет
использоваться в этом году
2-yr - будет
использоваться через два года
Description -
назначение и роль подсети
Addresses Used
Prefix Subnet Mask Size Current 1-yr 2-yr Description
193.1.193.0 255.255.255.192 64 28 34 60 Candy Cane Dept.
193.1.193.64 255.255.255.224 32 10 21 28 Toy Design
193.1.193.96 255.255.255.224 32 8 13 27 Toy Manufacture
193.1.193.128 128 Unused
193.1.194.0 255.255.254 512 317 429 480 Reindeer Training
193.1.196.0 255.255.255 256 132 200 230 Naughty or Nice
1024 495 697 825 Totals
#[REQUEST OVERVIEW TEMPLATE]# в БД не
вносится
request-size: число
запрашиваемых адресов
addresses-immediate: сколько адресов будет
использовано
немедленно (д.б. больше 1/4 числа
запрашиваемых адресов)
addresses-year-1: сколько адресов будет
использовано в течении 12 месяцев (д.б.
больше 1/2 числа
запрашиваемых адресов)
addresses-year-2: в течении 2 лет
subnets-immediate: подсеток
немедленно
subnets-year-1:
subnets-year-2:
inet-connect: будет ли
подсоединение к Интернет (will never connect, already connected through ...,
plan to connect когда через кого)
country-net: RU
private-considered: имеются в виду адреса из пула
локальных адресов (private address space)
request-refused: если на
предыдущий запрос был отказ, то кто
отказал и почему
PI-requested: нужен ли PI
адресный блок
address-space-returned: если старый
адресный блок будет
возвращен, то указать здесь в
формате
начало - конец to кому before YYYYMMDD
#[ADDRESSING PLAN TEMPLATE]# формат
аналогичен шаблону для текущего
адресного
пространства (будет выделено SIZE
адресов в строке Totals ;)
ripe-178 - RIPE Routing-WG Recommendation for
coordinated route-flap damping parameters
ripe-179 - Test Traffic Measurement Project Security
Document
ripe-180 - Test Traffic Data Disclosure Policy
ripe-181
ripe-183
ripe-185 - European Internet Registry Policies and
Procedure
(перевод:
Европейская система регистрации IP-адресов. Общие принципы и порядок
проведения)