Перевод RFC 4113

На главную

Network Working Group Request for Comments: 4113 Obsoletes: 2454, 2013 Category: Standards Track

B. Fenner

AT&T Labs - Research

J. Flick

Hewlett-Packard Company

June 2005

MIB для протокола UDP

Management Information Base for the User Datagram Protocol (UDP)

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

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

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

Тезисы

В этом документе определяется часть MIB¹ для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет управляемые объекты, которые используются для реализации протокола UDP² независимо от версии IP. Данный документ отменяет действие RFC 2013 и RFC 2454.

Оглавление

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

2. Обзор .............................................................

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

2.1.1. Связь с RFC1213-MIB ...............

2.1.2. Связь с IPV6-UDP-MIB .............

........................................................................................................................................2

........................................................................................................................................2

...........................................................................................................................................2

........................................................................................................................................2

............................................................................................................................................2

2.1.3. CBfl3bcHOST-RESOURCES-MIBHSYSAPPL-MIB................................................................................................................2

3. Определения.................................................................................................................................................................................................2

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

5. Участники........................................................................................................................................................................................11

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

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

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

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

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

¹Management Information Base ²User Datagram Protocol

rfc.com.ru

Перевод RFC 4113

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

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

Доступ к объектам обеспечивается через виртуальное хранилище информации, называемое MB. Доступ к объектам MB обычно обеспечивается с использованием протокола SNMP³. Объекты в базе MB определяются с использованием механизмов, определенных в SM⁴. В данном документе приводится спецификация модуля MB, которая соответствует стандарту SMv2, описанному в STD 58 ([RFC2578], [RFC2579] и [RFC2580]).

2. Обзор

В этом документе определяется часть MB для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет управляемые объекты, которые используются для реализации протокола UDP⁵ независимо от версии IP.

База UDP-MB, определяемая в этом документе состоит из одной таблицы и группы скаляров:

♦ Группа скаляров udp сообщает о параметрах и статистике протокола UDP. В эту группу после публикации RFC 2013 [RFC2013] были добавлены два скаляра udpHCInDatagrams и udpHCOutDatagrams, обеспечивающие возможность поддержки счетчиков для высокоскоростных сетей. Прекращается поддержка счетчиков sysUpTime, определенных в RFC 3418 [RFC3418].

♦ Таблица udpEndpointTable обеспечивает доступ к информации о состоянии для всех конечных точек UDP, обслуживаемых данным модулем протокола UDP. Информация в таблице обеспечивается как для традиционных прослушивающих точек с udpTable, так и для “подключенных” точек UDP, которые воспринимают пакеты только от заданной удаленной системы. Таблица также обеспечивает идентификацию процессов уровня операционной системы, которые обслуживают соединения UDP. Адреса и порты конечных точек UDP в этой таблице представлены с использованием текстовых соглашений InetAddressType, InetAddress и InetPortNumber, определенных в RFC 4001 [RFC4001].

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

В этом параграфе обсуждаются связи данного модуля UDP-MB с другими модулями MB.

2.1.1. Связь с RFC1213-MIB

Связанные с протоколом UDP объекты MB были изначально определены как часть RFC1213-MB в документе RFC 1213 [RFC1213]. Связанные с UDP объекты RFC1213-MB позднее были скопированы в отдельный модуль MB и опубликованы в RFC 2013 [RFC2013] с использованием формата SMv2. Обе предыдущие версии UDP-MB включают определение udpTable, которое признано устаревшим и отменено по двум причинам:

(1) udpTable поддерживает только IPv4.

Сейчас IETF предлагает создавать независимые от версии IP базы MB, а не различные варианты для разных версий протокола IP. Такой подход избавляет от лишних операций при определении новых объектов, поскольку они добавляются только в одну базу. Следовательно, опубликованное в RFC 2454 [RFC2454] предложение о поддержке разных таблиц утратило силу.

(2) Таблица udpTable не позволяет описывать “подключенные” конечные точки UDP.

“Подключенные” конечные точки отличаются по своему поведению и управлению от прослушивающих конечных точек. Добавление информации об удаленных конечных точках в таблицу udpEndpointTable позволяет добавлять специфические объекты для состояния и статистики “подключенных” конечных точек и соединений.

2.1.2. Связь с IPV6-UDP-MIB

База IPV6-UDP-MIB, определенная в RFC 2454 [RFC2454], была перемещена в число архивных по причине отказа от поддержки различных баз для разных версий протокола IP. Следовательно, реализация RFC 2454 не имеет смысла.

Отметим, что в силу того, что наблюдаемые в сети адреса представлены типами IPv4z и IPv6z, больше не возникает необходимости явного включения ifIndex в параграф index таблицы udpEndpointTable. Это является отличием от использования ipv6UdpIfIndex в RFC 2454.

2.1.3. Связь с HOST-RESOURCES-MIB и SYSAPPL-MIB

Таблица udpEndpointTable содержит идентификаторы процессов уровня операционной системы, которые обслуживают “подключенные” или прослушивающие конечные точки. Значение возвращается как Unsigned32 и предполагается, что это значение совпадает с hrSWRunIndex из HOST-RESOURCES-MIB [RFC2790] (если значение меньше 2147483647) или sysApplElmtRunIndex из SYSAPPL-MIB [RFC2287]. Такой подход позволяет управляющим приложениям идентифицировать соединения UDP, которые относятся к процессам уровня ОС и используют проверенную рабочую среду.

3. Определения

UDP-MIB DEFINITIONS ::= BEGIN

IMPORTS

MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Counter64, Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddress, InetAddressType, InetPortNumber FROM INET-ADDRESS-MIB;

udpMIB MODULE-IDENTITY

³Simple Network Management Protocol – простой протокол сетевого управления. ⁴Structure of Management Information – структура данных управления. ⁵User Datagram Protocol

rfc.com.ru 2 rfc.com.ru

Перево

LAST-UPDATED "200505200000Z" -- May 20, 2005 ORGANIZATION

"IETF IPv6 Working Group http://www.ietf.org/html.charters/ipv6-charter.html" CONTACT-INFO

"Bill Fenner (editor)

AT&T Labs -- Research

75 Willow Rd.

Menlo Park, CA 94025

Phone: +1 650 330-7893

Email: <fenner@research.att.com>

John Flick (editor)

Hewlett-Packard Company

8000 Foothills Blvd. M/S 5557

Roseville, CA 95747

Phone: +1 916 785 4018 Email: <john.flick@hp.com>

Send comments to <ipv6@ietf.org>"

DESCRIPTION⁶

"The MIB module for managing UDP implementations. Copyright (C) The Internet Society (2005). This version of this MIB module is part of RFC 4113; see the RFC itself for full legal notices."

REVISION "200505200000Z" -- May 20, 2005

DESCRIPTION⁷

"IP version neutral revision, incorporating the following revisions:

- Added udpHCInDatagrams and udpHCOutDatagrams in order to provide high-capacity counters for fast networks.

- Added text to the descriptions of all counter objects to indicate how discontinuities are detected.

- Deprecated the IPv4-specific udpTable and replaced it with the version neutral udpEndpointTable. This table includes support for connected UDP endpoints and support for identification of the operating system process associated with a UDP endpoint.

- Deprecated the udpGroup and replaced it with object groups representing the current set of objects.

- Deprecated udpMIBCompliance and replaced it with udpMIBCompliance2, which includes the compliance information for the new object groups.

This version published as RFC 4113." REVISION "199411010000Z" -- November 1, 1994 DESCRIPTION⁸

"Initial SMIv2 version, published as RFC 2013." REVISION "199103310000Z" -- March 31, 1991 DESCRIPTION⁹

"The initial revision of this MIB module was part of MIB-II, published as RFC 1213." ::= { mib-2 50 }

the UDP group¹⁰

⁶Модуль MB для управления реализациями протокола UDP. Авторские права принадлежать Internet Society (2005). Данная версия модуля MB является частью RFC 4113. Полная информация об авторских правах приведена в этом RFC. ⁷Не привязанный к версии протокола IP вариант, включающий следующие изменения:

♦ Добавлены udpHCInDatagrams и udpHCOutDatagrams для поддержки больших значения счетчиков в скоростных сетях.

♦ Добавлен текст в описание всех объектов, связанных со счетчиками, для индикации способа обнаружения разрывов в счете.

♦ Исключена связанная с IPv4 таблица udpTable и взамен включена таблица udpEndpointTable. Эта таблица включает поддержку подключенных конечных точек UDP и поддержку идентификации процессов ОС, связанных с конечной точкой UDP.

♦ Исключена группа udpGroup с включением взамен групп, представляющих текущий набор объектов.

♦ Взамен udpMBCompliance используется переменная udpMBCompliance2, которая включает информацию о соответствии стандарту для новых групп объектов.

Данная версия опубликована в RFC 4113.

⁸Изначальная версия SMv2, опубликованная как RFC 2013.

9Изначальная версия этого модуля MB являлась частью MIB-II, опубликованного как RFC 1213.

¹⁰Группа UDP______________________________________________________________________________________________________

rfc.com.ru 3 rfc.com.ru

Перевод RFC 4113

udp OBJECT IDENTIFIER ::= { mib-2 7 }

udpInDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION¹¹

"The total number of UDP datagrams delivered to UDP users.

Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 1 }

udpNoPorts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION

"The total number of received UDP datagrams for which there was no application at the destination port.

Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 2 }

udpInErrors OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION¹²

"The number of received UDP datagrams that could not be delivered for reasons other than the lack of an application at the destination port.

Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 3 }

udpOutDatagrams OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION¹³

"The total number of UDP datagrams sent from this entity.

Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 4 }

udpHCInDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION¹⁴

¹¹Общее число дейтаграмм UDP, доставленных пользователям UDP.

Разрывы в значениях этого счетчика могут происходить в момент реинициализации системы управления и другие моменты,

указываемые разрывами в значении sysUpTime.

¹²Число полученных дейтаграмм UDP, для которых адресат не имел соответствующего приложения.

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

указываемые разрывами в значении sysUpTime.

¹³Общее число дейтаграмм UDP, переданных с данного объекта.

указываемые разрывами в значении sysUpTime.

¹⁴Общее число дейтаграмм UDP, доставленных пользователям UDP для устройств, которые способны принимать более 1

миллиона дейтаграмм UDP в секунду.

rfc.com.ru 4 rfc.com.ru

Перевод RFC 4113

"The total number of UDP datagrams delivered to UDP users, for devices that can receive more than 1 million UDP datagrams per second.

Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 8 }

udpHCOutDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION¹⁵

"The total number of UDP datagrams sent from this entity, for devices that can transmit more than 1 million UDP datagrams per second.

Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 9 }

-- { udp 6 } was defined as the ipv6UdpTable in RFC2454's

-- IPV6-UDP-MIB. This RFC obsoletes RFC 2454, so { udp 6 } is

-- obsoleted¹⁶.

-- The UDP "Endpoint" table¹⁷.

udpEndpointTable OBJECT-TYPE

SYNTAX SEQUENCE OF UdpEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION¹⁸

"A table containing information about this entity's UDP endpoints on which a local application is currently accepting or sending datagrams.

The address type in this table represents the address type used for the communication, irrespective of the higher-layer abstraction. For example, an application using IPv6 'sockets' to communicate via IPv4 between ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use InetAddressType ipv4(1).

указываемые разрывами в значении sysUpTime.

¹⁵Общее число дейтаграмм UDP, переданных от данного объекта для устройств, которые могут передавать более 1 миллиона

дейтаграмм UDP в секунду.

указываемые разрывами в значении sysUpTime.

¹⁶Была определена как ipv6UdpTable в IPV6-UDP-MIB (RFC 2454). Данный документ отменяет RFC 2454 и { udp 6 } более не

используется.

¹⁷Таблица для конечной точки UDP

¹⁸Таблица, содержащая информацию о данной конечной точке UDP, где локальное приложение принимает или передает

дейтаграммы.

Тип адреса в этой таблице представляет тип адреса, используемого для обмена данными безотносительно к абстракции

вышележащего уровня. Например, приложение, применяющее “сокеты” IPv6 для обмена информацией через IPv4 между ::

ffff:10.0.0.1 и ::ffff:10.0.0.2, будет использовать InetAddressType ipv4(1).

В отличие от udpTable в RFC 2013 данная таблица также допускает представление приложений, которые полностью задают

локальные и удаленные адреса и номера портов. Прослушивающие приложения могут представляться тремя способами:

1) Приложение, которое готово принимать дейтаграммы IPv4 и IPv6, представляется udpEndpointLocalAddressType – unknown(0) и udpEndpointLocalAddress – ''h (строка октетов нулевой длины).

2) Приложение, которое готово принимать дейтаграммы только одного типа (IPv4 или IPv6), представляется udpEndpointLocalAddressType с подходящим типом адреса и udpEndpointLocalAddress – '0.0.0.0' или '::', соответственно.

3) Приложение, которое прослушивает дейтаграммы только для указанного адреса IP, но от любой удаленной системы, представляется udpEndpointLocalAddressType с подходящим типом адреса и значением udpEndpointLocalAddress, задающим локальный адрес.

Во всех случаях, когда удаленная сторона задается шаблоном, udpEndpointRemoteAddressType имеет значение unknown(0), udpEndpointRemoteAddress - ''h (строка октетов нулевой длины) и udpEndpointRemotePort – 0.

Если операционная система демультиплексирует пакеты UDP по адресам и портам удаленных систем или приложение имеет “подключенный” сокет, задающий используемый по умолчанию удаленный адрес и порт, значения udpEndpointRemote должны отражать это.

rfc.com.ru 5 rfc.com.ru

Перевод RFC 4113

Unlike the udpTable in RFC 2013, this table also allows the representation of an application that completely specifies both local and remote addresses and ports. A listening application is represented in three possible ways:

1) An application that is willing to accept both IPv4 and IPv6 datagrams is represented by a udpEndpointLocalAddressType of unknown(0) and a udpEndpointLocalAddress of ''h (a zero-length octet-string).

2) An application that is willing to accept only IPv4 or only IPv6 datagrams is represented by a udpEndpointLocalAddressType of the appropriate address type and a udpEndpointLocalAddress of '0.0.0.0' or '::' respectively.

3) An application that is listening for datagrams only for a specific IP address but from any remote system is represented by a

udpEndpointLocalAddressType of the appropriate address type, with udpEndpointLocalAddress specifying the local address.

In all cases where the remote is a wildcard, the udpEndpointRemoteAddressType is unknown(0), the udpEndpointRemoteAddress is ''h (a zero-length octet-string), and the udpEndpointRemotePort is 0.

If the operating system is demultiplexing UDP packets by remote address and port, or if the application has 'connected' the socket specifying a default remote address and port, the udpEndpointRemote* values should be used to reflect this." ::= { udp 7 }

udpEndpointEntry OBJECT-TYPE SYNTAX UdpEndpointEntry MAX-ACCESS not-accessible STATUS current

DESCRIPTION¹⁹

"Information about a particular current UDP endpoint.

Implementers need to be aware that if the total number of elements (octets or sub-identifiers) in udpEndpointLocalAddress and udpEndpointRemoteAddress exceeds 111, then OIDs of column instances in this table will have more than 128 sub-identifiers and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." INDEX { udpEndpointLocalAddressType,

udpEndpointLocalAddress,

udpEndpointLocalPort,

udpEndpointRemoteAddressType,

udpEndpointRemoteAddress,

udpEndpointRemotePort,

udpEndpointInstance } ::= { udpEndpointTable 1 }

UdpEndpointEntry ::= SEQUENCE {

udpEndpointLocalAddressType InetAddressType,

udpEndpointLocalAddress InetAddress,

udpEndpointLocalPort InetPortNumber,

udpEndpointRemoteAddressType InetAddressType,

udpEndpointRemoteAddress InetAddress,

udpEndpointRemotePort InetPortNumber,

udpEndpointInstance Unsigned32,

udpEndpointProcess Unsigned32 }

udpEndpointLocalAddressType OBJECT-TYPE

¹⁹Информация от отдельной конечной точке UDP.

Реализация должна быть готова к тому, что общее число элементов (октетов и субидентификаторов) в udpEndpointLocalAddress и udpEndpointRemoteAddress превышает 111. Тогда OID колонок экземпляров этой таблицы будут иметь более 128 субидентификаторов и не будут доступны для протоколов SNMPv1, SNMPv2c, SNMPv3

rfc.com.ru 6 rfc.com.ru

Пер

SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION²⁰

"The address type of udpEndpointLocalAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all local IP addresses are accepted." ::= { udpEndpointEntry 1 }

udpEndpointLocalAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION²¹

"The local IP address for this UDP endpoint.

The value of this object can be represented in three possible ways, depending on the characteristics of the listening application:

1. For an application that is willing to accept both IPv4 and IPv6 datagrams, the value of this object must be ''h (a zero-length octet-string), with the value of the corresponding instance of the udpEndpointLocalAddressType object being unknown(0).

2. For an application that is willing to accept only IPv4 or only IPv6 datagrams, the value of this object must be '0.0.0.0' or '::', respectively, while the corresponding instance of the

udpEndpointLocalAddressType object represents the appropriate address type.

3. For an application that is listening for data destined only to a specific IP address, the value of this object is the specific IP address for which this node is receiving packets, with the corresponding instance of the

udpEndpointLocalAddressType object representing the appropriate address type.

As this object is used in the index for the udpEndpointTable, implementors of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { udpEndpointEntry 2 }

udpEndpointLocalPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION²²

"The local port number for this UDP endpoint." ::= { udpEndpointEntry 3 }

udpEndpointRemoteAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current

²⁰Тип адреса udpEndpointLocalAddress. Ожидаются только адреса типов IPv4, IPv4z, IPv6, Ipv6z или unknown(0), если

принимаются дейтаграммы UDP для всех локальных адресов IP.

²¹Локальный IP-адрес данной конечной точки UDP.

Значение этого объекта может быть представлено тремя способами в зависимости от характеристик слушающего приложения:

1) Для приложений, которые готовы принимать дейтаграммы IPv4 и IPv6, значение этого объекта должно быть''h (строка октетов нулевой длины) со значением соответствующего экземпляра объекта udpEndpointLocalAddressType – unknown(0).

2) Для приложений, готовых принимать дейтаграммы только одного типа (IPv4 или IPv6), значение этого объекта должно быть '0.0.0.0' или '::', соответственно, тогда как соответствующий экземпляр объекта udpEndpointLocalAddressType представляет подходящий тип адреса.

3) Для приложений, которые слушают данные, направленные только в заданный адрес IP, значением этого объекта является этот IP-адрес, а соответствующий экземпляр udpEndpointLocalAddressType представляет подходящий тип адреса.

Когда этот объект используется в индексе для udpEndpointTable, разработчикам следует быть аккуратными, чтобы не создать записей, которые будут приводить к появлению OID с числом субидентификаторов, превышающим 128, поскольку в таких случаях информация не будет доступна для протоколов SNMPv1, SNMPv2c, SNMPv3. ²²Локальный номер порта для данной конечной точки UDP.

rfc.com.ru 7 rfc.com.ru

Перевод RFC 4113

DESCRIPTION²³

"The address type of udpEndpointRemoteAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all remote IP addresses are accepted. Also, note that some combinations of udpEndpointLocalAdressType and

udpEndpointRemoteAddressType are not supported. In particular, if the value of this object is not unknown(0), it is expected to always refer to the same IP version as udpEndpointLocalAddressType."

::= { udpEndpointEntry 4 }

udpEndpointRemoteAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION²⁴

"The remote IP address for this UDP endpoint. If datagrams from any remote system are to be accepted, this value is ''h (a zero-length octet-string). Otherwise, it has the type described by udpEndpointRemoteAddressType and is the address of the remote system from which datagrams are to be accepted (or to which all datagrams will be sent).

udpEndpointRemotePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION²⁵

"The remote port number for this UDP endpoint. If datagrams from any remote system are to be accepted, this value is zero." ::= { udpEndpointEntry 6 }

udpEndpointInstance OBJECT-TYPE

SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION²⁶

"The instance of this tuple. This object is used to distinguish among multiple processes 'connected' to the same UDP endpoint. For example, on a system implementing the BSD sockets interface, this would be used to support the SO_REUSEADDR and SO_REUSEPORT socket options."

::= { udpEndpointEntry 7 }

udpEndpointProcess OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current

²³Тип адреса udpEndpointRemoteAddress. Ожидаются только адреса типов IPv4, IPv4z, IPv6, Ipv6z или unknown(0), если

принимаются дейтаграммы UDP от всех удаленных адресов IP. Отметим также, что комбинации udpEndpointLocalAdressType и

udpEndpointRemoteAddressType не поддерживаются. В частности, если значение этого объекта отличается от unknown(0),

предполагается, что он указывает на ту же версию IP, что и udpEndpointLocalAddressType.

²⁴Удаленный адрес IP для данной конечной точки UDP. Если принимаются дейтаграммы от любой удаленной системы, это

значение должно быть ''h (строка октетов нулевой длины). В остальных случаях это значение имеет тип, описанный для

udpEndpointRemoteAddressType и является адресом удаленной точки, из которой принимаются дейтаграммы (или в которую они

передаются).

Когда этот объект используется в индексе для udpEndpointTable, разработчикам следует быть аккуратными, чтобы не создать

записей, которые будут приводить к появлению OID с числом субидентификаторов, превышающим 128, поскольку в таких

случаях информация не будет доступна для протоколов SNMPv1, SNMPv2c, SNMPv3.

²⁵Номер удаленного порта UDP для данной конечной точки UDP. Если принимаются дейтаграммы от любой удаленной системы,

это значение должно быть нулевым.

²⁶Экземпляр Удаленной точки. Этот объект используется для того, чтобы различать множество процессов, “подключенных” к

одной конечной точке UDP. Например, в системах, поддерживающих интерфейс сокетов BSD, этот объект может использоваться

для поддержки опций сокетов SO_REUSEADDR и SO_REUSEPORT.

rfc.com.ru 8 rfc.com.ru

Перевод

DESCRIPTION

"The system's process ID for the process associated with this endpoint, or zero if there is no such process. This value is expected to be the same as HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB:: sysApplElmtRunIndex for some row in the appropriate tables."

::= { udpEndpointEntry 8 }

The deprecated UDP Listener table²⁷

-- The deprecated UDP listener table only contains information -- about this entity's IPv4 UDP end-points on which a local -- application is currently accepting datagrams. It does not -- provide more detailed connection information, or information -- about IPv6 endpoints.

udpTable OBJECT-TYPE

SYNTAX SEQUENCE OF UdpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION²⁸

"A table containing IPv4-specific UDP listener information. It contains information about all local IPv4 UDP end-points on which an application is currently accepting datagrams. This table has been deprecated in favor of the version neutral udpEndpointTable." ::= { udp 5 }

udpEntry OBJECT-TYPE

SYNTAX UdpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION²⁹

"Information about a particular current UDP listener." INDEX { udpLocalAddress, udpLocalPort } ::= { udpTable 1 }

UdpEntry ::= SEQUENCE {

udpLocalAddress IpAddress,

udpLocalPort Integer32 }

udpLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION³⁰

"The local IP address for this UDP listener. In the case of a UDP listener that is willing to accept datagrams for any IP interface associated with the node, the value 0.0.0.0 is used." ::= { udpEntry 1 }

udpLocalPort OBJECT-TYPE

SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION³¹

"The local port number for this UDP listener." ::= { udpEntry 2 }

conformance information³²

²⁷Устаревшая таблица UDP Listener.

Эта таблица содержит только информацию конечных точках IPv4 данного объекта, на которых локальные приложения

принимают дейтаграммы. Более детальной информации или сведений о конечных точках IPv6 таблица не содержала.

²⁸Таблица содержит информацию IPv4 о “слушателях” UDP. Эта информация включает все локальные конечные точки IPv4, на

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

udpEndpointTable.

²⁹Информация об отдельном “слушателе” UDP.

³⁰Локальный IP-адрес “слушателя” UDP. В том случае, когда дейтаграммы UDP принимаются для всех IP-адресов данного узла,

используется значение 0.0.0.0.

³¹Локальный номер порта “слушателя” UDP.

³²Информация о соответствии спецификациям.

rfc.com.ru 9 rfc.com.ru

Перевод RFC 4113

udpMIBConformance OBJECT IDENTIFIER udpMIBCompliances OBJECT IDENTIFIER udpMIBGroups OBJECT IDENTIFIER

= { udpMIB 2 }

= { udpMIBConformance 1 }

= { udpMIBConformance 2 }

compliance statements³³

udpMIBCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION³⁴

"The compliance statement for systems that implement UDP.

There are a number of INDEX objects that cannot be represented in the form of OBJECT clauses in SMIv2, but for which we have the following compliance requirements, expressed in OBJECT clause form in this description clause:

-- OBJECT udpEndpointLocalAddressType -- SYNTAX InetAddressType { unknown(0), ipv4(1), -- ipv6(2), ipv4z(3),

-- ipv6z(4) }

-- DESCRIPTION³⁵

-- Support for dns(5) is not required. -- OBJECT udpEndpointLocalAddress -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION³⁶

-- Support is only required for zero-length -- octet-strings, and for scoped and unscoped -- IPv4 and IPv6 addresses. -- OBJECT udpEndpointRemoteAddressType -- SYNTAX InetAddressType { unknown(0), ipv4(1), -- ipv6(2), ipv4z(3),

-- ipv6z(4) }

-- DESCRIPTION³⁵

-- Support for dns(5) is not required. -- OBJECT udpEndpointRemoteAddress -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION³⁶

-- Support is only required for zero-length -- octet-strings, and for scoped and unscoped -- IPv4 and IPv6 addresses. " MODULE -- this module

MANDATORY-GROUPS { udpBaseGroup, udpEndpointGroup }

GROUP udpHCGroup

DESCRIPTION³⁷

"This group is mandatory for systems that are capable of receiving or transmitting more than 1 million UDP datagrams per second. 1 million datagrams per second will cause a Counter32 to wrap in just over an hour." ::= { udpMIBCompliances 2 }

udpMIBCompliance MODULE-COMPLIANCE STATUS deprecated DESCRIPTION³⁸

"The compliance statement for IPv4-only systems that implement UDP. For IP version independence, this compliance statement is deprecated in favor of udpMIBCompliance2. However, agents are still encouraged to implement these objects in order to interoperate with the deployed base of managers."

³³Заявления о соответствии.

³⁴Заявление о соответствии для систем, реализующих протокол UDP.

Существует множество объектов INDEX, которые не могут быть представлены в форме объектов (OBJECT) в SMIv2, но для

которых имеются следующие требования соответствия, выраженные ниже в форме объектов.

³⁵Поддержка dns(5) не требуется.

³⁶Поддержка требуется только для строк октетов нулевой длины и наблюдаемых или ненаблюдаемых адресов IPv4 и IPv6.

³⁷Эта группа является обязательной для систем, которые способны принимать или передавать более 1 миллиона дейтаграмм в

секунду. Скорость 1 миллион дейтаграмм в секунду будет приводить к переполнению счетчиков Counter32 в течение времени

чуть больше 1 часа.

³⁸Это заявление о соответствии для систем, поддерживающих только IPv4 и реализующих UDP. В целях обеспечения

независимости от версии протокола IP это заявление о совместимости отклонено в пользу независимого от версии

udpMIBCompliance2. Однако агенты по-прежнему поддерживают это заявление для обеспечения совместимости с

установленными программами сетевого управления.

rfc.com.ru

Перево

MODULE -- this module

MANDATORY-GROUPS { udpGroup } ::= { udpMIBCompliances 1 }

units of conformance³⁹

udpGroup OBJECT-GROUP

OBJECTS { udpInDatagrams, udpNoPorts,

udpInErrors, udpOutDatagrams, udpLocalAddress, udpLocalPort }

STATUS deprecated DESCRIPTION⁴⁰

"The deprecated group of objects providing for management of UDP over IPv4." ::= { udpMIBGroups 1 }

udpBaseGroup OBJECT-GROUP

OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors,

udpOutDatagrams } STATUS current DESCRIPTION⁴¹

"The group of objects providing for counters of UDP statistics." ::= { udpMIBGroups 2 }

udpHCGroup OBJECT-GROUP

OBJECTS { udpHCInDatagrams, udpHCOutDatagrams }

STATUS current

DESCRIPTION⁴²

"The group of objects providing for counters of high speed UDP implementations." ::= { udpMIBGroups 3 }

udpEndpointGroup OBJECT-GROUP

OBJECTS { udpEndpointProcess } STATUS current DESCRIPTION⁴³

"The group of objects providing for the IP version independent management of UDP 'endpoints'." ::= { udpMIBGroups 4 }

END

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

Этот документ содержит обновленные фрагменты RFC 1213 и заменяет собой RFC 2013 и 2454. Благодарим авторов и редакторов этих документов за прекрасно выполненную работу.

5. Участники

Этот документ является результатом работы команды по пересмотру IPv6 MIB и авторов предыдущих версий документа:

Bill Fenner, AT&T Labs -- Research

Email: fenner@research.at.com

Brian Haberman

Email: brian@innovationslab.net

Shawn A. Routhier, Wind River

Email: sar@epilogue.com

Juergen Schoenwalder, TU Braunschweig

Email: schoenw@ibr.cs.tu-bs.de

Dave Thaler, Microsoft

³⁹Элементы соответствия

⁴⁰Устаревшая группа объектов, обеспечивавшая управление UDP по протоколу IPv4.

⁴¹Группа объектов, обеспечивающая счетчики статистики UDP.

⁴²Группа объектов, обеспечивающая счетчики для высокоскоростных реализаций UDP.

⁴³Группа объектов, обеспечивающая независимое от версии IP управление конечными точками UDP.

rfc.com.ru 11 rfc.com.ru

Перевод RFC 4113

Email: dthaler@windows.microsoft.com

В документ включено много текста из RFC1213/RFC2013, подготовленных Keith McCloghrie, и структура MIB следует указанным документам.

Mike Daniele написал исходный документ IPv6 UDP MIB (RFC2454).

Juergen Schoenwalder подготовил много текста для раздела 2.

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

В данной базе MIB не определено объектов, которые имеют в MAX-ACCESS значение read-write и/или read-create. Следовательно, при корректной реализации MIB не возникает риска создания или изменения злоумышленником объектов в данном модуле MIB с помощью прямых операций SNMP SET.

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

Индексы таблиц udpEndpointTable и udpTable содержат информацию о “слушателях”. В частности, объекты udpEndpointLocalPort и udpLocalPort можно использовать для идентификации открытых портов и организации атаки на эти порты без использования сканера портов.

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

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

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

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

Модуль MIB, описанный в данном документе, использует следующие значения идентификаторов объекта, выделенные IANA и внесенные в реестр SMI Numbers:


	Дескриптор	Значение OBJECT IDENTIFIER
	udp	{ mib-2 7}
	udpMIB	{ mib-2 50 }

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

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

[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768⁴⁴, August 1980.

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

[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "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.

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

[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, "Textual Conventions for Internet Network Addresses", RFC 4001, February 2005.

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

[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets:MIB-II", STD 17, RFC 1213, March 1991.

[RFC2013] McCloghrie, K., "SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2", RFC 2013, November 1996.

[RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998.

[RFC2454] Daniele, M., "IP Version 6 Management Information Base for the User Datagram Protocol", RFC 2454, December 1998.

[RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 2790, March 2000.

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

⁴⁴Перевод этого стандарта имеется на сайте rfc.com.ru. Прим. перев.

rfc.com.ru 12

rfc.com.ru

Перевод RFC 4113

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

AT&T Labs -- Research

75 Willow Rd

Menlo Park, CA 94025

USA

EMail: fenner@research.att.com

John Flick

Hewlett-Packard Company

8000 Foothills Blvd. M/S 5557

Roseville, CA 95747-5557

USA

EMail: john.flick@hp.com

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

Николай Малых nmalykh@bilim.com

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

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

rfc.com.ru


	На главную




	Network Working Group Request for Comments: 4113 Obsoletes: 2454, 2013 Category: Standards Track			B. Fenner AT&T Labs - Research J. Flick Hewlett-Packard Company June 2005

	MIB для протокола UDP Management Information Base for the User Datagram Protocol (UDP)

	Статус документа Этот документ содержит стандарт протокола Internet, предложенного сообществу Internet, и служит приглашением к дискуссии в целях совершенствования и развития протокола. Текущее состояние стандартизации протокола можно узнать из документа "Internet Official Protocol Standards" (STD 1). Документ может распространяться свободно. Авторские права Copyright (C) The Internet Society (2005). Тезисы В этом документе определяется часть MIB¹ для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет управляемые объекты, которые используются для реализации протокола UDP² независимо от версии IP. Данный документ отменяет действие RFC 2013 и RFC 2454.

	Оглавление

	1. Стандартная модель управления Internet.. 2. Обзор ............................................................. 2.1. Связь с другими MIB ......................... 2.1.1. Связь с RFC1213-MIB ............... 2.1.2. Связь с IPV6-UDP-MIB .............			........................................................................................................................................2 ........................................................................................................................................2 ...........................................................................................................................................2 ........................................................................................................................................2 ............................................................................................................................................2

	2.1.3. CBfl3bcHOST-RESOURCES-MIBHSYSAPPL-MIB................................................................................................................2 3. Определения.................................................................................................................................................................................................2 4. Благодарности..............................................................................................................................................................................................11 5. Участники........................................................................................................................................................................................11 6. Вопросы безопасности..................................................................................................................................................................................12 7. Согласование с IANA....................................................................................................................................................................................12 8. Литература.................................................................................................................................................................................................12 8.1. Нормативные документы..................................................................................................................................................................12 8.2. Дополнительная литература.............................................................................................................................................................12

	¹Management Information Base ²User Datagram Protocol rfc.com.ru			rfc.com.ru



	Перевод RFC 4113 1. *Стандартная модель управления Internet* Детальный обзор документов, описывающих стандартную модель управления Internet, содержится в главе 7 RFC 3410 [RFC3410]. Доступ к объектам обеспечивается через виртуальное хранилище информации, называемое MB. Доступ к объектам MB обычно обеспечивается с использованием протокола SNMP³. Объекты в базе MB определяются с использованием механизмов, определенных в SM⁴. В данном документе приводится спецификация модуля MB, которая соответствует стандарту SMv2, описанному в STD 58 ([RFC2578], [RFC2579] и [RFC2580]). 2. *Обзор* В этом документе определяется часть MB для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет управляемые объекты, которые используются для реализации протокола UDP⁵ независимо от версии IP. База UDP-MB, определяемая в этом документе состоит из одной таблицы и группы скаляров: ♦ Группа скаляров udp сообщает о параметрах и статистике протокола UDP. В эту группу после публикации RFC 2013 [RFC2013] были добавлены два скаляра udpHCInDatagrams и udpHCOutDatagrams, обеспечивающие возможность поддержки счетчиков для высокоскоростных сетей. Прекращается поддержка счетчиков sysUpTime, определенных в RFC 3418 [RFC3418]. ♦ Таблица udpEndpointTable обеспечивает доступ к информации о состоянии для всех конечных точек UDP, обслуживаемых данным модулем протокола UDP. Информация в таблице обеспечивается как для традиционных прослушивающих точек с udpTable, так и для “подключенных” точек UDP, которые воспринимают пакеты только от заданной удаленной системы. Таблица также обеспечивает идентификацию процессов уровня операционной системы, которые обслуживают соединения UDP. Адреса и порты конечных точек UDP в этой таблице представлены с использованием текстовых соглашений InetAddressType, InetAddress и InetPortNumber, определенных в RFC 4001 [RFC4001]. 2.1. Связь с другими MIB В этом параграфе обсуждаются связи данного модуля UDP-MB с другими модулями MB. *2.1.1. Связь с RFC1213-MIB* Связанные с протоколом UDP объекты MB были изначально определены как часть RFC1213-MB в документе RFC 1213 [RFC1213]. Связанные с UDP объекты RFC1213-MB позднее были скопированы в отдельный модуль MB и опубликованы в RFC 2013 [RFC2013] с использованием формата SMv2. Обе предыдущие версии UDP-MB включают определение udpTable, которое признано устаревшим и отменено по двум причинам: (1) udpTable поддерживает только IPv4. Сейчас IETF предлагает создавать независимые от версии IP базы MB, а не различные варианты для разных версий протокола IP. Такой подход избавляет от лишних операций при определении новых объектов, поскольку они добавляются только в одну базу. Следовательно, опубликованное в RFC 2454 [RFC2454] предложение о поддержке разных таблиц утратило силу. (2) Таблица udpTable не позволяет описывать “подключенные” конечные точки UDP. “Подключенные” конечные точки отличаются по своему поведению и управлению от прослушивающих конечных точек. Добавление информации об удаленных конечных точках в таблицу udpEndpointTable позволяет добавлять специфические объекты для состояния и статистики “подключенных” конечных точек и соединений.

	*2.1.2. Связь с IPV6-UDP-MIB* База IPV6-UDP-MIB, определенная в RFC 2454 [RFC2454], была перемещена в число архивных по причине отказа от поддержки различных баз для разных версий протокола IP. Следовательно, реализация RFC 2454 не имеет смысла. Отметим, что в силу того, что наблюдаемые в сети адреса представлены типами IPv4z и IPv6z, больше не возникает необходимости явного включения ifIndex в параграф index таблицы udpEndpointTable. Это является отличием от использования ipv6UdpIfIndex в RFC 2454. *2.1.3. Связь с HOST-RESOURCES-MIB и SYSAPPL-MIB* Таблица udpEndpointTable содержит идентификаторы процессов уровня операционной системы, которые обслуживают “подключенные” или прослушивающие конечные точки. Значение возвращается как Unsigned32 и предполагается, что это значение совпадает с hrSWRunIndex из HOST-RESOURCES-MIB [RFC2790] (если значение меньше 2147483647) или sysApplElmtRunIndex из SYSAPPL-MIB [RFC2287]. Такой подход позволяет управляющим приложениям идентифицировать соединения UDP, которые относятся к процессам уровня ОС и используют проверенную рабочую среду. *3. Определения* UDP-MIB DEFINITIONS ::= BEGIN

	IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Counter64, Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMI MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF InetAddress, InetAddressType, InetPortNumber FROM INET-ADDRESS-MIB; udpMIB MODULE-IDENTITY

	³Simple Network Management Protocol – простой протокол сетевого управления. ⁴Structure of Management Information – структура данных управления. ⁵User Datagram Protocol rfc.com.ru 2 rfc.com.ru



	Перевод RFC 4113 "The total number of UDP datagrams delivered to UDP users, for devices that can receive more than 1 million UDP datagrams per second. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 8 } udpHCOutDatagrams OBJECT-TYPE SYNTAX Counter64 MAX-ACCESS read-only STATUS current DESCRIPTION¹⁵ "The total number of UDP datagrams sent from this entity, for devices that can transmit more than 1 million UDP datagrams per second. Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by discontinuities in the value of sysUpTime." ::= { udp 9 }

	-- { udp 6 } was defined as the ipv6UdpTable in RFC2454's -- IPV6-UDP-MIB. This RFC obsoletes RFC 2454, so { udp 6 } is -- obsoleted¹⁶.

	-- The UDP "Endpoint" table¹⁷. udpEndpointTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION¹⁸ "A table containing information about this entity's UDP endpoints on which a local application is currently accepting or sending datagrams. The address type in this table represents the address type used for the communication, irrespective of the higher-layer abstraction. For example, an application using IPv6 'sockets' to communicate via IPv4 between ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use InetAddressType ipv4(1).

	Разрывы значений этого счетчика могут происходить в моменты реинициализации системы управления другие моменты, указываемые разрывами в значении sysUpTime. ¹⁵Общее число дейтаграмм UDP, переданных от данного объекта для устройств, которые могут передавать более 1 миллиона дейтаграмм UDP в секунду. Разрывы значений этого счетчика могут происходить в моменты реинициализации системы управления другие моменты, указываемые разрывами в значении sysUpTime. ¹⁶Была определена как ipv6UdpTable в IPV6-UDP-MIB (RFC 2454). Данный документ отменяет RFC 2454 и { udp 6 } более не используется. ¹⁷Таблица для конечной точки UDP ¹⁸Таблица, содержащая информацию о данной конечной точке UDP, где локальное приложение принимает или передает дейтаграммы. Тип адреса в этой таблице представляет тип адреса, используемого для обмена данными безотносительно к абстракции вышележащего уровня. Например, приложение, применяющее “сокеты” IPv6 для обмена информацией через IPv4 между :: ffff:10.0.0.1 и ::ffff:10.0.0.2, будет использовать InetAddressType ipv4(1). В отличие от udpTable в RFC 2013 данная таблица также допускает представление приложений, которые полностью задают локальные и удаленные адреса и номера портов. Прослушивающие приложения могут представляться тремя способами: 1) Приложение, которое готово принимать дейтаграммы IPv4 и IPv6, представляется udpEndpointLocalAddressType – unknown(0) и udpEndpointLocalAddress – ''h (строка октетов нулевой длины). 2) Приложение, которое готово принимать дейтаграммы только одного типа (IPv4 или IPv6), представляется udpEndpointLocalAddressType с подходящим типом адреса и udpEndpointLocalAddress – '0.0.0.0' или '::', соответственно. 3) Приложение, которое прослушивает дейтаграммы только для указанного адреса IP, но от любой удаленной системы, представляется udpEndpointLocalAddressType с подходящим типом адреса и значением udpEndpointLocalAddress, задающим локальный адрес. Во всех случаях, когда удаленная сторона задается шаблоном, udpEndpointRemoteAddressType имеет значение unknown(0), udpEndpointRemoteAddress - ''h (строка октетов нулевой длины) и udpEndpointRemotePort – 0. Если операционная система демультиплексирует пакеты UDP по адресам и портам удаленных систем или приложение имеет “подключенный” сокет, задающий используемый по умолчанию удаленный адрес и порт, значения udpEndpointRemote должны отражать это. rfc.com.ru 5 rfc.com.ru



		Перевод RFC 4113
	DESCRIPTION²³ "The address type of udpEndpointRemoteAddress. Only IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or unknown(0) if datagrams for all remote IP addresses are accepted. Also, note that some combinations of udpEndpointLocalAdressType and udpEndpointRemoteAddressType are not supported. In particular, if the value of this object is not unknown(0), it is expected to always refer to the same IP version as udpEndpointLocalAddressType." ::= { udpEndpointEntry 4 } udpEndpointRemoteAddress OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION²⁴ "The remote IP address for this UDP endpoint. If datagrams from any remote system are to be accepted, this value is ''h (a zero-length octet-string). Otherwise, it has the type described by udpEndpointRemoteAddressType and is the address of the remote system from which datagrams are to be accepted (or to which all datagrams will be sent). As this object is used in the index for the udpEndpointTable, implementors of this table should be careful not to create entries that would result in OIDs with more than 128 subidentifiers; else the information cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." ::= { udpEndpointEntry 5 } udpEndpointRemotePort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS not-accessible STATUS current DESCRIPTION²⁵ "The remote port number for this UDP endpoint. If datagrams from any remote system are to be accepted, this value is zero." ::= { udpEndpointEntry 6 } udpEndpointInstance OBJECT-TYPE SYNTAX Unsigned32 (1..'ffffffff'h) MAX-ACCESS not-accessible STATUS current DESCRIPTION²⁶ "The instance of this tuple. This object is used to distinguish among multiple processes 'connected' to the same UDP endpoint. For example, on a system implementing the BSD sockets interface, this would be used to support the SO_REUSEADDR and SO_REUSEPORT socket options." ::= { udpEndpointEntry 7 } udpEndpointProcess OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current	Перевод RFC 4113

²³Тип адреса udpEndpointRemoteAddress. Ожидаются только адреса типов IPv4, IPv4z, IPv6, Ipv6z или unknown(0), если принимаются дейтаграммы UDP от всех удаленных адресов IP. Отметим также, что комбинации udpEndpointLocalAdressType и udpEndpointRemoteAddressType не поддерживаются. В частности, если значение этого объекта отличается от unknown(0), предполагается, что он указывает на ту же версию IP, что и udpEndpointLocalAddressType. ²⁴Удаленный адрес IP для данной конечной точки UDP. Если принимаются дейтаграммы от любой удаленной системы, это значение должно быть ''h (строка октетов нулевой длины). В остальных случаях это значение имеет тип, описанный для udpEndpointRemoteAddressType и является адресом удаленной точки, из которой принимаются дейтаграммы (или в которую они передаются). Когда этот объект используется в индексе для udpEndpointTable, разработчикам следует быть аккуратными, чтобы не создать записей, которые будут приводить к появлению OID с числом субидентификаторов, превышающим 128, поскольку в таких случаях информация не будет доступна для протоколов SNMPv1, SNMPv2c, SNMPv3. ²⁵Номер удаленного порта UDP для данной конечной точки UDP. Если принимаются дейтаграммы от любой удаленной системы, это значение должно быть нулевым. ²⁶Экземпляр Удаленной точки. Этот объект используется для того, чтобы различать множество процессов, “подключенных” к одной конечной точке UDP. Например, в системах, поддерживающих интерфейс сокетов BSD, этот объект может использоваться для поддержки опций сокетов SO_REUSEADDR и SO_REUSEPORT. rfc.com.ru 8 rfc.com.ru




	Перевод
	DESCRIPTION "The system's process ID for the process associated with this endpoint, or zero if there is no such process. This value is expected to be the same as HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB:: sysApplElmtRunIndex for some row in the appropriate tables." ::= { udpEndpointEntry 8 }


	The deprecated UDP Listener table²⁷ -- The deprecated UDP listener table only contains information -- about this entity's IPv4 UDP end-points on which a local -- application is currently accepting datagrams. It does not -- provide more detailed connection information, or information -- about IPv6 endpoints. udpTable OBJECT-TYPE SYNTAX SEQUENCE OF UdpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION²⁸ "A table containing IPv4-specific UDP listener information. It contains information about all local IPv4 UDP end-points on which an application is currently accepting datagrams. This table has been deprecated in favor of the version neutral udpEndpointTable." ::= { udp 5 } udpEntry OBJECT-TYPE SYNTAX UdpEntry MAX-ACCESS not-accessible STATUS deprecated DESCRIPTION²⁹ "Information about a particular current UDP listener." INDEX { udpLocalAddress, udpLocalPort } ::= { udpTable 1 } UdpEntry ::= SEQUENCE { udpLocalAddress IpAddress, udpLocalPort Integer32 } udpLocalAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS deprecated DESCRIPTION³⁰ "The local IP address for this UDP listener. In the case of a UDP listener that is willing to accept datagrams for any IP interface associated with the node, the value 0.0.0.0 is used." ::= { udpEntry 1 } udpLocalPort OBJECT-TYPE SYNTAX Integer32 (0..65535) MAX-ACCESS read-only STATUS deprecated DESCRIPTION³¹ "The local port number for this UDP listener." ::= { udpEntry 2 }


		conformance information³²

	²⁷Устаревшая таблица UDP Listener. Эта таблица содержит только информацию конечных точках IPv4 данного объекта, на которых локальные приложения принимают дейтаграммы. Более детальной информации или сведений о конечных точках IPv6 таблица не содержала. ²⁸Таблица содержит информацию IPv4 о “слушателях” UDP. Эта информация включает все локальные конечные точки IPv4, на которых приложения принимают дейтаграммы. Эта таблица запрещена в пользу независимой от версии IP таблицы udpEndpointTable. ²⁹Информация об отдельном “слушателе” UDP. ³⁰Локальный IP-адрес “слушателя” UDP. В том случае, когда дейтаграммы UDP принимаются для всех IP-адресов данного узла, используется значение 0.0.0.0. ³¹Локальный номер порта “слушателя” UDP. ³²Информация о соответствии спецификациям. rfc.com.ru 9 rfc.com.ru




	Перево	MODULE -- this module MANDATORY-GROUPS { udpGroup } ::= { udpMIBCompliances 1 } units of conformance³⁹


	udpGroup OBJECT-GROUP OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams, udpLocalAddress, udpLocalPort } STATUS deprecated DESCRIPTION⁴⁰ "The deprecated group of objects providing for management of UDP over IPv4." ::= { udpMIBGroups 1 } udpBaseGroup OBJECT-GROUP OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams } STATUS current DESCRIPTION⁴¹ "The group of objects providing for counters of UDP statistics." ::= { udpMIBGroups 2 } udpHCGroup OBJECT-GROUP OBJECTS { udpHCInDatagrams, udpHCOutDatagrams } STATUS current DESCRIPTION⁴² "The group of objects providing for counters of high speed UDP implementations." ::= { udpMIBGroups 3 } udpEndpointGroup OBJECT-GROUP OBJECTS { udpEndpointProcess } STATUS current DESCRIPTION⁴³ "The group of objects providing for the IP version independent management of UDP 'endpoints'." ::= { udpMIBGroups 4 } END *4. Благодарности* Этот документ содержит обновленные фрагменты RFC 1213 и заменяет собой RFC 2013 и 2454. Благодарим авторов и редакторов этих документов за прекрасно выполненную работу. *5. Участники* Этот документ является результатом работы команды по пересмотру IPv6 MIB и авторов предыдущих версий документа: Bill Fenner, AT&T Labs -- Research Email: fenner@research.at.com Brian Haberman Email: brian@innovationslab.net Shawn A. Routhier, Wind River Email: sar@epilogue.com Juergen Schoenwalder, TU Braunschweig Email: schoenw@ibr.cs.tu-bs.de Dave Thaler, Microsoft ³⁹Элементы соответствия ⁴⁰Устаревшая группа объектов, обеспечивавшая управление UDP по протоколу IPv4. ⁴¹Группа объектов, обеспечивающая счетчики статистики UDP. ⁴²Группа объектов, обеспечивающая счетчики для высокоскоростных реализаций UDP. ⁴³Группа объектов, обеспечивающая независимое от версии IP управление конечными точками UDP. rfc.com.ru 11 rfc.com.ru



Перевод RFC 4113

Адреса авторов Bill Fenner AT&T Labs -- Research 75 Willow Rd Menlo Park, CA 94025 USA EMail: fenner@research.att.com John Flick Hewlett-Packard Company 8000 Foothills Blvd. M/S 5557 Roseville, CA 95747-5557 USA EMail: john.flick@hp.com Перевод на русский язык Николай Малых nmalykh@bilim.com Полное заявление авторских прав Copyright (C) The Internet Society (2005). 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 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.

rfc.com.ru	13	rfc.com.ru