home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2454.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  16.0 KB  |  508 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      M. Daniele
  8. Request for Comments: 2454                Compaq Computer Corporation
  9. Category: Standards Track                               December 1998
  10.  
  11.  
  12.                IP Version 6 Management Information Base
  13.                     for the User Datagram Protocol
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Copyright Notice
  24.  
  25.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  26.  
  27. Abstract
  28.  
  29.    This document is one in the series of documents that define various
  30.    MIB objects for IPv6.  Specifically, this document is the MIB module
  31.    which defines managed objects for implementations of the User
  32.    Datagram Protocol (UDP) over IP Version 6 (IPv6).
  33.  
  34.    This document also recommends a specific policy with respect to the
  35.    applicability of RFC 2013 for implementations of IPv6.  Namely, that
  36.    most of managed objects defined in RFC 2013 are independent of which
  37.    IP versions underlie UDP, and only the UDP listener information is IP
  38.    version-specific.
  39.  
  40.    This memo defines an experimental portion of the Management
  41.    Information Base (MIB) for use with network management protocols in
  42.    IPv6-based internets.
  43.  
  44. 1.  Introduction
  45.  
  46.    A management system contains: several (potentially many) nodes, each
  47.    with a processing entity, termed an agent, which has access to
  48.    management instrumentation; at least one management station; and, a
  49.    management protocol, used to convey management information between
  50.    the agents and management stations.  Operations of the protocol are
  51.    carried out under an administrative framework which defines
  52.    authentication, authorization, access control, and privacy policies.
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Daniele                     Standards Track                     [Page 1]
  59.  
  60. RFC 2454                    UDP MIB for IPv6               December 1998
  61.  
  62.  
  63.    Management stations execute management applications which monitor and
  64.    control managed elements.  Managed elements are devices such as
  65.    hosts, routers, terminal servers, etc., which are monitored and
  66.    controlled via access to their management information.
  67.  
  68.    Management information is viewed as a collection of managed objects,
  69.    residing in a virtual information store, termed the Management
  70.    Information Base (MIB).  Collections of related objects are defined
  71.    in MIB modules.  These modules are written using a subset of OSI's
  72.    Abstract Syntax Notation One (ASN.1) [1], termed the Structure of
  73.    Management Information (SMI) [2].
  74.  
  75. 2.  Overview
  76.  
  77.    This document is one in the series of documents that define various
  78.    MIB objects, and statements of conformance, for IPv6.  This document
  79.    defines the required instrumentation for implementations of UDP over
  80.    IPv6.
  81.  
  82. 3.  Transparency of IP versions to UDP
  83.  
  84.    The fact that UDP is carried over IPv6 as opposed to IPv4, is largely
  85.    invisible to a UDP implementation.  A "UDPng" did not need to be
  86.    defined, implementations simply need to support IPv6 addresses.
  87.  
  88.    As such, the managed objects already defined in [UDP MIB] are
  89.    sufficient for managing UDP in the presence of IPv6.  These objects
  90.    are equally applicable whether the managed node supports IPv4 only,
  91.    IPv6 only, or both IPv4 and IPv6.
  92.  
  93.    For example, udpInDatagrams counts "The total number of UDP datagrams
  94.    delivered to UDP users", regardless of which version of IP is used to
  95.    deliver any of those datagrams.
  96.  
  97.    Stated differently, UDP implementations don't need separate counters
  98.    for IPv4 and for IPv6.
  99.  
  100. 4.  Representing UDP Listeners
  101.  
  102.    The exception to the statements in section 3 is the udpTable.  Since
  103.    IPv6 addresses cannot be represented with the IpAddress syntax, not
  104.    all UDP endpoints can be represented in the udpTable defined in [UDP
  105.    MIB].
  106.  
  107.    This memo defines a new, separate table to represent only those UDP
  108.    endpoints that utilize an IPv6 address.  UDP endpoints on IPv4
  109.    addresses continue to be represented in udpTable [UDP MIB].
  110.  
  111.  
  112.  
  113.  
  114. Daniele                     Standards Track                     [Page 2]
  115.  
  116. RFC 2454                    UDP MIB for IPv6               December 1998
  117.  
  118.  
  119.    A different approach would have been to define a new table to
  120.    represent all UDP endpoints regardless of IP version.  This would
  121.    require changes to [UDP MIB] and hence to existing (IPv4-only) UDP
  122.    implementations.  The approach suggested in this memo has the
  123.    advantage of leaving IPv4-only implementations intact.
  124.  
  125.    It is assumed that the objects defined in this memo will eventually
  126.    be defined in an update to [UDP MIB].  For this reason, the module
  127.    identity is assigned under the experimental portion of the MIB.
  128.  
  129. 5.  Conformance
  130.  
  131.    This memo contains conformance statements to define conformance to
  132.    this MIB for UDP over IPv6 implementations.
  133.  
  134. 6.  Definitions
  135.  
  136. IPV6-UDP-MIB DEFINITIONS ::= BEGIN
  137.  
  138. IMPORTS
  139.    MODULE-COMPLIANCE, OBJECT-GROUP      FROM SNMPv2-CONF
  140.    MODULE-IDENTITY, OBJECT-TYPE,
  141.    mib-2, experimental                  FROM SNMPv2-SMI
  142.    Ipv6Address, Ipv6IfIndexOrZero       FROM IPV6-TC;
  143.  
  144. ipv6UdpMIB MODULE-IDENTITY
  145.    LAST-UPDATED "9801290000Z"
  146.    ORGANIZATION "IETF IPv6 MIB Working Group"
  147.    CONTACT-INFO
  148.         "               Mike Daniele
  149.  
  150.                 Postal: Compaq Computer Corporation
  151.                         110 Spitbrook Rd
  152.                         Nashua, NH 03062.
  153.                         US
  154.  
  155.                 Phone:  +1 603 884 1423
  156.                 Email:  daniele@zk3.dec.com"
  157.    DESCRIPTION
  158.         "The MIB module for entities implementing UDP over IPv6."
  159.    ::= { experimental 87 }
  160.  
  161. -- objects specific to UDP for IPv6
  162.  
  163. udp      OBJECT IDENTIFIER ::= { mib-2 7 }
  164.  
  165. -- the UDP over IPv6 Listener table
  166.  
  167.  
  168.  
  169.  
  170. Daniele                     Standards Track                     [Page 3]
  171.  
  172. RFC 2454                    UDP MIB for IPv6               December 1998
  173.  
  174.  
  175. -- This table contains information about this entity's
  176. -- UDP/IPv6 endpoints.  Only endpoints utilizing IPv6 addresses
  177. -- are contained in this table.  This entity's UDP/IPv4 endpoints
  178. -- are contained in udpTable.
  179.  
  180. ipv6UdpTable OBJECT-TYPE
  181.    SYNTAX      SEQUENCE OF Ipv6UdpEntry
  182.    MAX-ACCESS  not-accessible
  183.    STATUS      current
  184.    DESCRIPTION
  185.         "A table containing UDP listener information for
  186.          UDP/IPv6 endpoints."
  187.    ::= { udp 6 }
  188.  
  189. ipv6UdpEntry OBJECT-TYPE
  190.    SYNTAX      Ipv6UdpEntry
  191.    MAX-ACCESS  not-accessible
  192.    STATUS      current
  193.    DESCRIPTION
  194.         "Information about a particular current UDP listener.
  195.  
  196.          Note that conceptual rows in this table require an
  197.          additional index object compared to udpTable, since
  198.          IPv6 addresses are not guaranteed to be unique on the
  199.          managed node."
  200.    INDEX   { ipv6UdpLocalAddress,
  201.              ipv6UdpLocalPort,
  202.              ipv6UdpIfIndex }
  203.    ::= { ipv6UdpTable 1 }
  204.  
  205. Ipv6UdpEntry ::= SEQUENCE {
  206.    ipv6UdpLocalAddress    Ipv6Address,
  207.    ipv6UdpLocalPort       INTEGER (0..65535),
  208.    ipv6UdpIfIndex         Ipv6IfIndexOrZero }
  209.  
  210. ipv6UdpLocalAddress OBJECT-TYPE
  211.    SYNTAX       Ipv6Address
  212.    MAX-ACCESS   not-accessible
  213.    STATUS       current
  214.    DESCRIPTION
  215.         "The local IPv6 address for this UDP listener.
  216.          In the case of a UDP listener which is willing
  217.          to accept datagrams for any IPv6 address
  218.          associated with the managed node, the value ::0
  219.          is used."
  220.    ::= { ipv6UdpEntry 1 }
  221.  
  222. ipv6UdpLocalPort OBJECT-TYPE
  223.  
  224.  
  225.  
  226. Daniele                     Standards Track                     [Page 4]
  227.  
  228. RFC 2454                    UDP MIB for IPv6               December 1998
  229.  
  230.  
  231.     SYNTAX     INTEGER (0..65535)
  232.     MAX-ACCESS not-accessible
  233.     STATUS     current
  234.     DESCRIPTION
  235.         "The local port number for this UDP listener."
  236.     ::= { ipv6UdpEntry 2 }
  237.  
  238. ipv6UdpIfIndex OBJECT-TYPE
  239.    SYNTAX     Ipv6IfIndexOrZero
  240.    MAX-ACCESS   read-only
  241.    STATUS     current
  242.    DESCRIPTION
  243.         "An index object used to disambiguate conceptual rows in
  244.          the table, since the ipv6UdpLocalAddress/ipv6UdpLocalPort
  245.          pair may not be unique.
  246.  
  247.          This object identifies the local interface that is
  248.          associated with ipv6UdpLocalAddress for this UDP listener.
  249.          If such a local interface cannot be determined, this object
  250.          should take on the value 0.  (A possible example of this
  251.          would be if the value of ipv6UdpLocalAddress is ::0.)
  252.  
  253.          The interface identified by a particular non-0 value of
  254.          this index is the same interface as identified by the same
  255.          value of ipv6IfIndex.
  256.  
  257.          The value of this object must remain constant during
  258.          the life of this UDP endpoint."
  259.    ::= { ipv6UdpEntry 3 }
  260.  
  261. --
  262. -- conformance information
  263. --
  264.  
  265. ipv6UdpConformance OBJECT IDENTIFIER ::= { ipv6UdpMIB 2 }
  266.  
  267. ipv6UdpCompliances OBJECT IDENTIFIER ::= { ipv6UdpConformance 1 }
  268. ipv6UdpGroups      OBJECT IDENTIFIER ::= { ipv6UdpConformance 2 }
  269.  
  270. -- compliance statements
  271.  
  272. ipv6UdpCompliance MODULE-COMPLIANCE
  273.    STATUS  current
  274.    DESCRIPTION
  275.         "The compliance statement for SNMPv2 entities which
  276.          implement UDP over IPv6."
  277.    MODULE  -- this module
  278.    MANDATORY-GROUPS { ipv6UdpGroup }
  279.  
  280.  
  281.  
  282. Daniele                     Standards Track                     [Page 5]
  283.  
  284. RFC 2454                    UDP MIB for IPv6               December 1998
  285.  
  286.  
  287.    ::= { ipv6UdpCompliances 1 }
  288.  
  289. ipv6UdpGroup OBJECT-GROUP
  290.    OBJECTS   { -- these are defined in this module
  291.                -- ipv6UdpLocalAddress (not-accessible)
  292.                -- ipv6UdpLocalPort (not-accessible)
  293.                ipv6UdpIfIndex }
  294.    STATUS    current
  295.    DESCRIPTION
  296.         "The group of objects providing management of
  297.          UDP over IPv6."
  298.    ::= { ipv6UdpGroups 1 }
  299.  
  300. END
  301.  
  302. 7.  Acknowledgments
  303.  
  304.    This memo is a product of the IPng work group, and benefited
  305.    especially from the contributions of the following working group
  306.    members:
  307.  
  308.       Dimitry Haskin          Bay Networks
  309.       Margaret Forsythe       Epilogue
  310.       Tim Hartrick            Mentat
  311.       Frank Solensky          FTP
  312.       Jack McCann             DEC
  313.  
  314. 8.  References
  315.  
  316.    [1]           Information processing systems - Open Systems
  317.                  Interconnection - Specification of Abstract Syntax
  318.                  Notation One (ASN.1), International Organization for
  319.                  Standardization.  International Standard 8824,
  320.                  (December, 1987).
  321.  
  322.    [2]           McCloghrie, K., Editor, "Structure of Management
  323.                  Information for version 2 of the Simple Network
  324.                  Management Protocol (SNMPv2)", RFC 1902, January 1996.
  325.  
  326.    [UDP MIB]     SNMPv2 Working Group, McCloghrie, K., Editor, "SNMPv2
  327.                  Management Information Base for the User Datagram
  328.                  Protocol using SMIv2", RFC 2013, November 1996.
  329.  
  330.    [IPV6 MIB TC] Haskin, D., and S. Onishi, "Management Information Base
  331.                  for IP Version 6: Textual Conventions and General
  332.                  Group", RFC 2465, December 1998.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Daniele                     Standards Track                     [Page 6]
  339.  
  340. RFC 2454                    UDP MIB for IPv6               December 1998
  341.  
  342.  
  343.    [IPV6]        Deering, S., and R. Hinden, "Internet Protocol, Version
  344.                  6 (IPv6) Specification", RFC 2460, December 1998.
  345.  
  346.    [RFC2274]     Blumenthal, U., and B. Wijnen, "The User-Based Security
  347.                  Model for Version 3 of the Simple Network Management
  348.                  Protocol (SNMPv3)", RFC 2274, January 1998.
  349.  
  350.    [RFC2275]     Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
  351.                  Access Control Model for the Simple Network Management
  352.                  Protocol (SNMP)", RFC 2275, January 1998.
  353.  
  354. 9.  Security Considerations
  355.  
  356.    There are no management objects defined in this MIB that have a MAX-
  357.    ACCESS clause of read-write and/or read-create.  So, if this MIB is
  358.    implemented correctly, then there is no risk that an intruder can
  359.    alter or create any management objects of this MIB via direct SNMP
  360.    SET operations.
  361.  
  362.    There are a number of managed objects in this MIB that may be
  363.    considered to contain sensitive information in some environments.
  364.    For example, the MIB identifies UDP ports on which processes are
  365.    listening.  Although this information might be considered sensitive
  366.    in some environments (i.e., to identify ports on which to launch
  367.    denial-of-service or other attacks), there are already other ways of
  368.    obtaining similar information.  For example, sending a random UDP
  369.    packet to an unused port prompts the generation of an ICMP port
  370.    unreachable message.
  371.  
  372.    Therefore, it may be important in some environments to control read
  373.    access to these objects and possibly to even encrypt the values of
  374.    these object when sending them over the network via SNMP.  Not all
  375.    versions of SNMP provide features for such a secure environment.
  376.    SNMPv1 by itself does not provide encryption or strong
  377.    authentication.
  378.  
  379.    It is recommended that the implementors consider the security
  380.    features as provided by the SNMPv3 framework.  Specifically, the use
  381.    of the User-based Security Model [RFC2274] and the View-based Access
  382.    Control Model [RFC2275] is recommended.
  383.  
  384.    It is then a customer/user responsibility to ensure that the SNMP
  385.    entity giving access to an instance of this MIB, is properly
  386.    configured to give access to those objects only to those principals
  387.    (users) that have legitimate rights to access them.
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Daniele                     Standards Track                     [Page 7]
  395.  
  396. RFC 2454                    UDP MIB for IPv6               December 1998
  397.  
  398.  
  399. 10. Author's Address
  400.  
  401.    Mike Daniele
  402.    Compaq Computer Corporation
  403.    110 Spit Brook Rd
  404.    Nashua, NH 03062
  405.  
  406.    Phone: +1-603-884-1423
  407.    EMail: daniele@zk3.dec.com
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Daniele                     Standards Track                     [Page 8]
  451.  
  452. RFC 2454                    UDP MIB for IPv6               December 1998
  453.  
  454.  
  455. 11.  Full Copyright Statement
  456.  
  457.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  458.  
  459.    This document and translations of it may be copied and furnished to
  460.    others, and derivative works that comment on or otherwise explain it
  461.    or assist in its implementation may be prepared, copied, published
  462.    and distributed, in whole or in part, without restriction of any
  463.    kind, provided that the above copyright notice and this paragraph are
  464.    included on all such copies and derivative works.  However, this
  465.    document itself may not be modified in any way, such as by removing
  466.    the copyright notice or references to the Internet Society or other
  467.    Internet organizations, except as needed for the purpose of
  468.    developing Internet standards in which case the procedures for
  469.    copyrights defined in the Internet Standards process must be
  470.    followed, or as required to translate it into languages other than
  471.    English.
  472.  
  473.    The limited permissions granted above are perpetual and will not be
  474.    revoked by the Internet Society or its successors or assigns.
  475.  
  476.    This document and the information contained herein is provided on an
  477.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  478.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  479.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  480.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  481.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Daniele                     Standards Track                     [Page 9]
  507.  
  508.