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).
Тезисы
В этом документе определяется часть MIB1 для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет управляемые объекты, которые используются для реализации протокола UDP2 независимо от версии 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
1Management Information Base 2User Datagram Protocol
                                                                                Перевод RFC 4113
1.  Стандартная модель управления Internet
Детальный обзор документов, описывающих стандартную модель управления Internet, содержится в главе 7 RFC 3410 [RFC3410].
Доступ к объектам обеспечивается через виртуальное хранилище информации, называемое MB. Доступ к объектам MB обычно обеспечивается с использованием протокола SNMP3. Объекты в базе MB определяются с использованием механизмов, определенных в SM4. В данном документе приводится спецификация модуля MB, которая соответствует стандарту SMv2, описанному в STD 58 ([RFC2578], [RFC2579] и [RFC2580]).
2.  Обзор
В этом документе определяется часть MB для использования с протоколами сетевого управления в сообществе Internet. В частности, документ определяет управляемые объекты, которые используются для реализации протокола UDP5 независимо от версии 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
3Simple Network Management Protocol – простой протокол сетевого управления. 4Structure of Management Information – структура данных управления. 5User 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
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>"
DESCRIPTION6
"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
DESCRIPTION7
"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 DESCRIPTION8
"Initial SMIv2 version, published as RFC 2013." REVISION "199103310000Z" -- March 31, 1991 DESCRIPTION9
"The initial revision of this MIB module was part of MIB-II, published as RFC 1213." ::= { mib-2 50 }
the UDP group10
6Модуль MB для управления реализациями протокола UDP. Авторские права принадлежать Internet Society (2005). Данная версия модуля MB является частью RFC 4113. Полная информация об авторских правах приведена в этом RFC. 7Не привязанный к версии протокола IP вариант, включающий следующие изменения:
♦    Добавлены udpHCInDatagrams и udpHCOutDatagrams для поддержки больших значения счетчиков в скоростных сетях.
♦    Добавлен текст в описание всех объектов, связанных со счетчиками, для индикации способа обнаружения разрывов в счете.
♦    Исключена связанная с IPv4 таблица udpTable и взамен включена таблица udpEndpointTable. Эта таблица включает поддержку подключенных конечных точек UDP и поддержку идентификации процессов ОС, связанных с конечной точкой UDP.
♦    Исключена группа udpGroup с включением взамен групп, представляющих текущий набор объектов.
♦    Взамен udpMBCompliance используется переменная udpMBCompliance2, которая включает информацию о соответствии стандарту для новых групп объектов.
Данная версия опубликована в RFC 4113.
8Изначальная версия SMv2, опубликованная как RFC 2013.
9Изначальная версия этого модуля MB являлась частью MIB-II, опубликованного как RFC 1213.
10Группа 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 DESCRIPTION11
"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 DESCRIPTION12
"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 DESCRIPTION13
"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 DESCRIPTION14
11Общее число дейтаграмм UDP, доставленных пользователям UDP.
Разрывы в значениях этого счетчика могут происходить в момент реинициализации системы управления и другие моменты,
указываемые разрывами в значении sysUpTime.
12Число полученных дейтаграмм UDP, для которых адресат не имел соответствующего приложения.
Разрывы значений этого счетчика могут происходить в моменты реинициализации системы управления другие моменты,
указываемые разрывами в значении sysUpTime.
13Общее число дейтаграмм UDP, переданных с данного объекта.
Разрывы значений этого счетчика могут происходить в моменты реинициализации системы управления другие моменты,
указываемые разрывами в значении sysUpTime.
14Общее число дейтаграмм 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 DESCRIPTION15
"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
-- obsoleted16.
-- The UDP "Endpoint" table17.
udpEndpointTable OBJECT-TYPE
SYNTAX SEQUENCE OF UdpEndpointEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION18
"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.
15Общее число дейтаграмм UDP, переданных от данного объекта для устройств, которые могут передавать более 1 миллиона
дейтаграмм UDP в секунду.
Разрывы значений этого счетчика могут происходить в моменты реинициализации системы управления другие моменты,
указываемые разрывами в значении sysUpTime.
16Была определена как ipv6UdpTable в IPV6-UDP-MIB (RFC 2454). Данный документ отменяет RFC 2454 и { udp 6 } более не
используется.
17Таблица для конечной точки UDP
18Таблица, содержащая информацию о данной конечной точке 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
DESCRIPTION19
"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
19Информация от отдельной конечной точке UDP.
Реализация должна быть готова к тому, что общее число элементов (октетов и субидентификаторов) в udpEndpointLocalAddress и udpEndpointRemoteAddress превышает 111. Тогда OID колонок экземпляров этой таблицы будут иметь более 128 субидентификаторов и не будут доступны для протоколов SNMPv1, SNMPv2c, SNMPv3
rfc.com.ru                                                                                     6                                                            rfc.com.ru
Пер
SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION20
"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 DESCRIPTION21
"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 DESCRIPTION22
"The local port number for this UDP endpoint." ::= { udpEndpointEntry 3 }
udpEndpointRemoteAddressType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current
20Тип адреса udpEndpointLocalAddress. Ожидаются только адреса типов IPv4, IPv4z, IPv6, Ipv6z или unknown(0), если
принимаются дейтаграммы UDP для всех локальных адресов IP.
21Локальный 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. 22Локальный номер порта для данной конечной точки UDP.
rfc.com.ru                                                                          7                                                                        rfc.com.ru
 
Перевод RFC 4113
DESCRIPTION23
"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 DESCRIPTION24
"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 DESCRIPTION25
"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 DESCRIPTION26
"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
23Тип адреса udpEndpointRemoteAddress. Ожидаются только адреса типов IPv4, IPv4z, IPv6, Ipv6z или unknown(0), если
принимаются дейтаграммы UDP от всех удаленных адресов IP. Отметим также, что комбинации udpEndpointLocalAdressType и
udpEndpointRemoteAddressType не поддерживаются. В частности, если значение этого объекта отличается от unknown(0),
предполагается, что он указывает на ту же версию IP, что и udpEndpointLocalAddressType.
24Удаленный адрес IP для данной конечной точки UDP. Если принимаются дейтаграммы от любой удаленной системы, это
значение должно быть ''h (строка октетов нулевой длины). В остальных случаях это значение имеет тип, описанный для
udpEndpointRemoteAddressType и является адресом удаленной точки, из которой принимаются дейтаграммы (или в которую они
передаются).
Когда этот объект используется в индексе для udpEndpointTable, разработчикам следует быть аккуратными, чтобы не создать
записей, которые будут приводить к появлению OID с числом субидентификаторов, превышающим 128, поскольку в таких
случаях информация не будет доступна для протоколов SNMPv1, SNMPv2c, SNMPv3.
25Номер удаленного порта UDP для данной конечной точки UDP. Если принимаются дейтаграммы от любой удаленной системы,
это значение должно быть нулевым.
26Экземпляр Удаленной точки. Этот объект используется для того, чтобы различать множество процессов, “подключенных” к
одной конечной точке 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 table27
-- 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 DESCRIPTION28
"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 DESCRIPTION29
"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 DESCRIPTION30
"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 DESCRIPTION31
"The local port number for this UDP listener." ::= { udpEntry 2 }
conformance information32
27Устаревшая таблица UDP Listener.
Эта таблица содержит только информацию конечных точках IPv4 данного объекта, на которых локальные приложения
принимают дейтаграммы. Более детальной информации или сведений о конечных точках IPv6 таблица не содержала.
28Таблица содержит информацию IPv4 о “слушателях” UDP. Эта информация включает все локальные конечные точки IPv4, на
которых приложения принимают дейтаграммы. Эта таблица запрещена в пользу независимой от версии IP таблицы
udpEndpointTable.
29Информация об отдельном “слушателе” UDP.
30Локальный IP-адрес “слушателя” UDP. В том случае, когда дейтаграммы UDP принимаются для всех IP-адресов данного узла,
используется значение 0.0.0.0.
31Локальный номер порта “слушателя” UDP.
32Информация о соответствии спецификациям.
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 statements33
udpMIBCompliance2 MODULE-COMPLIANCE STATUS current DESCRIPTION34
"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) }
-- DESCRIPTION35
-- Support for dns(5) is not required. -- OBJECT udpEndpointLocalAddress -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION36
-- 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) }
-- DESCRIPTION35
-- Support for dns(5) is not required. -- OBJECT udpEndpointRemoteAddress -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) -- DESCRIPTION36
-- 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
DESCRIPTION37
"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 DESCRIPTION38
"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."
33Заявления о соответствии.
34Заявление о соответствии для систем, реализующих протокол UDP.
Существует множество объектов INDEX, которые не могут быть представлены в форме объектов (OBJECT) в SMIv2, но для
которых имеются следующие требования соответствия, выраженные ниже в форме объектов.
35Поддержка dns(5) не требуется.
36Поддержка требуется только для строк октетов нулевой длины и наблюдаемых или ненаблюдаемых адресов IPv4 и IPv6.
37Эта группа является обязательной для систем, которые способны принимать или передавать более 1 миллиона дейтаграмм в
секунду. Скорость 1 миллион дейтаграмм в секунду будет приводить к переполнению счетчиков Counter32 в течение времени
чуть больше 1 часа.
38Это заявление о соответствии для систем, поддерживающих только IPv4 и реализующих UDP. В целях обеспечения
независимости от версии протокола IP это заявление о совместимости отклонено в пользу независимого от версии
udpMIBCompliance2. Однако агенты по-прежнему поддерживают это заявление для обеспечения совместимости с
установленными программами сетевого управления.
10
Перево
MODULE -- this module
MANDATORY-GROUPS { udpGroup } ::= { udpMIBCompliances 1 }
units of conformance39
udpGroup OBJECT-GROUP
OBJECTS { udpInDatagrams, udpNoPorts,
udpInErrors, udpOutDatagrams, udpLocalAddress, udpLocalPort }
STATUS deprecated DESCRIPTION40
"The deprecated group of objects providing for management of UDP over IPv4." ::= { udpMIBGroups 1 }
udpBaseGroup OBJECT-GROUP
OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors,
udpOutDatagrams } STATUS current DESCRIPTION41
"The group of objects providing for counters of UDP statistics." ::= { udpMIBGroups 2 }
udpHCGroup OBJECT-GROUP
OBJECTS { udpHCInDatagrams, udpHCOutDatagrams }
STATUS current
DESCRIPTION42
"The group of objects providing for counters of high speed UDP implementations." ::= { udpMIBGroups 3 }
udpEndpointGroup OBJECT-GROUP
OBJECTS { udpEndpointProcess } STATUS current DESCRIPTION43
"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
Brian Haberman
Shawn A. Routhier, Wind River
Juergen Schoenwalder, TU Braunschweig
Dave Thaler, Microsoft
39Элементы соответствия
40Устаревшая группа объектов, обеспечивавшая управление UDP по протоколу IPv4.
41Группа объектов, обеспечивающая счетчики статистики UDP.
42Группа объектов, обеспечивающая счетчики для высокоскоростных реализаций UDP.
43Группа объектов, обеспечивающая независимое от версии IP управление конечными точками UDP.
rfc.com.ru                                                                         11                                                                       rfc.com.ru
Перевод RFC 4113
В документ включено много текста из 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 76844, 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.
44Перевод этого стандарта имеется на сайте rfc.com.ru. Прим. перев.
rfc.com.ru                                                                                   12
Перевод RFC 4113
Адреса авторов Bill Fenner
AT&T Labs -- Research
75 Willow Rd
Menlo Park, CA 94025
USA
John Flick
Hewlett-Packard Company
8000 Foothills Blvd. M/S 5557
Roseville, CA 95747-5557
USA
Перевод на русский язык
Николай Малых 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.
13
гостиницы дешевые центр Москва ремонт принтеров canon, факсов.