idnits 2.17.1 draft-ietf-tsvwg-udplite-mib-01.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 1086. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1097. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1104. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1110. 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 (September 11, 2007) is 6069 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: March 14, 2008 September 11, 2007 7 MIB for the UDP-Lite protocol 8 draft-ietf-tsvwg-udplite-mib-01 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 March 14, 2008. 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 "200709110000Z" -- Tue, 11th Sep 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 "200709110000Z" -- Tue, 11th Sep 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 425 UDP-Lite endpoints on which a local application is 426 currently 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/port, or if the application 467 has 'connected' the socket specifying a default remote 468 address/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 535 IPv4 or only IPv6 datagrams, the value of this 536 object must be '0.0.0.0' or '::', respectively, 537 while the corresponding instance of the 538 EndpointLocalAddressType object represents the 539 appropriate address type. 541 3. For an application that is listening for data 542 destined only to a specific IP address, the value 543 of this object is the specific IP address for 544 which this node is receiving packets, with the 545 corresponding instance of the 546 EndpointLocalAddressType object representing the 547 appropriate address type. 549 As this object is used in the index for the 550 udpliteEndpointTable, implementors should be careful 551 not to create entries that would result in OIDs with 552 more than 128 subidentifiers; else the information 553 cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." 554 ::= { udpliteEndpointEntry 2 } 556 udpliteEndpointLocalPort OBJECT-TYPE 557 SYNTAX InetPortNumber 558 MAX-ACCESS not-accessible 559 STATUS current 560 DESCRIPTION 561 "The local port number for this UDP-Lite endpoint." 562 ::= { udpliteEndpointEntry 3 } 564 udpliteEndpointRemoteAddressType OBJECT-TYPE 565 SYNTAX InetAddressType 566 MAX-ACCESS not-accessible 567 STATUS current 568 DESCRIPTION 569 "The address type of udpliteEndpointRemoteAddress. Only 570 IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or 571 unknown(0) if datagrams for all remote IP addresses are 572 accepted. Also, note that some combinations of 573 udpliteEndpointLocalAdressType and 574 udpliteEndpointRemoteAddressType are not supported. In 575 particular, if the value of this object is not 576 unknown(0), it is expected to always refer to the 577 same IP version as udpliteEndpointLocalAddressType." 578 ::= { udpliteEndpointEntry 4 } 580 udpliteEndpointRemoteAddress OBJECT-TYPE 581 SYNTAX InetAddress 582 MAX-ACCESS not-accessible 583 STATUS current 584 DESCRIPTION 585 "The remote IP address for this UDP-Lite endpoint. If 586 datagrams from any remote system are to be accepted, 587 this value is ''h (a zero-length octet-string). 588 Otherwise, it has the type described by 589 udpliteEndpointRemoteAddressType and is the address of 590 the remote system from which datagrams are to be 591 accepted (or to which all datagrams will be sent). 593 As this object is used in the index for the 594 udpliteEndpointTable, implementors should be careful 595 not to create entries that would result in OIDs with 596 more than 128 subidentifiers; else the information 597 cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." 598 ::= { udpliteEndpointEntry 5 } 600 udpliteEndpointRemotePort OBJECT-TYPE 601 SYNTAX InetPortNumber 602 MAX-ACCESS not-accessible 603 STATUS current 604 DESCRIPTION 605 "The remote port number for this UDP-Lite endpoint. If 606 datagrams from any remote system are to be accepted, 607 this value is zero." 608 ::= { udpliteEndpointEntry 6 } 610 udpliteEndpointInstance OBJECT-TYPE 611 SYNTAX Unsigned32 (1..'ffffffff'h) 612 MAX-ACCESS not-accessible 613 STATUS current 614 DESCRIPTION 615 "The instance of this tuple. This object is used to 616 distinguish among multiple processes 'connected' to 617 the same UDP-Lite endpoint. For example, on a system 618 implementing the BSD sockets interface, this would be 619 used to support the SO_REUSEADDR and SO_REUSEPORT 620 socket options. 621 The object value should be obtained from a counter that 622 increments each time a new UDP-Lite endpoint is created. 623 Once the counter wraps around, care must be taken to 624 ensure that newly created indices are unique." 625 ::= { udpliteEndpointEntry 7 } 627 udpliteEndpointProcess OBJECT-TYPE 628 SYNTAX Unsigned32 629 MAX-ACCESS read-only 630 STATUS current 631 DESCRIPTION 632 "The system's process ID for the process associated with 633 this endpoint, or zero if there is no such process. 634 This value is expected to be the same as 635 HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB:: 636 sysApplElmtRunIndex for some row in the appropriate 637 tables." 638 ::= { udpliteEndpointEntry 8 } 640 udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite 641 SYNTAX Unsigned32 642 MAX-ACCESS read-only 643 STATUS current 644 DESCRIPTION 645 "The minimum checksum coverage expected by this endpoint. 646 (as defined in RFC 3828). If set to 0, only fully 647 covered datagrams are accepted." 648 ::= { udpliteEndpointEntry 9 } 650 udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite 651 SYNTAX Counter32 652 MAX-ACCESS read-only 653 STATUS current 654 DESCRIPTION 655 "The number of datagrams received by this endpoint whose 656 checksum coverage violated the minimum coverage threshold 657 set for this connection (i.e. all valid datagrams whose 658 checksum coverage was strictly smaller than the minimum, 659 as defined in RFC 3828)." 660 ::= { udpliteEndpointEntry 10 } 662 udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 } 664 udpliteMIBCompliance MODULE-COMPLIANCE 665 STATUS current 666 DESCRIPTION 667 "The compliance statement for systems that implement 668 UDP-Lite. 670 There are a number of INDEX objects that cannot be 671 represented in the form of OBJECT clauses in SMIv2, 672 but for which we have the following compliance 673 requirements, expressed in OBJECT clause form in this 674 description clause: 676 -- OBJECT udpliteEndpointLocalAddressType 677 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 678 -- ipv6(2), ipv4z(3), 679 -- ipv6z(4) } 680 -- DESCRIPTION 681 -- Support for dns(16) is not required. 682 -- OBJECT udpliteEndpointLocalAddress 684 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 685 -- DESCRIPTION 686 -- Support is only required for zero-length 687 -- octet-strings, and for scoped and unscoped 688 -- IPv4 and IPv6 addresses. 689 -- OBJECT udpliteEndpointRemoteAddressType 690 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 691 -- ipv6(2), ipv4z(3), 692 -- ipv6z(4) } 693 -- DESCRIPTION 694 -- Support for dns(16) is not required. 696 -- OBJECT udpliteEndpointRemoteAddress 697 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 698 -- DESCRIPTION 699 -- Support is only required for zero-length 700 -- octet-strings, and for scoped and unscoped 701 -- IPv4 and IPv6 addresses. 702 " 703 MODULE -- this module 704 MANDATORY-GROUPS { udpliteBaseGroup, 705 udplitePartialCsumGroup, 706 udpliteEndpointGroup } 707 GROUP udpliteAppGroup 708 DESCRIPTION 709 "This group is optional and provides supplementary 710 information about the effectivity of using minimum 711 checksum coverage thresholds on endpoints." 712 ::= { udpliteMIBConformance 1 } 714 udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 } 716 udpliteBaseGroup OBJECT-GROUP -- as in UDP 717 OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors, 718 udpliteOutDatagrams } 719 STATUS current 720 DESCRIPTION 721 "The group of objects providing for counters of 722 basic UDP-like statistics." 723 ::= { udpliteMIBGroups 1 } 725 udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite 726 OBJECTS { udpliteInPartialCov, 727 udpliteInBadChecksum, 728 udpliteOutPartialCov } 729 STATUS current 730 DESCRIPTION 731 "The group of objects providing for counters of 732 transport-layer statistics exclusive to UDP-Lite." 733 ::= { udpliteMIBGroups 2 } 735 udpliteEndpointGroup OBJECT-GROUP 736 OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage } 737 STATUS current 738 DESCRIPTION 739 "The group of objects providing for the IP version 740 independent management of UDP-Lite 'endpoints'." 741 ::= { udpliteMIBGroups 3 } 743 udpliteAppGroup OBJECT-GROUP 744 OBJECTS { udpliteEndpointViolCoverage } 745 STATUS current 746 DESCRIPTION 747 "The group of objects that provide application-level 748 information for the configuration management of 749 UDP-Lite 'endpoints'." 750 ::= { udpliteMIBGroups 4 } 752 END 754 4. Security Considerations 756 There are no management objects defined in this MIB module that have 757 a MAX-ACCESS clause of read-write and/or read-create. So, if this 758 MIB module is implemented correctly, then there is no risk that an 759 intruder can alter or create any management objects of this MIB 760 module via direct SNMP SET operations. 762 Some of the readable objects in this MIB module (i.e., objects with a 763 MAX-ACCESS other than not-accessible) may be considered sensitive or 764 vulnerable in some network environments. It is thus important to 765 control even GET and/or NOTIFY access to these objects and possibly 766 to even encrypt the values of these objects when sending them over 767 the network via SNMP. These are the tables and objects and their 768 sensitivity/vulnerability: 770 Since UDP-Lite permits the delivery of (partially) corrupted data to 771 an end host, the counters defined in this MIB may be used to imply 772 information about the characteristics of the end-to-end path over 773 which the datagrams are communicated. 775 The indices of the udpliteEndpointTable contain information about the 776 listeners on an entity. In particular, the udpliteEndpointLocalPort 777 and udpliteLocalPort objects in the indices can be used to identify 778 what ports are open on the machine and which attacks are likely to 779 succeed, without the attacker having to run a port scanner. The 780 table also identifies the currently listening UDP-Lite ports. This 781 could be used to infer the type of application associated with the 782 port at the receiver. The udpliteEndpointMinCoverage provides 783 information about the requirements of the transport service 784 associated with a specific UDP-Lite port. This provides additional 785 detail concerning the type of application associated with the port at 786 the receiver. 788 SNMP versions prior to SNMPv3 did not include adequate security. 789 Even if the network itself is secure (for example by using IPsec), 790 even then, there is no control as to who on the secure network is 791 allowed to access and GET/SET (read/change/create/delete) the objects 792 in this MIB module. 794 It is RECOMMENDED that implementers consider the security features as 795 provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), 796 including full support for the SNMPv3 cryptographic mechanisms (for 797 authentication and privacy). 799 Further, deployment of SNMP versions prior to SNMPv3 is NOT 800 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 801 enable cryptographic security. It is then a customer/operator 802 responsibility to ensure that the SNMP entity giving access to an 803 instance of this MIB module is properly configured to give access to 804 the objects only to those principals (users) that have legitimate 805 rights to indeed GET or SET (change/create/delete) them. 807 5. IANA Considerations 809 This document requires IANA action to assign the UDP-Lite OBJECT 810 IDENTIFIER value, defined in sections 2 and 3, under the 'mib-2' 811 subtree and to record the assignment in the SMI Numbers registry. 813 ==> Note to the RFC Editor (to be removed prior to publication): 815 The IANA is requested to assign a value for "XXX" under the 'mib-2' 816 subtree and to record the assignment in the SMI Numbers registry. 817 When the assignment has been made, the RFC Editor is asked to replace 818 "XXX" (here and in the MIB module) with the assigned value and to 819 remove this note. 821 6. Acknowledgments 823 The design of the MIB presented owes much to the format of the MIB 824 presented in [RFC4113]. 826 ==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION 828 Revision 00 of draft-ietf-tsvwg-udplite-mib was obsoleted by revision 829 01 due to a syntax error (quote transposed with full-stop) in the 830 MIB, which is corrected in rev-01. Thanks to Magnus Westerlund for 831 identifying this. 833 Draft draft-ietf-tsvwg-udplite-mib-00 was published as a work item of 834 tsvwg, June 2007. 836 The following changelog lists the changes up to revision 02 (which 837 became rev-00/01 of this document) of the preceding individual draft 838 submission draft-renker-tsvwg-udplite-mib. 840 Changes introduced in rev-01: 842 o General: 844 - incremented revision number to 01 846 - updated date to November 848 - rephrased abstract 850 o Section 1: 852 - rephrased the begining of the second paragraph 854 o Section 1.1: 856 - rephrased some items 858 - added missing InBadChecksum heading 860 - updated text to refer to 64bit counters 862 o Section 1.3: 864 - removed 'x' in 'datagrams' 866 - rephrased for clarity 868 - Figure 1: missing bracked text should be InErrors 870 - Figure 1: correction - NoPorts are not counted as InDatagrams 872 o Section 2: 874 - made the "Editor's Note" stand out more 876 o Section 3 / MIB: 878 - upgraded 11 32bit counters to 64bit 880 - moved from experimental to mib-2 882 - updated revision date 884 o Section 4: 886 - some minor changes 888 o Section 5: 890 - again highlighted the Editor's Note by using `==>' to make it 891 consistent 893 Changes introduced in rev-02: 895 o General: 897 - updated month, date, and revision 899 - changed `transport layer entities' to `endpoints' in abstract 901 o Section 1: 903 - added missing comma after `(socket) option' 905 - split explanatory clause after colon into standalone clause 907 o Section 1.1: 909 - added a bullet list of standard counters known from the UDP 910 MIB 912 - added a note that NoPorts does not increment InErrors 914 - removed description of InBadCoverage (no longer in MIB, see 915 below) 917 - qualified note with on 64-bit counters wrt `non-error' 918 counters, reflecting the change that all error counters have 919 been changed to Counter32 920 - Nit: changed `fairly recent' -> `more recent' 922 - removed traces of InBadCoverage (see below) 924 o Section 1.3: 926 - corrected figure 1 (NoPorts was inconsistent with text; Rec 927 Coverage was incorrectly labelled, it didn't show 928 EndpointViolCoverage; slight reformatting) 930 - Nit: `wrong value' -> `a wrong value' 932 - clarified that InBadChecksum can also serve as indicator of 933 path bit error rate 935 - Nit: `which' -> `that' in `a setting may then ...' and `A 936 configuration error may ...' 938 - removed traces of InBadCoverage (see below) 940 o Section 3 (the MIB): 942 - updated LAST-UPDATED and REVISION to match the revision date 944 - updated the Copyright in DESCRIPTION from 2006 to 2007 946 - converted all error counters to Counter32, following IETF 947 input for rev-01 949 - added a required IMPORTS statement for Counter32 to UDPLITE- 950 MIB DEFINITIONS 952 - demoted the following error counters from Counter64 to 953 Counter32: udpliteNoPorts, udpliteInErrors, 954 updliteInBadChecksum, udpliteEndpointViolCoverage 956 - removed second, redundant MIB-2 number of udplite, following 957 suggestion by Bill Fenner. 959 - updated warning about maximum number of sub-identifiers in 960 udpliteEndpointEntry, to reflect new structure 962 - udplite now comes as entry number 1 in the udpliteMIB tree 964 - accordingly changed the identifier of udpliteMIBConformance 965 to 2 966 - updated all RFC editor notes with regard to the assignment of 967 mib-2 identifier numbers (now only a single one required) 969 - updated section `IANA Considerations' with regard to this 970 change 972 - removed the InBadCoverage counter since it is subsumed by 973 InBadChecksum (see below) 975 - updated the following identifier numbers for consistency 976 after removal: udpliteInBadChecksum (6 -> 5), 977 udpliteOutDatagrams (7 -> 6), udpliteOutPartialCov (8 -> 7), 978 udpliteEndpointTable (9 -> 8) 980 - removed udpliteInBadCoverage from udplitePartialCsumGroup 982 - extended the definition of InBadChecksum to include invalid 983 checksum coverage 985 - added RFC 3828 references for udpliteEndpointMinCoverage and 986 udpliteEndpointViolCoverage 988 - updated the description of udpliteEndpointInstance with 989 respect to draft-persson-v6ops-mib-issue-01.txt, section 3.2 991 o Section 7 (References): 993 - RFC 4113 (UDP MIB) becomes informative, not normative 995 o Note on the removal of InBadCoverage: Following rev-01, this 996 counter has been removed since - with the exception of obviously 997 buggy UDP-Lite stacks - it is subsumed by InBadChecksum. An 998 illegal checksum value which is not the cause of a buggy 999 implementation will in practically all cases lead to an incorrect 1000 checksum value, so that one counter implies information inherent 1001 in the other. 1003 ====> END OF NOTE TO THE RFC EDITOR <==== 1005 7. References 1007 7.1. Normative References 1009 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1010 Requirement Levels", BCP 14, RFC 2119, March 1997. 1012 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1013 Schoenwaelder, Ed., "Structure of Management Information 1014 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1016 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1017 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 1018 STD 58, RFC 2579, April 1999. 1020 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 1021 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1022 April 1999. 1024 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1025 G. Fairhurst, "The Lightweight User Datagram Protocol 1026 (UDP-Lite)", RFC 3828, July 2004. 1028 7.2. Informative References 1030 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1031 August 1980. 1033 [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level 1034 Managed Objects for Applications", RFC 2287, 1035 February 1998. 1037 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", 1038 RFC 2790, March 2000. 1040 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1041 "Introduction and Applicability Statements for Internet- 1042 Standard Management Framework", RFC 3410, December 2002. 1044 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 1045 the User Datagram Protocol (UDP)", RFC 4113, June 2005. 1047 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1048 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1050 Authors' Addresses 1052 Gerrit Renker 1053 University of Aberdeen 1054 Department of Engineering 1055 Fraser Noble Building 1056 Aberdeen AB24 3UE 1057 Scotland 1059 Email: gerrit@erg.abdn.ac.uk 1060 URI: http://www.erg.abdn.ac.uk 1062 Godred Fairhurst 1063 University of Aberdeen 1064 Department of Engineering 1065 Fraser Noble Building 1066 Aberdeen AB24 3UE 1067 Scotland 1069 Email: gorry@erg.abdn.ac.uk 1070 URI: http://www.erg.abdn.ac.uk 1072 Full Copyright Statement 1074 Copyright (C) The IETF Trust (2007). 1076 This document is subject to the rights, licenses and restrictions 1077 contained in BCP 78, and except as set forth therein, the authors 1078 retain all their rights. 1080 This document and the information contained herein are provided on an 1081 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1082 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1083 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1084 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1085 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1086 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1088 Intellectual Property 1090 The IETF takes no position regarding the validity or scope of any 1091 Intellectual Property Rights or other rights that might be claimed to 1092 pertain to the implementation or use of the technology described in 1093 this document or the extent to which any license under such rights 1094 might or might not be available; nor does it represent that it has 1095 made any independent effort to identify any such rights. Information 1096 on the procedures with respect to rights in RFC documents can be 1097 found in BCP 78 and BCP 79. 1099 Copies of IPR disclosures made to the IETF Secretariat and any 1100 assurances of licenses to be made available, or the result of an 1101 attempt made to obtain a general license or permission for the use of 1102 such proprietary rights by implementers or users of this 1103 specification can be obtained from the IETF on-line IPR repository at 1104 http://www.ietf.org/ipr. 1106 The IETF invites any interested party to bring to its attention any 1107 copyrights, patents or patent applications, or other proprietary 1108 rights that may cover technology that may be required to implement 1109 this standard. Please address the information to the IETF at 1110 ietf-ipr@ietf.org. 1112 Acknowledgment 1114 Funding for the RFC Editor function is provided by the IETF 1115 Administrative Support Activity (IASA).