Адресация IPv6

Оценить необходимое число битов в адресе IPv6 нам позволит модель распределительной иерархии. Начнем мы с самого нижнего уровня в ней, который делить дальше нет смысла. Как мы знаем по опыту IPv4, субъект этого уровня — канал, а назначаемый ему префикс — подсеть. Иными словами, давайте допустим, что мы сохраним в IPv6 деление битов адреса на префикс подсети и номер узла в подсети.

Хотя каналу вполне можно назначить несколько подсетей, подсеть IP не может охватывать больше одного канала [§2.1 RFC 4291, RFC 4903]; это один из фундаментальных постулатов TCP/IP. Какое максимальное число узлов способен соединить один канал? Разумная оценка здесь — это число адресов MAC. Сегодня традиционные 48 битные адреса IEEE 802 уступают место 64 битным, т.н. EUI-64 Guidelines for 64-bit Global Identifier (EUI-64™) Registration Authority. IEEE. http://standards.ieee.org/regauth/oui/tutorials/EUI64.html . Теоретически канал с адресацией EUI 64 может соединить порядка $$2^63$$ узлов, так что пусть номер узла занимает для ровного счета 64 бита, то есть 8 байт.

Как это уже было в адресе IEEE 802, один бит EUI-64 занят, чтобы отличать групповые адреса от индивидуальных. Отсюда 63 я, а не 64 я степень двойки в числе узлов EUI-64.

Отлично, с номером узла мы разобрались. А какая длина потребуется префиксу подсети? Чтобы ответить и на этот вопрос, мы двинемся вверх по распределительной иерархии. Оставшаяся часть пирамиды носит скорее административный, нежели технический характер, и поэтому нам придется принять ее как данность. В ее современной структуре можно выделить четыре основных уровня http://www.ripe.net/docs/ipv6policy.html :

конечный пользователь, например, организация или частный клиент;

местная регистратура Internet — LIR (провайдер);

региональная регистратура Internet — RIR;

IANA.

Обратите внимание, что конечный пользователь здесь — это не человек за персональным компьютером, которому достаточно одного адреса IP, а сеть. Во-первых, провайдеры обслуживают не только частных лиц; а кроме того, и это даже важнее, все большее распространение получают домашние и персональные сети, когда один или несколько человек опутаны многоуровневой сетью, состоящей не только из традиционных ЭВМ, но также из телефонов, фото- и видеокамер, стиральных машин, кофеварок и тостеров. Сложная структура персональной сети нужна, как минимум, для безопасности. Вот представьте себе такую ситуацию. Снимая занятную сцену на камеры мобильных телефонов, горожане не замечают, что в ее фоне террорист расположил вирусный QR-код. Вечером по персональным сетям вирус перебирается из телефонов в кофеварки, и в понедельник утром жертвы получают вместо живительного напитка полную чашку водянистой бурды, отдающей горелым. Вечерние газеты пестрят заголовками о таинственной волне самоубийств… А ведь трагедию можно было предотвратить, разграничив сеть межсетевым экраном и поместив телефон и кофеварку в разные зоны безопасности.

Мы не поскупились, выдав 64 бита номеру узла, и теперь у нас возникает искушение продолжить оперировать порциями этой длины. Если мы так поступим, адрес получится длиною 320 бит, поскольку в нашей модели всего пять уровней иерархии: канал, пользователь, LIR, RIR и IANA. Безусловно, этого хватит на века, но по зубам ли будет столь длинный адрес современным вычислительным системам? Ведь пока длина адреса не превосходит разрядности вычислительной системы, элементарные операции над адресом можно выполнить, условно говоря, за единичное время. Иначе время операции начинает расти вместе с длиной адреса. Это справедливо как для традиционных ЭВМ с центральным процессором, так и для специализированных интегральных схем. Сегодня новые системы только-только подбираются к планке 256 бит Например, см. расширения SSE5 от AMD и AVX от Intel. ;так что давайте умерим нашу щедрость и посмотрим, нельзя ли будет обойтись более реальной величиной 128 бит.

Не должны мы забывать и о встроенных системах, которые до сих пор оперируют словами в 32 бита, а то и в 16 бит, потому что это уменьшает физические размеры системы и ее энергопотребление. Несмотря на свою маломощность, такие системы не отстают от своих "старших братьев" в том, что касается TCP/IP! Однако работа со слишком длинными адресами может оказаться им не по плечу ввиду ограниченного объема ОЗУ, так как вырастут в размере и сетевые структуры данных, и работающий с ними код.

Если весь адрес IPv6 окажется 128 битным, то на префикс подсети останется 64 бита. Допустим для первоначальной оценки, что это число битов поровну делят между четырьмя уровнями пирамиды. Тогда каждый уровень сможет получить 16 бит: в сети конечного пользователя будет до $$2^16$$ подсетей (по $$2^64$$ узлов каждая); у провайдера — до $$2^16$$ пользователей; каждая RIR сможет поддержать до $$2^16$$ LIR; наконец, IANA достанется $$2^16$$ префиксов как для выделения их RIR, так и для служебных целей.

Чтобы почувствовать, насколько это много или мало — 16 бит на каждом уровне иерархии, — давайте переведем несколько примеров на доступный нам язык IPv4. Так, если бы конечный пользователь назначал своим подсетям исключительно префиксы /24, то для выделения $$2^16$$ префиксов ему понадобился бы блок /8 (или, по старинке, сеть класса A) — предел мечтаний любой корпорации. При этом одна подсеть была бы ограничена всего лишь 254 узлами. В IPv6 же 16 бит на подсети — это минимум, что может получить пользователь, а в каждой его подсети будет до $$2^64$$ узлов! Что касается LIR, то до начала жесткой экономии адресов IPv4 новая LIR сразу получала блок /19, а он содержал всего лишь $$2^13$$ отдельных адресов, или же 32 подсети /24. Так что даже при делении префикса подсети IPv6 поровну LIR достанется втрое больше доступных битов, чем было во времена IPv4. Выходит, даже 16 бит на уровень могло бы хватить.

Конечно же, на практике число подчиненных субъектов будет расти при движении вниз. Так, IANA обслуживает всего несколько RIR, в ведении каждой RIR находится порядка сотен или тысяч LIR, а крупная LIR может поставлять услуги Internet миллионам конечных пользователей. Эту неравномерность шкалы вполне можно отразить в числе битов, которыми станет распоряжаться субъект каждого уровня, например, так:

IANA — 8 бит (256 RIR и служебных префиксов);

RIR — 16 бит (65 тысяч LIR);

LIR — 24 бит (16 миллионов сетей-клиентов);

конечный пользователь — 16 бит (65 тысяч подсетей).

Кроме того, основанное на префиксах распределение адресов позволяет варьировать размер блока в зависимости от запросов получателя, так что приведенные нами границы — лишь иллюстрация, а вовсе не строгое правило [§5 RFC 6177]. Небольшой LIR вполне хватит 16 бит, тогда как крупный корпоративный пользователь сможет получить у LIR в свое распоряжение, скажем, 24 бита и даже более того за счет слияния смежных 16 битных блоков. Тем не менее, ориентировочно в нашей модели конечный пользователь IPv6 получит от LIR префикс /48 и еще 16 бит останутся на внутреннюю структуру его сети.

В практике IPv6 уже есть прецеденты, когда особо крупная LIR получила у RIR /19 [§2.4.1 RFC 5375], что означает 29 доступных битов — конечно же, не считая тех битов, которые будут отданы в распоряжение конечных пользователей этой LIR. В терминах нашей оценочной модели, эта LIR сможет подключить до 2²⁹ пользователей, причем каждый получит довольно щедрую долю в адресном пространстве IPv6.

Чтобы выданный блок можно было укрупнить по требованию за счет слияния с соседним(и), достаточно следовать известной практике, когда выдающая сторона вводит единичные биты не в младшие, а в старшие разряды префикса [RFC 1219, RFC 3531]. Например, распоряжаясь 4 битами, их значения следует выдавать не как 0, 1, 2, 3…, а как 0, 8, 4, 12, 2, 10, 6, 14… Тогда при доле заполнения до $$\frac{1}{2^N}$$ у каждого выданного префикса заведомо будут свободны $$2^N -1$$2N–1 префиксов, следующих за ним, и у всей группы N младших битов будут нулевые, что обеспечит агрегирование. Например, пока выдано не более четверти доступных префиксов, каждый выданный блок можно укрупнить вдвое или вчетверо. Мы предлагаем читателю самостоятельно разобраться с двоичной арифметикой этого полезного приема. (Подсказка: рассмотрите "зеркальное отражение" n разрядной двоичной записи 0, 1, 2, 3…)

Таким образом, мы видим, что префикс подсети длиной 64 бита оставляет достаточно пространства для гибкого распределения битов согласно принципу: каждому по потребностям. Еще 64 бита мы заняли тем, что мы условно назвали номером узла в подсети. О структуре индивидуального адреса IPv6 мы еще поговорим в §2.6, а пока что сделаем наш первый технический вывод: всякий адрес IPv6 будет цепочкой из 128 битов [RFC 4291], как это показано на рис. 1.1. (рис 1.1) Адрес IPv6 в самом общем виде

Мы отложим численную интерпретацию этой цепочки до §2.2. Тем не менее, такая цепочка — несомненно, упорядочена: ее биты не "перетасованы", а следуют в строго определенном порядке.

Конечно, если бы IPv6 впервые возник в 2010 году, его адрес вполне мог бы удлиниться до 256 бит. Во-первых, это дало бы больше свободы в числе уровней распределения и маршрутизации. Во-вторых, разговоры об экономии префиксов Conservation. IPv6 Address Allocation and Assignment Policy. RIPE. http://www.ripe.net/docs/ipv6policy.html#conservation можно было бы отложить на неопределенный срок. С другой стороны, достаточное, но все же ограниченное число префиксов заставит инженера лишний раз подумать, а думать ему полезно. Избыток вычислительных ресурсов — это не оправдание бездумному их расходованию.

Любопытно заметить, что "ничто не ново под луной": завершенный 1 января 1983 года переход Internet от NCP к TCP/IP решал ту же самую задачу по расширению адресного пространства, а длина адреса тогда тоже увеличилась вчетверо, с одного байта до четырех.

Давайте оценим, сколько адресов IPv6 надо выдать, чтобы коэффициент HD (см. §1) достиг величины 0,8 (пороговое значение "пора задуматься" [§4 RFC 3194]). Нам будет удобно работать с двоичными логарифмами. Логарифм искомого числа примерно равен 0,8 * 128 102. То есть выходит, что "первый звонок" прозвенит за 26 двоичных порядков до абсолютного предела. В этом парадокс иерархического распределения: адреса фактически исчерпываются заметно раньше, чем можно было бы предвидеть на основании их общего числа.

Текстовое представление адреса IPv6

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

Поэтому давайте следующим шагом предложим лаконичное и однозначное текстовое представление адреса IPv6. В первую очередь, оно поможет людям записывать, читать и, по мере возможности, запоминать такие адреса. Однако записывают адреса не только на бумаге — их также вводят в память ЭВМ. В частности, именно к этому сводится ручная настройка адресов. Кроме того, адреса считывают с экрана и выводят на печать. Следовательно, текстовое представление адреса должно использовать только печатаемые символы, но в какой кодировке? Ведь их набор в разных кодировках отличается. К счастью, на практике можно выбрать подмножество символов, которое будет "по зубам" любой существующей ЭВМ, например: буквы латинского алфавита (без определенного регистра), десятичные цифры и основные знаки препинания.

Какие знаки препинания считать основными? Сегодня можно сказать, что это знаки препинания из кодировки ASCII — базовой кодировки, принятой в Internet [RFC 20] и до сих пор не сдавшей все свои позиции универсальной кодировке UTF 8 [RFC 5198]. А еще более мудрый выбор — это символы пунктуации, присутствующие одновременно и в ASCII, и в EBCDIC.

В копилке нашего опыта уже есть подобное решение для адреса IPv4, а именно формат "десятичный с точками" (dotted decimal):

На входе дан адрес IPv4 как упорядоченная цепочка из 32 бит.

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

Затем находят численное значение каждого байта и записывают его как десятичное число, руководствуясь при этом целым беззнаковым кодом и сетевым порядком битов: первый бит по порядку — самый старший, то есть наиболее значимый (MSB).

Наконец, перечисляют эти значения байтов так, чтобы слева стоял самый первый, он же наиболее значимый, байт. Между значениями ставят точки.

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

Обсудите применение такой нотации в системах вертикальной письменности.

В связи с десятичной записью байтов адреса IPv4 возникает вот какой вопрос: может ли она содержать ведущие нули? С одной стороны, арифметика позиционной записи гарантирует, что такие нули не меняют численного значения. Но, с другой стороны, на практике ведущие нули могут вызывать сложности. Скажем, в языке Си ведущий ноль означает, что число записано по основанию 8, а из языка Си через его стандартную библиотеку (см. функцию strtol) эта интерпретация вполне может проникнуть и в приложения, если программист не зафиксирует основание счисления явным образом, а позволит библиотеке угадывать его. Например, функции inet(3) из библиотеки BSD libc позволяют вводить октеты адреса IPv4 по любому основанию, принятому в языке Си: 8, 10, 16 http://www.freebsd.org/cgi/man.cgi?query=inetapropos=0sektion=3manpath=4.4BSD+Lite2arch=defaultformat=html , — используя префиксы 0 и 0x для выбора оснований 8 и 16, соответственно. В результате существует риск, что разные приложения могут интерпретировать ведущий ноль по-разному. Чтобы избежать неоднозначности, современная трактовка, основанная на формате URI, такова: в общепринятой записи адреса IPv4 ведущие нули недопустимы [§3.2.2 RFC 3986]. Конечно, эти соображения обусловлены историческими причинами, а не желанием оправдать небрежность разработчиков. Поэтому в IPv6 мы оставим корректную обработку ведущих нулей в текстовой записи адреса на совести программиста, а нам останется четко определить, что эти нули означают.

Что в этом рецепте можно улучшить? Во-первых, у десятичной записи довольно высокая избыточность; шестнадцатеричная запись может быть короче в $$\lg{16}\thickapprox1,2$$ раза. Для длинного адреса это плюс.

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

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

К примеру, адрес 203.0.113.42 как 32 битное целое беззнаковое число равен 3405803818 десятичному или 0xCB00712A шестнадцатеричному, и только в шестнадцатеричной записи значения отдельных байтов видны невооруженным глазом: 0xCB — 203, 0x00 — 0, 0x71 — 113 и 0x2A — 42

Вместе этих аргументов более чем достаточно, чтобы выбрать основанием текстовой нотации IPv6 число 16.

Тем временем в Австралии ведутся эксперименты с записью адресов IPv6 по основанию 85 [RFC 1924].

Пообещав наглядную связь между численным значением адреса IPv6 и его записью, перейдем к осуществлению нашего плана. Что мы понимаем под численным значением адреса? Как мы уже говорили, цепочку битов можно рассматривать как число в целом беззнаковом коде, если определить старшинство битов в ней. В TCP/IP принят сетевой порядок старшинства: первый бит — наиболее значимый. Это позволяет нам найти численное значение адреса IPv6, равно как и адреса IPv4, поскольку оба они — упорядоченные цепочки битов.

Следующий шаг — от абстрактного численного значения к его шестнадцатеричной записи. Чтобы записать цепочку из 128 битов как беззнаковое число в шестнадцатеричном представлении, потребуется 32 знака, включая возможные ведущие нули. Давайте для удобства добавим нейтральные символы-разделители через каждые несколько знаков, как это делают с телефонными номерами. Пусть в группе будет четыре знака, а разделяет группы знак двоеточия, а не точка — это позволит не спутать адрес IPv6 с адресом IPv4. Тогда, например, адрес с таким численным значением по основанию 16:

20010DB800000000000000100006789

можно записать так:

2001:0DB8:0000:0000:0000:0001:0000:6789

Выбор двоеточия на роль разделителя групп может показаться неудачным, потому что двоеточие уже нагружено несколькими смежными ролями и возможна путаница. Во-первых, двоеточие разделяет адрес хоста и номер порта в формате URL. По этой причине адрес IPv6 в составе URL приходится заключать в квадратные скобки [§3.2.2 RFC 3986 ] Обратите внимание, как создатели электронной почты Internet за много лет до IPv6 предусмотрели и обошли эту трудность: формат доменного литерала с самого начала требовал заключать адрес узла в квадратные скобки, независимо от сетевого протокола [§3.3 и §6.2.3 RFC 822]. . Во-вторых, двоеточие — это альтернативный разделитель в текстовой записи адресов MAC Согласно букве IEEE 802, стандартный разделитель — это дефис, тогда как двоеточие указывает на обратный порядок битов [§3.1.2 и §3.1.8 IEEE 802-2001]. Тем не менее, на практике двоеточие часто применяется вместо тире при прямом порядке битов. (В IEEE 802 принят порядок, обратный сетевому, то есть LSB.) Например, этой традиции следуют операционные системы семейства Unix. Но, если перебрать все символы пунктуации ASCII, то среди них окажется не так уж много удобных вариантов. Одно из требований к хорошему разделителю — это чтобы он был нейтральным в командной строке Unix. Ведь адреса часто бывают аргументами сетевых утилит, например, ping, telnet и tcpdump. Если теперь адреса IPv6 придется постоянно закавычивать или экранировать, то это нарушит уже сложившуюся практику, что было бы крайне нежелательно (т.н. правило наименьшего удивления).

Это был наш первый пример настоящей текстовой записи адреса IPv6. Он уже вполне отвечает формату и готов к использованию. Но мы видим, что его избыточность все еще велика: в нем много раз повторяются нули. А ведь по нашему плану адресное пространство IPv6 будет неисчерпаемым, а значит, разреженным, так что и на практике в адресах будут встречаться длинные цепочки нулей. Как бы нам сократить их запись? Для этого нам понадобится пара дополнительных правил.

Во-первых, давайте рассматривать каждую группу из четырех знаков как отдельное 16 битное беззнаковое число. Цепочка битов, представленная таким числом, не изменится, если мы отбросим ведущие нули, поскольку мы уже зафиксировали ее длину. Так что мы вправе объявить ведущие нули группы необязательными.

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

После этой простой поправки тот же самый адрес можно записать заметно короче:

2001:DB8:0:0:0:1:0:6789

Теперь мы замечаем, что в этом адресе подряд идут три нулевых группы. А что будет, если мы их вообще опустим? Мы точно знаем, что в полной записи адреса IPv6 восемь групп; благодаря этому мы можем элементарно вычислить длину пропущенной цепочки нулей. Например, давайте опустим нулевые группы, идущие подряд в нашем образцовом адресе:

2001:DB8::1:0:6789

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

При необходимости пара двоеточий может находиться не только в середине, но также и в начале или в конце адреса. Например, следующие две записи эквивалентны между собой — но отличны от 2001:DB8::1:0:6789:

2001:DB8:1:0:6789::

2001:DB8:1:0:6789:0:0:0

А что будет, если мы сделаем больше одного пропуска? Например, так:

2001:DB8::1::6789

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

Между тем, опустить можно любую цепочку нулей, а не только самую длинную. К примеру, наш образцовый адрес 2001:DB8::1:0:6789 можно записать и так:

2001:DB8:0:0:0:1::6789

Как нетрудно видеть, теперь опущена всего одна нулевая группа, потому что остальные семь записаны явно.

Только что составленное нами правило сокращенной записи позволит легче запоминать адреса IPv6. Если вам пожалуются на то, что адрес IPv6 невозможно запомнить, расскажите собеседнику об этом правиле.

Некоторые парсеры формата "десятичный с точками" IPv4 допускали сокращенную запись адресов на входе. Наиболее известный, а возможно, и единственный случай такого поведения — это функции inet(3) из библиотеки BSD libc, которые позволяли, к примеру, сократить запись адреса 10.0.0.1 до 10.1, а 192.168.0.1 до 192.168.1. Правила такого сокращения были сложнее, чем простой пропуск нулевых октетов — см. соответствующую страницу руководства man . http://www.freebsd.org/cgi/man.cgi?query=inetapropos=0sektion=3manpath=4.4BSD+Lite2arch=defaultformat=html Однако все подобные расширения нотации IPv4 были нестандартными и зависели от реализации, в отличие от общепринятых правил записи адресов IPv6. Проверьте себя, ответив на такой вопрос: какое максимальное число двоеточий может содержать запись адреса IPv6, отвечающая стандарту? (Ответ: 8. Пример можно найти в [§2.7.1 RFC 4291].)

Помимо полных, 128 битных адресов, в ряде случаев нам понадобится запись префиксов IPv6. Так, к примеру, префиксами будут представлены записи в таблицах маршрутов или просто блоки адресов, выделенные для каких-то целей. По своей сути, префикс — это цепочка битов, длина которой не больше, чем длина адреса. Как мы знаем, одна такая цепочка обозначает все адреса, старшие разряды которых совпадают с этой цепочкой. Из-за их тесной связи с адресами, префиксы удобно записывать в том же формате, только с явным указанием длины. Пусть десятичная длина префикса пишется после адреса через косую черту, как и в нотации IPv4 CIDR [§3.1 RFC 4632].

Допустим, нам дан такой двоичный префикс длиной 58 бит:

0010000000000001000011011011100000000000000000001100110110

Чтобы превратить его в полный, 128 битный адрес IPv6, который мы должны записать перед косой чертой, этот префикс надо дополнить 70 нулевыми битами справа — ведь префикс означает старшие биты адреса. Шестнадцатеричное значение искомого адреса таково:

20010DB800000CD800000000000000000

Записав этот адрес по недавно сформулированным правилам, мы ставим косую черту и пишем длину, 58. Вот что у нас получается:

2001:0DB8:0000:CD80:0000:0000:0000:0000/58

Это и есть текстовое представление данного префикса. А теперь мы можем переписать адрес IPv6 лаконичнее и получить краткий, но полностью эквивалентный вариант:

2001:DB8:0:CD80::/58

Наконец, иногда удобно одновременно записать адрес IP и его префикс. (Главное применение этой записи мы встретим при назначении адреса сетевому интерфейсу.) По определению, префикс уже содержится в старших разрядах адреса, так что достаточно дополнить адрес длиной префикса, применив ту же самую нотацию. Например, запись:

2001:DB8:0:CD9F::123/58 означает адрес 2001:DB8:0:CD9F::123 в контексте префикса 2001:DB8:0:CD80::/58.

Убедитесь, что адрес 2001:DB8:0:CD9F::123 действительно содержит префикс 2001:DB8:0:CD80::/58.

Отличить запись адреса с префиксом от записи чистого префикса в общем случае можно только по контексту. Конечно, в записях адресов довольно часто встречается ненулевой остаток (разряды справа от префикса), а в правильных записях префиксов его нет никогда; однако адрес, в котором остаток нулевой, тоже имеет право на существование.

Типичная ошибка, которую можно допустить, записывая префикс, — это отбросить в последней значащей группе концевые нули [§2.3 RFC 4291]. Например, следующие две записи не эквивалентны:

2001:DB8:0:CD80::/60

2001:DB8:0:CD8::/60

Чтобы убедиться в этом, достаточно преобразовать каждую из текстовых записей обратно в двоичное или шестнадцатеричное представление префикса и остатка, как показано в Табл. 1.1, и сравнить непосредственно их.

Развернутое представление префиксов IPv6

Текстовая нотация	Префикс(по основанию 16)	Остаток(по основанию 16)
2001:DB8:0:CD80::/60	20010DB800000CD8	00000000000000000
2001:DB8:0:CD8::/60	20010DB800000CD	80000000000000000

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

"Составленные" нами правила записи адресов и префиксов IPv6 зафиксированы в §2.2 и §2.3 RFC 4291. А вот что RFC 4291 забывает сказать, так это что текстовая нотация IPv6 нечувствительна к регистру: знаки-буквы могут быть как прописными (A–F), так и строчными (a–f) [§2.3 RFC 5952]. Это обычная практика шестнадцатеричной нотации.

Читая RFC 5952, имейте в виду, что речь идет только о формате адреса IPv6 , то есть в выводе программ. Авторы стандарта делают на этом слабое ударение, из-за чего §4.3 можно трактовать так, что заглавные буквы A–F в текстовой нотации IPv6 вообще запрещены. Не стоит удивляться, если завтра появится приложение или библиотека IPv6, которые откажутся принимать заглавные буквы на выходе.

Существует еще одна нотация, в которой младшие 4 байта адреса IPv6 записаны как адрес IPv4 [п. 3 §2.2 RFC 4291]. Например, наш первый адрес IPv6 будет записан как 2001:DB8::1:0.0.103.137. Она может быть полезна во время перехода, когда в сети сосуществуют IPv4 и IPv6, а некоторые адреса IPv6 содержат в себе адреса IPv4.

Типы адресов IPv6

Теперь мы можем заняться первичной "раскройкой" адресного пространства IPv6. Какие типы адресов нам понадобятся? Основываясь на нашем опыте с IPv4, мы составим такой пробный список:

глобальные индивидуальные адреса (global unicast);

частные индивидуальные адреса (private-use unicast);

внутриканальные индивидуальные адреса (link-local unicast);

групповые адреса (multicast);

адрес обратной связи (loopback);

неопределенный адрес (unspecified).

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

Неопределенный адрес (это был 0.0.0.0 в IPv4) означает, что адрес не установлен, не настроен, неизвестен. Например, в API сокетов Беркли приложение использует неопределенный локальный адрес сокета, чтобы сказать сетевому стеку: выбери подходящий адрес самостоятельно. Очевидно, что неопределенный адрес нельзя назначать интерфейсам или помещать в заголовок IP, кроме нескольких особо оговоренных случаев. Например, в самом начале автоматической настройки адресов узла адрес источника пакета может быть неопределенным, чтобы обойти "проблему курицы и яйца", когда узлу надо послать пакет, хотя у него еще нет собственных адресов — мы об этом еще поговорим. Напротив, адрес назначения пакета неопределенным быть не должен никогда, потому что иначе в нем не будет никакого смысла: это все равно, что пустое поле "куда/кому" на почтовом конверте. Поскольку неопределенный адрес играет довольно важную роль, его значение должно быть общепринятым и уникальным; нам надо утвердить его с самого начала. Пусть в IPv6 неопределенным тоже будет адрес с нулевым численным значением:

0:0:0:0:0:0:0:0

Благодаря правилам сокращения из §2.2, его можно записать и проще, всего парой двоеточий:

::

Адрес обратной связи необходим, чтобы сетевые приложения TCP/IP могли работать и на отдельной машине, у которой нет настоящих сетевых интерфейсов. Кроме того, удобно, когда один и тот же общепринятый адрес всегда указывает на локальный узел: меньше придется менять настройки сетевых приложений при их переносе с одного узла на другой, если части одного приложения тоже общаются по TCP/IP. Очевидно, что адрес обратной связи никогда не должен появляться в заголовках пакетов, путешествующих между узлами, потому что он имеет смысл только в пределах одного узла. В IPv4 для этой цели зарезервировали большой блок, 127.0.0.0/8; но, как показал опыт, достаточно было бы одного адреса 127.0.0.1. Поэтому в IPv6 мы ограничимся ровно одним адресом обратной связи. Ради простоты и краткости пусть это будет адрес с численным значением 1:

::1

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

FF00::/8

Обратите внимание, что эту запись нельзя сократить до FF::/8. Если вам это не очевидно, повторите правила записи адресов IPv6 из §2.2.

Теперь мы можем перейти к индивидуальным адресам (unicast). Наша главная цель — обеспечить Internet максимальным числом глобальных индивидуальных адресов; поэтому мы выделим в доступном адресном пространстве относительно небольшие множества адресов, не являющихся глобальными, а все остальные адреса пусть по умолчанию будут глобальными. Так мы максимизируем число последних.

Внутриканальные адреса нам знакомы еще по IPv4. Тогда это был блок 169.254.0.0/16, который полагалось использовать при автоматической настройке узлов в простой одноранговой сети [RFC 3927]. Пакеты с адресами из этого блока не должны покидать пределов одного канала и подключенных к нему узлов. Задача автоматической настройки наверняка возникнет и после перехода на IPv6, так что давайте зарезервируем для внутриканальных адресов такой префикс:

FE80::/10

Хотя по нашему генеральному плану длина префикса подсети составит 64 бита, это будет решение на уровне политики, а не протокола. Поэтому сейчас мы резервируем для внутриканальных адресов не /64, а блок существенно большего размера, и это не противоречит сказанному ранее.

Частные адреса IPv4 были нужны для развертывания сетей типа интранет, когда по своей технологии и архитектуре сеть устроена точно так же, как Internet, но физически отделена от него. Если бы было точно известно, что такой интранет никогда не станет частью Internet, блок адресов для него можно было бы выбрать совершенно произвольный, вплоть до 0.0.0.0/0. Но в действительности интранет рано или поздно соединяют с Internet через шлюз, и тогда возникает неоднозначность адресов: один адрес А оказывается назначен как внутри, в пределах интранета, так и снаружи, в Internet. После этого другие узлы интранета не могут быть уверены, куда они попадут, обращаясь по адресу А. Избежать этого сценария позволили четко оговоренные частные адреса [RFC 1918], которые никогда не применяются в роли глобальных и потому не встречаются в Internet. Этот подход не лишен недостатков, которые мы обсудим в §2.10. Тем не менее, он решает задачу уникальности адресов с точки зрения интранета. Сам термин "интранет" в большой мере устарел, так как сетей, полностью отделенных от Internet, осталось мало, а подавляющее их число просто подключено через шлюз, скрывающий частные адреса при помощи NAT или proxy. Поэтому примем на вооружение вместо него термин "сайт". Типичный пример сайта — это организация или ее часть, всей сетью которой управляет один отдел.

Когда в организации несколько сайтов, по-русски мы бы называли каждый из них просто площадкой, но термин "сайт" уже вошел в обиход.

Соответственно, в IPv6 вместо частных адресов возникают внутрисайтовые адреса (site-local address), которые значимы только в пределах данного сайта и не могут встречаться в глобальном пространстве Internet. Для них мы зарезервируем префикс, смежный предыдущему:

FEC0::/10

В конечном итоге недостатки внутрисайтовых адресов перевесили их преимущества, так что на сегодняшний день рекомендовано отказаться от их применения [RFC 3879]. Мы обсудим в §2.10, что именно привело к этому решению и чем мы располагаем взамен. Тем временем, как это ни странно, понятие внутрисайтовых адресов поможет нам разобраться с темой §2.4.

Наконец, все остальные адреса IPv6 относятся к типу глобальных индивидуальных. Ну, или практически все из них.

На самом деле, есть еще пара исключений, которые мы подробно рассматривать не будем. Адреса IPv6 с префиксом ::/96 содержат в себе адреса IPv4, но только глобальные индивидуальные [§2.5.5.1 RFC 4291], поэтому и внешний адрес IPv6 в известном смысле остается глобальным индивидуальным. Адреса IPv6 с префиксом ::FFFF:0:0/96 могут содержать в себе любой адрес IPv4 [§2.5.5.2 RFC 4291]. На практике префикс ::/96 больше не применяется, а префикс ::FFFF:0:0/96 используется только в API, чтобы "подружить" приложения IPv6 с сетевой средой IPv4 [RFC 4038]. Например, приложение без поддержки IPv4 все-таки можно заставить соединиться с хостом 192.0.2.1, подсунув ему такой адрес IPv6: ::FFFF:192.0.2.1. (О нотации см. примечание в конце §2.2.) Конечно, сам сетевой стек должен при этом поддерживать оба протокола.

Пока что для применения в Internet раздают блок 2000::/3 [ http://www.iana.org/assignments/ipv6-address-space , http://www.iana.org/assignments/ipv6-unicast-address-assignments ]. Остальные глобальные адреса IPv6 зарезервированы на случай, если этот блок исчерпается слишком скоро и надо будет пересмотреть политику выдачи адресов IPv6.

Среди глобальных индивидуальных адресов IPv6 нам следует сразу же зарезервировать диапазон для примеров. Его назначение понятно: даже если читатель бездумно введет адреса из примеров в конфигурацию живой сети, это не приведет к глобальному конфликту. Как мы помним, в IPv4 эту роль играли блоки 192.0.2.0/24, 198.51.100.0/24 и 203.0.113.0/24 [RFC 5735, RFC 5737]. Несколько штук их понадобилось, чтобы было удобнее составлять наглядные примеры взаимодействия разных сетей. Теперь же достаточно выделить один блок побольше, и авторы сами раскроят его по своему усмотрению. Пускай это будет 2001:DB8::/32 [RFC 3849]. Мы уже начали использовать его, говоря о текстовой нотации адреса IPv6.

Блок 192.0.2.0/24 был назначен для этой цели на высочайшем уровне, то есть IANA. Блоки 198.51.100.0/24, 203.0.113.0/24 и 2001:DB8::/32 выделены региональной регистратурой Азии и Океании APNIC.

Как мы помним, у IPv4 был сводный документ, посвященный адресам особого назначения [RFC 5735]. Аналогичный документ есть и у IPv6 [RFC 5156].

В Internet уже опубликовано немало технической документации, где для иллюстраций выбран префикс IPv6 2001:DB80::/32. Обсудите правомерность и удачность такого выбора.

Область и зона действия адреса IPv6

Затронутая нами в §2.3 концепция внутриканальных адресов подводит нас к одной любопытной и довольно общей проблеме. Пока что мы знакомы только с тем, как эта концепция реализована в IPv4, и реализация эта предполагает, что у каждого узла ровно один активный сетевой интерфейс [§3 RFC 3927]. Это позволяет объединить все узлы многоадресным каналом и обойтись одним префиксом, 169.254.0.0/16, без дальнейшего его дробления. Есть ли у нас основания для того, чтобы расширить эту схему на случай N каналов, где $$N > 1$$?

Для затравки мы можем представить себе простейший сценарий: в центре сети находится сервер, подключенный к нескольким каналам, а рабочие станции обращаются к нему по этим каналам. Примером послужит гипотетическая сеть НИИЧАВО А. и Б. Стругацкие. "Понедельник начинается в субботу": Сказка для научных работников младшего возраста — М.: Детская литература, 1965. — 224 с, ил. , показанная на рис. 1.2 (рис 1.2) Гипотетическая сеть НИИЧАВО Если любая рабочая станция в такой сети обращается только к своим соседям (neighbor) по каналу, включая сервер, то для работы сети достаточно внутриканальных адресов. Каждый канал может отвечать, скажем, независимому отделу организации; тогда подсети отделов будут изолированы друг от друга, и маршрутизация пакетов IP между ними не потребуется.

Пока мы работаем в рамках IPv4, осуществить эту схему на практике мы не сможем, потому что нам пришлось бы назначить каждому сетевому интерфейсу сервера адрес из одной и той же подсети, 169.254.0.0/16, а сетевой уровень IPv4 такой конфигурации не поддерживает по причине ее неоднозначности. А именно сетевой стек IPv4 не смог бы определить, через какой интерфейс надо передавать исходящие пакеты, адресованные 169.254.x.y.

Если же мы выйдем за пределы IPv4 и рассмотрим задачу на чисто логическом уровне, то внутриканальные адреса разных каналов вполне могут быть независимы, поскольку область действия каждого из них ограничена его каналом. Техническая сложность здесь заключается в том, что узлу, подключенному к нескольким каналам, надо научиться отличать адрес А на канале К1 от адреса А на канале К2, как показано на рис. 1.3. То есть указатель на канал должен стать частью внутриканального адреса. Если это произойдет, то один и тот же префикс подсети можно будет назначить разным интерфейсам узла, и это не приведет к неоднозначности.

(рис 1.3) Разрешение неоднозначности адреса А указанием канала Подобное решение давно применяют географы: городам можно давать одинаковые имена, если они стоят на разных реках. Чтобы не возникло путаницы, к собственному имени города добавляют название реки. Например, так появились Франкфурт-на-Майне и Франкфурт-на-Одере, Комсомольск-на-Амуре и Комсомольск-на-Днепре.

К сожалению, подобного механизма вообще не было в IPv4 — об этом подробно говорится в [§3 RFC 3927], — так что стек IPv4 не различал внутриканальные адреса или префиксы подсетей на разных каналах, если их двоичное значение совпадало. Хотя менять что-либо в поведении IPv4 уже поздно, нам ничто не мешает освободить IPv6 от этого ограничения.

Однако мы пойдем дальше по пути обобщения и не станем ограничивать эту интересную идею одними только каналами. Скажем так: пускай у каждого адреса IPv6 будет определенная область действия, или просто область (scope) [§4 RFC 4007]. Например, у внутриканального адреса это канал, у внутрисайтового — сайт, а у глобального — целая планета или даже вселенная (в зависимости от высоты наших звездных амбиций). Единственное исключение — это неопределенный адрес ::, ввиду его особого статуса: область действия адреса :: в общем случае не определена.

Если вам нужно освежить память насчет типов адресов IPv6, повторите §2.3.

Вернемся пока что к внутриканальным адресам и снова рассмотрим наш пример — сервер в центре организации (рис. 1.2). Допустим, всем его интерфейсам назначен один и тот же численный адрес FE80::1/64, область действия которого — канал . В §2.3 мы зарезервировали FE80::/10 для внутриканальных адресов, помните? Но, по нашему замыслу, адрес FE80::1 в отделе линейного счастья (канал К1) и адрес FE80::1 в отделе смысла жизни (канал К2) — суть разные адреса, несмотря на одинаковое численное значение и равновеликую область действия. Чтобы зафиксировать это различие, мы скажем, что канал К1 — это зона действия (scope zone), или просто зона, адреса "FE80::1 на К1". То же самое можно сказать о любом адресе из подсети "FE80::/64 на К1" — у всех у них зона совпадает. В то же время, у адресов "FE80::1 на К2" и, например, "FE80::C0DE на К2" будет другая зона, а именно канал К2.

Чем зона отличается от области? Область — это характеристика величины, размера: один канал, один сайт, одна вселенная. А зона — это конкретная территория, где актуален данный адрес IPv6: канал К1 в Отделе линейного счастья НИИЧАВО или облако Wi-Fi у меня дома; академическая сеть НИИЧАВО или корпоративная сеть компании Yoyodyne; наконец, наша Вселенная.

Адепты объектно-ориентированного программирования без труда заметят такую параллель: область — это класс, а зона — это объект.

Особенность такого подхода в том, что область адреса IPv6 можно определить по его двоичному префиксу (FE80::/10,— канал, FEC0::/10 — сайт, и т.д.), тогда как его зона зависит от конфигурации конкретной сети. Информация о зоне не содержится в численном значении адреса, а значит, ее надо хранить и сообщать дополнительно, например, как мы делали это выше, снабжая внутриканальный адрес уточнением: "на таком-то канале".

Означает ли это, что имя зоны становится неотъемлемой частью адреса IPv6? Придется ли поместить такие имена в заголовок IPv6 наряду с численными адресами источника и назначения? Чтобы ответить на этот вопрос, нам надо принять и понять простой факт: адресация между разными зонами одной области Или, говоря проще, одинаковой величины. невозможна, потому что адреса в их объединении не уникальны. Иными словами, если в заголовке пакета указан адрес источника или назначения, принадлежащий данной зоне, то пакет не должен покидать пределов этой зоны, потому что иначе адрес утратит свой смысл. То, что мы сейчас обнаружили — это фундаментальное свойство зонной архитектуры IPv6. Мы станем называть его "принцип изоляции зон".

Вообще-то, нам с самого начала было очевидно, что в нашем примере сети НИИЧАВО обмен трафиком между разными ЛВС невозможен, поскольку в них применяются только внутриканальные адреса. Сейчас же мы обобщили этот вывод на любую область.

Благодаря этому свойству узел-получатель всегда знает, из какой зоны пришел пакет. Например, если сервер НИИЧАВО получит из канала К2 пакет, созданный узлом FE80::DADA и адресованный FE80::F00D, то сервер немедленно отнесет адреса источника и назначения к зоне К2: они станут не просто FE80::DADA и FE80::F00D, а "FE80::DADA на канале К2" и "FE80::F00D на канале К2". Никакой дополнительной информации в заголовке самого пакета при этом не потребуется.

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

данный узел — транзитный на пути данного пакета;

данный узел — создатель пакета.

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

И только во втором случае сведения о зоне назначения пакета заранее недоступны. Здесь нет другого входа, как явным образом указать зону назначения. Например, если администратор сети НИИЧАВО захочет проверить с помощью ping доступность хоста FE80::Baa1 в недавно подключенном отделе научного атеизма (новый канал К4 — на схеме сети отсутствует), то ему придется указать в командной строке не только численный адрес, но и зону. Нам предстоит сконструировать стандартный механизм, который позволит это сделать.

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

Грубо говоря, включение имен зон в состав заголовка IPv6 означало бы просто отказ от зонной архитектуры и расширение адреса IPv6 еще несколькими битами.

Выходит, что идентификация зон — это частное дело отдельно взятого узла, и нет нужды заботиться о ее согласовании между узлами. Например, если бы в сети НИИЧАВО было два сервера, то один из них мог бы обозначать подключенные к нему каналы древнекитайскими иероглифами, а другой — древнегерманскими рунами, несмотря на то что у них есть общие каналы, как изображено на рис. 1.4. Главное, чтобы каждый узел сам не запутался в собственных обозначениях или, выражаясь строже, чтобы идентификатор зоны оставался уникальным в пределах узла.

(рис 1.4) Идентификаторы зон могут быть обозначены даже рунами или иероглифами

Пусть читатель найдет эти иероглифы и руны в Unicode.

На первый взгляд, мы сами себе противоречим. Ведь мы сказали в §2.2, что в текстовой записи адреса IPv6 допустимы только самые основные символы, а теперь говорим о каких-то рунах и иероглифах. Дело здесь в том, что идентификатор зоны, взятый на локальном узле, никогда не придется вводить в настройки другого узла, потому что там он не будет иметь никакого смысла. Именно поэтому локальный узел волен выбрать для идентификации зон любую знаковую систему, с которой он сам способен работать.

Как именно узел будет вести учет подключенных зон, мы оставим на усмотрение реализации. Тем не менее, можно предложить типовую модель этого механизма, чтобы не обсуждать воздушные замки. Итак, для того чтобы достоверно отличить разные зоны друг от друга, узлу достаточно:

а) знать область (величину) каждой из них: канал, сайт, …, вселенная;

б) пронумеровать зоны одной области (одинаковой величины).

Сочетание области и номера зоны мы обозначим как индекс зоны (zone index). Наши обозначения каналов в примере: "канал К1", "канал К2", "канал К3", — были ни чем иным как разновидностью таких индексов.

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

может ли область меньшей величины быть разделена между областями большей величины Тот же вопрос можно поставить так: могут ли зоны перекрываться? ;

могут ли адрес источника и адрес назначения пакета IPv6 принадлежать разным зонам?

Хотя мы еще не работали над заголовком IPv6, уже сейчас достаточно ясно, что в нем будут адреса источника и назначения пакета.

Для ответа на первый вопрос рассмотрим гипотетический канал К, который принадлежит одновременно двум сайтам, С1 и С2. Это значит, что к каналу К могут быть одновременно подключены два узла У1 и У2 с внутрисайтовым адресом, скажем, FEC0::C001. Отличаться эти адреса будут, конечно же, зоной: у одного это "сайт С1", а у другого — "сайт С2". Теперь представим себе, что третий узел, принадлежащий сайту С1, передает в канал К пакет, адресованный FEC0::C001. Согласно нашей рабочей модели, идентификатор зоны назначения в этом пакете не упоминается. В результате, хотя этот пакет предназначался узлу У1 по принципу изоляции зон, его примут оба узла, У1 и У2, потому что каждый из них решит так: "Этот пакет пришел из канала К, и значит, он относится к моему сайту". В такой схеме адрес назначения теряет однозначность. Как восстановить ее?

Для этого необходимо и достаточно, чтобы заголовок и входной интерфейс принятого пакета вместе однозначно определяли зоны адреса источника и адреса назначения [§7 и 8 RFC 4007]. Сам по себе численный адрес IPv6 из заголовка пакета указывает только на свою область, но не на зону. Значит, отображение области в зону надо провести на основе информации о входном интерфейсе. Чтобы это отображение оставалось однозначным и определенным для любой области, понадобится вот какое дополнительное условие: каждый интерфейс узла IPv6 находится ровно в одной зоне каждой области, независимо от назначенных ему адресов [§5 RFC 4007]. Предыдущий пример нарушал это требование, так как подключенные к каналу К интерфейсы узлов У1 и У2 находились одновременно в двух зонах области "сайт".

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

Не ошиблись ли мы, сказав "ровно в одной зоне" вместо "не больше чем в одной зоне"? На самом деле, нет. Ведь иначе пострадала бы определенность соответствия: <численный адрес и входной интерфейс>$$\to$$ <зона адреса>, — так как некоторым адресам во входящих пакетах не отвечала бы никакая зона.

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

(рис 1.5) Интерфейс принадлежит зонам всех областей

Последнее требование выполнимо, только если сетевая топология зон удовлетворяет ряду условий:

могут ли адрес источника и адрес назначения пакета IPv6 принадлежать разным зонам?

границы зон проходят сквозь узлы, а не сквозь каналы;

зоны никогда не перекрываются частично;

зона большей величины может полностью заключать в себя зоны меньшей величины.

Зона не может включить в себя другую зону той же области, однако зоны разных областей вполне могут иметь одинаковую границу. Скажем, зона "корпоративная сеть компании Yoyodyne" может совпадать по границам с зоной "канал Ethernet компании Yoyodyne", если сеть компании Yoyodyne состоит из одной ЛВС.

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

Вдобавок, еще одно топологическое условие нам дает принцип изоляции зон:

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

Физическая схема сети вполне может допускать разные трассы между парой интерфейсов. Не исключено, что некоторые из них нарушат это правило, если пакеты будут путешествовать по ним. Задача администратора сети — исключить подобные трассы-нарушители при настройке маршрутизации. Например, не следует маршрутизировать свой внутрисайтовый трафик через соседнюю организацию, как показано на рис. 1.6. В свою очередь, сетевой стек IPv6 должен блокировать такие нарушения и не пропускать пакет-нарушитель из одной зоны в другую.

Чтобы лучше понять все эти условия, рассмотрите пример сложной карты зон на рис. 1.6 и установите, как эта карта выполняет каждое из них.

(рис 1.6) Пример топологии зон. Допустимая и недопустимая внутрисайтовые трассы в нем

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

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

Это можно сформулировать и по-другому. "Дальность полета" пакета IPv6 ограничена двумя зонами, адреса источника и адреса назначения. Топология этих зон такова, что либо их границы совпадают, либо одна зона заключена внутри другой. Очевидно, что в последнем случае более сильное ограничение накладывает зона меньшей величины. Именно она и будет лимитирующей. Следовательно, ей должны принадлежать интерфейсы источника и назначения, чтобы пакет благополучно "долетел".

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

(рис 1.7) Обмен данными между адресами разных областей

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

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

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

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

[§9 RFC 4007] предлагает, чтобы маршрутизатор использовал отдельную таблицу маршрутов для каждой подключенной к нему зоны. Это позволи т с самого начала исключить из рассмотрения маршруты, нарушающие зону назначения.

[§9 RFC 4007] предписывает действовать по шагам: сначала по адресу назначения пакета маршрутизатор находит подходящий маршрут, который не нарушит зону назначения, а затем он проверяет, сохранит ли этот маршрут зону источника. То есть зона источника не влияет на окончательный выбор маршрута из множества альтернатив. На практике можно построить сеть, в которой такой маршрутизатор станет отбрасывать пакеты, хотя у него будет возможность продвинуть их с сохранением обеих зон. Пусть читатель сделает это на бумаге в качестве упражнения, используя области "канал", "сайт" и "вселенная".

Наконец мы можем сказать, что поняли структуру областей и зон IPv6. Теперь пора выполнить наше обещание и дать администратору сети НИИЧАВО необходимые инструменты, чтобы провести ping узла (а точнее, его интерфейса) FE80::Baa1 в отделе атеизма (канал К4). Какой информации не хватает в командной строке: "ping6 fe80::baa1"? Индекса зоны?

Чуть позже мы узнаем, что в IPv6 есть свой протокол управления, отличный от ICMP. Поэтому ping теперь называется ping6.Впрочем, без новой утилиты можно было и обойтись: выбор протокола могла бы выполнить одна и та же утилита ping по версии адреса назначения. К примеру,именно так поступает командный интерфейс JunOS, хотя его команда ping все равно вызывает за кулисами /sbin/ping или /sbin/ping6 в зависимости от версии данного адреса.

Как мы уже не раз говорили, численный адрес IPv6 сам указывает на свою область, в данном случае канал; индекс зоны тоже содержит в себе эти сведения. Выходит, что дополнить численный адрес индексом зоны было бы избыточно. Чтобы устранить эту избыточность, давайте еще раз просмотрим наши выкладки и решим такой ребус: чему равен полный зонный адрес IPv6 за вычетом адреса численного? Напрашивается такой ответ: он равен сетевому интерфейсу в данной зоне. Ведь именно знание входного интерфейса позволяет узлу дополнить численный адрес его зоной в принятом пакете. Поэтому кандидат №1 на роль удобного и понятного идентификатора, который расширит численный адрес IPv6 до зонного, — это системное имя сетевого интерфейса, подключенного к требуемой зоне. Например, если канал К4 подключен к серверу НИИЧАВО через интерфейс en3, то зонный адрес "FE80::Baa1 на канале К4" достаточно записать в командной строке, например, так: ping6 FE80::BAA1%en3

В этой нотации между численным адресом и именем интерфейса стоит символ процента, который реже других встречается в сетевом букваре.

Следует признать, что этот выбор символа-разделителя не идеален. Так, процент — это метасимвол в формате URI, так что зонный адрес IPv6, строго говоря, нельзя указать в URI буквально. Работа над оптимальным решением этого противоречия еще не завершена [draft-fenner-literal-zone, draft-ietf-6man-uri-zoneid].

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

(рис 1.8) Начальная настройка узла: гипотеза взаимно однозначного соответствия между интерфейсами и внутриканальными зонами (рис 1.9) Разрешение неоднозначности: два интерфейса подключены к одному каналу

Поэтому окончательную картину соответствия между интерфейсами и зонами способен построить только инженер-проектировщик данной сети. Имена же интерфейсов в системе дают лишь хорошее начальное приближение, которое система способна построить автоматически (см. рис. 1.8), так что администратору останется только скорректировать его, пользуясь картой сети [§6 RFC 4007], — например, как это изображено на рис. 1.9.

Как следствие, сетевой стек IPv6 должен предоставить инструменты для подстройки соответствий между интерфейсами и зонами.

Чтобы отразить эту особенность в терминологии, мы дадим текстовому идентификатору зоны отдельное название: zone_id [§11.2 RFC 4007] Такой идентификатор чаще всего совпадает с системным именем одного из интерфейсов, потому что это удобно и понятно, но жесткой связи между ними нет. В результате мы получаем такую текстовую нотацию зонного адреса IPv6:

численный_адрес%zone_id

Если мы хотим записать зонный префикс, то его длину следует поместить, как и прежде, после адреса [§11.7 RFC 4007]:

численный_адрес%zone_id/длина_префикса

Вот пример сочетания внутриканального адреса и длины префикса в одной строке:

FE80::DADA:C001%en5/64

Поскольку системные имена интерфейсов в разных системах выглядят по-разному, то и формат zone_id у них разный. В Табл. 1.2 приведено несколько примеров, как была бы введена команда ping6 по внутриканальному адресу хоста НИИЧАВО в разных ОС.

Ping по внутриканальному адресу в разных ОС

ОС	Команда
FreeBSD	ping6 FE80::Baa1%fxp3
Linux	ping6 FE80::Baa1%eth3
Mac OS X	ping6 FE80::Baa1%en3
MS Windows	ping6 FE80::Baa1%5

Кстати, это еще одна иллюстрация того, как идентификация зон локальна для каждого узла.

Чтобы завершить нашу работу над зонной архитектурой IPv6, нам надо рассмотреть последний вопрос: всегда ли в настройках и командной строке адрес IPv6 придется дополнять zone_id? На самом деле, нет. Во-первых, среди всевозможных областей IPv6 есть две области с особыми свойствами:

У адреса обратной связи ::1 область действия ограничена виртуальным интерфейсом типа "петля". Узлу нужен ровно один такой интерфейс, так что адрес обратной связи дополнять zone_id не надо. Можно сказать, что адрес ::1 — это особый случай внутриканального адреса, который встречается только на виртуальном канале интерфейса "петля" [§6 RFC 4007].

Глобальный адрес, такой как 2001:DB8::1, наделен в космическую эпоху даже не глобальной, а вселенской областью действия, так что никаких дополнительных указателей он тоже не требует — по крайней мере, пока к Internet не подключатся параллельные вселенные, жители которых тоже изобрели IPv6.

Здесь будет уместно замечание по поводу термина зонный адрес (scoped address), который встречается не только в нашем изложении, но и в документах RFC. Не следует понимать этот термин как "неглобальный адрес". Суть зонной адресной архитектуры IPv6 как раз в том, что у всех адресов кроме неопределенного есть область действия, просто у некоторых она глобальная. Поэтому "зонный адрес" — это адрес, который может и не быть глобальным, адрес произвольной области. Этот термин — памятка разработчику протокола или реализации, выросшему в среде IPv4, чтобы тот не забывал о существовании адресов IPv6, область действия которых меньше глобальной, и подвергал тщательному анализу детали своей разработки, связанные с этим необычным свойством адресации IPv6.

Кроме того, на практике удобно опустить zone_id, если эта информация избыточна. Например, какой смысл указывать его для внутрисайтового адреса, если все интерфейсы нашего узла принадлежат одному сайту, или для внутриканального адреса, если узел снабжен ровно одним интерфейсом помимо "петли"? Обобщить эту мысль можно, рекомендовав реализациям IPv6 поддержку зон по умолчанию, чтобы у каждой области была одна такая зона [§6 RFC 4007]. Тогда сетевой стек по численному значению адреса IPv6 без zone_id сможет "угадать" его зону.

Обратное тоже верно: на практике может быть удобно снабдить определенным zone_id адрес, у которого вообще нет области, — неопределенный адрес. Как мы уже сказали, в API сокетов Беркли неопределенным адресом приложение говорит сетевому стеку: выбери адрес сам. Если же приложение снабдит неопределенный адрес определенным значением zone_id, это может означать выбор подходящего адреса в пределах данной зоны [§4 и §11.1 RFC 4007].

Хотя до сих пор мы говорили про области и зоны индивидуальных адресов IPv6, ограничить область действия мы можем и у группового адреса. Тогда, к примеру, мы сможем назначить общепринятый групповой адрес "все маршрутизаторы данного канала". Подробнее об областях групповых адресов мы поговорим ниже, в §2.8.

Общепринятые функции внутриканальных адресов

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

Напомним себе, что значит "общепринятый" в контексте TCP/IP. В Internet никогда не было стандартов в полном смысле этого слова, потому что никто никому их не навязывал и никто не следил за их соблюдением. Каждый сам решал, придерживаться ли RFC или нет, но тем, кто выдумывал свои собственные технические условия, не стоило удивляться, что их система ни с чем больше не совместима. Отсюда и появились общепринятые форматы данных, значения параметров и правила поведения сторон: они всего лишь известны и добровольно приняты теми, кто желает, чтобы их система могла взаимодействовать с остальным миром. Хотя "стандартный" и "общепринятый" для нас синонимы, последний гораздо лучше передает техническую философию Сети.

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

В первую очередь, это продвижение пакетов (forwarding). Согласно фундаментальной модели IP — а IPv6 наследует ее без изменений, — пакеты перемещаются между узлами по каналам. Поэтому элементарным актом перемещения пакета от источника к адресату выступает шаг (hop) — передача пакета другому узлу IP в пределах одного канала, — а адрес сетевого интерфейса-получателя называют адрес следующего шага (next hop address), таким образом подчеркивая, что этот шаг может быть не последним на пути пакета.

Эти азбучные истины TCP/IP мы повторили только ради "синхронизации" с читателем.

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

Если мы рассмотрим маршрутизатор как роль узла, то она сводится только к продвижению транзитных пакетов, тогда как созданием и поглощением пакетов ведает роль, известная нам как хост. Следовательно, для выполнения функции маршрутизатора узлу вполне достаточно внутриканальных адресов. Преимущество подобного подхода в том, что транзитная инфраструктура сети То, что раньше называли "подсеть", то есть сеть за вычетом хостов. вообще не зависит от адресов, которыми хосты пользуются для сквозной передачи данных между собой. К примеру, если организация переходит к другому провайдеру услуг Internet и получает новый диапазон глобальных адресов взамен старого, ей не придется менять адреса на интерфейсах своих маршрутизаторов. Чтобы поощрить эту практику, мы выдвинем такое требование: каждый интерфейс маршрутизатора IPv6 обязан обладать как минимум одним индивидуальным внутриканальным адресом [§2.3 RFC 4861].

Второе возможное применение внутриканальных адресов — это распространение сведений, необходимых для автоматической настройки хостов. Здесь внутриканальные адреса способны разрешить "проблему курицы и яйца", когда хост не может получить из сети информацию для автоматической настройки своего сетевого интерфейса до тех пор, пока он не назначил интерфейсу адрес. Эта тема заслуживает развернутого обсуждения, и мы к ней еще вернемся ниже, в §5.4; а пока что, немного забегая вперед, скажем: хост IPv6 будет обязан поддерживать механизм автоматической настройки, а для этого его сетевому интерфейсу понадобится внутриканальный адрес [RFC 4862].

Подведем итог: каждый сетевой интерфейс IPv6 обязан иметь по меньшей мере один индивидуальный внутриканальный адрес [§2.1 RFC 4291]. Помимо него, интерфейсу понадобятся адреса в зонах большей величины. Ведь это лишь частный случай назначения одному интерфейсу нескольких адресов — полезной практики, принятой еще во времена IPv4 [§3.3.4.1 RFC 1122], — и мы пока что не обнаружили никаких причин отказаться от нее. Поэтому пусть у сетевого интерфейса IPv6 может быть несколько индивидуальных адресов, области Мы говорим "области", а не "зоны", потому что два адреса одного интерфейса никак не могут находиться в разных зонах одной области. И наоборот, если их области одинаковы, то и зона совпадает. Это следует из правил зонной топологии IPv6. и подсети которых могут как совпадать, так и быть разными [§2.1 RFC 4291].

Говоря проще, у сетевого интерфейса IPv6 может быть много индивидуальных адресов, а у некоторых или всех из них вполне может совпадать область, или даже префикс подсети. Подобный вывод о групповых адресах последует из этого, когда в §5.1 мы доберемся до розыска соседей, так как тогда интерфейсу IPv6 потребуется вплоть до одного группового адреса на каждый индивидуальный.

У этого простого, на первый взгляд, решения о поддержке множества адресов на интерфейсе IPv6 есть далеко идущие последствия для других протоколов. Вот только один пример. OSPF для IPv6 (OSPFv3) оперирует целыми каналами [§2.1 RFC 5340], а не отдельными подсетями, как делал его предшественник OSPFv2. Когда на каждом канале целое множество подсетей, прежний подход был бы неэффективен.