idnits 2.17.1 draft-ietf-ipv6-rfc2013-update-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 37 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 837: '... RECOMMENDED. Instead, it is RECOMM...' -- The abstract seems to indicate that this document obsoletes RFC2013, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (November 2003) is 7468 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) == Unused Reference: 'RFC768' is defined on line 759, but no explicit reference was found in the text == Unused Reference: 'RFC3291' is defined on line 782, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3291 (Obsoleted by RFC 4001) -- Obsolete informational reference (is this intentional?): RFC 2013 (Obsoleted by RFC 4113) -- Obsolete informational reference (is this intentional?): RFC 2454 (Obsoleted by RFC 4113, RFC 8096) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 MIB Revision Design Team Bill Fenner 2 INTERNET-DRAFT AT&T Research 3 Expires: May 2004 John Flick 4 Hewlett-Packard Company 5 November 2003 7 Management Information Base 8 for the User Datagram Protocol (UDP) 9 draft-ietf-ipv6-rfc2013-update-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet- Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This document is a product of the IPv6 MIB Revision Design Team. 33 Comments should be addressed to the authors, or to the mailing list 34 at ipv6@ietf.org. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This memo defines a portion of the Management Information Base (MIB) 43 for use with network management protocols in the Internet community. 44 In particular, it describes managed objects used for implementations 45 of the User Datagram Protocol (UDP) in an IP version independent 46 manner. This memo obsoletes RFCs 2013 and 2454. 48 Table of Contents 50 1. The Internet-Standard Management Framework ................. 4 51 2. Overview ................................................... 5 52 2.1. Relationship to Other MIBs ............................... 5 53 2.1.1. Relationship to RFC1213-MIB ............................ 5 54 2.1.2. Relationship to the IPV6-UDP-MIB ....................... 6 55 2.1.3. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB ..... 6 56 3. Definitions ................................................ 6 57 4. Intellectual Property ...................................... 15 58 5. Acknowledgements ........................................... 16 59 6. Contributers ............................................... 16 60 7. Normative References ....................................... 16 61 8. Informative References ..................................... 17 62 9. Security Considerations .................................... 17 63 10. Editors Addresses ......................................... 18 64 11. Full Copyright Statement .................................. 19 66 Revision History 68 [Note to RFC Editor: Please remove prior to publication] 70 Changes from draft-ietf-ipv6-rfc2013-update-00.txt 72 24 October 2003 74 Dropped udpEndpointInDatagrams, udpEndpointHCInDatagrams, 75 udpEndpointOutDatagrams, udpEndpointHCOutDatagrams, 76 udpEndpointInOctets, udpEndpointHCInOctets, 77 udpEndpointOutOctets, udpEndpointHCOutOctets, and 78 udpEndpointStartTime. 80 Removed udpEndpointStatsGroup, udpEndpointHCDatagramStatsGroup 81 and udpEndpointHCOctetStatsGroup. 83 Changed udpEndpointInstance back to read-only, since there is no 84 longer a mandatory non-auxiliary column in the udpEndpointTable. 86 Removed Open Issues section. 88 Moved Revision History section to beginning of document and 89 removed its section number, to allow for easier removal at RFC 90 publication. 92 Updated to latest MIB boilerplate. 94 Updated working group mailing list address. 96 Removed SIZE constraints from udpEndpointLocalAddress and 97 udpEndpointRemoteAddress, and updated the DESCRIPTION clause of 98 udpEndpointEntry. 100 Removed "Use of IP Addresses" section, since this information is 101 already documented in the relevant MIB DESCRIPTIONs. 103 Changes from draft-ietf-ipngwg-rfc2013-update-01.txt 105 28 May 2002 107 Removed udpConnectionTable 109 Renamed ListenerTable to EndpointTable, since with a remote 110 address Listener is not quite correct. 112 Use ''h consistently for 'any IP address', instead of sometimes 113 ''h and sometimes all-zeroes of the right address family. 115 Use "Datagram" instead of "Packet" to talk about UDP datagrams. 117 Added mandatory udpEndpointStartTime, this also fixes the 118 udpEndpointInstance needing to be read-only and mandatory. 120 Make udpEndpointProcess mandatory on systems that have process 121 IDs. 123 Make a note of { udp 6 } in a comment for clarity on why it's 124 skipped. 126 Fleshed out section 3. 128 Changed the deprecated udpLocalPort SYNTAX to Integer32. Since 129 it was already restricted to (0..65536) this is not a semantic 130 change. 132 Changes from draft-ietf-ipngwg-rfc2013-update-00.txt 134 14 November 2001 136 Added udpConnectionTable 138 Added udpListenerRemoteAddressType, to distinguish e.g. 139 IPV6_V6ONLY 141 Added counters to udpListenerTable and udpConnectionTable 143 Changes from draft-ops-rfc2013-update-00.txt 144 12 Jul 2001 146 Turned into IPNG WG document 148 Changes from first draft posted to v6mib mailing list: 150 23 Feb 2001 152 Made threshold for HC packet counters 1Mpps 154 Added copyright statements and table of contents 156 21 Feb 2001 -- Juergen's changes 158 Renamed udpInetTable to udpListenerTable 160 Updated Conformance info 162 6 Feb 2001 164 Removed v6-only objects. 166 Removed remote and instance objects, turning the table back into 167 a listener-only table. 169 Renamed inetUdp* to udpInet* 171 Added HC in and out datagram counters 173 Added SIZE restriction to udpListenerLocalAddress. (36 = 32- 174 byte addresses plus 4-byte scope, but it's just a strawman) 176 Used InetPortNumber TC from updated INET-ADDRESS-MIB 178 Updated compliance statements. 180 Added Keith to authors 182 Added open issues section. 184 1. The Internet-Standard Management Framework 186 For a detailed overview of the documents that describe the current 187 Internet-Standard Management Framework, please refer to section 7 of 188 RFC 3410 [RFC3410]. 190 Managed objects are accessed via a virtual information store, termed 191 the Management Information Base or MIB. MIB objects are generally 192 accessed through the Simple Network Management Protocol (SNMP). 193 Objects in the MIB are defined using the mechanisms defined in the 194 Structure of Management Information (SMI). This memo specifies a MIB 195 module that is compliant to the SMIv2, which is described in STD 58, 196 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 197 [RFC2580]. 199 2. Overview 201 The current UDP-MIB defined in this memo consists of one table and a 202 group of scalars: 204 - The udp group of scalars reports parameters and statistics of a 205 UDP protocol engine. Two scalars udpHCInDatagrams and 206 udpHCOutDatagrams have been added to this group since the 207 publication of RFC 2013 in order to provide high-capacity 208 counters for fast networks. 210 - The udpEndpointTable provides access to status information for 211 all UDP endpoints handled by a UDP protocol engine. The table 212 provides for strictly listening endpoints, as with the 213 historical udpTable, and also for "connected" UDP endpoints, 214 which only accept packets from a given remote system. It also 215 reports identification of the operating system level processes 216 which handles UDP connections. 218 2.1. Relationship to Other MIBs 220 This section discusses the relationship of this UDP-MIB module to 221 other MIB modules. 223 2.1.1. Relationship to RFC1213-MIB 225 UDP related MIB objects were originally defined as part of the 226 RFC1213-MIB defined in RFC 1213 [RFC1213]. The UDP related objects of 227 the RFC1213-MIB were later copied into a separate MIB module and 228 published in RFC 2013 [RFC2013] in SMIv2 format. 230 The previous versions of the UDP-MIB both defined the udpTable, which 231 has been deprecated for basically two reasons: 233 (1) The udpTable only supports IPv4. 235 The current approach in the IETF is to write IP version neutral 236 MIBs rather than having different definitions for various version 237 of IP. This reduces the amount of overhead when new objects are 238 introduced since there is only one place to add them. Hence, the 239 approach taken in RFC 2454 [RFC2454] of having separate tables is 240 not continued. 242 (2) The udpTable does not permit describing "connected" UDP 243 endpoints. 245 It turns out that "connected" endpoints tend to have a different 246 behaviour and management access pattern compared to listening 247 endpoints. Adding remote endpoint information to the 248 udpEndpointTable thus allows for the addition of specific status 249 and statistic objects for "connected" endpoints and connections. 251 2.1.2. Relationship to the IPV6-UDP-MIB 253 The IPV6-UDP-MIB defined in RFC 2454 has been moved to Historic since 254 the approach of having separate IP version specific tables is not 255 followed anymore. Implementation of RFC 2454 is thus not suggested 256 anymore. 258 2.1.3. Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB 260 The udpEndpointTable reports the identification of the operating 261 system level process which handles a connection or a listening 262 endpoint. The value is reported as an Unsigned32 which is expected to 263 be the same as the hrSWRunIndex of the HOST-RESOURCES-MIB [RFC2790] 264 (if the value is smaller than 2147483647) or the sysApplElmtRunIndex 265 of the SYSAPPL-MIB [RFC2287]. This allows managment applications to 266 identify the UDP connections that belong to an operating system level 267 process, which has proven to be valuable in operational environments. 269 3. Definitions 271 UDP-MIB DEFINITIONS ::= BEGIN 273 IMPORTS 274 MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Counter64, 275 Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMI 276 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 277 InetAddress, InetAddressType, 278 InetPortNumber FROM INET-ADDRESS-MIB; 280 udpMIB MODULE-IDENTITY 281 LAST-UPDATED "200310240000Z" -- October 24, 2003 282 ORGANIZATION "IETF IPv6 Working Group 283 http://www.ietf.org/htmp.charters/ipv6-charter.html" 284 CONTACT-INFO 285 "Bill Fenner (editor) 286 AT&T Labs -- Research 287 75 Willow Rd. 288 Menlo Park, CA 94025 290 Phone: +1 650 330-7893 291 Email: 293 John Flick (editor) 295 Hewlett-Packard Company 296 8000 Foothills Blvd. M/S 5557 297 Roseville, CA 95747 299 Phone: +1 916 785 4018 300 Email: " 302 DESCRIPTION 303 "The MIB module for managing UDP implementations. 305 Copyright (C) The Internet Society (2003). This 306 version of this MIB module is part of RFC XXXX; 307 see the RFC itself for full legal notices. 308 -- RFC Ed.: Replace XXXX with the actual RFC number & remove 309 -- this note" 310 REVISION "200310240000Z" -- October 24, 2003 311 DESCRIPTION 312 "IP version neutral revision, published as RFC XXXX." 313 -- RFC Ed.: Replace XXXX with the actual RFC number & remove 314 -- this note" 315 REVISION "199411010000Z" -- November 1, 1994 316 DESCRIPTION 317 "Initial SMIv2 version, published as RFC 2013." 318 REVISION "199103310000Z" -- March 31, 1991 319 DESCRIPTION 320 "The initial revision of this MIB module was part of MIB-II." 321 ::= { mib-2 50 } 323 -- the UDP group 325 udp OBJECT IDENTIFIER ::= { mib-2 7 } 327 udpInDatagrams OBJECT-TYPE 328 SYNTAX Counter32 329 MAX-ACCESS read-only 330 STATUS current 331 DESCRIPTION 332 "The total number of UDP datagrams delivered to UDP users." 333 ::= { udp 1 } 335 udpNoPorts OBJECT-TYPE 336 SYNTAX Counter32 337 MAX-ACCESS read-only 338 STATUS current 339 DESCRIPTION 340 "The total number of received UDP datagrams for which there 341 was no application at the destination port." 342 ::= { udp 2 } 344 udpInErrors OBJECT-TYPE 345 SYNTAX Counter32 346 MAX-ACCESS read-only 347 STATUS current 348 DESCRIPTION 349 "The number of received UDP datagrams that could not be 350 delivered for reasons other than the lack of an application 351 at the destination port." 352 ::= { udp 3 } 354 udpOutDatagrams OBJECT-TYPE 355 SYNTAX Counter32 356 MAX-ACCESS read-only 357 STATUS current 358 DESCRIPTION 359 "The total number of UDP datagrams sent from this entity." 360 ::= { udp 4 } 362 udpHCInDatagrams OBJECT-TYPE 363 SYNTAX Counter64 364 MAX-ACCESS read-only 365 STATUS current 366 DESCRIPTION 367 "The total number of UDP datagrams delivered to UDP users, 368 for devices which can receive more than 1 million UDP 369 datagrams per second." 370 ::= { udp 8 } 372 udpHCOutDatagrams OBJECT-TYPE 373 SYNTAX Counter64 374 MAX-ACCESS read-only 375 STATUS current 376 DESCRIPTION 377 "The total number of UDP datagrams sent from this entity, for 378 devices which can transmit more than 1 million UDP datagrams 379 per second." 380 ::= { udp 9 } 382 -- 383 -- { udp 6 } was defined as the ipv6UdpTable in RFC2454's IPV6-UDP-MIB. 384 -- This RFC obsoletes RFC 2454, so { udp 6 } is obsoleted. 385 -- 387 -- The UDP "Endpoint" table. 389 udpEndpointTable OBJECT-TYPE 390 SYNTAX SEQUENCE OF UdpEndpointEntry 391 MAX-ACCESS not-accessible 392 STATUS current 393 DESCRIPTION 394 "A table containing information about this entity's UDP 395 endpoints on which a local application is currently 396 accepting or sending datagrams. 398 The address type in this table represents the address type 399 used for the communication, irrespective of the higher-layer 400 abstraction. For example, an application using IPv6 401 'sockets' to communicate via IPv4 between ::ffff:10.0.0.1 402 and ::ffff:10.0.0.2 would use InetAddressType ipv4(1). 404 Unlike the udpTable in RFC 2013, this table also allows the 405 representation of an application which completely specifies 406 both local and remote addresses and ports. A listening 407 application is represented in three possible ways: 409 1) an application which is willing to accept both IPv4 and 410 IPv6 datagrams is represented by a 411 udpEndpointLocalAddressType of unknown(0) and 412 udpEndpointLocalAddress of ''h (a zero-length 413 octet-string). 415 2) an application which is willing to accept only IPv4 or 416 only IPv6 datagrams is represented by a 417 udpEndpointLocalAddressType of the appropriate address 418 type, and udpEndpointLocalAddress of ''h (a zero-length 419 octet-string). 421 3) an application which is listening for datagrams only for 422 a specific IP address, but from any remote system, is 423 repesented by a udpEndpointLocalAddressType of the 424 appropriate address type, udpEndpointLocalAddress 425 specifying the local address. 427 In all cases where the remote is a wildcard, the 428 udpEndpointRemoteAddressType is unknown(0), the 429 udpEndpointRemoteAdderess is ''h (a zero-length 430 octet-string), and the udpEndpointRemotePort is 0. 432 If the operating system is demultiplexing UDP packets by 433 remote address and port, or if the application has 434 'connected' the socket specifying a default remote address 435 and port, the udpEndpointRemote* values should be used to 436 reflect this." 437 ::= { udp 7 } 439 udpEndpointEntry OBJECT-TYPE 440 SYNTAX UdpEndpointEntry 441 MAX-ACCESS not-accessible 442 STATUS current 443 DESCRIPTION 444 "Information about a particular current UDP endpoint. 446 Implementers need to be aware that if the total number 447 of elements (octets or sub-identifiers) in 448 udpEndpointLocalAddress and udpEndpointRemoteAddress 449 exceeds 111 then OIDs of column instances in this table 450 will have more than 128 sub-identifiers and cannot be 451 accessed using SNMPv1, SNMPv2c, or SNMPv3." 452 INDEX { udpEndpointLocalAddressType, 453 udpEndpointLocalAddress, 454 udpEndpointLocalPort, 455 udpEndpointRemoteAddressType, 456 udpEndpointRemoteAddress, 457 udpEndpointRemotePort, 458 udpEndpointInstance } 459 ::= { udpEndpointTable 1 } 461 UdpEndpointEntry ::= SEQUENCE { 462 udpEndpointLocalAddressType InetAddressType, 463 udpEndpointLocalAddress InetAddress, 464 udpEndpointLocalPort InetPortNumber, 465 udpEndpointRemoteAddressType InetAddressType, 466 udpEndpointRemoteAddress InetAddress, 467 udpEndpointRemotePort InetPortNumber, 468 udpEndpointInstance Unsigned32, 469 udpEndpointProcess Unsigned32 470 } 472 udpEndpointLocalAddressType OBJECT-TYPE 473 SYNTAX InetAddressType 474 MAX-ACCESS not-accessible 475 STATUS current 476 DESCRIPTION 477 "The address type of udpEndpointLocalAddress. Only IPv4, 478 IPv4z, IPv6 and IPv6z addresses are expected, or 479 unknown(0) if datagrams for all local IP addresses are 480 accepted." 481 ::= { udpEndpointEntry 1 } 483 udpEndpointLocalAddress OBJECT-TYPE 484 SYNTAX InetAddress 485 MAX-ACCESS not-accessible 486 STATUS current 487 DESCRIPTION 488 "The local IP address for this UDP endpoint. This is either 489 one of the IP addresses assigned to the system, or a null 490 octet-string (''h) to represent that datagrams destined to 491 any address assigned to the system of an IP version 492 consistent with udpEndpointLocalAddressType (or any IP 493 version, if udpEndpointLocalAddressType is unknown(0)) will 494 be accepted." 495 ::= { udpEndpointEntry 2 } 497 udpEndpointLocalPort OBJECT-TYPE 498 SYNTAX InetPortNumber 499 MAX-ACCESS not-accessible 500 STATUS current 501 DESCRIPTION 502 "The local port number for this UDP endpoint." 503 ::= { udpEndpointEntry 3 } 505 udpEndpointRemoteAddressType OBJECT-TYPE 506 SYNTAX InetAddressType 507 MAX-ACCESS not-accessible 508 STATUS current 509 DESCRIPTION 510 "The address type of udpEndpointRemoteAddress. Only IPv4, 511 IPv4z, IPv6 and IPv6 addresses are expected, or 512 unknown(0) if datagrams for all remote IP addresses are 513 accepted." 514 ::= { udpEndpointEntry 4 } 516 udpEndpointRemoteAddress OBJECT-TYPE 517 SYNTAX InetAddress 518 MAX-ACCESS not-accessible 519 STATUS current 520 DESCRIPTION 521 "The remote IP address for this UDP endpoint. If datagrams 522 from any remote system are to be accepted, this value is ''h 523 (a zero-length octet-string). Otherwise, it has the type 524 described by udpEndpointRemoteAddressType, and is the 525 address of the remote system from which datagrams are to be 526 accepted (or to which all datagrams will be sent)." 527 ::= { udpEndpointEntry 5 } 529 udpEndpointRemotePort OBJECT-TYPE 530 SYNTAX InetPortNumber 531 MAX-ACCESS not-accessible 532 STATUS current 533 DESCRIPTION 534 "The remote port number for this UDP endpoint. If datagrams 535 from any remote system are to be accepted, this value is 536 zero." 537 ::= { udpEndpointEntry 6 } 539 udpEndpointInstance OBJECT-TYPE 540 SYNTAX Unsigned32 (1..'ffffffff'h) 541 MAX-ACCESS read-only 542 STATUS current 543 DESCRIPTION 544 "The instance of this tuple. This object is used to 545 distinguish between multiple processes 'connected' to the 546 same UDP endpoint." 547 ::= { udpEndpointEntry 7 } 549 udpEndpointProcess OBJECT-TYPE 550 SYNTAX Unsigned32 551 MAX-ACCESS read-only 552 STATUS current 553 DESCRIPTION 554 "The system's process ID for the process associated with this 555 endpoint, or zero if there is no such process. This value 556 is expected to be the same as 557 HOST-RESOURCES-MIB::hrSWRunIndex or 558 SYSAPPL-MIB::sysApplElmtRunIndex for some row in the 559 appropriate tables." 560 ::= { udpEndpointEntry 8 } 562 -- The deprecated UDP Listener table 564 -- The deprecated UDP listener table only contains information about this 565 -- entity's IPv4 UDP end-points on which a local application is 566 -- currently accepting datagrams. It does not provide more detailed 567 -- connection information, or information about IPv6 endpoints. 569 udpTable OBJECT-TYPE 570 SYNTAX SEQUENCE OF UdpEntry 571 MAX-ACCESS not-accessible 572 STATUS deprecated 573 DESCRIPTION 574 "A table containing IPv4-specific UDP listener information. 575 It contains information about all local IPv4 UDP end-points 576 on which an application is currently accepting datagrams. 578 This table has been deprecated in favor of the version 579 neutral udpEndpointTable." 580 ::= { udp 5 } 582 udpEntry OBJECT-TYPE 583 SYNTAX UdpEntry 584 MAX-ACCESS not-accessible 585 STATUS deprecated 586 DESCRIPTION 587 "Information about a particular current UDP listener." 588 INDEX { udpLocalAddress, udpLocalPort } 589 ::= { udpTable 1 } 591 UdpEntry ::= SEQUENCE { 592 udpLocalAddress IpAddress, 593 udpLocalPort Integer32 594 } 596 udpLocalAddress OBJECT-TYPE 597 SYNTAX IpAddress 598 MAX-ACCESS read-only 599 STATUS deprecated 600 DESCRIPTION 601 "The local IP address for this UDP listener. In the case of 602 a UDP listener which is willing to accept datagrams for any 603 IP interface associated with the node, the value 0.0.0.0 is 604 used." 605 ::= { udpEntry 1 } 607 udpLocalPort OBJECT-TYPE 608 SYNTAX Integer32 (0..65535) 609 MAX-ACCESS read-only 610 STATUS deprecated 611 DESCRIPTION 612 "The local port number for this UDP listener." 613 ::= { udpEntry 2 } 615 -- conformance information 617 udpMIBConformance OBJECT IDENTIFIER ::= { udpMIB 2 } 619 udpMIBCompliances OBJECT IDENTIFIER ::= { udpMIBConformance 1 } 620 udpMIBGroups OBJECT IDENTIFIER ::= { udpMIBConformance 2 } 622 -- compliance statements 624 udpMIBCompliance2 MODULE-COMPLIANCE 625 STATUS current 626 DESCRIPTION 627 "The compliance statement for systems which implement UDP." 628 MODULE -- this module 629 MANDATORY-GROUPS { udpBaseGroup, udpEndpointGroup } 630 GROUP udpHCGroup 631 DESCRIPTION 632 "This group is mandatory for those systems which are 633 capable of receiving or transmitting more than 1 634 million UDP datagrams per second. 1 million datagrams 635 per second will cause a Counter32 to wrap in just over 636 an hour." 637 GROUP udpEndpointProcessGroup 638 DESCRIPTION 639 "This group is mandatory for systems which implement a 640 'process ID' concept, in particular those that also 641 implement the HOST-RESOURCES-MIB or SYSAPPL-MIB." 642 ::= { udpMIBCompliances 2 } 644 udpMIBCompliance MODULE-COMPLIANCE 645 STATUS deprecated 646 DESCRIPTION 647 "The compliance statement for IPv4-only systems which 648 implement UDP. For IP version independence, this compliance 649 statement is deprecated in favor of udpMIBCompliance2. 650 However, agents are still encouraged to implement these 651 objects in order to interoperate with the deployed base 652 of managers." 653 MODULE -- this module 654 MANDATORY-GROUPS { udpGroup } 655 ::= { udpMIBCompliances 1 } 657 -- units of conformance 659 udpGroup OBJECT-GROUP 660 OBJECTS { udpInDatagrams, udpNoPorts, 661 udpInErrors, udpOutDatagrams, 662 udpLocalAddress, udpLocalPort } 663 STATUS deprecated 664 DESCRIPTION 665 "The deprecated group of objects providing for management of 666 UDP over IPv4." 667 ::= { udpMIBGroups 1 } 669 udpBaseGroup OBJECT-GROUP 670 OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors, udpOutDatagrams } 671 STATUS current 672 DESCRIPTION 673 "The group of objects providing for counters of UDP 674 statistics." 675 ::= { udpMIBGroups 2 } 677 udpHCGroup OBJECT-GROUP 678 OBJECTS { udpHCInDatagrams, udpHCOutDatagrams } 679 STATUS current 680 DESCRIPTION 681 "The group of objects providing for counters of high speed 682 UDP implementations." 683 ::= { udpMIBGroups 3 } 685 udpEndpointGroup OBJECT-GROUP 686 OBJECTS { udpEndpointInstance } 687 STATUS current 688 DESCRIPTION 689 "The group of objects providing for the IP version 690 independent management of UDP 'endpoints'." 691 ::= { udpMIBGroups 4 } 693 udpEndpointProcessGroup OBJECT-GROUP 694 OBJECTS { udpEndpointProcess } 695 STATUS current 696 DESCRIPTION 697 "The object mapping a UDP 'endpoint' to a system process." 698 ::= { udpMIBGroups 5 } 700 END 702 4. Intellectual Property 704 The IETF takes no position regarding the validity or scope of any 705 intellectual property or other rights that might be claimed to 706 pertain to the implementation or use of the technology described in 707 this document or the extent to which any license under such rights 708 might or might not be available; neither does it represent that it 709 has made any effort to identify any such rights. Information on the 710 IETF's procedures with respect to rights in standards-track and 711 standards-related documentation can be found in BCP-11. Copies of 712 claims of rights made available for publication and any assurances of 713 licenses to be made available, or the result of an attempt made to 714 obtain a general license or permission for the use of such 715 proprietary rights by implementors or users of this specification can 716 be obtained from the IETF Secretariat. 718 The IETF invites any interested party to bring to its attention any 719 copyrights, patents or patent applications, or other proprietary 720 rights which may cover technology that may be required to practice 721 this standard. Please address the information to the IETF Executive 722 Director. 724 5. Acknowledgements 726 This document contains a modified subset of RFC 1213 and updates RFC 727 2013 and RFC 2454. Acknowledments are therefore due to the authors 728 and editors of these documents for their excellent work. 730 6. Contributers 732 This document is an output of the IPv6 MIB revision team, and 733 contributors to earlier versions of this document include: 735 Bill Fenner, AT&T Labs -- Research 736 Email: fenner@research.at.com 738 Brian Haberman 739 Email: brian@innovationslab.net 741 Shawn A. Routhier, Wind River 742 Email: sar@epilogue.com 744 Juergen Schoenwalder, TU Braunschweig 745 Email: schoenw@ibr.cs.tu-bs.de 747 Dave Thaler, Microsoft 748 Email: dthaler@windows.microsoft.com 750 Much of Keith McCloghrie's text from RFC1213/RFC2013 remains in this 751 document, and the structure of the MIB is due to him. 753 Mike Daniele wrote the original IPv6 UDP MIB in RFC2454. 755 Juergen Schoenwalder provided much of the text for section 2. 757 7. Normative References 759 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 760 August 1980. 762 [RFC2287] Krupczak, C., and J. Saperia, "Definitions of 763 System-Level Managed Objects for Applications", RFC 2287, 764 February 1998. 766 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 767 Rose, M. and S. Waldbusser, "Structure of Management 768 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 769 1999. 771 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 772 Rose, M. and S. Waldbusser, "Textual Conventions for 773 SMIv2", STD 58, RFC 2579, April 1999. 775 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, 776 J., Rose, M. and S. Waldbusser, "Conformance Statements 777 for SMIv2", STD 58, RFC 2580, April 1999. 779 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 780 2790, March 2000. 782 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. 783 Schoenwaelder, "Textual Conventions for Internet Network 784 Addresses", RFC 3291, May 2002. 786 8. Informative References 788 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 789 "Introduction and Applicability Statements for Internet- 790 Standard Management Framework", RFC 3410, December 2002. 792 [RFC1213] McCloghrie, K. and M. Rose, Editors, "Management 793 Information Base for Network Management of TCP/IP-based 794 internets: MIB-II", STD 17, RFC 1213, March 1991. 796 [RFC2013] McCloghrie, K., "Management Information Base for the 797 User Datagram Protocol using SMIv2", RFC 2013, November 798 1996. 800 [RFC2454] Daniele, M., "IP Version 6 Management Information Base 801 for the User Datagram Protocol", RFC 2454, December 802 1998. 804 9. Security Considerations 806 There are no management objects defined in this MIB that have a MAX- 807 ACCESS clause of read-write and/or read-create. So, if this MIB is 808 implemented correctly, then there is no risk that an intruder can 809 alter or create any management objects of this MIB module via direct 810 SNMP SET operations. 812 Some of the readable objects in this MIB module (i.e., objects with a 813 MAX-ACCESS other than not-accessible) may be considered sensitive or 814 vulnerable in some network environments. It is thus important to 815 control even GET and/or NOTIFY access to these objects and possibly 816 to even encrypt the values of these objects when sending them over 817 the network via SNMP. These are the tables and objects and their 818 sensitivity/vulnerability: 820 The udpEndpointLocalPort and udpLocalPort objects can be used to 821 identify what ports are open on the machine and can thus what attacks 822 are likely to succeed, without the attacker having to run a port 823 scanner. 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 the implementors consider the security 832 features as provided by the SNMPv3 framework (see [RFC3410], section 833 8), including full support for the SNMPv3 cryptographic mechanisms 834 (for authentication and privacy). 836 Furthermore, 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 10. Editors Addresses 846 Bill Fenner 847 AT&T Labs -- Research 848 75 Willow Rd 849 Menlo Park, CA 94025 850 USA 852 Email: fenner@research.att.com 854 John Flick 855 Hewlett-Packard Company 856 8000 Foothills Blvd. M/S 5557 857 Roseville, CA 95747-5557 858 USA 860 Email: johnf@rose.hp.com 862 11. Full Copyright Statement 864 Copyright (C) The Internet Society (2003). All Rights Reserved. 866 This document and translations of it may be copied and furnished to 867 others, and derivative works that comment on or otherwise explain it 868 or assist in its implementation may be prepared, copied, published 869 and distributed, in whole or in part, without restriction of any 870 kind, provided that the above copyright notice and this paragraph are 871 included on all such copies and derivative works. However, this 872 document itself may not be modified in any way, such as by removing 873 the copyright notice or references to the Internet Society or other 874 Internet organizations, except as needed for the purpose of 875 developing Internet standards in which case the procedures for 876 copyrights defined in the Internet Standards process must be 877 followed, or as required to translate it into languages other than 878 English. 880 The limited permissions granted above are perpetual and will not be 881 revoked by the Internet Society or its successors or assigns. 883 This document and the information contained herein is provided on an 884 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 885 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 886 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 887 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 888 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.