Internet-Draft IANA Address MIB September 1998 Expires March, 1999 IANA Address MIB 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