Форматы адресов IPv6

Структура индивидуального адреса IPv6

В IPv4 структуру индивидуального адреса определил процесс иерархического распределения префиксов: каждый уровень этой иерархии добавлял к префиксу несколько битов справа, а затем отдавал удлиненный префикс на более низкий уровень. В самом конце этого пути префикс назначали каналу, и он становился префиксом подсети. Поэтому, с точки зрения конечного участника, индивидуальный адрес IPv4 состоял из трех полей: назначенного "сверху" префикса, номера подсети и номера узла в пределах подсети; первые два поля вместе давали префикс подсети. Это касалось не только глобальных адресов: рекомендованные префиксы частных адресов IPv4 тоже были "спущены сверху", только не при посредстве провайдера или LIR, а непосредственно из рук IANA. Благодаря CIDR [RFC 4632], длина этих полей в адресе IPv4 не была фиксированной с момента отказа от маршрутизации по классам. Так, длина назначенного префикса зависела от "пути" по иерархии, приведшей к данному адресу; затем конечный владелец префикса делил остаток битов адреса по своему усмотрению, балансируя между тонким дроблением сети и экономией адресов, так как каждая подсеть "съедала" два ценных адреса IPv4.

У этой схемы есть, как минимум, два важных преимущества. Во-первых, такое распределение адресного пространства основано всего на одной элементарной операции, а именно на делении блока адресов пополам. Как нетрудно убедиться, именно это происходит, когда к данному префиксу добавляют справа один бит, а затем перебирают его возможные значения, то есть 0 и 1. Конечно, у этой процедуры есть известное ограничение: она работает только с блоками по адресов IPv4, имеющих общий префикс длины ; исходным блоком служит все адресное пространство IPv4, которому отвечает пустой префикс нулевой длины. Если бы блок был произвольным диапазоном адресов, то мы не смогли бы привести его к единому префиксу; поэтому он должен удовлетворять вышеуказанному условию. Именно это позволяет нам поставить знак эквивалентности между префиксами и блоками адресов.

Во-вторых, когда иерархия распределения адресов совпадает с иерархией маршрутизации, появляется возможность для агрегирования маршрутов. Допустим, к примеру, что региональный провайдер получил блок X.Y.0.0/16, а теперь делит его на блоки X.Y.Z.0/24 и выдает их местным провайдерам, подключенным к нему. Те, в свою очередь, выдают каждому конечному клиенту блок /30. В результате только местный провайдер должен работать с мелкими маршрутами /30, указывающими на его собственных клиентов. Вышестоящий провайдер имеет дело с более крупными маршрутами X.Y.Z.0/24, каждый из которых указывает на одного местного провайдера, независимо от числа его клиентов. Наконец, в ядре Internet (зоне без умолчания) региональный провайдер представлен одним маршрутом X.Y.0.0/16, независимо от числа местных провайдеров и их клиентов. В идеале, это позволяет избежать экспоненциального роста числа маршрутов при движении вверх по иерархии маршрутизации, как показано на рис. 2.1.

Рис. 2.1. Агрегирование маршрутов IPv4 в Internet

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

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

Начнем мы с младших битов и посмотрим на ту часть, что в IPv4 была номером узла в подсети. В современной практике IP не только у маршрутизаторов, но и у хостов может быть несколько сетевых интерфейсов, в том числе и в одной подсети [§3.3.4 RFC 1122]. Например, это важно для подключения с резервированием. При этом у каждого из интерфейсов должен быть адрес, уникальный в пределах зоны. Если интерфейсы узла окажутся в одной подсети, то их адреса смогут отличаться только в младших разрядах, потому что префикс подсети у них будет одинаковый. То есть интерфейсам понадобятся разные номера узла, хотя физически узел один и тот же. Чтобы избавиться от этой путаницы, скажем так: номер в подсети принадлежит не всему узлу, а только одному из его интерфейсов. Поэтому самая младшая часть адреса IPv6 называется идентификатор интерфейса (interface ID) [§2.5 RFC 4291], а не номер узла. Соответственно, и вместо номера подсети в IPv6 говорят: идентификатор подсети (subnet ID). Ну, а старшие биты адреса IPv6 занимает назначенный тем или иным образом префикс, например, глобально маршрутизируемый. Этот префикс и идентификатор подсети вместе образуют префикс подсети (subnet prefix). Такую структуру адреса иллюстрирует рис. 2.2.

Рис. 2.2. Общая структура глобального индивидуального адреса IPv6

Теперь пришло время вспомнить, что в длину адреса IPv6 мы заложили длину идентификатора интерфейса, равную 64 битам. Соответственно, на префикс подсети тоже оставалось 64 бита. Тем не менее, это были просто размышления, не имеющие силу закона. Поэтому бывалый сетевой администратор, съевший собаку на IPv4, все еще может выбирать длину префикса подсети по старинке, исходя из личных прогнозов роста подсети. Но чем это плохо? Дело в том, что устаревший подход перечеркнет наши благие намерения, потому что подсети будут по-прежнему страдать от перенаселения узлами. Чтобы полностью исключить человеческий фактор и навсегда избавить IPv6 от перенаселения подсетей, мы в приказном порядке зафиксируем длины идентификатора интерфейса и префикса подсети на значении 64 бита [§2.5.1 RFC 4291], как показано на рис. 2.3.

Размер адресного пространства IPv6 настолько огромен, что мы можем позволить себе это расточительство. Взамен сетевые администраторы будут навсегда избавлены от сомнительных прогнозов роста подсетей. Да-да, и на канал "точка-точка" (point-to-point), в котором по определению всего два интерфейса, тоже надо назначить префикс /64. Если кто-то скажет, что это уже чересчур, у нас готов встречный вопрос: "А что, если завтра на месте канала "точка-точка" возникнет широковещательный канал со многими интерфейсами? Опять менять адреса?"

Так мы отвязываем длину идентификатора интерфейса не только от планируемого размера подсети, но и от технологии канала. Позже мы убедимся, что фиксированная длина идентификатора интерфейса открывает нам и другие интересные возможности.

Рис. 2.3. Фактический формат индивидуального адреса IPv6

Небольшая оговорка, которую мы должны сделать, — это что среди всех индивидуальных адресов IPv6 есть один префикс, зарезервированный для особых целей. Адреса в нем не обязаны содержать 64 битный идентификатор интерфейса. Этот префикс — 000, или же ::/3 в текстовой нотации IPv6 [§2.5.4 RFC 4291].

Что же касается внутриканальных адресов, то для них мы исключения делать не будем: каждый из них содержит 64 битный идентификатор интерфейса. А каково значение оставшихся 54 битов, идентификатора подсети? Пусть, как показано на рис. 2.4, это будет ноль. Остальные значения этого поля во внутриканальных адресах зарезервированы [§2.5.6 RFC 4291]. Таким образом, на практике внутриканальные адреса ограничены подсетью FE80::/64.

Рис. 2.4. Формат внутриканального адреса IPv6