IPv6 для профессионалов

IPv6 для профессионалов

2-е издание, исправленное

Тихий Я.В.

Национальный Открытый Университет “ИНТУИТ”
2016

2

IPv6 для профессионалов/ Я.В. Тихий - М.: Национальный Открытый Университет “ИНТУИТ”, 2016

Курс посвящен углубленному изучению архитектуры IPv6 методом последовательной реконструкции
(воссоздания) данной системы протоколов.
Целевая аудитория курса — это специалисты TCP/IP, выросшие в среде IPv4. Курс опирается на
всесторонние знания о предыдущей версии IP и предъявляет высокие требования к уровню
подготовки учащегося. В ходе курса будут рассмотрены все основные аспекты IPv6: адресация,
структура и функции заголовков, правила фрагментации, взаимодействие со смежными протоколами,
протокол управления, розыск соседей, автоматическая настройка узлов, управление групповым
вещанием, а также вспомогательные механизмы конфиденциальности, безопасности и
отказоустойчивости. Это отвечает следующим протоколам стека IPv6 (в алфавитном порядке):
базовый IPv6, ICMPv6, MLD, NDP, SEND, Shim6, SLAAC.

(c) ООО “ИНТУИТ.РУ”, 2013-2016
(c) Тихий Я.В., 2013-2016

3

Предисловие

Умный поймет с полуслова. (Пословица)

Хотя IPv6 уже давно у всех на слуху, многие сетевые инженеры по-прежнему не
спешат с головой погрузиться в новую технологическую реальность, и у них на то есть
уважительная причина: банальный недостаток времени на изучение новой
архитектуры. Безусловно, не осталось никого, кто не слышал бы о пресловутом 128-
битном адресе IPv6; но, увы, слишком часто познания о новом протоколе этим и
ограничиваются. По злой иронии, сейчас, когда адресное пространство IPv4
фактически исчерпано и все поголовно рвутся осваивать IPv6, вынужденный и
поспешный переход меньше всего способствует глубокому пониманию достоинств
нового протокола. Ведь и правда, кто же станет ночи напролет корпеть над
многочисленными тонкостями, когда обстоятельства требуют только удлинить адрес
IP, и как можно скорее? Такой поворот событий оказывает медвежью услугу всем
участникам процесса. С одной стороны, авторы IPv6 проделали огромную работу по
созданию новой архитектуры сетевого уровня для Internet, но их фундаментальные
идеи так и не получают широкого признания — совершенно невозможного без знания.
С другой стороны, сетевые инженеры погрязли в рутине и лишены того удовольствия,
которое испытывает специалист, только вполне осмыслив и оценив по достоинству
новую технологию — не говоря уже о том, что само эффективное ее использование
невозможно без всестороннего понимания.

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

В полной мере ощутив эти трудности на собственном опыте, мы осмелимся
предложить старой гвардии игру поинтереснее. В этой книге мы поставим себя на
место создателей IPv6 и вообразим, будто это мы сами — вместе с читателем, конечно
же! — по частям разрабатываем и собираем механизм IPv6, опираясь только на наш
опыт с IPv4. Поспешим заверить: мы вовсе не пытаемся присвоить чужие лавры, а
лишь воздаем дань гению настоящих авторов IPv6. Ведь, как мы сами скоро убедимся,
практически все аспекты IPv6 можно понять и объяснить с четких технических
позиций. Пока индустрия TCP/IP не торопилась принять IPv6 на вооружение, у его
разработчиков было достаточно времени, чтобы старательно отшлифовать каждую
деталь. Если IPv4 — это был, по сути, плод эксперимента, создание первопроходцев, у
которых еще не было опыта и готовых ответов на многие вопросы, то IPv6 —
тщательно продуманный механизм, в котором каждая деталь находится на своем месте.

Нам остается надеяться, что такой не совсем традиционный подход к изложению
материала поможет воздать всем по заслугам. Прежде всего, эксперты по TCP/IP,
стремящиеся включить IPv6 в свой арсенал, будут вознаграждены за потраченные на
учебу усилия. По ходу курса у них будет возможность насладиться знакомством с
новыми интересными идеями и еще раз подтвердить собственный уровень, а в

4

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

5

Адресация IPv6

Почему необходим новый протокол и как избежать повторения старых ошибок.
Возрождение сквозного принципа. Планирование адресного пространства IPv6.
Объективная оценка требуемого числа адресов. Текстовая запись адреса IPv6. Типы
адресов IPv6. Зонная адресная архитектура IPv6 и ее приложения.

Предпосылки

Революция — это не торжественный обед и не литературный вечер, не рисунок и не
вышивка; ее нельзя вершить изысканно и учтиво. Революция — это акт насилия. (Мао
Цзе-Дун)

Чтобы разработать для Internet сетевой протокол нового поколения, нужен весьма
серьезный толчок. Ведь вложения труда и средств в уже существующий протокол IP
версии 4 весьма и весьма велики. Пусть стартовым импульсом нам послужит тот
прискорбный факт, что глобальное адресное пространство IPv4 уже практически
исчерпано1).

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

Прежде чем мы двинемся дальше, нам следует разобраться, почему адресное
пространство IPv4 считается исчерпанным. Разумеется, это вовсе не означает, что
число хостов в Internet уже достигло предела. Куда же тогда делись адреса? Мы
должны разгадать тайну пропавших адресов, чтобы по возможности избежать той же
проблемы в новом протоколе.

Часть адресов IPv4 зарезервирована для специальных целей [RFC 5735]; часть теряется
на границах подсетей; и, наконец, какое-то их число просто стало жертвой
неоптимального распределения в те времена, когда недостатка в адресах еще не
ощущалось: организации получили большие блоки адресов, но назначили узлам2)

далеко не все из них.

Главный же источник потерь кроется в иерархической структуре индивидуальных
(unicast) адресов IPv4 [RFC 3194]. Как мы знаем, их распределяют не по одному, а
путем последовательного деления больших блоков на меньшие [§4.2 RFC 4632]: IANA
“раскраивает” все адресное пространство IPv4 и выдает самые большие блоки в
ведение RIR; те делят полученные блоки и выдают в руки LIR блоки поменьше; а LIR
уже выдают адреса или напрямую конечным пользователям, или провайдерам Internet
без статуса LIR, чтобы те передали их пользователям. Конечный пользователь в этой
схеме тоже может быть организацией, в которой есть своя сетевая под-иерархия.

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

6

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

Деление и слияние как способ эволюции объектов имеет и другие, не столь важные для
нас теперь, но оттого не менее интересные последствия для численного выражения их
размерам3)

Потери адресов при иерархическом распределении неизбежны; это плата за то, что
адреса IP не приходится выпрашивать по одному непосредственно у IANA. К счастью,
мы не первые, кто столкнулся с этой проблемой: она хорошо знакома телефонистам.
Ведь телефонные номера тоже основаны на иерархии префиксов, только десятичных, а
не двоичных, и номера эти уже не раз приходилось удлинять, чтобы поддержать рост
телефонных сетей. Этот опыт для нас особо ценен, так как он говорит, что потери
адресного пространства поддаются эмпирическому прогнозированию с помощью
логарифмического коэффициента плотности узлов HD [RFC 3194]:

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

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

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

Ссылаясь на опыт телефонных сетей и вычислительных сетей предыдущего поколения,
[RFC 3194] делает вывод, что дальнейший рост сети становится практически
невозможным, когда HD достигает порогового значения 0,87. Для 32-битного адреса
это означает порядка 240 миллионов узлов, тогда как адресов IPv4 уже выделено, по
разным оценкам, 2–3 миллиарда4). Проблема налицо!

Между тем, заметьте: Internet достиг ранее неслыханного значения HD 0.96–0.98, и
только тогда начались настоящие трудности с адресным пространством IPv4. Что
может быть лучшим комплиментом механизму распределения адресов, принятому в
Internet? Есть даже мнение, что управление ростом сетей IP на основе пороговых
значений HD, взятых из истории, может оказаться чрезмерно консервативным и
недооценить возможности технологии IP по поддержанию густонаселенных сетей
[RFC 4692].

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

7

Нехватка адресов всерьез сказывается не только на практике, но и на философии
Internet. Получение глобальных адресов IPv4 становится все более хлопотным делом,
потому что администраторы всех уровней иерархии стараются экономить этот ценный
ресурс. В ответ рождаются технические решения, которые позволяют обходиться всего
несколькими глобальными адресами на сеть, независимо от числа хостов в ней. Самые
популярные приемы — это NAT и proxy в сочетании с частным адресным
пространством. В свою очередь, повсеместное их применение приводит к неявному
отказу от главного принципа Internet: сквозной прозрачности на сетевом уровне [RFC
2775], когда любой хост А может послать пакет IP любому хосту Б (где А может быть
равно Б). В TCP/IP этот принцип осуществим, только пока у каждого хоста есть
собственный глобальный адрес.

Можно сказать и так: исторически хосту Internet полагалось иметь глобальный адрес,
чтобы сквозная прозрачность стала реальностью. Ведь пока хосты А и Б находятся в
одном адресном пространстве IP, адрес Б — единственное, что должен знать хост А,
чтобы однозначно передать пакет хосту Б.

А следующим шагом сетевые инженеры открыто хоронят сквозную прозрачность: они
объявляют ее вредной для безопасности и конфиденциальности доступа к Internet, а
затем провозглашают NAT и proxy универсальными защитниками частной сети.
Давайте посмотрим, можно ли согласиться с такой точкой зрения.

Прежде всего, надо иметь в виду, что экономия адресного пространства, защита
безопасности и обеспечение конфиденциальности доступа — это совершенно разные
задачи, каждую из которых можно решить только целенаправленно. Поэтому NAT и
proxy экономят сетевые адреса, и не более того. Злоумышленники уже научились
преодолевать границы частных сетей, например, заражая компьютер внутри такой сети
с помощью электронного письма и заставляя его самостоятельно выходить на связь с
“подпольным центром управления”. А маскировка сетевого адреса еще не гарантирует,
что сеансы пользователя останутся конфиденциальными: пользователя может выдать
не только его адрес IP, но также данные прикладного уровня, например, заголовки
электронных писем и поля запросов HTTP, и даже значения полей в заголовках
сетевого и транспортного уровней, если провести их корреляцию во времени.
(Простейший пример — когда хост последовательно увеличивает значение
идентификатора в заголовке IPv4, так что его пакеты легко выделить из общего потока
даже после NAT.)

Еще популярно мнение, что NAT обеспечивает безопасность частной сети при
минимальных затратах на настройку и поддержку, по принципу: установил и забыл.
Сторонники этой точки зрения вообще склонны к забывчивости и потому не помнят,
сколько человеко-часов уходит на то, чтобы “подружить” NAT с некоторыми
протоколами, из которых вспомним хотя бы IPsec5), RFC 3715], FTP и SIP.

Прочие сетевые приложения, для полноценной работы которых необходим известный
или хотя бы фиксированный адрес IP, сами идут на различные трюки, собирательно
известные как “односторонняя фиксация собственного адреса” (Unilateral Self-Address
Fixing, UNSAF), чтобы обхитрить NAT [RFC 3424]. В свою очередь, это создает
дополнительные бреши в и без того слабой системе безопасности, так как

8

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

Чисто практические затруднения, вызванные NAT, — это только видимая верхушка
айсберга. У применения NAT есть и менее очевидные последствия на уровне
архитектуры Internet. Их развернутый анализ можно найти в [RFC 2993].

Теперь перейдем к тезису о том, что сквозная прозрачность Internet опасна. Может ли
быть опасным принцип? Наверное, да, если он однозначно ведет к опасным
результатам, но это едва ли относится к сквозной прозрачности. Речь ведь идет не о
полной доступности, когда всем хостам позволен бесконтрольный обмен данными, а о
сквозной адресации. Это значит, что непосредственное взаимодействие хостов всегда
возможно технически, а разрешать его или нет — вопрос чисто административный.
Если же мы отступимся от принципа сквозной прозрачности, то обязательно возникнут
ситуации, когда прямое взаимодействие узлов необходимо, но технически невозможно.
Любой инженер-практик знает, как неприятно оказаться в подобном тупике.

Конечно, NAT и proxy — далеко не единственные враги сквозной прозрачности
Internet. За более подробным “черным списком” мы отсылаем читателя к [RFC 2775].

Восстановить сквозную прозрачность Internet можно, только увеличив число
глобальных сетевых адресов, — иного пути здесь нет. Число адресов IPv4 ограничено,
потому что у их двоичного представления фиксированная длина. Мы не собираемся
отказываться от двоичного представления информации, так что нам придется просто
увеличить число двоичных разрядов в адресе IP. Насколько радикальные изменения
это вызовет в технологии TCP/IP?

Попробуем для начала консервативный подход. Можно ли расширить адрес IP, не
отказываясь от протокола IPv4 и, в частности, от его формата заголовка? Например, мы
могли бы поместить новые, расширенные адреса в специальные опции IPv4. ARP
справился бы с новыми адресами, так как длина адреса в нем явно указывается. С
ICMP ситуация сложнее, так как некоторые типы сообщений ICMP включают в себя
адреса IPv4. Наконец, фиксированное смещение адресов от начала заголовка облегчает
быструю аппаратную маршрутизацию пакетов, тогда как размещение адресов в опциях
значительно усложнило бы ее. Ну, и вообще говоря, опции потому так и называются,
что они должны быть факультативными, то есть необязательными для исполнения. Это
окончательный аргумент против того, чтобы новые адреса находились в опциях IPv4. В
то же время, основной заголовок IPv4 рассчитан только на 32 битные адреса. Вывод
такой, что текущим форматом заголовка IPv4 нам все-таки придется пожертвовать,
поскольку в нем нет места для новых адресов.

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

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

9

помощью можно будет отличить новые пакеты IP от старых, не привлекая
дополнительных сведений: сетевому стеку будет достаточно проверить значение этого
поля. Если мы так поступим, то будущий протокол формально окажется новой версией
IP. По историческим причинам он получил от IANA номер версии 66), поэтому и
назовем мы его “IP версии 6”, или кратко IPv6.

Формат пакета IP, не зависящий от версии протокола

Мы скоро убедимся, тем не менее, что архитектурный фундамент IPv4 и IPv6 не так уж
сильно разнится. Говоря об их общих чертах, мы будем использовать собирательное
наименование: IP.

Длина адреса IPv6

— Скажите, Шура, честно, сколько вам нужно денег для счастья? — спросил Остап. —
Только подсчитайте все.

— Сто рублей, — ответил Балаганов, с сожалением отрываясь от хлеба с колбасой.

— Да нет, вы меня не поняли. Не на сегодняшний день, а вообще. Для счастья. Ясно?
Чтобы вам было хорошо на свете.

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

— Ладно, — сказал Остап, — получите пятьдесят тысяч.

(И. Ильф, Е. Петров. “Золотой теленок”)

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

1. “не надо гадать на кофейной гуще”: оставим попытки предсказать длину нового

адреса IP и сделаем ее переменной;

2. “к природе за советом”: давайте посмотрим, сколько всего песчинок в пустыне

Сахара, молекул воды в мировом океане или протонов в наблюдаемой вселенной,
и решим, что большего числа адресов IP человечеству никогда не понадобится;

3. “возможности во главе угла”: длина адреса IP должна стать такой, чтобы это

открыло новые возможности на уровне работы протокола.

10