RFC 4884 Extended ICMP to Support Multi-Part Messages

Опубликовано 09.04.2007 автором Nikolai Malykh 
Network Working Group                                      R. Bonica
Request for Comments: 4884                          Juniper Networks
Updates: 792, 4443                                            D. Gan
Category: Standards Track                                 Consultant
                                                           D. Tappan
                                                          Consultant
                                                        C. Pignataro
                                                 Cisco Systems, Inc.
                                                          April 2007

 

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

Extended ICMP to Support Multi-Part Messages

PDF

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

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

Авторские права

Copyright (C) The IETF Trust (2007).

Аннотация

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

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

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

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

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

Оглавление

Исключено из версии HTML

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

Ниже приводится список изменений в ICMP, вносимых данным документом.

ICMP Extension Structure может добавляться в конец сообщений ICMPv4 Destination Unreachable, Time Exceeded и Parameter Problem.

ICMP Extension Structure может добавляться в конец сообщений ICMPv6 Destination Unreachable и Time Exceeded.

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

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

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

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

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

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

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

  • Destination Unreachable – адресат недоступен;
  • Time Exceeded – время жизни истекло;
  • Parameter Problem – проблема с параметрами;
  • Source Quench – слишком большая скорость передачи;
  • Redirect — перенаправление;
  • Echo Request/Reply – запрос/отклик эхо;
  • Timestamp/Timestamp Reply – временная метка и отклик с временной сеткой;
  • Information Request/Information Reply – информационный запрос/отклик.

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

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

  • Destination Unreachable – адресат недоступен;
  • Packet Too Big – слишком большой пакет;
  • Time Exceeded – время жизни истекло;
  • Parameter Problem – проблема с параметрами;
  • Echo Request/Reply – запрос/отклик эхо.

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

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

  • ICMPv4 Destination Unreachable (type = 3);
  • ICMPv4 Time Exceeded (type = 11);
  • ICMPv4 Parameter Problem (type = 12);
  • ICMPv6 Destination Unreachable (type = 1);
  • ICMPv6 Packet Too Big (type = 2);
  • ICMPv6 Time Exceeded (type = 3);
  • ICMPv6 Parameter Problem (type = 4).

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

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

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

  • Destination Unreachable (type = 3);
  • Time Exceeded (type = 11);
  • Parameter Problem (type = 12).

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

  • Destination Unreachable (type = 1);
  • Time Exceeded (type = 3).

Атрибут размера должен задаваться в тех случаях, когда к перечисленным выше сообщениям добавляется 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|не используется|    Length     |         Next-Hop MTU*         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Заголовок IP и начальные октеты исходной дейтаграммы     |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 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             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|не используется|    Length     |        не используется        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Заголовок IP и начальные октеты исходной дейтаграммы     |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 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     |        не используется        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Заголовок IP и начальные октеты исходной дейтаграммы     |
|                                                               |
|                           //                                  |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 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     |                не используется                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Максимально возможное число октетов               |
+           вызвавшего сообщение 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     |                не используется                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Максимально возможное число октетов               |
+           вызвавшего сообщение ICMPv6 пакета, без             +
|          превышения минимального IPv6 MTU [RFC4443]           |

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

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

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

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

  • ICMPv4 Destination Unreachable;
  • ICMPv4 Time Exceeded;
  • ICMPv4 Parameter Problem;
  • ICMPv6 Destination Unreachable;
  • ICMPv6 Time Exceeded.

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

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

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

  • сообщения без расширений ICMP;
  • сообщения с несовместимыми с данной спецификацией расширениями ICMP;
  • сообщения с совместимыми расширениями ICMP.

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

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

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

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

  • классические приложения;
  • несовместимые приложения;
  • совместимые приложения.

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

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

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

Таблица 1.

Нет расширений

Несовместимые расширения

Совместимые расширения
Классические приложения

–

Параграф 5.1

Параграф 5.1
Несовместимые приложения

Параграф 5.2

–

Параграф 5.3
Совместимые приложения

Параграф 5.4

Параграф 5.5

–

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

Прочерк в ячейке таблицы говорит о нормальной ситуации, которая не требует разъяснений. В последующих параграфах предполагается, что сообщения 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:

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

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

Аналогичный анализ можно провести для 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, определенные в этом документе, не конфликтуют с системами трансляции адресов (NAT2). [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.

    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, включая расширения, не должен превышать минимальный размер буфера сборки. Рисунок 6 показывает формат ICMP Extension Header.

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

Version – версия (4 бита)

Номер версии расширения ICMP. Данный документ задает версию 2.

Reserved – резерв (12 битов)

Резервное поле, которое должно иметь нулевое значение.

Checksum – контрольная сумма (16 битов)

Дополнение до 1 суммы дополнений до 1 октетов структуры данных. При расчете контрольной суммы значение поля предполагается нулевым. Равное нулю поле контрольной суммы говорит об отсутствии последней. Использование поля контрольной суммы в заголовке расширения описано в параграфе 5.2.

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. Заголовок и данные объекта расширения

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

Length – размер (16 битов)

Размер объекта в октетах с учетом заголовка и данных.

Class-Num (8 битов)

Идентификатор класса объекта.

C-Type (8 битов)

Идентификатор субтипа объекта.

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

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

В этом документе не задаются условия, при которых маршрутизаторы передают сообщения ICMP. Следовательно, не возникает возможностей для организации новых атак на службы (DoS3). Маршрутизаторы могут ограничивать скорость передачи сообщения 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. Нормативные документы

[RFC0792] Postel, J., “Internet Control Message Protocol”, STD 5, RFC 792, September 1981.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191, November 1990.

[RFC1812] Baker, F., “Requirements for IP Version 4 Routers”, RFC 1812, June 1995.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[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. Дополнительная литература

[UNNUMBERED] Atlas, A., Bonica, R., Rivers, JR., Shen, N., and E. Chen, “ICMP Extensions for Unnumbered Interfaces”, Work in Progress, March 2007.

[MPLS-ICMP] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, “ICMP Extensions for MultiProtocol Label Switching”, Work in Progress5, January 2007.

[ATTACKS] Gont, F., “ICMP attacks against TCP”, Work in Progress, October 2006.

[ROUTING-INST] Shen, N. and E. Chen, “ICMP Extensions for Routing Instances”, Work in Progress, November 2006.

[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: rbonica@juniper.net

Der-Hwa Gan

Consultant

EMail: derhwagan@yahoo.com

Daniel C. Tappan

Consultant

EMail: Dan.Tappan@gmail.com

Carlos Pignataro

Cisco Systems, Inc.

7025 Kit Creek Road

Research Triangle Park, NC 27709

US

EMail: cpignata@cisco.com

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

Николай Малых

nmalykh@gmail.com

Полное заявление автоских прав

Copyright (C) The IETF Trust (2007).

К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

Интеллектуальная собственность

IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.

Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.

1Далее для удобства будет называть такие сообщения многокомпонентными. Прим. перев.

2Network Address Translation.

3Denial-of-service attack – атака на отказ служб.

5Работа завершена и опубликована в RFC 4950. Прим. перев.

 

Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.