Формат дейтаграммы протокола IPv6

Формат дейтаграммы протокола IPv6 показан на рис. 4.39. По новому формату можно судить о наиболее существенных изменениях в протоколе IP.
□ Расширенные возможности адресации. В дейтаграмме протокола IPv6 размер IP-адреса увеличен с 32 до 128 бит. Это гарантирует, что адресного пространства будет хватать всем и всегда. Теперь можно дать IP-адрес каждой песчинке на планете. В дополнение к индивидуальным и групповым адресам в протоколе IPv6 появился новый тип адресов, называемых адресами свободной рассылки (anycast addresses), позволяющих пересылать дейтаграмму любому члену группы хостов. (Это может служить, например, для передачи сообщения HTTP GET ближайшему из нескольких зеркальных сайтов, содержащих данный документ.)
□ Упрощенный 40-разрядный заголовок. Несколько полей протокола IPv4 были опущены или сделаны необязательными, о чем будет сказано далее. Получившийся в результате 40-разрядный заголовок фиксированной длины обеспечивает ускоренную обработку IP-дейтаграммы. Новый способ кодирования необязательных полей обеспечивает их более гибкую обработку. Метка потока и приоритет. Определение потока в протоколе IPv6 довольно расплывчато. В RFC 1752 и RFC 2460 утверждается, что поле метки потока позволяет «маркировать пакеты, для которых отправителю требуется специальная обработка, например, обслуживание с отличным от предоставляемого по умолчанию уровнем качества или обслуживание в реальном времени». С одной стороны, обрабатываться в качестве потока могут, например, транслируемые аудио- или видеоданные, трафик высокоприоритетного пользователя (например, платящего за более качественное обслуживание своего трафика). С другой стороны, традиционные приложения, такие как приложения передачи файлов и электронной почты, в качестве потока могут не обрабатываться. Ясно лишь то, что разработчики протокола IPv6 предвидят необходимость в дифференцировании потоков, несмотря на то что точное понятие потока еще не определено. В заголовке IPv6 также есть восьмиразрядное поле класса трафика. Подобно полю TOS (Type Of Service — тип службы) протокола IPv4 это поле может использоваться для предоставления приоритета определенным пакетам потока, а также для предоставления приоритета дейтаграммам определенных приложений (например, ICMP-пакетам) по сравнению с дейтаграммами других приложений (например, пакетам с сетевыми новостями).

Как упоминалось выше, формат IPv6^emarpaMM проще формата IPv4-дейтаграмм (см. рис. 4.23 и 4.39). Ниже перечислены поля IPve-дейтаграммы.
□ Версия. Это 4-разрядное поле идентифицирует номер версии протокола IP и для протокола IPv6 содержит значение 6. Обратите внимание, если поместить в это поле значение 4, то мы не получим корректную дейтаграмму протокола IPv4 (если бы это было так, жизнь была бы намного проще).
□ Класс трафика. Это 8-разрядное поле отчасти напоминает поле TOS протокола IPv4.
□ Метка потока. Как упоминалось выше, это 20-разрядное поле используется для идентификации «потока» дейтаграмм.
□ Длина полезной нагрузки. Это 16-разрядное поле обрабатывается как целое число без знака и содержит количество байтов в 1Ру6-дейтаграмме, следующих за 40-разрядным заголовком дейтаграммы.
□ Следующий заголовок. Это поле идентифицирует протокол, которому доставляется содержимое (поле данных) дейтаграммы (например, TCP или UDP). Для этого поля используются те же значения, что и для поля протокола в IPv4-3aro-ловке.
□ Ограничение на число ретрансляционных участков. Содержимое этого поля уменьшается на единицу на каждом маршрутизаторе, через который проходит дейтаграмма. Когда содержимое этого поля достигает нуля, дейтаграмма уничтожается.
□ Адреса отправителя и получателя. Различные форматы 128-разрядных IPv6-адресов описаны в RFC 2373.
□ Данные. Это полезная нагрузка IPv6-дейтаграммы. Когда дейтаграмма достигает пункта назначения, полезная нагрузка извлекается из нее и передается протоколу, указанному в поле следующего заголовка.

Итак, мы перечислили поля, включенные в IPv6-дейтаграмму. Сравнивая формат IPv6-дейтаграммы, показанной на рис. 4.39, с форматом дейтаграммы протокола IPv4 на рис. 4.23, можно заметить, что некоторые поля IPv4-дейтаграммы не включены в IPv6-дейтаграмму.

□ Фрагментация/повторная сборка. Протокол IPv6 не позволяет производить на маршрутизаторах фрагментацию и повторную сборку. Если принятая маршрутизатором IPv6-дейтаграмма слишком велика для передачи по выходной линии, маршрутизатор просто отбрасывает такую дейтаграмму и посылает обратно отправителю (см. ниже) ICMP-сообщение об ошибке (пакет слишком велик). Отправитель может послать данные еще раз, используя IP-дейтаграммы меньшего размера. Такие операции, как фрагментация и повторная сборка дейтаграмм, требуют много времени. Избавление маршрутизаторов от необходимости выполнять подобные действия существенно ускоряет работу протокола IP.
□ Контрольная сумма заголовка. Поскольку протоколы транспортного уровня (например, TCP и UDP), а также протоколы канального уровня (например, Ethernet) в архитектуре протоколов Интернета считают контрольную сумму передаваемых данных, разработчики протокола IP посчитали, что реализация той же функции на сетевом уровне будет излишней. Опять же, центральной задачей была быстрая обработка IP-пакетов. Как было показано в подразделе «Адресация в протоколе IPv4» раздела «Интернет-протокол», поскольку IPv4-заголовок содержит поле времени жизни (TTL), аналогичное полю ограничения на число ретрансляционных участков в протоколе IPv6, контрольную сумму IPv4-заголовка приходилось пересчитывать на каждом маршрутизаторе. Как и фрагментация, и повторная сборка, эта операция также отнимает много времени.
□ Параметры. Поле параметров более не входит в стандартный IP-заголовок. Однако от него не отказались полностью. Вместо этого поле необязательных параметров может быть одним из «следующих заголовков» (наравне с ТСР-или UDP-заголовками), на которые может ссылаться 1Ру6-заголовок. В результате удаления этого поля длина IP-заголовка стала фиксированной (40 байт).