idnits 2.17.1 draft-ietf-ops-rfc2851-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 293 has weird spacing: '... octets cont...' == Line 305 has weird spacing: '... octets cont...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2001) is 8463 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '18' is defined on line 745, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (ref. '2') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '10') ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '13') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '14') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '15') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '16') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (ref. '17') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2373 (ref. '19') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2553 (ref. '20') (Obsoleted by RFC 3493) Summary: 19 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Daniele 3 Internet-Draft Compaq Computer Corporation 4 Expires: August 23, 2001 B. Haberman 5 Nortel Networks 6 S. Routhier 7 Wind River Systems, Inc. 8 J. Schoenwaelder 9 TU Braunschweig 10 February 22, 2001 12 Textual Conventions for Internet Network Addresses 13 draft-ietf-ops-rfc2851-update-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 To view the entire list of Internet-Draft Shadow Directories, see 31 http://www.ietf.org/shadow.html. 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/iid-abstracts.txt 36 This Internet-Draft will expire on August 23, 2001. 38 Copyright Notice 40 Copyright (C) The Internet Society (2001). All Rights Reserved. 42 Abstract 44 This MIB module defines textual conventions to represent commonly 45 used Internet network layer addressing information. The intent is 46 that these definitions will be imported and used in MIBs that would 47 otherwise define their own representations. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The SNMP Management Framework . . . . . . . . . . . . . . . . 4 53 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 10 55 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 11 56 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 11 57 4.3 Multiple InetAddresses per Host . . . . . . . . . . . . . . . 11 58 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 12 59 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 12 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 62 8. Intellectual Property Notice . . . . . . . . . . . . . . . . . 15 63 9. Changes from RFC 2851 . . . . . . . . . . . . . . . . . . . . 15 64 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 65 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 67 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 19 69 1. Introduction 71 Several standard-track MIB modules use the IpAddress SMIv2 base 72 type. This limits the applicability of these MIB modules to IP 73 Version 4 (IPv4) since the IpAddress SMIv2 base type can only 74 contain 4 byte IPv4 addresses. The IpAddress SMIv2 base type has 75 become problematic with the introduction of IP Version 6 (IPv6) 76 addresses [19]. 78 This document defines multiple textual conventions as a mechanism to 79 express generic Internet network layer addresses within MIB module 80 specifications. The solution is compatible with SMIv2 (STD 58) and 81 SMIv1 (STD 16). New MIB definitions which need to express network 82 layer Internet addresses SHOULD use the textual conventions defined 83 in this memo. New MIBs SHOULD NOT use the SMIv2 IpAddress base type 84 anymore. 86 A generic Internet address consists of two objects, one whose syntax 87 is InetAddressType, and another whose syntax is InetAddress. The 88 value of the first object determines how the value of the second 89 object is encoded. The InetAddress textual convention represents an 90 opaque Internet address value. The InetAddressType enumeration is 91 used to "cast" the InetAddress value into a concrete textual 92 convention for the address type. This usage of multiple textual 93 conventions allows expression of the display characteristics of each 94 address type and makes the set of defined Internet address types 95 extensible. 97 The textual conventions defined in this document can be used to 98 define Internet addresses by using DNS domain names in addition to 99 IPv4 and IPv6 addresses. A MIB designer can write compliance 100 statements to express that only a subset of the possible address 101 types must be supported by a compliant implementation. 103 MIB developers who need to represent Internet addresses SHOULD use 104 these definitions whenever applicable, as opposed to defining their 105 own constructs. Even MIBs that only need to represent IPv4 or IPv6 106 addresses SHOULD use the textual conventions defined in this memo. 108 There are many widely deployed MIBs that use IPv4 addresses and 109 which need to be revised to support IPv6. These MIBs can be 110 categorized as follows: 112 1. MIB modules which define management information that is in 113 principle IP version neutral, but the MIB currently uses 114 addressing constructs specific to a certain IP version. 115 2. MIB modules which define management information that is specific 116 to particular IP version (either IPv4 or IPv6) and which is very 117 unlikely to be ever applicable to another IP version. 119 MIB modules of the first type SHOULD provide object definitions 120 (e.g. tables) that work with all versions of IP. In particular, when 121 revising a MIB module which contains IPv4 specific tables, it is 122 suggested to define new tables using the textual conventions defined 123 in this memo which support all versions of IP. The status of the new 124 tables SHOULD be "current" while the status of the old IP version 125 specific tables SHOULD be changed to "deprecated". The other 126 approach of multiple tables for different IP versions is strongly 127 discouraged. 129 MIB modules of the second type, which are inherently IP version 130 specific, do not need to be redefined. Note that even in this case, 131 any additions to these MIB modules or new IP version specific MIB 132 modules SHOULD use the textual conventions defined in this memo. 134 MIB developers SHOULD NOT use the textual conventions defined in 135 this document to represent generic transport layer addresses. 136 Instead the SMIv2 TAddress textual convention and associated 137 definitions should be used for transport layer addresses. 139 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" 140 in this document are to be interpreted as described in RFC 2119 [1]. 142 2. The SNMP Management Framework 144 The SNMP Management Framework presently consists of five major 145 components: 146 o An overall architecture, described in RFC 2571 [2]. 147 o Mechanisms for describing and naming objects and events for the 148 purpose of management. The first version of this Structure of 149 Management Information (SMI) is called SMIv1 and described in STD 150 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The 151 second version, called SMIv2, is described in STD 58, RFC 2578 152 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. 153 o Message protocols for transferring management information. The 154 first version of the SNMP message protocol is called SNMPv1 and 155 described in STD 15, RFC 1157 [9]. A second version of the SNMP 156 message protocol, which is not an Internet standards track 157 protocol, is called SNMPv2c and described in RFC 1901 [10] and 158 RFC 1906 [11]. The third version of the message protocol is 159 called SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and 160 RFC 2574 [13]. 161 o Protocol operations for accessing management information. The 162 first set of protocol operations and associated PDU formats is 163 described in STD 15, RFC 1157 [9]. A second set of protocol 164 operations and associated PDU formats is described in RFC 1905 165 [14]. 166 o A set of fundamental applications described in RFC 2573 [15] and 167 the view-based access control mechanism described in RFC 2575 169 [16]. 170 A more detailed introduction to the current SNMP Management 171 Framework can be found in RFC 2570 [17]. 173 Managed objects are accessed via a virtual information store, termed 174 the Management Information Base or MIB. Objects in the MIB are 175 defined using the mechanisms defined in the SMI. 177 This memo specifies a MIB module that is compliant to the SMIv2. A 178 MIB conforming to the SMIv1 can be produced through the appropriate 179 translations. The resulting translated MIB must be semantically 180 equivalent, except where objects or events are omitted because no 181 translation is possible (use of Counter64). Some machine readable 182 information in SMIv2 will be converted into textual descriptions in 183 SMIv1 during the translation process. However, this loss of machine 184 readable information is not considered to change the semantics of 185 the MIB. 187 3. Definitions 189 INET-ADDRESS-MIB DEFINITIONS ::= BEGIN 191 IMPORTS 192 MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI 193 TEXTUAL-CONVENTION FROM SNMPv2-TC; 195 inetAddressMIB MODULE-IDENTITY 196 LAST-UPDATED "200102220000Z" 197 ORGANIZATION 198 "IETF Operations and Management Area" 199 CONTACT-INFO 200 "Juergen Schoenwaelder (Editor) 201 TU Braunschweig 202 Bueltenweg 74/75 203 38106 Braunschweig, Germany 205 Phone: +49 531 391-3289 206 EMail: schoenw@ibr.cs.tu-bs.de 208 Send comments to mibs@ops.ietf.org." 210 DESCRIPTION 211 "This MIB module defines textual conventions for 212 representing Internet addresses. An Internet 213 address can be an IPv4 address, an IPv6 address 214 or a DNS domain name." 216 REVISION "200102220000Z" 217 DESCRIPTION 218 "First revision, published as RFC XXXX. This revisions 219 contains several clarifications and it introduces some 220 new textual conventions: InetAddressPrefixLength, 221 InetPortNumber, and InetAutonomousSystemNumber." 223 REVISION "200006080000Z" 224 DESCRIPTION 225 "Initial version, published as RFC 2851." 226 ::= { mib-2 76 } 228 InetAddressType ::= TEXTUAL-CONVENTION 229 STATUS current 230 DESCRIPTION 231 "A value that represents a type of Internet address. 233 unknown(0) An unknown address type. This value MUST 234 be used if the value of the corresponding 235 InetAddress object is a zero-length string. 236 It may also be used to indicate an IP address 237 which is not in one of the formats defined 238 below. 240 ipv4(1) An IPv4 address as defined by the 241 InetAddressIPv4 textual convention. 243 ipv6(2) An IPv6 address as defined by the 244 InetAddressIPv6 textual convention. 246 dns(16) A DNS domain name as defined by the 247 InetAddressDNS textual convention. 249 Each definition of a concrete InetAddressType value must be 250 accompanied by a definition of a textual convention for use 251 with that InetAddressType. 253 The InetAddressType textual convention SHOULD NOT be subtyped 254 in object type definitions to support future extensions. It 255 MAY be subtyped in compliance statements in order to require 256 only a subset of these address types for a compliant 257 implementation." 258 SYNTAX INTEGER { 259 unknown(0), 260 ipv4(1), -- these named numbers are aligned 261 ipv6(2), -- with AddressFamilyNumbers from 262 dns(16) -- IANA-ADDRESS-FAMILY-NUMBERS-MIB 263 } 265 InetAddress ::= TEXTUAL-CONVENTION 266 STATUS current 267 DESCRIPTION 268 "Denotes a generic Internet address. 270 An InetAddress value is always interpreted within the 271 context of an InetAddressType value. The InetAddressType 272 object which defines the context must be registered 273 immediately before the object which uses the InetAddress 274 textual convention. In other words, the object identifiers 275 for the InetAddressType object and the InetAddress object 276 MUST have the same length and the last sub-identifier of 277 the InetAddressType object MUST be 1 less than the last 278 sub-identifier of the InetAddress object. 280 When this textual convention is used as the syntax of an 281 index object, there may be issues with the limit of 128 282 sub-identifiers specified in SMIv2, STD 58. In this case, 283 the OBJECT-TYPE declaration MUST include a 'SIZE' clause 284 to limit the number of potential instance sub-identifiers." 285 SYNTAX OCTET STRING (SIZE (0..255)) 287 InetAddressIPv4 ::= TEXTUAL-CONVENTION 288 DISPLAY-HINT "1d.1d.1d.1d" 289 STATUS current 290 DESCRIPTION 291 "Represents an IPv4 network address: 293 octets contents encoding 294 1-4 IP address network-byte order 296 The corresponding InetAddressType value is ipv4(1)." 297 SYNTAX OCTET STRING (SIZE (4)) 299 InetAddressIPv6 ::= TEXTUAL-CONVENTION 300 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 301 STATUS current 302 DESCRIPTION 303 "Represents an IPv6 network address: 305 octets contents encoding 306 1-16 IPv6 address network-byte order 307 17-20 scope identifier network-byte order 309 The corresponding InetAddressType value is ipv6(2). 311 The scope identifier (bytes 17-20) MUST NOT be present 312 for global IPv6 addresses. For non-global IPv6 addresses 313 (e.g. link-local or site-local addresses), the scope 314 identifier MUST be present if there is no other way to 315 disambiguate non-global IPv6 addresses. The scope 316 identifier contains a link identifier for link-local 317 and a site identifier for site-local IPv6 addresses. 319 The scope identifier MUST disambiguate identical address 320 values. For link-local addresses, the scope identifier will 321 typically be the interface index (ifIndex as defined in the 322 IF-MIB, RFC 2863) of the interface on which the address is 323 configured. 325 The scope identifier may contain the special value 0 326 which refers to the default scope. The default scope 327 may be used in cases where the valid scope identifier 328 is not known (e.g., a management application needs to 329 write a site-local InetAddressIPv6 address without 330 knowing the site identifier value). The default scope 331 SHOULD NOT be used as an easy way out in cases where 332 the scope identifier for a non-global IPv6 address 333 is known." 334 SYNTAX OCTET STRING (SIZE (16|20)) 336 InetAddressDNS ::= TEXTUAL-CONVENTION 337 DISPLAY-HINT "255a" 338 STATUS current 339 DESCRIPTION 340 "Represents a DNS domain name. The name SHOULD be 341 fully qualified whenever possible. 343 The corresponding InetAddressType is dns(16). 345 The DESCRIPTION clause of InetAddress objects that 346 may have InetAddressDNS values must fully describe 347 how (and when) such names are to be resolved to IP 348 addresses." 349 SYNTAX OCTET STRING (SIZE (1..255)) 351 InetAddressPrefixLength ::= TEXTUAL-CONVENTION 352 STATUS current 353 DESCRIPTION 354 "Denotes the length of a generic Internet network address 355 prefix. A value of n corresponds to an IP address mask 356 which has n contiguous 1-bits from the most significant 357 bit (MSB) and all other bits set to 0. 359 An InetAddressPrefixLength value is always interpreted 360 within the context of an InetAddressType value. The 361 InetAddressType only object or InetAddressType with 362 InetAddress objects which define the context must be 363 registered immediately before the object which uses the 364 InetAddressPrefixLength textual convention. In other 365 words, the object identifiers for the InetAddressType 366 object and the InetAddressPrefixLength object MUST 367 have the same length and the last sub-identifier of 368 the InetAddressType object MUST be 1 less than the 369 last sub-identifier of the InetAddressPrefixLength 370 object and MUST be 2 less than the last sub-identifier 371 of the InetAddressPrefixLength object if an InetAddress 372 object is defined between InetAddressType and 373 InetAddressPrefixLength objects. 375 InetAddressPrefixLength values that are larger than 376 the maximum length of an IP address for a specific 377 InetAddressType are treated as the maximum significant 378 value applicable for the InetAddressType. The maximum 379 significant value is 32 for the InetAddressType 380 'ipv4(1)' and 128 for the InetAddressType 'ipv6(2)'. 381 The maximum significant value for the InetAddressType 382 'dns(16)' is 0. 384 The value zero is object-specific and must be defined as 385 part of the description of any object which uses this 386 syntax. Examples of the usage of zero might include 387 situations where the Internet network address prefix 388 is unknown or does not apply." 389 SYNTAX Unsigned32 391 InetPortNumber ::= TEXTUAL-CONVENTION 392 STATUS current 393 DESCRIPTION 394 "Represents a 16 bit port number of an Internet transport 395 layer protocol. Port numbers are assigned by IANA. A 396 current list of all assignments is available from 397 . 399 The value zero is object-specific and must be defined as 400 part of the description of any object which uses this 401 syntax. Examples of the usage of zero might include 402 situations where a port number is unknown, or when the 403 value zero is used as a wildcard in a filter." 404 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 405 SYNTAX Unsigned32 (0..65535) 407 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 408 STATUS current 409 DESCRIPTION 410 "Represents an autonomous system number which identifies an 411 Autonomous System (AS). An AS is a set of routers under a 412 single technical administration, using an interior gateway 413 protocol and common metrics to route packets within the AS, 414 and using an exterior gateway protocol to route packets to 415 other ASs'. IANA maintains the AS number space and has 416 delegated large parts to the regional registries. 418 Autonomous system numbers are currently limited to 16 bits 419 (0..65535). There is however work in progress to enlarge the 420 autonomous system number space to 32 bits. This textual 421 convention therefore uses an Unsigned32 value without a 422 range restriction in order to support a larger autonomous 423 system number space." 424 REFERENCE "RFC 1771, RFC 1930" 425 SYNTAX Unsigned32 427 END 429 4. Usage Hints 431 One particular usage of InetAddressType/InetAddress pairs is to 432 avoid over-constraining an object definition by the use of the 433 IpAddress SMI base type. An InetAddressType/InetAddress pair allows 434 to represent IP addresses in various formats. 436 The InetAddressType and InetAddress objects SHOULD NOT be subtyped. 437 Subtyping binds the MIB module to specific address formats, which 438 may cause serious problems if new address formats need to be 439 introduced. Note that it is possible to write compliance statements 440 in order to express that only a subset of the defined address types 441 must be implemented to be compliant. 443 Internet addresses MUST always be represented by a pair of 444 InetAddressType/InetAddress objects. It is not allowed to "share" an 445 InetAddressType between multiple InetAddress objects. Furthermore, 446 the InetAddressType object must be registered immediately before the 447 InetAddress object. In other words, the object identifiers for the 448 InetAddressType object and the InetAddress object MUST have the same 449 length and the last sub-identifier of the InetAddressType object 450 MUST be 1 less than the last sub-identifier of the InetAddress 451 object. 453 4.1 Table Indexing 455 When a generic Internet address is used as an index, both the 456 InetAddressType and InetAddress objects MUST be used. The 457 InetAddressType object MUST come immediately before the InetAddress 458 object in the INDEX clause. If multiple Internet addresses are used 459 in the INDEX clause, then every Internet address must be represented 460 by a pair of InetAddressType and InetAddress objects. 462 The IMPLIED keyword MUST NOT be used for an object of type 463 InetAddress in an INDEX clause. Instance sub-identifiers are then of 464 the form T.N.O1.O2...On, where T is the value of the InetAddressType 465 object, O1...On are the octets in the InetAddress object, and N is 466 the number of those octets. 468 There is a meaningful lexicographical ordering to tables indexed in 469 this fashion. Command generator applications may lookup specific 470 addresses of known type and value, issue GetNext requests for 471 addresses of a single type, or issue GetNext requests for a specific 472 type and address prefix. 474 4.2 Uniqueness of Addresses 476 IPv4 addresses were intended to be globally unique, current usage 477 notwithstanding. IPv6 addresses were architected to have different 478 scopes and hence uniqueness [19]. In particular, IPv6 "link-local" 479 and "site-local" addresses are not guaranteed to be unique on any 480 particular node. In such cases, the duplicate addresses must be 481 configured on different interfaces. So the combination of an IPv6 482 address and an interface number is unique. The interface number may 483 therefore be used as a scope identifier. 485 The InetAddressIPv6 textual convention has been defined to represent 486 global and non-global IPv6 addresses. MIB designers who use 487 InetAddressType/InetAddress pairs therefore do not need define 488 additional objects in order to support link-local or site-local 489 addresses. 491 The size of the scope identifier has been chosen so that it matches 492 the sin6_scope_id field of the sockaddr_in6 structure defined in RFC 493 2553 [20]. 495 4.3 Multiple InetAddresses per Host 497 A single host system may be configured with multiple addresses (IPv4 498 or IPv6), and possibly with multiple DNS names. Thus it is possible 499 for a single host system to be represented by multiple 500 InetAddressType/InetAddress pairs. 502 If this could be an implementation or usage issue, then the 503 DESCRIPTION clause of the relevant objects MUST fully describe 504 required behavior. 506 4.4 Resolving DNS Names 508 DNS names must be resolved to IP addresses when communication with 509 the named host is required. This raises a temporal aspect to 510 defining MIB objects whose value is a DNS name: When is the name 511 translated to an address? 513 For example, consider an object defined to indicate a forwarding 514 destination, and whose value is a DNS name. When does the forwarding 515 entity resolve the DNS name? Each time forwarding occurs? Once, when 516 the object was instantiated? 518 The DESCRIPTION clause of such objects SHOULD precisely define how 519 and when any required name to address resolution is done. 521 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 522 define how and when a reverse lookup is being done if an agent has 523 accessed instrumentation that knows about an IP address and the MIB 524 or implementation requires to map the address to a name. 526 5. Table Indexing Example 528 This example shows a table listing communication peers that are 529 identified by either an IPv4 address, an IPv6 address or a DNS name. 530 The table definition also prohibits entries with an empty address 531 (whose type would be "unknown"). The size of a DNS name is limited 532 to 64 characters. 534 peerTable OBJECT-TYPE 535 SYNTAX SEQUENCE OF PeerEntry 536 MAX-ACCESS not-accessible 537 STATUS current 538 DESCRIPTION 539 "A list of communication peers." 540 ::= { somewhere 1 } 542 peerEntry OBJECT-TYPE 543 SYNTAX PeerEntry 544 MAX-ACCESS not-accessible 545 STATUS current 546 DESCRIPTION 547 "An entry containing information about a particular peer." 548 INDEX { peerAddressType, peerAddress } 549 ::= { peerTable 1 } 551 PeerEntry ::= SEQUENCE { 552 peerAddressType InetAddressType, 553 peerAddress InetAddress, 554 peerStatus INTEGER 555 } 557 peerAddressType OBJECT-TYPE 558 SYNTAX InetAddressType 559 MAX-ACCESS not-accessible 560 STATUS current 561 DESCRIPTION 562 "The type of Internet address by which the peer 563 is reachable." 564 ::= { peerEntry 1 } 566 peerAddress OBJECT-TYPE 567 SYNTAX InetAddress (SIZE (1..64)) 568 MAX-ACCESS not-accessible 569 STATUS current 570 DESCRIPTION 571 "The Internet address for the peer. Note that 572 implementations must limit themselves to a single 573 entry in this table per reachable peer. 575 The peerAddress may not be empty due to the SIZE 576 restriction. 578 If a row is created administratively by an SNMP 579 operation and the address type value is dns(16), then 580 the agent stores the DNS name internally. A DNS name 581 lookup must be performed on the internally stored DNS 582 name whenever it is being used to contact the peer. 584 If a row is created by the managed entity itself and 585 the address type value is dns(16), then the agent 586 stores the IP address internally. A DNS reverse lookup 587 must be performed on the internally stored IP address 588 whenever the value is retrieved via SNMP." 589 ::= { peerEntry 2 } 591 The following compliance statement specifies that implementations 592 need only support IPv4 addresses and globally unique IPv6 addresses 593 to be compliant. Support for DNS names or scoped IPv6 addresses is 594 not required. 596 peerCompliance MODULE-COMPLIANCE 597 STATUS current 598 DESCRIPTION 599 "The compliance statement the peer MIB." 601 MODULE -- this module 602 MANDATORY-GROUPS { peerGroup } 604 OBJECT peerAddressType 605 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 606 DESCRIPTION 607 "An implementation is only required to support IPv4 608 and IPv6 addresses." 610 OBJECT peerAddress 611 SYNTAX InetAddress (SIZE(4|16)) 612 DESCRIPTION 613 "An implementation is only required to support IPv4 614 and globally unique IPv6 addresses." 616 ::= { somewhere 2 } 618 Note that the SMIv2 does not permit inclusion of not-accessible 619 objects in an object group (see section 3.1 in STD 58, RFC 2580 620 [8]). It is therefore not possible to formally refine the syntax of 621 auxiliary objects which are not-accessible. In such a case, it is 622 suggested to express the refinement informally in the DESCRIPTION 623 clause of the MODULE-COMPLIANCE macro invocation. 625 6. Security Considerations 627 This module does not define any management objects. Instead, it 628 defines a set of textual conventions which may be used by other MIB 629 modules to define management objects. 631 Meaningful security considerations can only be written in the 632 modules that define management objects. 634 7. Acknowledgments 636 This document was produced by the Operations and Management Area 637 "IPv6MIB" design team. The authors would like to thank Randy Bush, 638 Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Tim 639 Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas Narten, Erik 640 Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew Smith, Dave 641 Thaler, Kenneth White, Bert Wijnen, and Brian Zill for their 642 comments and suggestions. 644 8. Intellectual Property Notice 646 The IETF takes no position regarding the validity or scope of any 647 intellectual property or other rights that might be claimed to 648 pertain to the implementation or use of the technology described in 649 this document or the extent to which any license under such rights 650 might or might not be available; neither does it represent that it 651 has made any effort to identify any such rights. Information on the 652 IETF's procedures with respect to rights in standards-track and 653 standards-related documentation can be found in BCP-11. Copies of 654 claims of rights made available for publication and any assurances 655 of licenses to be made available, or the result of an attempt made 656 to obtain a general license or permission for the use of such 657 propritary rights by implementors or users of this specification can 658 be obtained from the IETF Secretariat. 660 The IETF invites any interested party to bring to its attention any 661 copyrights, patents or patent applications, or other proprietary 662 rights which may cover technology that may be required to practice 663 this standard. Please address the information to the IETF Executive 664 Director. 666 9. Changes from RFC 2851 668 The following changes have been made relative to RFC 2851: 669 o Added new TCs: InetAddressPrefixLength, InetPortNumber, 670 InetAutonomousSystemNumber 671 o Rewrote the introduction to say clearly that in general, one 672 should define MIB tables that work with all versions of IP. The 673 other approach of multiple tables for different IP versions is 674 strongly discouraged. (kzm) 676 10. Open Issues 678 o Shall we define an InetProtocolNumber TC, similar to the 679 InetPortNumber TC? 681 References 683 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 684 Levels", BCP 14, RFC 2119, March 1997. 686 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 687 Describing SNMP Management Frameworks", RFC 2571, April 1999. 689 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 690 Management Information for TCP/IP-based Internets", STD 16, RFC 691 1155, May 1990. 693 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 694 RFC 1212, March 1991. 696 [5] Rose, M., "A Convention for Defining Traps for use with the 697 SNMP", RFC 1215, March 1991. 699 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 700 M. and S. Waldbusser, "Structure of Management Information 701 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 703 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 704 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 705 RFC 2579, April 1999. 707 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 708 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 709 58, RFC 2580, April 1999. 711 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 712 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. 714 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 715 "Introduction to Community-based SNMPv2", RFC 1901, January 716 1996. 718 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 719 "Transport Mappings for Version 2 of the Simple Network 720 Management Protocol (SNMPv2)", RFC 1906, January 1996. 722 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 723 Processing and Dispatching for the Simple Network Management 724 Protocol (SNMP)", RFC 2572, April 1999. 726 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 727 for version 3 of the Simple Network Management Protocol 728 (SNMPv3)", RFC 2574, April 1999. 730 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 731 "Protocol Operations for Version 2 of the Simple Network 732 Management Protocol (SNMPv2)", RFC 1905, January 1996. 734 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 735 2573, April 1999. 737 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 738 Control Model (VACM) for the Simple Network Management 739 Protocol (SNMP)", RFC 2575, April 1999. 741 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 742 to Version 3 of the Internet-standard Network Management 743 Framework", RFC 2570, April 1999. 745 [18] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 746 RFC 2863, June 2000. 748 [19] Hinden, R. and S. Deering, "IP Version 6 Addressing 749 Architecture", RFC 2373, July 1998. 751 [20] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 752 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 754 Authors' Addresses 756 Mike Daniele 757 Compaq Computer Corporation 758 110 Spit Brook Rd 759 Nashua, NH 03062 760 USA 762 Phone: +1 603 884-1423 763 EMail: daniele@zk3.dec.com 765 Brian Haberman 766 Nortel Networks 767 4039 Emperor Blvd., Suite 200 768 Durham, NC 27703 769 USA 771 Phone: +1 919 992-4439 772 EMail: haberman@nortelnetworks.com 774 Shawn A. Routhier 775 Wind River Systems, Inc. 776 1 Tara Blvd, Suite 403 777 Nashua, NH 03062 778 USA 780 Phone: +1 603 897-2000 781 EMail: sar@epilogue.com 782 Juergen Schoenwaelder 783 TU Braunschweig 784 Bueltenweg 74/75 785 38106 Braunschweig 786 Germany 788 Phone: +49 531 391-3289 789 EMail: schoenw@ibr.cs.tu-bs.de 791 Full Copyright Statement 793 Copyright (C) The Internet Society (2001). All Rights Reserved. 795 This document and translations of it may be copied and furnished to 796 others, and derivative works that comment on or otherwise explain it 797 or assist in its implementation may be prepared, copied, published 798 and distributed, in whole or in part, without restriction of any 799 kind, provided that the above copyright notice and this paragraph 800 are included on all such copies and derivative works. However, this 801 document itself may not be modified in any way, such as by removing 802 the copyright notice or references to the Internet Society or other 803 Internet organizations, except as needed for the purpose of 804 developing Internet standards in which case the procedures for 805 copyrights defined in the Internet Standards process must be 806 followed, or as required to translate it into languages other than 807 English. 809 The limited permissions granted above are perpetual and will not be 810 revoked by the Internet Society or its successors or assigns. 812 This document and the information contained herein is provided on an 813 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 814 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 815 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 816 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 817 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 819 Acknowledgement 821 Funding for the RFC Editor function is currently provided by the 822 Internet Society.