AAA

RFC 4884 — Расширенный протокол ICMP для поддержки сообщений из нескольких частей

Статус документа

В этом документе содержится проект стандартного протокола, предложенного сообществу Internet. Документ служит приглашением к дискуссии в целях развития и совершенствования протокола. Текущее состояние стандартизации протокола вы можете узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться без ограничений.

Тезисы

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

Многокомпонентные сообщения поддерживаются структурой расширения ICMP. Эта структура располагается в конце сообщения ICMP и включает заголовок расширения, за которым следует один или множество объектов расширения. Каждый из таких объектов содержит заголовок объекта и данные. Заголовки объектов используют общий формат.

Этот документ переопределяет упомянутые выше сообщения ICMP за счет задания атрибута размера. Все определенные к настоящему моменту сообщения ICMP, к которым будет добавляться в конце структура расширения, включают поле «исходная дейтаграмма». Это поле содержит начальные октеты дейтаграммы, которая вызвала сообщение ICMP об ошибке. Хотя поле «исходной дейтаграммы» имеет переменный размер, в сообщениях ICMP нет поля для указания этого размера. Поэтому, для упрощения анализа сообщений этот документ выделяет 8 ранее зарезервированных битов для указания размера поля исходной дейтаграммы.

Предложенные модификации меняют требования совместимости для ICMP. Влияние этих изменений на соответствующие требованиям спецификации реализации протокола рассматривается в этом документе. Приведены также требования к будущим реализациям.

Этот документ является обновлением RFC 792 и RFC 4443.

Оглавление

1. Введение

В этом документе заново определены сообщения ICMPv4 [RFC0792] и ICMPv6 [RFC4443] для включения структуры расширения и атрибута размера. Структура расширения поддерживает многокомпонентные операции ICMP. Разработчики протоколов могут создавать сообщения ICMP, передающие дополнительную информацию, которая представляется с помощью структуры расширения.

Этот документ также решает фундаментальную проблему расширяемости ICMP. Все сообщения ICMP, рассматриваемые в этом документе, включают поле «исходной дейтаграммы», содержащее начальные октеты дейтаграммы, вызвавшей сообщение ICMP об ошибке. Хотя поле «исходной дейтаграммы» имеет переменный размер, в сообщениях ICMP нет поля для указания этого размера.

Приложения определяют размер поля «исходной дейтаграммы» из общего размера сообщения ICMP. Если структура расширения добавляется в конце сообщения без введения атрибута размера поля «исходной дейтаграммы», сообщение становится «неразборчивым». В частности, приложения не смогут, где заканчивается поле «исходной дейтаграммы» и начинается структура расширения. Поэтому в данном документе предложен атрибут размера наряду со структурой расширения, добавляемой в конце сообщения ICMP.

В документе также решается задача совместимости с существующими реализациями ICMP, которые не поддерживают определенных здесь расширений или реализуют их без добавления атрибута размера. В частности, рассматриваются вопросы совместимости с некотрыми широко распространенными реализациями ICMPv4, , совместимыми с MPLS, которые передают определенные здесь расширения без добавления требуемого атрибута размера.

В этом документе не определяются объекты расширения ICMP. Определен только заголовок расширения и заголовок, используемый всеми объектами. В работах [UNNUMBERED], [ROUTING-INST] и [MPLS-ICMP] описаны примеры применения объектов расширения ICMP.

Упомянутые выше документы имеют ряд общих характеристик. Они добавляют информацию к сообщениям ICMP Time Expired для программ трассировки (TRACEROUTE). В этом случае, как и во многих других, добавление информации к существующему сообщению ICMP Time Expired более предпочтительно, чем определение нового сообщения и генерация двух сообщений вместо одного при отбрасывании пакетов по причине обнуления TTL.

2. Используемые в документе соглашения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [RFC2119].

3. Список изменений ICMP

The following is a summary of changes to ICMP that are introduced by this memo:

4. Расширяемость ICMP

RFC 792 определяет следующие типы сообщений ICMPv4:

[RFC1191] резервирует биты для поля Next-Hop MTU в сообщениях Destination Unreachable.

RFC 4443 определяет следующие типы сообщений ICMPv6:

Многие сообщения ICMP в соответствии с текущими опеределениями являются расширяемыми. Разработчики протоколов могут расширять сообщения ICMP простым добавлением полей или структур данных в конец сообщения.

Однако ряд сообщений ICMP в соответствии с текущими определениями не поддерживает расширений:

Эти сообщения содержат поле «исходной дейтаграммы», которое включает начальные октеты дейтаграммы, вызвавшей сообщение ICMP. RFC 792 определеяет поле «исходной дейтаграммы» для сообщений ICMPv4. В RFC 792 поле «исходной дейтаграммы» включает заголовок IP и следующие за ним 8 октетов исходной дейтаграммы. [RFC1812] расширяет поле «исходной дейтаграммы», позволяя включать в него любое число октетов при условии, что размер сообщения ICMP не будет превышать минимальный размер буфера сборки IPv4 (т. е., 576 октета). RFC 4443 определяет поле «исходной дейтаграммы» для сообщений ICMPv6. В RFC 4443 поле «исходной дейтаграммы» всегда содержит столько октетов, сколько можно включить без превышения сообщением ICMP минимального размера IPv6 MTU (т. е., 1280 октетов).

К сожалению, поле «исходной дейтаграммы» не имеет атрибута размера. Приложения определяют размер этого поля по общему размеру сообщения ICMP. Если к сообщения добавляется структура расширения без добавления атрибута размера поля «исходной дейтаграммы», сообщение становится «неразборчивым». В частности, приложение не сможет определить, где заканчивается поле «исходной дейтаграммы» и начинается структура расширения.

Для решения этой проблемы в настоящем документе вводится 8-битовый атрибут размера для следующих сообщений ICMPv4:

Такой же 8-битовый атрибут размера добавляется в сообщения ICMPv6:

Атрибут размера должен задаваться в тех случаях, когда к перечисленным выше сообщениям добавляется ICMP Extension Structure.

Атрибут размера показывает размер поля «исходной дейтаграммы». Пространство для атрибута размера берется из резервных октетов, которые раньше были определены с нулевым значением.

Для сообщения ICMPv4 атрибут размера показывает число 32-битовых слов. При наличии атрибута размера поле «исходной дейтаграммы» должно дополняться нулями для выравнивания по ближайшей 32-битовой границе. Поскольку в каждом из затрагиваемых изменениями типов сообщений ICMPv4 был зарезервирован шестой октет, этот октет был выбран для размещения атрибута размера в сообщениях ICMPv4.

Для сообщения ICMPv6 атрибут размера показывает количество 64-битовых слов. При наличии атрибута размера поле «исходной дейтаграммы» должно дополняться нулями для выравнивания по ближайшей 64-битовой границе. Поскольку в каждом из затрагиваемых типов сообщений ICMPv6 шестой октет был резервным, этот октет был выбран для размещения атрибута размера в ICMPv6.

Для обеспечения совместимости с более ранними версиями при добавлении в конец сообщения ICMP Extension Structure и наличии поля «исходной дейтаграммы» последнее должно содержать не менее 128 октетов. Если в исходной дейтаграмме менее 128, поле «исходной дейтаграммы» должно дополняться нулями до 128 октетов (обоснование этого приведено в параграфе 5.1).

В следующих параграфах описан атрибут размера в сообщениях ICMP.

4.1. ICMPv4 Destination Unreachable

Рисунок 1 показывает формат сообщения ICMPv4 Destination Unreachable.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     unused    |    Length     |         Next-Hop MTU*         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Заголовок Internet и начальные октеты исходной дейтаграммы   |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1: ICMPv4 Destination Unreachable

Синтаксис и семантика всех полей этого сообщения не меняются по сравнению с RFC 792, за исключением добавления во второе слово атрибута размера (Length). Этот атрибут указывает размер поля «исходной дейтаграммы» в 32-битовых словах.

Поле Next-Hop MTU требуется не во всех случаях. Оно показано только для деонстрации того, что эти биты заняты для данного типа сообщений и их невозможно выделить для целей настойщего документа.

4.2. ICMPv4 Time Exceeded

Рисунок 2 показывает формат сообщения ICMPv4 Time Exceeded.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     unused    |    Length     |          unused               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Заголовок Internet и начальные октеты исходной дейтаграммы   |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2: ICMPv4 Time Exceeded

Синтаксис и семантика всех полей этого сообщения не меняются по сравнению с RFC 792, за исключением добавления во второе слово атрибута размера (Length). Этот атрибут указывает размер поля «исходной дейтаграммы» в 32-битовых словах.

4.3. ICMPv4 Parameter Problem

Рисунок 3 показывает формат сообщения ICMPv4 Parameter Problem.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Pointer    |    Length     |          unused               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Заголовок Internet и начальные октеты исходной дейтаграммы   |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3: ICMPv4 Parameter Problem

Синтаксис и семантика всех полей этого сообщения не меняются по сравнению с RFC 792, за исключением добавления во второе слово атрибута размера (Length). Этот атрибут указывает размер поля «исходной дейтаграммы» в 32-битовых словах.

4.4. ICMPv6 Destination Unreachable

Рисунок 4 показывает формат сообщения ICMPv6 Destination Unreachable.

    0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Length     |                  Unused                       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Максимально возможное число октетов          |
+                вызвавшего сообщение ICMPv6 пакета, без        +
|                превышения минимального IPv6 MTU [RFC4443]     |

Рисунок 4: ICMPv6 Destination Unreachable

Синтаксис и семантика всех полей этого сообщения не меняются по сравнению с RFC 4443, за исключением добавления во второе слово атрибута размера (Length). Этот атрибут указывает размер поля «исходной дейтаграммы» в 64-битовых словах.

4.5. ICMPv6 Time Exceeded

Рисунок 5 показывает формат сообщения ICMPv6 Time Exceeded.

     0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Length     |                 Unused                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Максимально возможное число октетов          |
+                вызвавшего сообщение ICMPv6 пакета, без        +
|                превышения минимального IPv6 MTU [RFC4443]     |

Рисунок 5: ICMPv6 Time Exceeded

Синтаксис и семантика всех полей этого сообщения не меняются по сравнению с RFC 4443, за исключением добавления во второе слово атрибута размера (Length). Этот атрибут указывает размер поля «исходной дейтаграммы» в 64-битовых словах.

4.6. Сообщения ICMP, которые могут быть расширены

Структура расширения ICMP может добавляться в конец сообщений следующих типов:

ICMP Extension Structure недопустимо добавлять в прочие сообщения ICMP, упомянутые в разделе 4. Расширения не были определены для сообщений ICMPv6 Packet Too Big и Parameter Problem по причине отсутствия в этих типах сообщения пространства для размещения атрибута размера.

5. Совместимость с предыдущими версиями

Сообщения ICMP можно разделить на несколько категорий:

Все реализации ICMP могут передавать сообщения без расширений. Реализации ICMP до 1999 г. просто не знают о расширениях ICMP.

Некоторые реализации ICMP, выпущенные между 1999 г. и публикацией этого документа могут передавать не соответствующие этой спецификации варианты расширений ICMP. В частности, такие реализации могут добавлять структуру расширения ICMP в конец сообщений Time Exceeded и Destination Unreachable. В таких случаях реализации передают ровно 128 октетов, представляющих исходную дейтаграмму, дополняя ее, при необходимости, нулями. Расчет контрольной суммы такие реализации выполняют в соответствии с приведенным здесь описанием. Однако они не задают атрибут размера для поля «исходной дейтаграммы».

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

Приложения, принимающие сообщения ICMP также можно разделить по категориям:

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

Несовместимые реализации разбирают определенные здесь расширения, но только для сообщений Time Expired и Destination Unreachable. Они требуют, чтобы поле «исходной дейтаграммы» имело размер 128 октетов и не понимают атрибута размера, связанного с этим полем. Несовместимые реализации выпускались с 1999 г. до момента публикации этого документа.

Совместимые реализаци полностью соответствуют данной спецификации.

Таблица 1 показывает, как приложения каждой категории будут относится к разборке сообщений ICMP всех категорий.

Нет расширенийНесовместимые расширенияСовместимые расширения
Классические приложенияПараграф 5.1Параграф 5.1
Несовместимые приложенияПараграф 5.2Параграф 5.3
Совместимые приложенияПараграф 5.4Параграф 5.5

Прочерк в ячейке таблицы говорит о нормальной ситуации, которая не требует разъяснений. В последующих параграфах предполагается, что сообщения ICMP относятся к типу Time Exceeded.

5.1. Классическое приложение получает сообщение ICMP с расширениями

Когда классическое приложение получает сообщение ICMP с расширением, приложение будет некорректно интерпретировать это расширение, как часть поля «исходной дейтаграммы». К счастью, расширения начинаются не ранее 128 октетов от начала поля «исходной дейтаграммы». Поэтому проблемы могут возникать только у тех приложений, которые обрабатывают более 128 окетов поля «исходной дейтаграммы». На момент публикации этого документа было известно только два таких приложения, причем степень негативного влияния расширений минимальна.

Некоторые варианты стека TCP при получении сообщения ICMP проверяют контрольную сумму поля «исходной дейтаграммы» [ATTACKS]. Если эта сумма некорректна, стек TCP отбрасывает сообщение ICMP по соображениям безопасности. Если завершающие октеты поля «исходной дейтаграммы» переписаны расширением ICMP, такой стек TCP будет отбрасывать сообщения ICMP, которые не были бы отброшены в обычных условиях. Негативное влияние такого отбрасывания считается минимальным, поскольку множество сообщений ICMP отбрасывается по другим причинам (например, фильтрация ICMP, перегрузка в сети, некорректная контрольная сумма в результате «усекновения» исходной дейтаграммы).

Другой, теоретически возможный, но весьма маловероятный случай возникает, когда расширения ICMP переписывают часть поля «исходной дейтаграммы», которая представляет заголовок TCP, что приводит стек TCP к работе с некорректным соединением TCP. Такие случаи маловероятны, поскольку для их возникновения нужно, чтобы заголовок TCP выходил за пределы первых 128 октетов поля «исходной дейтаграммы», а расширение напоминало бы корректный заголовок TCP.

5.2. Несовместимое приложение получает сообщение ICMP без расширений

Когда несовместимое приложение ICMPv4 получает сообщение без расширений, оно проверяет общий размер сообщения ICMPv4. Если этот размер меньше размера заголовка IP в сообщении + + 144 октета, приложение корректно определяет отсутствие расширений.

Значение 144 включает 8 октетов двух первых слов сообщения ICMPv4 Time Exceeded, 128 октетов поля «исходной дейтаграммы», 4 октета заголовка расширения ICMP и 4 октета одного заголовка объекта ICMP. Все перечисленные октеты требуются при использовании расширений.

Если данные ICMPv4 включают не менее 144 октетов, приложение должно проверить октет 137 для определения наличия корректного заголовка ICMPv4 Extension. Корректный заголовок расширения должен содержать корректный номер версии и контрольную суииу. Если это не выполняется, приложение корректно считает, что в сообщении не содержится расширений.

Несовместимые приложения предполагают, что структура расширения ICMPv4 начинается с октета 137 сообщения Time Exceeded после поля «исходной дейтаграммы» размером 128 октетов.

В перечисленных ниже случаях возможен некорректный анализ несовместимым приложением сообщения ICMPv4:

Такие случаи возможны, но маловероятны.

Аналогичный анализ можно провести для ICMPv6 с соответствующим изменением числовых констант.

5.3. Несовместимое приложение получает сообщение ICMP с совместимым расширением

Когда несовместимое приложение получает сообщение с совместимым расширением ICMP, оно сможет корректно разобрать такое сообщение лишь в тех случаях, когда размер поля «исходной дейтаграммы» в точности равен 128 октетам. Это обусловлено тем, что несовместимые приложения не понимают атрибута размера поля «исходной дейтаграммы» (они предполагают этот размер равным 128 октетам).

За исключением ограничения на размер сообщения ICMP в целом (не более размера минимального буфера сборки — 576 октетов для ICMPv4 и 1280 октетов для ICMPv6), не вводится ограничений на размер поля «исходной дейтаграммы». Однако каждая реализация сама решает, сколько октетов исходной дейтаграммы следует включать в сообщение. Для обеспечения совместимости с несовместимыми с данной спецификацией реализациями TRACEROUTE включается в точности 128 октетов исходной дейтаграммы. Если такая совместимость не требуется, можно включать большее число октетов исходной дейтаграммы.

5.4. Совместимое приложение получает сообщение ICMP без расширений

Когда совместимое приложение получает сообщение ICMP, оно проверяет значение атрибута размера поля «исходной дейтаграммы». Если атрибут имеет значение 0, совместимая реализация должна считать, что сообщение не включает расширений.

5.5. Совместимое приложение получает сообщение ICMP с несовместимым расширением

Когда совместимое приложение получает сообщение ICMP, оно проверяет значение атрибута размера поля «исходной дейтаграммы». Если атрибут имеет значение 0, совместимая реализация должна считать, что сообщение не включает расширений. В этом случае такое определение корректно, но не обеспечивает совместимости с несовместимой с данной спецификацией реализацией ICMP, которая отправила сообщение.

Поэтому для упрощения и стимулирования перехода совместимые реализации TRACEROUTE должны включать не используемый по умолчанию механизм поддержки несовместимых откликов. В частности, когда приложение TRACEROUTE, работающее в несовместимом режиме, получает достаточно большое сообщение ICMP без атрибута размера, оно будет разбирать корректный заголовок расширения в фиксированном положении, предполагая поле «исходной дейтаграммы» размером 128 октетов. Если приложение находит корректный номер версии и контрольную сумму, оно будет трактовать следующие октеты, как структуру расширения.

6. Взаимодействие с трансляцией адресов

Расширения ICMP, определенные в этом документе, не конфликтуют с системами трансляции адресов (NAT). [RFC3022] разрешает традиционным устройствам NAT изменять отдельные поля сообщений ICMP. К числу таких полей относится и упоминаемое здесь поле «исходной дейтаграммы». Однако, если устройство NAT меняет поле «исходной дейтаграммы», изменять следует только начальные поля этого поля, представляющие внешний заголовок IP. Поскольку внешний заголовок IP гарантированно располагается в первых 128 октетах поля «исходной дейтаграммы», расширения ICMP и NAT не нарушают работу друг друга.

Понятно, что реализация NAT может пренебречь ограничениями RFC 3022 и переписать определенное в этом документе поле атрибута размера. Если реализация NAT будет заполнять это поле нулями, полученный в результате пакет будет неотличим от пакетов, генерируемых несовместимыми реализациями ICMP. Вопросы совместимости для таких случаев рассмотрены в параграфе 5.5.

7. Структура расширения ICMP

В этом документе предлагается опциональная структура расширения (ICMP Extension Structure), которая может добавляться в конец сообщений ICMP, перечисленных в параграфе 4.6 этого документа.

Extension Structure содержит один заголовок расширения (Extension Header), за которым следует один или несколько объектов. Получив сообщение ICMP с расширениями, прикладная программа может обработать часть объектов, игнорируя остальные. Наличие в сообщении нераспознанных объектов не является показателем некорректного формата сообщения ICMP.

Как сказано выше, общий размер сообщения ICMP, включая расширения, не должен превышать минимальный размер буфера сборки. Рисунок 6 показывает формат ICMP Extension Header.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version|      (Reserved)       |           Checksum            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 6: Заголовок расширения ICMP

Заголовок расширения ICMP имеет следующие поля:

8. Объекты расширения ICMP

Каждый объект расширения содержит по крайней мере одно 32-битовое слово, представляющее заголовок и и данные объекта расширения. Все заголовки объектов используют общий формат. Рисунок 7 показывает формат заголовка и данных объекта.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |   Class-Num   |   C-Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                    // (данные объекта) //                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7: Заголовок и данные объекта расширения

Заголовок объекта включает следующие поля:

9. Вопросы безопасности

При получении сообщения ICMP прикладная программа должна проверить его синтаксическую корректность. Должна проверяться также контрольная сумма расширения. Некорректно заданные атрибуты размера и другие синтаксические проблемы могут приводить к переполнению буфера.

В этом документе не задаются условия, при которых маршрутизаторы передают сообщения ICMP. Следовательно, не возникает возможностей для организации новых атак на службы (DoS). Маршрутизаторы могут ограничивать скорость передачи сообщения ICMP.

10. Согласование с IANA

Заголовок ICMP Extension Object содержит два 8-битовых поля — Class-Num идентифицирует класс объекта, а C-Type — субтип класса. Значения субтипов определяются для каждого класса объектов.

Агенство IANA организовало и поддерживает реестр классов объектов расширения ICMP и субтипов для этих классов. В настоящем документе не задается каких-либо значений для этих реестров. Классы объектов 0xF7 — 0xFF резервируются для частных применений. Значения идентификаторов класса выделяются в порядке поступления заявок (first-come-first-serve). Правила выделения значений субтипов должны задаваться в документах, определяющих класс.

11. Благодарности

Спасибо Pekka Nikander, Mark Doll, Fernando Gont, Joe Touch, Christian Voiqt и Sharon за их комментарии к документу.

12. Литература

12.1. Нормативные документы

  1. [RFC0792]Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
  2. [RFC1191]Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
  3. [RFC1812]Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  4. [RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  5. [RFC4443]Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.

12.2. Дополнительная литература

  1. [UNNUMBERED]Atlas, A., Bonica, R., Rivers, JR., Shen, N., and E. Chen, "ICMP Extensions for Unnumbered Interfaces", Work in Progress, March 2007.
  2. [MPLS-ICMP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "ICMP Extensions for MultiProtocol Label Switching", Work in Progress3, January 2007.
  3. [ATTACKS] Gont, F., "ICMP attacks against TCP", Work in Progress, October 2006.
  4. [ROUTING-INST] Shen, N. and E. Chen, "ICMP Extensions for Routing Instances", Work in Progress, November 2006.
  5. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

Адреса авторов

Ronald P. Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, VA 20171 US
EMail: ten.repinuj@acinobr

Der-Hwa Gan
Consultant
EMail: moc.oohay@nagawhred

Daniel C. Tappan
Consultant
EMail: moc.liamg@nappat.nad

Carlos Pignataro
Cisco Systems, Inc.
7025 Kit Creek Road
Research Triangle Park, NC 27709 US
EMail: moc.ocsic@atangipc

Перевод на русский язык

Николай Малых, moc.milib@hkylamn