idnits 2.17.1 draft-ietf-ipv6-rfc2013-update-04.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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1106. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1090. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1096. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 981: '... 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 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 18, 2004) is 7128 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) -- 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 (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 MIB Revision Design Team B. Fenner 2 Internet-Draft AT&T Labs -- Research 3 Expires: April 18, 2005 J. Flick 4 Hewlett-Packard Company 5 October 18, 2004 7 Management Information Base for the User Datagram Protocol (UDP) 8 draft-ietf-ipv6-rfc2013-update-04 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 18, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). 41 Abstract 43 This memo defines a portion of the Management Information Base (MIB) 44 for use with network management protocols in the Internet community. 45 In particular, it describes managed objects used for implementations 46 of the User Datagram Protocol (UDP) in an IP version independent 47 manner. This memo obsoletes RFCs 2013 and 2454. 49 Table of Contents 51 1. Revision History . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The Internet-Standard Management Framework . . . . . . . . . . 7 53 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 3.1 Relationship to Other MIBs . . . . . . . . . . . . . . . . 8 55 3.1.1 Relationship to RFC1213-MIB . . . . . . . . . . . . . 8 56 3.1.2 Relationship to the IPV6-UDP-MIB . . . . . . . . . . . 8 57 3.1.3 Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB . . 8 58 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 60 6. Contributers . . . . . . . . . . . . . . . . . . . . . . . . . 20 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 64 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 65 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 67 Intellectual Property and Copyright Statements . . . . . . . . 25 69 1. Revision History 71 [Note to RFC Editor: Please remove prior to publication] 73 Changes from draft-ietf-ipv6-rfc2013-update-02.txt 75 18 October 2004 - IETF Last Call comments 77 Updated reference to RFC3291 to refer to 3291bis internet-draft. 79 Updated DESCRIPTION clause of the most recent REVISION clause to 80 reflect the changes that have been made since RFC 2013. 82 Updated DESCRIPTION clause of least recent REVISION clause to 83 reflect that MIB-II was published as RFC 1213. 85 Added pseudo OBJECT clauses to the description of 86 udpMIBCompliance2 for udpEndpointLocalAddress and 87 udpEndpointRemoteAddress. 89 Updated Overview section so that all references are cited. 91 Moved references to RFC 2287 and RFC 2790 from Normative 92 References to Informative References, since they are not actually 93 required for implementation, and we don't want advancement of this 94 document to be blocked. 96 Removed use of zero-length addresses to represent wildcard 97 listeners when the version is specified. Instead, use zero valued 98 addresses of the appropriate length. Updated udpEndpointTable and 99 udpEndpointLocalAddress DESCRIPTION clauses to reflect this. 101 Added IANA Considerations section. 103 Updated IPR boilerplate. 105 Changes from draft-ietf-ipv6-rfc2013-update-02.txt 107 27 April 2004 109 Added text to section 2.1.2 to clarify why an equivalent to RFC 110 2454's ipv6UdpIfIndex is not required. 112 Changed the text of the Security Considerations so that it no 113 longer implies that udpEndpointLocalPort is readable, but is 114 instead only returned as part of an index. 116 Added an explicit reference to sysUpTime as a discontinuity 117 indicator to the counter objects in the mib. 119 Reworded the description of udpEndpointLocalAddress to indicate 120 that it can be used to represent any address that the local system 121 is listening to, not just addresses assigned to the system. 123 Updated the description of InetAddress objects used as index 124 elements to indicate the 128 octet limit. 126 Added a note to the description of udpEndpointRemoteAddressType to 127 indicate that some combinations of udpEndpointLocalAddressType and 128 udpEndpointRemoteAddressType are not legal. 130 Reverted udpEndpointInstance to not-accessible, since 131 udpEndpointProcess is now a mandatory to implement object (to 132 align with the TCP-MIB). 134 Added text to the udpEndpointInstance description to describe why 135 it is needed. 137 Added pseudo OBJECT clauses to the description of 138 udpMIBCompliance2 for udpEndpointLocalAddressType and 139 udpEndpointRemoteAddressType. 141 Removed udpEndpointInstance from the udpEndpointGroup, since it is 142 now not-accessible, and added udpEndpointProcess to the 143 udpEndpointGroup, since it is now mandatory. Removed the 144 udpEndpointProcessGroup. 146 Changes from draft-ietf-ipv6-rfc2013-update-00.txt 148 24 October 2003 150 Dropped udpEndpointInDatagrams, udpEndpointHCInDatagrams, 151 udpEndpointOutDatagrams, udpEndpointHCOutDatagrams, 152 udpEndpointInOctets, udpEndpointHCInOctets, udpEndpointOutOctets, 153 udpEndpointHCOutOctets, and udpEndpointStartTime. 155 Removed udpEndpointStatsGroup, udpEndpointHCDatagramStatsGroup and 156 udpEndpointHCOctetStatsGroup. 158 Changed udpEndpointInstance back to read-only, since there is no 159 longer a mandatory non-auxiliary column in the udpEndpointTable. 161 Removed Open Issues section. 163 Moved Revision History section to beginning of document and 164 removed its section number, to allow for easier removal at RFC 165 publication. 167 Updated to latest MIB boilerplate. 169 Updated working group mailing list address. 171 Removed SIZE constraints from udpEndpointLocalAddress and 172 udpEndpointRemoteAddress, and updated the DESCRIPTION clause of 173 udpEndpointEntry. 175 Removed "Use of IP Addresses" section, since this information is 176 already documented in the relevant MIB DESCRIPTIONs. 178 Changes from draft-ietf-ipngwg-rfc2013-update-01.txt 180 28 May 2002 182 Removed udpConnectionTable. 184 Renamed ListenerTable to EndpointTable, since with a remote 185 address Listener is not quite correct. 187 Use ''h consistently for 'any IP address', instead of sometimes 188 ''h and sometimes all-zeroes of the right address family. 190 Use "Datagram" instead of "Packet" to talk about UDP datagrams. 192 Added mandatory udpEndpointStartTime, this also fixes the 193 udpEndpointInstance needing to be read-only and mandatory. 195 Make udpEndpointProcess mandatory on systems that have process 196 IDs. 198 Make a note of { udp 6 } in a comment for clarity on why it's 199 skipped. 201 Fleshed out section 3. 203 Changed the deprecated udpLocalPort SYNTAX to Integer32. Since it 204 was already restricted to (0..65536) this is not a semantic 205 change. 207 Changes from draft-ietf-ipngwg-rfc2013-update-00.txt 209 14 November 2001 211 Added udpConnectionTable. 213 Added udpListenerRemoteAddressType, to distinguish e.g. 214 IPV6_V6ONLY. 216 Added counters to udpListenerTable and udpConnectionTable. 218 Changes from draft-ops-rfc2013-update-00.txt 220 12 Jul 2001 222 Turned into IPNG WG document 224 Changes from first draft posted to v6mib mailing list: 226 23 Feb 2001 228 Made threshold for HC packet counters 1Mpps 230 Added copyright statements and table of contents 232 21 Feb 2001 -- Juergen's changes 234 Renamed udpInetTable to udpListenerTable 236 Updated Conformance info 238 6 Feb 2001 240 Removed v6-only objects. 242 Removed remote and instance objects, turning the table back into a 243 listener-only table. 245 Renamed inetUdp* to udpInet* 247 Added HC in and out datagram counters 249 Added SIZE restriction to udpListenerLocalAddress. (36 = 32-byte 250 addresses plus 4-byte scope, but it's just a strawman) 252 Used InetPortNumber TC from updated INET-ADDRESS-MIB 254 Updated compliance statements. 256 Added Keith to authors 258 Added open issues section. 260 2. The Internet-Standard Management Framework 262 For a detailed overview of the documents that describe the current 263 Internet-Standard Management Framework, please refer to section 7 of 264 RFC 3410 [RFC3410]. 266 Managed objects are accessed via a virtual information store, termed 267 the Management Information Base or MIB. MIB objects are generally 268 accessed through the Simple Network Management Protocol (SNMP). 269 Objects in the MIB are defined using the mechanisms defined in the 270 Structure of Management Information (SMI). This memo specifies a MIB 271 module that is compliant to the SMIv2, which is described in STD 58, 272 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 273 [RFC2580]. 275 3. Overview 277 This memo defines a portion of the Management Information Base (MIB) 278 for use with network management protocols in the Internet community. 279 In particular, it describes managed objects used for implementations 280 of the User Datagram Protocol (UDP), as defined in RFC 768 [RFC0768], 281 in an IP version independent manner. 283 The current UDP-MIB defined in this memo consists of one table and a 284 group of scalars: 286 o The udp group of scalars reports parameters and statistics of a 287 UDP protocol engine. Two scalars udpHCInDatagrams and 288 udpHCOutDatagrams have been added to this group since the 289 publication of RFC 2013 [RFC2013] in order to provide 290 high-capacity counters for fast networks. Discontinuities in the 291 values of the counters in this group are indicated by 292 discontinuities in the value of the sysUpTime object, which is 293 defined in RFC 3418 [RFC3418]. 295 o The udpEndpointTable provides access to status information for all 296 UDP endpoints handled by a UDP protocol engine. The table 297 provides for strictly listening endpoints, as with the historical 298 udpTable, and also for "connected" UDP endpoints, which only 299 accept packets from a given remote system. It also reports 300 identification of the operating system level processes which 301 handle UDP connections. Addresses and ports of UDP endpoints in 302 this table are represented using the InetAddressType, InetAddress, 303 and InetPortNumber textual conventions defined in RFC 3291bis 304 [I-D.ietf-ops-rfc3291bis]. 306 3.1 Relationship to Other MIBs 308 This section discusses the relationship of this UDP-MIB module to 309 other MIB modules. 311 3.1.1 Relationship to RFC1213-MIB 313 UDP related MIB objects were originally defined as part of the 314 RFC1213-MIB defined in RFC 1213 [RFC1213]. The UDP related objects 315 of the RFC1213-MIB were later copied into a separate MIB module and 316 published in RFC 2013 [RFC2013] in SMIv2 format. 318 The previous versions of the UDP-MIB both defined the udpTable, which 319 has been deprecated for basically two reasons: 321 (1) The udpTable only supports IPv4. 323 The current approach in the IETF is to write IP version neutral 324 MIBs rather than having different definitions for various version 325 of IP. This reduces the amount of overhead when new objects are 326 introduced since there is only one place to add them. Hence, the 327 approach taken in RFC 2454 [RFC2454] of having separate tables is 328 not continued. 330 (2) The udpTable does not permit describing "connected" UDP 331 endpoints. 333 It turns out that "connected" endpoints tend to have a different 334 behaviour and management access pattern compared to listening 335 endpoints. Adding remote endpoint information to the 336 udpEndpointTable thus allows for the addition of specific status 337 and statistic objects for "connected" endpoints and connections. 339 3.1.2 Relationship to the IPV6-UDP-MIB 341 The IPV6-UDP-MIB defined in RFC 2454 [RFC2454] has been moved to 342 Historic since the approach of having separate IP version specific 343 tables is not followed anymore. Implementation of RFC 2454 is thus 344 not suggested anymore. 346 Note that since scoped addresses are now represented using the ipv4z 347 and ipv6z address types, there is no longer a need to explicitly 348 include the ifIndex in the index clause of the udpEndpointTable. 349 This is a change from the use of ipv6UdpIfIndex in RFC 2454. 351 3.1.3 Relationship to HOST-RESOURCES-MIB and SYSAPPL-MIB 353 The udpEndpointTable reports the identification of the operating 354 system level process which handles a connection or a listening 355 endpoint. The value is reported as an Unsigned32 which is expected 356 to be the same as the hrSWRunIndex of the HOST-RESOURCES-MIB 357 [RFC2790] (if the value is smaller than 2147483647) or the 358 sysApplElmtRunIndex of the SYSAPPL-MIB [RFC2287]. This allows 359 managment applications to identify the UDP connections that belong to 360 an operating system level process, which has proven to be valuable in 361 operational environments. 363 4. Definitions 365 UDP-MIB DEFINITIONS ::= BEGIN 367 IMPORTS 368 MODULE-IDENTITY, OBJECT-TYPE, Integer32, Counter32, Counter64, 369 Unsigned32, IpAddress, mib-2 FROM SNMPv2-SMI 370 MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF 371 InetAddress, InetAddressType, 372 InetPortNumber FROM INET-ADDRESS-MIB; 374 udpMIB MODULE-IDENTITY 375 LAST-UPDATED "200410180000Z" -- October 18, 2004 376 ORGANIZATION 377 "IETF IPv6 Working Group 378 http://www.ietf.org/html.charters/ipv6-charter.html" 379 CONTACT-INFO 380 "Bill Fenner (editor) 382 AT&T Labs -- Research 383 75 Willow Rd. 384 Menlo Park, CA 94025 386 Phone: +1 650 330-7893 387 Email: 389 John Flick (editor) 391 Hewlett-Packard Company 392 8000 Foothills Blvd. M/S 5557 393 Roseville, CA 95747 395 Phone: +1 916 785 4018 396 Email: 398 Send comments to " 399 DESCRIPTION 400 "The MIB module for managing UDP implementations. 402 Copyright (C) The Internet Society (2004). This 403 version of this MIB module is part of RFC XXXX; 404 see the RFC itself for full legal notices." 405 -- RFC Ed.: Replace XXXX with actual RFC number & remove note 406 REVISION "200410180000Z" -- October 18, 2004 407 DESCRIPTION 408 "IP version neutral revision, incorporating the 409 following revisions: 411 - Added udpHCInDatagrams and udpHCOutDatagrams in order 412 to provide high-capacity counters for fast networks. 413 - Added text to the descriptions of all counter objects 414 to indicate how discontinuities are detected. 415 - Deprecated the IPv4-specific udpTable and replaced it 416 with the version neutral udpEndpointTable. This 417 table includes support for connected UDP endpoints 418 and support for identification of the operating 419 system process associated with a UDP endpoint. 420 - Deprecated the udpGroup, and replaced it with object 421 groups representing the current set of objects. 422 - Deprecated udpMIBCompliance, and replaced it with 423 udpMIBCompliance2, which includes the compliance 424 information for the new object groups. 426 This version published as RFC XXXX." 427 -- RFC Ed.: Replace XXXX with actual RFC number & remove note 428 REVISION "199411010000Z" -- November 1, 1994 429 DESCRIPTION 430 "Initial SMIv2 version, published as RFC 2013." 431 REVISION "199103310000Z" -- March 31, 1991 432 DESCRIPTION 433 "The initial revision of this MIB module was part of 434 MIB-II, published as RFC 1213." 435 ::= { mib-2 50 } 437 -- the UDP group 439 udp OBJECT IDENTIFIER ::= { mib-2 7 } 441 udpInDatagrams OBJECT-TYPE 442 SYNTAX Counter32 443 MAX-ACCESS read-only 444 STATUS current 445 DESCRIPTION 446 "The total number of UDP datagrams delivered to UDP 447 users. 449 Discontinuities in the value of this counter can occur 450 at re-initialization of the management system, and at 451 other times as indicated by discontinuities in the 452 value of sysUpTime." 453 ::= { udp 1 } 455 udpNoPorts OBJECT-TYPE 456 SYNTAX Counter32 457 MAX-ACCESS read-only 458 STATUS current 459 DESCRIPTION 460 "The total number of received UDP datagrams for which 461 there was no application at the destination port. 463 Discontinuities in the value of this counter can occur 464 at re-initialization of the management system, and at 465 other times as indicated by discontinuities in the 466 value of sysUpTime." 467 ::= { udp 2 } 469 udpInErrors OBJECT-TYPE 470 SYNTAX Counter32 471 MAX-ACCESS read-only 472 STATUS current 473 DESCRIPTION 474 "The number of received UDP datagrams that could not be 475 delivered for reasons other than the lack of an 476 application at the destination port. 478 Discontinuities in the value of this counter can occur 479 at re-initialization of the management system, and at 480 other times as indicated by discontinuities in the 481 value of sysUpTime." 482 ::= { udp 3 } 484 udpOutDatagrams OBJECT-TYPE 485 SYNTAX Counter32 486 MAX-ACCESS read-only 487 STATUS current 488 DESCRIPTION 489 "The total number of UDP datagrams sent from this 490 entity. 492 Discontinuities in the value of this counter can occur 493 at re-initialization of the management system, and at 494 other times as indicated by discontinuities in the 495 value of sysUpTime." 496 ::= { udp 4 } 498 udpHCInDatagrams OBJECT-TYPE 499 SYNTAX Counter64 500 MAX-ACCESS read-only 501 STATUS current 502 DESCRIPTION 503 "The total number of UDP datagrams delivered to UDP 504 users, for devices which can receive more than 1 505 million UDP datagrams per second. 507 Discontinuities in the value of this counter can occur 508 at re-initialization of the management system, and at 509 other times as indicated by discontinuities in the 510 value of sysUpTime." 511 ::= { udp 8 } 513 udpHCOutDatagrams OBJECT-TYPE 514 SYNTAX Counter64 515 MAX-ACCESS read-only 516 STATUS current 517 DESCRIPTION 518 "The total number of UDP datagrams sent from this 519 entity, for devices which can transmit more than 1 520 million UDP datagrams per second. 522 Discontinuities in the value of this counter can occur 523 at re-initialization of the management system, and at 524 other times as indicated by discontinuities in the 525 value of sysUpTime." 526 ::= { udp 9 } 528 -- 529 -- { udp 6 } was defined as the ipv6UdpTable in RFC2454's 530 -- IPV6-UDP-MIB. This RFC obsoletes RFC 2454, so { udp 6 } is 531 -- obsoleted. 532 -- 534 -- The UDP "Endpoint" table. 536 udpEndpointTable OBJECT-TYPE 537 SYNTAX SEQUENCE OF UdpEndpointEntry 538 MAX-ACCESS not-accessible 539 STATUS current 540 DESCRIPTION 541 "A table containing information about this entity's UDP 542 endpoints on which a local application is currently 543 accepting or sending datagrams. 545 The address type in this table represents the address 546 type used for the communication, irrespective of the 547 higher-layer abstraction. For example, an application 548 using IPv6 'sockets' to communicate via IPv4 between 549 ::ffff:10.0.0.1 and ::ffff:10.0.0.2 would use 550 InetAddressType ipv4(1). 552 Unlike the udpTable in RFC 2013, this table also allows 553 the representation of an application which completely 554 specifies both local and remote addresses and ports. A 555 listening application is represented in three possible 556 ways: 558 1) an application which is willing to accept both IPv4 559 and IPv6 datagrams is represented by a 560 udpEndpointLocalAddressType of unknown(0) and 561 udpEndpointLocalAddress of ''h (a zero-length 562 octet-string). 564 2) an application which is willing to accept only IPv4 565 or only IPv6 datagrams is represented by a 566 udpEndpointLocalAddressType of the appropriate 567 address type, and udpEndpointLocalAddress of 568 '0.0.0.0' or '::' respectively. 570 3) an application which is listening for datagrams only 571 for a specific IP address, but from any remote 572 system, is repesented by a 573 udpEndpointLocalAddressType of the appropriate 574 address type, udpEndpointLocalAddress specifying the 575 local address. 577 In all cases where the remote is a wildcard, the 578 udpEndpointRemoteAddressType is unknown(0), the 579 udpEndpointRemoteAddress is ''h (a zero-length 580 octet-string), and the udpEndpointRemotePort is 0. 582 If the operating system is demultiplexing UDP packets 583 by remote address and port, or if the application has 584 'connected' the socket specifying a default remote 585 address and port, the udpEndpointRemote* values should 586 be used to reflect this." 587 ::= { udp 7 } 589 udpEndpointEntry OBJECT-TYPE 590 SYNTAX UdpEndpointEntry 591 MAX-ACCESS not-accessible 592 STATUS current 593 DESCRIPTION 594 "Information about a particular current UDP endpoint. 596 Implementers need to be aware that if the total number 597 of elements (octets or sub-identifiers) in 598 udpEndpointLocalAddress and udpEndpointRemoteAddress 599 exceeds 111 then OIDs of column instances in this table 600 will have more than 128 sub-identifiers and cannot be 601 accessed using SNMPv1, SNMPv2c, or SNMPv3." 602 INDEX { udpEndpointLocalAddressType, 603 udpEndpointLocalAddress, 604 udpEndpointLocalPort, 605 udpEndpointRemoteAddressType, 606 udpEndpointRemoteAddress, 607 udpEndpointRemotePort, 608 udpEndpointInstance } 609 ::= { udpEndpointTable 1 } 611 UdpEndpointEntry ::= SEQUENCE { 612 udpEndpointLocalAddressType InetAddressType, 613 udpEndpointLocalAddress InetAddress, 614 udpEndpointLocalPort InetPortNumber, 615 udpEndpointRemoteAddressType InetAddressType, 616 udpEndpointRemoteAddress InetAddress, 617 udpEndpointRemotePort InetPortNumber, 618 udpEndpointInstance Unsigned32, 619 udpEndpointProcess Unsigned32 620 } 622 udpEndpointLocalAddressType OBJECT-TYPE 623 SYNTAX InetAddressType 624 MAX-ACCESS not-accessible 625 STATUS current 626 DESCRIPTION 627 "The address type of udpEndpointLocalAddress. Only 628 IPv4, IPv4z, IPv6 and IPv6z addresses are expected, or 629 unknown(0) if datagrams for all local IP addresses are 630 accepted." 631 ::= { udpEndpointEntry 1 } 633 udpEndpointLocalAddress OBJECT-TYPE 634 SYNTAX InetAddress 635 MAX-ACCESS not-accessible 636 STATUS current 637 DESCRIPTION 638 "The local IP address for this UDP endpoint. 640 The value of this object can be represented in three 641 possible ways, depending on the characteristics of the 642 listening application: 644 1. For an application that is willing to accept both 645 IPv4 and IPv6 datagrams, the value of this object 646 must be ''h (a zero-length octet-string), with 647 the value of the corresponding instance of the 648 udpEndpointLocalAddressType object being unknown(0). 650 2. For an application which is willing to accept only 651 IPv4 or IPv6 datagrams, the value of this object 652 must be '0.0.0.0' or '::' respectively, while the 653 corresponding instatnce of the 654 udpEndpointLocalAddressType object represents the 655 appropriate address type. 657 3. For an application which is listening for data 658 destined only to a specific IP address, the value 659 of this object is the specific IP address for which 660 this node is receiving packets, with the 661 corresponding instance of the 662 udpEndpointLocalAddressType object representing the 663 appropriate address type. 665 As this object is used in the index for the 666 udpEndpointTable, implementors of this table should be 667 careful not to create entries that would result in OIDs 668 with more than 128 subidentifiers; else the information 669 cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." 670 ::= { udpEndpointEntry 2 } 672 udpEndpointLocalPort OBJECT-TYPE 673 SYNTAX InetPortNumber 674 MAX-ACCESS not-accessible 675 STATUS current 676 DESCRIPTION 677 "The local port number for this UDP endpoint." 678 ::= { udpEndpointEntry 3 } 680 udpEndpointRemoteAddressType OBJECT-TYPE 681 SYNTAX InetAddressType 682 MAX-ACCESS not-accessible 683 STATUS current 684 DESCRIPTION 685 "The address type of udpEndpointRemoteAddress. Only 686 IPv4, IPv4z, IPv6 and IPv6z addresses are expected, or 687 unknown(0) if datagrams for all remote IP addresses are 688 accepted. Also, note that some combinations of 689 udpEndpointLocalAdressType and 690 udpEndpointRemoteAddressType are not supported. In 691 particular, if the value of this object is not 692 unknown(0), it is expected to always refer to the 693 same IP version as udpEndpointLocalAddressType." 694 ::= { udpEndpointEntry 4 } 696 udpEndpointRemoteAddress OBJECT-TYPE 697 SYNTAX InetAddress 698 MAX-ACCESS not-accessible 699 STATUS current 700 DESCRIPTION 701 "The remote IP address for this UDP endpoint. If 702 datagrams from any remote system are to be accepted, 703 this value is ''h (a zero-length octet-string). 704 Otherwise, it has the type described by 705 udpEndpointRemoteAddressType, and is the address of the 706 remote system from which datagrams are to be accepted 707 (or to which all datagrams will be sent). 709 As this object is used in the index for the 710 udpEndpointTable, implementors of this table should be 711 careful not to create entries that would result in OIDs 712 with more than 128 subidentifiers; else the information 713 cannot be accessed using SNMPv1, SNMPv2c or SNMPv3." 714 ::= { udpEndpointEntry 5 } 716 udpEndpointRemotePort OBJECT-TYPE 717 SYNTAX InetPortNumber 718 MAX-ACCESS not-accessible 719 STATUS current 720 DESCRIPTION 721 "The remote port number for this UDP endpoint. If 722 datagrams from any remote system are to be accepted, 723 this value is zero." 724 ::= { udpEndpointEntry 6 } 726 udpEndpointInstance OBJECT-TYPE 727 SYNTAX Unsigned32 (1..'ffffffff'h) 728 MAX-ACCESS not-accessible 729 STATUS current 730 DESCRIPTION 731 "The instance of this tuple. This object is used to 732 distinguish between multiple processes 'connected' to 733 the same UDP endpoint. For example, on a system 734 implementing the BSD sockets interface, this would be 735 used to support the SO_REUSEADDR and SO_REUSEPORT 736 socket options." 737 ::= { udpEndpointEntry 7 } 739 udpEndpointProcess OBJECT-TYPE 740 SYNTAX Unsigned32 741 MAX-ACCESS read-only 742 STATUS current 743 DESCRIPTION 744 "The system's process ID for the process associated with 745 this endpoint, or zero if there is no such process. 746 This value is expected to be the same as 747 HOST-RESOURCES-MIB::hrSWRunIndex or SYSAPPL-MIB:: 748 sysApplElmtRunIndex for some row in the appropriate 749 tables." 750 ::= { udpEndpointEntry 8 } 752 -- The deprecated UDP Listener table 754 -- The deprecated UDP listener table only contains information 755 -- about this entity's IPv4 UDP end-points on which a local 756 -- application is currently accepting datagrams. It does not 757 -- provide more detailed connection information, or information 758 -- about IPv6 endpoints. 760 udpTable OBJECT-TYPE 761 SYNTAX SEQUENCE OF UdpEntry 762 MAX-ACCESS not-accessible 763 STATUS deprecated 764 DESCRIPTION 765 "A table containing IPv4-specific UDP listener 766 information. It contains information about all local 767 IPv4 UDP end-points on which an application is 768 currently accepting datagrams. This table has been 769 deprecated in favor of the version neutral 770 udpEndpointTable." 771 ::= { udp 5 } 773 udpEntry OBJECT-TYPE 774 SYNTAX UdpEntry 775 MAX-ACCESS not-accessible 776 STATUS deprecated 777 DESCRIPTION 778 "Information about a particular current UDP listener." 779 INDEX { udpLocalAddress, udpLocalPort } 780 ::= { udpTable 1 } 782 UdpEntry ::= SEQUENCE { 783 udpLocalAddress IpAddress, 784 udpLocalPort Integer32 785 } 786 udpLocalAddress OBJECT-TYPE 787 SYNTAX IpAddress 788 MAX-ACCESS read-only 789 STATUS deprecated 790 DESCRIPTION 791 "The local IP address for this UDP listener. In the 792 case of a UDP listener which is willing to accept 793 datagrams for any IP interface associated with the 794 node, the value 0.0.0.0 is used." 795 ::= { udpEntry 1 } 797 udpLocalPort OBJECT-TYPE 798 SYNTAX Integer32 (0..65535) 799 MAX-ACCESS read-only 800 STATUS deprecated 801 DESCRIPTION 802 "The local port number for this UDP listener." 803 ::= { udpEntry 2 } 805 -- conformance information 807 udpMIBConformance OBJECT IDENTIFIER ::= { udpMIB 2 } 809 udpMIBCompliances OBJECT IDENTIFIER ::= { udpMIBConformance 1 } 810 udpMIBGroups OBJECT IDENTIFIER ::= { udpMIBConformance 2 } 812 -- compliance statements 814 udpMIBCompliance2 MODULE-COMPLIANCE 815 STATUS current 816 DESCRIPTION 817 "The compliance statement for systems which implement 818 UDP. 820 There are a number of INDEX objects that cannot be 821 represented in the form of OBJECT clauses in SMIv2, but 822 for which we have the following compliance 823 requirements, expressed in OBJECT clause form in this 824 description clause: 826 -- OBJECT udpEndpointLocalAddressType 827 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 828 -- ipv6(2), ipv4z(3), 829 -- ipv6z(4) } 830 -- DESCRIPTION 831 -- Support for dns(5) is not required. 832 -- OBJECT udpEndpointLocalAddress 833 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 834 -- DESCRIPTION 835 -- Support is only required for zero-length 836 -- octet-strings, and for scoped and unscoped 837 -- IPv4 and IPv6 addresses. 838 -- OBJECT udpEndpointRemoteAddressType 839 -- SYNTAX InetAddressType { unknown(0), ipv4(1), 840 -- ipv6(2), ipv4z(3), 841 -- ipv6z(4) } 842 -- DESCRIPTION 843 -- Support for dns(5) is not required. 844 -- OBJECT udpEndpointRemoteAddress 845 -- SYNTAX InetAddress (SIZE(0|4|8|16|20)) 846 -- DESCRIPTION 847 -- Support is only required for zero-length 848 -- octet-strings, and for scoped and unscoped 849 -- IPv4 and IPv6 addresses. 850 " 851 MODULE -- this module 852 MANDATORY-GROUPS { udpBaseGroup, udpEndpointGroup } 853 GROUP udpHCGroup 854 DESCRIPTION 855 "This group is mandatory for those systems which 856 are capable of receiving or transmitting more than 857 1 million UDP datagrams per second. 1 million 858 datagrams per second will cause a Counter32 to 859 wrap in just over an hour." 860 ::= { udpMIBCompliances 2 } 862 udpMIBCompliance MODULE-COMPLIANCE 863 STATUS deprecated 864 DESCRIPTION 865 "The compliance statement for IPv4-only systems which 866 implement UDP. For IP version independence, this 867 compliance statement is deprecated in favor of 868 udpMIBCompliance2. However, agents are still 869 encouraged to implement these objects in order to 870 interoperate with the deployed base of managers." 871 MODULE -- this module 872 MANDATORY-GROUPS { udpGroup } 873 ::= { udpMIBCompliances 1 } 875 -- units of conformance 877 udpGroup OBJECT-GROUP 878 OBJECTS { udpInDatagrams, udpNoPorts, 879 udpInErrors, udpOutDatagrams, 880 udpLocalAddress, udpLocalPort } 881 STATUS deprecated 882 DESCRIPTION 883 "The deprecated group of objects providing for 884 management of UDP over IPv4." 885 ::= { udpMIBGroups 1 } 887 udpBaseGroup OBJECT-GROUP 888 OBJECTS { udpInDatagrams, udpNoPorts, udpInErrors, 889 udpOutDatagrams } 890 STATUS current 891 DESCRIPTION 892 "The group of objects providing for counters of UDP 893 statistics." 894 ::= { udpMIBGroups 2 } 896 udpHCGroup OBJECT-GROUP 897 OBJECTS { udpHCInDatagrams, udpHCOutDatagrams } 898 STATUS current 899 DESCRIPTION 900 "The group of objects providing for counters of high 901 speed UDP implementations." 902 ::= { udpMIBGroups 3 } 904 udpEndpointGroup OBJECT-GROUP 905 OBJECTS { udpEndpointProcess } 906 STATUS current 907 DESCRIPTION 908 "The group of objects providing for the IP version 909 independent management of UDP 'endpoints'." 910 ::= { udpMIBGroups 4 } 912 END 914 5. Acknowledgements 916 This document contains a modified subset of RFC 1213 and updates RFC 917 2013 and RFC 2454. Acknowledments are therefore due to the authors 918 and editors of these documents for their excellent work. 920 6. Contributers 922 This document is an output of the IPv6 MIB revision team, and 923 contributors to earlier versions of this document include: 925 Bill Fenner, AT&T Labs -- Research 926 Email: fenner@research.at.com 927 Brian Haberman 928 Email: brian@innovationslab.net 930 Shawn A. Routhier, Wind River 931 Email: sar@epilogue.com 933 Juergen Schoenwalder, TU Braunschweig 934 Email: schoenw@ibr.cs.tu-bs.de 936 Dave Thaler, Microsoft 937 Email: dthaler@windows.microsoft.com 939 Much of Keith McCloghrie's text from RFC1213/RFC2013 remains in this 940 document, and the structure of the MIB is due to him. 942 Mike Daniele wrote the original IPv6 UDP MIB in RFC2454. 944 Juergen Schoenwalder provided much of the text for section 2. 946 7. Security Considerations 948 There are no management objects defined in this MIB that have a 949 MAX-ACCESS clause of read-write and/or read-create. So, if this MIB 950 is implemented correctly, then there is no risk that an intruder can 951 alter or create any management objects of this MIB module via direct 952 SNMP SET operations. 954 Some of the readable objects in this MIB module (i.e., objects with a 955 MAX-ACCESS other than not-accessible) may be considered sensitive or 956 vulnerable in some network environments. It is thus important to 957 control even GET and/or NOTIFY access to these objects and possibly 958 to even encrypt the values of these objects when sending them over 959 the network via SNMP. These are the tables and objects and their 960 sensitivity/vulnerability: 962 The indices of the udpEndpointTable and udpTable contain information 963 on the listeners on an entity. In particular, the 964 udpEndpointLocalPort and udpLocalPort objects in the indices can be 965 used to identify what ports are open on the machine and can thus what 966 attacks are likely to succeed, without the attacker having to run a 967 port scanner. 969 SNMP versions prior to SNMPv3 did not include adequate security. 970 Even if the network itself is secure (for example by using IPSec), 971 even then, there is no control as to who on the secure network is 972 allowed to access and GET/SET (read/change/create/delete) the objects 973 in this MIB module. 975 It is recommended that the implementors consider the security 976 features as provided by the SNMPv3 framework (see [RFC3410], section 977 8), including full support for the SNMPv3 cryptographic mechanisms 978 (for authentication and privacy). 980 Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT 981 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 982 enable cryptographic security. It is then a customer/operator 983 responsibility to ensure that the SNMP entity giving access to an 984 instance of this MIB module is properly configured to give access to 985 the objects only to those principals (users) that have legitimate 986 rights to indeed GET or SET (change/create/delete) them. 988 8. IANA Considerations 990 The MIB module in this document uses the following IANA-assigned 991 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 993 +------------+-------------------------+ 994 | Descriptor | OBJECT IDENTIFIER value | 995 +------------+-------------------------+ 996 | udp | { mib-2 7} | 997 | udpMIB | { mib-2 50 } | 998 +------------+-------------------------+ 1000 Editor's Note (to be removed prior to publication): this draft makes 1001 no additional requests of the IANA. 1003 9. References 1005 9.1 Normative References 1007 [I-D.ietf-ops-rfc3291bis] 1008 Daniele, M., "Textual Conventions for Internet Network 1009 Addresses", draft-ietf-ops-rfc3291bis-06 (work in 1010 progress), August 2004. 1012 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1013 August 1980. 1015 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1016 McCloghrie, K., Rose, M. and S. Waldbusser, "Structure of 1017 Management Information Version 2 (SMIv2)", STD 58, RFC 1018 2578, April 1999. 1020 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1021 McCloghrie, K., Rose, M. and S. Waldbusser, "Textual 1022 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 1024 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 1025 "Conformance Statements for SMIv2", STD 58, RFC 2580, 1026 April 1999. 1028 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 1029 Simple Network Management Protocol (SNMP)", STD 62, RFC 1030 3418, December 2002. 1032 9.2 Informative References 1034 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1035 for Network Management of TCP/IP-based internets:MIB-II", 1036 STD 17, RFC 1213, March 1991. 1038 [RFC2013] McCloghrie, K., "SNMPv2 Management Information Base for 1039 the User Datagram Protocol using SMIv2", RFC 2013, 1040 November 1996. 1042 [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System-Level 1043 Managed Objects for Applications", RFC 2287, February 1044 1998. 1046 [RFC2454] Daniele, M., "IP Version 6 Management Information Base for 1047 the User Datagram Protocol", RFC 2454, December 1998. 1049 [RFC2790] Waldbusser, S. and P. Grillo, "Host Resources MIB", RFC 1050 2790, March 2000. 1052 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1053 "Introduction and Applicability Statements for 1054 Internet-Standard Management Framework", RFC 3410, 1055 December 2002. 1057 Authors' Addresses 1059 Bill Fenner 1060 AT&T Labs -- Research 1061 75 Willow Rd 1062 Menlo Park, CA 94025 1063 USA 1065 EMail: fenner@research.att.com 1066 John Flick 1067 Hewlett-Packard Company 1068 8000 Foothills Blvd. M/S 5557 1069 Roseville, CA 95747-5557 1070 USA 1072 EMail: john.flick@hp.com 1074 Intellectual Property Statement 1076 The IETF takes no position regarding the validity or scope of any 1077 Intellectual Property Rights or other rights that might be claimed to 1078 pertain to the implementation or use of the technology described in 1079 this document or the extent to which any license under such rights 1080 might or might not be available; nor does it represent that it has 1081 made any independent effort to identify any such rights. Information 1082 on the procedures with respect to rights in RFC documents can be 1083 found in BCP 78 and BCP 79. 1085 Copies of IPR disclosures made to the IETF Secretariat and any 1086 assurances of licenses to be made available, or the result of an 1087 attempt made to obtain a general license or permission for the use of 1088 such proprietary rights by implementers or users of this 1089 specification can be obtained from the IETF on-line IPR repository at 1090 http://www.ietf.org/ipr. 1092 The IETF invites any interested party to bring to its attention any 1093 copyrights, patents or patent applications, or other proprietary 1094 rights that may cover technology that may be required to implement 1095 this standard. Please address the information to the IETF at 1096 ietf-ipr@ietf.org. 1098 Disclaimer of Validity 1100 This document and the information contained herein are provided on an 1101 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1102 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1103 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1104 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1105 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1106 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1108 Copyright Statement 1110 Copyright (C) The Internet Society (2004). This document is subject 1111 to the rights, licenses and restrictions contained in BCP 78, and 1112 except as set forth therein, the authors retain all their rights. 1114 Acknowledgment 1116 Funding for the RFC Editor function is currently provided by the 1117 Internet Society.