Home Articles FAQs XREF Games Software Instant Books BBS About FOLDOC RFCs Feedback Sitemap

Request For Comments - RFC2454

You are here: irt.org | RFCs | RFC2454 [ previous next ]

Network Working Group                                      M. Daniele
Request for Comments: 2454                Compaq Computer Corporation
Category: Standards Track                               December 1998

               IP Version 6 Management Information Base
                    for the User Datagram Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   This document is one in the series of documents that define various
   MIB objects for IPv6.  Specifically, this document is the MIB module
   which defines managed objects for implementations of the User
   Datagram Protocol (UDP) over IP Version 6 (IPv6).

   This document also recommends a specific policy with respect to the
   applicability of RFC 2013 for implementations of IPv6.  Namely, that
   most of managed objects defined in RFC 2013 are independent of which
   IP versions underlie UDP, and only the UDP listener information is IP

   This memo defines an experimental portion of the Management
   Information Base (MIB) for use with network management protocols in
   IPv6-based internets.

1.  Introduction

   A management system contains: several (potentially many) nodes, each
   with a processing entity, termed an agent, which has access to
   management instrumentation; at least one management station; and, a
   management protocol, used to convey management information between
   the agents and management stations.  Operations of the protocol are
   carried out under an administrative framework which defines
   authentication, authorization, access control, and privacy policies.

Daniele                     Standards Track                     [Page 1]

RFC 2454                    UDP MIB for IPv6               December 1998

   Management stations execute management applications which monitor and
   control managed elements.  Managed elements are devices such as
   hosts, routers, terminal servers, etc., which are monitored and
   controlled via access to their management information.

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management
   Information Base (MIB).  Collections of related objects are defined
   in MIB modules.  These modules are written using a subset of OSI's
   Abstract Syntax Notation One (ASN.1) [1], termed the Structure of
   Management Information (SMI) [2].

2.  Overview

   This document is one in the series of documents that define various
   MIB objects, and statements of conformance, for IPv6.  This document
   defines the required instrumentation for implementations of UDP over

3.  Transparency of IP versions to UDP

   The fact that UDP is carried over IPv6 as opposed to IPv4, is largely
   invisible to a UDP implementation.  A "UDPng" did not need to be
   defined, implementations simply need to support IPv6 addresses.

   As such, the managed objects already defined in [UDP MIB] are
   sufficient for managing UDP in the presence of IPv6.  These objects
   are equally applicable whether the managed node supports IPv4 only,
   IPv6 only, or both IPv4 and IPv6.

   For example, udpInDatagrams counts "The total number of UDP datagrams
   delivered to UDP users", regardless of which version of IP is used to
   deliver any of those datagrams.

   Stated differently, UDP implementations don't need separate counters
   for IPv4 and for IPv6.

4.  Representing UDP Listeners

   The exception to the statements in section 3 is the udpTable.  Since
   IPv6 addresses cannot be represented with the IpAddress syntax, not
   all UDP endpoints can be represented in the udpTable defined in [UDP

   This memo defines a new, separate table to represent only those UDP
   endpoints that utilize an IPv6 address.  UDP endpoints on IPv4
   addresses continue to be represented in udpTable [UDP MIB].

Daniele                     Standards Track                     [Page 2]

RFC 2454                    UDP MIB for IPv6               December 1998

   A different approach would have been to define a new table to
   represent all UDP endpoints regardless of IP version.  This would
   require changes to [UDP MIB] and hence to existing (IPv4-only) UDP
   implementations.  The approach suggested in this memo has the
   advantage of leaving IPv4-only implementations intact.

   It is assumed that the objects defined in this memo will eventually
   be defined in an update to [UDP MIB].  For this reason, the module
   identity is assigned under the experimental portion of the MIB.

5.  Conformance

   This memo contains conformance statements to define conformance to
   this MIB for UDP over IPv6 implementations.

6.  Definitions


   mib-2, experimental                  FROM SNMPv2-SMI
   Ipv6Address, Ipv6IfIndexOrZero       FROM IPV6-TC;

   LAST-UPDATED "9801290000Z"
        "               Mike Daniele

                Postal: Compaq Computer Corporation
                        110 Spitbrook Rd
                        Nashua, NH 03062.

                Phone:  +1 603 884 1423
                Email:  daniele@zk3.dec.com"
        "The MIB module for entities implementing UDP over IPv6."
   ::= { experimental 87 }

-- objects specific to UDP for IPv6

udp      OBJECT IDENTIFIER ::= { mib-2 7 }

-- the UDP over IPv6 Listener table

Daniele                     Standards Track                     [Page 3]

RFC 2454                    UDP MIB for IPv6               December 1998

-- This table contains information about this entity's
-- UDP/IPv6 endpoints.  Only endpoints utilizing IPv6 addresses
-- are contained in this table.  This entity's UDP/IPv4 endpoints
-- are contained in udpTable.

ipv6UdpTable OBJECT-TYPE
   SYNTAX      SEQUENCE OF Ipv6UdpEntry
   MAX-ACCESS  not-accessible
   STATUS      current
        "A table containing UDP listener information for
         UDP/IPv6 endpoints."
   ::= { udp 6 }

ipv6UdpEntry OBJECT-TYPE
   SYNTAX      Ipv6UdpEntry
   MAX-ACCESS  not-accessible
   STATUS      current
        "Information about a particular current UDP listener.

         Note that conceptual rows in this table require an
         additional index object compared to udpTable, since
         IPv6 addresses are not guaranteed to be unique on the
         managed node."
   INDEX   { ipv6UdpLocalAddress,
             ipv6UdpIfIndex }
   ::= { ipv6UdpTable 1 }

Ipv6UdpEntry ::= SEQUENCE {
   ipv6UdpLocalAddress    Ipv6Address,
   ipv6UdpLocalPort       INTEGER (0..65535),
   ipv6UdpIfIndex         Ipv6IfIndexOrZero }

ipv6UdpLocalAddress OBJECT-TYPE
   SYNTAX       Ipv6Address
   MAX-ACCESS   not-accessible
   STATUS       current
        "The local IPv6 address for this UDP listener.
         In the case of a UDP listener which is willing
         to accept datagrams for any IPv6 address
         associated with the managed node, the value ::0
         is used."
   ::= { ipv6UdpEntry 1 }

ipv6UdpLocalPort OBJECT-TYPE

Daniele                     Standards Track                     [Page 4]

RFC 2454                    UDP MIB for IPv6               December 1998

    SYNTAX     INTEGER (0..65535)
    MAX-ACCESS not-accessible
    STATUS     current
        "The local port number for this UDP listener."
    ::= { ipv6UdpEntry 2 }

ipv6UdpIfIndex OBJECT-TYPE
   SYNTAX     Ipv6IfIndexOrZero
   MAX-ACCESS   read-only
   STATUS     current
        "An index object used to disambiguate conceptual rows in
         the table, since the ipv6UdpLocalAddress/ipv6UdpLocalPort
         pair may not be unique.

         This object identifies the local interface that is
         associated with ipv6UdpLocalAddress for this UDP listener.
         If such a local interface cannot be determined, this object
         should take on the value 0.  (A possible example of this
         would be if the value of ipv6UdpLocalAddress is ::0.)

         The interface identified by a particular non-0 value of
         this index is the same interface as identified by the same
         value of ipv6IfIndex.

         The value of this object must remain constant during
         the life of this UDP endpoint."
   ::= { ipv6UdpEntry 3 }

-- conformance information

ipv6UdpConformance OBJECT IDENTIFIER ::= { ipv6UdpMIB 2 }

ipv6UdpCompliances OBJECT IDENTIFIER ::= { ipv6UdpConformance 1 }
ipv6UdpGroups      OBJECT IDENTIFIER ::= { ipv6UdpConformance 2 }

-- compliance statements

   STATUS  current
        "The compliance statement for SNMPv2 entities which
         implement UDP over IPv6."
   MODULE  -- this module
   MANDATORY-GROUPS { ipv6UdpGroup }

Daniele                     Standards Track                     [Page 5]

RFC 2454                    UDP MIB for IPv6               December 1998

   ::= { ipv6UdpCompliances 1 }

   OBJECTS   { -- these are defined in this module
               -- ipv6UdpLocalAddress (not-accessible)
               -- ipv6UdpLocalPort (not-accessible)
               ipv6UdpIfIndex }
   STATUS    current
        "The group of objects providing management of
         UDP over IPv6."
   ::= { ipv6UdpGroups 1 }


7.  Acknowledgments

   This memo is a product of the IPng work group, and benefited
   especially from the contributions of the following working group

      Dimitry Haskin          Bay Networks
      Margaret Forsythe       Epilogue
      Tim Hartrick            Mentat
      Frank Solensky          FTP
      Jack McCann             DEC

8.  References

   [1]           Information processing systems - Open Systems
                 Interconnection - Specification of Abstract Syntax
                 Notation One (ASN.1), International Organization for
                 Standardization.  International Standard 8824,
                 (December, 1987).

   [2]           McCloghrie, K., Editor, "Structure of Management
                 Information for version 2 of the Simple Network
                 Management Protocol (SNMPv2)", RFC 1902, January 1996.

   [UDP MIB]     SNMPv2 Working Group, McCloghrie, K., Editor, "SNMPv2
                 Management Information Base for the User Datagram
                 Protocol using SMIv2", RFC 2013, November 1996.

   [IPV6 MIB TC] Haskin, D., and S. Onishi, "Management Information Base
                 for IP Version 6: Textual Conventions and General
                 Group", RFC 2465, December 1998.

Daniele                     Standards Track                     [Page 6]

RFC 2454                    UDP MIB for IPv6               December 1998

   [IPV6]        Deering, S., and R. Hinden, "Internet Protocol, Version
                 6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC2274]     Blumenthal, U., and B. Wijnen, "The User-Based Security
                 Model for Version 3 of the Simple Network Management
                 Protocol (SNMPv3)", RFC 2274, January 1998.

   [RFC2275]     Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
                 Access Control Model for the Simple Network Management
                 Protocol (SNMP)", RFC 2275, January 1998.

9.  Security Considerations

   There are no management objects defined in this MIB that have a MAX-
   ACCESS clause of read-write and/or read-create.  So, if this MIB is
   implemented correctly, then there is no risk that an intruder can
   alter or create any management objects of this MIB via direct SNMP
   SET operations.

   There are a number of managed objects in this MIB that may be
   considered to contain sensitive information in some environments.
   For example, the MIB identifies UDP ports on which processes are
   listening.  Although this information might be considered sensitive
   in some environments (i.e., to identify ports on which to launch
   denial-of-service or other attacks), there are already other ways of
   obtaining similar information.  For example, sending a random UDP
   packet to an unused port prompts the generation of an ICMP port
   unreachable message.

   Therefore, it may be important in some environments to control read
   access to these objects and possibly to even encrypt the values of
   these object when sending them over the network via SNMP.  Not all
   versions of SNMP provide features for such a secure environment.
   SNMPv1 by itself does not provide encryption or strong

   It is recommended that the implementors consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model [RFC2274] and the View-based Access
   Control Model [RFC2275] is recommended.

   It is then a customer/user responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB, is properly
   configured to give access to those objects only to those principals
   (users) that have legitimate rights to access them.

Daniele                     Standards Track                     [Page 7]

RFC 2454                    UDP MIB for IPv6               December 1998

10. Author's Address

   Mike Daniele
   Compaq Computer Corporation
   110 Spit Brook Rd
   Nashua, NH 03062

   Phone: +1-603-884-1423
   EMail: daniele@zk3.dec.com

Daniele                     Standards Track                     [Page 8]

RFC 2454                    UDP MIB for IPv6               December 1998

11.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Daniele                     Standards Track                     [Page 9]

©2018 Martin Webb