idnits 2.17.1 draft-ietf-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 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1148. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1155. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1161. 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 11, 2007) is 6040 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 30, 2008 October 11, 2007 7 MIB for the UDP-Lite protocol 8 draft-ietf-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 March 30, 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, RFC 3828. It defines a 43 set of new MIB entities to characterise the behaviour and performance 44 of 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 . . . . 4 56 1.3. Interpretation of the MIB Variables . . . . . . . . . . . 5 57 1.4. Conventions . . . . . . . . . . . . . . . . . . . . . . . 7 58 2. The Internet-Standard Management Framework . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . . 32 67 Intellectual Property and Copyright Statements . . . . . . . . . . 33 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 the that of UDP [RFC4113], with 103 extensions corresponding to the additional capabilities of UDP-Lite. 104 The UDP-Lite MIB module is placed beneath the mib-2 subtree, adhering 105 to the familiar structure of the UDP-MIB module [RFC4113] to ease 106 integration. 108 In particular, these well-known basic counters are supported: 110 o InDatagrams 112 o NoPorts 114 o InErrors 115 o OutDatagrams 117 The following read-only variables have been added to the basic 118 structure used in the UDP-MIB module: 120 InPartialCov: The number of received datagrams, with a valid 121 format and checksum, whose checksum coverage is strictly less than 122 the datagram length. 124 InBadChecksum: The number of received datagrams with an invalid 125 checksum (i.e. where the receiver-recalculated UDP-Lite checksum 126 does not match that in the Checksum field). Unlike NoPorts, this 127 error type also counts as InErrors. 129 OutPartialCov: The number of sent datagrams with a valid format 130 and checksum whose checksum coverage is strictly less than the 131 datagram length. 133 All non-error counters used in this document are 64-bit counters. 134 This is a departure from UDP, which traditionally used 32-bit 135 counters and mandates 64-bit counters only on fast networks 136 [RFC4113]. This choice is justified by the fact that UDP-Lite is a 137 more recent protocol, and that network speeds continue to grow. 139 Another contrast to UDP is that the UDP-Lite MIB module does not 140 support an IPv4-only listener table. This feature was present only 141 for compatibility reasons and is superseded by the more informative 142 endpoint table. Two columnar objects have been 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 1.2. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB 161 The endpoint table of [RFC4113] contains one columnar object, also 162 used in this MIB module, which reports the identification of the 163 piece of software handling a connection or a listening endpoint. The 164 value is reported as an Unsigned32, which is expected to be the same 165 as the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] (if the value 166 is smaller than 2147483647) or the sysApplElmtRunIndex of the 167 SYSAPPL-MIB [RFC2287]. 169 1.3. Interpretation of the MIB Variables 171 Figure 1 shows an informal survey of the packet processing path, with 172 reference to counter names in brackets. 174 Received UDP-Lite Datagrams 175 | 176 | +- Full Coverage ---------------------+-> Deliver 177 | | | 178 +- Valid Header--+ +- >= Rec. Coverage --+ 179 | (InDatagrams) | | 180 | +- Partial -----+ 181 | (InPartialCov) | 182 | +- < Rec. Coverage --+ 183 | (EndpointViolCoverage) | 184 | | 185 | | 186 +- Header Error ---+ | 187 | | | 188 +- Checksum Error -+-----------------------------------+-> Discard 189 | (InBadChecksum) (InErrors) 190 | 191 +- Port Error -------------------------------------------> Discard 192 (NoPorts) 194 Figure 1: UDP-Lite Input Processing Path 196 A platform-independent test of the UDP-Lite implementations in two 197 connected end hosts may be performed as follows. 199 On the sending side, OutDatagrams and OutPartialCov are observed. 200 The ratio OutPartialCov/OutDatagrams describes the fraction (between 201 0 and 1) of datagrams using partial checksum coverage. 203 On the receiving side, InDatagrams, InPartialCov, and InErrors are 204 monitored. If datagrams are received from the given sender, InErrors 205 is close to zero, and InPartialCov is zero, no partial coverage is 206 employed. If no datagrams are received and InErrors increases 207 proportionally with the sending rate, a configuration error is likely 208 (a wrong value of receiver minimum checksum coverage). 210 The InBadChecksum counter reflects errors that may persist following 211 end-host processing, router processing, or link processing (this 212 includes illegal coverage values as defined in [RFC3828], since 213 checksum and checksum coverage are mutually inter-dependent). In 214 particular, InBadChecksum can serve as an indicator of the residual 215 link bit error rate: on links with higher bit error rates, a lower 216 value of the checksum coverage may help to reduce both the values of 217 InErrors and InBadChecksum. 219 By observing these values and adapting the configuration, a setting 220 may then be found that is more adapted to the specific type of link, 221 as well as the type of payload; indicated by a reduction of the 222 number of discarded datagrams (InErrors), leading to an improved 223 performance. 225 The above statistics are elementary and can be used to derive the 226 following information: 228 o The total number of incoming datagrams is InDatagrams + InErrors + 229 NoPorts 231 o The number of InErrors that were discarded due to problems other 232 than bad checksum is InErrors - InBadChecksum 234 o The number of InDatagrams that have full coverage is InDatagrams - 235 InPartialCov. 237 o The number of OutDatagrams that have full coverage is OutDatagrams 238 - OutPartialCov. 240 The following Case diagram [CASE] summarises the relationships 241 between the counters on the input processing path. 243 Transport Layer Interface 244 ------------------------------------------------------------- 245 /\ 246 || 247 ----------------------------- InDatagrams 248 || ^ 249 || | 250 || | 251 ||----------------------> InPartialCov 252 || | 253 || | 254 || v 255 || EndpointViolCoverage 256 || | 257 NoPorts <--------|| | 258 || | 259 ||------> InBadChecksum ------>| 260 || | 261 || | 262 || v 263 ||------------------------> InErrors 264 || 265 || 266 ------------------------------------------------------------- 267 Network Layer Interface 269 Figure 2: Counters for received UDP-Lite Datagrams 271 A configuration error may occur when a sender chooses a coverage 272 value for the datagrams that it sends that is less than the minimum 273 coverage configured by the intended recipient. The minimum coverage 274 is set on a per-session basis by the application associated with the 275 listening endpoint, and its current value is recorded in the 276 udpliteEndpointTable. Reception of valid datagrams with a checksum 277 coverage value less than this threshold results in dropping the 278 datagram [RFC3828] and incrementing InErrors. To improve debugging 279 of such (misconfigured) cases, an implementer may choose to support 280 the optional udpliteEndpointViolCoverage entry in the endpoint table 281 (Section 1.1.) that specifically counts datagrams falling in this 282 category. Without this feature, failure due to misconfiguration can 283 not be distinguished from datagram processing failure. 285 1.4. Conventions 287 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 288 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 289 document are to be interpreted as described in BCP 14, [RFC2119]. 291 2. The Internet-Standard Management Framework 293 For a detailed overview of the documents that describe the current 294 Internet-Standard Management Framework, please refer to section 7 of 295 RFC 3410 [RFC3410]. 297 Managed objects are accessed via a virtual information store, termed 298 the Management Information Base or MIB. MIB objects are generally 299 accessed through the Simple Network Management Protocol (SNMP). 300 Objects in the MIB are defined using the mechanisms defined in the 301 Structure of Management Information (SMI). This memo specifies a MIB 302 module that is compliant to the SMIv2, which is described in STD 58, 303 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 304 [RFC2580]. 306 3. Definitions 308 UDPLITE-MIB DEFINITIONS ::= BEGIN 310 IMPORTS 311 MODULE-IDENTITY, 312 OBJECT-TYPE, 313 mib-2, Unsigned32, 314 Counter32, Counter64 FROM SNMPv2-SMI -- [RFC2578] 316 MODULE-COMPLIANCE, 317 OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580] 319 InetAddress, 320 InetAddressType, 321 InetPortNumber FROM INET-ADDRESS-MIB; -- [RFC4001] 323 udpliteMIB MODULE-IDENTITY 324 LAST-UPDATED "200709270000Z" -- Thu, 27th Sep 2007 325 ORGANIZATION "IETF TSV Working Group (TSVWG)" 326 CONTACT-INFO 327 "IETF TSV Working Group 328 http://www.ietf.org/html.charters/tsvwg-charter.html 329 Mailing List: tsvwg@ietf.org 331 Gerrit Renker, Godred Fairhurst 332 Electronics Research Group 333 Department of Engineering, University of Abderdeen 334 Fraser Noble Building, Aberdeen AB24 3UE, UK" 335 DESCRIPTION 336 "The MIB module for managing UDP-Lite implementations. 337 Copyright (C) The IETF Trust (2007). This version of 338 this MIB module is part of RFC ZZZ; see the RFC 339 itself for full legal notices." 341 -- RFC Ed.: replace ZZZ with actual RFC number & remove this note 343 REVISION "200709270000Z" -- Thu, 27th Sep 2007 344 DESCRIPTION 345 "Initial SMIv2 revision, based on the format of the UDP 346 MIB module (RFC 4113) and published as RFC ZZZ." 348 -- RFC Ed.: replace ZZZ with actual RFC number & remove this note 350 ::= { mib-2 XXX } 352 -- RFC Ed.: replace XXX with OBJECT-IDENTIFIER & remove this note 354 udplite OBJECT IDENTIFIER ::= { udpliteMIB 1 } 356 udpliteInDatagrams OBJECT-TYPE -- as in UDP-MIB 357 SYNTAX Counter64 358 MAX-ACCESS read-only 359 STATUS current 360 DESCRIPTION 361 "The total number of UDP-Lite datagrams that were 362 delivered to UDP-Lite users. 363 Discontinuities in the value of this counter can occur 364 at re-initialization of the management system, and at 365 other times as indicated by discontinuities in the 366 value of sysUpTime." 367 ::= { udplite 1 } 369 udpliteInPartialCov OBJECT-TYPE -- new in UDP-Lite 370 SYNTAX Counter64 371 MAX-ACCESS read-only 372 STATUS current 373 DESCRIPTION 374 "The total number of UDP-Lite datagrams that were 375 delivered to UDP-Lite users (applications) and whose 376 checksum coverage was strictly less than the datagram 377 length. 378 Discontinuities in the value of this counter can occur 379 at re-initialization of the management system, and at 380 other times as indicated by discontinuities in the 381 value of sysUpTime." 382 ::= { udplite 2 } 384 udpliteNoPorts OBJECT-TYPE -- as in UDP-MIB 385 SYNTAX Counter32 386 MAX-ACCESS read-only 387 STATUS current 388 DESCRIPTION 389 "The total number of received UDP-Lite datagrams for 390 which there was no listener at the destination port. 391 Discontinuities in the value of this counter can occur 392 at re-initialization of the management system, and at 393 other times as indicated by discontinuities in the 394 value of sysUpTime." 395 ::= { udplite 3 } 397 udpliteInErrors OBJECT-TYPE -- as in UDP-MIB 398 SYNTAX Counter32 399 MAX-ACCESS read-only 400 STATUS current 401 DESCRIPTION 402 "The number of received UDP-Lite datagrams that could not 403 be delivered for reasons other than the lack of an 404 application at the destination port. 405 Discontinuities in the value of this counter can occur 406 at re-initialization of the management system, and at 407 other times as indicated by discontinuities in the 408 value of sysUpTime." 409 ::= { udplite 4 } 411 udpliteInBadChecksum OBJECT-TYPE -- new in UDP-Lite 412 SYNTAX Counter32 413 MAX-ACCESS read-only 414 STATUS current 415 DESCRIPTION 416 "The number of received UDP-Lite datagrams whose checksum 417 could not be validated. This includes illegal checksum 418 coverage values, as their use would lead to incorrect 419 checksums. 420 Discontinuities in the value of this counter can occur 421 at re-initialization of the management system, and at 422 other times as indicated by discontinuities in the 423 value of sysUpTime." 424 REFERENCE "RFC 3828, section 3.1" 425 ::= { udplite 5 } 427 udpliteOutDatagrams OBJECT-TYPE -- as in UDP-MIB 428 SYNTAX Counter64 429 MAX-ACCESS read-only 430 STATUS current 431 DESCRIPTION 432 "The total number of UDP-Lite datagrams sent from this 433 entity. 434 Discontinuities in the value of this counter can occur 435 at re-initialization of the management system, and at 436 other times as indicated by discontinuities in the 437 value of sysUpTime." 438 ::= { udplite 6 } 440 udpliteOutPartialCov OBJECT-TYPE -- new in UDP-Lite 441 SYNTAX Counter64 442 MAX-ACCESS read-only 443 STATUS current 444 DESCRIPTION 445 "The total number of udpliteOutDatagrams whose 446 checksum coverage was strictly less than the 447 datagram length. 448 Discontinuities in the value of this counter can occur 449 at re-initialization of the management system, and at 450 other times as indicated by discontinuities in the 451 value of sysUpTime." 452 ::= { udplite 7 } 454 udpliteEndpointTable OBJECT-TYPE 455 SYNTAX SEQUENCE OF UdpLiteEndpointEntry 456 MAX-ACCESS not-accessible 457 STATUS current 458 DESCRIPTION 459 "A table containing information about this entity's 460 UDP-Lite endpoints on which a local application is 461 currently accepting or sending datagrams. 463 The address type in this table represents the address 464 type used for the communication, irrespective of the 465 higher-layer abstraction. For example, an application 466 using IPv6 'sockets' to communicate via IPv4 between 467 ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use 468 InetAddressType ipv4(1). 470 Like the udpTable in RFC 4113, this table also allows 471 the representation of an application that completely 472 specifies both local and remote addresses and ports. A 473 listening application is represented in three possible 474 ways: 476 1) An application that is willing to accept both IPv4 477 and IPv6 datagrams is represented by a 478 udpliteEndpointLocalAddressType of unknown(0) and a 479 udpliteEndpointLocalAddress of ''h (a zero-length 480 octet-string). 482 2) An application that is willing to accept only IPv4 483 or only IPv6 datagrams is represented by a 484 udpliteEndpointLocalAddressType of the appropriate 485 address type and a udpliteEndpointLocalAddress of 486 '0.0.0.0' or '::' respectively. 488 3) An application that is listening for datagrams only 489 for a specific IP address but from any remote 490 system is represented by a 491 udpliteEndpointLocalAddressType of the appropriate 492 address type, with udpliteEndpointLocalAddress 493 specifying the local address. 495 In all cases where the remote is a wildcard address, 496 the udpliteEndpointRemoteAddressType is unknown(0), 497 the udpliteEndpointRemoteAddress is ''h (a zero-length 498 octet-string), and the udpliteEndpointRemotePort is 0. 500 If the operating system is demultiplexing UDP-Lite 501 packets by remote address/port, or if the application 502 has 'connected' the socket specifying a default remote 503 address/port, the udpliteEndpointRemote* values should 504 be used to reflect this." 505 ::= { udplite 8 } 507 udpliteEndpointEntry OBJECT-TYPE 508 SYNTAX UdpLiteEndpointEntry 509 MAX-ACCESS not-accessible 510 STATUS current 511 DESCRIPTION 512 "Information about a particular current UDP-Lite endpoint. 514 Implementers need to pay attention to the sizes of 515 udpliteEndpointLocalAddress/RemoteAddress, as OIDs of 516 column instances in this table must have no more than 517 128 sub-identifiers in order to remain accessible with 518 SNMPv1, SNMPv2c, and SNMPv3." 519 INDEX { udpliteEndpointLocalAddressType, 520 udpliteEndpointLocalAddress, 521 udpliteEndpointLocalPort, 522 udpliteEndpointRemoteAddressType, 523 udpliteEndpointRemoteAddress, 524 udpliteEndpointRemotePort, 525 udpliteEndpointInstance } 526 ::= { udpliteEndpointTable 1 } 528 UdpLiteEndpointEntry ::= SEQUENCE { 529 udpliteEndpointLocalAddressType InetAddressType, 530 udpliteEndpointLocalAddress InetAddress, 531 udpliteEndpointLocalPort InetPortNumber, 532 udpliteEndpointRemoteAddressType InetAddressType, 533 udpliteEndpointRemoteAddress InetAddress, 534 udpliteEndpointRemotePort InetPortNumber, 535 udpliteEndpointInstance Unsigned32, 536 udpliteEndpointProcess Unsigned32, 537 udpliteEndpointMinCoverage Unsigned32, 538 udpliteEndpointViolCoverage Counter32 539 } 541 udpliteEndpointLocalAddressType OBJECT-TYPE 542 SYNTAX InetAddressType 543 MAX-ACCESS not-accessible 544 STATUS current 545 DESCRIPTION 546 "The address type of udpliteEndpointLocalAddress. Only 547 IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or 548 unknown(0) if datagrams for all local IP addresses are 549 accepted." 550 ::= { udpliteEndpointEntry 1 } 552 udpliteEndpointLocalAddress OBJECT-TYPE 553 SYNTAX InetAddress 554 MAX-ACCESS not-accessible 555 STATUS current 556 DESCRIPTION 557 "The local IP address for this UDP-Lite endpoint. 559 The value of this object can be represented in three 560 possible ways, depending on the characteristics of the 561 listening application: 563 1. For an application that is willing to accept both 564 IPv4 and IPv6 datagrams, the value of this object 565 must be ''h (a zero-length octet-string), with 566 the value of the corresponding instance of the 567 EndpointLocalAddressType object being unknown(0). 569 2. For an application that is willing to accept only 570 IPv4 or only IPv6 datagrams, the value of this 571 object must be '0.0.0.0' or '::', respectively, 572 while the corresponding instance of the 573 EndpointLocalAddressType object represents the 574 appropriate address type. 576 3. For an application that is listening for data 577 destined only to a specific IP address, the value 578 of this object is the specific IP address for 579 which this node is receiving packets, with the 580 corresponding instance of the 581 EndpointLocalAddressType object representing the 582 appropriate address type. 584 As this object is used in the index for the 585 udpliteEndpointTable, implementors should be careful 586 not to create entries that would result in OIDs with 587 more than 128 subidentifiers; else the information 588 cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." 589 ::= { udpliteEndpointEntry 2 } 591 udpliteEndpointLocalPort OBJECT-TYPE 592 SYNTAX InetPortNumber 593 MAX-ACCESS not-accessible 594 STATUS current 595 DESCRIPTION 596 "The local port number for this UDP-Lite endpoint." 597 ::= { udpliteEndpointEntry 3 } 599 udpliteEndpointRemoteAddressType OBJECT-TYPE 600 SYNTAX InetAddressType 601 MAX-ACCESS not-accessible 602 STATUS current 603 DESCRIPTION 604 "The address type of udpliteEndpointRemoteAddress. Only 605 IPv4, IPv4z, IPv6, and IPv6z addresses are expected, or 606 unknown(0) if datagrams for all remote IP addresses are 607 accepted. Also, note that some combinations of 608 udpliteEndpointLocalAdressType and 609 udpliteEndpointRemoteAddressType are not supported. In 610 particular, if the value of this object is not 611 unknown(0), it is expected to always refer to the 612 same IP version as udpliteEndpointLocalAddressType." 613 ::= { udpliteEndpointEntry 4 } 615 udpliteEndpointRemoteAddress OBJECT-TYPE 616 SYNTAX InetAddress 617 MAX-ACCESS not-accessible 618 STATUS current 619 DESCRIPTION 620 "The remote IP address for this UDP-Lite endpoint. If 621 datagrams from any remote system are to be accepted, 622 this value is ''h (a zero-length octet-string). 623 Otherwise, it has the type described by 624 udpliteEndpointRemoteAddressType and is the address of 625 the remote system from which datagrams are to be 626 accepted (or to which all datagrams will be sent). 628 As this object is used in the index for the 629 udpliteEndpointTable, implementors should be careful 630 not to create entries that would result in OIDs with 631 more than 128 subidentifiers; else the information 632 cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3." 633 ::= { udpliteEndpointEntry 5 } 635 udpliteEndpointRemotePort OBJECT-TYPE 636 SYNTAX InetPortNumber 637 MAX-ACCESS not-accessible 638 STATUS current 639 DESCRIPTION 640 "The remote port number for this UDP-Lite endpoint. If 641 datagrams from any remote system are to be accepted, 642 this value is zero." 643 ::= { udpliteEndpointEntry 6 } 645 udpliteEndpointInstance OBJECT-TYPE 646 SYNTAX Unsigned32 (1..'ffffffff'h) 647 MAX-ACCESS not-accessible 648 STATUS current 649 DESCRIPTION 650 "The instance of this tuple. This object is used to 651 distinguish among multiple processes 'connected' to 652 the same UDP-Lite endpoint. For example, on a system 653 implementing the BSD sockets interface, this would be 654 used to support the SO_REUSEADDR and SO_REUSEPORT 655 socket options." 656 ::= { udpliteEndpointEntry 7 } 658 udpliteEndpointProcess OBJECT-TYPE 659 SYNTAX Unsigned32 660 MAX-ACCESS read-only 661 STATUS current 662 DESCRIPTION 663 "A unique value corresponding to a piece of software 664 running on this endpoint. Where possible, this should 665 be the system's native, unique identification number. 667 This identifier is platform-specific. It may correspond 668 to a process ID or application instance number. It is 669 expected to be the same as HOST-RESOURCES-MIB:: 670 hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for 671 some row in the appropriate tables. 673 A value of zero indicates that the application 674 instance(s) cannot be identified." 675 ::= { udpliteEndpointEntry 8 } 677 udpliteEndpointMinCoverage OBJECT-TYPE -- new in UDP-Lite 678 SYNTAX Unsigned32 679 MAX-ACCESS read-only 680 STATUS current 681 DESCRIPTION 682 "The minimum checksum coverage expected by this endpoint. 683 If set to 0, only fully covered datagrams are accepted." 684 REFERENCE "RFC 3828, section 3.1" 685 ::= { udpliteEndpointEntry 9 } 687 udpliteEndpointViolCoverage OBJECT-TYPE -- new / optional in UDP-Lite 688 SYNTAX Counter32 689 MAX-ACCESS read-only 690 STATUS current 691 DESCRIPTION 692 "The number of datagrams received by this endpoint whose 693 checksum coverage violated the minimum coverage threshold 694 set for this connection (i.e. all valid datagrams whose 695 checksum coverage was strictly smaller than the minimum, 696 as defined in RFC 3828)." 697 ::= { udpliteEndpointEntry 10 } 699 udpliteMIBConformance OBJECT IDENTIFIER ::= { udpliteMIB 2 } 701 udpliteMIBCompliance MODULE-COMPLIANCE 702 STATUS current 703 DESCRIPTION 704 "The compliance statement for systems that implement 705 UDP-Lite. 707 There are a number of INDEX objects that cannot be 708 represented in the form of OBJECT clauses in SMIv2, 709 but for which we have the following compliance 710 requirements, expressed in OBJECT clause form in this 711 description clause: 713 -- OBJECT udpliteEndpointLocalAddressType 714 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 715 -- ipv6(2), ipv4z(3), 716 -- ipv6z(4) } 717 -- DESCRIPTION 718 -- Support for dns(16) is not required. 719 -- OBJECT udpliteEndpointLocalAddress 721 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 722 -- DESCRIPTION 723 -- Support is only required for zero-length 724 -- octet-strings, and for scoped and unscoped 725 -- IPv4 and IPv6 addresses. 726 -- OBJECT udpliteEndpointRemoteAddressType 727 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 728 -- ipv6(2), ipv4z(3), 729 -- ipv6z(4) } 730 -- DESCRIPTION 731 -- Support for dns(16) is not required. 733 -- OBJECT udpliteEndpointRemoteAddress 734 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 735 -- DESCRIPTION 736 -- Support is only required for zero-length 737 -- octet-strings, and for scoped and unscoped 738 -- IPv4 and IPv6 addresses. 739 " 740 MODULE -- this module 741 MANDATORY-GROUPS { udpliteBaseGroup, 742 udplitePartialCsumGroup, 743 udpliteEndpointGroup } 744 GROUP udpliteAppGroup 745 DESCRIPTION 746 "This group is optional and provides supplementary 747 information about the effectivity of using minimum 748 checksum coverage thresholds on endpoints." 749 ::= { udpliteMIBConformance 1 } 751 udpliteMIBGroups OBJECT IDENTIFIER ::= { udpliteMIBConformance 2 } 753 udpliteBaseGroup OBJECT-GROUP -- as in UDP 754 OBJECTS { udpliteInDatagrams, udpliteNoPorts, udpliteInErrors, 755 udpliteOutDatagrams } 756 STATUS current 757 DESCRIPTION 758 "The group of objects providing for counters of 759 basic UDP-like statistics." 760 ::= { udpliteMIBGroups 1 } 762 udplitePartialCsumGroup OBJECT-GROUP -- specific to UDP-Lite 763 OBJECTS { udpliteInPartialCov, 764 udpliteInBadChecksum, 765 udpliteOutPartialCov } 766 STATUS current 767 DESCRIPTION 768 "The group of objects providing for counters of 769 transport-layer statistics exclusive to UDP-Lite." 770 ::= { udpliteMIBGroups 2 } 772 udpliteEndpointGroup OBJECT-GROUP 773 OBJECTS { udpliteEndpointProcess, udpliteEndpointMinCoverage } 774 STATUS current 775 DESCRIPTION 776 "The group of objects providing for the IP version 777 independent management of UDP-Lite 'endpoints'." 778 ::= { udpliteMIBGroups 3 } 780 udpliteAppGroup OBJECT-GROUP 781 OBJECTS { udpliteEndpointViolCoverage } 782 STATUS current 783 DESCRIPTION 784 "The group of objects that provide application-level 785 information for the configuration management of 786 UDP-Lite 'endpoints'." 787 ::= { udpliteMIBGroups 4 } 789 END 791 4. Security Considerations 793 There are no management objects defined in this MIB module that have 794 a MAX-ACCESS clause of read-write and/or read-create. So, if this 795 MIB module is implemented correctly, then there is no risk that an 796 intruder can alter or create any management objects of this MIB 797 module via direct SNMP SET operations. 799 Some of the readable objects in this MIB module (i.e., objects with a 800 MAX-ACCESS other than not-accessible) may be considered sensitive or 801 vulnerable in some network environments. It is thus important to 802 control even GET and/or NOTIFY access to these objects and possibly 803 to even encrypt the values of these objects when sending them over 804 the network via SNMP. These are the tables and objects and their 805 sensitivity/vulnerability: 807 Since UDP-Lite permits the delivery of (partially) corrupted data to 808 an end host, the counters defined in this MIB module ay be used to 809 imply information about the characteristics of the end-to-end path 810 over which the datagrams are communicated. 812 The indices of the udpliteEndpointTable contain information about the 813 listeners on an entity. In particular, the udpliteEndpointLocalPort 814 and udpliteLocalPort objects in the indices can be used to identify 815 what ports are open on the machine and which attacks are likely to 816 succeed, without the attacker having to run a port scanner. The 817 table also identifies the currently listening UDP-Lite ports. This 818 could be used to infer the type of application associated with the 819 port at the receiver. The udpliteEndpointMinCoverage provides 820 information about the requirements of the transport service 821 associated with a specific UDP-Lite port. This provides additional 822 detail concerning the type of application associated with the port at 823 the receiver. 825 SNMP versions prior to SNMPv3 did not include adequate security. 826 Even if the network itself is secure (for example by using IPsec), 827 even then, there is no control as to who on the secure network is 828 allowed to access and GET/SET (read/change/create/delete) the objects 829 in this MIB module. 831 It is RECOMMENDED that implementers consider the security features as 832 provided by the SNMPv3 framework (see RFC 3410 [RFC3410], section 8), 833 including full support for the SNMPv3 cryptographic mechanisms (for 834 authentication and privacy). 836 Further, deployment of SNMP versions prior to SNMPv3 is NOT 837 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 838 enable cryptographic security. It is then a customer/operator 839 responsibility to ensure that the SNMP entity giving access to an 840 instance of this MIB module is properly configured to give access to 841 the objects only to those principals (users) that have legitimate 842 rights to indeed GET or SET (change/create/delete) them. 844 5. IANA Considerations 846 The MIB module in this document uses the following IANA-assigned 847 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 849 +------------+-------------------------+ 850 | Descriptor | OBJECT IDENTIFIER value | 851 +------------+-------------------------+ 852 | udpliteMIB | { mib-2 XXX } | 853 +------------+-------------------------+ 855 ==> Note to the RFC Editor (to be removed prior to publication): 857 The IANA is requested to assign a value for "XXX" under the 'mib-2' 858 subtree and to record the assignment in the SMI Numbers registry. 859 When the assignment has been made, the RFC Editor is asked to replace 860 "XXX" (here and in the MIB module) with the assigned value and to 861 remove this note. 863 6. Acknowledgments 865 The design of the MIB module presented in this document owes much to 866 the format of the module presented in [RFC4113]. 868 ==> NOTE TO THE RFC EDITOR: PLEASE REMOVE THIS LOG PRIOR TO PUBLICATION 870 Revision 00 of draft-ietf-tsvwg-udplite-mib was obsoleted by revision 871 01 due to a syntax error (quote transposed with full-stop) in the MIB 872 module, which is corrected in rev-01. Thanks to Magnus Westerlund 873 for identifying this. 875 Draft draft-ietf-tsvwg-udplite-mib-00 was published as a work item of 876 tsvwg, June 2007. 878 The following changelog lists the changes up to revision 02 (which 879 became rev-00/01 of this document) of the preceding individual draft 880 submission draft-renker-tsvwg-udplite-mib. 882 Changes introduced in rev-01: 884 o General: 886 - incremented revision number to 01 888 - updated date to November 890 - rephrased abstract 892 o Section 1: 894 - rephrased the begining of the second paragraph 896 o Section 1.1: 898 - rephrased some items 900 - added missing InBadChecksum heading 902 - updated text to refer to 64bit counters 904 o Section 1.3: 906 - removed 'x' in 'datagrams' 908 - rephrased for clarity 910 - Figure 1: missing bracked text should be InErrors 912 - Figure 1: correction - NoPorts are not counted as InDatagrams 914 o Section 2: 916 - made the "Editor's Note" stand out more 918 o Section 3 / MIB: 920 - upgraded 11 32bit counters to 64bit 922 - moved from experimental to mib-2 924 - updated revision date 926 o Section 4: 928 - some minor changes 930 o Section 5: 932 - again highlighted the Editor's Note by using `==>' to make it 933 consistent 935 Changes introduced in rev-02: 937 o General: 939 - updated month, date, and revision 941 - changed `transport layer entities' to `endpoints' in abstract 943 o Section 1: 945 - added missing comma after `option' 947 - split explanatory clause after colon into standalone clause 949 o Section 1.1: 951 - added a bullet list of standard counters known from the UDP 952 MIB 954 - added a note that NoPorts does not increment InErrors 956 - removed description of InBadCoverage (no longer in MIB, see 957 below) 959 - qualified note with on 64-bit counters wrt `non-error' 960 counters, reflecting the change that all error counters have 961 been changed to Counter32 962 - Nit: changed `fairly recent' -> `more recent' 964 - removed traces of InBadCoverage (see below) 966 o Section 1.3: 968 - corrected figure 1 (NoPorts was inconsistent with text; Rec 969 Coverage was incorrectly labelled, it didn't show 970 EndpointViolCoverage; slight reformatting) 972 - Nit: `wrong value' -> `a wrong value' 974 - clarified that InBadChecksum can also serve as indicator of 975 path bit error rate 977 - Nit: `which' -> `that' in `a setting may then ...' and `A 978 configuration error may ...' 980 - removed traces of InBadCoverage (see below) 982 o Section 3 (the MIB): 984 - updated LAST-UPDATED and REVISION to match the revision date 986 - updated the Copyright in DESCRIPTION from 2006 to 2007 988 - converted all error counters to Counter32, following IETF 989 input for rev-01 991 - added a required IMPORTS statement for Counter32 to UDPLITE- 992 MIB DEFINITIONS 994 - demoted the following error counters from Counter64 to 995 Counter32: udpliteNoPorts, udpliteInErrors, 996 updliteInBadChecksum, udpliteEndpointViolCoverage 998 - removed second, redundant MIB-2 number of udplite, following 999 suggestion by Bill Fenner. 1001 - updated warning about maximum number of sub-identifiers in 1002 udpliteEndpointEntry, to reflect new structure 1004 - udplite now comes as entry number 1 in the udpliteMIB tree 1006 - accordingly changed the identifier of udpliteMIBConformance 1007 to 2 1008 - updated all RFC editor notes with regard to the assignment of 1009 mib-2 identifier numbers (now only a single one required) 1011 - updated section `IANA Considerations' with regard to this 1012 change 1014 - removed the InBadCoverage counter since it is subsumed by 1015 InBadChecksum (see below) 1017 - updated the following identifier numbers for consistency 1018 after removal: udpliteInBadChecksum (6 -> 5), 1019 udpliteOutDatagrams (7 -> 6), udpliteOutPartialCov (8 -> 7), 1020 udpliteEndpointTable (9 -> 8) 1022 - removed udpliteInBadCoverage from udplitePartialCsumGroup 1024 - extended the definition of InBadChecksum to include invalid 1025 checksum coverage 1027 - added RFC 3828 references for udpliteEndpointMinCoverage and 1028 udpliteEndpointViolCoverage 1030 - updated the description of udpliteEndpointInstance with 1031 respect to draft-persson-v6ops-mib-issue-01.txt, section 3.2 1033 o Section 7 (References): 1035 - RFC 4113 (UDP MIB) becomes informative, not normative 1037 o Note on the removal of InBadCoverage: Following rev-01, this 1038 counter has been removed since - with the exception of obviously 1039 buggy UDP-Lite stacks - it is subsumed by InBadChecksum. An 1040 illegal checksum value which is not the cause of a buggy 1041 implementation will in practically all cases lead to an incorrect 1042 checksum value, so that one counter implies information inherent 1043 in the other. 1045 ====> END OF NOTE TO THE RFC EDITOR <==== 1047 7. References 1049 7.1. Normative References 1051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1052 Requirement Levels", BCP 14, RFC 2119, March 1997. 1054 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1055 Rose, M., and S. Waldbusser, "Structure of Management 1056 Information Version 2 (SMIv2)", STD 58, RFC 2578, 1057 April 1999. 1059 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1060 Rose, M., and S. Waldbusser, "Textual Conventions for 1061 SMIv2", STD 58, RFC 2579, April 1999. 1063 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1064 Rose, M., and S. Waldbusser, "Conformance Statements for 1065 SMIv2", STD 58, RFC 2580, April 1999. 1067 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 1068 G. Fairhurst, "The Lightweight User Datagram Protocol 1069 (UDP-Lite)", RFC 3828, July 2004. 1071 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 1072 Schoenwaelder, "Textual Conventions for Internet Network 1073 Addresses", RFC 4001, February 2005. 1075 7.2. Informative References 1077 [CASE] Case, J. and C. Partridge, "Case Diagrams: A First Step to 1078 Diagrammed Management Information Bases", ACM Computer 1079 Communications Review, 19(1):13-16, January 1989. 1081 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1082 August 1980. 1084 [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level 1085 Managed Objects for Applications", RFC 2287, 1086 February 1998. 1088 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", 1089 RFC 2790, March 2000. 1091 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 1092 "Introduction and Applicability Statements for Internet- 1093 Standard Management Framework", RFC 3410, December 2002. 1095 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 1096 the User Datagram Protocol (UDP)", RFC 4113, June 2005. 1098 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 1099 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 1101 Authors' Addresses 1103 Gerrit Renker 1104 University of Aberdeen 1105 Department of Engineering 1106 Fraser Noble Building 1107 Aberdeen AB24 3UE 1108 Scotland 1110 Email: gerrit@erg.abdn.ac.uk 1111 URI: http://www.erg.abdn.ac.uk 1113 Godred Fairhurst 1114 University of Aberdeen 1115 Department of Engineering 1116 Fraser Noble Building 1117 Aberdeen AB24 3UE 1118 Scotland 1120 Email: gorry@erg.abdn.ac.uk 1121 URI: http://www.erg.abdn.ac.uk 1123 Full Copyright Statement 1125 Copyright (C) The IETF Trust (2007). 1127 This document is subject to the rights, licenses and restrictions 1128 contained in BCP 78, and except as set forth therein, the authors 1129 retain all their rights. 1131 This document and the information contained herein are provided on an 1132 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1133 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1134 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1135 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1136 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1137 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1139 Intellectual Property 1141 The IETF takes no position regarding the validity or scope of any 1142 Intellectual Property Rights or other rights that might be claimed to 1143 pertain to the implementation or use of the technology described in 1144 this document or the extent to which any license under such rights 1145 might or might not be available; nor does it represent that it has 1146 made any independent effort to identify any such rights. Information 1147 on the procedures with respect to rights in RFC documents can be 1148 found in BCP 78 and BCP 79. 1150 Copies of IPR disclosures made to the IETF Secretariat and any 1151 assurances of licenses to be made available, or the result of an 1152 attempt made to obtain a general license or permission for the use of 1153 such proprietary rights by implementers or users of this 1154 specification can be obtained from the IETF on-line IPR repository at 1155 http://www.ietf.org/ipr. 1157 The IETF invites any interested party to bring to its attention any 1158 copyrights, patents or patent applications, or other proprietary 1159 rights that may cover technology that may be required to implement 1160 this standard. Please address the information to the IETF at 1161 ietf-ipr@ietf.org. 1163 Acknowledgment 1165 Funding for the RFC Editor function is provided by the IETF 1166 Administrative Support Activity (IASA).