IPv6-пакет
Пакет IPv6 — это наименьший объект сообщения, передаваемый с использованием Интернет-протокола версии 6 (IPv6). Пакеты состоят из управляющей информации для адресации и маршрутизации, а также полезных данных пользовательских данных. Управляющая информация в пакетах IPv6 подразделяется на обязательный фиксированный заголовок и дополнительные заголовки расширения. Полезная нагрузка пакета IPv6 обычно представляет собой дейтаграмму или сегмент протокола транспортного уровня более высокого уровня , но вместо этого может быть данными для интернет-уровня (например, ICMPv6 ) или канального уровня (например, OSPF ).
Пакеты IPv6 обычно передаются по канальному уровню (т. е. через Ethernet или Wi-Fi ), который инкапсулирует каждый пакет в кадр . Пакеты также могут передаваться по протоколу туннелирования более высокого уровня , например IPv4, при использовании технологий перехода 6to4 или Teredo .
В отличие от IPv4, маршрутизаторы не фрагментируют пакеты IPv6 размером больше, чем максимальная единица передачи (MTU), за это несет исключительную ответственность исходный узел. Минимальный MTU в 1280 октетов обязателен для IPv6, но хостам «настоятельно рекомендуется» использовать Path MTU Discovery, чтобы воспользоваться преимуществами MTU, превышающими минимальный. [1]
С июля 2017 года Управление по присвоению номеров в Интернете (IANA) отвечает за регистрацию всех параметров IPv6, которые используются в заголовках пакетов IPv6. [1]
Фиксированный заголовок
[ редактировать ]Фиксированный заголовок запускает пакет IPv6 и имеет размер 40 октетов (320 бит ). [1] Байты многобайтовых полей располагаются в сетевом порядке байтов .
Исправлен формат заголовка Смещения Октет 0 1 2 3 Октет Кусочек 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Версия Класс трафика Метка потока 4 32 Длина полезной нагрузки Следующий заголовок Предел прыжков 8 64 Исходный адрес 12 96 16 128 20 160 24 192 Адрес назначения 28 224 32 256 36 288
- Версия (4 бита)
- Константа 6 (битовая последовательность 0110 ).
- Класс трафика (6+2 бита)
- Биты этого поля содержат два значения. Шесть старших битов содержат поле дифференцированных услуг (поле DS), которое используется для классификации пакетов. [2] [3] В настоящее время все стандартные поля DS заканчиваются битом «0». Любое поле DS, оканчивающееся двумя битами «1», предназначено для локального или экспериментального использования. [4]
- Остальные два бита используются для явного уведомления о перегрузке (ECN); [5] Значения приоритета подразделяются на диапазоны: трафик, в котором источник обеспечивает контроль перегрузки, и трафик без контроля перегрузки.
- Метка потока (20 бит)
- Высокоэнтропийный идентификатор потока пакетов между источником и пунктом назначения. Поток — это группа пакетов, например сеанс TCP или медиапоток. Специальная метка потока 0 означает, что пакет не принадлежит ни одному потоку (при использовании этой схемы). Более старая схема идентифицирует поток по адресу и порту источника, адресу и порту назначения, протоколу (значение последнего поля следующего заголовка ). [6] Кроме того, было предложено использовать метку потока для обнаружения поддельных пакетов. [7]
- Длина полезной нагрузки (16 бит)
- Размер полезных данных в октетах, включая любые заголовки расширений. Длина устанавливается равной нулю, когда заголовок расширения Hop-by-Hop содержит опцию Jumbo Payload . [8]
- Следующий заголовок (8 бит)
- Указывает тип следующего заголовка. В этом поле обычно указывается протокол транспортного уровня , используемый полезной нагрузкой пакета. Если в пакете присутствуют заголовки расширения, это поле указывает, какой заголовок расширения следует за ним. Значения совпадают со значениями, используемыми для поля протокола IPv4, поскольку оба поля имеют одну и ту же функцию (см. Список номеров протоколов IP ).
- Предел прыжков (8 бит)
- Заменяет поле времени жизни в IPv4. Это значение уменьшается на единицу на каждом узле пересылки, и пакет отбрасывается, если оно становится равным 0. Однако узел назначения должен нормально обрабатывать пакет, даже если он получен с пределом переходов, равным 0.
- Адрес источника (128 бит)
- Одноадресный IPv6-адрес отправляющего узла.
- Адрес назначения (128 бит)
- Одноадресный или многоадресный адрес IPv6 узла(ов) назначения.
В целях повышения производительности, а также поскольку предполагается, что современные технологии канального уровня и протоколы транспортного уровня обеспечивают достаточное обнаружение ошибок, [9] заголовок не имеет контрольной суммы для его защиты. [1]
Заголовки расширений
[ редактировать ]Заголовки расширений содержат дополнительную информацию интернет-уровня и размещаются между фиксированным заголовком и заголовком протокола верхнего уровня. [1] Заголовки расширений образуют цепочку, используя поля «Следующий заголовок» . Поле «Следующий заголовок» в фиксированном заголовке указывает тип первого заголовка расширения; Поле «Следующий заголовок» последнего заголовка расширения указывает тип заголовка протокола верхнего уровня в полезной нагрузке пакета. Все заголовки расширений имеют размер, кратный 8 октетам; некоторые заголовки расширений требуют внутреннего заполнения для удовлетворения этого требования.
Определено несколько заголовков расширений, и в будущем могут быть определены новые заголовки расширений. Большинство заголовков расширений проверяются и обрабатываются в пункте назначения пакета. Пошаговые параметры могут обрабатываться и модифицироваться промежуточными узлами и, если они присутствуют, должны быть первым расширением. Все заголовки расширений являются необязательными и должны появляться не более одного раза, за исключением расширения заголовка «Параметры места назначения» , которое может появляться дважды. [1]
Если узел не распознает конкретный заголовок расширения, он должен отбросить пакет и отправить сообщение о проблеме с параметром ( ICMPv6 тип 4, код 1). [1]
Определенные заголовки расширений ниже перечислены в предпочтительном порядке для случая, когда за фиксированным заголовком следует более одного заголовка расширения.
Заголовок расширения Значение поля следующего заголовка Описание Пошаговые параметры 0 Параметры, которые необходимо просмотреть всем устройствам на пути Маршрутизация 43 Методы указания маршрута дейтаграммы (используются с Mobile IPv6 ) Фрагмент 44 Содержит параметры для фрагментации датаграмм. Заголовок аутентификации (AH) 51 Содержит информацию, используемую для проверки подлинности большинства частей пакета. Инкапсуляция полезных данных безопасности (ESP) 50 Переносит зашифрованные данные для безопасной связи. Параметры назначения (перед заголовком верхнего уровня) 60 Опции, которые необходимо проверять только по месту назначения пакета Мобильность (в настоящее время без заголовка верхнего уровня) 135 Параметры, используемые с мобильным IPv6 Протокол идентификации хоста 139 Используется для протокола идентификации хоста версии 2 (HIPv2). [10] Протокол Шим6 140 Используется для Shim6 [11] Сдержанный 253 Используется для экспериментов и испытаний. [12] [4] Сдержанный 254 Используется для экспериментов и испытаний. [12] [4]
Значение 59 (Нет следующего заголовка) в поле «Следующий заголовок» указывает на то, что после этого заголовка нет никакого следующего заголовка , даже заголовка протокола верхнего уровня. Это означает, что с точки зрения заголовка пакет IPv6 заканчивается сразу после него: полезная нагрузка должна быть пустой. Однако в полезных данных все равно могут содержаться данные, если длина полезных данных в первом заголовке пакета больше, чем длина всех расширенных заголовков в пакете. Эти данные должны игнорироваться хостами, но передаваться маршрутизаторам без изменений. [1] : 4.7
Пошаговые параметры и параметры назначения
[ редактировать ]Заголовок расширения Hop-by-Hop Options может проверяться и изменяться всеми узлами на пути пакета, включая отправляющие и принимающие узлы. (Для аутентификации значения параметров, которые могут меняться по пути, игнорируются.) Заголовок расширения Destination Options должен проверяться только узлом(ами) назначения. Оба заголовка расширения имеют размер не менее 8 октетов; если присутствует больше опций, чем поместится в этом пространстве, блоки по 8 октетов, содержащие опции и дополнения, добавляются в заголовок повторно, пока не будут представлены все опции.
«Пошаговые параметры» и «Параметры назначения» Формат заголовка расширения Смещения Октет 0 1 2 3 Октет Кусочек 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Следующий заголовок Длина расширения заголовка Параметры и дополнение 4 32 Параметры и дополнение 8 64 Необязательно: дополнительные параметры и отступы. 12 96
- Следующий заголовок (8 бит)
- Указывает тип следующего заголовка.
- Длина расширения заголовка (8 бит)
- Длина этого заголовка в блоках по 8 октетов, не включая первые 8 октетов.
- Параметры и отступы (переменные)
- Содержит один или несколько параметров и дополнительные поля заполнения для выравнивания параметров и увеличения общей длины заголовка, кратной 8 октетам. Опции имеют TLV -код.
Маршрутизация
[ редактировать ]Заголовок расширения маршрутизации используется для направления пакета к одному или нескольким промежуточным узлам перед отправкой в пункт назначения. Размер заголовка составляет не менее 8 октетов; если требуется больше данных, специфичных для типа , чем умещается в 4 октета, блоки по 8 октетов добавляются к заголовку повторно, пока все данные, специфичные для типа, не будут помещены. [1]
маршрутизации Формат заголовка расширения Смещения Октет 0 1 2 3 Октет Кусочек 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Следующий заголовок Длина расширения заголовка Тип маршрутизации Осталось сегментов 4 32 Типовые данные 8 64 Опционально: дополнительные данные по типу ... 12 96
- Следующий заголовок (8 бит)
- Указывает тип следующего заголовка.
- Длина расширения заголовка (8 бит)
- Длина этого заголовка кратна 8 октетам, не считая первых 8 октетов.
- Тип маршрутизации (8 бит)
- Значение от 0 до 255, присвоенное IANA . [13]
Тип Статус Комментарий 0 Устарело В связи с тем, что с заголовком маршрутизации типа 0 простая, но эффективная атака типа «отказ в обслуживании» , может быть запущена [14] этот заголовок устарел в 2007 году, и хосты и маршрутизаторы обязаны игнорировать эти заголовки. [15] 1 Устарело Используется для проекта Нимрод. [16] финансируется DARPA . Он был устарел в 2009 году. 2 Допустимый Ограниченная версия типа 0 используется для мобильного IPv6 , где может содержать домашний адрес мобильного узла. 3 Допустимый Заголовок исходного маршрута RPL [17] для сетей с низким энергопотреблением и потерями. 4 Допустимый Заголовок маршрутизации сегмента (SRH). [18] 253 Частное использование Может использоваться для тестирования, а не для реальных реализаций. Эксперимент 1 в стиле RFC3692 . [12] 254 Частное использование Может использоваться для тестирования, а не для реальных реализаций. Эксперимент 2 в стиле RFC3692 . [12]
- Сегменты слева (8 бит)
- Количество узлов, которые этот пакет еще должен посетить, прежде чем достигнет конечного пункта назначения.
- Типовые данные (переменная)
- Данные, принадлежащие этому типу заголовка маршрутизации.
Фрагмент
[ редактировать ]Чтобы отправить пакет, размер которого превышает MTU пути , отправляющий узел разбивает пакет на фрагменты. Заголовок расширения Fragment содержит информацию, необходимую для повторной сборки исходного (нефрагментированного) пакета. [1]
фрагмента Формат заголовка расширения Смещения Октет 0 1 2 3 Октет Кусочек 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 0 0 Следующий заголовок Сдержанный Смещение фрагмента Рез М 4 32 Идентификация
- Следующий заголовок (8 бит)
- Определяет тип следующего заголовка.
- Зарезервировано (8 бит)
- Инициализируется всеми нулями.
- Смещение фрагмента (13 бит)
- Смещение в 8-байтовых единицах относительно начала фрагментируемой части исходного пакета.
- Разрешение (2 бита)
- Сдержанный; инициализируется нулями.
- М-флаг (1 бит)
- 1 означает, что следуют дополнительные фрагменты; 0 означает последний фрагмент.
- Идентификация (32 бита)
- Идентификационное значение пакета, сгенерированное исходным узлом. Нужен для сборки оригинального пакета.
Заголовок аутентификации (AH) и инкапсуляция полезных данных безопасности (ESP)
[ редактировать ]Заголовок аутентификации и инкапсулирующая полезная нагрузка безопасности являются частью IPsec и используются одинаково в IPv6 и IPv4. [19] [20]
Полезная нагрузка
[ редактировать ]За фиксированными и дополнительными заголовками IPv6 следует полезная нагрузка верхнего уровня — данные, предоставляемые транспортным уровнем, например сегмент TCP или дейтаграмма UDP . Поле Next Header последнего заголовка IPv6 указывает, какой тип полезной нагрузки содержится в этом пакете.
Стандартная длина полезной нагрузки
[ редактировать ]Поле длины полезной нагрузки IPv6 (и IPv4 ) имеет размер 16 бит, что позволяет указать максимальную длину в 65 535 полезной нагрузки октетов. На практике хосты определяют максимальную полезную длину полезной нагрузки, используя Path MTU Discovery (определяя минимальный MTU на пути от отправителя к получателю), чтобы избежать необходимости фрагментировать пакеты. Большинство протоколов канального уровня имеют MTU значительно меньше 65 535 октетов.
Джамбограмма
[ редактировать ]Дополнительная функция IPv6, опция большой полезной нагрузки в заголовке расширения 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-by-Hop ). Лишь немногие протоколы канального уровня могут обрабатывать пакеты размером более 65 535 октетов. [ нужна ссылка ]
Фрагментация
[ редактировать ]В отличие от IPv4, маршрутизаторы IPv6 никогда не фрагментируют пакеты IPv6. Пакеты, превышающие размер максимальной единицы передачи (MTU) канала назначения, отбрасываются, и об этом условии сигнализирует Пакет слишком большой» сообщение ICMPv6 « исходному узлу, аналогично методу IPv4, когда «Не фрагментировать» . бит установлен [1] Ожидается, что конечные узлы в IPv6 будут выполнять обнаружение Path MTU , чтобы определить максимальный размер отправляемых пакетов, а протокол верхнего уровня, как ожидается, будет ограничивать размер полезной нагрузки. Если протокол верхнего уровня не может этого сделать, хост-отправитель может вместо этого использовать фрагмента заголовок расширения .
Любой уровень канала передачи данных, передающий данные IPv6, должен быть способен передавать IP-пакет, содержащий до 1280 байтов, таким образом, отправляющая конечная точка может ограничить свои пакеты до 1280 байтов и избежать необходимости фрагментации или обнаружения Path MTU.
Фрагментация
[ редактировать ]Пакет, содержащий первый фрагмент исходного (большого) пакета, состоит из пяти частей: заголовков для каждого фрагмента (важнейшие исходные заголовки, которые неоднократно используются в каждом фрагменте), за которыми следует заголовок расширения фрагмента, содержащий нулевое смещение, а затем все оставшиеся исходные заголовки расширения, затем исходный заголовок верхнего уровня (альтернативно заголовок ESP) и часть исходной полезной нагрузки. [1] Каждый последующий пакет состоит из трех частей: заголовков для каждого фрагмента, за которыми следует заголовок расширения фрагмента и часть исходной полезной нагрузки, определяемая смещением фрагмента.
Заголовки для каждого фрагмента определяются на основе того, содержит ли оригинал заголовок расширения маршрутизации или шаг-за-шагом . Если ни один из них не существует, фрагментная часть представляет собой просто фиксированный заголовок. Если заголовок расширения маршрутизации существует, заголовки для каждого фрагмента включают фиксированный заголовок и все заголовки расширения, включая заголовок маршрутизации . Если заголовок расширения Hop-by-Hop существует, заголовки каждого фрагмента состоят только из фиксированного заголовка и заголовка расширения Hop-by-Hop .
В любом случае для последнего заголовка фрагментной части значение Next Header установлено на 44, чтобы указать, что за ним следует заголовок расширения фрагмента . Каждый фрагмента заголовок расширения имеет флаг M, установленный в значение 1 (что указывает на то, что следуют дополнительные фрагменты), кроме последнего, флаг которого установлен на 0 . Длина каждого фрагмента кратна 8 октетам, за исключением, возможно, последнего фрагмента.
Заголовки для каждого фрагмента исторически назывались «нефрагментируемой частью», имея в виду возможность фрагментации остальной части заголовка до 2014 года. Теперь никакие заголовки на самом деле не являются фрагментируемыми. [21]
Сборка
[ редактировать ]Исходный пакет повторно собирается принимающим узлом путем сбора всех фрагментов и размещения каждого фрагмента по указанному смещению и отбрасывания заголовков расширения фрагмента пакетов, которые их перенесли. Пакеты, содержащие фрагменты, не обязательно должны прибывать последовательно; они будут переставлены принимающим узлом.
Если не все фрагменты получены в течение 60 секунд после получения первого пакета с фрагментом, повторная сборка исходного пакета прекращается и все фрагменты отбрасываются. Если был получен первый фрагмент (который содержит фиксированный заголовок) и один или несколько других отсутствуют, сообщение о превышении времени ( ICMPv6 тип 3, код 1) возвращается узлу, отправителю фрагментированного пакета.
Когда узел повторной сборки обнаруживает фрагмент, который перекрывается с другим фрагментом, повторная сборка исходного пакета прерывается и все фрагменты отбрасываются. Узел может опционально игнорировать точные дубликаты фрагмента вместо того, чтобы рассматривать точные дубликаты как перекрывающиеся друг друга. [1]
Хосты-получатели должны приложить все усилия для повторной сборки фрагментированных IP-датаграмм, которые после повторной сборки содержат до 1500 байт. Хостам разрешено предпринимать попытки собрать фрагментированные дейтаграммы размером более 1500 байт, но им также разрешено молча отбрасывать любую дейтаграмму после того, как становится очевидно, что повторно собранный пакет будет иметь размер более 1500 байт. Поэтому отправителям следует избегать отправки фрагментированных IP-дейтаграмм с общим повторно собранным размером более 1500 байт, если только они не знают, что получатель способен повторно собрать такие большие датаграммы.
Безопасность
[ редактировать ]Исследования показали, что использование фрагментации можно использовать для обхода контроля сетевой безопасности. В результате в 2014 году прежнее разрешение на переполнение цепочки заголовков IPv6 за пределами первого фрагмента было запрещено, чтобы избежать некоторых очень патологических случаев фрагментации. [21] Кроме того, в результате исследования обхода Router Advertisement Guard, [22] использование фрагментации с помощью Neighbor Discovery не рекомендуется, а использование фрагментации с Secure Neighbor Discovery (SEND) не рекомендуется. [23]
Ссылки
[ редактировать ]- ^ Перейти обратно: а б с д и ж г час я дж к л м С. Диринг ; Р. Хинден (июль 2017 г.). Спецификация интернет-протокола версии 6 (IPv6) . IETF . дои : 10.17487/RFC8200 . СТД 86. RFC 8200 . Интернет-стандарт 86. Устарел . РФК 2460 .
- ^ К. Николс; С. Блейк; Ф. Бейкер ; Д. Блэк (декабрь 1998 г.). Определение поля дифференцированных услуг (поля DS) в заголовках IPv4 и IPv6 . Сетевая рабочая группа. дои : 10.17487/RFC2474 . РФК 2474 . Предлагаемый стандарт. Устаревшие RFC 1455 and 1349. Updated by RFC 3168 , 3260 и 8436 .
- ^ Д. Гроссман (апрель 2002 г.). Новая терминология и разъяснения для DiffServ . дои : 10.17487/RFC3260 . РФК 3260 . Информационный. Обновления RFC 2474 , 2475 и 2597 .
- ^ Перейти обратно: а б с Б. Феннер (ноябрь 2006 г.). Экспериментальные значения в заголовках IPv4, IPv6, ICMPv4, ICMPv6, UDP и TCP . Сетевая рабочая группа. дои : 10.17487/RFC4727 . РФК 4727 . Предлагаемый стандарт.
- ^ К. Рамакришнан; С. Флойд; Д. Блэк (сентябрь 2001 г.). Добавление явного уведомления о перегрузке (ECN) в IP . Сетевая рабочая группа. дои : 10.17487/RFC3168 . РФК 3168 . Предлагаемый стандарт. Устаревшие RFC 2481. Updates RFC 2474, 2401 and 793. Updated by RFC 4301 , 6040 и 8311 .
- ^ С. Аманте; Б. Карпентер ; С. Цзян; Дж. Раджахалме (ноябрь 2011 г.). Спецификация метки потока IPv6 . IETF . дои : 10.17487/RFC6437 . ISSN 2070-1721 . RFC 6437 . Предлагаемый стандарт. Устаревшие RFC 3697. Updates RFC 2205 и 2460 .
- ^ Использование метки потока IPv6 в качестве Nonce транспортного уровня для защиты от атак спуфинга вне пути
- ^ Перейти обратно: а б с Д. Борман; С. Диринг ; Р. Хинден (август 1999 г.). Джамбограммы IPv6 . Сетевая рабочая группа. дои : 10.17487/RFC2675 . РФК 2675 . Предлагаемый стандарт. Устаревшие РФК 2147 .
- ^ К. Партридж; Ф. Кастенхольц (декабрь 1994 г.). Технические критерии выбора IP следующего поколения (IPng) . Сетевая рабочая группа. дои : 10.17487/RFC1726 . РФК 1726 . Информационный. сек. 2.6.
- ^ Т. Хир; П. Йокела; Т. Хендерсон (апрель 2015 г.). Р. Московиц (ред.). Протокол идентификации хоста версии 2 (HIPv2) . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7401 . ISSN 2070-1721 . РФК 7401 . Предлагаемый стандарт. Устаревшие RFC 5201. Updated by RFC 8002 и 9374 .
- ^ Э. Нордмарк; М. Багнуло (июнь 2009 г.). Shim6: протокол Multihoming Shim уровня 3 для IPv6 . Сетевая рабочая группа. дои : 10.17487/RFC5533 . RFC 5533 . Предлагаемый стандарт.
- ^ Перейти обратно: а б с д Т. Нартен (январь 2004 г.). Присвоение экспериментальных и тестовых номеров, которые считаются полезными . Сетевая рабочая группа. дои : 10.17487/RFC3692 . BCP 82. RFC 3692 . Лучшая общая практика. Обновления РФК 2434 .
- ^ «Параметры протокола Интернета версии 6 (IPv6): типы маршрутизации» . ИАНА . Проверено 15 октября 2021 г.
- ^ Филипп Бьонди, Арну Эбалар (апрель 2007 г.). «Безопасность заголовка маршрутизации IPv6» (PDF) . ЕАДС . Проверено 3 декабря 2010 г.
Тип 0: злой механизм...
- ^ Дж. Эбли; П. Савола; Дж. Невилл-Нил (декабрь 2007 г.). Устаревшие заголовки маршрутизации типа 0 в IPv6 . дои : 10.17487/RFC5095 . РФК 5095 . Проект стандарта. Обновления RFC 2460 и 4294 .
- ^ И. Кастинейра; Н. Чьяппа; М. Стенструп (август 1996 г.). Архитектура маршрутизации Nimrod . дои : 10.17487/RFC1992 . РФК 1992 . Информационный.
- ^ Дж. Хуэй; ДжП. Вассер; Д. Каллер; В. Манрал (март 2012 г.). Заголовок маршрутизации IPv6 для исходных маршрутов с протоколом маршрутизации для сетей с низким энергопотреблением и потерями (RPL) . Рабочая группа по интернет-инжинирингу . дои : 10.17487/RFC6554 . RFC 6554 . Предлагаемый стандарт.
- ^ С. Превиди; Дж. Ледди; С. Мацусима; Д. Войер (март 2020 г.). С. Филсфилс; Д. Дьюкс (ред.). Заголовок маршрутизации сегмента IPv6 (SRH) . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC8754 . ISSN 2070-1721 . RFC 8754 . Предлагаемый стандарт.
- ^ С. Кент (декабрь 2005 г.). Заголовок аутентификации IP . Сетевая рабочая группа. дои : 10.17487/RFC4302 . РФК 4302 . Предлагаемый стандарт. Устаревшие РФК 2402 .
- ^ С. Кент (декабрь 2005 г.). IP-инкапсуляция полезных данных безопасности . Сетевая рабочая группа. дои : 10.17487/RFC4303 . RFC 4303 . Предлагаемый стандарт. Устаревшие РФК 2406 .
- ^ Перейти обратно: а б Ф. Гонт; В. Манрал; Р. Боника (январь 2014 г.). Последствия слишком больших цепочек заголовков IPv6 . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7112 . ISSN 2070-1721 . РФК 7112 . Предлагаемый стандарт. Обновления РФК 2460 .
- ^ Ф. Гонт (февраль 2014 г.). Рекомендации по внедрению защиты рекламы маршрутизатора IPv6 (RA-Guard) . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC7113 . ISSN 2070-1721 . РФК 7113 . Информационный. Обновления РФК 6105 .
- ^ Ф. Гонт (август 2013 г.). Влияние фрагментации IPv6 на безопасность при обнаружении соседей IPv6 . Целевая группа инженеров Интернета (IETF). дои : 10.17487/RFC6980 . ISSN 2070-1721 . РФК 6980 . Предлагаемый стандарт. Обновления RFC 3971 и 4861 .