idnits 2.17.1 draft-renker-tsvwg-udplite-mib-02.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 1073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1091. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1097. 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 (April 27, 2007) is 6209 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: October 29, 2007 April 27, 2007 7 MIB for the UDP-Lite protocol 8 draft-renker-tsvwg-udplite-mib-02 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 October 29, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document specifies a Management Information Base (MIB) for the 42 Lightweight User Datagram Protocol (UDP-Lite, RFC 3828). It defines 43 a set of new MIB entities to characterise the behaviour and 44 performance of transport layer endpoints deploying UDP-Lite. UDP- 45 Lite resembles UDP (RFC 768), but differs from the semantics of UDP 46 by the addition of a single (socket) option. This adds the 47 capability for variable-length data checksum coverage, which can 48 benefit a class of applications that prefer delivery of (partially) 49 corrupted datagram payload data in preference to discarding the 50 datagram. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Relationship to the UDP-MIB . . . . . . . . . . . . . . . 3 56 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB . . . . 4 57 1.3. Interpretation of the MIB Variables . . . . . . . . . . . 5 58 2. The Internet-Standard Management Framework . . . . . . . . . . 7 59 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 62 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 30 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 30 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 67 Intellectual Property and Copyright Statements . . . . . . . . . . 32 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 (socket) option, which communicates a length value. At the 82 sender 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 using the SMIv2 format [RFC2578]. 98 1.1. Relationship to the UDP-MIB 100 The similarities between UDP and UDP-Lite suggest that the MIB for 101 UDP-Lite should resemble the MIB for UDP [RFC4113], with extensions 102 corresponding to the additional capabilities of UDP-Lite. The UDP- 103 Lite MIB is placed beneath the mib-2 subtree, adhering to the 104 familiar structure of the UDP MIB [RFC4113] to ease integration. 106 In particular, these well-known basic counters are supported: 108 o InDatagrams 110 o NoPorts 112 o InErrors 114 o OutDatagrams 116 The following read-only variables have been added to the basic 117 structure used in the UDP MIB: 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 contrast to UDP is that the UDP-Lite MIB does not support an 139 IPv4-only listener table. This feature was present only for 140 compatibility reasons and is superseded by the more informative 141 endpoint table. Two columnar objects have been added to this table: 143 udpliteEndpointMinCoverage: The minimum acceptable receiver 144 checksum coverage length [RFC3828]. This value may be manipulated 145 by the application attached to the receiving endpoint. 147 udpliteEndpointViolCoverage: This object is optional and counts 148 the number of valid datagrams with a checksum coverage value less 149 than the corresponding value of udpliteEndpointMinCoverage. 150 Although being otherwise valid, such datagrams are discarded 151 rather than passed to the application. This object thus serves to 152 separate cases of violated coverage from other InErrors. 154 The second entry is not required to manage the transport protocol and 155 hence is not mandatory. It may be implemented to assist in debugging 156 application design and configuration. 158 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB 160 The endpoint table of [RFC4113] contains one columnar object, also 161 used in this MIB, which reports the identification of the operating- 162 system-level process handling a connection or a listening endpoint. 163 The value is reported as an Unsigned32, which is expected to be the 164 same as the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] (if the 165 value is smaller than 2147483647) or the sysApplElmtRunIndex of the 166 SYSAPPL-MIB [RFC2287]. 168 1.3. Interpretation of the MIB Variables 170 A platform-independent test of the UDP-Lite implementations in two 171 connected end hosts may be performed as follows. 173 On the sending side, OutDatagrams and OutPartialCov are observed. If 174 both values are equal, no partial coverage is employed. On the 175 receiving side, InDatagrams, InPartialCov, and InErrors are 176 monitored. If datagrams are received from the given sender, InErrors 177 is close to zero, and InPartialCov is zero, no partial coverage is 178 employed. If no datagrams are received and InErrors increases 179 proportionally with the sending rate, a configuration error is likely 180 (a wrong value of receiver minimum checksum coverage). 182 The InBadChecksum counter reflects errors that may persist following 183 end-host processing, router processing, or link processing (this 184 includes illegal coverage values as defined in [RFC3828], since 185 checksum and checksum coverage are mutually inter-dependent). In 186 particular, InBadChecksum can serve as an indicator of the residual 187 link bit error rate: on links with higher bit error rates, a lower 188 value of the checksum coverage may help to reduce both the values of 189 InErrors and InBadChecksum. 191 By observing these values and adapting the configuration, a setting 192 may then be found that is more adapted to the specific type of link, 193 as well as the type of payload; indicated by a reduction of the 194 number of discarded datagrams (InErrors), leading to an improved 195 performance. 197 The above statistics are elementary and can be used to derive the 198 following information: 200 o The total number of incoming datagrams is InDatagrams + InErrors + 201 NoPorts 203 o The number of InErrors that were discarded due to problems other 204 than bad checksum is InErrors - InBadChecksum 206 o The number of InDatagrams that have full coverage is InDatagrams - 207 InPartialCov. 209 o The number of OutDatagrams that have full coverage is OutDatagrams 210 - OutPartialCov. 212 A configuration error may occur when a sender chooses a coverage 213 value for the datagrams that it sends that is less than the minimum 214 coverage configured by the intended recipient. The minimum coverage 215 is set on a per-session basis by the application associated with the 216 listening endpoint, and its current value is recorded in the 217 udpliteEndpointTable. Reception of valid datagrams with a checksum 218 coverage value less than this threshold results in dropping the 219 datagram [RFC3828] and incrementing InErrors. To improve debugging 220 of such (misconfigured) cases, an implementer may choose to support 221 the optional udpliteEndpointViolCoverage entry in the endpoint table 222 (Section 1.1.) that specifically counts datagrams falling in this 223 category. Without this feature, failure due to misconfiguration can 224 not be distinguished from datagram processing failure. 226 Figure 1 summarises the roles of the various receiver counters. 228 Received Datagrams 229 | 230 | +-Full Coverage ----------------------+---> Deliver 231 | | | 232 + InDatagrams -+ +-- >= Rec Coverage ---+ 233 | | | 234 | +-InPartialCov-+ 235 | | 236 | +-- < Rec Coverage ---+ 237 | (EndpointViolCoverage) | 238 | | 239 | | 240 + InBadChecksum -------------------------------------+---> Discard 241 | (InErrors) 242 | 243 + NoPorts -----------------------------------------------> Discard 245 Figure 1: Counters for received UDP-Lite Datagrams 247 2. The Internet-Standard Management Framework 249 For a detailed overview of the documents that describe the current 250 Internet-Standard Management Framework, please refer to section 7 of 251 RFC 3410 [RFC3410]. 253 Managed objects are accessed via a virtual information store, termed 254 the Management Information Base or MIB. MIB objects are generally 255 accessed through the Simple Network Management Protocol (SNMP). 256 Objects in the MIB are defined using the mechanisms defined in the 257 Structure of Management Information (SMI). This memo specifies a MIB 258 module that is compliant to the SMIv2, which is described in STD 58, 259 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 260 [RFC2580]. 262 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 263 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 264 document are to be interpreted as described in BCP 14, RFC 2119 265 [RFC2119]. 267 ==> RFC Editor's Note (please replace XXX with IANA value): 269 The MIB module in this document uses the following IANA-assigned 270 value, to be recorded in the SMI Numbers registry: 272 +------------+-------------------------+ 273 | Descriptor | OBJECT IDENTIFIER value | 274 +------------+-------------------------+ 275 | udpliteMIB | { mib-2 XXX } | 276 +------------+-------------------------+ 278 Table 1: UDP-Lite Object Identifier 280 3. Definitions 282 UDPLITE-MIB DEFINITIONS ::= BEGIN 283 IMPORTS 284 MODULE-IDENTITY, OBJECT-TYPE, mib-2, 285 Unsigned32, Counter32, Counter64 FROM SNMPv2-SMI 286 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 287 InetAddress, InetAddressType, 288 InetPortNumber FROM INET-ADDRESS-MIB; 290 udpliteMIB MODULE-IDENTITY 291 LAST-UPDATED "200704190000Z" -- Thu, 19th Apr 2007 292 ORGANIZATION 293 "Electronics Research Group at the University of 294 Aberdeen, UK" 295 CONTACT-INFO 296 "Electronics Research Group 297 Department of Engineering, University of Abderdeen 298 Fraser Noble Building, Aberdeen AB24 3UE, UK 300 Phone: +44 1224 27 2813 301 Email: gerrit@erg.abdn.ac.uk" 302 DESCRIPTION 303 "The MIB module for managing UDP-Lite implementations. 304 Copyright (C) The Internet Society (2007). This 305 version of this MIB module is part of RFC ZZZ; 306 see the RFC itself for full legal notices." 308 -- RFC Ed.: replace ZZZ with actual RFC number & remove this note 310 REVISION "200704190000Z" -- Thu, 19th Apr 2007 311 DESCRIPTION 312 "Initial SMIv2 revision, based on the format of 313 the UDP MIB (RFC 4113) and published as RFC ZZZ." 315 -- RFC Ed.: replace ZZZ with actual RFC number & remove this note 317 ::= { mib-2 XXX } 319 -- RFC Ed.: replace XXX with OBJECT-IDENTIFIER & remove this note 321 udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 } 322 udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB 323 SYNTAX Counter64 324 MAX-ACCESS read-only 325 STATUS current 326 DESCRIPTION 327 "The total number of UDP-Lite datagrams that were 328 delivered to UDP-Lite users. 329 Discontinuities in the value of this counter can occur 330 at re-initialization of the management system, and at 331 other times as indicated by discontinuities in the 332 value of sysUpTime." 333 ::= { udplite 1 } 335 udpliteInPartialCov OBJECT-TYPE -- new in UDP-Lite 336 SYNTAX Counter64 337 MAX-ACCESS read-only 338 STATUS current 339 DESCRIPTION 340 "The total number of UDP-Lite datagrams that were 341 delivered to UDP-Lite users (applications) and whose 342 checksum coverage was strictly less than the datagram 343 length. 344 Discontinuities in the value of this counter can occur 345 at re-initialization of the management system, and at 346 other times as indicated by discontinuities in the 347 value of sysUpTime." 348 ::= { udplite 2 } 350 udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB 351 SYNTAX Counter32 352 MAX-ACCESS read-only 353 STATUS current 354 DESCRIPTION 355 "The total number of received UDP-Lite datagrams for 356 which there was no listener at the destination port. 357 Discontinuities in the value of this counter can occur 358 at re-initialization of the management system, and at 359 other times as indicated by discontinuities in the 360 value of sysUpTime." 361 ::= { udplite 3 } 363 udpliteInErrors OBJECT-TYPE -- as in UDP-MIB 364 SYNTAX Counter32 365 MAX-ACCESS read-only 366 STATUS current 367 DESCRIPTION 368 "The number of received UDP-Lite datagrams that could not 369 be delivered for reasons other than the lack of an 370 application at the destination port. 371 Discontinuities in the value of this counter can occur 372 at re-initialization of the management system, and at 373 other times as indicated by discontinuities in the 374 value of sysUpTime." 375 ::= { udplite 4 } 377 udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite 378 SYNTAX Counter32 379 MAX-ACCESS read-only 380 STATUS current 381 DESCRIPTION 382 "The number of received UDP-Lite datagrams whose checksum 383 could not be validated. This includes illegal checksum 384 coverage values (as defined in RFC 3828), as their use 385 would lead to incorrect checksums. 386 Discontinuities in the value of this counter can occur 387 at re-initialization of the management system, and at 388 other times as indicated by discontinuities in the 389 value of sysUpTime." 390 ::= { udplite 5 } 392 udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB 393 SYNTAX Counter64 394 MAX-ACCESS read-only 395 STATUS current 396 DESCRIPTION 397 "The total number of UDP-Lite datagrams sent from this 398 entity. 399 Discontinuities in the value of this counter can occur 400 at re-initialization of the management system, and at 401 other times as indicated by discontinuities in the 402 value of sysUpTime." 403 ::= { udplite 6 } 405 udpliteOutPartialCov OBJECT-TYPE -- new in UDP-Lite 406 SYNTAX Counter64 407 MAX-ACCESS read-only 408 STATUS current 409 DESCRIPTION 410 "The total number of udpliteOutdatagrams whose 411 checksum coverage was strictly less than the 412 datagram length. 413 Discontinuities in the value of this counter can occur 414 at re-initialization of the management system, and at 415 other times as indicated by discontinuities in the 416 value of sysUpTime." 417 ::= { udplite 7 } 419 udpliteEndpointTable OBJECT-TYPE 420 SYNTAX SEQUENCE OF UdpLiteEndpointEntry 421 MAX-ACCESS not-accessible 422 STATUS current 423 DESCRIPTION 424 "A table containing information about this entity's UDP- 425 Lite endpoints on which a local application is currently 426 accepting or sending datagrams. 428 The address type in this table represents the address 429 type used for the communication, irrespective of the 430 higher-layer abstraction. For example, an application 431 using IPv6 'sockets' to communicate via IPv4 between 432 ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use 433 InetAddressType ipv4(1). 435 Like the udpTable in RFC 4113, this table also allows 436 the representation of an application that completely 437 specifies both local and remote addresses and ports. A 438 listening application is represented in three possible 439 ways: 441 1) An application that is willing to accept both IPv4 442 and IPv6 datagrams is represented by a 443 udpliteEndpointLocalAddressType of unknown(0) and a 444 udpliteEndpointLocalAddress of ''h (a zero-length 445 octet-string). 447 2) An application that is willing to accept only IPv4 448 or only IPv6 datagrams is represented by a 449 udpliteEndpointLocalAddressType of the appropriate 450 address type and a udpliteEndpointLocalAddress of 451 '0.0.0.0' or '::' respectively. 453 3) An application that is listening for datagrams only 454 for a specific IP address but from any remote 455 system is represented by a 456 udpliteEndpointLocalAddressType of the appropriate 457 address type, with udpliteEndpointLocalAddress 458 specifying the local address. 460 In all cases where the remote is a wildcard, the 461 udpliteEndpointRemoteAddressType is unknown(0), the 462 udpliteEndpointRemoteAddress is ''h (a zero-length 463 octet-string), and the udpliteEndpointRemotePort is 0. 465 If the operating system is demultiplexing UDP-Lite 466 packets by remote address and port, or if the application 467 has 'connected' the socket specifying a default remote 468 address and port, the udpliteEndpointRemote* values should 469 be used to reflect this." 470 ::= { udplite 8 } 472 udpliteEndpointEntry OBJECT-TYPE 473 SYNTAX UdpLiteEndpointEntry 474 MAX-ACCESS not-accessible 475 STATUS current 476 DESCRIPTION 477 "Information about a particular current UDP-Lite endpoint. 479 Implementers need to pay attention to the sizes of 480 udpliteEndpointLocalAddress/RemoteAddress, as OIDs of 481 column instances in this table must have no more than 482 128 sub-identifiers in order to remain accessible with 483 SNMPv1, SNMPv2c, and SNMPv3". 484 INDEX { udpliteEndpointLocalAddressType, 485 udpliteEndpointLocalAddress, 486 udpliteEndpointLocalPort, 487 udpliteEndpointRemoteAddressType, 488 udpliteEndpointRemoteAddress, 489 udpliteEndpointRemotePort, 490 udpliteEndpointInstance } 491 ::= { udpliteEndpointTable 1 } 493 UdpLiteEndpointEntry ::= SEQUENCE { 494 udpliteEndpointLocalAddressType InetAddressType, 495 udpliteEndpointLocalAddress InetAddress, 496 udpliteEndpointLocalPort InetPortNumber, 497 udpliteEndpointRemoteAddressType InetAddressType, 498 udpliteEndpointRemoteAddress InetAddress, 499 udpliteEndpointRemotePort InetPortNumber, 500 udpliteEndpointInstance Unsigned32, 501 udpliteEndpointProcess Unsigned32, 502 udpliteEndpointMinCoverage Unsigned32, 503 udpliteEndpointViolCoverage Counter32 504 } 506 udpliteEndpointLocalAddressType OBJECT-TYPE 507 SYNTAX InetAddressType 508 MAX-ACCESS not-accessible 509 STATUS current 510 DESCRIPTION 511 "The address type of udpliteEndpointLocalAddress. Only 512 IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or 513 unknown(0) if datagrams for all local IP addresses are 514 accepted." 515 ::= { udpliteEndpointEntry 1 } 517 udpliteEndpointLocalAddress OBJECT-TYPE 518 SYNTAX InetAddress 519 MAX-ACCESS not-accessible 520 STATUS current 521 DESCRIPTION 522 "The local IP address for this UDP-Lite endpoint. 524 The value of this object can be represented in three 525 possible ways, depending on the characteristics of the 526 listening application: 528 1. For an application that is willing to accept both 529 IPv4 and IPv6 datagrams, the value of this object 530 must be ''h (a zero-length octet-string), with 531 the value of the corresponding instance of the 532 EndpointLocalAddressType object being unknown(0). 534 2. For an application that is willing to accept only IPv4 535 or only IPv6 datagrams, the value of this object 536 must be '0.0.0.0' or '::', respectively, while the 537 corresponding instance of the EndpointLocalAddressType 538 object represents the appropriate address type. 540 3. For an application that is listening for data 541 destined only to a specific IP address, the value 542 of this object is the specific IP address for which 543 this node is receiving packets, with the corresponding 544 instance of the EndpointLocalAddressType object 545 representing the appropriate address type. 547 As this object is used in the index for the 548 udpliteEndpointTable, implementors of this table should be 549 careful not to create entries that would result in OIDs 550 with more than 128 subidentifiers; else the information 551 cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." 552 ::= { udpliteEndpointEntry 2 } 554 udpliteEndpointLocalPort OBJECT-TYPE 555 SYNTAX InetPortNumber 556 MAX-ACCESS not-accessible 557 STATUS current 558 DESCRIPTION 559 "The local port number for this UDP-Lite endpoint." 560 ::= { udpliteEndpointEntry 3 } 562 udpliteEndpointRemoteAddressType OBJECT-TYPE 563 SYNTAX InetAddressType 564 MAX-ACCESS not-accessible 565 STATUS current 566 DESCRIPTION 567 "The address type of udpliteEndpointRemoteAddress. Only 568 IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or 569 unknown(0) if datagrams for all remote IP addresses are 570 accepted. Also, note that some combinations of 571 udpliteEndpointLocalAdressType and 572 udpliteEndpointRemoteAddressType are not supported. In 573 particular, if the value of this object is not 574 unknown(0), it is expected to always refer to the 575 same IP version as udpliteEndpointLocalAddressType." 576 ::= { udpliteEndpointEntry 4 } 578 udpliteEndpointRemoteAddress OBJECT-TYPE 579 SYNTAX InetAddress 580 MAX-ACCESS not-accessible 581 STATUS current 582 DESCRIPTION 583 "The remote IP address for this UDP-Lite endpoint. If 584 datagrams from any remote system are to be accepted, 585 this value is ''h (a zero-length octet-string). 586 Otherwise, it has the type described by 587 udpliteEndpointRemoteAddressType and is the address of the 588 remote system from which datagrams are to be accepted 589 (or to which all datagrams will be sent). 591 As this object is used in the index for the 592 udpliteEndpointTable, implementors of this table should be 593 careful not to create entries that would result in OIDs 594 with more than 128 subidentifiers; else the information 595 cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." 596 ::= { udpliteEndpointEntry 5 } 598 udpliteEndpointRemotePort OBJECT-TYPE 599 SYNTAX InetPortNumber 600 MAX-ACCESS not-accessible 601 STATUS current 602 DESCRIPTION 603 "The remote port number for this UDP-Lite endpoint. If 604 datagrams from any remote system are to be accepted, 605 this value is zero." 606 ::= { udpliteEndpointEntry 6 } 608 udpliteEndpointInstance OBJECT-TYPE 609 SYNTAX Unsigned32 (1..'ffffffff'h) 610 MAX-ACCESS not-accessible 611 STATUS current 612 DESCRIPTION 613 "The instance of this tuple. This object is used to 614 distinguish among multiple processes 'connected' to 615 the same UDP-Lite endpoint. For example, on a system 616 implementing the BSD sockets interface, this would be 617 used to support the SO_REUSEADDR and SO_REUSEPORT 618 socket options. 619 The object value should be obtained from a counter that 620 increments each time a new UDP-Lite endpoint is created. 621 Once the counter wraps around, care must be taken to 622 ensure that newly created indices are unique." 623 ::= { udpliteEndpointEntry 7 } 625 udpliteEndpointProcess OBJECT-TYPE 626 SYNTAX Unsigned32 627 MAX-ACCESS read-only 628 STATUS current 629 DESCRIPTION 630 "The system's process ID for the process associated with 631 this endpoint, or zero if there is no such process. 632 This value is expected to be the same as 633 HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB:: 634 sysApplElmtRunIndex for some row in the appropriate 635 tables." 636 ::= { udpliteEndpointEntry 8 } 638 udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite 639 SYNTAX Unsigned32 640 MAX-ACCESS read-only 641 STATUS current 642 DESCRIPTION 643 "The minimum checksum coverage expected by this endpoint. 644 (as defined in RFC 3828). If set to 0, only fully 645 covered datagrams are accepted." 646 ::= { udpliteEndpointEntry 9 } 648 udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite 649 SYNTAX Counter32 650 MAX-ACCESS read-only 651 STATUS current 652 DESCRIPTION 653 "The number of datagrams received by this endpoint whose 654 checksum coverage violated the minimum coverage threshold 655 set for this connection (i.e. all valid datagrams whose 656 checksum coverage was strictly smaller than the minimum, 657 as defined in RFC 3828)." 658 ::= { udpliteEndpointEntry 10 } 660 udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 } 662 udpliteMIBCompliance MODULE-COMPLIANCE 663 STATUS current 664 DESCRIPTION 665 "The compliance statement for systems that implement 666 UDP-Lite. 668 There are a number of INDEX objects that cannot be 669 represented in the form of OBJECT clauses in SMIv2, but 670 for which we have the following compliance 671 requirements, expressed in OBJECT clause form in this 672 description clause: 674 -- OBJECT udpliteEndpointLocalAddressType 675 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 676 -- ipv6(2), ipv4z(3), 677 -- ipv6z(4) } 678 -- DESCRIPTION 679 -- Support for dns(16) is not required. 680 -- OBJECT udpliteEndpointLocalAddress 682 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 683 -- DESCRIPTION 684 -- Support is only required for zero-length 685 -- octet-strings, and for scoped and unscoped 686 -- IPv4 and IPv6 addresses. 687 -- OBJECT udpliteEndpointRemoteAddressType 688 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 689 -- ipv6(2), ipv4z(3), 690 -- ipv6z(4) } 691 -- DESCRIPTION 692 -- Support for dns(16) is not required. 694 -- OBJECT udpliteEndpointRemoteAddress 695 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 696 -- DESCRIPTION 697 -- Support is only required for zero-length 698 -- octet-strings, and for scoped and unscoped 699 -- IPv4 and IPv6 addresses. 700 " 701 MODULE -- this module 702 MANDATORY-GROUPS { udpliteBaseGroup, udplitePartialCsumGroup, 703 udpliteEndpointGroup } 704 GROUP udpliteAppGroup 705 DESCRIPTION 706 "This group is optional and provides supplementary 707 information about the effectivity of using minimum 708 checksum coverage thresholds on endpoints." 709 ::= { udpliteMIBConformance 1 } 711 udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 } 713 udpliteBaseGroup OBJECT-GROUP -- as in UDP 714 OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors, 715 udpliteOutDatagrams } 716 STATUS current 717 DESCRIPTION 718 "The group of objects providing for counters of 719 basic UDP-like statistics." 720 ::= { udpliteMIBGroups 1 } 722 udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite 723 OBJECTS { udpliteInPartialCov, 724 udpliteInBadChecksum, 725 udpliteOutPartialCov } 726 STATUS current 727 DESCRIPTION 728 "The group of objects providing for counters of 729 transport-layer statistics exclusive to UDP-Lite." 730 ::= { udpliteMIBGroups 2 } 732 udpliteEndpointGroup OBJECT-GROUP 733 OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage } 734 STATUS current 735 DESCRIPTION 736 "The group of objects providing for the IP version 737 independent management of UDP-Lite 'endpoints'." 739 ::= { udpliteMIBGroups 3 } 741 udpliteAppGroup OBJECT-GROUP 742 OBJECTS { udpliteEndpointViolCoverage } 743 STATUS current 744 DESCRIPTION 745 "The group of objects that provide application-level 746 information for the configuration management of 747 UDP-Lite 'endpoints'." 748 ::= { udpliteMIBGroups 4 } 750 END 752 4. Security Considerations 754 There are no management objects defined in this MIB module that have 755 a MAX-ACCESS clause of read-write and/or read-create. So, if this 756 MIB module is implemented correctly, then there is no risk that an 757 intruder can alter or create any management objects of this MIB 758 module via direct SNMP SET operations. 760 Some of the readable objects in this MIB module (i.e., objects with a 761 MAX-ACCESS other than not-accessible) may be considered sensitive or 762 vulnerable in some network environments. It is thus important to 763 control even GET and/or NOTIFY access to these objects and possibly 764 to even encrypt the values of these objects when sending them over 765 the network via SNMP. These are the tables and objects and their 766 sensitivity/vulnerability: 768 Since UDP-Lite permits the delivery of (partially) corrupted data to 769 an end host, the counters defined in this MIB may be used to imply 770 information about the characteristics of the end-to-end path over 771 which the datagrams are communicated. 773 The indices of the udpliteEndpointTable contain information about the 774 listeners on an entity. In particular, the udpliteEndpointLocalPort 775 and udpliteLocalPort objects in the indices can be used to identify 776 what ports are open on the machine and which attacks are likely to 777 succeed, without the attacker having to run a port scanner. The 778 table also identifies the currently listening UDP-Lite ports. This 779 could be used to infer the type of application associated with the 780 port at the receiver. The udpliteEndpointMinCoverage provides 781 information about the requirements of the transport service 782 associated with a specific UDP-Lite port. This provides additional 783 detail concerning the type of application associated with the port at 784 the receiver. 786 SNMP versions prior to SNMPv3 did not include adequate security. 787 Even if the network itself is secure (for example by using IPsec), 788 even then, there is no control as to who on the secure network is 789 allowed to access and GET/SET (read/change/create/delete) the objects 790 in this MIB module. 792 It is RECOMMENDED that implementers consider the security features as 793 provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), 794 including full support for the SNMPv3 cryptographic mechanisms (for 795 authentication and privacy). 797 Further, deployment of SNMP versions prior to SNMPv3 is NOT 798 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 799 enable cryptographic security. It is then a customer/operator 800 responsibility to ensure that the SNMP entity giving access to an 801 instance of this MIB module is properly configured to give access to 802 the objects only to those principals (users) that have legitimate 803 rights to indeed GET or SET (change/create/delete) them. 805 5. IANA Considerations 807 This document requires IANA action to assign the UDP-Lite OBJECT 808 IDENTIFIER value, defined in sections 2 and 3, under the 'mib-2' 809 subtree and to record the assignment in the SMI Numbers registry. 811 ==> Note to the RFC Editor (to be removed prior to publication): 813 The IANA is requested to assign a value for "XXX" under the 'mib-2' 814 subtree and to record the assignment in the SMI Numbers registry. 815 When the assignment has been made, the RFC Editor is asked to replace 816 "XXX" (here and in the MIB module) with the assigned value and to 817 remove this note. 819 6. Acknowledgments 821 The design of the MIB presented owes much to the format of the MIB 822 presented in [RFC4113]. 824 ==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION 826 Changes introduced in rev-01: 828 o General: 830 - incremented revision number to 01 832 - updated date to November 834 - rephrased abstract 836 o Section 1: 838 - rephrased the begining of the second paragraph 840 o Section 1.1: 842 - rephrased some items 844 - added missing InBadChecksum heading 846 - updated text to refer to 64bit counters 848 o Section 1.3: 850 - removed 'x' in 'datagrams' 852 - rephrased for clarity 854 - Figure 1: missing bracked text should be InErrors 856 - Figure 1: correction - NoPorts are not counted as InDatagrams 858 o Section 2: 860 - made the "Editor's Note" stand out more 862 o Section 3 / MIB: 864 - upgraded 11 32bit counters to 64bit 866 - moved from experimental to mib-2 868 - updated revision date 870 o Section 4: 872 - some minor changes 874 o Section 5: 876 - again highlighted the Editor's Note by using `==>' to make it 877 consistent 879 Changes introduced in rev-02: 881 o General: 883 - updated month, date, and revision 885 - changed `transport layer entities' to `endpoints' in abstract 887 o Section 1: 889 - added missing comma after `(socket) option' 891 - split explanatory clause after colon into standalone clause 893 o Section 1.1: 895 - added a bullet list of standard counters known from the UDP 896 MIB 898 - added a note that NoPorts does not increment InErrors 900 - removed description of InBadCoverage (no longer in MIB, see 901 below) 903 - qualified note with on 64-bit counters wrt `non-error' 904 counters, reflecting the change that all error counters have 905 been changed to Counter32 907 - Nit: changed `fairly recent' -> `more recent' 909 - removed traces of InBadCoverage (see below) 911 o Section 1.3: 913 - corrected figure 1 (NoPorts was inconsistent with text; Rec 914 Coverage was incorrectly labelled, it didn't show 915 EndpointViolCoverage; slight reformatting) 916 - Nit: `wrong value' -> `a wrong value' 918 - clarified that InBadChecksum can also serve as indicator of 919 path bit error rate 921 - Nit: `which' -> `that' in `a setting may then ...' and `A 922 configuration error may ...' 924 - removed traces of InBadCoverage (see below) 926 o Section 3 (the MIB): 928 - updated LAST-UPDATED and REVISION to match the revision date 930 - updated the Copyright in DESCRIPTION from 2006 to 2007 932 - converted all error counters to Counter32, following IETF 933 input for rev-01 935 - added a required IMPORTS statement for Counter32 to UDPLITE- 936 MIB DEFINITIONS 938 - demoted the following error counters from Counter64 to 939 Counter32: udpliteNoPorts, udpliteInErrors, 940 updliteInBadChecksum, udpliteEndpointViolCoverage 942 - removed second, redundant MIB-2 number of udplite, following 943 suggestion by Bill Fenner. 945 - updated warning about maximum number of sub-identifiers in 946 udpliteEndpointEntry, to reflect new structure 948 - udplite now comes as entry number 1 in the udpliteMIB tree 950 - accordingly changed the identifier of udpliteMIBConformance 951 to 2 953 - updated all RFC editor notes with regard to the assignment of 954 mib-2 identifier numbers (now only a single one required) 956 - updated section `IANA Considerations' with regard to this 957 change 959 - removed the InBadCoverage counter since it is subsumed by 960 InBadChecksum (see below) 962 - updated the following identifier numbers for consistency 963 after removal: udpliteInBadChecksum (6 -> 5), 964 udpliteOutDatagrams (7 -> 6), udpliteOutPartialCov (8 -> 7), 965 udpliteEndpointTable (9 -> 8) 967 - removed udpliteInBadCoverage from udplitePartialCsumGroup 969 - extended the definition of InBadChecksum to include invalid 970 checksum coverage 972 - added RFC 3828 references for udpliteEndpointMinCoverage and 973 udpliteEndpointViolCoverage 975 - updated the description of udpliteEndpointInstance with 976 respect to draft-persson-v6ops-mib-issue-01.txt, section 3.2 978 o Section 7 (References): 980 - RFC 4113 (UDP MIB) becomes informative, not normative 982 o Note on the removal of InBadCoverage: Following rev-01, this 983 counter has been removed since - with the exception of obviously 984 buggy UDP-Lite stacks - it is subsumed by InBadChecksum. An 985 illegal checksum value which is not the cause of a buggy 986 implementation will in practically all cases lead to an incorrect 987 checksum value, so that one counter implies information inherent 988 in the other. 990 ====> END OF NOTE TO THE RFC EDITOR <==== 992 7. References 994 7.1. Normative References 996 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 997 Requirement Levels", BCP 14, RFC 2119, March 1997. 999 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1000 Schoenwaelder, Ed., "Structure of Management Information 1001 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1003 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1004 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1005 STD 58, RFC 2579, April 1999. 1007 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1008 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1009 April 1999. 1011 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1012 G. Fairhurst, "The Lightweight User Datagram Protocol 1013 (UDP-Lite)", RFC 3828, July 2004. 1015 7.2. Informative References 1017 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1018 August 1980. 1020 [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level 1021 Managed Objects for Applications", RFC 2287, 1022 February 1998. 1024 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", 1025 RFC 2790, March 2000. 1027 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1028 "Introduction and Applicability Statements for Internet- 1029 Standard Management Framework", RFC 3410, December 2002. 1031 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 1032 the User Datagram Protocol (UDP)", RFC 4113, June 2005. 1034 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1035 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1037 Authors' Addresses 1039 Gerrit Renker 1040 University of Aberdeen 1041 Department of Engineering 1042 Fraser Noble Building 1043 Aberdeen AB24 3UE 1044 Scotland 1046 Email: gerrit@erg.abdn.ac.uk 1047 URI: http://www.erg.abdn.ac.uk 1049 Godred Fairhurst 1050 University of Aberdeen 1051 Department of Engineering 1052 Fraser Noble Building 1053 Aberdeen AB24 3UE 1054 Scotland 1056 Email: gorry@erg.abdn.ac.uk 1057 URI: http://www.erg.abdn.ac.uk 1059 Full Copyright Statement 1061 Copyright (C) The IETF Trust (2007). 1063 This document is subject to the rights, licenses and restrictions 1064 contained in BCP 78, and except as set forth therein, the authors 1065 retain all their rights. 1067 This document and the information contained herein are provided on an 1068 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1069 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1070 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1071 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1072 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1073 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1075 Intellectual Property 1077 The IETF takes no position regarding the validity or scope of any 1078 Intellectual Property Rights or other rights that might be claimed to 1079 pertain to the implementation or use of the technology described in 1080 this document or the extent to which any license under such rights 1081 might or might not be available; nor does it represent that it has 1082 made any independent effort to identify any such rights. Information 1083 on the procedures with respect to rights in RFC documents can be 1084 found in BCP 78 and BCP 79. 1086 Copies of IPR disclosures made to the IETF Secretariat and any 1087 assurances of licenses to be made available, or the result of an 1088 attempt made to obtain a general license or permission for the use of 1089 such proprietary rights by implementers or users of this 1090 specification can be obtained from the IETF on-line IPR repository at 1091 http://www.ietf.org/ipr. 1093 The IETF invites any interested party to bring to its attention any 1094 copyrights, patents or patent applications, or other proprietary 1095 rights that may cover technology that may be required to implement 1096 this standard. Please address the information to the IETF at 1097 ietf-ipr@ietf.org. 1099 Acknowledgment 1101 Funding for the RFC Editor function is provided by the IETF 1102 Administrative Support Activity (IASA).