idnits 2.17.1 draft-ietf-tsvwg-udplite-mib-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1195. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1206. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1213. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1219. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 29, 2007) is 6024 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area Working Group G. Renker 3 Internet-Draft G. Fairhurst 4 Intended status: Standards Track University of Aberdeen 5 Expires: May 1, 2008 October 29, 2007 7 MIB for the UDP-Lite protocol 8 draft-ietf-tsvwg-udplite-mib-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 1, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies a Management Information Base (MIB) module 42 for the Lightweight User Datagram Protocol. It defines a set of new 43 MIB objects to characterise the behaviour and performance of 44 transport layer endpoints deploying UDP-Lite. UDP-Lite resembles 45 UDP, but differs from the semantics of UDP by the addition of a 46 single option. This adds the capability for variable-length data 47 checksum coverage, which can benefit a class of applications that 48 prefer delivery of (partially) corrupted datagram payload data in 49 preference to discarding the datagram. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Relationship to the UDP-MIB . . . . . . . . . . . . . . . 3 55 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB . . . . 5 56 1.3. Interpretation of the MIB Variables . . . . . . . . . . . 5 57 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 8 58 2. The Internet-Standard Management Framework . . . . . . . . . . 9 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 23 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 32 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 32 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 67 Intellectual Property and Copyright Statements . . . . . . . . . . 35 69 1. Introduction 71 The Lightweight User Datagram Protocol (UDP-Lite) [RFC3828] (also 72 known as UDPLite) is an IETF standards-track transport protocol. The 73 operation of UDP-Lite is similar to the User Datagram Protocol (UDP) 74 [RFC0768], but can also serve applications in error-prone network 75 environments that prefer to have partially damaged payloads delivered 76 rather than discarded. This is achieved by changing the semantics of 77 the UDP Length field to that of a Checksum Coverage field. If this 78 feature is not used, UDP-Lite is semantically identical to UDP. 80 The interface of UDP-Lite differs from that of UDP by the addition of 81 a single option, which communicates a length value. At the sender 82 this specifies the intended datagram checksum coverage; at the 83 receiver it signifies a minimum coverage threshold for incoming 84 datagrams. This length value may also be modified during the 85 lifetime of a connection. UDP-Lite does not provide mechanisms to 86 negotiate the checksum coverage between the sender and receiver. 87 Where required, this needs to be communicated by another protocol. 88 DCCP [RFC4340] for instance includes a capability to negotiate 89 checksum coverage values. 91 This document defines a set of runtime statistics (variables) that 92 facilitate both network management/monitoring as well as unified 93 comparisons between different protocol implementations and operating 94 environments. To provide a common interface for users and 95 implementors of UDP-Lite modules, the definitions of these runtime 96 statistics are provided as a MIB module using the SMIv2 format 97 [RFC2578]. 99 1.1. Relationship to the UDP-MIB 101 The similarities between UDP and UDP-Lite suggest that the MIB module 102 for UDP-Lite should resemble that of UDP [RFC4113], with extensions 103 corresponding to the additional capabilities of UDP-Lite. The UDP- 104 Lite MIB module is placed beneath the mib-2 subtree, adhering to the 105 familiar structure of the UDP-MIB module to ease integration. 107 In particular, these well-known basic counters are supported: 109 o InDatagrams 111 o NoPorts 113 o InErrors 115 o OutDatagrams 116 The following read-only variables have been added to the basic 117 structure used in the UDP-MIB module: 119 InPartialCov: The number of received datagrams, with a valid 120 format and checksum, whose checksum coverage is strictly less than 121 the datagram length. 123 InBadChecksum: The number of received datagrams with an invalid 124 checksum (i.e. where the receiver-recalculated UDP-Lite checksum 125 does not match that in the Checksum field). Unlike NoPorts, this 126 error type also counts as InErrors. 128 OutPartialCov: The number of sent datagrams with a valid format 129 and checksum whose checksum coverage is strictly less than the 130 datagram length. 132 All non-error counters used in this document are 64-bit counters. 133 This is a departure from UDP, which traditionally used 32-bit 134 counters and mandates 64-bit counters only on fast networks 135 [RFC4113]. This choice is justified by the fact that UDP-Lite is a 136 more recent protocol, and that network speeds continue to grow. 138 Another difference from the UDP MIB module is that the UDP-Lite MIB 139 module does not support an IPv4-only listener table. This feature 140 was present only for compatibility reasons and is superseded by the 141 more informative endpoint table. Two columnar objects have been 142 added to this table: 144 udpliteEndpointMinCoverage: The minimum acceptable receiver 145 checksum coverage length [RFC3828]. This value may be manipulated 146 by the application attached to the receiving endpoint. 148 udpliteEndpointViolCoverage: This object is optional and counts 149 the number of valid datagrams with a checksum coverage value less 150 than the corresponding value of udpliteEndpointMinCoverage. 151 Although being otherwise valid, such datagrams are discarded 152 rather than passed to the application. This object thus serves to 153 separate cases of violated coverage from other InErrors. 155 The second entry is not required to manage the transport protocol and 156 hence is not mandatory. It may be implemented to assist in debugging 157 application design and configuration. 159 The UDP-Lite MIB module also provides a discontinuity object to help 160 determine whether one or more of its counters experienced a 161 discontinuity event. This is an event, other than re-initialising 162 the management system, which invalidates the management entity's 163 understanding of the counter values. 165 For example, if UDP-Lite is implemented as a loadable operating 166 system module, a module load or unload would produce a discontinuity. 167 By querying the value of udpliteStatsDiscontinuityTime, a management 168 entity can determine whether or not a discontinuity event has 169 occurred. 171 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB 173 The UDP-Lite endpoint table contains one columnar object, 174 udpliteEndpointProcess, reporting a unique value which identifies a 175 distinct piece of software associated with this endpoint. (When more 176 than one piece of software is associated with this endpoint, a 177 representative is chosen; so that consecutive queries consistently 178 refer to the same identifier, as long as the representative piece of 179 software is running and still associated with the endpoint.) 181 The value of udpliteEndpointProcess is reported as an Unsigned32; and 182 it shares with the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] 183 and the sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287] the 184 requirement that, wherever possible, this should be the native and 185 unique identification number employed by the system. 187 If the SYSAPPL-MIB module is available, the value of 188 udpliteEndpointProcess should correspond to the appropriate value of 189 sysApplElmtRunIndex. If not available, an alternative should be used 190 (e.g. the hrSWRunIndex of the HOST-RESOURCES-MIB module). 192 1.3. Interpretation of the MIB Variables 194 Figure 1 shows an informal survey of the packet processing path, with 195 reference to counter names in brackets. 197 Received UDP-Lite Datagrams 198 | 199 | +- Full Coverage ---------------------+-> Deliver 200 | | | 201 +- Valid Header--+ +- >= Rec. Coverage --+ 202 | (InDatagrams) | | 203 | +- Partial -----+ 204 | (InPartialCov) | 205 | +- < Rec. Coverage --+ 206 | (EndpointViolCoverage) | 207 | | 208 | | 209 +- Header Error ---+ | 210 | | | 211 +- Checksum Error -+-----------------------------------+-> Discard 212 | (InBadChecksum) (InErrors) 213 | 214 +- Port Error -------------------------------------------> Discard 215 (NoPorts) 217 Figure 1: UDP-Lite Input Processing Path 219 A platform-independent test of the UDP-Lite implementations in two 220 connected end hosts may be performed as follows. 222 On the sending side, OutDatagrams and OutPartialCov are observed. 223 The ratio OutPartialCov/OutDatagrams describes the fraction (between 224 0 and 1) of datagrams using partial checksum coverage. 226 On the receiving side, InDatagrams, InPartialCov, and InErrors are 227 monitored. If datagrams are received from the given sender, InErrors 228 is close to zero, and InPartialCov is zero, no partial coverage is 229 employed. If no datagrams are received and InErrors increases 230 proportionally with the sending rate, a configuration error is likely 231 (a wrong value of receiver minimum checksum coverage). 233 The InBadChecksum counter reflects errors that may persist following 234 end-host processing, router processing, or link processing (this 235 includes illegal coverage values as defined in [RFC3828], since 236 checksum and checksum coverage are mutually inter-dependent). In 237 particular, InBadChecksum can serve as an indicator of the residual 238 link bit error rate: on links with higher bit error rates, a lower 239 value of the checksum coverage may help to reduce both the values of 240 InErrors and InBadChecksum. 242 By observing these values and adapting the configuration, a setting 243 may then be found that is more adapted to the specific type of link, 244 as well as the type of payload; indicated by a reduction of the 245 number of discarded datagrams (InErrors), leading to an improved 246 performance. 248 The above statistics are elementary and can be used to derive the 249 following information: 251 o The total number of incoming datagrams is InDatagrams + InErrors + 252 NoPorts 254 o The number of InErrors that were discarded due to problems other 255 than bad checksum is InErrors - InBadChecksum 257 o The number of InDatagrams that have full coverage is InDatagrams - 258 InPartialCov. 260 o The number of OutDatagrams that have full coverage is OutDatagrams 261 - OutPartialCov. 263 The following Case diagram [CASE] summarises the relationships 264 between the counters on the input processing path. 266 Transport Layer Interface 267 ------------------------------------------------------------- 268 /\ 269 || 270 ----------------------------- InDatagrams 271 || ^ 272 || | 273 || | 274 ||----------------------> InPartialCov 275 || | 276 || | 277 || v 278 || EndpointViolCoverage 279 || | 280 NoPorts <--------|| | 281 || | 282 ||------> InBadChecksum ------>| 283 || | 284 || | 285 || v 286 ||------------------------> InErrors 287 || 288 || 289 ------------------------------------------------------------- 290 Network Layer Interface 292 Figure 2: Counters for received UDP-Lite Datagrams 294 A configuration error may occur when a sender chooses a coverage 295 value for the datagrams that it sends that is less than the minimum 296 coverage configured by the intended recipient. The minimum coverage 297 is set on a per-session basis by the application associated with the 298 listening endpoint, and its current value is recorded in the 299 udpliteEndpointTable. Reception of valid datagrams with a checksum 300 coverage value less than this threshold results in dropping the 301 datagram [RFC3828] and incrementing InErrors. To improve debugging 302 of such (misconfigured) cases, an implementer may choose to support 303 the optional udpliteEndpointViolCoverage entry in the endpoint table 304 (Section 1.1.) that specifically counts datagrams falling in this 305 category. Without this feature, failure due to misconfiguration can 306 not be distinguished from datagram processing failure. 308 1.4. Conventions 310 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 311 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 312 document are to be interpreted as described in BCP 14, [RFC2119]. 314 2. The Internet-Standard Management Framework 316 For a detailed overview of the documents that describe the current 317 Internet-Standard Management Framework, please refer to section 7 of 318 RFC 3410 [RFC3410]. 320 Managed objects are accessed via a virtual information store, termed 321 the Management Information Base or MIB. MIB objects are generally 322 accessed through the Simple Network Management Protocol (SNMP). 323 Objects in the MIB are defined using the mechanisms defined in the 324 Structure of Management Information (SMI). This memo specifies a MIB 325 module that is compliant to the SMIv2, which is described in STD 58, 326 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 327 [RFC2580]. 329 3. Definitions 331 UDPLITE-MIB DEFINITIONS ::= BEGIN 333 IMPORTS 334 MODULE-IDENTITY, 335 OBJECT-TYPE, 336 mib-2, Unsigned32, 337 Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578] 339 TimeStamp FROM SNMPv2-TC -- [RFC2579] 341 MODULE-COMPLIANCE, 342 OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] 344 InetAddress, 345 InetAddressType, 346 InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001] 348 udpliteMIB MODULE-IDENTITY 349 LAST-UPDATED "200710290000Z" -- Mon, 29th Oct 2007 350 ORGANIZATION "IETF TSV Working Group (TSVWG)" 351 CONTACT-INFO 352 "IETF TSV Working Group 353 http://www.ietf.org/html.charters/tsvwg-charter.html 354 Mailing List: tsvwg@ietf.org 356 Gerrit Renker, Godred Fairhurst 357 Electronics Research Group 358 School of Engineering, University of Aberdeen 359 Fraser Noble Building, Aberdeen AB24 3UE, UK" 360 DESCRIPTION 361 "The MIB module for managing UDP-Lite implementations. 362 Copyright (C) The IETF Trust (2007). This version of 363 this MIB module is part of RFC ZZZ; see the RFC 364 itself for full legal notices." 366 -- RFC Ed.: replace ZZZ with actual RFC number & remove this note 368 REVISION "200710290000Z" -- Mon, 29th Oct 2007 369 DESCRIPTION 370 "Initial SMIv2 revision, based on the format of the UDP 371 MIB module (RFC 4113) and published as RFC ZZZ." 373 -- RFC Ed.: replace ZZZ with actual RFC number & remove this note 375 ::= { mib-2 XXX } 377 -- RFC Ed.: replace XXX with OBJECT-IDENTIFIER & remove this note 379 udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 } 381 udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB 382 SYNTAX Counter64 383 MAX-ACCESS read-only 384 STATUS current 385 DESCRIPTION 386 "The total number of UDP-Lite datagrams that were 387 delivered to UDP-Lite users. 388 Discontinuities in the value of this counter can occur 389 at re-initialisation of the management system, and at 390 other times as indicated by the value of 391 udpliteStatsDiscontinuityTime." 392 ::= { udplite 1 } 394 udpliteInPartialCov OBJECT-TYPE -- new in UDP-Lite 395 SYNTAX Counter64 396 MAX-ACCESS read-only 397 STATUS current 398 DESCRIPTION 399 "The total number of UDP-Lite datagrams that were 400 delivered to UDP-Lite users (applications) and whose 401 checksum coverage was strictly less than the datagram 402 length. 403 Discontinuities in the value of this counter can occur 404 at re-initialisation of the management system, and at 405 other times as indicated by the value of 406 udpliteStatsDiscontinuityTime." 407 ::= { udplite 2 } 409 udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB 410 SYNTAX Counter32 411 MAX-ACCESS read-only 412 STATUS current 413 DESCRIPTION 414 "The total number of received UDP-Lite datagrams for 415 which there was no listener at the destination port. 417 Discontinuities in the value of this counter can occur 418 at re-initialisation of the management system, and at 419 other times as indicated by the value of 420 udpliteStatsDiscontinuityTime." 421 ::= { udplite 3 } 423 udpliteInErrors OBJECT-TYPE -- as in UDP-MIB 424 SYNTAX Counter32 425 MAX-ACCESS read-only 426 STATUS current 427 DESCRIPTION 428 "The number of received UDP-Lite datagrams that could not 429 be delivered for reasons other than the lack of an 430 application at the destination port. 431 Discontinuities in the value of this counter can occur 432 at re-initialisation of the management system, and at 433 other times as indicated by the value of 434 udpliteStatsDiscontinuityTime." 435 ::= { udplite 4 } 437 udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite 438 SYNTAX Counter32 439 MAX-ACCESS read-only 440 STATUS current 441 DESCRIPTION 442 "The number of received UDP-Lite datagrams whose checksum 443 could not be validated. This includes illegal checksum 444 coverage values, as their use would lead to incorrect 445 checksums. 446 Discontinuities in the value of this counter can occur 447 at re-initialisation of the management system, and at 448 other times as indicated by the value of 449 udpliteStatsDiscontinuityTime." 450 REFERENCE "RFC 3828, section 3.1" 451 ::= { udplite 5 } 453 udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB 454 SYNTAX Counter64 455 MAX-ACCESS read-only 456 STATUS current 457 DESCRIPTION 458 "The total number of UDP-Lite datagrams sent from this 459 entity. 460 Discontinuities in the value of this counter can occur 461 at re-initialisation of the management system, and at 462 other times as indicated by the value of 463 udpliteStatsDiscontinuityTime." 464 ::= { udplite 6 } 466 udpliteOutPartialCov OBJECT-TYPE -- new in UDP-Lite 467 SYNTAX Counter64 468 MAX-ACCESS read-only 469 STATUS current 470 DESCRIPTION 471 "The total number of udpliteOutDatagrams whose 472 checksum coverage was strictly less than the 473 datagram length. 474 Discontinuities in the value of this counter can occur 475 at re-initialisation of the management system, and at 476 other times as indicated by the value of 477 udpliteStatsDiscontinuityTime." 478 ::= { udplite 7 } 480 udpliteEndpointTable OBJECT-TYPE 481 SYNTAX SEQUENCE OF UdpLiteEndpointEntry 482 MAX-ACCESS not-accessible 483 STATUS current 484 DESCRIPTION 485 "A table containing information about this entity's 486 UDP-Lite endpoints on which a local application is 487 currently accepting or sending datagrams. 489 The address type in this table represents the address 490 type used for the communication, irrespective of the 491 higher-layer abstraction. For example, an application 492 using IPv6 'sockets' to communicate via IPv4 between 493 ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use 494 InetAddressType ipv4(1). 496 Like the udpTable in RFC 4113, this table also allows 497 the representation of an application that completely 498 specifies both local and remote addresses and ports. A 499 listening application is represented in three possible 500 ways: 502 1) An application that is willing to accept both IPv4 503 and IPv6 datagrams is represented by a 504 udpliteEndpointLocalAddressType of unknown(0) and a 505 udpliteEndpointLocalAddress of ''h (a zero-length 506 octet-string). 508 2) An application that is willing to accept only IPv4 509 or only IPv6 datagrams is represented by a 510 udpliteEndpointLocalAddressType of the appropriate 511 address type and a udpliteEndpointLocalAddress of 512 '0.0.0.0' or '::' respectively. 514 3) An application that is listening for datagrams only 515 for a specific IP address but from any remote 516 system is represented by a 517 udpliteEndpointLocalAddressType of the appropriate 518 address type, with udpliteEndpointLocalAddress 519 specifying the local address. 521 In all cases where the remote address is a wildcard, 522 the udpliteEndpointRemoteAddressType is unknown(0), 523 the udpliteEndpointRemoteAddress is ''h (a zero-length 524 octet-string), and the udpliteEndpointRemotePort is 0. 526 If the operating system is demultiplexing UDP-Lite 527 packets by remote address/port, or if the application 528 has 'connected' the socket specifying a default remote 529 address/port, the udpliteEndpointRemote* values should 530 be used to reflect this." 531 ::= { udplite 8 } 533 udpliteEndpointEntry OBJECT-TYPE 534 SYNTAX UdpLiteEndpointEntry 535 MAX-ACCESS not-accessible 536 STATUS current 537 DESCRIPTION 538 "Information about a particular current UDP-Lite endpoint. 540 Implementers need to pay attention to the sizes of 541 udpliteEndpointLocalAddress/RemoteAddress, as OIDs of 542 column instances in this table must have no more than 543 128 sub-identifiers in order to remain accessible with 544 SNMPv1, SNMPv2c, and SNMPv3." 545 INDEX { udpliteEndpointLocalAddressType, 546 udpliteEndpointLocalAddress, 547 udpliteEndpointLocalPort, 548 udpliteEndpointRemoteAddressType, 549 udpliteEndpointRemoteAddress, 550 udpliteEndpointRemotePort, 551 udpliteEndpointInstance } 552 ::= { udpliteEndpointTable 1 } 554 UdpLiteEndpointEntry ::= SEQUENCE { 555 udpliteEndpointLocalAddressType InetAddressType, 556 udpliteEndpointLocalAddress InetAddress, 557 udpliteEndpointLocalPort InetPortNumber, 558 udpliteEndpointRemoteAddressType InetAddressType, 559 udpliteEndpointRemoteAddress InetAddress, 560 udpliteEndpointRemotePort InetPortNumber, 561 udpliteEndpointInstance Unsigned32, 562 udpliteEndpointProcess Unsigned32, 563 udpliteEndpointMinCoverage Unsigned32, 564 udpliteEndpointViolCoverage Counter32 565 } 566 udpliteEndpointLocalAddressType OBJECT-TYPE 567 SYNTAX InetAddressType 568 MAX-ACCESS not-accessible 569 STATUS current 570 DESCRIPTION 571 "The address type of udpliteEndpointLocalAddress. Only 572 IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or 573 unknown(0) if datagrams for all local IP addresses are 574 accepted." 575 ::= { udpliteEndpointEntry 1 } 577 udpliteEndpointLocalAddress OBJECT-TYPE 578 SYNTAX InetAddress 579 MAX-ACCESS not-accessible 580 STATUS current 581 DESCRIPTION 582 "The local IP address for this UDP-Lite endpoint. 584 The value of this object can be represented in three 585 possible ways, depending on the characteristics of the 586 listening application: 588 1. For an application that is willing to accept both 589 IPv4 and IPv6 datagrams, the value of this object 590 must be ''h (a zero-length octet-string), with 591 the value of the corresponding instance of the 592 EndpointLocalAddressType object being unknown(0). 594 2. For an application that is willing to accept only 595 IPv4 or only IPv6 datagrams, the value of this 596 object must be '0.0.0.0' or '::', respectively, 597 while the corresponding instance of the 598 EndpointLocalAddressType object represents the 599 appropriate address type. 601 3. For an application that is listening for data 602 destined only to a specific IP address, the value 603 of this object is the specific IP address for 604 which this node is receiving packets, with the 605 corresponding instance of the 606 EndpointLocalAddressType object representing the 607 appropriate address type. 609 As this object is used in the index for the 610 udpliteEndpointTable, implementors should be careful 611 not to create entries that would result in OIDs with 612 more than 128 sub-identifiers; this is because of SNMP 613 and SMI limitations." 614 ::= { udpliteEndpointEntry 2 } 616 udpliteEndpointLocalPort OBJECT-TYPE 617 SYNTAX InetPortNumber 618 MAX-ACCESS not-accessible 619 STATUS current 620 DESCRIPTION 621 "The local port number for this UDP-Lite endpoint." 622 ::= { udpliteEndpointEntry 3 } 624 udpliteEndpointRemoteAddressType OBJECT-TYPE 625 SYNTAX InetAddressType 626 MAX-ACCESS not-accessible 627 STATUS current 628 DESCRIPTION 629 "The address type of udpliteEndpointRemoteAddress. Only 630 IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or 631 unknown(0) if datagrams for all remote IP addresses are 632 accepted. Also, note that some combinations of 633 udpliteEndpointLocalAdressType and 634 udpliteEndpointRemoteAddressType are not supported. In 635 particular, if the value of this object is not 636 unknown(0), it is expected to always refer to the 637 same IP version as udpliteEndpointLocalAddressType." 638 ::= { udpliteEndpointEntry 4 } 640 udpliteEndpointRemoteAddress OBJECT-TYPE 641 SYNTAX InetAddress 642 MAX-ACCESS not-accessible 643 STATUS current 644 DESCRIPTION 645 "The remote IP address for this UDP-Lite endpoint. If 646 datagrams from any remote system are to be accepted, 647 this value is ''h (a zero-length octet-string). 648 Otherwise, it has the type described by 649 udpliteEndpointRemoteAddressType and is the address of 650 the remote system from which datagrams are to be 651 accepted (or to which all datagrams will be sent). 653 As this object is used in the index for the 654 udpliteEndpointTable, implementors should be careful 655 not to create entries that would result in OIDs with 656 more than 128 sub-identifiers; this is because of SNMP 657 and SMI limitations." 658 ::= { udpliteEndpointEntry 5 } 660 udpliteEndpointRemotePort OBJECT-TYPE 661 SYNTAX InetPortNumber 662 MAX-ACCESS not-accessible 663 STATUS current 664 DESCRIPTION 665 "The remote port number for this UDP-Lite endpoint. If 666 datagrams from any remote system are to be accepted, 667 this value is zero." 668 ::= { udpliteEndpointEntry 6 } 670 udpliteEndpointInstance OBJECT-TYPE 671 SYNTAX Unsigned32 (1..'ffffffff'h) 672 MAX-ACCESS not-accessible 673 STATUS current 674 DESCRIPTION 675 "The instance of this tuple. This object is used to 676 distinguish among multiple processes 'connected' to 677 the same UDP-Lite endpoint. For example, on a system 678 implementing the BSD sockets interface, this would be 679 used to support the SO_REUSEADDR and SO_REUSEPORT 680 socket options." 681 ::= { udpliteEndpointEntry 7 } 683 udpliteEndpointProcess OBJECT-TYPE 684 SYNTAX Unsigned32 685 MAX-ACCESS read-only 686 STATUS current 687 DESCRIPTION 688 "A unique value corresponding to a piece of software 689 running on this endpoint. 691 If this endpoint is associated with more than one piece 692 of software, the agent should choose one of these; such 693 that subsequent reads will consistently return the same 694 value, as long as the representative piece of software 695 is running and still associated with the endpoint. The 696 implementation may use any algorithm satisfying these 697 constraints (e.g. choosing the entity with the oldest 698 start time). 700 This identifier is platform-specific. Wherever possible, 701 it should use the system's native, unique identification 702 number as value. 704 If the SYSAPPL-MIB module is available, the value should 705 be the same as sysApplElmtRunIndex. If not available, an 706 alternative should be used (e.g. the hrSWRunIndex of the 707 HOST-RESOURCES-MIB module). 709 If it is not possible to uniquely identify the pieces of 710 software associated with this endpoint, then the value 711 zero should be used. (Note that zero is otherwise a 712 valid value for sysApplElmtRunIndex.)" 713 ::= { udpliteEndpointEntry 8 } 715 udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite 716 SYNTAX Unsigned32 717 MAX-ACCESS read-only 718 STATUS current 719 DESCRIPTION 720 "The minimum checksum coverage expected by this endpoint. 721 A value of 0 indicates that only fully covered datagrams 722 are accepted." 723 REFERENCE "RFC 3828, section 3.1" 724 ::= { udpliteEndpointEntry 9 } 726 udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite 727 SYNTAX Counter32 728 MAX-ACCESS read-only 729 STATUS current 730 DESCRIPTION 731 "The number of datagrams received by this endpoint whose 732 checksum coverage violated the minimum coverage threshold 733 set for this connection (i.e. all valid datagrams whose 734 checksum coverage was strictly smaller than the minimum, 735 as defined in RFC 3828). 736 Discontinuities in the value of this counter can occur 737 at re-initialisation of the management system, and at 738 other times as indicated by the value of 739 udpliteStatsDiscontinuityTime." 740 ::= { udpliteEndpointEntry 10 } 742 udpliteStatsDiscontinuityTime OBJECT-TYPE 743 SYNTAX TimeStamp 744 MAX-ACCESS read-only 745 STATUS current 746 DESCRIPTION 747 "The value of sysUpTime at the most recent occasion at 748 which one or more of the UDP-Lite counters suffered a 749 discontinuity. 750 A value of zero indicates no such discontinuity has 751 occurred since the last re-initialisation of the local 752 management subsystem." 753 ::= { udplite 9 } 755 -- Conformance Information 757 udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 } 759 udpliteMIBCompliance MODULE-COMPLIANCE 760 STATUS current 761 DESCRIPTION 762 "The compliance statement for systems that implement 763 UDP-Lite. 765 There are a number of INDEX objects that cannot be 766 represented in the form of OBJECT clauses in SMIv2, 767 but for which we have the following compliance 768 requirements, expressed in OBJECT clause form in this 769 description clause: 771 -- OBJECT udpliteEndpointLocalAddressType 772 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 773 -- ipv6(2), ipv4z(3), 774 -- ipv6z(4) } 775 -- DESCRIPTION 776 -- Support for dns(16) is not required. 777 -- OBJECT udpliteEndpointLocalAddress 779 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 780 -- DESCRIPTION 781 -- Support is only required for zero-length 782 -- octet-strings, and for scoped and unscoped 783 -- IPv4 and IPv6 addresses. 784 -- OBJECT udpliteEndpointRemoteAddressType 785 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 786 -- ipv6(2), ipv4z(3), 787 -- ipv6z(4) } 788 -- DESCRIPTION 789 -- Support for dns(16) is not required. 790 -- OBJECT udpliteEndpointRemoteAddress 791 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 792 -- DESCRIPTION 793 -- Support is only required for zero-length 794 -- octet-strings, and for scoped and unscoped 795 -- IPv4 and IPv6 addresses. 796 " 797 MODULE -- this module 798 MANDATORY-GROUPS { udpliteBaseGroup, 799 udplitePartialCsumGroup, 800 udpliteEndpointGroup } 801 GROUP udpliteAppGroup 802 DESCRIPTION 803 "This group is optional and provides supplementary 804 information about the effectiveness of using minimum 805 checksum coverage thresholds on endpoints." 807 ::= { udpliteMIBConformance 1 } 809 udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 } 811 udpliteBaseGroup OBJECT-GROUP -- as in UDP 812 OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors, 813 udpliteOutDatagrams, udpliteStatsDiscontinuityTime } 814 STATUS current 815 DESCRIPTION 816 "The group of objects providing for counters of 817 basic UDP-like statistics." 818 ::= { udpliteMIBGroups 1 } 820 udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite 821 OBJECTS { udpliteInPartialCov, 822 udpliteInBadChecksum, 823 udpliteOutPartialCov } 824 STATUS current 825 DESCRIPTION 826 "The group of objects providing for counters of 827 transport-layer statistics exclusive to UDP-Lite." 828 ::= { udpliteMIBGroups 2 } 830 udpliteEndpointGroup OBJECT-GROUP 831 OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage } 832 STATUS current 833 DESCRIPTION 834 "The group of objects providing for the IP version 835 independent management of UDP-Lite 'endpoints'." 836 ::= { udpliteMIBGroups 3 } 838 udpliteAppGroup OBJECT-GROUP 839 OBJECTS { udpliteEndpointViolCoverage } 840 STATUS current 841 DESCRIPTION 842 "The group of objects that provide application-level 843 information for the configuration management of 844 UDP-Lite 'endpoints'." 845 ::= { udpliteMIBGroups 4 } 847 END 849 4. Security Considerations 851 There are no management objects defined in this MIB module that have 852 a MAX-ACCESS clause of read-write and/or read-create. So, if this 853 MIB module is implemented correctly, then there is no risk that an 854 intruder can alter or create any management objects of this MIB 855 module via direct SNMP SET operations. 857 Some of the readable objects in this MIB module (i.e., objects with a 858 MAX-ACCESS other than not-accessible) may be considered sensitive or 859 vulnerable in some network environments. It is thus important to 860 control even GET and/or NOTIFY access to these objects and possibly 861 to even encrypt the values of these objects when sending them over 862 the network via SNMP. These are the tables and objects and their 863 sensitivity/vulnerability: 865 Since UDP-Lite permits the delivery of (partially) corrupted data to 866 an end host, the counters defined in this MIB module may be used to 867 infer information about the characteristics of the end-to-end path 868 over which the datagrams are communicated. 870 The indices of the udpliteEndpointTable contain information about the 871 listeners on an entity. In particular, the udpliteEndpointLocalPort 872 and udpliteLocalPort objects in the indices can be used to identify 873 what ports are open on the machine and which attacks are likely to 874 succeed, without the attacker having to run a port scanner. The 875 table also identifies the currently listening UDP-Lite ports. This 876 could be used to infer the type of application associated with the 877 port at the receiver. The udpliteEndpointMinCoverage provides 878 information about the requirements of the transport service 879 associated with a specific UDP-Lite port. This provides additional 880 detail concerning the type of application associated with the port at 881 the receiver. 883 SNMP versions prior to SNMPv3 did not include adequate security. 884 Even if the network itself is secure (for example by using IPsec), 885 even then, there is no control as to who on the secure network is 886 allowed to access and GET/SET (read/change/create/delete) the objects 887 in this MIB module. 889 It is RECOMMENDED that implementers consider the security features as 890 provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), 891 including full support for the SNMPv3 cryptographic mechanisms (for 892 authentication and privacy). 894 Further, deployment of SNMP versions prior to SNMPv3 is NOT 895 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 896 enable cryptographic security. It is then a customer/operator 897 responsibility to ensure that the SNMP entity giving access to an 898 instance of this MIB module is properly configured to give access to 899 the objects only to those principals (users) that have legitimate 900 rights to indeed GET or SET (change/create/delete) them. 902 5. IANA Considerations 904 The MIB module in this document uses the following IANA-assigned 905 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 907 +------------+-------------------------+ 908 | Descriptor | OBJECT IDENTIFIER value | 909 +------------+-------------------------+ 910 | udpliteMIB | { mib-2 XXX } | 911 +------------+-------------------------+ 913 ==> Note to the RFC Editor (to be removed prior to publication): 915 The IANA is requested to assign a value for "XXX" under the 'mib-2' 916 subtree and to record the assignment in the SMI Numbers registry. 917 When the assignment has been made, the RFC Editor is asked to replace 918 "XXX" (here and in the MIB module) with the assigned value and to 919 remove this note. 921 6. Acknowledgments 923 The design of the MIB module presented in this document owes much to 924 the format of the module presented in [RFC4113]. 926 ==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION 928 Revision 00 of draft-ietf-tsvwg-udplite-mib was obsoleted by revision 929 01 due to a syntax error (quote transposed with full-stop) in the MIB 930 module, which is corrected in rev-01. Thanks to Magnus Westerlund 931 for identifying this. 933 Draft draft-ietf-tsvwg-udplite-mib-00 was published as a work item of 934 tsvwg, June 2007. 936 The following changelog lists the changes up to revision 02 (which 937 became rev-00/01 of this document) of the preceding individual draft 938 submission draft-renker-tsvwg-udplite-mib. 940 Changes introduced in rev-01: 942 o General: 944 - incremented revision number to 01 946 - updated date to November 948 - rephrased abstract 950 o Section 1: 952 - rephrased the beginning of the second paragraph 954 o Section 1.1: 956 - rephrased some items 958 - added missing InBadChecksum heading 960 - updated text to refer to 64bit counters 962 o Section 1.3: 964 - removed 'x' in 'datagrams' 966 - rephrased for clarity 968 - Figure 1: missing bracketed text should be InErrors 970 - Figure 1: correction - NoPorts are not counted as InDatagrams 972 o Section 2: 974 - made the "Editor's Note" stand out more 976 o Section 3 / MIB: 978 - upgraded 11 32bit counters to 64bit 980 - moved from experimental to mib-2 982 - updated revision date 984 o Section 4: 986 - some minor changes 988 o Section 5: 990 - again highlighted the Editor's Note by using `==>' to make it 991 consistent 993 Changes introduced in rev-02: 995 o General: 997 - updated month, date, and revision 999 - changed `transport layer entities' to `endpoints' in abstract 1001 o Section 1: 1003 - added missing comma after `option' 1005 - split explanatory clause after colon into standalone clause 1007 o Section 1.1: 1009 - added a bullet list of standard counters known from the UDP 1010 MIB 1012 - added a note that NoPorts does not increment InErrors 1014 - removed description of InBadCoverage (no longer in MIB, see 1015 below) 1017 - qualified note with on 64-bit counters wrt `non-error' 1018 counters, reflecting the change that all error counters have 1019 been changed to Counter32 1020 - Nit: changed `fairly recent' -> `more recent' 1022 - removed traces of InBadCoverage (see below) 1024 o Section 1.3: 1026 - corrected figure 1 (NoPorts was inconsistent with text; Rec 1027 Coverage was incorrectly labelled, it didn't show 1028 EndpointViolCoverage; slight reformatting) 1030 - Nit: `wrong value' -> `a wrong value' 1032 - clarified that InBadChecksum can also serve as indicator of 1033 path bit error rate 1035 - Nit: `which' -> `that' in `a setting may then ...' and `A 1036 configuration error may ...' 1038 - removed traces of InBadCoverage (see below) 1040 o Section 3 (the MIB): 1042 - updated LAST-UPDATED and REVISION to match the revision date 1044 - updated the Copyright in DESCRIPTION from 2006 to 2007 1046 - converted all error counters to Counter32, following IETF 1047 input for rev-01 1049 - added a required IMPORTS statement for Counter32 to UDPLITE- 1050 MIB DEFINITIONS 1052 - demoted the following error counters from Counter64 to 1053 Counter32: udpliteNoPorts, udpliteInErrors, 1054 updliteInBadChecksum, udpliteEndpointViolCoverage 1056 - removed second, redundant MIB-2 number of udplite, following 1057 suggestion by Bill Fenner. 1059 - updated warning about maximum number of sub-identifiers in 1060 udpliteEndpointEntry, to reflect new structure 1062 - udplite now comes as entry number 1 in the udpliteMIB tree 1064 - accordingly changed the identifier of udpliteMIBConformance 1065 to 2 1066 - updated all RFC editor notes with regard to the assignment of 1067 mib-2 identifier numbers (now only a single one required) 1069 - updated section `IANA Considerations' with regard to this 1070 change 1072 - removed the InBadCoverage counter since it is subsumed by 1073 InBadChecksum (see below) 1075 - updated the following identifier numbers for consistency 1076 after removal: udpliteInBadChecksum (6 -> 5), 1077 udpliteOutDatagrams (7 -> 6), udpliteOutPartialCov (8 -> 7), 1078 udpliteEndpointTable (9 -> 8) 1080 - removed udpliteInBadCoverage from udplitePartialCsumGroup 1082 - extended the definition of InBadChecksum to include invalid 1083 checksum coverage 1085 - added RFC 3828 references for udpliteEndpointMinCoverage and 1086 udpliteEndpointViolCoverage 1088 - updated the description of udpliteEndpointInstance with 1089 respect to draft-persson-v6ops-mib-issue-01.txt, section 3.2 1091 o Section 7 (References): 1093 - RFC 4113 (UDP MIB) becomes informative, not normative 1095 o Note on the removal of InBadCoverage: Following rev-01, this 1096 counter has been removed since - with the exception of obviously 1097 buggy UDP-Lite stacks - it is subsumed by InBadChecksum. An 1098 illegal checksum value which is not the cause of a buggy 1099 implementation will in practically all cases lead to an incorrect 1100 checksum value, so that one counter implies information inherent 1101 in the other. 1103 ====> END OF NOTE TO THE RFC EDITOR <==== 1105 7. References 1107 7.1. Normative References 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, March 1997. 1112 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1113 Rose, M., and S. Waldbusser, "Structure of Management 1114 Information Version 2 (SMIv2)", STD 58, RFC 2578, 1115 April 1999. 1117 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1118 Rose, M., and S. Waldbusser, "Textual Conventions for 1119 SMIv2", STD 58, RFC 2579, April 1999. 1121 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1122 Rose, M., and S. Waldbusser, "Conformance Statements for 1123 SMIv2", STD 58, RFC 2580, April 1999. 1125 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1126 G. Fairhurst, "The Lightweight User Datagram Protocol 1127 (UDP-Lite)", RFC 3828, July 2004. 1129 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1130 Schoenwaelder, "Textual Conventions for Internet Network 1131 Addresses", RFC 4001, February 2005. 1133 7.2. Informative References 1135 [CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to 1136 Diagrammed Management Information Bases", ACM Computer 1137 Communications Review, 19(1):13-16, January 1989. 1139 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1140 August 1980. 1142 [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level 1143 Managed Objects for Applications", RFC 2287, 1144 February 1998. 1146 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", 1147 RFC 2790, March 2000. 1149 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1150 "Introduction and Applicability Statements for Internet- 1151 Standard Management Framework", RFC 3410, December 2002. 1153 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 1154 the User Datagram Protocol (UDP)", RFC 4113, June 2005. 1156 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1157 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1159 Authors' Addresses 1161 Gerrit Renker 1162 University of Aberdeen 1163 School of Engineering 1164 Fraser Noble Building 1165 Aberdeen AB24 3UE 1166 Scotland 1168 Email: gerrit@erg.abdn.ac.uk 1169 URI: http://www.erg.abdn.ac.uk 1171 Godred Fairhurst 1172 University of Aberdeen 1173 School of Engineering 1174 Fraser Noble Building 1175 Aberdeen AB24 3UE 1176 Scotland 1178 Email: gorry@erg.abdn.ac.uk 1179 URI: http://www.erg.abdn.ac.uk 1181 Full Copyright Statement 1183 Copyright (C) The IETF Trust (2007). 1185 This document is subject to the rights, licenses and restrictions 1186 contained in BCP 78, and except as set forth therein, the authors 1187 retain all their rights. 1189 This document and the information contained herein are provided on an 1190 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1191 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1192 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1193 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1194 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1195 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1197 Intellectual Property 1199 The IETF takes no position regarding the validity or scope of any 1200 Intellectual Property Rights or other rights that might be claimed to 1201 pertain to the implementation or use of the technology described in 1202 this document or the extent to which any license under such rights 1203 might or might not be available; nor does it represent that it has 1204 made any independent effort to identify any such rights. Information 1205 on the procedures with respect to rights in RFC documents can be 1206 found in BCP 78 and BCP 79. 1208 Copies of IPR disclosures made to the IETF Secretariat and any 1209 assurances of licenses to be made available, or the result of an 1210 attempt made to obtain a general license or permission for the use of 1211 such proprietary rights by implementers or users of this 1212 specification can be obtained from the IETF on-line IPR repository at 1213 http://www.ietf.org/ipr. 1215 The IETF invites any interested party to bring to its attention any 1216 copyrights, patents or patent applications, or other proprietary 1217 rights that may cover technology that may be required to implement 1218 this standard. Please address the information to the IETF at 1219 ietf-ipr@ietf.org. 1221 Acknowledgment 1223 Funding for the RFC Editor function is provided by the IETF 1224 Administrative Support Activity (IASA).