Из Википедии, бесплатной энциклопедии
  (Перенаправлено из заголовка IPv6 )
Перейти к навигации Перейти к поиску

Пакет IPv6 - это наименьший объект сообщения, которым обмениваются с использованием Интернет-протокола версии 6 (IPv6).

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

Пакеты IPv6 обычно передаются на канальном уровне, например, через Ethernet , который инкапсулирует каждый пакет в кадр . Пакеты также могут транспортироваться по протоколу туннелирования более высокого уровня , например IPv4, при использовании технологий перехода 6to4 или Teredo .

В отличие от обработки IPv4, маршрутизаторы не фрагментируют пакеты IPv6, размер которых превышает максимальную единицу передачи (MTU), это является исключительной ответственностью исходного узла. IPv6 требует минимального MTU в 1280 октетов , но хостам «настоятельно рекомендуется» использовать Path MTU Discovery, чтобы использовать MTU больше минимального. [1]

С июля 2017 года Internet Assigned Numbers Authority (IANA) отвечает за регистрацию всех параметров IPv6, которые используются в заголовках пакетов IPv6. [1]

Фиксированный заголовок [ править ]

Фиксированный заголовок запускает пакет IPv6 и имеет размер 40 октетов (320 бит ). [1]

Фиксированный формат заголовка
СмещенияОктет0123
ОктетКусочек0123456789101112131415161718192021 год22232425262728293031 год
00ВерсияКласс трафикаЭтикетка потока
432Длина полезной нагрузкиСледующий заголовокПредел хопов
864Адрес источника
1296
16128
20160
24192Адрес назначения
28224
32256
36288
Версия (4 бита)
Константа 6 (битовая последовательность 0110 ).
Класс трафика (6 + 2 бита)
Биты этого поля содержат два значения. Шесть старших битов содержат поле дифференцированных услуг (поле DS), которое используется для классификации пакетов. [2] [3] В настоящее время все стандартные поля DS заканчиваются битом «0». Любое поле DS, которое заканчивается двумя битами «1», предназначено для локального или экспериментального использования. [4]
Оставшиеся два бита используются для явного уведомления о перегрузке (ECN); [5] значения приоритета подразделяются на диапазоны: трафик, в котором источник обеспечивает управление перегрузкой, и трафик управления без перегрузки.
Этикетка потока (20 бит)
Идентификатор с высокой энтропией потока пакетов между источником и местом назначения. Поток - это группа пакетов, например, сеанс TCP или медиапоток. Специальная метка потока 0 означает, что пакет не принадлежит ни одному потоку (при использовании этой схемы). Более старая схема идентифицирует поток по адресу источника и порту, адресу назначения и порту, протоколу (значение последнего поля следующего заголовка ). [6] Кроме того, было предложено использовать метку потока для обнаружения поддельных пакетов. [7]
Длина полезной нагрузки (16 бит)
Размер полезной нагрузки в октетах, включая любые заголовки расширения. Длина устанавливается равной нулю, когда заголовок расширения " шаг-за-шагом" содержит параметр " Jumbo Payload" . [8]
Следующий заголовок (8 бит)
Задает тип следующего заголовка. В этом поле обычно указывается протокол транспортного уровня , используемый полезной нагрузкой пакета. Если в пакете присутствуют заголовки расширения, это поле указывает, за каким заголовком расширения следует. Эти значения совпадают со значениями, используемыми для поля протокола IPv4, поскольку оба поля имеют одинаковую функцию (см. Список номеров IP-протоколов ).
Предел скачка (8 бит)
Заменяет поле времени жизни в IPv4. Это значение уменьшается на единицу на каждом узле пересылки, и пакет отбрасывается, если он становится равным 0. Однако узел назначения должен обрабатывать пакет обычным образом, даже если он получен с пределом скачков, равным 0.
Исходный адрес (128 бит)
Одноадресный IPv6-адрес отправляющего узла.
Адрес назначения (128 бит)
Одноадресный или многоадресный IPv6-адрес узла (ов) назначения.

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

Заголовки расширений [ править ]

Заголовки расширений несут дополнительную информацию об уровне Интернета и помещаются между фиксированным заголовком и заголовком протокола верхнего уровня. [1] Заголовки расширений образуют цепочку с использованием полей следующего заголовка . Поле следующего заголовка в фиксированном заголовке указывает тип первого расширенного заголовка; следующего заголовка поле заголовка последнего расширения указывает тип заголовка протокола верхнего слоя в полезной нагрузке пакета. Все заголовки расширения имеют размер, кратный 8 октетам; некоторые заголовки расширения требуют внутреннего заполнения для удовлетворения этого требования.

Определено несколько заголовков расширений [1], и в будущем могут быть определены новые заголовки расширений. Заголовки расширений должны проверяться и обрабатываться только в месте назначения пакета, за исключением параметров « шаг за шагом» , который является единственным, который может обрабатываться и даже изменяться промежуточными узлами. [1] Заданные ниже заголовки расширений перечислены в предпочтительном порядке, если за фиксированным заголовком следует несколько заголовков расширения. Обратите внимание, что все заголовки расширения являются необязательными и должны отображаться не более одного раза, за исключением заголовка « Параметры назначения» , который может отображаться дважды.

Если узел не распознает конкретный заголовок расширения, он должен отбросить пакет и отправить сообщение о проблеме с параметром ( ICMPv6 тип 4, код 1). [1] Когда значение 0 следующего заголовка появляется в заголовке, отличном от фиксированного заголовка, узел должен делать то же самое.

Заголовок расширенияТипОписание
Пошаговые варианты0Параметры, которые необходимо проверить на всех устройствах на пути.
Маршрутизация43Методы для указания маршрута для дейтаграммы (используются с Mobile IPv6 ).
Фрагмент44Содержит параметры для фрагментации дейтаграмм.
Заголовок аутентификации (AH)51Содержит информацию, используемую для проверки подлинности большинства частей пакета.
Инкапсуляция данных безопасности (ESP)50Переносит зашифрованные данные для безопасной связи.
Параметры назначения (перед заголовком верхнего уровня)60Опции, которые нужно проверять только по месту назначения пакета.
Мобильность (в настоящее время без заголовка верхнего уровня)135Параметры, используемые с Mobile IPv6 .
Протокол идентификации хоста139Используется для протокола идентификации хоста версии 2 (HIPv2). [10]
Протокол Shim6140Используется для Shim6 . [11]
Зарезервированный253Используется для экспериментов и тестирования. [12] [4]
Зарезервированный254Используется для экспериментов и тестирования. [12] [4]

Значение 59 (нет следующего заголовка) в поле Next Header указывает на то, что нет следующего заголовка бы то ни было , следующий за этим, даже не в заголовок протокола верхнего уровня. Это означает, что с точки зрения заголовка пакет IPv6 заканчивается сразу после него: полезная нагрузка должна быть пустой. [1] Однако в полезной нагрузке могут все еще присутствовать данные, если длина полезной нагрузки в первом заголовке пакета больше, чем длина всех заголовков расширения в пакете. Хосты должны игнорировать эти данные, но маршрутизаторы не могут их изменить.

Параметры перехода и параметры пункта назначения [ править ]

Hop-на-Hop Options заголовок расширения может быть рассмотрен и изменен всеми узлами на пути пакета, включая отправку и получение узлов. (Для аутентификации значения параметров, которые могут изменяться по пути, игнорируются.) Заголовок расширения Destination Options должен проверяться только узлом (ами) назначения. Оба заголовка расширения имеют размер не менее 8 октетов; если присутствует больше опций, чем умещается в этом пространстве, блоки по 8 октетов добавляются в заголовок многократно - содержащие опции и заполнение - до тех пор, пока не будут представлены все опции.

Формат заголовка расширений " Параметры перехода" и " Параметры назначения"
СмещенияОктет0123
ОктетКусочек0123456789101112131415161718192021 год22232425262728293031 год
00Следующий заголовокHDR Ext LenПараметры и отступы
432Параметры и отступы
864Необязательно: дополнительные параметры и отступы ...
1296
Следующий заголовок (8 бит)
Задает тип следующего заголовка.
HDR Ext Len (8 бит)
Длина этого заголовка в 8-октетных единицах, не считая первых 8 октетов.
Опции (переменные)
Содержит один или несколько параметров и необязательные поля заполнения для выравнивания параметров и для увеличения общей длины заголовка, кратной 8 октетам. Опции имеют кодировку TLV .

Маршрутизация [ править ]

Маршрутизации заголовка расширения используется для направления пакета на один или более промежуточных узлов перед отправкой к месту назначения. Заголовок имеет размер не менее 8 октетов; если требуется больше данных, зависящих от типа , чем умещается в 4 октета, блоки по 8 октетов добавляются в заголовок повторно, пока не будут размещены все данные, зависящие от типа . [1]

Формат заголовка расширения маршрутизации
СмещенияОктет0123
ОктетКусочек0123456789101112131415161718192021 год22232425262728293031 год
00Следующий заголовокHDR Ext LenТип маршрутизацииСегменты слева
432Типовые данные
864Необязательно: дополнительные данные для конкретного типа ...
1296
Следующий заголовок (8 бит)
Указывает тип следующего заголовка.
HDR Ext Len (8 бит)
Длина этого заголовка, кратная 8 октетам, не считая первых 8 октетов.
Тип маршрутизации (8 бит)
Значение от 0 до 255, присвоенное IANA . [13]
ТипПоложение делКомментарий
0Не рекомендуетсяВ связи с тем, что с типом заголовка маршрутизации 0 может быть запущена простая, но эффективная [14] атака отказа в обслуживании ,

этот заголовок устарел с 2007 года [15], и хост и маршрутизаторы должны игнорировать эти заголовки.

1Не рекомендуетсяИспользуется для проекта Nimrod [16], финансируемого DARPA . Устарело с 2009 года.
2ДопустимыйОграниченная версия типа 0 и используется для Mobile IPv6 , где может содержать домашний адрес мобильного узла.
3ДопустимыйЗаголовок маршрута источника RPL [17] для сетей с низким энергопотреблением и с потерями.
253Частное использованиеМожет использоваться для тестирования, но не для реальных реализаций. RFC3692 Эксперимент 1 . [12]
254Частное использованиеМожет использоваться для тестирования, но не для реальных реализаций. RFC3692 Эксперимент 2 . [12]
Сегменты слева (8 бит)
Количество узлов, которые этот пакет еще должен посетить, прежде чем достигнет своего конечного пункта назначения.
Типовые данные (переменная)
Данные, принадлежащие этому типу заголовка маршрутизации.

Фрагмент [ править ]

Чтобы отправить пакет, размер которого превышает MTU пути , отправляющий узел разбивает пакет на фрагменты. Фрагмент заголовок расширения несет информацию , необходимую для сборки оригинала (ненарушенный) пакета. [1]

Формат заголовка расширения фрагмента
СмещенияОктет0123
ОктетКусочек0123456789101112131415161718192021 год22232425262728293031 год
00Следующий заголовокЗарезервированныйСмещение фрагментаResM
432Идентификация
Следующий заголовок (8 бит)
Определяет тип следующего заголовка.
Зарезервировано (8 бит)
Инициализируется всеми нулями.
Смещение фрагмента (13 бит)
Смещение в 8-октетных единицах относительно начала фрагментируемой части исходного пакета.
Res (2 бита)
Зарезервированный; инициализирован нулями.
M Флаг (1 бит)
1 означает, что следуют другие фрагменты; 0 означает последний фрагмент.
Идентификация (32 бита)
Значение идентификации пакета, генерируемое исходным узлом. Требуется для повторной сборки исходного пакета.

Заголовок аутентификации (AH) и инкапсуляция данных безопасности (ESP) [ править ]

Заголовок аутентификации и Encapsulating Security Payload является частью IPsec и одинаково используется в IPv6 и IPv4 в. [18] [19]

Полезная нагрузка [ править ]

За фиксированными и необязательными заголовками IPv6 следует полезная нагрузка верхнего уровня , данные, предоставляемые транспортным уровнем, например сегмент TCP или дейтаграмма UDP . Поле Next Header последнего заголовка IPv6 указывает, какой тип полезной нагрузки содержится в этом пакете.

Стандартная длина полезной нагрузки [ править ]

Поле длины полезной нагрузки IPv6 (и IPv4 ) имеет размер 16 бит, что позволяет указывать максимальную длину65 535 октетов для полезной нагрузки. На практике хосты определяют максимальную полезную длину полезной нагрузки, используя обнаружение MTU пути (что дает минимальный MTU на пути от отправителя к получателю), чтобы избежать необходимости фрагментировать пакеты. Большинствопротоколов канального уровня имеют MTU значительно меньше, чем65 535 октетов.

Джумбограмма [ править ]

Дополнительная функция IPv6, опция jumbo payload в заголовке расширения Hop-By-Hop Options [8], позволяет обмениваться пакетами с полезной нагрузкой до одного октета меньше 4 ГБ (2 32 - 1 =    4 294 967 295 октетов), используя поле длиной 32 бита. Пакеты с такой полезной нагрузкой называются джумбограммами .

Поскольку и TCP, и UDP включают поля, ограниченные 16 битами (длина, указатель срочных данных), поддержка джумбограмм IPv6 требует изменений в реализации протокола транспортного уровня . [8] Джумбограммы актуальны только для ссылок, у которых MTU больше, чем65 583 октета (более65 535 октетов для полезной нагрузки, плюс 40 октетов для фиксированного заголовка, плюс 8 октетов для Hop-по-Hop расширенного заголовка). Только несколько протоколов канального уровня могут обрабатывать пакеты размером более65 535 октетов. [ необходима цитата ]

Фрагментация [ править ]

В отличие от IPv4, маршрутизаторы IPv6 (промежуточные узлы) никогда не фрагментируют пакеты IPv6. Пакеты , превышающего размер блока максимальной передачи (MTU) канал связи назначений отбрасываются , и это состояние сигнализируется пакет слишком большой ICMPv6 типа 2 сообщения в узел инициирующего, аналогично способом IPv4 , когда не фрагментировать бит является набор. [1] Предполагается, что конечные узлы в IPv6 будут выполнять обнаружение MTU пути для определения максимального размера пакетов для отправки, а протокол верхнего уровня должен ограничивать размер полезной нагрузки.

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

Фрагментация [ править ]

Пакет, содержащий первый фрагмент исходного (большего) пакета, состоит из пяти частей: заголовков для каждого фрагмента (важнейшие исходные заголовки, которые многократно используются в каждом фрагменте), за которым следует заголовок расширения фрагмента, содержащий нулевое смещение, затем все оставшиеся исходные заголовки расширения, затем исходный заголовок верхнего уровня (альтернативно заголовок ESP) и часть исходной полезной нагрузки. [1]

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

Заголовки для каждого фрагмента определяются в зависимости от того, содержит ли оригинал заголовок расширения Routing или Hop-by-Hop :

  • ни один не существует: фрагментная часть - это просто фиксированный заголовок
  • Маршрутизация заголовка расширения существует: заголовки в-фрагмента включают в себя фиксированный заголовок и все расширения заголовки вплоть до и включая маршрутизацию одного
  • Hop-на-Hop заголовка расширения существует: заголовки в-фрагмент состоит только из фиксированного заголовка и Hop-по-Hop заголовок расширения.

В любом случае, последний заголовок фрагментной части имеет значение Next Header, установленное на 44, чтобы указать, что следует заголовок расширения фрагмента .

Каждый заголовок расширения фрагмента имеет свой флаг M, установленный в 1 (что указывает на то, что следуют другие фрагменты), за исключением последнего, флаг которого установлен в 0 .

Длина каждого фрагмента кратна 8 октетам, за исключением последнего фрагмента.

Заголовки для каждого фрагмента исторически назывались «нефрагментируемой частью», имея в виду возможность фрагментации остальных заголовков до 2014 г. Теперь заголовки не могут быть фрагментированы. [20]

Повторная сборка [ править ]

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

Если не все фрагменты получены в течение 60 секунд после получения первого пакета с фрагментом, повторная сборка исходного пакета прекращается, и все фрагменты отбрасываются. Если был получен первый фрагмент (который содержит фиксированный заголовок), сообщение Time Exceeded ( ICMPv6 тип 3, код 1) возвращается узлу, создавшему фрагментированный пакет, если пакет был отброшен по этой причине.

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

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

Безопасность [ править ]

Исследования показали, что использование фрагментации может использоваться для обхода средств контроля сетевой безопасности. В результате в 2014 году ранее допускавшееся переполнение цепочки заголовков IPv6 за пределы первого фрагмента стало запрещено, чтобы избежать некоторых очень патологических случаев фрагментации. [20] Кроме того, в результате исследования уклонения от Router Advertising Guard [21] использование фрагментации с обнаружением соседей не рекомендуется, а использование фрагментации с помощью Secure Neighbor Discovery (SEND) не рекомендуется. [22]

Ссылки [ править ]

  1. ^ Б с д е е г ч я J к л м п о С. Deering ; Р. Хинден (июль 2017 г.). Спецификация интернет-протокола версии 6 (IPv6) . Инженерная группа Интернета (IETF). DOI : 10,17487 / RFC8200 . RFC 8200 .Устраняет RFC 2460 .
  2. ^ К. Николс; С. Блейк; Ф. Бейкер ; Д. Блэк (декабрь 1998 г.). Определение поля дифференцированного обслуживания (поля DS) в заголовках IPv4 и IPv6 . DOI : 10,17487 / RFC2474 . RFC 2474 .
  3. Перейти ↑ D. Grossman (апрель 2002 г.). Новая терминология и пояснения к DiffServ . DOI : 10,17487 / RFC3260 . RFC 3260 .
  4. ^ a b c Б. Феннер (ноябрь 2006 г.). Экспериментальные значения в заголовках IPv4, IPv6, ICMPv4, ICMPv6, UDP и TCP . Сетевая рабочая группа. DOI : 10,17487 / RFC4727 . RFC 4727 .
  5. ^ К. Рамакришнан; С. Флойд; Д. Блэк (сентябрь 2001 г.). Добавление явного уведомления о перегрузке (ECN) в IP . DOI : 10,17487 / RFC3168 . RFC 3168 .
  6. ^ С. Аманте; Б. Карпентер; С. Цзян; Дж. Раджахалме (ноябрь 2011 г.). Спецификация метки потока IPv6 . DOI : 10,17487 / RFC6437 . RFC 6437 .
  7. ^ Использование метки потока IPv6 в качестве одноразового номера транспортного уровня для защиты от атак с использованием спуфинга вне маршрута
  8. ^ a b c Д. Борман; С. Диринг ; Р. Хинден (август 1999 г.). Джумбограммы IPv6 . DOI : 10,17487 / RFC2675 . RFC 2675 .
  9. ^ С. Куропатка; Ф. Кастенхольц (декабрь 1994 г.). Технические критерии выбора IP The Next Generation (IPng) . сек. 6.2. DOI : 10,17487 / RFC1726 . RFC 1726 .
  10. ^ T. Heer; П. Йокела; Т. Хендерсон (апрель 2015 г.). Р. Московиц (ред.). Протокол идентификации хоста версии 2 (HIPv2) . Инженерная группа Интернета (IETF). DOI : 10,17487 / RFC7401 . ISSN 2070-1721 . RFC 7401 . 
  11. ^ Э. Нордмарк; М. Багнуло (июнь 2009 г.). Shim6: Протокол совместимости с несколькими адресами уровня 3 для IPv6 . Сетевая рабочая группа. DOI : 10,17487 / RFC5533 . RFC 5533 .
  12. ^ а б в г Т. Нартен (январь 2004 г.). Присвоение экспериментальных и тестовых номеров считается полезным . Сетевая рабочая группа. DOI : 10,17487 / RFC3692 . RFC 3692 . BCP 82. Обновляет RFC 2434 .
  13. ^ «Параметры Интернет-протокола версии 6 (IPv6): типы маршрутизации» . IANA . Проверено 17 ноября 2017 .
  14. ^ Philippe Biondi, Arnoud Ebalard (апрель 2007). «Безопасность заголовков маршрутизации IPv6» (PDF) . EADS . Проверено 3 декабря 2010 года . Тип 0: злой механизм ...
  15. ^ Дж. Эбли; П. Савола; Г. Невилл-Нил (декабрь 2007 г.). Устарело использование заголовков маршрутизации типа 0 в IPv6 . DOI : 10,17487 / RFC5095 . RFC 5095 .
  16. ^ И. Кастинейра; Н. Чиаппа; М. Стинструп (август 1996 г.). Архитектура маршрутизации Nimrod . DOI : 10,17487 / RFC1992 . RFC 1992 .
  17. ^ Дж. Хуэй; JP. Вассер; Д. Каллер; В. Манрал (март 2012 г.). Заголовок маршрутизации IPv6 для исходных маршрутов с протоколом маршрутизации для сетей с низким энергопотреблением и с потерями (RPL) . Инженерная группа Интернета (IETF). DOI : 10,17487 / RFC6554 . RFC 6554 .
  18. ^ С. Кент (декабрь 2005 г.). Заголовок аутентификации IP . DOI : 10,17487 / RFC4302 . RFC 4302 .
  19. ^ С. Кент (декабрь 2005 г.). IP-инкапсуляция данных безопасности . DOI : 10,17487 / RFC4302 . RFC 4302 .
  20. ^ a b Ф. Гонт; В. Манраль; Р. Боника (январь 2014 г.). Последствия слишком больших цепочек заголовков IPv6 . DOI : 10,17487 / RFC7112 . RFC 7112 .
  21. ↑ F. Gont (февраль 2014 г.). Рекомендации по реализации для IPv6 Router Advertising Guard (RA-Guard) . DOI : 10,17487 / RFC7113 . RFC 7113 .
  22. ↑ F. Gont (август 2013). Последствия для безопасности фрагментации IPv6 с обнаружением соседей IPv6 . DOI : 10,17487 / RFC6980 . RFC 6980 .