[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
Internet-Draft             IANA Address MIB             September 1998
Expires March, 1999

                           IANA Address MIB

                <draft-daniele-iana-addr-mib-00.txt>

                             Mike Daniele
                       Compaq Computer Corporation

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups.  Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
   Coast), or ftp.isi.edu (US West Coast).

1.  Abstract

   This document contains an initial version of a MIB module for
   commonly used network addressing information. It defines a registry
   for identifiers that identify protocols and a set of textual
   conventions for representing addresses. This document also
   establishes IANA as the maintainer of this registry.

2.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

    o   An overall architecture, described in RFC 2271 [1].

    o   Mechanisms for describing and naming objects and events for the
        purpose of management. The first version of this Structure of
        Management Information (SMI) is called SMIv1 and described in
        RFC 1155 [2], RFC 1212 [3] and RFC 1215 [4]. The second version,
        called SMIv2, is described in RFC 1902 [5], RFC 1903 [6] and RFC
        1904 [7].

    o   Message protocols for transferring management information. The
        first version of the SNMP message protocol is called SNMPv1 and
        described in RFC 1157 [8]. A second version of the SNMP message
        protocol, which is not an Internet standards track protocol, is
        called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10].
        The third version of the message protocol is called SNMPv3 and
        described in RFC 1906 [10], RFC 2272 [11] and RFC 2274 [12].

    o   Protocol operations for accessing management information. The
        first set of protocol operations and associated PDU formats is
        described in RFC 1157 [8]. A second set of protocol operations
        and associated PDU formats is described in RFC 1905 [13].

    o   A set of fundamental applications described in RFC 2273 [14] and
        the view-based access control mechanism described in RFC 2275
        [15].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2. A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations. The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64). Some machine readable
   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process. However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

3.  Overview

   This MIB module contains definitions for commonly used network
   addressing information.  In particular, it defines a registry of
   OBJECT-IDENTIFIERs for protocols, and a set of textual conventions
   for representing endpoints.  The former are intended to be widely
   used as values for OBJECT-TYPEs whose syntax is TDomain, the latter
   as values for OBJECT-TYPEs whose syntax is TAddress.

   The purpose of this memo is to provide a single, well-known repository
   for address-related information.  Further, this module establishes IANA
   as the maintainer of these definitions (see section 6).

   Without such a repository, each MIB module requiring addressing constructs
   is forced to either define its own, or attempt to locate and include similar
   definitions from other modules.  The advantages of a repository are

   a) there is a single set of definitions
   b) all MIB developers know what to include, and where to look
   c) multiple definitions of the same information is avoided
   d) the definitions are independant and widely useable, not tied
      to a particular protocol, MIB module, or enterprise
   e) this module can be updated independently, and hence much more
      rapidly, than if the information is defined in broader RFCs
      on the standards-track (for example, [RFC1906])

4.   Transport Domains and Addresses

   The TDomain and TAddress textual conventions are defined in [RFC1903],
   and are intended to be used in MIB modules to represent transport
   domains and addresses.

   Actual values for OBJECT-TYPEs with these syntaxes are currently defined
   in [RFC1906] and various other (enterprise-specific) modules.
   The transport domains defined in [RFC1906] all contain "snmp" as the prefix
   in their name, are all assigned under `snmpDomains' (from [RFC1902]).
   There has been some confusion as to whether these defintions are
   appropriate for designating transport endpoints for non-SNMP traffic.
   These definitions are also now incomplete, new transport addresses are
   needed currently to support (at least) IPv6, TCP, and Unix-domain sockets.

   This module defines a new set of generic transport domains and addresses.
   All assignments are made under a new branch; (TBD), to be administered
   by IANA.

5.  Impact on Transport Mappings

   This module does NOT define the transport mappings for any particular
   protocol.  Rather, it defines a set of common identifiers and textual
   conventions that are intended to be used within various transport mappings
   documents.

   (Inclusion within transport mappings is just one possible use of
    these generic definitions.)

6.  IANA Considerations

   It is intended that IANA will maintain this MIB module.

   Following the policies outlined in [IANA-CONSIDERATIONS],
   additions to this module MUST be reviewed by a Designated Expert.

7.  Definitions

IANA-ADDRESS-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-IDENTITY FROM SNMPv2-SMI
    TEXTUAL-CONVENTION FROM SNMPv2-TC;

ianaAddressMIB MODULE-IDENTITY
   LAST-UPDATED "9809180000Z"
   ORGANIZATION "IANA"
   CONTACT-INFO "TBD"
   DESCRIPTION
        "The MIB module for commonly-used network addressing definitions."
   ::= { TBD }

--
-- The registration node for protocol domains
--
ianaAddrDomains OBJECT IDENTIFIER ::= { TBD }

--
-- Protocol domains
--

-- UDP over IPv4

ianaAddrUDPIPv4Domain   OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The UDP over IPv4 transport domain.  The corresponding
            transport address is of type IanaAddrIPv4TAddress."
    ::= { ianaAddrDomains 1 }

-- UDP over IPv6

ianaAddrUDPIPv6Domain   OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The UDP over IPv6 transport domain.  The corresponding
            transport address is of type IanaAddrIPv6TAddress."
    ::= { ianaAddrDomains 2 }

-- TCP over IPv4

ianaAddrTCPIPv4Domain   OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The TCP over IPv4 transport domain.  The corresponding
            transport address is of type IanaAddrIPv4TAddress."
    ::= { ianaAddrDomains 3 }

-- TCP over IPv6

ianaAddrTCPIPv6Domain   OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The TCP over IPv6 transport domain.  The corresponding
            transport address is of type IanaAddrIPv6TAddress."
    ::= { ianaAddrDomains 4 }

-- UNIX-domain sockets

ianaAddrUNIXDomain      OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The unix-domain sockets transport domain.  The corresponding
            transport address is of type IanaAddrUNIXTAddress."
    ::= { ianaAddrDomains 5 }

-- OSI

ianaAddrCLNSDomain OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The CLNS transport domain.  The corresponding
            transport address is of type IanaAddrOSITAddress."
    ::= { ianaAddrDomains 6 }

ianaAddrCONSDomain OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The CONS transport domain.  The corresponding
            transport address is of type IanaAddrOSITAddress."
    ::= { ianaAddrDomains 7 }

-- DDP

ianaAddrDDPDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The DDP transport domain.  The corresponding
            transport address is of type IanaAddrNBPTAddress."
    ::= { ianaAddrDomains 8 }

-- IPX

ianaAddrIPXDomain  OBJECT-IDENTITY
    STATUS     current
    DESCRIPTION
            "The IPX transport domain.  The corresponding
            transport address is of type IanaAddrIPXTAddress."
    ::= { ianaAddrDomains 9 }


--
-- Enumerated integer version of previous registrations.
--
-- This TC can be used to represent transport domains in situations
-- where a syntax of TDomain is unwieldy (for example, when
-- used as an index).
--
-- Currently the enumerated values of this object are identical to the
-- last sub-identifier of the OID registered for the same domain.
--

IanaAddrTDomainType ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d"
    STATUS       current
    DESCRIPTION
            "A value that represents a transport domain."
    SYNTAX      INTEGER {
                        other(0),
                        ianaAddrUDPIPv4Domain(1),
                        ianaAddrUDPIPv6Domain(2),
                        ianaAddrTCPIPv4Domain(3),
                        ianaAddrTCPIPv6Domain(4),
                        ianaAddrUNIXDomain(5),
                        ianaAddrCLNSDomain(6),
                        ianaAddrCONSDomain(7),
                        ianaAddrDDPDomain(8),
                        ianaAddrIPXDomain(9)
                        }

--
-- Textual conventions for transport endpoints.
--
-- These are named xxxTAddress to denote transport addresses,
-- and differentiate them from network addresses that may be included
-- in subsequent versions.
--

-- TCP/UDP over IPv4 Transport Address

IanaAddrIPv4TAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d/2d"
    STATUS       current
    DESCRIPTION
            "Represents a TCP-over-IPv4 or a UDP-over-IPv4
             transport address:

               octets   contents        encoding
                1-4     IP address      network-byte order
                5-6     TCP or UDP port network-byte order
            "
    SYNTAX       OCTET STRING (SIZE (6))

-- TCP/UDP over IPv6 Transport Address

IanaAddrIPv6TAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x/2d"
    STATUS       current
    DESCRIPTION
            "Represents a TCP-over-IPv6 or a UDP-over-IPv6
             transport address:

                octets   contents        encoding
                 1-16    IPv6 address    network-byte order
                 17-18   TCP or UDP port network-byte order
             "
     SYNTAX       OCTET STRING (SIZE (18))

-- UNIX-domain socket Transport Address

IanaAddrUNIXTAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1a"
    STATUS       current
    DESCRIPTION
             "Represents a UNIX-domain socket endpoint:

                octets       contents               encoding
                all          UNIX domain endpoint   string

             "
     SYNTAX       OCTET STRING

-- OSI Transport Address

IanaAddrOSITAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "*1x:/1x:"
    STATUS       current
    DESCRIPTION
            "Represents an OSI transport-address:

               octets   contents           encoding
                  1     length of NSAP     'n' as an unsigned-integer
                                              (either 0 or from 3 to 20)
               2..(n+1) NSAP                concrete binary representation
               (n+2)..m TSEL                string of (up to 64) octets
            "
    SYNTAX       OCTET STRING (SIZE (1 | 4..85))

-- NBP Transport Address

IanaAddrNBPTAddress ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
            "Represents an NBP name:

                 octets        contents          encoding
                    1          length of object  'n' as an unsigned integer
                  2..(n+1)     object            string of (up to 32) octets
                   n+2         length of type    'p' as an unsigned integer
              (n+3)..(n+2+p)   type              string of (up to 32) octets
                  n+3+p        length of zone    'q' as an unsigned integer
            (n+4+p)..(n+3+p+q) zone              string of (up to 32) octets

            For comparison purposes, strings are case-insensitive. All
            strings may contain any octet other than 255 (hex ff)."
    SYNTAX       OCTET STRING (SIZE (3..99))

-- IPX Transport Address

IanaAddrIPXTTAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
    STATUS       current
    DESCRIPTION
            "Represents an IPX address:

               octets   contents            encoding
                1-4     network-number      network-byte order
                5-10    physical-address    network-byte order
               11-12    socket-number       network-byte order
            "
    SYNTAX       OCTET STRING (SIZE (12))


END

8.  Open Issues

   1) Can the TDomain and TAddress textual conventions defined
      in RFC 1903 be used to represent "generic" transport information,
      used by applications other than just SNMP?

   Proposal: While their definitions use detailed examples
   that are SNMP-specific, they may be used more widely.
   (An update to RFC1903 should modify their descriptions accordingly.)

   2) Can the IANA-ADDRESS-MIB also be used for non-transport
      addresses?  For example, can a TAddress be used to represent
      just a network-layer address?

   Proposal:  Yes, it can be used for arbitrary address domains. We
   should clarify the wordings of the TDomain and TAddress
   definition in the successor of RFC 1903 to make that clear. This
   needs to be discussed with the work currently going on to bring
   RFC 1903 to full standard status.

   3) Do we need an OID where IANA controlled MIB modules such as this
     module can be registered?  (Another such module might be
     the IANA-LANGUAGE-MIB from the DISMAN WG.)

     Proposal: Yes.  One possible node is

             iana OBJECT IDENTIFIER ::= { internet 7 }

     Whatever assignment is made, it should optimally be reflected in the
     revision of RFC 1902 which is currently being worked on.

   4) Should there be separate OID branches for network (and below) addresses,
      network+transport addresses, and applications?
      Or is some other hierarchy more useful?

      Proposal: No.

   5) If this memo prospers, what happens to the values defined in RFC1906?

9.  Acknowledgements

   Many of the definitions in this module are taken directly from [RFC1906].
   Thanks to Juergen Schoenwaelder and Mark Ellison for ideas and review to date.

10.  References

   [RFC1902]
   [RFC1903]
   [RFC1906]
   [RFC2257]
   [IPv6]
   [IANA-CONSIDERATIONS]

11.  Security Considerations

   This MIB module defines assigned values for commonly used addressing
   domains, and a set of textual conventions.  It does not define any
   MIB objects that actually contain management information.

   As such, there are no security considerations for this module.

12. 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

13.  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
   English.

   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
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Expires March, 1999