Internet DRAFT - draft-daniele-iana-addr-mib
draft-daniele-iana-addr-mib
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
