doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

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]
+