From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5097.txt | 1291 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1291 insertions(+) create mode 100644 doc/rfc/rfc5097.txt (limited to 'doc/rfc/rfc5097.txt') diff --git a/doc/rfc/rfc5097.txt b/doc/rfc/rfc5097.txt new file mode 100644 index 0000000..4f12a7c --- /dev/null +++ b/doc/rfc/rfc5097.txt @@ -0,0 +1,1291 @@ + + + + + + +Network Working Group G. Renker +Request for Comments: 5097 G. Fairhurst +Category: Standards Track University of Aberdeen + January 2008 + + + MIB for the UDP-Lite Protocol + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document specifies a Management Information Base (MIB) module + for the Lightweight User Datagram Protocol (UDP-Lite). It defines a + set of new MIB objects to characterise the behaviour and performance + of transport layer endpoints deploying UDP-Lite. UDP-Lite resembles + UDP, but differs from the semantics of UDP by the addition of a + single option. This adds the capability for variable-length data + checksum coverage, which can benefit a class of applications that + prefer delivery of (partially) corrupted datagram payload data in + preference to discarding the datagram. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Relationship to the UDP-MIB ................................2 + 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB .........4 + 1.3. Interpretation of the MIB Variables ........................5 + 1.4. Conventions ................................................8 + 2. The Internet-Standard Management Framework ......................8 + 3. Definitions .....................................................8 + 4. Security Considerations ........................................19 + 5. IANA Considerations ............................................20 + 6. Acknowledgments ................................................20 + 7. References .....................................................20 + 7.1. Normative References ......................................20 + 7.2. Informative References ....................................21 + + + + + + + + +Renker & Fairhurst Standards Track [Page 1] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + +1. Introduction + + The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also + known as UDPLite) is an IETF standards-track transport protocol. The + operation of UDP-Lite is similar to the User Datagram Protocol (UDP) + [RFC768], but can also serve applications in error-prone network + environments that prefer to have partially damaged payloads delivered + rather than discarded. This is achieved by changing the semantics of + the UDP Length field to that of a Checksum Coverage field. If this + feature is not used, UDP-Lite is semantically identical to UDP. + + The interface of UDP-Lite differs from that of UDP by the addition of + a single option, which communicates a length value. At the sender + this specifies the intended datagram checksum coverage; at the + receiver it signifies a minimum coverage threshold for incoming + datagrams. This length value may also be modified during the + lifetime of a connection. UDP-Lite does not provide mechanisms to + negotiate the checksum coverage between the sender and receiver. + Where required, this needs to be communicated by another protocol. + The Datagram Congestion Control Protocol (DCCP) [RFC4340] for + instance includes a capability to negotiate checksum coverage values. + + This document defines a set of runtime statistics (variables) that + facilitate network management/monitoring as well as unified + comparisons between different protocol implementations and operating + environments. To provide a common interface for users and + implementors of UDP-Lite modules, the definitions of these runtime + statistics are provided as a MIB module using the SMIv2 format + [RFC2578]. + +1.1. Relationship to the UDP-MIB + + The similarities between UDP and UDP-Lite suggest that the MIB module + for UDP-Lite should resemble that of UDP [RFC4113], with extensions + corresponding to the additional capabilities of UDP-Lite. The UDP- + Lite MIB module is placed beneath the mib-2 subtree, adhering to the + familiar structure of the UDP-MIB module to ease integration. + + In particular, these well-known basic counters are supported: + + o InDatagrams + + o NoPorts + + o InErrors + + o OutDatagrams + + + + +Renker & Fairhurst Standards Track [Page 2] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + The following read-only variables have been added to the basic + structure used in the UDP-MIB module: + + InPartialCov: The number of received datagrams, with a valid + format and checksum, whose checksum coverage is strictly less than + the datagram length. + + InBadChecksum: The number of received datagrams with an invalid + checksum (i.e., where the receiver-recalculated UDP-Lite checksum + does not match that in the Checksum field). Unlike NoPorts, this + error type also counts as InErrors. + + OutPartialCov: The number of sent datagrams with a valid format + and checksum whose checksum coverage is strictly less than the + datagram length. + + All non-error counters used in this document are 64-bit counters. + This is a departure from UDP, which traditionally used 32-bit + counters and mandates 64-bit counters only on fast networks + [RFC4113]. This choice is justified by the fact that UDP-Lite is a + more recent protocol, and that network speeds continue to grow. + + Another difference from the UDP MIB module is that the UDP-Lite MIB + module does not support an IPv4-only listener table. This feature + was present only for compatibility reasons and is superseded by the + more informative endpoint table. Two columnar objects have been + added to this table: + + udpliteEndpointMinCoverage: The minimum acceptable receiver + checksum coverage length [RFC3828]. This value may be manipulated + by the application attached to the receiving endpoint. + + udpliteEndpointViolCoverage: This object is optional and counts + the number of valid datagrams with a checksum coverage value less + than the corresponding value of udpliteEndpointMinCoverage. + Although being otherwise valid, such datagrams are discarded + rather than passed to the application. This object thus serves to + separate cases of violated coverage from other InErrors. + + The second entry is not required to manage the transport protocol and + hence is not mandatory. It may be implemented to assist in debugging + application design and configuration. + + The UDP-Lite MIB module also provides a discontinuity object to help + determine whether one or more of its counters experienced a + discontinuity event. This is an event, other than re-initialising + the management system, that invalidates the management entity's + understanding of the counter values. + + + +Renker & Fairhurst Standards Track [Page 3] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + For example, if UDP-Lite is implemented as a loadable operating + system module, a module load or unload would produce a discontinuity. + By querying the value of udpliteStatsDiscontinuityTime, a management + entity can determine whether or not a discontinuity event has + occurred. + +1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB + + The UDP-Lite endpoint table contains one columnar object, + udpliteEndpointProcess, reporting a unique value that identifies a + distinct piece of software associated with this endpoint. (When more + than one piece of software is associated with this endpoint, a + representative is chosen, so that consecutive queries consistently + refer to the same identifier. The reported value is then consistent, + as long as the representative piece of software is running and still + associated with the endpoint.) + + The value of udpliteEndpointProcess is reported as an Unsigned32, and + it shares with the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] + and the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287] the + requirement that, wherever possible, this should be the native and + unique identification number employed by the system. + + If the SYSAPPL-MIB module is available, the value of + udpliteEndpointProcess should correspond to the appropriate value of + sysApplElmtRunIndex. If not available, an alternative should be used + (e.g., the hrSWRunIndex of the HOST-RESOURCES-MIB module). + + + + + + + + + + + + + + + + + + + + + + + + +Renker & Fairhurst Standards Track [Page 4] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + +1.3. Interpretation of the MIB Variables + + Figure 1 shows an informal survey of the packet processing path, with + reference to counter names in parentheses. + + Received UDP-Lite Datagrams + | + | +- Full Coverage ---------------------+-> Deliver + | | | + +- Valid Header--+ +- >= Rec. Coverage --+ + | (InDatagrams) | | + | +- Partial -----+ + | (InPartialCov) | + | +- < Rec. Coverage --+ + | (EndpointViolCoverage) | + | | + | | + +- Header Error ---+ | + | | | + +- Checksum Error -+-----------------------------------+-> Discard + | (InBadChecksum) (InErrors) + | + +- Port Error -------------------------------------------> Discard + (NoPorts) + + Figure 1: UDP-Lite Input Processing Path + + A platform-independent test of the UDP-Lite implementations in two + connected end hosts may be performed as follows. + + On the sending side, OutDatagrams and OutPartialCov are observed. + The ratio OutPartialCov/OutDatagrams describes the fraction (between + 0 and 1) of datagrams using partial checksum coverage. + + On the receiving side, InDatagrams, InPartialCov, and InErrors are + monitored. If datagrams are received from the given sender, InErrors + is close to zero, and InPartialCov is zero, no partial coverage is + employed. If no datagrams are received and InErrors increases + proportionally with the sending rate, a configuration error is likely + (a wrong value of receiver minimum checksum coverage). + + The InBadChecksum counter reflects errors that may persist following + end-host processing, router processing, or link processing (this + includes illegal coverage values as defined in [RFC3828], since + checksum and checksum coverage are mutually interdependent). In + particular, InBadChecksum can serve as an indicator of the residual + + + + + +Renker & Fairhurst Standards Track [Page 5] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + link bit error rate: on links with higher bit error rates, a lower + value of the checksum coverage may help to reduce the values of both + InErrors and InBadChecksum. By observing these values and adapting + the configuration, a setting may then be found that is more adapted + to the specific type of link, and the type of payload. In + particular, a reduction in the number of discarded datagrams + (InErrors), may indicate an improved performance. + + The above statistics are elementary and can be used to derive the + following information: + + o The total number of incoming datagrams is InDatagrams + InErrors + + NoPorts. + + o The number of InErrors that were discarded due to problems other + than a bad checksum is InErrors - InBadChecksum. + + o The number of InDatagrams that have full coverage is InDatagrams - + InPartialCov. + + o The number of OutDatagrams that have full coverage is OutDatagrams + - OutPartialCov. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Renker & Fairhurst Standards Track [Page 6] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + The following Case diagram [CASE] summarises the relationships + between the counters on the input processing path. + + Transport Layer Interface + ------------------------------------------------------------- + /\ + || + ----------------------------- InDatagrams + || ^ + || | + || | + ||----------------------> InPartialCov + || | + || | + || v + || EndpointViolCoverage + || | + NoPorts <--------|| | + || | + ||------> InBadChecksum ------>| + || | + || | + || v + ||------------------------> InErrors + || + || + ------------------------------------------------------------- + Network Layer Interface + + Figure 2: Counters for Received UDP-Lite Datagrams + + A configuration error may occur when a sender chooses a coverage + value for the datagrams that it sends that is less than the minimum + coverage configured by the intended recipient. The minimum coverage + is set on a per-session basis by the application associated with the + listening endpoint, and its current value is recorded in the + udpliteEndpointTable. Reception of valid datagrams with a checksum + coverage value less than this threshold results in dropping the + datagram [RFC3828] and incrementing InErrors. To improve debugging + of such (misconfigured) cases, an implementer may choose to support + the optional udpliteEndpointViolCoverage entry in the endpoint table + (Section 1.1) that specifically counts datagrams falling in this + category. Without this feature, failure due to misconfiguration can + not be distinguished from datagram processing failure. + + + + + + + +Renker & Fairhurst Standards Track [Page 7] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + +1.4. Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in BCP 14 [RFC2119]. + +2. The Internet-Standard Management Framework + + For a detailed overview of the documents that describe the current + Internet-Standard Management Framework, please refer to section 7 of + RFC 3410 [RFC3410]. + + Managed objects are accessed via a virtual information store, termed + the Management Information Base or MIB. MIB objects are generally + accessed through the Simple Network Management Protocol (SNMP). + Objects in the MIB are defined using the mechanisms defined in the + Structure of Management Information (SMI). This memo specifies a MIB + module that is compliant to the SMIv2, which is described in STD 58, + RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 + [RFC2580]. + +3. Definitions + + UDPLITE-MIB DEFINITIONS ::= BEGIN + + IMPORTS + MODULE-IDENTITY, + OBJECT-TYPE, + mib-2, Unsigned32, + Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578] + + TimeStamp FROM SNMPv2-TC -- [RFC2579] + + MODULE-COMPLIANCE, + OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] + + InetAddress, + InetAddressType, + InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001] + + udpliteMIB MODULE-IDENTITY + LAST-UPDATED "200712180000Z" -- 18 December 2007 + ORGANIZATION "IETF TSV Working Group (TSVWG)" + CONTACT-INFO + "IETF TSV Working Group + http://www.ietf.org/html.charters/tsvwg-charter.html + Mailing List: tsvwg@ietf.org + + + + +Renker & Fairhurst Standards Track [Page 8] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + Gerrit Renker, Godred Fairhurst + Electronics Research Group + School of Engineering, University of Aberdeen + Fraser Noble Building, Aberdeen AB24 3UE, UK" + DESCRIPTION + "The MIB module for managing UDP-Lite implementations. + Copyright (C) The IETF Trust (2008). This version of + this MIB module is part of RFC 5097; see the RFC + itself for full legal notices." + + REVISION "200712180000Z" -- 18 December 2007 + DESCRIPTION + "Initial SMIv2 revision, based on the format of the UDP + MIB module (RFC 4113) and published as RFC 5097." + ::= { mib-2 170 } + + udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 } + + udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of UDP-Lite datagrams that were + delivered to UDP-Lite users. + Discontinuities in the value of this counter can occur + at re-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + ::= { udplite 1 } + + udpliteInPartialCov OBJECT-TYPE -- new in UDP-Lite + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of UDP-Lite datagrams that were + delivered to UDP-Lite users (applications) and whose + checksum coverage was strictly less than the datagram + length. + Discontinuities in the value of this counter can occur + at re-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + ::= { udplite 2 } + + + + + + +Renker & Fairhurst Standards Track [Page 9] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of received UDP-Lite datagrams for + which there was no listener at the destination port. + Discontinuities in the value of this counter can occur + at re-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + ::= { udplite 3 } + + udpliteInErrors OBJECT-TYPE -- as in UDP-MIB + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received UDP-Lite 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-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + ::= { udplite 4 } + + udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of received UDP-Lite datagrams whose checksum + could not be validated. This includes illegal checksum + coverage values, as their use would lead to incorrect + checksums. + Discontinuities in the value of this counter can occur + at re-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + REFERENCE "RFC 3828, section 3.1" + ::= { udplite 5 } + + udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + + + +Renker & Fairhurst Standards Track [Page 10] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + "The total number of UDP-Lite datagrams sent from this + entity. + Discontinuities in the value of this counter can occur + at re-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + ::= { udplite 6 } + + udpliteOutPartialCov OBJECT-TYPE -- new in UDP-Lite + SYNTAX Counter64 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The total number of udpliteOutDatagrams whose + checksum coverage was strictly less than the + datagram length. + Discontinuities in the value of this counter can occur + at re-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + ::= { udplite 7 } + + udpliteEndpointTable OBJECT-TYPE + SYNTAX SEQUENCE OF UdpLiteEndpointEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "A table containing information about this entity's + UDP-Lite 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). + + Like the udpTable in RFC 4113, 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 + udpliteEndpointLocalAddressType of unknown(0) and a + udpliteEndpointLocalAddress of ''h (a zero-length + + + +Renker & Fairhurst Standards Track [Page 11] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + octet-string). + + 2) An application that is willing to accept only IPv4 + or only IPv6 datagrams is represented by a + udpliteEndpointLocalAddressType of the appropriate + address type and a udpliteEndpointLocalAddress 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 + udpliteEndpointLocalAddressType of the appropriate + address type, with udpliteEndpointLocalAddress + specifying the local address. + + In all cases where the remote address is a wildcard, + the udpliteEndpointRemoteAddressType is unknown(0), + the udpliteEndpointRemoteAddress is ''h (a zero-length + octet-string), and the udpliteEndpointRemotePort is 0. + + If the operating system is demultiplexing UDP-Lite + packets by remote address/port, or if the application + has 'connected' the socket specifying a default remote + address/port, the udpliteEndpointRemote* values should + be used to reflect this." + ::= { udplite 8 } + + udpliteEndpointEntry OBJECT-TYPE + SYNTAX UdpLiteEndpointEntry + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "Information about a particular current UDP-Lite endpoint. + Implementers need to pay attention to the sizes of + udpliteEndpointLocalAddress/RemoteAddress, as Object + Identifiers (OIDs) of column instances in this table must + have no more than 128 sub-identifiers in order to remain + accessible with SNMPv1, SNMPv2c, and SNMPv3." + INDEX { udpliteEndpointLocalAddressType, + udpliteEndpointLocalAddress, + udpliteEndpointLocalPort, + udpliteEndpointRemoteAddressType, + udpliteEndpointRemoteAddress, + udpliteEndpointRemotePort, + udpliteEndpointInstance } + ::= { udpliteEndpointTable 1 } + + UdpLiteEndpointEntry ::= SEQUENCE { + + + +Renker & Fairhurst Standards Track [Page 12] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + udpliteEndpointLocalAddressType InetAddressType, + udpliteEndpointLocalAddress InetAddress, + udpliteEndpointLocalPort InetPortNumber, + udpliteEndpointRemoteAddressType InetAddressType, + udpliteEndpointRemoteAddress InetAddress, + udpliteEndpointRemotePort InetPortNumber, + udpliteEndpointInstance Unsigned32, + udpliteEndpointProcess Unsigned32, + udpliteEndpointMinCoverage Unsigned32, + udpliteEndpointViolCoverage Counter32 + } + + udpliteEndpointLocalAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The address type of udpliteEndpointLocalAddress. Only + IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or + unknown(0) if datagrams for all local IP addresses are + accepted." + ::= { udpliteEndpointEntry 1 } + + udpliteEndpointLocalAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The local IP address for this UDP-Lite 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 + EndpointLocalAddressType 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 + EndpointLocalAddressType object represents the + appropriate address type. + + 3. For an application that is listening for data + + + +Renker & Fairhurst Standards Track [Page 13] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + 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 + EndpointLocalAddressType object representing the + appropriate address type. + + As this object is used in the index for the + udpliteEndpointTable, implementors should be careful + not to create entries that would result in OIDs with + more than 128 sub-identifiers; this is because of SNMP + and SMI limitations." + ::= { udpliteEndpointEntry 2 } + + udpliteEndpointLocalPort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The local port number for this UDP-Lite endpoint." + ::= { udpliteEndpointEntry 3 } + + udpliteEndpointRemoteAddressType OBJECT-TYPE + SYNTAX InetAddressType + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The address type of udpliteEndpointRemoteAddress. 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 + udpliteEndpointLocalAdressType and + udpliteEndpointRemoteAddressType 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 udpliteEndpointLocalAddressType." + ::= { udpliteEndpointEntry 4 } + + udpliteEndpointRemoteAddress OBJECT-TYPE + SYNTAX InetAddress + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The remote IP address for this UDP-Lite 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 + udpliteEndpointRemoteAddressType and is the address of + + + +Renker & Fairhurst Standards Track [Page 14] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + 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 + udpliteEndpointTable, implementors should be careful + not to create entries that would result in OIDs with + more than 128 sub-identifiers; this is because of SNMP + and SMI limitations." + ::= { udpliteEndpointEntry 5 } + + udpliteEndpointRemotePort OBJECT-TYPE + SYNTAX InetPortNumber + MAX-ACCESS not-accessible + STATUS current + DESCRIPTION + "The remote port number for this UDP-Lite endpoint. If + datagrams from any remote system are to be accepted, + this value is zero." + ::= { udpliteEndpointEntry 6 } + + udpliteEndpointInstance 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-Lite 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." + ::= { udpliteEndpointEntry 7 } + + udpliteEndpointProcess OBJECT-TYPE + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "A unique value corresponding to a piece of software + running on this endpoint. + + If this endpoint is associated with more than one piece + of software, the agent should choose one of these. As + long as the representative piece of software + is running and still associated with the endpoint, + subsequent reads will consistently return the same + value. The implementation may use any algorithm + satisfying these constraints (e.g., choosing the entity + + + +Renker & Fairhurst Standards Track [Page 15] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + with the oldest start time). + + This identifier is platform-specific. Wherever possible, + it should use the system's native, unique identification + number as the value. + + If the SYSAPPL-MIB module is available, the value should + be the same as sysApplElmtRunIndex. If not available, an + alternative should be used (e.g., the hrSWRunIndex of the + HOST-RESOURCES-MIB module). + + If it is not possible to uniquely identify the pieces of + software associated with this endpoint, then the value + zero should be used. (Note that zero is otherwise a + valid value for sysApplElmtRunIndex.)" + ::= { udpliteEndpointEntry 8 } + + udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite + SYNTAX Unsigned32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The minimum checksum coverage expected by this endpoint. + A value of 0 indicates that only fully covered datagrams + are accepted." + REFERENCE "RFC 3828, section 3.1" + ::= { udpliteEndpointEntry 9 } + + udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite + SYNTAX Counter32 + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The number of datagrams received by this endpoint whose + checksum coverage violated the minimum coverage threshold + set for this connection (i.e., all valid datagrams whose + checksum coverage was strictly smaller than the minimum, + as defined in RFC 3828). + Discontinuities in the value of this counter can occur + at re-initialisation of the management system, and at + other times as indicated by the value of + udpliteStatsDiscontinuityTime." + ::= { udpliteEndpointEntry 10 } + + + + + + + + +Renker & Fairhurst Standards Track [Page 16] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + udpliteStatsDiscontinuityTime OBJECT-TYPE + SYNTAX TimeStamp + MAX-ACCESS read-only + STATUS current + DESCRIPTION + "The value of sysUpTime at the most recent occasion at + which one or more of the UDP-Lite counters suffered a + discontinuity. + A value of zero indicates no such discontinuity has + occurred since the last re-initialisation of the local + management subsystem." + ::= { udplite 9 } + + -- Conformance Information + + udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 } + + udpliteMIBCompliance MODULE-COMPLIANCE + STATUS current + DESCRIPTION + "The compliance statement for systems that implement + UDP-Lite. + + 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 udpliteEndpointLocalAddressType + -- SYNTAX InetAddressType { unknown(0), ipv4(1), + -- ipv6(2), ipv4z(3), + -- ipv6z(4) } + -- DESCRIPTION + -- Support for dns(16) is not required. + -- OBJECT udpliteEndpointLocalAddress + -- 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 udpliteEndpointRemoteAddressType + -- SYNTAX InetAddressType { unknown(0), ipv4(1), + -- ipv6(2), ipv4z(3), + -- ipv6z(4) } + -- DESCRIPTION + -- Support for dns(16) is not required. + -- OBJECT udpliteEndpointRemoteAddress + + + +Renker & Fairhurst Standards Track [Page 17] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + -- 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 { udpliteBaseGroup, + udplitePartialCsumGroup, + udpliteEndpointGroup } + GROUP udpliteAppGroup + DESCRIPTION + "This group is optional and provides supplementary + information about the effectiveness of using minimum + checksum coverage thresholds on endpoints." + ::= { udpliteMIBConformance 1 } + + udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 } + + udpliteBaseGroup OBJECT-GROUP -- as in UDP + OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors, + udpliteOutDatagrams, udpliteStatsDiscontinuityTime } + STATUS current + DESCRIPTION + "The group of objects providing for counters of + basic UDP-like statistics." + ::= { udpliteMIBGroups 1 } + + udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite + OBJECTS { udpliteInPartialCov, + udpliteInBadChecksum, + udpliteOutPartialCov } + STATUS current + DESCRIPTION + "The group of objects providing for counters of + transport layer statistics exclusive to UDP-Lite." + ::= { udpliteMIBGroups 2 } + + udpliteEndpointGroup OBJECT-GROUP + OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage } + STATUS current + DESCRIPTION + "The group of objects providing for the IP version + independent management of UDP-Lite 'endpoints'." + ::= { udpliteMIBGroups 3 } + + + + + + +Renker & Fairhurst Standards Track [Page 18] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + udpliteAppGroup OBJECT-GROUP + OBJECTS { udpliteEndpointViolCoverage } + STATUS current + DESCRIPTION + "The group of objects that provide application-level + information for the configuration management of + UDP-Lite 'endpoints'." + ::= { udpliteMIBGroups 4 } + + END + +4. Security Considerations + + There are no management objects defined in this MIB module that have + a MAX-ACCESS clause of read-write and/or read-create. So, if this + MIB module is implemented correctly, then there is no risk that an + intruder can alter or create any management objects of this MIB + module via direct SNMP SET operations. + + Some of the readable objects in this MIB module (i.e., objects with a + MAX-ACCESS other than not-accessible) may be considered sensitive or + vulnerable in some network environments. It is thus important to + control even GET and/or NOTIFY access to these objects and possibly + to even encrypt the values of these objects when sending them over + the network via SNMP. These are the tables and objects and their + sensitivity/vulnerability: + + The indices of the udpliteEndpointTable contain information about the + listeners on an entity. In particular, the udpliteEndpointLocalPort + index objects can be used to identify ports that are open on the + machine and which attacks are likely to succeed, without the attacker + having to run a port scanner. The table also identifies the + currently listening UDP-Lite ports. + + The udpliteEndpointMinCoverage provides information about the + requirements of the transport service associated with a specific + UDP-Lite port. This provides additional detail concerning the type + of application associated with the port at the receiver. + + Since UDP-Lite permits the delivery of (partially) corrupted data to + an end host, the counters defined in this MIB module may be used to + infer information about the characteristics of the end-to-end path + over which the datagrams are communicated. This information could be + used to infer the type of application associated with the port at the + receiver. + + SNMP versions prior to SNMPv3 did not include adequate security. + Even if the network itself is secure (for example by using IPsec), + + + +Renker & Fairhurst Standards Track [Page 19] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + even then, there is no control as to who on the secure network is + allowed to access and GET/SET (read/change/create/delete) the objects + in this MIB module. + + It is RECOMMENDED that implementers consider the security features as + provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), + including full support for the SNMPv3 cryptographic mechanisms (for + authentication and privacy). + + Further, deployment of SNMP versions prior to SNMPv3 is NOT + RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to + enable cryptographic security. It is then a customer/operator + responsibility to ensure that the SNMP entity giving access to an + instance of this MIB module is properly configured to give access to + the objects only to those principals (users) that have legitimate + rights to indeed GET or SET (change/create/delete) them. + +5. IANA Considerations + + The MIB module in this document uses the following IANA-assigned + OBJECT IDENTIFIER values recorded in the SMI Numbers registry: + + +------------+-------------------------+ + | Descriptor | OBJECT IDENTIFIER value | + +------------+-------------------------+ + | udpliteMIB | { mib-2 170 } | + +------------+-------------------------+ + +6. Acknowledgments + + The design of the MIB module presented in this document owes much to + the format of the module presented in [RFC4113]. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, April + 1999. + + [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, "Textual Conventions for + SMIv2", STD 58, RFC 2579, April 1999. + + + +Renker & Fairhurst Standards Track [Page 20] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + + [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., + Rose, M., and S. Waldbusser, "Conformance Statements for + SMIv2", STD 58, RFC 2580, April 1999. + + [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and + G. Fairhurst, "The Lightweight User Datagram Protocol + (UDP-Lite)", RFC 3828, July 2004. + + [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. + Schoenwaelder, "Textual Conventions for Internet Network + Addresses", RFC 4001, February 2005. + +7.2. Informative References + + [CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to + Diagrammed Management Information Bases", ACM Computer + Communications Review, 19(1):13-16, January 1989. + + [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level + Managed Objects for Applications", RFC 2287, February + 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. + + [RFC4113] Fenner, B. and J. Flick, "Management Information Base for + the User Datagram Protocol (UDP)", RFC 4113, June 2005. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, March 2006. + + + + + + + + + + + + + + +Renker & Fairhurst Standards Track [Page 21] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + +Authors' Addresses + + Gerrit Renker + University of Aberdeen + School of Engineering + Fraser Noble Building + Aberdeen AB24 3UE + Scotland + + EMail: gerrit@erg.abdn.ac.uk + URI: http://www.erg.abdn.ac.uk + + + Godred Fairhurst + University of Aberdeen + School of Engineering + Fraser Noble Building + Aberdeen AB24 3UE + Scotland + + EMail: gorry@erg.abdn.ac.uk + URI: http://www.erg.abdn.ac.uk + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Renker & Fairhurst Standards Track [Page 22] + +RFC 5097 MIB for the UDP-Lite Protocol January 2008 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2008). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + 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. + + + + + + + + + + + + +Renker & Fairhurst Standards Track [Page 23] + -- cgit v1.2.3