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.

Работа с базой данных RIPE (маршрутизация и домены не описаны)

Вся информация только на английском.

Опрос базы данных делается с помощью 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 любому желающему:
1. NONE
2. CRYPT-PW шифрованный с помощью crypt(3) пароль (13 символов). В этом случае все письма с изменениями закрытых данной схемой объектов должны включать строку
  password: нешифрованный-пароль (действует до конца письма или следующей строки "password:")
3. MAIL-FROM регулярное-выражение (которое сравнивается с заголовком From: из письма)
4. 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 шестнадцатеричных цифр.
method: [generated] [single] [ ] генерируется из certif, ручной ввод игнорируется
owner: [generated] [multiple] [ ]
fingerpr: [generated] [single] [ ]
certif: [mandatory] [single] [ ] публичный ключ, экспортированный в ASCII формате (включая маркеры BEGIN и END и пустые строки)
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Шаблон domain:

domain: [mandatory] [single] [primary/look-up key]
descr: [mandatory] [multiple] [ ]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
zone-c: [mandatory] [multiple] [inverse key]
nserver: [optional] [multiple] [ ]
sub-dom: [optional] [multiple] [ ]
dom-net: [optional] [multiple] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [optional] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [ ]
refer: [optional] [single] [] ссылка на whois сервер настоющего владельца в формате
тип хост порт
где тип может быть:
- RIPE (whoisd от RIPE)
- InterNIC (whoisd от InterNIC)
- SIMPLE (простой whoisd)
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Шаблон role (не может использоваться в admin-c), очень похож на person:

role: [mandatory] [single] [primary/look-up key]
address: [mandatory] [multiple] [ ]
phone: [optional] [multiple] [ ]
fax-no: [optional] [multiple] [ ]
e-mail: [mandatory] [multiple] [look-up key]
trouble: [optional] [multiple] [ ] - ссылки на дополнительную информацию
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
nic-hdl: [mandatory] [single] [primary/look-up key]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]

Provider Aggregatable Address Space

Адреса из блоков некоторых провайдеров СНГ поддерживает РосНИИРОС. Другие провайдеры делают это сами, но процедуры очень похожи, основываются на ripe-141, ripe-142 и описаны у РоснИИРОС. Почтовые адреса для посылки заявок в формате ripe-141 (иногда провайдер все делает сам, надо только иметь DNS-сервер):

noc@demos.ru - Демос
registry@rt.ru - Ростелеком
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 ;)
- Prefix# Subnet Mask Size Immediate 1yr 2yr Description
#[NETWORK TEMPLATE]#
- inetnum: mandatory single - определяет интервал IP адресов, заполняется LIR после утверждения заявки
  - 192.87.45.0 - это одна сетка класса C
  - 192.87.44.0 - 192.87.45.0 - блок из двух сеток класса C (пробелы важны!)
  - т.к. реальный адрес обычно неизвестен в момент заполнения, то можно вписать x.x.x.x/23 (для двух сеток C)
- netname: mandatory single - имя для интервала IP адресов (буквы, цифры и минус)
- descr: mandatory multiple - описание организации и месторасположение
- country: mandatory single - RU (две буквы в соответсвии с ISO 3166)
- admin-c: mandatory multiple - e-mail адрес администратора (должен физически находиться в расположении сети)
- tech-c: mandatory multiple - e-mail адрес технического специалиста (м.б. консультант со стороны)
- rev-srv: optional multiple - полное доменное имя хоста (без последней точки), на котором работает DNS-сервер, обслуживающий обратный домен
- remarks: optional multiple
- status: mandatory single
  - ALLOCATED PA - блок адресов выделен IR (Internet Registry) для дальнейшего распределения только в виде PA
  - ALLOCATED PI - адресное пространство выделено LIR, и все выдаваемые из него адреса являются PI
  - ALLOCATED UNSPECIFIED - адресное пространство выделено IR, адреса выданные из него могут быть как PA, так и PI
  - ASSIGNED PA - адрес из пула провайдера, выданный конечному пользователю
  - ASSIGNED PI - адрес, независимый от провайдера, выданный конечному пользователю
- mnt-by: optional mutliple - ссылка на mntner
- notify: optional mutliple - e-mail адрес
- changed: mandatory multiple - e-mail YYYYMMDD
- source: RIPE
#[PERSON TEMPLATE]# если не заведено в БД RIPE ранее
- person: mandatory single - полное имя, желательно в формате: Имя О Фамилия
- address: mandatory multiple - поный почтовый адрес в международном порядке: организация, улица, дом, город, страна
- e-mail: optional multiple
- phone: mandatory multiple - +7 095 9327647
- fax-no: optional multiple - +7 095 9327410
- mnt-by: optional mutliple - ссылка на mntner
- notify: optional multiple - e-mail адрес
- nic-hdl: optional single - уникальный идентификатор персоны, при создании можно указывать
  - AUTO-1
  - AUTO-1инициалы
- changed: mandatory multiple - e-mail YYYYMMDD
- source: RIPE
#[TEMPLATES END]#

Provider Independent Address Space

Не гарантируется маршрутизация по всему Интернет.

LIR

Требуются значительные капитальные вложения.

Наши объекты в БД RIPE.

person: SEB-RIPE

person: EMS-RIPE

Ссылки

ripe-001 - RIPE Terms of Reference
ripe-063 - RIPE Recommendation on Operational Contacts
ripe-114 - Taking Care of Your Domain
ripe-119 - шаблоны для сетей и персон (здесь же описано как оформлять запросы на изменение в БД)
ripe-120 - авторизация доступа и извещение об изменениях в базе данных RIPE
ripe-127 - разница между Provider Aggregatable Address Space и Provider Independent Address Space
ripe-140 - типы адресных пространств (замещен ripe-185)
ripe-141 - форма заполнения заявки на назначение адресов
ripe-142 - инструкция по заполнению формы
ripe-143
ripe-147 - заявка на AS
ripe-152 - финансовые вопросы LIR
ripe-154 - тренировка LIR в RIPE NCC
ripe-155 - распределение адресов класса A
ripe-157 - как работать с базой данных RIPE
ripe-158 - Internet Delay Measurements using Test Traffic. Design Note.
ripe-159 - правила и процедуры (замещен ripe-185)
ripe-160 - как стать LIR
ripe-161 - A New Structure for the RIPE NCC De-Facto Organisational Rules (Revised)
ripe-164 - The Financial Separation of TERENA and RNA
ripe-165 - RIPE NCC Tax Position for 1998 and Beyond
ripe-167 - A Regional Internet Registry for the Commonwealth of Independent States
ripe-168 - Internet Delay Measurements using Test Traffic. Installing and hosting a Test Box.
ripe-170
ripe-171 - RIPE NCC Annual General Meeting October 15th 1998 (DRAFT) Minutes
ripe-173 - RIPE NCC General Terms and Conditions
ripe-174 - RIPE NCC Conflict Arbitration Procedure
ripe-177 - RIPE CENTR Proposal
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-адресов. Общие принципы и порядок проведения)
ripe-186 - RIPE NCC Activities &enditure 1999 (оправдываются куда уходят собранные деньги)
ripe-187 - RIPE NCC Charging Scheme 1999 (как расчитывается размер оплаты)
ripe-188 - RIPE NCC Billing Procedure and Fee Schedule 1999 (сколько платить)
ripe-189 - изменения к ripe-157 (работа с БД RIPE) (по состоянию на 14 января 1999)
ripe-190 - раздача лицензий на PGP (дают нахаляву всем, кто имеет mntner в БД RIPE)
ripe-191 - The Standard RIPE NCC Service Agreement (форма соглашения/договора об обслуживании, для юристов)
рекомендации по заполнению заявки ripe-141 от РосНИИРОС
RFC, посвященные IP адресации и распределению IP адресов (разобрано до RFC2505: 791, 792, 917, 919, 922, 932, 936, 940, 950, 1122, 1219, 1466, 1467)
RFC 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR).
RFC 1518 An Architecture for IP Address Allocation with CIDR
RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy.
RFC 1520
RFC 1597 Address Allocation for Private Internets.
RFC 1627 Network 10 Considered Harmful (Some Practices Shouldn't be Codified).
RFC 1744 Observations on the Management of the Internet Address Space.
RFC 1797 Class A Subnet Experiment. Internet Assigned Numbers Authority (IANA).
RFC 1812 Requirements for IP Version 4 Routers.
RFC 1814 Unique Addresses are Good.
RFC 1817
RFC 1878 Variable Length Subnet Table For IPv4.
RFC 1879 Class A Subnet Experiment Results and Recommendations.
RFC 1900 Renumbering Needs Work.
RFC 1916 Enterprise Renumbering: Experience and Information Solicitation.
RFC 1917 An Appeal to the Internet Community to Return Unused IP Networks (Prefixes) to the IANA.
RFC 1918 Address Allocation for Private Internets.
RFC 2008 Implications of Various Address Allocation Policies for Internet Routing.
RFC 2036 Observations on the use of Components of the Class A Address Space within the Internet.
RFC 2050 INTERNET REGISTRY IP ALLOCATION GUIDELINES.
RFC 2071 Network Renumbering Overview: Why would I want it and what is it anyway?
RFC 2072 Router Renumbering Guide.
RFC 2101 IPv4 Address Behaviour Today
RFC 2317 Classless IN-ADDR.ARPA delegation

Карта сайта

News

Автора!

Bog BOS: Блоки IP адресов и их распределение