RFC 8200 · июль 2017
Спецификация протокола Интернета версии 6 (IPv6)
Авторы: S. Deering и R. Hinden. STD 86. Июль 2017. Заменяет RFC 2460.
Аннотация
Этот документ определяет версию 6 протокола Интернета (IPv6) и заменяет RFC 2460.
Статус документа
Этот документ относится к стандартам Интернета.
Документ подготовлен Инженерной группой Интернета (IETF) и отражает консенсус её сообщества. Он прошёл публичное рассмотрение и одобрен к публикации Руководящей группой по инженерным вопросам Интернета (IESG). Дополнительные сведения о стандартах Интернета приведены в разделе 2 RFC 7841.
Сведения о текущем статусе документа, исправлениях и способах обратной связи можно получить по адресу http://www.rfc-editor.org/info/rfc8200.
Уведомление об авторских правах
Copyright (c) 2017 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
На документ распространяются BCP 78 и Правовые положения IETF Trust, относящиеся к документам IETF (http://trustee.ietf.org/license-info), действовавшие на дату публикации. Внимательно ознакомьтесь с ними: они описывают ваши права и ограничения. Компоненты программного кода, извлечённые из документа, должны включать текст упрощённой лицензии BSD, как указано в разделе 4.e Правовых положений IETF Trust, и предоставляются без гарантий согласно этой лицензии.
Документ может содержать материалы из документов или вкладов IETF, опубликованных или предоставленных в открытый доступ до 10 ноября 2008 года. Обладатели авторских прав на некоторые материалы могли не предоставить IETF Trust право разрешать их изменение вне процесса стандартизации IETF. Без соответствующей лицензии правообладателей документ нельзя изменять или создавать производные произведения вне этого процесса, кроме форматирования для публикации в качестве RFC или перевода на другие языки.
1. Введение
IP версии 6 (IPv6) — новая версия протокола Интернета (IP), разработанная как преемник IP версии 4 (IPv4) [RFC791]. Изменения при переходе от IPv4 к IPv6 относятся главным образом к следующим категориям.
• Расширенные возможности адресации. IPv6 увеличивает размер IP-адреса с 32 до 128 битов для поддержки большего числа уровней иерархии адресации, гораздо большего числа адресуемых узлов и более простой автоматической настройки адресов. Масштабируемость групповой маршрутизации улучшена за счёт добавления поля области действия в групповые адреса. Определён новый тип адреса — адрес произвольного получателя (anycast), используемый для отправки пакета любому одному узлу из группы.
• Упрощение формата заголовка. Некоторые поля заголовка IPv4 исключены или стали необязательными, чтобы снизить обычные затраты на обработку пакетов и ограничить расход пропускной способности на заголовок IPv6.
• Улучшенная поддержка расширений и параметров. Изменение способа кодирования параметров заголовка IP обеспечивает более эффективную пересылку, менее жёсткие ограничения длины параметров и большую гибкость при введении новых параметров в будущем.
• Возможность маркировки потоков. Добавлена возможность маркировать последовательности пакетов, которые отправитель просит обрабатывать в сети как единый поток.
• Возможности аутентификации и конфиденциальности. Для IPv6 определены расширения, поддерживающие аутентификацию, целостность данных и, необязательно, конфиденциальность данных.
Этот документ определяет базовый заголовок IPv6 и первоначально определённые заголовки расширений и параметры IPv6. Также рассматриваются вопросы размера пакетов, семантика меток потоков и классов трафика и влияние IPv6 на протоколы верхних уровней. Формат и семантика адресов IPv6 отдельно определены в [RFC4291]. Версия ICMP для IPv6, которую обязаны включать все реализации IPv6, определена в [RFC4443].
Порядок передачи данных IPv6 совпадает с IPv4, как определено в приложении B [RFC791].
Примечание. Поскольку этот документ заменяет [RFC2460], ссылки на RFC 2460 в любом документе, упомянутом здесь, следует понимать как ссылки на настоящий документ.
2. Терминология
Узел — устройство, реализующее IPv6.
Маршрутизатор — узел, пересылающий пакеты IPv6, явно адресованные не ему самому (см. примечание ниже).
Хост — любой узел, не являющийся маршрутизатором (см. примечание ниже).
Верхний уровень — уровень протокола непосредственно над IPv6. Примеры: транспортные протоколы TCP и UDP, управляющие протоколы ICMP, протоколы маршрутизации OSPF, а также протоколы межсетевого или нижнего уровня, туннелируемые через IPv6, то есть инкапсулированные в него, например IPX, AppleTalk или сам IPv6.
Канал — средство или среда связи, посредством которой узлы могут взаимодействовать на канальном уровне, то есть непосредственно ниже IPv6. Примеры: сети Ethernet, простые или объединённые мостами; каналы PPP; сети X.25, Frame Relay или ATM; а также туннели межсетевого или более высокого уровня, например через IPv4 или сам IPv6.
Соседи — узлы, подключённые к одному каналу.
Интерфейс — средство подключения узла к каналу.
Адрес — идентификатор интерфейса или набора интерфейсов на уровне IPv6.
Пакет — заголовок IPv6 вместе с полезной нагрузкой.
MTU канала — максимальная единица передачи, то есть максимальный размер пакета в октетах, который можно передать по каналу.
MTU пути — минимальное значение MTU всех каналов пути между узлом-источником и узлом назначения.
Примечание. Устройство с несколькими интерфейсами может быть настроено на пересылку пакетов, адресованных не ему, при поступлении через некоторые, но не все интерфейсы, и отбрасывание таких пакетов при поступлении через остальные. При получении пакетов и взаимодействии с соседями через первые интерфейсы, на которых выполняется пересылка, устройство должно соблюдать требования протокола к маршрутизаторам. При получении пакетов и взаимодействии с соседями через вторые интерфейсы, на которых пересылка не выполняется, оно должно соблюдать требования к хостам.
3. Формат заголовка IPv6
Заголовок IPv6 состоит из следующих полей в порядке передачи:
| Version: 4 бита | Traffic Class: 8 бит | Flow Label: 20 бит | | Payload Length: 16 бит | Next Header: 8 бит | Hop Limit: 8 бит | | Source Address: 128 бит | | Destination Address: 128 бит |
Version — четырёхбитный номер версии протокола Интернета, равный 6.
Traffic Class — восьмибитное поле класса трафика; см. раздел 7.
Flow Label — 20-битная метка потока; см. раздел 6.
Payload Length — 16-битное беззнаковое целое число. Длина полезной нагрузки IPv6, то есть оставшейся части пакета после заголовка IPv6, в октетах. Любые присутствующие заголовки расширений (раздел 4) считаются частью полезной нагрузки и включаются в эту длину.
Next Header — восьмибитный идентификатор, определяющий тип заголовка непосредственно после заголовка IPv6. Используются те же значения, что и для поля Protocol в IPv4 [IANA-PN].
Hop Limit — восьмибитное беззнаковое целое число, уменьшаемое на единицу каждым узлом, пересылающим пакет. При пересылке пакет отбрасывается, если Hop Limit был равен нулю при получении или уменьшен до нуля. Узлу назначения не следует отбрасывать пакет с Hop Limit, равным нулю; ему следует обработать пакет обычным образом.
Source Address — 128-битный адрес источника пакета; см. [RFC4291].
Destination Address — 128-битный адрес предполагаемого получателя пакета, который при наличии заголовка маршрутизации может не быть конечным получателем; см. [RFC4291] и раздел 4.4.
4. Заголовки расширений IPv6
В IPv6 необязательная информация межсетевого уровня кодируется в отдельных заголовках, которые могут располагаться в пакете между заголовком IPv6 и заголовком верхнего уровня. Таких заголовков расширений немного; каждый обозначается отдельным значением Next Header.
Заголовкам расширений назначаются номера из реестра номеров протоколов IP IANA [IANA-PN], общего для IPv4 и IPv6. При обработке последовательности значений Next Header первое значение, не обозначающее заголовок расширения [IANA-EH], указывает, что следующий элемент пакета — соответствующий заголовок верхнего уровня. Если заголовка верхнего уровня нет, используется специальное значение No Next Header.
Как показано в примерах, пакет IPv6 может содержать ноль, один или несколько заголовков расширений, каждый из которых обозначается полем Next Header предшествующего заголовка:
IPv6 (Next Header = TCP) → заголовок TCP и данные IPv6 (Next Header = Routing) → Routing (Next Header = TCP) → заголовок TCP и данные IPv6 (Next Header = Routing) → Routing (Next Header = Fragment) → Fragment (Next Header = TCP) → фрагмент заголовка TCP и данных
Заголовки расширений, за исключением Hop-by-Hop Options, не обрабатываются, не вставляются и не удаляются узлами на пути доставки, пока пакет не достигнет узла, указанного в поле Destination Address заголовка IPv6, или каждого узла из указанного набора при групповой адресации.
Заголовок Hop-by-Hop Options не вставляется и не удаляется, но может проверяться или обрабатываться любым узлом на пути доставки до достижения указанного в Destination Address узла или каждого узла набора при групповой адресации. При наличии он должен располагаться непосредственно после заголовка IPv6. Его наличие обозначается значением ноль в поле Next Header заголовка IPv6.
ПРИМЕЧАНИЕ. Хотя [RFC2460] требовал проверки и обработки Hop-by-Hop Options всеми узлами, теперь ожидается, что узлы на пути пакета проверяют и обрабатывают этот заголовок только при явной настройке на это.
На узле назначения обычная демультиплексная обработка поля Next Header заголовка IPv6 вызывает модуль обработки первого заголовка расширения или заголовка верхнего уровня, если расширений нет. Содержимое и семантика каждого заголовка расширения определяют, следует ли переходить к следующему. Поэтому заголовки расширений должны обрабатываться строго в порядке их появления в пакете; например, получатель не должен искать в пакете определённый тип заголовка расширения и обрабатывать его до всех предшествующих.
Если после обработки заголовка узел назначения должен перейти к следующему, но не распознаёт значение Next Header текущего заголовка, ему следует отбросить пакет и отправить источнику сообщение ICMP Parameter Problem с кодом ICMP 1 («обнаружен нераспознанный тип Next Header») и смещением нераспознанного значения в исходном пакете в поле ICMP Pointer. Те же действия следует выполнить, если узел встретил значение Next Header, равное нулю, в любом заголовке, кроме IPv6.
Длина каждого заголовка расширения кратна восьми октетам, чтобы сохранять восьмиоктетное выравнивание последующих заголовков. Многооктетные поля внутри каждого заголовка расширения выровнены по естественным границам: поле длиной n октетов находится на смещении от начала заголовка, кратном n, для n = 1, 2, 4 или 8.
Полная реализация IPv6 включает следующие заголовки расширений: Hop-by-Hop Options, Fragment, Destination Options, Routing, Authentication и Encapsulating Security Payload. Первые четыре определены в этом документе, последние два — соответственно в [RFC4302] и [RFC4303]. Актуальный перечень заголовков расширений IPv6 приведён в [IANA-EH].
4.1. Порядок заголовков расширений
Если один пакет содержит несколько заголовков расширений, рекомендуется следующий порядок:
Заголовок IPv6 Заголовок Hop-by-Hop Options Заголовок Destination Options (примечание 1) Заголовок Routing Заголовок Fragment Заголовок Authentication (примечание 2) Заголовок Encapsulating Security Payload (примечание 2) Заголовок Destination Options (примечание 3) Заголовок верхнего уровня
Примечание 1. Для параметров, обрабатываемых первым узлом назначения из поля Destination Address заголовка IPv6 и последующими узлами назначения, перечисленными в заголовке Routing.
Примечание 2. Дополнительные рекомендации по взаимному порядку заголовков Authentication и Encapsulating Security Payload приведены в [RFC4303].
Примечание 3. Для параметров, обрабатываемых только конечным узлом назначения пакета.
Каждый заголовок расширения следует включать не более одного раза, кроме Destination Options, который следует включать не более двух раз: один перед Routing и один перед заголовком верхнего уровня.
Если заголовок верхнего уровня сам является заголовком IPv6, то есть IPv6 туннелируется через IPv6 или инкапсулирован в него, за ним могут следовать собственные заголовки расширений, к которым отдельно применяются те же рекомендации о порядке.
При определении других заголовков расширений должны указываться ограничения на их порядок относительно перечисленных выше.
Узлы IPv6 должны принимать заголовки расширений в любом порядке и любом количестве в одном пакете и пытаться их обрабатывать, кроме Hop-by-Hop Options, который разрешён только непосредственно после заголовка IPv6. Тем не менее источникам пакетов IPv6 настоятельно рекомендуется соблюдать указанный порядок, пока последующие спецификации не пересмотрят эту рекомендацию.
4.2. Параметры
Два определённых в этом документе заголовка расширений — Hop-by-Hop Options и Destination Options — содержат переменное число параметров, закодированных по схеме тип–длина–значение (TLV):
| Option Type: 8 бит | Opt Data Len: 8 бит | Option Data: переменная длина |
Option Type — восьмибитный идентификатор типа параметра.
Opt Data Len — восьмибитное беззнаковое целое число, длина поля Option Data данного параметра в октетах.
Option Data — поле переменной длины с данными, зависящими от типа параметра.
Последовательность параметров заголовка должна обрабатываться строго в порядке их появления. Например, получатель не должен искать параметр определённого типа и обрабатывать его до всех предшествующих.
Идентификаторы Option Type кодируются так, что два старших бита задают действие, которое должен выполнить обрабатывающий узел IPv6, если тип параметра ему неизвестен:
00 — пропустить параметр и продолжить обработку заголовка. 01 — отбросить пакет. 10 — отбросить пакет и независимо от того, является ли Destination Address групповым адресом, отправить по Source Address сообщение ICMP Parameter Problem с кодом 2, указывающее на нераспознанный Option Type. 11 — отбросить пакет и, только если Destination Address не является групповым адресом, отправить по Source Address сообщение ICMP Parameter Problem с кодом 2, указывающее на нераспознанный Option Type.
Третий по старшинству бит Option Type указывает, могут ли данные Option Data изменяться на пути к конечному получателю. Если пакет содержит заголовок Authentication, при вычислении или проверке значения аутентификации пакета всё поле Option Data параметра, данные которого могут меняться в пути, должно рассматриваться как состоящее из нулевых октетов.
0 — Option Data не изменяется в пути. 1 — Option Data может изменяться в пути.
Три описанных старших бита считаются частью Option Type, а не независимыми от него. Следовательно, конкретный параметр обозначается полным восьмибитным Option Type, а не только пятью младшими битами.
Для Hop-by-Hop Options и Destination Options используется общее пространство номеров Option Type. Однако спецификация конкретного параметра может ограничить его применение только одним из этих двух заголовков.
Для отдельных параметров могут действовать требования к выравниванию, обеспечивающие расположение многооктетных значений Option Data на естественных границах. Требование записывается как xn+y: Option Type должен находиться на смещении от начала заголовка, кратном x октетам, плюс y октетов. Например, 2n означает любое смещение, кратное двум октетам; 8n+2 — любое смещение, кратное восьми октетам, плюс два октета.
При необходимости используются два параметра заполнения, выравнивающие последующие параметры и дополняющие содержащий их заголовок до длины, кратной восьми октетам. Их должны распознавать все реализации IPv6.
Параметр Pad1, без требований к выравниванию: один октет со значением 0. ВНИМАНИЕ: Pad1 — особый случай; полей длины и значения у него нет. Он вставляет один октет заполнения в область параметров заголовка. Если требуется более одного октета, следует использовать описанный далее PadN, а не несколько Pad1.
Параметр PadN, без требований к выравниванию: Option Type = 1, затем Opt Data Len и Option Data. Он вставляет в область параметров два или более октетов заполнения. Для N октетов заполнения Opt Data Len содержит N−2, а Option Data состоит из N−2 нулевых октетов.
Рекомендации по форматированию новых параметров приведены в приложении A.
4.3. Заголовок Hop-by-Hop Options
Заголовок Hop-by-Hop Options переносит необязательные сведения, которые могут проверяться и обрабатываться каждым узлом на пути доставки пакета. Он обозначается значением Next Header = 0 в заголовке IPv6 и имеет следующий формат:
| Next Header: 8 бит | Hdr Ext Len: 8 бит | Options: переменная длина |
Next Header — восьмибитный идентификатор типа заголовка непосредственно после Hop-by-Hop Options. Используются значения поля Protocol IPv4 [IANA-PN].
Hdr Ext Len — восьмибитное беззнаковое целое число: длина заголовка Hop-by-Hop Options в единицах по восемь октетов без учёта первых восьми октетов.
Options — поле переменной длины, подобранной так, чтобы длина всего заголовка Hop-by-Hop Options была кратна восьми октетам. Оно содержит один или несколько параметров в кодировке TLV, как описано в разделе 4.2.
Единственные параметры Hop-by-Hop, определённые этим документом, — Pad1 и PadN из раздела 4.2.
4.4. Заголовок Routing
Источник IPv6 использует заголовок Routing для перечисления одного или нескольких промежуточных узлов, через которые пакет должен пройти по пути к месту назначения. Эта функция очень похожа на параметр IPv4 Loose Source and Record Route. Заголовок Routing обозначается значением Next Header = 43 в непосредственно предшествующем заголовке и имеет формат:
| Next Header: 8 бит | Hdr Ext Len: 8 бит | Routing Type: 8 бит | Segments Left: 8 бит | | данные, зависящие от типа: переменная длина |
Next Header — восьмибитный идентификатор типа заголовка непосредственно после Routing; используются значения поля Protocol IPv4 [IANA-PN].
Hdr Ext Len — восьмибитное беззнаковое целое число: длина заголовка Routing в единицах по восемь октетов без учёта первых восьми октетов.
Routing Type — восьмибитный идентификатор конкретной разновидности заголовка Routing.
Segments Left — восьмибитное беззнаковое целое число: число оставшихся сегментов маршрута, то есть явно перечисленных промежуточных узлов, через которые ещё предстоит пройти до конечного пункта назначения.
Данные, зависящие от типа, — поле переменной длины; его формат определяется Routing Type, а длина такова, чтобы весь заголовок Routing был кратен восьми октетам.
Если при обработке полученного пакета узел встречает заголовок Routing с неизвестным значением Routing Type, требуемое поведение зависит от Segments Left:
• Если Segments Left равно нулю, узел должен проигнорировать заголовок Routing и перейти к следующему заголовку пакета, тип которого указан в поле Next Header заголовка Routing. • Если Segments Left не равно нулю, узел должен отбросить пакет и отправить по Source Address сообщение ICMP Parameter Problem с кодом 0, указывающее на неизвестный Routing Type.
Если после обработки заголовка Routing промежуточный узел определяет, что пакет нужно переслать на канал с MTU меньше размера пакета, он должен отбросить пакет и отправить по Source Address сообщение ICMP Packet Too Big.
Текущий перечень заголовков Routing IPv6 и их статус приведены в [IANA-RH]. Рекомендации по их назначению содержатся в [RFC5871].
4.5. Заголовок Fragment
Источник IPv6 использует заголовок Fragment для отправки пакета, который больше MTU пути к месту назначения. В отличие от IPv4, фрагментация в IPv6 выполняется только узлами-источниками, а не маршрутизаторами на пути доставки; см. раздел 5. Заголовок Fragment обозначается значением Next Header = 44 в непосредственно предшествующем заголовке и имеет формат:
| Next Header: 8 бит | Reserved: 8 бит | Fragment Offset: 13 бит | Res: 2 бита | M: 1 бит | | Identification: 32 бита |
Next Header — восьмибитный идентификатор типа первого заголовка фрагментируемой части исходного пакета, определённой ниже; используются значения поля Protocol IPv4 [IANA-PN].
Reserved — зарезервированное восьмибитное поле. При отправке устанавливается в ноль, при получении игнорируется.
Fragment Offset — 13-битное беззнаковое целое число: смещение данных после этого заголовка относительно начала фрагментируемой части исходного пакета, в единицах по восемь октетов.
Res — зарезервированное двухбитное поле. При отправке устанавливается в ноль, при получении игнорируется.
Флаг M: 1 — есть последующие фрагменты; 0 — последний фрагмент.
Identification — 32 бита; см. описание ниже.
Чтобы отправить пакет, превышающий MTU пути к назначению, узел-источник может разделить его на фрагменты и отправить каждый отдельным пакетом для последующей сборки у получателя.
Для каждого фрагментируемого пакета источник создаёт значение Identification. Оно должно отличаться от идентификатора любого другого фрагментированного пакета, недавно* отправленного с теми же Source Address и Destination Address. При наличии заголовка Routing учитывается Destination Address конечного пункта назначения.
* «Недавно» означает в пределах максимального вероятного времени жизни пакета, включая время прохождения от источника до получателя и ожидание сборки с другими фрагментами этого пакета. При этом источник не обязан знать максимальное время жизни. Предполагается, что требование выполняется алгоритмом с низкой частотой повторного использования идентификаторов. Примеры таких алгоритмов описаны в [RFC7739].
Исходный большой нефрагментированный пакет называется «исходным пакетом» и рассматривается как состоящий из трёх частей:
| Заголовки каждого фрагмента | Заголовки расширений и верхнего уровня | Фрагментируемая часть |
Заголовки каждого фрагмента должны включать заголовок IPv6 и любые заголовки расширений, которые должны обрабатываться узлами на пути к назначению: все заголовки до Routing включительно, если он присутствует; иначе до Hop-by-Hop Options включительно, если он присутствует; иначе заголовков расширений в этой части нет.
Заголовки расширений — все остальные заголовки расширений, не вошедшие в часть заголовков каждого фрагмента. Для этой цели Encapsulating Security Payload (ESP) не считается заголовком расширения. Заголовок верхнего уровня — первый заголовок верхнего уровня, не являющийся заголовком расширения IPv6. Примеры: TCP, UDP, IPv4, IPv6, ICMPv6 и, как отмечено, ESP.
Фрагментируемая часть состоит из остальной части пакета после заголовка верхнего уровня или после любого заголовка, начального IPv6 или расширения, содержащего значение Next Header = No Next Header.
Фрагментируемая часть исходного пакета делится на фрагменты. Их длины выбираются так, чтобы полученные пакеты фрагментов помещались в MTU пути к месту или местам назначения. Каждый полный фрагмент, кроме, возможно, последнего, имеет длину, кратную восьми октетам.
Фрагменты передаются отдельными пакетами. Первый содержит заголовки каждого фрагмента, заголовок Fragment, заголовки расширений и верхнего уровня и первый фрагмент. Каждый последующий содержит заголовки каждого фрагмента, заголовок Fragment и соответствующий фрагмент.
Первый пакет фрагмента состоит из:
1. Заголовков каждого фрагмента исходного пакета, причём Payload Length исходного заголовка IPv6 изменяется на длину только этого пакета фрагмента без длины самого заголовка IPv6, а Next Header последнего из заголовков каждого фрагмента изменяется на 44. 2. Заголовка Fragment, содержащего: значение Next Header, определяющее первый заголовок после заголовков каждого фрагмента исходного пакета; Fragment Offset со смещением фрагмента относительно начала фрагментируемой части исходного пакета в единицах по восемь октетов, равным 0 для первого фрагмента; флаг M со значением 1, поскольку фрагмент первый; и Identification, созданный для исходного пакета. 3. Заголовков расширений, если они есть, и заголовка верхнего уровня. Эти заголовки должны находиться в первом фрагменте. Примечание: это ограничивает суммарный размер заголовков до заголовка верхнего уровня включительно значением MTU пути к месту или местам назначения пакета. 4. Первого фрагмента.
Последующие пакеты фрагментов состоят из:
1. Заголовков каждого фрагмента исходного пакета с изменённым Payload Length, содержащим длину только этого пакета без длины самого заголовка IPv6, и значением Next Header последнего из этих заголовков, изменённым на 44. 2. Заголовка Fragment со значением Next Header, определяющим первый заголовок после заголовков каждого фрагмента исходного пакета; Fragment Offset со смещением относительно начала фрагментируемой части исходного пакета в единицах по восемь октетов; флагом M, равным 0 для последнего фрагмента и 1 для остальных; и Identification, созданным для исходного пакета. 3. Самого фрагмента.
Не должны создаваться фрагменты, перекрывающие другие фрагменты того же исходного пакета.
В месте назначения пакеты фрагментов собираются в исходный нефрагментированный пакет: заголовки каждого фрагмента, заголовки расширений и верхнего уровня, затем данные первого, второго и последующих фрагментов.
Сборка регулируется следующими правилами.
Исходный пакет собирается только из пакетов фрагментов с одинаковыми Source Address, Destination Address и Fragment Identification.
Заголовки каждого фрагмента собранного пакета состоят из всех заголовков до заголовка Fragment первого пакета фрагмента, то есть пакета с нулевым Fragment Offset, не включая сам Fragment, со следующими двумя изменениями:
• Поле Next Header последнего из заголовков каждого фрагмента берётся из поля Next Header заголовка Fragment первого фрагмента. • Payload Length собранного пакета вычисляется по длине заголовков каждого фрагмента и длине и смещению последнего фрагмента. Например:
PL.orig = PL.first − FL.first − 8 + (8 × FO.last) + FL.last
где PL.orig — поле Payload Length собранного пакета; PL.first — Payload Length первого пакета фрагмента; FL.first — длина части после заголовка Fragment первого пакета; FO.last — поле Fragment Offset заголовка Fragment последнего пакета; FL.last — длина части после заголовка Fragment последнего пакета.
Фрагментируемая часть собранного пакета формируется из частей после заголовков Fragment каждого пакета. Длина каждой части вычисляется вычитанием из Payload Length пакета длины заголовков между заголовком IPv6 и самой частью; её относительное положение во фрагментируемой части вычисляется по Fragment Offset.
Заголовок Fragment отсутствует в окончательно собранном пакете.
Если фрагмент является целой дейтаграммой, то есть и Fragment Offset, и флаг M равны нулю, дальнейшая сборка не нужна; его следует обработать как полностью собранный пакет, обновив Next Header, скорректировав Payload Length, удалив заголовок Fragment и т. д. Любые другие соответствующие ему фрагменты с теми же адресами IPv6 источника и назначения и Fragment Identification следует обрабатывать независимо.
При сборке фрагментированных пакетов возможны следующие ошибки:
• Если в течение 60 секунд после получения первого по времени фрагмента не получено достаточно фрагментов для завершения сборки, сборку нужно прекратить и отбросить все полученные для этого пакета фрагменты. Если получен первый фрагмент, то есть с Fragment Offset = 0, его источнику следует отправить сообщение ICMP Time Exceeded — Fragment Reassembly Time Exceeded. • Если длина фрагмента, определённая по Payload Length пакета фрагмента, не кратна восьми октетам, а флаг M равен 1, фрагмент нужно отбросить и следует отправить его источнику ICMP Parameter Problem с кодом 0, указывающий на Payload Length пакета фрагмента. • Если длина и смещение фрагмента таковы, что Payload Length собранного с его участием пакета превысит 65 535 октетов, фрагмент нужно отбросить и следует отправить его источнику ICMP Parameter Problem с кодом 0, указывающий на поле Fragment Offset пакета фрагмента. • Если первый фрагмент не содержит все заголовки до заголовка верхнего уровня включительно, его следует отбросить и отправить источнику ICMP Parameter Problem с кодом 3 и нулевым полем Pointer. • Если какие-либо собираемые фрагменты перекрывают другие фрагменты того же пакета, сборку нужно прекратить и отбросить все полученные для него фрагменты; сообщения об ошибке ICMP отправлять не следует.
Следует учитывать, что фрагменты могут дублироваться в сети. Вместо того чтобы считать точные дубликаты перекрывающимися фрагментами, реализация может обнаруживать и отбрасывать их, сохраняя остальные фрагменты того же пакета.
Следующие ситуации не ожидаются часто, но не считаются ошибками:
• Число и содержимое заголовков перед Fragment у разных фрагментов одного исходного пакета могут различаться. Все заголовки перед Fragment в каждом пакете обрабатываются при поступлении до постановки фрагментов в очередь на сборку. В собранном пакете сохраняются только заголовки пакета с нулевым Offset. • Значения Next Header в заголовках Fragment разных фрагментов исходного пакета могут различаться. Для сборки используется только значение из пакета с нулевым Offset. • Другие поля заголовка IPv6 также могут различаться между собираемыми фрагментами. Спецификации, использующие эти поля, могут давать дополнительные указания, если базового механизма применения значений фрагмента с нулевым Offset недостаточно. Например, раздел 5.3 [RFC3168] описывает объединение битов явного уведомления о перегрузке ECN разных фрагментов для получения битов ECN собранного пакета.
4.6. Заголовок Destination Options
Заголовок Destination Options переносит необязательные сведения, которые нужно проверять только узлу или узлам назначения пакета. Он обозначается значением Next Header = 60 в непосредственно предшествующем заголовке и имеет формат:
| Next Header: 8 бит | Hdr Ext Len: 8 бит | Options: переменная длина |
Next Header — восьмибитный идентификатор типа заголовка непосредственно после Destination Options. Используются значения поля Protocol IPv4 [IANA-PN].
Hdr Ext Len — восьмибитное беззнаковое целое число: длина заголовка Destination Options в единицах по восемь октетов без учёта первых восьми октетов.
Options — поле переменной длины, подобранной так, чтобы весь заголовок Destination Options имел длину, кратную восьми октетам. Содержит один или несколько параметров в кодировке TLV, описанных в разделе 4.2.
Единственные параметры назначения, определённые этим документом, — Pad1 и PadN из раздела 4.2.
Необязательные сведения для назначения можно закодировать в пакете IPv6 двумя способами: как параметр заголовка Destination Options либо как отдельный заголовок расширения. Примеры второго подхода — заголовки Fragment и Authentication. Выбор зависит от желаемого действия узла назначения, который не понимает эти сведения:
• Если требуется отбросить пакет и, только если его Destination Address не является групповым адресом, отправить по Source Address сообщение ICMP Unrecognized Type, сведения можно закодировать либо отдельным заголовком, либо параметром Destination Options, два старших бита Option Type которого равны 11. Выбор может зависеть от того, какой способ занимает меньше октетов, обеспечивает лучшее выравнивание или более эффективный разбор. • Если требуется иное действие, сведения должны кодироваться как параметр Destination Options, два старших бита Option Type которого равны 00, 01 или 10 и задают нужное действие (см. раздел 4.2).
4.7. Отсутствие следующего заголовка
Значение 59 в поле Next Header заголовка IPv6 или любого заголовка расширения указывает, что за этим заголовком ничего нет. Если поле Payload Length заголовка IPv6 указывает на наличие октетов после заголовка с Next Header = 59, эти октеты нужно игнорировать и при пересылке пакета передавать без изменений.
4.8. Определение новых заголовков расширений и параметров
Определять новые заголовки расширений IPv6 не рекомендуется, кроме случаев, когда ни один существующий заголовок нельзя использовать с определением нового параметра для него. Предложение нового заголовка расширения должно содержать подробное техническое объяснение, почему существующий заголовок нельзя использовать для требуемой функции. Дополнительные сведения приведены в [RFC6564].
Примечание. Новые заголовки расширений, требующие поузловой обработки, определять нельзя: согласно разделу 4 единственный заголовок расширения с таким поведением — Hop-by-Hop Options.
Новые параметры Hop-by-Hop не рекомендуются, поскольку узлы могут быть настроены игнорировать заголовок Hop-by-Hop Options, отбрасывать содержащие его пакеты или направлять их на медленный путь обработки. Разработчики, рассматривающие новые параметры Hop-by-Hop, должны учитывать такое вероятное поведение. До стандартизации любого нового параметра Hop-by-Hop необходимо очень чётко обосновать его необходимость.
Вместо определения новых заголовков расширений рекомендуется использовать Destination Options для необязательных сведений, которые должны проверяться только узлом или узлами назначения: это обеспечивает лучшую обработку и обратную совместимость.
Если новые заголовки расширений всё же определяются, они должны использовать следующий формат:
| Next Header: 8 бит | Hdr Ext Len: 8 бит | Header-Specific Data: переменная длина |
Next Header — восьмибитный идентификатор типа заголовка непосредственно после этого заголовка расширения; используются значения поля Protocol IPv4 [IANA-PN].
Hdr Ext Len — восьмибитное беззнаковое целое число: длина заголовка Destination Options в единицах по восемь октетов без учёта первых восьми октетов.
Header-Specific Data — поле переменной длины, содержащее специфичные для заголовка расширения поля.
5. Вопросы размера пакетов
IPv6 требует, чтобы каждый канал в Интернете имел MTU не менее 1280 октетов. Это называется минимальным MTU канала IPv6. На любом канале, который не может передать пакет размером 1280 октетов целиком, на уровне ниже IPv6 должны обеспечиваться специфичные для канала фрагментация и сборка.
Каналы с настраиваемым MTU, например PPP [RFC1661], должны настраиваться на MTU не менее 1280 октетов; рекомендуется 1500 октетов или больше, чтобы возможная инкапсуляция, то есть туннелирование, не вызывала фрагментации на уровне IPv6.
От каждого непосредственно подключённого канала узел должен уметь принимать пакеты размером до MTU этого канала.
Узлам IPv6 настоятельно рекомендуется реализовывать обнаружение MTU пути [RFC8201], чтобы находить и использовать значения выше 1280 октетов. Однако минимальная реализация IPv6, например в загрузочном ПЗУ, может просто ограничиться отправкой пакетов не более 1280 октетов и не реализовывать обнаружение MTU пути.
Для отправки пакета, превышающего MTU пути, узел может использовать заголовок Fragment IPv6 для фрагментации у источника и сборки у получателя или получателей. Однако такая фрагментация не рекомендуется приложениям, способным подстраивать размер пакетов под измеренный MTU пути вплоть до 1280 октетов.
Узел должен уметь принимать фрагментированный пакет, размер которого после сборки достигает 1500 октетов. Разрешается принимать фрагментированные пакеты, собирающиеся в пакеты более 1500 октетов. Протокол верхнего уровня или приложение, полагающееся на фрагментацию IPv6 при отправке пакетов больше MTU пути, не должно отправлять пакеты больше 1500 октетов без уверенности, что получатель способен собрать пакет такого большего размера.
6. Метки потоков
Источник использует 20-битное поле Flow Label заголовка IPv6 для маркировки последовательностей пакетов, которые должны обрабатываться в сети как единый поток.
Текущее определение Flow Label IPv6 приведено в [RFC6437].
7. Классы трафика
Сеть использует восьмибитное поле Traffic Class заголовка IPv6 для управления трафиком. Значение его битов в полученном пакете или фрагменте может отличаться от отправленного источником.
Текущее использование Traffic Class для дифференцированного обслуживания и явного уведомления о перегрузке определено в [RFC2474] и [RFC3168].
8. Вопросы протоколов верхнего уровня
8.1. Контрольные суммы верхнего уровня
Любой транспортный или иной протокол верхнего уровня, включающий адреса из заголовка IP в вычисление контрольной суммы, необходимо изменить для IPv6, используя 128-битные адреса IPv6 вместо 32-битных адресов IPv4. В частности, псевдозаголовок TCP и UDP для IPv6 имеет следующий формат:
| Source Address: 128 бит | | Destination Address: 128 бит | | Upper-Layer Packet Length: 32 бита | | нули: 24 бита | Next Header: 8 бит |
• Если пакет IPv6 содержит заголовок Routing, в псевдозаголовке используется Destination Address конечного пункта назначения. У источника этот адрес находится в последнем элементе заголовка Routing; у получателя или получателей — в поле Destination Address заголовка IPv6. • Значение Next Header в псевдозаголовке обозначает протокол верхнего уровня, например 6 для TCP или 17 для UDP. Оно отличается от Next Header в заголовке IPv6, если между IPv6 и заголовком верхнего уровня есть заголовки расширений. • Upper-Layer Packet Length в псевдозаголовке — длина заголовка и данных верхнего уровня, например заголовка TCP вместе с данными TCP. Некоторые протоколы верхнего уровня содержат собственную информацию о длине, например поле Length заголовка UDP; для них в псевдозаголовке используется это значение. Другие, например TCP, не содержат собственной длины; тогда используется Payload Length заголовка IPv6 за вычетом длины всех заголовков расширений между IPv6 и заголовком верхнего уровня. • В отличие от IPv4, по умолчанию контрольная сумма UDP в пакетах, создаваемых узлом IPv6, обязательна. Создавая пакет UDP, узел IPv6 должен вычислить контрольную сумму по пакету и псевдозаголовку; если результат равен нулю, перед помещением в заголовок UDP его нужно заменить шестнадцатеричным FFFF. Получатели IPv6 должны отбрасывать пакеты UDP с нулевой контрольной суммой и им следует регистрировать ошибку. • В качестве исключения протоколы, использующие UDP для туннельной инкапсуляции, могут включать режим нулевой контрольной суммы для определённого порта или набора портов при отправке и/или приёме. Любой узел с таким режимом должен соблюдать требования «Заявления о применимости дейтаграмм IPv6 UDP с нулевыми контрольными суммами» [RFC6936].
Версия ICMP для IPv6 [RFC4443] включает приведённый псевдозаголовок в вычисление контрольной суммы; это отличается от ICMP для IPv4, где псевдозаголовок не используется. Изменение защищает ICMP от ошибочной доставки и повреждения тех полей заголовка IPv6, от которых он зависит и которые, в отличие от IPv4, не покрываются контрольной суммой межсетевого уровня. Поле Next Header псевдозаголовка ICMP содержит значение 58, обозначающее ICMP для IPv6.
8.2. Максимальное время жизни пакета
В отличие от IPv4, узлы IPv6 не обязаны обеспечивать ограничение максимального времени жизни пакета. Поэтому поле IPv4 Time-to-Live переименовано в IPv6 в Hop Limit. На практике очень немногие реализации IPv4, если они вообще есть, соблюдают требование ограничения времени жизни, поэтому практически это не изменение. Любой протокол верхнего уровня, рассчитывающий на ограничение времени жизни межсетевым уровнем IPv4 или IPv6, следует обновить собственными механизмами обнаружения и отбрасывания устаревших пакетов.
8.3. Максимальный размер полезной нагрузки верхнего уровня
При вычислении максимального размера полезной нагрузки для данных верхнего уровня протокол верхнего уровня должен учитывать, что заголовок IPv6 больше заголовка IPv4. Например, в IPv4 параметр TCP Maximum Segment Size (MSS) вычисляется как максимальный размер пакета — значение по умолчанию или полученное при обнаружении MTU пути — минус 40 октетов: 20 для минимального заголовка IPv4 и 20 для минимального заголовка TCP. При TCP поверх IPv6 MSS должен вычисляться как максимальный размер пакета минус 60 октетов, поскольку минимальный заголовок IPv6 без расширений на 20 октетов больше минимального заголовка IPv4.
8.4. Ответы на пакеты с заголовками Routing
Если протокол верхнего уровня отправляет один или несколько пакетов в ответ на полученный пакет с заголовком Routing, ответные пакеты не должны включать заголовок Routing, автоматически полученный «обращением» полученного заголовка, ЕСЛИ НЕ проверены целостность и подлинность полученных Source Address и заголовка Routing, например с помощью заголовка Authentication в полученном пакете. Иными словами, в ответ на пакет с Routing разрешены только следующие варианты:
• Ответные пакеты без заголовков Routing. • Ответные пакеты с заголовками Routing, НЕ полученными обращением Routing принятого пакета, например с заголовком из локальной конфигурации. • Ответные пакеты с заголовками Routing, полученными обращением Routing принятого пакета, ЕСЛИ И ТОЛЬКО ЕСЛИ отвечающий проверил целостность и подлинность Source Address и заголовка Routing полученного пакета.
9. Вопросы IANA
На RFC 2460 ссылается ряд реестров IANA, включая параметры Internet Protocol Version 6 (IPv6) [IANA-6P], назначенные номера протоколов Интернета [IANA-PN], сетевые идентификаторы ONC RPC (netids) [IANA-NI], представляющие интерес идентификаторы протоколов сетевого уровня (NLPID) [IANA-NL] и реестры протоколов [IANA-PR]. IANA обновила эти ссылки на настоящий документ.
10. Вопросы безопасности
С точки зрения базового формата и передачи пакетов свойства безопасности IPv6 сходны с IPv4. Вопросы безопасности включают:
• Прослушивание: элементы на пути могут наблюдать весь пакет каждой дейтаграммы IPv6, включая содержимое и метаданные. • Повторное воспроизведение: злоумышленник записывает последовательность пакетов из сети и воспроизводит её первоначальному получателю. • Вставку пакета: злоумышленник подделывает пакет с выбранными свойствами и вводит его в сеть. • Удаление пакета: злоумышленник удаляет пакет из сети. • Изменение пакета: злоумышленник удаляет пакет из сети, изменяет и вводит обратно. • Атаки посредника (MITM): злоумышленник подменяет поток связи, выдавая себя перед получателем за отправителя, а перед отправителем — за получателя. • Отказ в обслуживании (DoS): злоумышленник отправляет получателю большие объёмы легитимного трафика, чтобы перегрузить его.
Пакеты IPv6 могут быть защищены от прослушивания, повтора, вставки и изменения пакетов и атак посредника с помощью «Архитектуры безопасности протокола Интернета» [RFC4301]. Кроме того, протоколы верхнего уровня, такие как TLS и SSH, могут защищать трафик приложений поверх IPv6.
Механизма защиты от атак DoS здесь нет. Защита от таких атак выходит за рамки спецификации.
Адреса IPv6 значительно больше адресов IPv4, поэтому сканировать адресное пространство через Интернет и даже в одном сетевом канале, например локальной сети, гораздо сложнее. Подробнее см. [RFC7707].
Ожидается, что адреса IPv6 узлов будут заметнее в Интернете, чем адреса IPv4, поскольку преобразование адресов используется реже. Это создаёт дополнительные вопросы конфиденциальности, например облегчает различение конечных точек. Подробнее см. [RFC7721].
Архитектура заголовков расширений IPv6, добавляя большую гибкость, создаёт и новые проблемы безопасности. Как отмечено ниже, вопросы заголовка Fragment решены, но последствия для безопасности любого нового заголовка расширения необходимо тщательно изучать, включая его взаимодействие с существующими заголовками. Подробнее см. [RFC7045].
Эта версия спецификации IPv6 решает ряд проблем безопасности, обнаруженных в предыдущей версии [RFC2460]:
• Текст переработан для фрагментов, представляющих целые дейтаграммы, у которых Fragment Offset и M равны нулю. При получении их следует обрабатывать как собранные пакеты; другие соответствующие фрагменты следует обрабатывать независимо. Процесс создания фрагментов изменён так, чтобы не создавать фрагменты целой дейтаграммы. Подробнее см. [RFC6946] и [RFC8021]. • Из раздела 5 удалён абзац, требовавший добавлять заголовок Fragment к исходящим пакетам, если ICMP Packet Too Big сообщает MTU следующего перехода менее 1280. Подробнее см. [RFC6946]. • Текст изменён: узлы IPv6 не должны создавать перекрывающиеся фрагменты; если при сборке дейтаграммы обнаружен хотя бы один перекрывающийся фрагмент, всю дейтаграмму и её фрагменты нужно молча отбросить. Также уточнено, что при получении перекрывающихся фрагментов не следует отправлять ошибку ICMP. Подробнее см. [RFC5722]. • Текст изменён так, чтобы требовать размещения всех заголовков до первого заголовка верхнего уровня включительно в первом фрагменте. Подробнее см. [RFC7112]. • Включены обновления [RFC5095] и [RFC5871]: удалены описание заголовка Routing типа 0 (RH0) и RH0 из списка обязательных расширений; рекомендации по назначению заголовков Routing определены в RFC 5871.
Вопросы безопасности других частей IPv6, включая адресацию, ICMPv6 и обнаружение MTU пути, рассматриваются в соответствующих спецификациях.
11. Ссылки
11.1. Нормативные ссылки
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC0791, September 1981,
<http://www.rfc-editor.org/info/rfc791>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
11.2. Информационные ссылки
[Err2541] RFC Errata, Erratum ID 2541, RFC 2460.
[Err4279] RFC Errata, Erratum ID 4279, RFC 2460.
[Err4657] RFC Errata, Erratum ID 4657, RFC 2460.
[Err4662] RFC Errata, Erratum ID 4662, RFC 2460.
[IANA-6P] IANA, "Internet Protocol Version 6 (IPv6) Parameters",
<https://www.iana.org/assignments/ipv6-parameters>.
[IANA-EH] IANA, "IPv6 Extension Header Types",
<https://www.iana.org/assignments/ipv6-parameters>.
[IANA-NI] IANA, "ONC RPC Network Identifiers (netids)",
<https://www.iana.org/assignments/rpc-netids>.
[IANA-NL] IANA, "Network Layer Protocol Identifiers (NLPIDs) of
Interest", <https://www.iana.org/assignments/nlpids>.
[IANA-PN] IANA, "Protocol Numbers",
<https://www.iana.org/assignments/protocol-numbers>.
[IANA-PR] IANA, "Protocol Registries", <https://www.iana.org/
protocols>.
[IANA-RH] IANA, "Routing Types", <https://www.iana.org/assignments/
ipv6-parameters>.
[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,
<http://www.rfc-editor.org/info/rfc1661>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, DOI 10.17487/RFC5722, December 2009,
<http://www.rfc-editor.org/info/rfc5722>.
[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for
the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871,
May 2010, <http://www.rfc-editor.org/info/rfc5871>.
[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
RFC 6564, DOI 10.17487/RFC6564, April 2012,
<http://www.rfc-editor.org/info/rfc6564>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement
for the Use of IPv6 UDP Datagrams with Zero Checksums",
RFC 6936, DOI 10.17487/RFC6936, April 2013,
<http://www.rfc-editor.org/info/rfc6936>.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments",
RFC 6946, DOI 10.17487/RFC6946, May 2013,
<http://www.rfc-editor.org/info/rfc6946>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014,
<http://www.rfc-editor.org/info/rfc7112>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<http://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
[RFC7739] Gont, F., "Security Implications of Predictable Fragment
Identification Values", RFC 7739, DOI 10.17487/RFC7739,
February 2016, <http://www.rfc-editor.org/info/rfc7739>.
[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6
Atomic Fragments Considered Harmful", RFC 8021,
DOI 10.17487/RFC8021, January 2017,
<http://www.rfc-editor.org/info/rfc8021>.
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, "Path
MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<http://www.rfc-editor.org/info/rfc8201>.
Приложение A. Рекомендации по форматированию параметров
В приложении приведены рекомендации по размещению полей при проектировании новых параметров заголовков Hop-by-Hop Options и Destination Options, описанных в разделе 4.2. Рекомендации основаны на следующих предположениях.
• Желательно, чтобы любые многооктетные поля в области Option Data параметра располагались на естественных границах: поле длиной n октетов должно находиться на смещении от начала заголовка Hop-by-Hop или Destination Options, кратном n, для n = 1, 2, 4 или 8. • Желательно также, чтобы заголовок Hop-by-Hop или Destination Options занимал как можно меньше места при соблюдении требования кратности его длины восьми октетам. • Можно предположить, что при наличии любого из этих заголовков он содержит очень мало параметров, обычно один.
Из этих предположений следует такой подход: расположить поля от меньшего к большему без внутреннего заполнения, затем вывести требование выравнивания всего параметра из требования к самому большому полю, но не более восьми октетов. Подход показан в следующих примерах.
Пример 1
Если параметр X требует двух полей данных длиной 8 и 4 октета, их следует расположить так:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type=X |Opt Data Len=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| поле 4 октета |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ поле 8 окт. +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Требование выравнивания — 8n+2, чтобы восьмиоктетное поле начиналось на смещении от начала содержащего заголовка, кратном восьми. Полный заголовок Hop-by-Hop или Destination Options с этим единственным параметром выглядит так:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=1 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | поле 4 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + поле 8 окт. + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Пример 2
Если параметр Y требует трёх полей данных длиной 4, 2 и 1 октет, они располагаются так:
+-+-+-+-+-+-+-+-+
| Option Type=Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Data Len=7 | поле 1 октет | поле 2 октета |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| поле 4 октета |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Требование выравнивания — 4n+3, чтобы четырёхоктетное поле начиналось на смещении от начала содержащего заголовка, кратном четырём. Полный заголовок Hop-by-Hop или Destination Options с этим единственным параметром выглядит так:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=1 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | поле 1 октет | поле 2 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | поле 4 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Пример 3
Заголовок Hop-by-Hop или Destination Options, содержащий оба параметра X и Y из примеров 1 и 2, имеет один из двух следующих форматов в зависимости от того, какой параметр идёт первым:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=3 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | поле 4 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + поле 8 окт. + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=1 | 0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | поле 1 октет | поле 2 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | поле 4 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len=3 | Pad1 Option=0 | Option Type=Y | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Opt Data Len=7 | поле 1 октет | поле 2 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | поле 4 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PadN Option=1 |Opt Data Len=4 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 0 | Option Type=X |Opt Data Len=12| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | поле 4 октета | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + поле 8 окт. + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Приложение B. Изменения по сравнению с RFC 2460
Этот документ содержит следующие изменения по сравнению с RFC 2460.
• Из аннотации удалено название IP Next Generation. • В раздел 1 добавлено, что порядок передачи данных такой же, как в IPv4 согласно RFC 791. • В разделе 3 уточнено уменьшение Hop Limit. • Уточнено, что заголовки расширений, кроме Hop-by-Hop Options, не обрабатываются, не вставляются и не удаляются узлами на пути доставки. • Требование обработки Hop-by-Hop Options заменено на возможность и добавлено примечание об ожидаемом поведении. • В раздел 4 добавлен абзац о нумерации заголовков расширений и определении заголовков верхнего уровня; в конце раздела добавлена ссылка на реестр IANA типов заголовков расширений IPv6. • Включены обновления RFC 5095 и 5871: описание RH0 удалено, указано, что рекомендации по назначению заголовков маршрутизации содержатся в RFC 5871, а RH0 удалён из списка обязательных расширений. • Раздел 4.5 о фрагментации IPv6 переработан с учётом RFC 5722, 6946, 7112 и 8021. В частности:
— Переработано описание фрагментов, представляющих целые дейтаграммы с нулевыми Fragment Offset и M: их следует обрабатывать как собранные пакеты, а другие соответствующие фрагменты — независимо. Процесс создания изменён так, чтобы не создавать такие фрагменты. — Запрещено создавать перекрывающиеся фрагменты. Если при сборке обнаружен хотя бы один перекрывающийся фрагмент, всю дейтаграмму и её фрагменты нужно молча отбросить; уточнено, что ошибку ICMP отправлять не следует. — Все заголовки до первого заголовка верхнего уровня включительно должны находиться в первом фрагменте. В связи с этим изменено описание фрагментации и сборки и добавлен новый случай ошибки. — Добавлены правила обработки точных дубликатов фрагментов. — Исправлено описание включения заголовка Authentication (AH) и отмечен случай No Next Header. — Термин «нефрагментируемые заголовки» заменён на «заголовки каждого фрагмента». — Из раздела 5 удалено требование добавлять Fragment к исходящим пакетам при получении ICMP Packet Too Big с MTU следующего перехода менее 1280. — Уточнены ограничения MTU и кратности восьми октетам, отмечено ограничение на заголовки в первом фрагменте.
• В разделе 4.5 уточнено, что некоторые поля IPv6 могут различаться между собираемыми фрагментами, а другие спецификации могут содержать дополнительные указания по сборке; см., например, раздел 5.3 [RFC3168]. • Включено обновление RFC 6564: добавлен раздел 4.8 с рекомендациями по определению новых заголовков расширений и параметров. • В раздел 5 добавлено определение минимального MTU канала IPv6. • Упрощён раздел 6 о метках потоков и удалено прежнее приложение A «Семантика и использование поля Flow Label»; вместо этого даны ссылки на текущие спецификации Flow Label [RFC6437] и Traffic Class [RFC2474], [RFC3168]. • В раздел 8 включено обновление RFC 6935 «IPv6 и контрольные суммы UDP для туннелируемых пакетов»: добавлено исключение из поведения по умолчанию для UDP-пакетов туннелей с нулевой контрольной суммой. • В раздел 9 «Вопросы IANA» добавлено указание заменить ссылки на RFC 2460 ссылками на этот документ. • Переработан и расширен раздел 10 «Вопросы безопасности». • В благодарности добавлен абзац об авторах документов, вносящих обновления. • Ссылки обновлены до текущих версий и разделены на нормативные и информационные. • Внесены изменения по исправлениям RFC 2460:
— Исправление 2541 [Err2541] отмечало, что RFC 2460 не обновил RFC 2205 после изменения длины метки потока с 24 до 20 битов по сравнению с RFC 1883. Вопрос решён в RFC 6437, где определена метка потока; настоящая спецификация ссылается на RFC 6437. Изменения не требуются. — Исправление 4279 [Err4279] отмечало отсутствие обработки случая, когда пересылающий узел получает пакет с нулевым Hop Limit. Это исправлено в разделе 3. — Исправление 4657 [Err4657] предлагало указать, что заголовки расширений никогда не должны вставляться узлом, отличным от источника пакета. Вопрос решён в разделе 4 «Заголовки расширений IPv6». — Исправление 4662 [Err4662] предлагало указать, что заголовки расширений, за одним исключением, не проверяются, не обрабатываются, не изменяются, не вставляются и не удаляются узлами на пути доставки. Вопрос решён в разделе 4. — Исправление 2843 отмечено как отклонённое. Изменения не вносились.
Благодарности
Авторы благодарят участников рабочей группы IPng, исследовательской группы End-to-End Protocols и интернет-сообщества в целом за многочисленные полезные предложения.
Авторы также благодарят авторов обновляющих RFC, включённых в этот документ для перевода спецификации IPv6 в статус стандарта Интернета: Joe Abley, Shane Amante, Jari Arkko, Manav Bhatia, Ronald P. Bonica, Scott Bradner, Brian Carpenter, P.F. Chimento, Marshall Eubanks, Fernando Gont, James Hoagland, Sheng Jiang, Erik Kline, Suresh Krishnan, Vishwas Manral, George Neville-Neil, Jarno Rajahalme, Pekka Savola, Magnus Westerlund и James Woodyatt.
Адреса авторов
Stephen E. Deering На пенсии Vancouver, British Columbia Canada
Robert M. Hinden Check Point Software 959 Skyway Road San Carlos, CA 94070 United States of America
Эл. почта: bob.hinden@gmail.com
Deering & Hinden Standards Track [Page 42]
Перевод: RFCNET · rfcnet.ru
Original copyright notice
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Deering & Hinden Standards Track [Page 2]
RFC 8200 IPv6 Specification July 2017
Неофициальный перевод. При расхождениях см. оригинал.