RFC4833 Timezone Options for DHCP

Network Working Group                                            E. Lear
Request for Comments: 4833                            Cisco Systems GmbH
Updates: 2132                                                  P. Eggert
Category: Standards Track                                           UCLA
                                                              April 2007

Опции часового пояса для DHCP

Timezone Options for DHCP

PDF

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

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

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

Copyright (C) The IETF Trust (2007).

Тезисы

Двумя основными способами обмена информацией о часовых поясах являются строки POSIX 1003.1 timezone и имена в базе данных timezone. Этот документ задает опции DHCP для каждого из этих методов. Использование опции DHCPv4 time offset прекращается.

1. Введение

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

  • POSIX-строка TZ;

  • ссылка на имя записи для часового пояса в базе данных TZ.

Стандарт POSIX [1] обеспечивает способ представления часового пояса в форме строки. Использование таких строк позволяет осуществлять точный переход между летним и зимним временем (DST1), а также другие случаи перевода часов, которые происходят регулярно (например, во второе воскресенье марта в 02:00 по местному времени). Однако для переходов с более длительными периодами, которые включают изменение правил перехода на летнее время, я также для нерегулярных переходов требуются другие механизмы.

База данных TZ [7], используемая во многих операционных системах, обеспечивает совместимость со старыми версиями, а также требуемую точность перехода для большинства мест планеты и времени с 1970 года. База данных TZ таже пытается обеспечить понятный для человека набор идентификаторов часовых поясов. Кроме того, многие системы уже используют базу данных TZ и имена часовых поясов стали фактически стандартными. Поскольку база данных TZ содержит больше информации, можно эвристически вывести информацию POSIX из идентификатора TZ (см., например, [10]), но не наоборот.

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

1.1. Смежные работы

Протокол DHCP2 [3] обеспечивает хостам возможность получения конфигурационной информации, относящейся к конкретному местоположению в сети IP сервии 4. Аналогично поддерживается и настройка хостов IP версии 6 [5]. В RFC 2132 [4] задана опция для предоставления клиенту информации о часовом поясе в форме смещения относительно времени UTC в секундах. Предоставляемой этой опцией информации не достаточно для определения клиентом настроек летнего времени и перехода между летним и зимним временем. Для того, чтобы клиент мог точно установить местное время, серверам DHCP следует учитывать переход DST при определении срока действия аренды.

Кроме того, смещения недостаточно для определения реального часового пояса, к которому относится клиент, и в результате нет возможности получить понятное человеку обозначение часового пояса типа EST или EDT.

В спецификации iCalendar [9] определены элементы VTIMEZONE. При полном задании они обеспечивают уровень точности, схожий с базой данных TZ. Однако по причине отсутствия глобального реестра VTIMEZONE TZID (хотя один из возможных реестров предложен в [8]) для точного указания часового пояса требуется указать запись полностью. Для обеспечения нужной информации потребуется не менее 300 октетов, а верхней границы просто нет. Кроме того, на момент подготовки этого документа авторам не было известно ни одной операционной системы, изначально использующей записи VTIMEZONE. Можно включить опцию для TZURL. Однако при «холодном старте» это будет сильно нагружать серверы DHCP и другие компоненты.

2. Новые опции часового пояса для DHCPv4

Ниже показаны две новых опции, определенные для протокола DHCPv4.

            PCode  Len   TZ-POSIX String
           +-----+-----+------------------------------+
           | 100 |  N  | Строка IEEE 1003.1           |
           +-----+-----+------------------------------+

            TCode  Len   TZ-Database String
           +-----+-----+------------------------------+
           | 101 |  N  | Ссылка на TZ Database        |
           +-----+-----+------------------------------+

В соответствии с RFC 2939 [6] агентство IANA выделило значения PCode (100) и TCode (101).

Поле Len содержит 1-октетное значение, которое указывает размер следующей за полем строки в каждой из опций.

Значения строк, следующих за полем Len описаны ниже. Отметим, что они не завершаются символом ASCII NULL.

3. Новые опции часового пояса для DHCPv6

Семантика и содержимое представления этих опций в DHCPv6 в точности совпадают с описанными для DHCPv4 с учетом различий в способах кодирования опций DHCPv4 и DHCPv6.

Представление новых опций часового пояса в DHCPv6 показано ниже.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OPTION_NEW_POSIX_TIMEZONE    |         option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      TZ POSIX String                          |
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_NEW_POSIX_TIMEZONE(41)

option-length

Число октетов TZ POSIX String, описанной ниже.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  OPTION_NEW_TZDB_TIMEZONE    |          option-length         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          TZ Name                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

option-code

OPTION_NEW_TZDB_TIMEZONE(42)

option-length

Число октетов TZ Database String, описанной ниже.

4. POSIX-строка TZ

POSIX-строка TZ представляет собой строку, подходящую для переменной TZ, в соответствии с параграфом 8.3 [1] за исключением того, что эта строка не должна начинаться с двоеточия (:). Строка не завершается символом ASCII NULL. Пример строки приведен ниже.

   EST5EDT4,M3.2.0/02:00,M11.1.0/02:00

Эта строка описывает часовой пояс, отстающий от UTC на 5 часов в обычный период (зимой) и на 4 в период DST (летом), который начинается во второе воскресенье марта в 02:00 по местному времени и заканчивается в первое воскресенье ноября в 02:00 по местному времени. В обычный период этот часовой пояс обзначается EST, а в период DST — EDT.

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

5. TZ Name

TZ Name представляет собой имя записи Zone в базе данных, которую обычно называют базой данных TZ. В частности, при текстовом формате базы данных строка указывает поле name в строке часового пояса. Для использования этой опции у клиента должна быть копия базы данных. Строка не завершается символом ASCII NULL.

Примером может служить строка Europe/Zurich.

Для использования этой опции у клиента уже должна быть копия TZ Database. Конфигурация базы данных выходит за рамки этого документа. Клиентам, поддерживающим эту опцию, следует предпочитать ее строке POSIX, если он распознает возвращенную строку TZ Name. Если строка TZ Name не распознана, клиент должен игнорировать опцию.

6. Использование строк, возвращенных сервером

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

При выборе опции, реализуемой на стороне клиента, должно приниматься во внимание что использование TZ Name проще и обеспечивает точность в течение продолжительных периодов, зато POSIX-строка TZ POSIX не требует регулярно обновлять копию базы данных TZ. Для большинства пользователей TZ Name будет лучше, в частности для случаев, когда часовой пояс не меняется в течение продолжительного времени, но POSIX-строка TZ может оказаться более удобной для небольших приложений с хорошей поддержкой.

От клиентов не требуется реализация обоих вариантов, а серверу, поддерживающему одну из этих опций, следует реализовать и другую. Связь между опциями может быть организована администратором системы. Базовый сервер может передавать клиентам значения опций без их анализа и проверки пригодности. Более функциональный сервер может иметь копию базы данных TZ и сравнивать значения TZ name с имеющейся копией или эвристически выводить POSIX-строки TZ из строк TZ name для упрощения администрирования.

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

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

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

7. Новая опция Timezone и время аренды

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

8. Отмена опции Time Offset

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

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

Атакующий может предоставить клиенту ложную информацию. В результате кто-то может пропустить встречу или оказаться на ней слишком рано, а также возможно рассогласование работы сложной техники или выполнения иных важных функций и даже возникновение отказов в работе. Если у клиента имеются средства управления заданиями (например, cron), работающие по часам, возможно выполнение некоторых заданий раньше или позже запланированного времени, повтор или пропуск некоторых заданий во время перехода DST. В таких случаях может оказаться разумным запрос операционной системой подтверждения на изменение часового пояса от человека.

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

Клиентам, использующим опцию POSIX, следует также с подозрением относиться к установкам часового пояса, задающим смещение от UTC более 25 часов (ограничение POSIX с учетом использования летнего времени). На момент подготовки этого документа максимальное смещение от UTC на практике составляло 14 часов, но в будущем это смещение может быть увеличено.

10. Взаимодействие с IANA

Агентство IANA выделило коды опций DHCPv4 и DHCPv6 для указания часового пояса со ссылками на этот документ.

Агентство IANA анонсировало отмену опции time offset IPv4 (тег 2) со ссылкой на этот документ.

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

Этот документ задает способ обмена информацией о часовых поясах. Сложно было собрать изменения различных баз данных из расположенных по всему миру источников. Многие добровольцы делали эту работу на протяжении нескольких лет через список рассылки tz@elsie.nci.nih.gov. Спасибо также Ralph Droms, Bernie Volz, Ted Lemon, Lisa Dusseault, John Hawkinson, Stig Venaas и Simon Vaillancourt за их вклад в улучшение этой работы.

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

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

[1] «Standard for Information Technology — Portable Operating System Interface (POSIX) — Base Definitions», IEEE Std 1003.1-2004, December 2004.

[2] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[3] Droms, R., «Dynamic Host Configuration Protocol», RFC 2131, March 1997.

[4] Alexander, S. and R. Droms, «DHCP Options and BOOTP Vendor Extensions», RFC 2132, March 1997.

[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, «Dynamic Host Configuration Protocol for IPv6 (DHCPv6)», RFC 3315, July 2003.

[6] Droms, R., «Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types», BCP 43, RFC 2939, September 2000.

[7] Eggert, P. and A. Olson, «Sources for Time Zone and Daylight Saving Time Data», <http://www.twinsun.com/tz/tz-link.htm>.

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

[8] Vaillancourt, S., «Calconnect.org TC Timezone Technical Committee: Timezone Registry and Service Recommendations», April 2006.

[9] Dawson, F. and Stenerson, D., «Internet Calendaring and Scheduling Core Object Specification (iCalendar)», RFC 2445, November 1998.

[10] Eggert, P. and E. Reingold, «cal-dst.el — calendar functions for daylight savings rules», <http://cvs.savannah.gnu.org/viewcvs/*checkout*/emacs/lisp/calendar/cal-dst.el?root=emacs>.

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

Eliot Lear

Cisco Systems GmbH

Glatt-com

Glattzentrum, ZH CH-8301

Switzerland

Phone: +41 1 878 9200

EMail: lear@cisco.com

Paul Eggert

UCLA

Computer Science Department

4532J Boelter Hall

Los Angeles, CA 90095

USA

Phone: +1 310 825 3886

EMail: eggert@cs.ucla.edu

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

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

nmalykh@gmail.com

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

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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

1Daylight saving time.

2Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации.




RFC 4836 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

Network Working Group                                           E. Beili
Request for Comments: 4836                              Actelis Networks
Obsoletes: 3636                                               April 2007
Category: Standards Track

Определения управляемых объектов для IEEE 802.3 MAU

Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)

PDF

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

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

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

Copyright (C) The IETF Trust (2007).

Тезисы

Этот документ определяет часть MIB1 для использования с протоколами сетевого управления в сообществе Internet. В частности, определены объекты для управления модулями подключения IEEE 802.3 MAU2. Этот документ служит заменой RFC 3636. Он меняет указанную спецификацию путем переноса определений OBJECT-IDENTITY и относящихся к ним текстовых соглашений в отдельный модуль MIB, администрируемый агентством IANA3. Кроме того, добавлена информация для поддержки MAU типов EFM и 10GBASE-CX44.

Оглавление

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

1. Введение

Этот документ определяет часть MIB для использования с протоколами сетевого управления в сообществе Internet. В частности, определены объекты для управления модулями подключения IEEE 802.3 MAU.

Предыдущая версия документа — RFC 3636 [RFC3636] — определяла один модуль MIB. Данный документ разделил исходный модуль MIB на два, поместив часто обновляемые объекты и текстовые соглашения в отдельный модуль, администрируемый IANA, для того, чтобы не нужно было менять базовый модуль MAU MIB.

Первая версия администрируемого IANA модуля MIB была расширена списком объектов управления для поддержки интерфейсов EFM и 10GBASE-CX4.

Технология Ethernet, определенная рабочей группой IEEE 802.3, продолжает развиваться с ростом скорости, добавлением новых типов кабелей и интерфейсов, а также новых возможностей. Это развитие может потребовать изменения управляемых объектов с учетом новых функций. Данный документ, наряду с другими документами рабочей группы, отражает определенный этап развития технологии Ethernet. В будущем этот документ может быть пересмотрен или рабочая группа Ethernet Interfaces and Hub MIB Working Group может выпустить новый документ для Ethernet.

2. Стандартная модель управления Internet

Подробный обзор документов, описывающих текущую модель стандартного сетевого управления Internet, приведен в разделе 7 RFC 3410 [RFC3410].

Доступ к управляемым объектам осуществляется через виртуальные хранилища информации, называемые MIB. Доступ к объектам MIB обычно происходит с использованием простого протокола сетевого управления SNMP5. Объекты в MIB определяются с использованием механизмов SMI6. Этот документ задает модуль MIB, соответствующий спецификации SMIv2, описанной в STD 58 RFC 2578 [RFC2578], STD 58 RFC 2579 [RFC2579] и STD 58 RFC 2580 [RFC2580].

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

3. Обзор

Экземпляры объектов этих типов представляют атрибуты IEEE 802.3 MAU. Некоторые типы MAU определены в стандарте IEEE 802.3 CSMA/CD [IEEE802.3]. Эти MAU могут подключаться к повторителям или интерфейсам 802.3 (типа Ethernet). Для удобства в этом документе они называются MAU повторителей и MAU интерфейсов.

Представленные здесь определения основаны на параграфах 30.5 «Layer Management for 10 Mb/s, 100 Mb/s, 1000 Mb/s, and 10 Gb/s Medium Attachment Units (MAUs)», 30.6 «Management for link Auto-Negotiation» и Приложении 30A «GDMO Specifications for 802.3 managed object classes» стандарта IEEE Std. 802.3-2005 [IEEE802.3]. Данная спецификация предназначена для управления всеми типами Ethernet/802.3 MAU.

3.1. Связь с RFC 3636

Определения управляемых объектов в этом документе включают в себя определения RFC 3636 [RFC3636].

Для снижения потребности в обновлении базового модуля MAU MIB в результате добавления новых типов MAU, состояний Media Available, возможностей Auto Negotiation и/или типов разъемов (Jack) все относящиеся к делу объекты и текстовые соглашения перенесены в отдельный модуль MIB (IANA-MAU-MIB), администрируемый IANA, первая версия которого определена в этом документе. Таким образом, при добавлении MAU, состояния доступности среды, возможностей автосогласования и/или типов разъемов, определенных рабочей группой IEEE 802.3, потребуется пересмотр лишь поддерживаемого IANA модуля, а заданный в этом документе базовый модуль MAU-MIB сохранится.

В дополнение к этому добавлены определения в администрируемый IANA модуль MIB для поддержки интерфейсов EFM и 10GBASE-CX4, определенных в IEEE Std 802.3ah-2004 [IEEE802.3ah] и IEEE Std 802.3ak-2004 [IEEE802.3ak], соответственно, которые сейчас являются частью IEEE Std 802.3-2005 [IEEE802.3].

Следует отметить, что внесенные здесь изменения не полностью совместимы с модулями MIB, импортирующими в данный момент дескрипторы объектов типа MAU из MAU-MIB. Такие модули требуют пересмотра с импортом соответствующих дескрипторов из IANA-MAU-MIB. Всем управляющим приложениям, обрабатывающим такие объекты (например, выводящим пользователю текст DESCRIPTION), нужно брать определения из IANA-MAU-MIB, а не MAU-MIB. Хотя очевидно, что изменения, требующие таких корректировок, не соответствуют правилам SMIv2 для пересмотра модулей MIB (см. раздел 10 в [RFC2578]), в данном случае значительные издержки, связанные с отказом от этих изменений, являются достаточным основанием для отхода от правил. Следует подчеркнуть, что рабочая группа не смогла найти модулей MIB или управляющих приложений, для которых эти изменения имели негативное влияние.

3.2. Связи с другими MIB

Предполагается, что агенты, реализующие MAU-MIB, будут также реализовать (по меньшей мере) группу system, определенную в SNMPv2 MIB [RFC3418]. В следующих параграфах рассмотрены другие MIB, которые агенту следует реализовать.

3.2.1. Связь с Interfaces MIB

Параграфы этого документа, определяющие связанные с MAU объекты для интерфейсов, задают расширение Interfaces MIB [RFC2863]. Агент, реализующий относящийся к MAU интерфейса объект, должен также реализовать относящиеся к нему группы ifCompliance3 MODULE-COMPLIANCE из Interface MIB. Значение объекта ifMauIfIndex совпадает со значением ifIndex, используемым для создания экземпляра интерфейса, к которому подключен MAU.

От агентов требуется реализация объектов, связанных с MAU интерфейсов, в соответствии с заявлением dot3Compliance2 MODULE-COMPLIANCE в Interface MIB [RFC3635] для интерфейсов типа Ethernet. Кроме того, при использовании связанных с MAU объектов, используемых для управления 10GBASE-W PHY (т. е. когда ifMauType имеет значение dot3MauType10GigBaseW или иного варианта 10GBASE-W), агент должен также поддерживать Ethernet WAN Interface Sublayer (WIS) MIB [RFC3637] и должен следовать заданной там модели уровней для интерфейса. В данном случае значение объекта ifMauIfIndex совпадает со значением ifIndex для верхнего уровня стека, т. е. для записи ifTable, имеющей ifType = ethernetCsmacd(6). Если относящиеся к MAU интерфейса объекты используются для управления PHY, позволяющим динамически менять тип MAU, агенту нужно создать элементы ifTable, ifStackTable и ifInvStackTable, относящиеся к WIS, при замене ifMauDefaultType на вариант 10GBASE-W (т. е. dot3MauType10GigBaseW, dot3MauType10GigBaseEW, dot3MauType10GigBaseLW или dot3MauType10GigBaseSW) с другого типа и удалять относящиеся к WIS элементы при смене ifMauDefaultType на тип, не являющийся 10GBASE-W. Агенту нужно также изменить значения ifConnectorPresent и ifHighSpeed в записи ifTable с индексом ifMauIfIndex, как указано в [RFC3635] и [RFC3637] при таких манипуляциях с ifMauDefaultType, но не нужно делать этого при иных изменениях.

(Отметим, что порты повторителей не представляются интерфейсами в Interface MIB.)

3.2.2. Связь с модулем 802.3 Repeater MIB

Параграф этого документа, определяющий связанные с MAU повторителя объекты, задает расширение 802.3 Repeater MIB, определенного в [RFC2108]. Агент, реализующий такие объекты, должен также соответствовать заявлению snmpRptrModCompl в модуле 802.3 Repeater MIB.

Значения rpMauGroupIndex и rpMauPortIndex, используемые для создания экземпляра переменной MAU повторителя нужно делать совпадающими с rptrPortGroupIndex и rptrPortIndex, использованными для создания экземпляра порта, к которому присоединен данный MAU.

3.3. Управление встроенными MAU

В некоторых случаях MAU может быть «внутренним», т. е. вся функциональность будет реализована в самом устройстве. Например, управляемый повторитель может содержать внутренний MAU повторителя и/или интерфейса, через который проходят управляющие коммуникации, исходящие от одного из внешних портов повторителя для связи с агентом управления. Такие внутренние MAU могут (но не обязаны) быть управляемыми. Для управляемых MAU объекты, описывающие их атрибуты, должны присутствовать в подходящем субдереве MIB — dot3RpMauBasicGroup для внутренних MAU повторителя и dot3IfMauBasicGroup для внутренних MAU интерфейса.

3.4. Отображение управляемых объектов IEEE 802.3

В этом параграфе показано сопоставление объектов управления (атрибутов), определенных в разделе 30 [IEEE802.3], с объектами управления, определенными в этом документе.

Таблица 1. Сопоставление с объектами IEEE 802.3.

Управляемые объекты IEEE 802.3

Соответствующие объекты SNMP

oMAU

.aMAUID

rpMauIndex or ifMauIndex или broadMauIndex

.aMAUType

rpMauType или ifMauType

.aMAUTypeList

ifMauTypeListBits

.aMediaAvailable

rpMauMediaAvailable или ifMauMediaAvailable

.aLoseMediaCounter

rpMauMediaAvailableStateExits или ifMauMediaAvailableStateExits

.aJabber

rpMauJabberState и rpMauJabberingStateEnters или ifMauJabberState и ifMauJabberingStateEnters

.aMAUAdminState

rpMauStatus или ifMauStatus

.aBbMAUXmitRcvSplitType

broadMauXmtRcvSplitType

.aBroadbandFrequencies

broadMauXmtCarrierFreq и broadMauTranslationFreq

.aFalseCarriers

rpMauFalseCarriers или ifMauFalseCarriers

.acResetMAU

rpMauStatus или ifMauStatus

.acMAUAdminControl

rpMauStatus или ifMauStatus

.nJabber

rpMauJabberTrap или ifMauJabberTrap

oAutoNegotiation

.aAutoNegID

ifMauIndex

.aAutoNegAdminState

ifMauAutoNegAdminStatus

.aAutoNegRemoteSignalling

ifMauAutoNegRemoteSignalling

.aAutoNegAutoConfig

ifMauAutoNegConfig

.aAutoNegLocalTechnologyAbility

ifMauAutoNegCapabilityBits

.aAutoNegAdvertisedTechnologyAbility

ifMauAutoNegAdvertisedBits и ifMauAutoNegRemoteFaultAdvertised

.aAutoNegReceivedTechnologyAbility

ifMauAutoNegReceivedBits и ifMauAutoNegRemoteFaultReceived

.acAutoNegRestartAutoConfig

ifMauAutoNegRestart

.acAutoNegAdminControl

ifMauAutoNegAdminStatus

Ниже приведены управляемые объекты IEEE 802.3, которые не включены в MAU-MIB, с указанием причин исключения.

Таблица 2. Объекты управления IEEE 802.3, не включенные в MAU-MIB.

Управляемые объекты IEEE 802.3

Причина исключения

oMAU

.aIdleErrorCount

Полезно лишь для 100BaseT2, не получивших широкого распространения.

oAutoNegotiation

.aAutoNegLocalSelectorAbility

Требуется лишь для поддержки isoethernet (802.9a), не включенного в MAU-MIB.

.aAutoNegAdvertisedSelectorAbility

.aAutoNegReceivedSelectorAbility

3.5. Добавление новых типов MAU

3.5.1. dot3MauType

Идентификатор dot3MauType OBJECT IDENTIFIER и его определения OBJECT-IDENTITY перенесены из MAU-MIB в поддерживаемый IANA модуль IANA-MAU-MIB, первая версия которого опубликована в этом документе.

При определении нового IEEE 802.3 MAU агентство IANA может выпустить новую версию IANA-MAU-MIB с новым dot3MauType OBJECT-IDENTITY, соответствующим текстовым соглашением IANAifMauTypeListBits и, возможно, новыми значениями IANAifMauMediaAvailable, IANAifMauAutoNegCapBits и/или IANAifJackType.

Для добавления новых MAU, состояний Media Available, возможностей Auto Negotiation и/или разъемов (Jack) требуется процедура Expert Review, как указано в RFC 2434 [RFC2434].

В некоторых случаях для новых типов MAU могут требоваться новые управляемые объекты или могут возникать побочные эффекты в поведении имеющихся объектов. В таких случаях требуется также спецификация проекта стандарта (новый или пересмотренный документ). В таких документах требуется отметить особые свойства определяемого типа MAU (например, побочное влияние на ifStackTable как отмечено здесь для 10GBASE-W MAU).

3.5.2. IANAifMauTypeListBits

Синтаксис ifMauTypeListBits преобразован в текстовое соглашение, целочисленные перечисляемые значения теперь определены в текстовом соглашении IANAifMauTypeListBits и могут быть заданы заново (с дополнительными значениями при их определении в IEEE 802.3) в поддерживаемом IANA модуле MIB без выпуска новой версии этого документа.

3.5.3. IANAifMauMediaAvailable

Синтаксис ifMauMediaAvailable и rpMauMediaAvailable преобразован в текстовое соглашение, целочисленные перечисляемые значения теперь определены в текстовом соглашении IANAifMauMediaAvailable и могут быть заданы заново (с дополнительными значениями при их определении в IEEE 802.3) в поддерживаемом IANA модуле MIB без выпуска новой версии этого документа.

3.5.4. IANAifMauAutoNegCapBits

Синтаксис ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits и ifMauAutoNegCapReceivedBits преобразован в текстовое соглашение, целочисленные перечисляемые значения теперь определены в текстовом соглашении IANAifMauAutoNegCapBits и могут быть заданы заново (с дополнительными значениями при их определении в IEEE 802.3) в поддерживаемом IANA модуле MIB без выпуска новой версии этого документа.

3.5.5. JackType

Текстовое соглашение JackType было заменено IANAifJackType, определенным в поддерживаемом IANA модуле MIB, что позволяет добавлять новые типы разъемов (при их добавлении в IEEE 802.3) без смены версии этого документа.

4. Определение MAU MIB

   MAU-MIB DEFINITIONS ::= BEGIN

     IMPORTS
       Counter32, Integer32, Counter64,
       OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, mib-2
         FROM SNMPv2-SMI         -- RFC 2578
       TruthValue, AutonomousType, TEXTUAL-CONVENTION
         FROM SNMPv2-TC          -- RFC 2579
       OBJECT-GROUP, MODULE-COMPLIANCE, NOTIFICATION-GROUP
         FROM SNMPv2-CONF        -- RFC 2580
       InterfaceIndex
         FROM IF-MIB             -- RFC 2863
       IANAifMauTypeListBits, IANAifMauMediaAvailable,
       IANAifMauAutoNegCapBits, IANAifJackType
         FROM IANA-MAU-MIB
                          -- http://www.iana.org/assignments/ianamau-mib 
       ;

     mauMod MODULE-IDENTITY
       LAST-UPDATED "200704210000Z"  -- 21 апреля 2007 г.
       ORGANIZATION "IETF Ethernet Interfaces and Hub MIB Working Group"
       CONTACT-INFO
         "WG charter:
           http://www.ietf.org/html.charters/hubmib-charter.html 

         Mailing Lists:
           General Discussion: hubmib@ietf.org
           To Subscribe: hubmib-request@ietf.org
           In Body: subscribe your_email_address

          Chair: Bert Wijnen
         Postal: Alcatel-Lucent
                 Schagen 33
                 3461 GL Linschoten
                 Netherlands
          Phone: +31-348-407-775
          EMail: bwijnen@alcatel-lucent.com

         Editor: Edward Beili
         Postal: Actelis Networks Inc.
                 25 Bazel St., P.O.B. 10173
                 Petach-Tikva 10173
                 Israel
            Tel: +972-3-924-3491
          EMail: edward.beili@actelis.com"

       DESCRIPTION
         "Управляющая информация для 802.3 MAU.

         Ниже перечислены документы, упоминаемые в этом модуле MIB.

         [IEEE802.3] 
            IEEE Std 802.3, 2005 Edition: 'IEEE Standard for Information
            technology - Telecommunications and information exchange
            between systems - Local and metropolitan area networks -
            Specific requirements - Part 3: Carrier sense multiple
            access with collision detection (CSMA/CD) access method and
            physical layer specifications'.

            Особый интерес представляет раздел 30, 'Management'.

         Copyright (C) The IETF Trust (2007).
         Эта версия модуля MIB является частью RFC 4836, где правовые
         вопросы рассмотрены более полно."

       REVISION    "200704210000Z"  -- 21 апреля 2007 г.
       DESCRIPTION "Обновлены ссылки на поддерживаемые IANA текстовые
                   соглашения для типов MAU, состояния доступности среды,
                   возможностей автосогласования и типов разъемов вместо
                   использования внутренних определений.

                   Эта версия опубликована в RFC 4836."

       REVISION    "200309190000Z"  -- 19 сентября 2003 г.
       DESCRIPTION "Добавлена поддержка MAU 10 Гбит/с, которая
                   потребовала пересмотра.
                   - добавлены OBJECT-IDENTITY для MAU 10 Гбит/с;
                   - добавлен тип разъемой fiberLC в JackType;
                   - расширен набор ifMauTypeListBits для MAU 10 Гбит/с;
                   - добавлены значения в ifMauMediaAvailable и
                     обновлено описание с учетом поведения при 10 Гбит/с;
                   - добавлена 64-битовая версия ifMauFalseCarriers и
                     группа mauIfGrpHCStats;
                   - mauModIfCompl2 заменено на mauModIfCompl3 с новой группой.

                   Эта версия опубликована в RFC 3636."

       REVISION    "199908240400Z" — 24 августа 1999 г.
       DESCRIPTION "Эта версия опубликована в RFC 2668. Добавлена поддержка
                   MAU 1000 Мбит/с и согласование управления потоком данных."

       REVISION    "199710310000Z" — 31 октября 1997 г.
       DESCRIPTION "Эта версия опубликована в RFC 2239."

       REVISION    "199309300000Z" — 30 сентября 1993 г.
       DESCRIPTION "Исходная версия, опубликованная в RFC 1515."

       ::= { snmpDot3MauMgt 6 }

      snmpDot3MauMgt OBJECT IDENTIFIER ::= { mib-2 26 }

      -- Текстовые соглашения

      JackType ::= TEXTUAL-CONVENTION
        STATUS      deprecated
        DESCRIPTION "********* Отменено **********

                    Это TC было отменено с заменой на IANAifJackType.

                    Общие перечисляемые значения для типов разъемов
                    в MAU повторителей и интерфейсов."
        SYNTAX      INTEGER {
                              other(1),
                              rj45(2),
                              rj45S(3), -- rj45 с экраном
                              db9(4),
                              bnc(5),
                              fAUI(6),  -- розетка aui
                              mAUI(7),  -- вилка aui
                              fiberSC(8),
                              fiberMIC(9),
                              fiberST(10),
                              telco(11),
                              mtrj(12),  -- оптика MT-RJ
                              hssdc(13), -- оптический канал style-2
                              fiberLC(14)
                          }

      dot3RpMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 1 }
      dot3IfMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 2 }
      dot3BroadMauBasicGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 3 }

      -- OID в приведенной ниже ветви зарезервирован для
      -- IANA-MAU-MIB при назначении новых типов MAU:
      --                        { snmpDot3MauMgt 4 }

      dot3IfMauAutoNegGroup
          OBJECT IDENTIFIER ::= { snmpDot3MauMgt 5 }

      -- следующий OID является значением MODULE-IDENTITY 
      -- для этого модуля MIB:   { snmpDot3MauMgt 6 }

      --
      -- Таблица Basic Repeater MAU
      --

      rpMauTable OBJECT-TYPE
        SYNTAX      SEQUENCE OF RpMauEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION "Таблица с описанием и данными состояния для
                    MAU, подключенных к порту повторителя."
        ::= { dot3RpMauBasicGroup 1 }

      rpMauEntry OBJECT-TYPE
        SYNTAX      RpMauEntry
        MAX-ACCESS  not-accessible
        STATUS      current
        DESCRIPTION "Запись в таблице с данными для одного MAU."
        INDEX       { rpMauGroupIndex,
                      rpMauPortIndex,
                      rpMauIndex
                    }
        ::= { rpMauTable 1 }

      RpMauEntry ::=
        SEQUENCE {
            rpMauGroupIndex                     Integer32,
            rpMauPortIndex                      Integer32,
            rpMauIndex                          Integer32,
            rpMauType                           AutonomousType,
            rpMauStatus                         INTEGER,
            rpMauMediaAvailable                 IANAifMauMediaAvailable,
            rpMauMediaAvailableStateExits       Counter32,
            rpMauJabberState                    INTEGER,
            rpMauJabberingStateEnters           Counter32,
            rpMauFalseCarriers                  Counter32
      }

      rpMauGroupIndex OBJECT-TYPE
        SYNTAX      Integer32 (1..2147483647)
        MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                               -- это индекс SMIv1.
        STATUS      current
        DESCRIPTION "Уникальный идентификатор группы, содержащей порт,
                    к которому подключен описываемый записью MAU.

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

                    Группа, указанная конкретным значением этого объекта,
                    совпадает с группой с тем же значением в of rptrGroupIndex."
        REFERENCE   "RFC 2108, rptrGroupIndex."
        ::= { rpMauEntry 1 }

      rpMauPortIndex OBJECT-TYPE
        SYNTAX      Integer32 (1..2147483647)
        MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                               -- это индекс SMIv1.
        STATUS      current
        DESCRIPTION "Эта переменная однозначно указывает порт повторителя
                    в группе rpMauGroupIndex, к которому подключен MAU,
                    описываемый этой записью."
        REFERENCE   "RFC 2108, rptrPortIndex."
        ::= { rpMauEntry 2 }

      rpMauIndex OBJECT-TYPE
        SYNTAX      Integer32 (1..2147483647)
        MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                               -- это индекс SMIv1.
        STATUS      current
        DESCRIPTION " Эта переменная однозначно указывает MAU, описываемый
                    этой записью среди других MAU, подключенных к тому же
                    порту (rpMauPortIndex)."
        REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID."
        ::= { rpMauEntry 3 }

      rpMauType OBJECT-TYPE
        SYNTAX      AutonomousType
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION "Этот объект указывает типа MAU. Значения для стандартных
                    типов IEEE 802.3 MAU определены в поддерживаемом IANA
                    модуле IANA-MAU-MIB как OBJECT-IDENTITY типа dot3MauType.
                    Если тип MAU не известен, возвращается идентификатор
                    объекта zeroDotZero."
        REFERENCE   "[IEEE802.3], 30.5.1.1.2, aMAUType."
        ::= { rpMauEntry 4 }

      rpMauStatus OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          operational(3),
                          standby(4),
                          shutdown(5),
                          reset(6)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Текущее состояние MAU. Этот объект МОЖЕТ реализоваться
                      как read-only теми агентами и MAU, которые не поддерживают
                      программное управления состоянием MAU. Некоторые агенты могут 
                      не поддерживать установку для этого объекта некоторых
                      перечисляемых значения.

                      Значение other(1) возвращается, если MAU находится в
                      состоянии, отличном от 2 - 6.

                      Значение unknown(2) возвращается, когда состояние MAU
                      не известно (например, при инициализации).

                      MAU в состоянии operational(3) находится в рабочем
                      состоянии и передает сигналы подключенному DTE или
                      повторителю в соответствии со спецификацией.

                      MAU в состоянии standby(4) форсирует для DI и CI 
                      состояние idle, а для приемопередатчика idle или fault,
                      если они поддерживаются. Режим standby(4) применим лишь
                      для MAU канального типа. Состояние rpMauMediaAvailable 
                      не изменяется.

                      Для MAU в состоянии shutdown(5) предполагаются такие же
                      условия для DI, CI и приемопередатчика, как при 
                      отключении питания или отсоединении. MAU МОЖЕТ
                      возвращать значение other(1) для объектов
                      rpMauJabberState и rpMauMediaAvailable, когда
                      он находится в этом состоянии. Для AUI это
                      состояние будет отключать питание AUI.

                      Установка для этой переменной значения reset(6)
                      сбрасывает MAU как при отключении питания по 
                      меньшей мере на полсекунды с последующим включением.
                      От агента не требуется возврат значений reset(6).

                      Установка для этой переменной значения operational(3),
                      standby(4) или shutdown(5) приводит MAU в соответствующее
                      состояние, за исключением того, что перевод комбинированного 
                      MAU или AUI в состояние standby(4) будет выключать MAU."
          REFERENCE   "[IEEE802.3], 30.5.1.1.7, aMAUAdminState,
                      30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1,
                      acResetMAU."
          ::= { rpMauEntry 5 }

      rpMauMediaAvailable OBJECT-TYPE
          SYNTAX      IANAifMauMediaAvailable
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Этот объект указывает состояние Media Available в MAU,
                      дополнительно к rpMauStatus. Значения для стандартных
                      состояний IEEE 802.3 Media Available определены в
                      моддерживаемом IANA модуле IANA-MAU-MIB как 
                      IANAifMauMediaAvailable TC."
          REFERENCE   "[IEEE802.3], 30.5.1.1.4, aMediaAvailable."
          ::= { rpMauEntry 6 }

      rpMauMediaAvailableStateExits OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев, когда rpMauMediaAvailable для экземпляра 
                      MAU выходило из состояния available(3).

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением rptrMonitorPortLastChange."
          REFERENCE   "[IEEE802.3], 30.5.1.1.5, aLoseMediaCounter.
                      RFC 2108, rptrMonitorPortLastChange"
          ::= { rpMauEntry 7 }

      rpMauJabberState OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          noJabber(3),
                          jabbering(4)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение other(1) возвращается, если состояние jabber
                      отличается от 2, 3 или 4. Агент всегда ДОЛЖЕН возвращать
                      other(1) для MAU типа dot3MauTypeAUI.

                      Значение unknown(2) возвращается, если точное состояние
                      MAU не известно (например, при инициализации).

                      Если MAU не поддерживает jabbering, агент возвращает
                      noJabber(3). Это «нормальное» состояние.

                      Если MAU находится в состоянии jabber, агент возвращает 
                      значение jabbering(4)."
          REFERENCE "[IEEE802.3], 30.5.1.1.6, aJabber.jabberFlag."
          ::= { rpMauEntry 8 }

      rpMauJabberingStateEnters OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев, когда mauJabberState для этого экземпляра 
                      MAU было в состоянии jabbering(4). Для MAU типов
                      dot3MauTypeAUI, dot3MauType100BaseT4,
                      dot3MauType100BaseTX, dot3MauType100BaseFX и всех
                      типов 1000 Мбит/с этот счетчик всегда показывает 0.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением rptrMonitorPortLastChange."
          REFERENCE   "[IEEE802.3], 30.5.1.1.6, aJabber.jabberCounter.
                      RFC 2108, rptrMonitorPortLastChange"
          ::= { rpMauEntry 9 }

      rpMauFalseCarriers OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число связанных с несущей ложных событий в интервале
                      IDLE на каналах 100BASE-X. Этот счетчик не 
                      инкрементируется со скоростью символов. Он может
                      увеличиваться после корректной установки несущей с
                      максимальной скоростью 1 раз за 100 мсек до следующего
                      события, связанного с несущей.

                      Счетчик инкрементируется только для MAU типов 
                      dot3MauType100BaseT4, dot3MauType100BaseTX,
                      dot3MauType100BaseFX и всех типов 1000 Мбит/с.

                      Для остальных типов MAU счетчик всегда показывает 0.

                      Приблизительное минимальное время заполнения (rollover) 
                      счетчика составляет 7,4 часа.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением rptrMonitorPortLastChange."
          REFERENCE   "[IEEE802.3], 30.5.1.1.10, aFalseCarriers.
                      RFC 2108, rptrMonitorPortLastChange"
          ::= { rpMauEntry 10 }

      -- rpJackTable применяется к MAU, подключенным к повторителям, имеющим
      -- один или несколько внешних разъемов.

      rpJackTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF RpJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Информация о внешних разъемах, подключенных к
                      MAU, присоединенным к портам повторителя."
          ::= { dot3RpMauBasicGroup 2 }

      rpJackEntry OBJECT-TYPE
          SYNTAX      RpJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Запись с информацией о конкретном разъеме."
          INDEX       { rpMauGroupIndex,
                        rpMauPortIndex,
                        rpMauIndex,
                        rpJackIndex
                      }
          ::= { rpJackTable 1 }

      RpJackEntry ::=
          SEQUENCE {
              rpJackIndex                         Integer32,
              rpJackType                          IANAifJackType
          }

      rpJackIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Эта переменная однозначно указывает разъем, 
                      описанный данной записью, среди других разъемов
                      того же MAU (rpMauIndex)."
          ::= { rpJackEntry 1 }

      rpJackType OBJECT-TYPE
          SYNTAX      IANAifJackType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Тип разъема с внешней точки зрения."
          ::= { rpJackEntry 2 }

      --
      -- Таблица Basic Interface MAU
      --

      ifMauTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF IfMauEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Таблица с описаниями и статусом MAU, 
                      подключенных к интерфейсу."
          ::= { dot3IfMauBasicGroup 1 }

      ifMauEntry OBJECT-TYPE
          SYNTAX      IfMauEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Таблица с информацией об отдельном MAU."
          INDEX       { ifMauIfIndex,
                        ifMauIndex
                      }
          ::= { ifMauTable 1 }

      IfMauEntry ::=
          SEQUENCE {
              ifMauIfIndex                      InterfaceIndex,
              ifMauIndex                        Integer32,
              ifMauType                         AutonomousType,
              ifMauStatus                       INTEGER,
              ifMauMediaAvailable               IANAifMauMediaAvailable,
              ifMauMediaAvailableStateExits     Counter32,
              ifMauJabberState                  INTEGER,
              ifMauJabberingStateEnters         Counter32,
              ifMauFalseCarriers                Counter32,
              ifMauTypeList                     Integer32,
              ifMauDefaultType                  AutonomousType,
              ifMauAutoNegSupported             TruthValue,
              ifMauTypeListBits                 IANAifMauTypeListBits,
              ifMauHCFalseCarriers              Counter64
          }

      ifMauIfIndex OBJECT-TYPE
          SYNTAX      InterfaceIndex
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      current
          DESCRIPTION "Эта переменная однозначно указывает интерфейс, к
                      которому подключен описываемый записью MAU."
          REFERENCE   "RFC 2863, ifIndex"
          ::= { ifMauEntry 1 }

      ifMauIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      current
          DESCRIPTION "Переменная однозначно указывает MAU, описываемый
                      данной записью, среди других MAU того же
                      интерфейса (ifMauIfIndex)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID."
          ::= { ifMauEntry 2 }

      ifMauType OBJECT-TYPE
        SYNTAX      AutonomousType
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION "Этот объект указывает тип MAU. Значения для стандартных
                    типов IEEE 802.3 MAU определены в поддерживаемом IANA
                    модуле IANA-MAU-MIB как OBJECT-IDENTITY для dot3MauType.
                    Если тип MAU не известен, возвращается zeroDotZero.

                    Этот объект представляет операционный тип MAU, как определено 
                    1) результатом функции автосогласования или 2) значением
                    ifMauDefaultType, если автосогласование не реализовано 
                    или отключено для этого MAU. В случае 2) установка объекта
                    ifMauDefaultType будет переводить MAU в другой режим."
        REFERENCE   "[IEEE802.3], 30.5.1.1.2, aMAUType."
        ::= { ifMauEntry 3 }

      ifMauStatus OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          operational(3),
                          standby(4),
                          shutdown(5),
                          reset(6)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Текущее состояние MAU. Этот объект МОЖЕТ быть
                      открыт лишь для чтения теми агентами и MAU,
                      которые не поддерживают программного контроля
                      состояния MAU. Некоторые агенты могут не поддерживать
                      для этого объекта установку перечисляемых значений.

                      Значение other(1) возвращается, если состояние MAU 
                      отличается 2 - 6.

                      Значение unknown(2) возвращается, если точное состояние
                      MAU не известно (например, при инициализации).

                      MAU в состоянии operational(3) полностью работоспособен;
                      он функционирует и передает сигналы своему подключенному
                      DTE или порту повторителя в соответствии со спецификацией.

                      MAU в состоянии standby(4) переводит DI и CI в бездействие,
                      а приемопередатчик в бездействие или отказ, если это
                      поддерживается. Режим standby(4) применим лишь к MAU
                      канального типа. Состояние ifMauMediaAvailable не меняется.

                      MAU в состоянии shutdown(5) предполагает для DI, CI и 
                      приемопередатчика такие же условия, как при отключении
                      питания или отсоединении. MAU МОЖЕТ возвращать значение 
                      other(1) для объектов ifMauJabberState и ifMauMediaAvailable 
                      в таком состоянии. Для AUI это состояние будет отключать
                      удаленное питание от AUI.

                      Установка значения reset(6) сбрасывает MAU как при выключении
                      и последующем включении с задержкой не менее полсекунды. Агент
                      не обязан возвращать значение reset(6).

                      Установка значения operational(3), standby(4) или shutdown(5)
                      переводит MAU в соответствующее состояние, за исключением
                      установки комбинированных MAU или AUI в состояние
                      standby(4), переводящей MAU в состояние shutdown."
          REFERENCE   "[IEEE802.3], 30.5.1.1.7, aMAUAdminState,
                      30.5.1.2.2, acMAUAdminControl, and 30.5.1.2.1,
                      acResetMAU."
          ::= { ifMauEntry 4 }

      ifMauMediaAvailable OBJECT-TYPE
          SYNTAX      IANAifMauMediaAvailable
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Этот объект указывает состояние Media Available для
                      MAU в дополнение к ifMauStatus. Значения для 
                      стандартных состояний IEEE 802.3 Media Available 
                      определены в поддерживаемом IANA модуле IANA-MAU-MIB
                      как IANAifMauMediaAvailable TC."
          REFERENCE   "[IEEE802.3], 30.5.1.1.4, aMediaAvailable."
          ::= { ifMauEntry 5 }

      ifMauMediaAvailableStateExits OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев выхода ifMauMediaAvailable для
                      данного экземпляра MAU из состояния available(3).

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.5, aLoseMediaCounter.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 6 }

      ifMauJabberState OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          unknown(2),
                          noJabber(3),
                          jabbering(4)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение other(1) возвращается, если jabber
                      находится не в состоянии 2, 3 или 4. Агент ДОЛЖЕН
                      всегда возвращать other(1) для MAU типа dot3MauTypeAUI.

                      Значение unknown(2) возвращается, когда точное состояние 
                      MAU не известно (например, при инициализации).

                      Если MAU не поддерживает jabbering, агент возвращает
                      noJabber(3). Это «нормальное» состояние.

                      Если MAU находится в состоянии jabber, агент возвращает 
                      значение jabbering(4)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.6, aJabber.jabberFlag."
          ::= { ifMauEntry 7 }

      ifMauJabberingStateEnters OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число случаев, когда mauJabberState для этого экземпляра 
                      MAU было в состоянии jabbering(4). Этот счетчик всегда
                      показывает 0 для MAU типа dot3MauTypeAUI и всех типов
                      со скоростями выше 10 Мбит/с.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.6, aJabber.jabberCounter.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 8 }

      ifMauFalseCarriers OBJECT-TYPE
          SYNTAX      Counter32
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число связанных с несущей ложных событий в интервале
                      IDLE на каналах 100BASE-X и 1000BASE-X. 
                     
                      Для остальных типов MAU счетчик всегда показывает 0. 
                      Счетчик не инкрементируется со скоростью символов.

			  Счетчик может увеличиваться после корректной установки 
                      несущей с максимальной скоростью 1 раз за 100 мсек до 
                      следующего события CarrierEvent.

                      Счетчик может заполняться достаточно быстро. Станциям
                      управления рекомендуется опрашивать ifMauHCFalseCarriers 
                      вместо него для предотвращения потери данных.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.10, aFalseCarriers.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 9 }

      ifMauTypeList OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу ifMauTypeListBits.

                      Значение, однозначно указывающее набор возможных типов
                      IEEE 802.3 для данного MAU. Значение представляет собой
                      сумму, начальное значение которой равно 0. Затем 
                      для каждого типа возможности этого MAU, 2 возводится 
                      в степень, показанную ниже и добавляется к сумме.
                      Например, MAU с поддержкой лишь 10BASE-T будет иметь
                      значение 512 (29). MAU с поддержкой 10Base-T 
			  (полнодуплексный) и 100BASE-TX (полнодуплексный) будет
                      иметь значение 67584 (211 + 216).

                      Степени 2 для разных возможностей приведены ниже.

                      Степень  Возможность
                        0      прочие или неизвестные
                        1      AUI
                        2      10BASE-5
                        3      FOIRL
                        4      10BASE-2
                        5      10BASE-T, режим дуплекса не известен
                        6      10BASE-FP
                        7      10BASE-FB
                        8      10BASE-FL, режим дуплекса не известен
                        9      10BROAD36
                       10      10BASE-T, полудуплексный
                       11      10BASE-T, полнодуплексный
                       12      10BASE-FL, полудуплексный
                       13      10BASE-FL, полнодуплексный
                       14      100BASE-T4
                       15      100BASE-TX, полудуплексный
                       16      100BASE-TX, полнодуплексный
                       17      100BASE-FX, полудуплексный
                       18      100BASE-FX, полнодуплексный
                       19      100BASE-T2, полудуплексный
                       20      100BASE-T2, полнодуплексный

                      При наличии в MAU автосогласования этот объект
                      будет отображаться на ifMauAutoNegCapability."
          ::= { ifMauEntry 10 }

      ifMauDefaultType OBJECT-TYPE
          SYNTAX      AutonomousType
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Этот объект указывает принятый по умолчанию 
                      административный тип baseband MAU, используемый вместе 
                      с операционным типом MAU, указанным ifMauType.

                      Набор возможных значений этого объекта совпадает с
                      набором значения, определенных для ifMauType.

                      Этот объект представляет задаваемый административно 
                      тип MAU. Если автосогласование не включено или не
                      реализовано для MAU, значение этого объекта задает
                      рабочий тип MAU. В этом случае установка объекта 
                      будет переводить MAU в соответствующий режим.

                      При реализованном и включенном автосогласовании для
                      MAU рабочий тип MAU определяется автоматически и
                      значение этого объекта указывает тип, автоматически
                      выбираемый для MAU при последующем отключении
                      автосогласования.

                      Примечание для разработчиков. Может потребоваться
                      реализация для оборудования, которое не точно
                      соответствует описанному выше поведению. В частности,
                      при выключении ifMauAutoNegAdminStatus реализация
                      агента ДОЛЖНА обеспечить корректную смену рабочего
                      типа MAU (указывается ifMauType) к заданному этим
                      объектом вместо прожолжения работы в прежнем режиме, 
                      определенном автоматически."
          REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID, and 22.2.4.1.4."
          ::= { ifMauEntry 11 }

      ifMauAutoNegSupported OBJECT-TYPE
          SYNTAX      TruthValue
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Этот объект показывает поддержку автосогласования в MAU."
          ::= { ifMauEntry 12 }

      ifMauTypeListBits OBJECT-TYPE
          SYNTAX      IANAifMauTypeListBits
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможных
                      типов IEEE 802.3, которые может иметь MAU. При
                      наличии автосогласования на MAU этот объект 
                      будет отображаться на ifMauAutoNegCapabilityBits.

                      Отметим, что MAU может оказаться способным работать 
                      как MAU, тип которого отсутствует в этом MIB. Это
  			  указывается возвратом бита bOther в дополнение к 
                      битам стандартных возможностей, перечисленным в 
                      IANAifMauTypeListBits TC."
          ::= { ifMauEntry 13 }

      ifMauHCFalseCarriers OBJECT-TYPE
          SYNTAX      Counter64
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Число связанных с несущей ложных событий в интервале
                      IDLE на каналах 100BASE-X и 1000BASE-X links.

                      Для остальных типов MAU счетчик всегда показывает 0. 
                      Счетчик не инкрементируется со скоростью символов.

                      Этот счетчик является 64-битовой версией счетчика
                      ifMauFalseCarriers. Поскольку 32-битовый счетчик 
                      может переполняться достаточно быстро, станциям
                      управления рекомендуется опрашивать 64-битовый 
                      счетчик для предотвращения потери данных.

                      Разрывы в значении этого счетчика могут приводить к
                      повторной инициализации системы управления, как указано
                      значением ifCounterDiscontinuityTime."
          REFERENCE   "[IEEE802.3], 30.5.1.1.10, aFalseCarriers.
                      RFC 2863, ifCounterDiscontinuityTime."
          ::= { ifMauEntry 14 }

      -- ifJackTable применяется к MAU, подключенных к интерфейсам с одним или
      -- несколькими внешними разъемами.

      ifJackTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF IfJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Информация о внешних разъемах MAU, подключенных к интерфейсу."
          ::= { dot3IfMauBasicGroup 2 }

      ifJackEntry OBJECT-TYPE
          SYNTAX      IfJackEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Запись с информацией о конкретном разъеме."
          INDEX       { ifMauIfIndex,
                        ifMauIndex,
                        ifJackIndex
                      }
          ::= { ifJackTable 1 }

      IfJackEntry ::=
          SEQUENCE {
              ifJackIndex                         Integer32,
              ifJackType                          IANAifJackType
          }

      ifJackIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Эта переменная однозначно указывает описываемый
                      записью разъем среди других разъемов того же MAU."
          ::= { ifJackEntry 1 }

      ifJackType OBJECT-TYPE
          SYNTAX      IANAifJackType
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Тип разъема с внешней точки зрения."
          ::= { ifJackEntry 2 }

      --
      -- Таблица автосогласования MAU
      --

      ifMauAutoNegTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF IfMauAutoNegEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Объекты конфигурации и состояния для функции
                      автосогласования MAU, подключенных к интерфейсам.

                      ifMauAutoNegTable применяется к системам, в которых
                      автосогласование поддерживается на одном или множестве
                      MAU, подключенных к интерфейсам. Отметим, что при 
                      имеющемся и включенном автосогласовании объект
                      ifMauType отражает результат функции согласования."
          ::= { dot3IfMauAutoNegGroup 1 }

      ifMauAutoNegEntry OBJECT-TYPE
          SYNTAX      IfMauAutoNegEntry
          MAX-ACCESS  not-accessible
          STATUS      current
          DESCRIPTION "Запись таблицы с данными конфигурации и состояния 
                      для функции автосогласования отдельного MAU."
          INDEX       { ifMauIfIndex,
                        ifMauIndex
                      }
          ::= { ifMauAutoNegTable 1 }

      IfMauAutoNegEntry ::=
          SEQUENCE {
              ifMauAutoNegAdminStatus           INTEGER,
              ifMauAutoNegRemoteSignaling       INTEGER,
              ifMauAutoNegConfig                INTEGER,
              ifMauAutoNegCapability            Integer32,
              ifMauAutoNegCapAdvertised         Integer32,
              ifMauAutoNegCapReceived           Integer32,
              ifMauAutoNegRestart               INTEGER,
              ifMauAutoNegCapabilityBits        IANAifMauAutoNegCapBits,
              ifMauAutoNegCapAdvertisedBits     IANAifMauAutoNegCapBits,
              ifMauAutoNegCapReceivedBits       IANAifMauAutoNegCapBits,
              ifMauAutoNegRemoteFaultAdvertised INTEGER,
              ifMauAutoNegRemoteFaultReceived   INTEGER
          }

      ifMauAutoNegAdminStatus OBJECT-TYPE
          SYNTAX      INTEGER {
                          enabled(1),
                          disabled(2)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Установка значения enabled(1) будет включать
                      автосогласование на поддерживающем его интерфейсе.

                      При значении disabled(2) интерфейс будет работать 
                      как при отсутствии сигналов автосогласования. В
                      таких условиях IEEE 802.3 MAU будет незамедлительно
                      переходить в состояние, заданное ifMauDefaultType.

                      Примечание для разработчиков. При переходе
                      ifMauAutoNegAdminStatus из включенного состояния в
                      выключенное реализация агента ДОЛЖНА обеспечить
                      переключение рабочего типа MAU (указываемого в
                      ifMauType) к значению, заданному ifMauDefaultType,
                      вместо продолжения работы в прежнем режиме, 
                      определенном автоматически."
          REFERENCE   "[IEEE802.3], 30.6.1.1.2, aAutoNegAdminState,
                      and 30.6.1.2.2, acAutoNegAdminControl."
          ::= { ifMauAutoNegEntry 1 }

      ifMauAutoNegRemoteSignaling OBJECT-TYPE
          SYNTAX      INTEGER {
                          detected(1),
                          notdetected(2)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, которое показывает, используются ли на
                      удаленной стороне сигналы автосогласования. Переменная
                      принимает значение detected(1) тогда и только тогда,
                      когда при предыдущем согласовании канала были приняты 
                      сигналы FLP Burst."
          REFERENCE   "[IEEE802.3], 30.6.1.1.3,
                      aAutoNegRemoteSignaling."
          ::= { ifMauAutoNegEntry 2 }

      ifMauAutoNegConfig OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          configuring(2),
                          complete(3),
                          disabled(4),
                          parallelDetectFail(5)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, показывающее текущий статус процесса
                      автосогласования. Значение parallelDetectFail(5) 
                      отображается на отказ при параллельном детектировании, 
                      как определено в параграфе 28.2.3.1 [IEEE802.3]."
          REFERENCE   "[IEEE802.3], 30.6.1.1.4, aAutoNegAutoConfig."
          ::= { ifMauAutoNegEntry 4 }

      ifMauAutoNegCapability OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу 
                      ifMauAutoNegCapabilityBits.

                      Значение, однозначно указывающее набор возможностей
                      локального элемента автосогласования. Значение 
                      является суммой, которая исходно равна 0. Далее для
                      каждой поддерживаемой интерфейсом возможности число 2
                      возводится в соответствующую степень и добавляется к
                      сумме. Например, интерфейс, поддерживающий лишь 
                      полнодуплексный режим 100Base-TX, будет иметь значение
                      32768 (215). Аналогичный интерфейс, поддерживающий 
                      полудуплексный и полнодуплексный режим 100Base-TX,
                      будет иметь значение 98304 (215 + 216).

                      Степени 2 для возможностей перечислены ниже.

                      Степень   Возможность
                        0       прочие и неизвестные 
                       (1-9)    (резерв)
                       10       10BASE-T, полудуплексный режим
                       11       10BASE-T, полнодуплексный режим
                       12       (резерв)
                       13       (резерв)
                       14       100BASE-T4
                       15       100BASE-TX, полудуплексный режим
                       16       100BASE-TX, полнодуплексный режим
                       17       (резерв)
                       18       (резерв)
                       19       100BASE-T2, полудуплексный режим
                       20       100BASE-T2, полнодуплексный режим

                      Отметим, что поддерживающие MIB интерфейсы могут
                      иметь возможности, выходящие за рамки этого MIB."
          REFERENCE   "[IEEE802.3], 30.6.1.1.5,
                      aAutoNegLocalTechnologyAbility."
          ::= { ifMauAutoNegEntry 5 }

      ifMauAutoNegCapAdvertised OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-write
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу 
                      ifMauAutoNegCapAdvertisedBits.

                      Значение, однозначно указывающее набор возможностей,
                      анонсируемый локальным элементом автосогласования.
                      Возможные значения этого объекта приведены в 
                      описании ifMauAutoNegCapability.

                      Возможности из этого объекта, не указанные в 
                      ifMauAutoNegCapability, не могут быть включены."
          REFERENCE   "[IEEE802.3], 30.6.1.1.6,
                      aAutoNegAdvertisedTechnologyAbility."
          ::= { ifMauAutoNegEntry 6 }

      ifMauAutoNegCapReceived OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      От этого объекта отказались в пользу
                      ifMauAutoNegCapReceivedBits.

                      Значение, однозначно указывающее набор возможностей,
                      полученный от удаленного элемента автосогласования.
                      Возможные значения этого объекта приведены в 
                      описании ifMauAutoNegCapability.

                      Отметим, что интерфейсы, поддерживающие этот MIB,
                      могут быть подключены к удаленным элементам 
                      автосогласования, возможности которых выходят 
                      за рамки этого MIB."
          REFERENCE   "[IEEE802.3], 30.6.1.1.7,
                      aAutoNegReceivedTechnologyAbility."
          ::= { ifMauAutoNegEntry 7 }

      ifMauAutoNegRestart OBJECT-TYPE
          SYNTAX      INTEGER {
                          restart(1),
                          norestart(2)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Если этот объект имеет значение restart(1), это
                      будет форсировать начало повторного автосогласования
                      для канала. Если сигналы автосогласования отключены,
                      значение этого объекта не играет роли. 
                      Установка значения norestart(2) не дает эффекта."
          REFERENCE   "[IEEE802.3], 30.6.1.2.1, acAutoNegRestartAutoConfig."
          ::= { ifMauAutoNegEntry 8 }

      ifMauAutoNegCapabilityBits OBJECT-TYPE
          SYNTAX      IANAifMauAutoNegCapBits
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможностей
                      локального элемента автосогласования. Отметим, что
                      интерфейсы, поддерживающие этот MIB, могут иметь
                      возможности, выходящие за рамки этого MIB.

                      Отметим, что локальный элемент автосогласования
                      может поддерживать возможности, выходящие за рамки
                      этого MIB. Это указывается возвратом бита bOther 
                      в дополнение к битам стандартных возможностей, 
                      указанных в IANAifMauAutoNegCapBits TC."
          REFERENCE   "[IEEE802.3], 30.6.1.1.5, aAutoNegLocalTechnologyAbility."
          ::= { ifMauAutoNegEntry 9 }

      ifMauAutoNegCapAdvertisedBits OBJECT-TYPE
          SYNTAX      IANAifMauAutoNegCapBits
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможностей,
                      анонсируемый локальным элементом автосогласования.
                      Возможные значения этого объекта приведены в 
                      описании ifMauAutoNegCapability.

                      Возможности из этого объекта, не указанные в 
                      ifMauAutoNegCapabilityBits, не могут быть включены.

                      Отметим, что локальный элемент автосогласования
                      может поддерживать возможности, выходящие за рамки
                      этого MIB. Это указывается возвратом бита bOther 
                      в дополнение к битам стандартных возможностей, 
                      указанных в IANAifMauAutoNegCapBits TC."
          REFERENCE   "[IEEE802.3], 30.6.1.1.6,
                      aAutoNegAdvertisedTechnologyAbility."
          ::= { ifMauAutoNegEntry 10 }

      ifMauAutoNegCapReceivedBits OBJECT-TYPE
          SYNTAX      IANAifMauAutoNegCapBits
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, однозначно указывающее набор возможностей,
                      полученный от удаленного элемента автосогласования.
                      Отметим, что локальный элемент автосогласования
                      может поддерживать возможности, выходящие за рамки
                      этого MIB. Это указывается возвратом бита bOther 
                      в дополнение к битам стандартных возможностей, 
                      указанных в IANAifMauAutoNegCapBits TC."
          REFERENCE   "[IEEE802.3], 30.6.1.1.7,
                      aAutoNegReceivedTechnologyAbility."
          ::= { ifMauAutoNegEntry 11 }

      ifMauAutoNegRemoteFaultAdvertised OBJECT-TYPE
          SYNTAX      INTEGER {
                          noError(1),
                          offline(2),
                          linkFailure(3),
                          autoNegError(4)
                      }
          MAX-ACCESS  read-write
          STATUS      current
          DESCRIPTION "Значение, указывающее все индикации локальных 
                      отказов, которые данный MAU обнаружил и будет 
                      анонсировать при следующем автосогласовании для 
                      MAU 1000 Мбит/с."
          REFERENCE   "[IEEE802.3], 30.6.1.1.6,
                      aAutoNegAdvertisedTechnologyAbility."
          ::= { ifMauAutoNegEntry 12 }

      ifMauAutoNegRemoteFaultReceived OBJECT-TYPE
          SYNTAX      INTEGER {
                          noError(1),
                          offline(2),
                          linkFailure(3),
                          autoNegError(4)
                      }
          MAX-ACCESS  read-only
          STATUS      current
          DESCRIPTION "Значение, указывающее все индикации, принятые
                      от удаленной стороны канала локальным элементом
                      автосогласования для MAU 1000 Мбит/с."
          REFERENCE   "[IEEE802.3], 30.6.1.1.7,
                      aAutoNegReceivedTechnologyAbility."
          ::= { ifMauAutoNegEntry 13 }

      --
      -- Таблица базовых Broadband MAU
      --

      broadMauBasicTable OBJECT-TYPE
          SYNTAX      SEQUENCE OF BroadMauBasicEntry
          MAX-ACCESS  not-accessible
          STATUS      deprecated
          DESCRIPTION "********* Отменена **********

                      Эта таблица отменена полностью. Реализаций таблицы
                      не было известно и не очевидно, что они были. IEEE
                      рекомендует не применять эти типы MAU в новых сетях.

                      Таблица описаний и данных состояния для broadband 
                      MAU, присоединенных к интерфейсам."
          ::= { dot3BroadMauBasicGroup 1 }

      broadMauBasicEntry OBJECT-TYPE
          SYNTAX      BroadMauBasicEntry
          MAX-ACCESS  not-accessible
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Запись таблицы с информацией об одном broadband MAU."
          INDEX       { broadMauIfIndex,
                        broadMauIndex
                      }
          ::= { broadMauBasicTable 1 }

      BroadMauBasicEntry ::=
          SEQUENCE {
              broadMauIfIndex                     InterfaceIndex,
              broadMauIndex                       Integer32,
              broadMauXmtRcvSplitType             INTEGER,
              broadMauXmtCarrierFreq              Integer32,
              broadMauTranslationFreq             Integer32
          }

      broadMauIfIndex OBJECT-TYPE
          SYNTAX      InterfaceIndex
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Отднозначно указывает интерфейс, с которым соединен
                      описываемый этой записью MAU."
          REFERENCE   "RFC 2863, ifIndex."
          ::= { broadMauBasicEntry 1 }

      broadMauIndex OBJECT-TYPE
          SYNTAX      Integer32 (1..2147483647)
          MAX-ACCESS  read-only  -- только чтение, поскольку изначально 
                                 -- это индекс SMIv1.
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Однозначно указывает MAU, подключенный к интерфейсу
                      broadMauIfIndex описываемому этой записью."
          REFERENCE   "[IEEE802.3], 30.5.1.1.1, aMAUID."
          ::= { broadMauBasicEntry 2 }

      broadMauXmtRcvSplitType OBJECT-TYPE
          SYNTAX      INTEGER {
                          other(1),
                          single(2),
                          dual(3)
                      }
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Указывает тип частотного мультиплексирования/
                      кабельной системы, используемый для разделения
                      путей передачи и приема 10BROAD36 MAU.

                      Значение other(1) возвращается в случаях, когда 
                      тип разделения не является ни single, ни dual.

                      Значение single(2) указывает систему с одним кабелем,
                      dual(3) — систему с двумя кабелями (смещение обычно 0)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.8, aBbMAUXmitRcvSplitType."
          ::= { broadMauBasicEntry 3 }

      broadMauXmtCarrierFreq OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Эта переменная указывает частоту передатчика 
                      10BROAD36 MAU в ¼ МГц (т. е. 250 КГц)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.9,
                      aBroadbandFrequencies.xmitCarrierFrequency."
          ::= { broadMauBasicEntry 4 }

      broadMauTranslationFreq OBJECT-TYPE
          SYNTAX      Integer32
          MAX-ACCESS  read-only
          STATUS      deprecated
          DESCRIPTION "********* Отменен **********

                      Эта переменная указывает смещение частоты приемника 
                      10BROAD36 MAU в ¼ МГц (т. е. 250 Кгц)."
          REFERENCE   "[IEEE802.3], 30.5.1.1.9,
                      aBroadbandFrequencies.translationFrequency."
          ::= { broadMauBasicEntry 5 }

      -- Nуведомления для использования 802.3 MAU

      snmpDot3MauTraps OBJECT IDENTIFIER ::= { snmpDot3MauMgt 0 }

      rpMauJabberTrap NOTIFICATION-TYPE
          OBJECTS     { rpMauJabberState }
          STATUS      current
          DESCRIPTION "Это уведомление передается при переходе
                      управляемого MAU повторителя в состояние jabber.

                      Агент ДОЛЖЕН тормозить (дросселировать) генерацию 
                      последовательных rpMauJabberTraps так, чтобы интервал
                      между ними был не менее 5 секунд."
          REFERENCE   "[IEEE802.3], 30.5.1.3.1, nJabber notification."
          ::= { snmpDot3MauTraps 1 }

      ifMauJabberTrap NOTIFICATION-TYPE
          OBJECTS     { ifMauJabberState }
          STATUS      current
          DESCRIPTION "Это уведомление передается при переходе
                      управляемого MAU повторителя в состояние jabber.

                      Агент ДОЛЖЕН тормозить (дросселировать) генерацию 
                      последовательных ifMauJabberTraps так, чтобы интервал
                      между ними был не менее 5 секунд."

          REFERENCE   "[IEEE802.3], 30.5.1.3.1, nJabber notification."
          ::= { snmpDot3MauTraps 2 }

      -- Информация о соответствии

      mauModConf
              OBJECT IDENTIFIER ::= { mauMod 1 }
        mauModCompls
              OBJECT IDENTIFIER ::= { mauModConf 1 }
        mauModObjGrps
              OBJECT IDENTIFIER ::= { mauModConf 2 }
        mauModNotGrps
              OBJECT IDENTIFIER ::= { mauModConf 3 }

      -- Object groups

      mauRpGrpBasic OBJECT-GROUP
          OBJECTS     { rpMauGroupIndex,
                        rpMauPortIndex,
                        rpMauIndex,
                        rpMauType,
                        rpMauStatus,
                        rpMauMediaAvailable,
                        rpMauMediaAvailableStateExits,
                        rpMauJabberState,
                        rpMauJabberingStateEnters
                      }
          STATUS      current
          DESCRIPTION "Базовая группа соответствия для MAU, подключенных
                      к портам повторителя. Эта группа служит также
                      спецификацией соответствия для реализаций RFC 1515."
          ::= { mauModObjGrps 1 }

      mauRpGrp100Mbs OBJECT-GROUP
          OBJECTS     { rpMauFalseCarriers }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, подключенных к портам
                      повторителя со скоростью не менее 100 Мбит/с."
          ::= { mauModObjGrps 2 }

      mauRpGrpJack OBJECT-GROUP
          OBJECTS     { rpJackType }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, подключенных к портам
                      повторителя, с возможностью выбора разъема."
          ::= { mauModObjGrps 3 }

      mauIfGrpBasic OBJECT-GROUP
          OBJECTS     { ifMauIfIndex,
                        ifMauIndex,
                        ifMauType,
                        ifMauStatus,
                        ifMauMediaAvailable,
                        ifMauMediaAvailableStateExits,
                        ifMauJabberState,
                        ifMauJabberingStateEnters
                      }
          STATUS      current
          DESCRIPTION "Базовая группа соответствия для MAU, подключенных
                      к интерфейсам. Interfaces. Эта группа служит также
                      спецификацией соответствия для реализаций RFC 1515."
          ::= { mauModObjGrps 4 }

      mauIfGrp100Mbs OBJECT-GROUP
          OBJECTS     { ifMauFalseCarriers,
                        ifMauTypeList,
                        ifMauDefaultType,
                        ifMauAutoNegSupported
                      }

          STATUS      deprecated
          DESCRIPTION "********* Отменена **********

                      Группа соответствия для MAU, подключенных к
                      интерфейсам, поддерживающим 100 Мбит/с.

                      От этой группы отказались в пользу 
                      mauIfGrpHighCapacity."
          ::= { mauModObjGrps 5 }

      mauIfGrpJack OBJECT-GROUP
          OBJECTS     { ifJackType }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, подключенных к
                      интерфейсам с возможностью выбора разъема."
          ::= { mauModObjGrps 6 }

      mauIfGrpAutoNeg OBJECT-GROUP
          OBJECTS     { ifMauAutoNegAdminStatus,
                        ifMauAutoNegRemoteSignaling,
                        ifMauAutoNegConfig,
                        ifMauAutoNegCapability,
                        ifMauAutoNegCapAdvertised,
                        ifMauAutoNegCapReceived,
                        ifMauAutoNegRestart
                      }
          STATUS      deprecated
          DESCRIPTION "********* Отменена **********

                      Группа соответствия для MAU, подключенных
                      к интерфейсам с управляемым автосогласованием.

                      От этой группы отказались в пользу 
                      mauIfGrpAutoNeg2."
          ::= { mauModObjGrps 7 }

      mauBroadBasic OBJECT-GROUP
          OBJECTS     { broadMauIfIndex,
                        broadMauIndex,
                        broadMauXmtRcvSplitType,
                        broadMauXmtCarrierFreq,
                        broadMauTranslationFreq
                      }
          STATUS      deprecated
          DESCRIPTION "********* Отменена **********
                      Группа соответствия для broadband MAU, подключенных
                      К интерфейсам.

                      Эта группа отменена. О реализациях ее ничего не
                      известно, а реализация в будущем не очевидна."
          ::= { mauModObjGrps 8 }

      mauIfGrpHighCapacity OBJECT-GROUP
          OBJECTS     { ifMauFalseCarriers,
                        ifMauTypeListBits,
                        ifMauDefaultType,
                        ifMauAutoNegSupported
                      }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, присоединенных к 
                      интерфейсу с поддержкой не менее 100 Мбит/с."
          ::= { mauModObjGrps 9 }

      mauIfGrpAutoNeg2 OBJECT-GROUP
          OBJECTS     { ifMauAutoNegAdminStatus,
                        ifMauAutoNegRemoteSignaling,
                        ifMauAutoNegConfig,
                        ifMauAutoNegCapabilityBits,
                        ifMauAutoNegCapAdvertisedBits,
                        ifMauAutoNegCapReceivedBits,
                        ifMauAutoNegRestart
                      }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU, присоединенных к 
                      интерфейсу с поддержкой управляемого автосогласования."
          ::= { mauModObjGrps 10 }

      mauIfGrpAutoNeg1000Mbps OBJECT-GROUP
          OBJECTS     { ifMauAutoNegRemoteFaultAdvertised,
                        ifMauAutoNegRemoteFaultReceived
                      }
          STATUS      current
          DESCRIPTION "Группа соответствия для MAU 1000 Мбит/с, присоединенных к 
                      интерфейсу с поддержкой управляемого автосогласования."
          ::= { mauModObjGrps 11 }

      mauIfGrpHCStats OBJECT-GROUP
          OBJECTS     { ifMauHCFalseCarriers }
          STATUS      current
          DESCRIPTION "Соответствие для высокоскоростной статистики 
                      MAU, присоединенных к интерфейсам."
          ::= { mauModObjGrps 12 }

      -- Группа уведомлений

      rpMauNotifications NOTIFICATION-GROUP
          NOTIFICATIONS { rpMauJabberTrap }
          STATUS      current
          DESCRIPTION "Уведомления для MAU повторителя."
          ::= { mauModNotGrps 1 }

      ifMauNotifications NOTIFICATION-GROUP
          NOTIFICATIONS { ifMauJabberTrap }
          STATUS      current
          DESCRIPTION "Уведомления для MAU интерфейса."
          ::= { mauModNotGrps 2 }

      -- Compliances

      mauModRpCompl MODULE-COMPLIANCE
          STATUS      deprecated
          DESCRIPTION "******** Отменено ********
                      Соответствие для MAU, подключенных к портам
                      повторителя.

                      Это соответствие отменено с заменой на 
                      mauModRpCompl2 для большего контроля, позволяющего
                      открывать rpMauStatus только для чтения."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauRpGrpBasic }

              GROUP       mauRpGrp100Mbs
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauRpGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       rpMauNotifications
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU, подключенных к портам повторителя."
          ::= { mauModCompls 1 }

      mauModIfCompl MODULE-COMPLIANCE
          STATUS      deprecated
          DESCRIPTION "******** Отменено ********

                      Соответствие для MAU, подключенных к интерфейсам.
                      Этот соответствие отменено с заменой на mauModIfCompl2."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauIfGrpBasic }

              GROUP       mauIfGrp100Mbs
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauIfGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       mauIfGrpAutoNeg
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой управляемого автосогласования."

              GROUP       mauBroadBasic
              DESCRIPTION "Реализация этой группы обязательна для
                          broadband MAUs."

              GROUP       ifMauNotifications
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU, подключенных к интерфейсам."
          ::= { mauModCompls 2 }

      mauModIfCompl2 MODULE-COMPLIANCE
          STATUS      deprecated
          DESCRIPTION "******** Отменено ********

                      Соответствие для MAU, подключенных к интерфейсам.

                      Этот соответствие отменено с заменой на mauModIfCompl3."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauIfGrpBasic }

              GROUP       mauIfGrpHighCapacity
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauIfGrpJack

              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       mauIfGrpAutoNeg2
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой управляемого автосогласования."

              GROUP       mauIfGrpAutoNeg1000Mbps
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой скорости 100 Мбит/с и выше, а также
                          управляемого автосогласования.

              GROUP       ifMauNotifications
              DESCRIPTION "Реализация этой группы рекомендуется
                          для MAU, подключенных к интерфейсам."

              OBJECT      ifMauStatus
              MIN-ACCESS  read-only
              DESCRIPTION "Возможность записи не требуется."
          ::= { mauModCompls 3 }

      mauModRpCompl2 MODULE-COMPLIANCE
          STATUS      current
          DESCRIPTION "Соответствие для MAU, подключенных к портам повторителя.

                      Отметим, что это требует соответствия заявлению
                      snmpRptrModCompl MODULE-COMPLIANCE в
                      SNMP-REPEATER-MIB (RFC 2108)."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauRpGrpBasic }

              GROUP       mauRpGrp100Mbs
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauRpGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       rpMauNotifications

              DESCRIPTION "Реализация этой группы рекомендуется
                          для MAU, подключенных к портам повторителя."

              OBJECT      rpMauStatus
              MIN-ACCESS  read-only
              DESCRIPTION "Возможность записи не требуется."
          ::= { mauModCompls 4 }

      mauModIfCompl3 MODULE-COMPLIANCE
          STATUS      current
          DESCRIPTION "Соответствие для MAU, подключенных к интерфейсам.

                      Отметим, что это требует соответствия заявлению
                      ifCompliance3 MODULE-COMPLIANCE в IF-MIB (RFC 2863)
                      и dot3Compliance2 MODULE-COMPLIANCE в
                      EtherLike-MIB (RFC3635)."

          MODULE — данный модуль
              MANDATORY-GROUPS { mauIfGrpBasic }

              GROUP       mauIfGrpHighCapacity
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой скорости 100 Мбит/с и выше."

              GROUP       mauIfGrpHCStats
              DESCRIPTION "Реализация этой группы обязательна рекомендуется
                          для MAU с поддержкой скорости 1000 Мбит/с и
                          рекомендуется для 100 Мбит/с.

              GROUP       mauIfGrpJack
              DESCRIPTION "Реализация этой необязательной группы рекомендуется
                          для MAU с поддержкой одного или нескольких внешних
                          разъемов."

              GROUP       mauIfGrpAutoNeg2
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой управляемого автосогласования."

              GROUP       mauIfGrpAutoNeg1000Mbps
              DESCRIPTION "Реализация этой группы обязательна для MAU с 
                          поддержкой скорости 1000 Мбит/с и выше, а также
                          управляемого автосогласования"

              GROUP       ifMauNotifications
              DESCRIPTION "Реализация этой группы рекомендуется для
                          MAU, подключенных к интерфейсам."

              OBJECT      ifMauStatus
              MIN-ACCESS  read-only
              DESCRIPTION "Возможность записи не требуется."
          ::= { mauModCompls 5 }

   END

5. Администрируемые IANA определения MAU TC

   IANA-MAU-MIB DEFINITIONS ::= BEGIN

     IMPORTS
       MODULE-IDENTITY, OBJECT-IDENTITY, mib-2
         FROM SNMPv2-SMI
       TEXTUAL-CONVENTION
         FROM SNMPv2-TC
       ;

     ianaMauMIB MODULE-IDENTITY
       LAST-UPDATED "200704210000Z"  -- 21 апреля 2007 г.
       ORGANIZATION "IANA"
       CONTACT-INFO "        Internet Assigned Numbers Authority

                     Postal: ICANN
                             4676 Admiralty Way, Suite 330
                             Marina del Rey, CA 90292

                        Tel: +1-310-823-9358
                      EMail: iana@iana.org"

       DESCRIPTION
         "Этот модуль MIB определяет dot3MauType OBJECT-IDENTITY и
         текстовые соглашения IANAifMauListBits, IANAifMauMediaAvailable,
         IANAifMauAutoNegCapBits и IANAifJackType, задающие перечисляемые
         значения объектов ifMauTypeListBits, ifMauMediaAvailable/
         rpMauMediaAvailable, ifMauAutoNegCapabilityBits/
         ifMauAutoNegCapAdvertisedBits/ifMauAutoNegCapReceivedBits и
         ifJackType/rpJackType, соответственно, определенные в MAU-MIB.

         Предполагается, что каждый новый тип MAU, состояние Media 
         Availability, возможность Auto Negotiation и/или тип Jack, 
         определенные рабочей группой IEEE 802.3 и одобренные для
         публикации в IEEE Std 802.3, будут добавляться в этот модуль
         MIB, в предположении, что они будут управляться базовыми
         объектами MAU-MIB. Для таких дополнений нужна процедура
         Expert Review, определенная в RFC 2434 [RFC2434].

         Ниже приведены ссылки, используемые в данном модуле MIB.

         [IEEE802.3]
            IEEE Std 802.3, 2005 Edition: 'IEEE Standard for
            Information technology - Telecommunications and information
            exchange between systems - Local and metropolitan area
            networks - Specific requirements -
            Part 3: Carrier sense multiple access with collision
            detection (CSMA/CD) access method and physical layer
            specifications'.

         Эту ссылку следует обновлять при добавлении в модуль новых
         типов MAU, состояний Media Availability, возможностей Auto 
         Negotiation и/или типов Jack.

         Copyright (C) The IETF Trust (2007).
         Исходная версия этого модуля MIB опубликована в RFC 4836, 
         где правовые вопросы рассмотрены более подробно. 
         Дополнительная информация доступна по ссылке
         http://www.ietf.org/copyrights/ianamib.html" 

       REVISION     "200704210000Z"  -- 21 апреля 2007 г.
       DESCRIPTION  "Исходная версия этого модуля опубликована в RFC 4836."
       ::= { mib-2 154 }

     -- Текстовые соглашения

     IANAifMauTypeListBits ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Этот тип данных используется в качестве синтаксиса объектов 
         ifMauTypeListBits в (обновленном) определении MAU-MIB ifMauTable.

         Актуальный вариант этого текстового соглашения доступен в версии
         этого модуля MIB на сайте IANA.

         Запросы новых значений следует отправлять в IANA п адресу
         iana@iana.org. 

         Отметим, что изменения этого текстового соглашения НУЖНО 
         согласовывать с соответствующими изменениями dot3MauType
         OBJECT-IDENTITY."
       REFERENCE
         "[IEEE802.3], Section 30.5.1.1.2"
       SYNTAX       BITS {
              bOther(0),          -- другие и неизсестные
              bAUI(1),            -- AUI
              b10base5(2),        -- 10BASE-5
              bFoirl(3),          -- FOIRL

              b10base2(4),        -- 10BASE-2
              b10baseT(5),        -- 10BASE-T, режим дуплекса не известен
              b10baseFP(6),       -- 10BASE-FP
              b10baseFB(7),       -- 10BASE-FB
              b10baseFL(8),       -- 10BASE-FL, режим дуплекса не известен
              b10broad36(9),      -- 10BROAD36
              b10baseTHD(10),     -- 10BASE-T, полудуплексный
              b10baseTFD(11),     -- 10BASE-T, полнодуплексный
              b10baseFLHD(12),    -- 10BASE-FL, полудуплексный
              b10baseFLFD(13),    -- 10BASE-FL, полнодуплексный
              b100baseT4(14),     -- 100BASE-T4
              b100baseTXHD(15),   -- 100BASE-TX, полудуплексный
              b100baseTXFD(16),   -- 100BASE-TX, полнодуплексный
              b100baseFXHD(17),   -- 100BASE-FX, полудуплексный
              b100baseFXFD(18),   -- 100BASE-FX, полнодуплексный
              b100baseT2HD(19),   -- 100BASE-T2, полудуплексный
              b100baseT2FD(20),   -- 100BASE-T2, полнодуплексный

              b1000baseXHD(21),   -- 1000BASE-X, полудуплексный
              b1000baseXFD(22),   -- 1000BASE-X, полнодуплексный
              b1000baseLXHD(23),  -- 1000BASE-LX, полудуплексный
              b1000baseLXFD(24),  -- 1000BASE-LX, полнодуплексный
              b1000baseSXHD(25),  -- 1000BASE-SX, полудуплексный
              b1000baseSXFD(26),  -- 1000BASE-SX, полнодуплексный
              b1000baseCXHD(27),  -- 1000BASE-CX, полудуплексный
              b1000baseCXFD(28),  -- 1000BASE-CX, полнодуплексный
              b1000baseTHD(29),   -- 1000BASE-T, полудуплексный
              b1000baseTFD(30),   -- 1000BASE-T, полнодуплексный

              b10GbaseX(31),      -- 10GBASE-X
              b10GbaseLX4(32),    -- 10GBASE-LX4
              b10GbaseR(33),      -- 10GBASE-R
              b10GbaseER(34),     -- 10GBASE-ER
              b10GbaseLR(35),     -- 10GBASE-LR
              b10GbaseSR(36),     -- 10GBASE-SR
              b10GbaseW(37),      -- 10GBASE-W
              b10GbaseEW(38),     -- 10GBASE-EW
              b10GbaseLW(39),     -- 10GBASE-LW
              b10GbaseSW(40),     -- 10GBASE-SW
              -- new since RFC 3636
              b10GbaseCX4(41),    -- 10GBASE-CX4
              b2BaseTL(42),       -- 2BASE-TL
              b10PassTS(43),      -- 10PASS-TS
              b100BaseBX10D(44),  -- 100BASE-BX10D
              b100BaseBX10U(45),  -- 100BASE-BX10U
              b100BaseLX10(46),   -- 100BASE-LX10
              b1000BaseBX10D(47), -- 1000BASE-BX10D
              b1000BaseBX10U(48), -- 1000BASE-BX10U
              b1000BaseLX10(49),  -- 1000BASE-LX10
              b1000BasePX10D(50), -- 1000BASE-PX10D
              b1000BasePX10U(51), -- 1000BASE-PX10U
              b1000BasePX20D(52), -- 1000BASE-PX20D
              b1000BasePX20U(53)  -- 1000BASE-PX20U
         }

     IANAifMauMediaAvailable ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Этот тип данных используется в качестве синтаксиса объектов
         ifMauMediaAvailable и rpMauMediaAvailable в (обновленном)
         определении MAU-MIB ifMauTable и rpMauTable, соответственно.

         Возможные значения:
           other(1)             - не определен (не относится к указанным ниже)
           unknown(2)           - реальное состояние MAU не известно (например,
                                  в процессе инициализации)
           available(3)         - link, light или loopback в обычном состоянии
           notAvailable(4)      - link loss, low light или no loopback
           remoteFault(5)       - обнаружен отказ на удаленной стороне канала;
                                  это значение применимо к 10BASE-FB и 100BASE-T4 
                                  Far End Fault Indication, а также другим отказам
                                  на удаленной стороне в системах с автосогласованием
           invalidSignal(6)     - получен непригодный сигнал от другой стороны
                                  (только 10BASE-FB)
           remoteJabber(7)      - отказ на удаленной стороне, jabber
           remoteLinkLoss(8)    - отказ на удаленной стороне, потеря связи
           remoteTest(9)        - отказ на удаленной стороне, тест
           offline(10)          - отключен (только Auto-Negotiation, п. 37)
           autoNegError(11)     - ошибка автосогласования 
                                  (только Auto-Negotiation, п. 37)
           pmdLinkFault(12)     - отказ приема PMA/PMD; в случае PAF 
                                  (2BASE-TL/10PASS-TS PHY) отказ канала 
                                  на всех PME в группе
           wisFrameLoss(13)     - потеря кадра WIS, только 10GBASE-W
           wisSignalLoss(14)    - потеря сигнала WIS, только 10GBASE-W
           pcsLinkFault(15)     - отказ PCS на приемном канале
           excessiveBER(16)     - монитор PCS Bit Error Ratio указал
                                  слишком много ошибок
           dxsLinkFault(17)     - отказ DTE XGXS на приемном канале, только XAUI
           pxsLinkFault(18)     - отказ PHY XGXS на приемном канале, только XAUI
           availableReduced(19) — нормальный канал, снижение скорости, только
                                  2BASE-TL/10PASS-TS
           ready(20)            - по крайней мере один канал в группе PME 
                                  детектировал сигналы согласования, только
                                  2BASE-TL/10PASS-TS.

         Если MAU относится к каналу 10 Мбит/с или оптическому типу 
         (FOIRL, 10BASE-T, 10BASE-F), это эквивалентно функции проверки отказа 
         при тесте/малого уровня оптического сигнала. Для AUI, 10BASE2, 10BASE5 
         или 10BROAD36 это показывает обнаружение петли (loopback) на устройстве
         DI. Значение этого атрибута сохраняется от пакета к пакету для MAU
         типов AUI, 10BASE5, 10BASE2, 10BROAD36 и 10BASEFP.

         При включении питания или Media Available принимает значение
         unknown(2) для AUI, 10BASE5, 10BASE2, 10BROAD36 и 10BASE-FP.
         Для таких MAU будет выполняться шлейфовый (loopback) тест при
         каждой передаче в течение которой не было обнаружен конфиликтов.
         Если DI принимает данные, когда DO возвращено в IDL после
         передачи, при которой не возникло конфликтов, петля будет 
         обнаружена. Состояние Media Available будет меняться лишь в 
         процессе передачи без конфликтов для AUI, 10BASE2, 10BASE5, 
         10BROAD36 и 10BASE-FP.

         Для 100BASE-T2, 100BASE-T4, 100BASE-TX, 100BASE-FX,
         100BASE-LX10 и 100BASE-BX10 PHY перечисляемые значения
         соответствуют состояниям диаграммы целостности канала.
         Все MAU, реализующие раздел 28 [IEEE802.3] (Auto-Negotiation), 
         будут отображать индикацию удаленного отказа на remoteFault(5).

         Все MAU, реализующие раздел 37 Auto-Negotiation, будут 
         отображать принятые биты RF1 и RF2 следующим образом:
         Offline отображается на offline(10), Link_Failure - на
         remoteFault(5), Auto-Negotiation Error — на autoNegError(11).

         Значение remoteFault(5) применяется к индикации удаленного 
         отказа 10BASE-FB, индикации отказа 100BASE-X на удаленной стороне 
         и неизвестного удаленного отказа в системах, поддерживающий 
         Auto-Negotiation (раздел 28).

         Значения remoteJabber(7), remoteLinkLoss(8) или remoteTest(9)
         СЛЕДУЕТ применять вместо remoteFault(5), когда причина отказа
         указана протоколом сигнализации.
         При наличии MII (раздер 22) или GMII (раздел 35) значение 1
         бита удаленных отказов отображается на значение remoteFault(5),
         а 0 — на notAvailable(4). Значение notAvailable(4) имеет 
         преимущество перед remoteFault(5).

         Для 2BASE-TL и 10PASS-TS PHY значение unknown(2) отображается
         на условие инициализации PHY (PCS с подключенными PME), 
         ready(20) отображается на отключенный интерфейс с хотя бы одним
         PME в группе агрегирования, готовым к согласованию, available(3) 
         отображается на условие, когда все PME в группе агрегирования
         активны, notAvailable(4) — на условие, когда все PME в группе
         выключены и нет сигналов согласования, availableReduced(19) - 
         на условие, когда интерфейс активен и обнаружен отказ канала
         в приемном направлении одним или несколькими PME в группе
         агрегирования и хотя бы один PME активен, а pmdLinkFault(12) 
         отображается на условие обнаружения отказа в приемном направлении
         всеми PME в группе агрегирования.

         Для 10 Гбит/с перечисляемые значения отображаются на переменную 
         link_fault диаграммы состояний Link Fault Signaling - значение
         OK отображается на available(3), Local Fault — на notAvailable(4),
         а Remote Fault — на remoteFault(5). Значение pmdLinkFault(12), 
         wisFrameLoss(13), wisSignalLoss(14), pcsLinkFault(15), 
         excessiveBER(16) или dxsLinkFault(17) СЛЕДУЕТ применять вместо
         notAvailable(4) в тех случаях, когда причину состояния Local Fault
         можно указать с использованием интерфейса MDIO (раздел 45). При
         наличии множества причин состояния Local Fault СЛЕДУЕТ выбирать
         ошибку с высшим приоритетом, из приведенного списка по убыванию:
           pxsLinkFault
           pmdLinkFault
           wisFrameLoss
           wisSignalLoss
           pcsLinkFault
           excessiveBER
           dxsLinkFault.

         При наличии интерфейса MDIO (раздел 45) 0 в бите состояния
         PMA/PMD Receive ([IEEE802.3] параграф 45.2.1.2.2) отображается 
         на значение pmdLinkFault(12), 1 в бите состояния LOF (параграф
         45.2.2.10.4) — на wisFrameLoss(13), 1 в бите состояния LOS
         (параграф 45.2.2.10.5) — на wisSignalLoss, 0 в бите состояния 
         PCS Receive link (параграф 45.2.3.2.2) — на pcsLinkFault(15),
         1 в бите состояния 10GBASE-R PCS Latched high BER (параграф
         45.2.3.12.2) — на excessiveBER, 0 в бите состояния DTE XS 
         приемного канала (параграф 45.2.5.2.2) — на dxsLinkFault(17),
         а 0 в бите состояния PHY XS передающего канала (параграф
         45.2.4.2.2) — на pxsLinkFault(18).

         Актуальная версия этого текстового соглашения доступна в
         модуле MIB на сайте IANA.

         Запросы для новых значений следует направлять в IANA по адресу
         (iana@iana.org)." 
       REFERENCE
         "[IEEE802.3], Section 30.5.1.1.4"
       SYNTAX       INTEGER {
              other(1),
              unknown(2),
              available(3),
              notAvailable(4),
              remoteFault(5),
              invalidSignal(6),
              remoteJabber(7),
              remoteLinkLoss(8),
              remoteTest(9),
              offline(10),
              autoNegError(11),
              pmdLinkFault(12),
              wisFrameLoss(13),
              wisSignalLoss(14),
              pcsLinkFault(15),
              excessiveBER(16),
              dxsLinkFault(17),
              pxsLinkFault(18),
              availableReduced(19),
              ready(20)
         }

     IANAifMauAutoNegCapBits ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Этот тип данных служит в качестве синтаксиса объектов
         ifMauAutoNegCapabilityBits, ifMauAutoNegCapAdvertisedBits и
         ifMauAutoNegCapReceivedBits в (обновленном) определении
         ifMauAutoNegTable в модуле MAU-MIB.

         Актуальная версия этого текстового соглашения доступна в
         модуле MIB на сайте IANA.

         Запросы для новых значений следует направлять в IANA по адресу
         (iana@iana.org)."
       REFERENCE	"[IEEE802.3], Section 30.6.1.1.5"
       SYNTAX       BITS {
              bOther(0),          -- прочие или неизвестные
              b10baseT(1),        -- 10BASE-T, полудуплексный режим
              b10baseTFD(2),      -- 10BASE-T, полнодуплексный режим
              b100baseT4(3),      -- 100BASE-T4
              b100baseTX(4),      -- 100BASE-TX, полудуплексный режим
              b100baseTXFD(5),    -- 100BASE-TX, полнодуплексный режим
              b100baseT2(6),      -- 100BASE-T2, полудуплексный режим
              b100baseT2FD(7),    -- 100BASE-T2, полнодуплексный режим
              bFdxPause(8),       -- PAUSE для полнодуплексных каналов
              bFdxAPause(9),      -- Asymmetric PAUSE для полнодуплексных
                                  --     каналов
              bFdxSPause(10),     -- Symmetric PAUSE для полнодуплексных
                                  --     каналов
              bFdxBPause(11),     -- Asymmetric и Symmetric PAUSE для
                                  --     полнодуплексных каналов
              b1000baseX(12),     -- 1000BASE-X, -LX, -SX, -CX,
                                  --     полудуплексный режим
              b1000baseXFD(13),   -- 1000BASE-X, -LX, -SX, -CX,
                                  --     полнодуплексный режим
              b1000baseT(14),     -- 1000BASE-T, полудуплексный режим
              b1000baseTFD(15)    -- 1000BASE-T, полнодуплексный режим
         }

     IANAifJackType ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
         "Общие перечисляемые значения для типов разъемов в MAU интерфейсов
         и повторителей. Этот тип данных служит синтаксисом для объектов
         ifJackType и rpJackType в (обновленных) определениях MAU-MIB
         ifJackTable и rpJackTable, соответственно.

         Possible values are:
              other(1)          - не определен или не известен
              rj45(2)           - RJ45
              rj45S(3)          - RJ45 с экраном
              db9(4)            - DB9
              bnc(5)            - BNC
              fAUI(6)           - розетка AUI
              mAUI(7)           - вилка AUI 
              fiberSC(8)        - оптика SC
              fiberMIC(9)       - оптика MIC 
              fiberST(10)       - оптика ST 
              telco(11)         - Telco
              mtrj(12)          - оптика MT-RJ 
              hssdc(13)         - оптический канал style-2
              fiberLC(14)       - оптика LC 
              cx4(15)           - IB4X для 10GBASE-CX4

         Актуальная версия этого текстового соглашения доступна в
         модуле MIB на сайте IANA.

         Запросы для новых значений следует направлять в IANA по адресу
         (iana@iana.org)."
       SYNTAX       INTEGER {
              other(1),
              rj45(2),
              rj45S(3),
              db9(4),
              bnc(5),
              fAUI(6),
              mAUI(7),
              fiberSC(8),
              fiberMIC(9),
              fiberST(10),
              telco(11),
              mtrj(12),
              hssdc(13),
              fiberLC(14),
              -- добавлено в RFC 3636
              cx4(15)
         }

     -- OBJECT IDENTITY для типов MAU 
     -- (см. rpMauType и ifMauType в MAU-MIB, где описано применение)
     -- Приведенные ниже определения были перемещены из RFC 3636 и
     -- не будут включаться в новые выпуски.

     dot3MauType OBJECT IDENTIFIER ::= { mib-2 snmpDot3MauMgt(26) 4 }

     dot3MauTypeAUI OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Нет внутреннего MAU, виден через AUI"
       REFERENCE   "[IEEE802.3], Section 7"
       ::= { dot3MauType 1 }

     dot3MauType10Base5 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для толстого коаксиала"
       REFERENCE   "[IEEE802.3], Section 7"
       ::= { dot3MauType 2 }

     dot3MauTypeFoirl OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "FOIRL MAU"
       REFERENCE   "[IEEE802.3], Section 9.9"
       ::= { dot3MauType 3 }

     dot3MauType10Base2 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для тонкого коаксиала"
       REFERENCE   "[IEEE802.3], Section 10"
       ::= { dot3MauType 4 }

     dot3MauType10BaseT OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "UTP MAU.
                   Отметим, что агентам настоятельно рекомендуется
                   возвращать значение dot3MauType10BaseTHD или
                   dot3MauType10BaseTFD при известном режиме дуплекса.
                   Однако программам управления следует быть готовыми
                   получать это значение типа MAU от старых агентов."
       REFERENCE   "[IEEE802.3], Section 14"
       ::= { dot3MauType 5 }

     dot3MauType10BaseFP OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для пассивной оптики"
       REFERENCE   "[IEEE802.3], Section 16"
       ::= { dot3MauType 6 }

     dot3MauType10BaseFB OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для синхронной оптики"
       REFERENCE   "[IEEE802.3], Section 17"
       ::= { dot3MauType 7 }

     dot3MauType10BaseFL OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для асинхронной оптики.
                   Отметим, что агентам настоятельно рекомендуется
                   возвращать значение dot3MauType10BaseFLHD или
                   dot3MauType10BaseFLFD при известном режиме дуплекса.
                   Однако программам управления следует быть готовыми
                   получать это значение типа MAU от старых агентов."
       REFERENCE   "[IEEE802.3], Section 18"
       ::= { dot3MauType 8 }

     dot3MauType10Broad36 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "MAU для широкополосного DTE.
                   Отметим, что 10BROAD36 MAU могут подключаться к
                   интерфейсам, но не к повторителям."
       REFERENCE   "[IEEE802.3], Section 11"
       ::= { dot3MauType 9 }

     ------ добавлены в RFC 1515
     dot3MauType10BaseTHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "UTP MAU, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 14"
       ::= { dot3MauType 10 }

     dot3MauType10BaseTFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "UTP MAU, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 14"
       ::= { dot3MauType 11 }

     dot3MauType10BaseFLHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "async fiber MAU, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 18"
       ::= { dot3MauType 12 }

     dot3MauType10BaseFLFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "async fiber MAU, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 18"
       ::= { dot3MauType 13 }

     dot3MauType100BaseT4 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "4 пары кабеля UTP категории 3"
       REFERENCE   "[IEEE802.3], Section 23"
       ::= { dot3MauType 14 }

     dot3MauType100BaseTXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 пары кабеля UTP категории 5, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 25"
       ::= { dot3MauType 15 }

     dot3MauType100BaseTXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 pair category 5 UTP, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 25"
       ::= { dot3MauType 16 }

     dot3MauType100BaseFXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X-волокно на основе PMT, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 26"
       ::= { dot3MauType 17 }

     dot3MauType100BaseFXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X-волокно на основе PMT, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 26"
       ::= { dot3MauType 18 }

     dot3MauType100BaseT2HD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 пары кабеля UTP категории 3, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 32"
       ::= { dot3MauType 19 }

     dot3MauType100BaseT2FD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 пары кабеля UTP категории 3, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 32"
       ::= { dot3MauType 20 }

     ------ добавлены в RFC 2239:
     dot3MauType1000BaseXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "PCS/PMA, неизвестный PMD, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 36"
       ::= { dot3MauType 21 }

     dot3MauType1000BaseXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "PCS/PMA, неизвестный PMD, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 36"
       ::= { dot3MauType 22 }

     dot3MauType1000BaseLXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с длинноволновым лазером, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 23 }

     dot3MauType1000BaseLXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с длинноволновым лазером, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 24 }

     dot3MauType1000BaseSXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с коротковолновым лазером, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 25 }

     dot3MauType1000BaseSXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Оптика с коротковолновым лазером, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 38"
       ::= { dot3MauType 26 }

     dot3MauType1000BaseCXHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "150-омный сбалансированный кабель, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 39"
       ::= { dot3MauType 27 }

     dot3MauType1000BaseCXFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "150-омный сбалансированный кабель, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 39"
       ::= { dot3MauType 28 }

     dot3MauType1000BaseTHD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "4 пары кабеля UTP категории 5, полудуплексный режим"
       REFERENCE   "[IEEE802.3], Section 40"
       ::= { dot3MauType 29 }

     dot3MauType1000BaseTFD OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "4 пары кабеля UTP категории 5, полнодуплексный режим"
       REFERENCE   "[IEEE802.3], Section 40"
       ::= { dot3MauType 30 }

     ------ добавлены в RFC 2668:
     dot3MauType10GigBaseX OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X PCS/PMA, неизвестный PMD."
       REFERENCE   "[IEEE802.3], Section 48"
       ::= { dot3MauType 31 }

     dot3MauType10GigBaseLX4 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "X-волокно с WWDM"
       REFERENCE   "[IEEE802.3], Section 53"
       ::= { dot3MauType 32 }

     dot3MauType10GigBaseR OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R PCS/PMA, неизвестный PMD."
       REFERENCE   "[IEEE802.3], Section 49"
       ::= { dot3MauType 33 }

     dot3MauType10GigBaseER OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R-волокно, 1550 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 34 }

     dot3MauType10GigBaseLR OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R-волокно, 1310 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 35 }

     dot3MauType10GigBaseSR OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "R-волокно, 850 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 36 }

     dot3MauType10GigBaseW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W PCS/PMA, неизвестный PMD."
       REFERENCE   "[IEEE802.3], Section 49 and 50"
       ::= { dot3MauType 37 }

     dot3MauType10GigBaseEW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W-волокно, 1550 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 38 }

     dot3MauType10GigBaseLW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W-волокно, 1310 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 39 }

     dot3MauType10GigBaseSW OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "W-волокно, 850 нм"
       REFERENCE   "[IEEE802.3], Section 52"
       ::= { dot3MauType 40 }

     ------ добавлено в RFC 3636:
     dot3MauType10GigBaseCX4 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "8-парный сбалансированный кабель 100 Ом"
       REFERENCE   "[IEEE802.3], Section 54"
       ::= { dot3MauType 41 }

     dot3MauType2BaseTL OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Телефонный кабель UTP до 2700 м, необязательный PAF"
       REFERENCE   "[IEEE802.3], Sections 61 and 63"
       ::= { dot3MauType 42 }

     dot3MauType10PassTS OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Телефонный кабель UTP до 750 м, необязательный PAF"
       REFERENCE   "[IEEE802.3], Sections 61 and 62"
       ::= { dot3MauType 43 }

     dot3MauType100BaseBX10D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одно волокно OLT, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 58"
       ::= { dot3MauType 44 }

     dot3MauType100BaseBX10U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно ONU, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 58"
       ::= { dot3MauType 45 }

     dot3MauType100BaseLX10 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 одномодовых волокна, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 58"
       ::= { dot3MauType 46 }

     dot3MauType1000BaseBX10D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно OLT, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 59"
       ::= { dot3MauType 47 }

     dot3MauType1000BaseBX10U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно ONU, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 59"
       ::= { dot3MauType 48 }

     dot3MauType1000BaseLX10 OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "2 одномодовых волокна, длинноволновый лазер, 10 км"
       REFERENCE   "[IEEE802.3], Section 59"
       ::= { dot3MauType 49 }

     dot3MauType1000BasePX10D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON OLT, 10 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 50 }

     dot3MauType1000BasePX10U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON ONU, 10 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 51 }

     dot3MauType1000BasePX20D OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON OLT, 20 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 52 }

     dot3MauType1000BasePX20U OBJECT-IDENTITY
       STATUS      current
       DESCRIPTION "Одномодовое волокно EPON ONU, 20 км"
       REFERENCE   "[IEEE802.3], Section 60"
       ::= { dot3MauType 53 }

   END

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

IANA-MAU-MIB не определяет каких-либо объектов управления. Вместо этого модуль определяет набор текстовых соглашений, используемых MAU-MIB, которые могут также применяться в других модулях MIB для определения объектов управления. Значимое рассмотрение вопросов безопасности может быть проведено лишь для модулей MIB, определяющих объекты управления.

Для множества объектов, определенных в MAU-MIB, установлено MAX-ACCESS для чтения и записи (read-write). Установка таких объектов может существенно влиять на работу сети, включая:

  • отключение и включение MAU;

  • смена принятого по умолчанию типа MAU;

  • включение, отключение или перезапуск автосогласования;

  • изменение возможностей, анонсируемых MAU при автосогласовании.

Такие объекты могут быть уязвимы в некоторых сетевых средах. Поддержка операций SET в небезопасной среде без подобающей защиты может негативно повлиять на работу сети.

Некоторые из доступных для чтения объектов данного модуля MIB (т. е. объекты, у которых MAX-ACCESS отличается от not-accessible) могут быть уязвимы в некоторых сетевых средах. В некоторых средах может оказаться нежелательным доступ неуполномоченных сторон к статистике работы отдельных каналов. Поэтому важно контролировать доступ GET и/или NOTIFY к таким объектам и по возможности шифровать объекты при передаче через сеть по протоколу SNMP.

Протокол SNMP до версии SNMPv3 не обеспечивает адекватной защиты. Даже в защищенной сети (например, с помощью IPSec) нет возможности персонально контролировать доступ GET/SET (чтение, изменение, создание, удаление) к объектам модуля MAU-MIB.

Разработчикам рекомендуется рассмотреть функции защиты, обеспечиваемые SNMPv3 (см. раздел 8 [RFC3410]), включая полную поддержку криптографических механизмов SNMPv3 (для аутентификации и конфиденциальности).

Более того, развертывание версий SNMP до SNMPv3 не рекомендуется. Вместо этого рекомендуется использовать SNMPv3 и включать криптографическую защиту. Тогда на абонентов/операторов ложится ответственность за обеспечение того, чтобы объект SNMP, предоставляющий доступ к экземпляру этого модуля MIB, был правильно настроен для предоставления доступа к объектам лишь тем элементам (пользователям), которые имеют легитимные права выполнять операции GET или SET (изменить, создать, удалить).

7. Взаимодействие с IANA

Этот документ определяет превую версию администрируемого IANA модуля IANA-MAU-MIB. Предполагается, что каждый новый тип MAU, состояние Media Available, возможность Auto Negotiation и/или тип разъема, определенные рабочей группой IEEE 802.3 и одобренные для включения в IEEE Std 802.3, будут добавляться в поддерживаемый IANA модуль MIB при условии, что он может управляться базовыми объектами из модуля MAU-MIB.

При добавлении каждого нового типа MAU следует давать краткое описание технологии MAU и, по возможности, ссылку на публично доступную спецификацию. Для каждого изменения требуется процедура Expert Review, определенная в RFC 2434 [RFC2434].

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

Этот документ подготовлен рабочей группой IETF Ethernet Interfaces and Hub MIB, в которой следует особо подчеркнуть усилия Mike Heard, John Flick и Dan Romascanu.

Документ основан на предложенном стандарте MAU MIB, RFC 3636 [RFC3636] под редакцией John Flick из Hewlett-Packard, подготовленном рабочей группой Ethernet Interfaces and Hub MIB. Документ расширен путем переноса отождествлений объектов и текстовых соглашений для типов MAU в поддерживаемый IANA модуль MIB. Кроме того, обеспечивается поддержка EFM и 10GBASE-CX4 MAU, определенных в [IEEE802.3ah] и [IEEE802.3ak], соответственно.

RFC 3636 был основан на предложенном стандарте MAU MIB, RFC 2668 [RFC2668] под редакцией John Flick из Hewlett-Packard и Andrew Smith (тогда Extreme Networks), подготовленном рабочей группой Ethernet Interfaces and Hub MIB. Документ был расширен путем добавления поддержки MAU 10 Гбит/с, определенных в [IEEE802.3ae].

RFC 2668 был основан на предложенном стандарте MAU MIB, RFC 2239 [RFC2239] под редакцией Kathryn de Graaf (тогда 3Com) и Dan Romascanu (тогда Madge Networks), подготовленном рабочей группой Ethernet Interfaces and Hub MIB. Документ был расширен путем добавления поддержки MAU 1000 Мбит/с, согласования PAUSE и статуса удаленных отказов, как определено в [IEEE802.3].

RFC 2239 был основан на предложенном стандарте MAU MIB, RFC 1515 [RFC1515] под редакцией Donna McMaster (тогда SynOptics Communications), Keith McCloghrie (тогда Hughes LAN Systems) и Sam Roberts (тогда Farallon Computing), подготовленном рабочей группой Hub MIB. Документ был расширен путем добавления поддержки MAU 100 Мбит/с, полнодуплексных MAU, автосогласования и управления разъемами, как определено в [IEEE802.3].

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

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

[IEEE802.3] IEEE, «IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications», IEEE Std 802.3-2005, December 2005.

[IEEE802.3ae] IEEE, «IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Media Access Control (MAC) Parameters, Physical Layer and Management Parameters for 10 Gb/s Operation», IEEE Std 802.3ae-2002, August 2002.

[IEEE802.3ah] IEEE, «Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Media Access Control Parameters, Physical Layers and Management Parameters for Subscriber Access Networks», IEEE Std 802.3ah-2004, September 2004.

[IEEE802.3ak] IEEE, «IEEE Standard for Information technology — Telecommunications and information exchange between systems — Local and metropolitan area networks — Specific requirements — Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications — Physical Layer and Management Parameters for 10Gb/s Operation, Type 10GBASE-CX4», IEEE Std 802.3ak-2004, March 2004.

[RFC2108] de Graaf, K., Romascanu, D., McMaster, D., and K. McCloghrie, «Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2», RFC 2108, February 1997.

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

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 2434, October 1998.

[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, April 1999.

[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Textual Conventions for SMIv2», STD 58, RFC 2579, April 1999.

[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, «Conformance Statements for SMIv2», STD 58, RFC 2580, April 1999.

[RFC2863] McCloghrie, K. and F. Kastenholz, «The Interfaces Group MIB», RFC 2863, June 2000.

[RFC3635] Flick, J., «Definitions of Managed Objects for the Ethernet-like Interface Types», RFC 3635, September 2003.

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

[RFC1515] McMaster, D., McCloghrie, K., and S. Roberts, «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)», RFC 1515, September 1993.

[RFC2239] de Graaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S. Roberts, «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) using SMIv2», RFC 2239, November 1997.

[RFC2668] Smith, A., Flick, J., de Graaf, K., Romascanu, D., McMaster, D., McCloghrie, K., and S. Roberts, «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)», RFC 2668, August 1999.

[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, «Introduction and Applicability Statements for Internet-Standard Management Framework», RFC 3410, December 2002.

[RFC3418] Presuhn, R., «Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3418, December 2002.

[RFC3636] Flick, J., «Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs)», RFC 3636, September 2003.

[RFC3637] Heard, C., «Definitions of Managed Objects for the Ethernet WAN Interface Sublayer», RFC 3637, September 2003.


Адрес автора

Edward Beili

Actelis Networks

Bazel 25

Petach-Tikva

Israel

Phone: +972-3-924-3491

EMail: edward.beili@actelis.com


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

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

nmalykh@gmail.com

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

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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


1Management Information Base — база информации для управления.

2Medium Attachment Unit — модуль подключения к среде передачи.

3Internet Assigned Number Authority

4Ethernet in the First Mile — Ethernet на первой миле.

5Simple Network Management Protocol.

6Structure of Management Information — структура информации управления.




RFC 4884 Extended ICMP to Support Multi-Part Messages

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).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

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


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

2Network Address Translation.

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

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

 




RFC 4835 Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

Network Working Group                                      V. Manral
Request for Comments: 4835                          IP Infusion Inc.
Obsoletes: 4305                                           April 2007
Category: Standards Track

Требования к реализациям криптографических алгоритмов для ESP и AH

Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

PDF

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

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

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

Copyright (C) The Internet Trust (2007).

Тезисы

Группа протоколов IPsec использует различные криптографические алгоритмы для обеспечения услуг защиты. Протоколы ESP1 и AH2) обеспечивают два механизма защиты данных, передаваемых через IPsec SA3. Для обеспечения совместимости требуется задать набор обязательных для реализации алгоритмов, чтобы гарантировать поддержку всеми реализациями хотя одного алгоритма. В этом документе определяется набор обязательных для реализации в протоколах ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут быть отнесены в будущем к числу обязательных.

Оглавление

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

1. Введение

Протоколы ESP и AH обеспечивают два механизма для защиты данных, передаваемых через IPsec SA [RFC4301], [RFC4302]. Для обеспечения совместимости требуется задать набор обязательных для реализации алгоритмов, чтобы гарантировать поддержку всеми реализациями хотя одного алгоритма. В этом документе определяется набор обязательных для реализации в протоколах ESP и AH алгоритмов, а также указаны алгоритмы, которые следует реализовать, поскольку они могут быть отнесены в будущем к числу обязательных.

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

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

В идеальном случае алгоритмам, которые будут внесены в число обязательных для реализации завтра, уже следует присутствовать в большинстве реализаций IPsec на момент придания им статуса обязательных. Для облегчения этого мы будем пытаться идентифицировать такие алгоритмы (поскольку они уже известны) в данном документе. Не существует гарантий того, что указанные алгоритмы станут в будущем обязательными, но они могут ими стать. Все известные алгоритмы являются объектами атак и использование любого из них может быть прекращено в будущем.

2. Уровни требований

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

Кроме того, здесь определено несколько дополнительных уровней.

SHOULD+

Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD+, в будущем перейдет в число обязательных (MUST).

SHOULD-

Этот термин обозначает то же, что и SHOULD. Однако, алгоритм, помеченный как SHOULD-, может перейти на уровень разрешенных (MAY) или ниже в будущих версиях этого документа.

MUST-

Этот термин обозначает то же, что и MUST. Однако мы предполагаем, что в какой-то момент этот алгоритм перестанет быть обязательным.

3. Выбор алгоритма

Для обеспечения совместимости реализаций IPsec требуется поддержка по крайней мере одного общего алгоритма защиты. В этом разделе приведены требования по реализации алгоритмов защиты для соответствующих спецификации реализаций протоколов ESP и AH. Алгоритмы защиты, реально используемые любой конкретной защищенной связью ESP или AH, определяются механизмом согласования (таким, как IKE4 [RFC2409], [RFC4306]) или задаются при организации соединения.

Естественно, допускается реализация дополнительных (стандартных или фирменных) алгоритмов, не упомянутых в этом документе.

3.1. Протокол ESP

Требования в поддержке алгоритмов защиты для соответствующих спецификации реализаций протокола ESP приведены ниже. Определения уровней требований (колонка Требования) содержатся в разделе 2.

3.1.1. Алгоритмы шифрования и аутентификации для ESP

В приведенных ниже таблицах указаны требования к алгоритмам шифрования и аутентификации для протокола IPsec ESP.

Требования Алгоритм шифрования
MUST — обязательно NULL [RFC2410]5
MUST — обязательно AES-CBC со 128-битовыми ключами [RFC3602]
MUST- — обязательно , но может утратить статус TripleDES-CBC [RFC2451]
SHOULD — следует AES-CTR [RFC3686]
SHOULD NOT — не следует DES-CBC [RFC2405]6
Требования Алгоритм аутентификации
MUST — обязательно HMAC-SHA1-96 [RFC2404]7
SHOULD+ — следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566]
MAY — возможно NULL2
MAY — возможно HMAC-MD5-96 [RFC2403]8

3.1.2. Комбинированные алгоритмы для ESP

Как указано в [RFC4303], протокол поддерживает использование комбинированных алгоритмов, которые обеспечивают услуги конфиденциальности и аутентификации. Поддержка таких алгоритмов требует соответствующего структурирования реализации ESP. Во многих ситуациях комбинированные алгоритмы обеспечивают значительные преимущества в части эффективности и пропускной способности. Хотя в настоящее время не указывается предлагаемых или обязательных к реализации комбинированных алгоритмов, предполагается, что в ближайшем будущем представят интерес алгоритмы AES-CCM [RFC4309] и AES-GCM [RFC4106]. Алгоритм AES-CCM принят в качестве предпочтительного для IEEE 802.11 [802.11i], а AES- GCM — для IEEE 802.1ae [802.1ae].

3.2. Протокол AH

Ниже приведены требования к реализации алгоритмов защиты в соответствующих спецификации реализациях протокола AH. Определения уровней требований (колонка Требования) приведены в разделе 2. Как вы понимаете, все перечисленные алгоритмы относятся к числу алгоритмов аутентификации.

Требования Алгоритм аутентификации
MUST — обязательно HMAC-SHA1-96 [RFC2404]9
SHOULD+ — следует, но может стать обязательным AES-XCBC-MAC-96 [RFC3566]
MAY — возможно HMAC-MD5-96 [RFC2403]10

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

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

Этот документ посвящен выбору криптографических алгоритмов для использования с протоколами ESP и AH и, в частности, обязательных для реализации алгоритмов. Алгоритмы, которые в соответствии с этой спецификацией требуется (MUST) или следует (SHOULD) реализовать, не имеют в данный момент известных фактов взлома и выполненные криптографические исследования позволяют надеяться, что эти алгоритмы останутся безопасными в обозримом будущем. Однако, такое положение дел не обязательно сохранится. Мы, следовательно, предполагаем появление новых версий этого документа, отражающих накопленный в сфере защиты опыт.

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

Значительная часть этого документа перенесена из RFC 4305, являющегося предшественником данного документа. Сам RFC 4305 заимствует часть текста из документа Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 [RFC4307], подготовленного Jeffrey I. Schiller.

Спасибо перечисленным здесь людям, которые указали ошибки в RFC 4305 или ответили на сообщения об их обнаружении: Paul Hoffman, Stephen Kent, Paul Koning и Lars Volker. Полезные комментарии были получены от Russ Housley, Elwyn Davies, Nicolas Williams и Alfred Hoenes.

6. Отличия RFC 2402 и RFC 2406 от RFC 4305

[RFC2402] и [RFC2406] определяли протоколы IPsec AH и IPsec ESP. Каждый из этих документов содержал требования к криптографическим алгоритмам для соответствующего протокола. В настоящее время эти спецификации заменены документами [RFC4302] и [RFC4303], которые не содержат требований к реализации криптографических алгоритмов. В данном документе указаны такие требования для обоих протоколов — [RFC4302] и [RFC4303].

Сравнение требований приведено ниже.

Старое требование Старый RFC Новое требование Алгоритм
MUST — требуется 2406 SHOULD NOT — не следует DES-CBC [RFC2405]11
MUST — требуется 2402, 2406 MAY — возможно HMAC-MD5-96 [RFC2403]
MUST — требуется 2402, 2406 MUST — требуется HMAC-SHA1-96 [RFC2404]

7. Отличия от RFC 4305

Этот документ является заменой [RFC4305]. Документ меняет требование по поддержке алгоритма аутентификации NULL с MUST (требуется) на MAY (возможно). Это изменение внесено для обеспечения согласованности с [RFC4301]. Добавлен текст об атаках с использованием конфликтов SHA-1, а также отмечены, как предполагаемые для использования в будущем, алгоритмы AES-GCM и AES-CCM.

Измененные требования к поддержке алгоритмов в реализациях протоколов перечислены в таблице.

Старое требование Старый RFC Новое требование Алгоритм
MUST — требуется 2406 MAY — возможно Аутентификация NULL
MUST — требуется 2406 MUST — требуется Шифрование NULL
SHOULD+ — следует с возможностью перехода в должно 4305 MUST — требуется Шифрование AES-CBC

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

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

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP14, RFC2119, March 1997.

[RFC2403] Madson, C. and R. Glenn, «The Use of HMAC-MD5-96 within ESP and AH», RFC 2403, November 1998.

[RFC2404] Madson, C. and R. Glenn, «The Use of HMAC-SHA-1-96 within ESP and AH», RFC 2404, November 1998.

[RFC2405] Madson, C. and N. Doraswamy, «The ESP DES-CBC Cipher Algorithm With Explicit IV», RFC 2405, November 1998.

[RFC2410] Glenn, R. and S. Kent, «The NULL Encryption Algorithm and Its Use With IPsec», RFC 2410, November 1998.

[RFC2451] Pereira, R. and R. Adams, «The ESP CBC-Mode Cipher Algorithms», RFC 2451, November 1998.

[RFC3566] Frankel, S. and H. Herbert, «The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec», RFC 3566, September 2003.

[RFC3602] Frankel, S., Glenn, R., and S. Kelly, «The AES-CBC Cipher Algorithm and Its Use with IPsec», RFC 3602, September 2003.

[RFC3686] Housley, R., «Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)», RFC 3686, January 2004.

[RFC4301] Kent, S. and K. Seo, «Security Architecture for the Internet Protocol», RFC 4301, December 2005.

[RFC4302] Kent, S., «IP Authentication Header», RFC 4302, December 2005.

[RFC4303] Kent, S., «IP Encapsulating Security Payload (ESP)», RFC 4303, December 2005.

[RFC4305] Eastlake, D., «Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)», RFC 4305, December 2005.

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

[802.11i] «LAN/MAN Specific Requirements Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications», IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.11i, June 2004.

[802.1ae] «Media Access Control (MAC) Security», IEEE Standard Medium Access Control (MAC) Security, IEEE Std 802.1ae, June 2006.

[DES-WDRAW] «Announcing Proposed Withdrawal of Federal Information Processing Standard (FIPS) for the Data Encryption Standard (DES) and Request for Comments», FIPS Notice Docket No. 040602169-4169-01, July 2004.

[MD5-COLL] Klima, V., «Finding MD5 Collisions — a Toy For a Notebook», Cryptology ePrint Archive Medium Report 2005/075, March 2005.

[RFC2402] Kent, S. and R. Atkinson, «IP Authentication Header», RFC 2402, November 1998.

[RFC2406] Kent, S. and R. Atkinson, «IP Encapsulating Security Payload (ESP)», RFC 2406, November 1998.

[RFC2407] Piper, D., «The Internet IP Security Domain of Interpretation for ISAKMP», RFC 2407, November 1998.

[RFC2409] Harkins, D. and D. Carrel, «The Internet Key Exchange (IKE)», RFC 2409, November 1998.

[RFC4106] Viega, J. and D. McGrew, «The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)», RFC 4106, June 2005.

[RFC4306] Kaufman, C., «Internet Key Exchange (IKEv2) Protocol», RFC 4306, December 2005.

[RFC4307] Schiller, J., «Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)», RFC 4307, December 2005.

[RFC4309] Housley, R., «Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)», RFC 4309, December 2005.

[SHA1-COLL] Rijmen, V. and E. Oswald, «Update on SHA-1», Cryptology ePrint Archive Report 2005/010, January 2005.

Адрес автора

Vishwas Manral

IP Infusion Inc.

Bamankhola, Bansgali,

Almora, Uttarakhand 263601

India

Phone: +91-98456-61911

EMail: vishwas@ipinfusion.com


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

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

nmalykh@gmail.com

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

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

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

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

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

Финансирование функций RFC Editor обеспечено IETF Administrative Support Activity (IASA).


1Encapsulating Security Payload — инкапсуляция защищенных данных.

2Authentication Header — заголовок аутентификации.

3Security Association — защищенная связь.

4Internet Key Exchange — обмен ключами в Internet.

5Поскольку шифрование в ESP является необязательными, поддержка алгоритма NULL требуется для обеспечения совместимости со способом согласования услуг. Отметим, что, несмотря на возможность использования алгоритма NULL и для аутентификации, недопустимо использование NULL для обоих алгоритмов сразу [RFC4301].

6Алгоритм DES с его малым размером ключей и публично показанной открытой аппаратурой для взлома, является сомнительным средством защиты общего пользования.

7В алгоритме SHA-1 проявились слабые стороны [SHA1-COLL], однако это не должно влиять на использование SHA1 с HMAC.

8В алгоритме MD5 проявились слабые стороны [MD5-COLL], однако это не должно влиять на использование MD5 с HMAC.

9В алгоритме SHA-1 проявились слабые стороны [SHA1-COLL], однако это не должно влиять на использование SHA1 с HMAC.

10В алгоритме MD5 проявились слабые стороны [MD5-COLL], однако это не должно влиять на использование MD5 с HMAC.

11IETF запрещает самостоятельное использование DES уже много лет и не включает этот алгоритм в новые стандарты в течение достаточного времени (см. комментарий IESG на первой странице [RFC2407]). [RFC4305] является первым проектом стандарта, в котором указано, что реализациям не следует использовать алгоритм DES самостоятельно (не в комбинации с другими, прим. перев.). Институт стандартов и технологий США (NIST) формально признал слабость DES при самостоятельном использовании в документе [DES-WDRAW], призывая прекратить использование этого алгоритма в качестве Государственного стандарта США. Алгоритм Triple DES по прежнему признается как IETF, так и NIST.

13Этот документ признан устаревшим и заменен RFC 5996, а затем RFC 7296Прим. перев.