idnits 2.17.1 draft-ietf-ops-rfc2851-update-01.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: ---------------------------------------------------------------------------- == 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 are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The abstract seems to indicate that this document obsoletes RFC2851, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 330 has weird spacing: '... octets cont...' == Line 342 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 792, 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: 17 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Daniele 3 Internet-Draft Consultant 4 Expires: December 30, 2001 B. Haberman 5 Nortel Networks 6 S. Routhier 7 Wind River Systems, Inc. 8 J. Schoenwaelder 9 TU Braunschweig 10 July 2001 12 Textual Conventions for Internet Network Addresses 13 draft-ietf-ops-rfc2851-update-01.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 Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 30, 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 textual conventions will be imported and used in MIB 47 modules that would otherwise define their own representations. 49 This document obsoletes RFC 2851. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. The SNMP Management Framework . . . . . . . . . . . . . . . . 4 55 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 11 58 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 11 59 4.3 Multiple InetAddresses per Host . . . . . . . . . . . . . . . 12 60 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 12 61 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 13 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 64 8. Intellectual Property Notice . . . . . . . . . . . . . . . . . 15 65 9. Changes from RFC 2851 . . . . . . . . . . . . . . . . . . . . 16 66 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 71 1. Introduction 73 Several standard-track MIB modules use the IpAddress SMIv2 base type. 74 This limits the applicability of these MIB modules to IP Version 4 75 (IPv4) since the IpAddress SMIv2 base type can only contain 4 byte 76 IPv4 addresses. The IpAddress SMIv2 base type has become problematic 77 with the introduction of IP Version 6 (IPv6) addresses [19]. 79 This document defines multiple textual conventions as a mechanism to 80 express generic Internet network layer addresses within MIB module 81 specifications. The solution is compatible with SMIv2 (STD 58) and 82 SMIv1 (STD 16). New MIB definitions which need to express network 83 layer Internet addresses SHOULD use the textual conventions defined 84 in this memo. New MIB modules SHOULD NOT use the SMIv2 IpAddress 85 base type anymore. 87 A generic Internet address consists of two objects, one whose syntax 88 is InetAddressType, and another whose syntax is InetAddress. The 89 value of the first object determines how the value of the second 90 object is encoded. The InetAddress textual convention represents an 91 opaque Internet address value. The InetAddressType enumeration is 92 used to "cast" the InetAddress value into a concrete textual 93 convention for the address type. This usage of multiple textual 94 conventions allows expression of the display characteristics of each 95 address type and makes the set of defined Internet address types 96 extensible. 98 The textual conventions defined in this document can be used to 99 define Internet addresses by using DNS domain names in addition to 100 IPv4 and IPv6 addresses. A MIB designer can write compliance 101 statements to express that only a subset of the possible address 102 types must be supported by a compliant implementation. 104 MIB developers who need to represent Internet addresses SHOULD use 105 these definitions whenever applicable, as opposed to defining their 106 own constructs. Even MIB modules that only need to represent IPv4 or 107 IPv6 addresses SHOULD use the textual conventions defined in this 108 memo. 110 There are many widely deployed MIB modules that use IPv4 addresses 111 and which need to be revised to support IPv6. These MIBs can be 112 categorized as follows: 114 1. MIB modules which define management information that is in 115 principle IP version neutral, but the MIB currently uses 116 addressing constructs specific to a certain IP version. 118 2. MIB modules which define management information that is specific 119 to particular IP version (either IPv4 or IPv6) and which is very 120 unlikely to be ever applicable to another IP version. 122 MIB modules of the first type SHOULD provide object definitions (e.g. 123 tables) that work with all versions of IP. In particular, when 124 revising a MIB module which contains IPv4 specific tables, it is 125 suggested to define new tables using the textual conventions defined 126 in this memo which support all versions of IP. The status of the new 127 tables SHOULD be "current" while the status of the old IP version 128 specific tables SHOULD be changed to "deprecated". The other 129 approach of having multiple similar tables for different IP versions 130 is strongly discouraged. 132 MIB modules of the second type, which are inherently IP version 133 specific, do not need to be redefined. Note that even in this case, 134 any additions to these MIB modules or new IP version specific MIB 135 modules SHOULD use the textual conventions defined in this memo. 137 MIB developers SHOULD NOT use the textual conventions defined in this 138 document to represent generic transport layer addresses. Instead the 139 SMIv2 TAddress textual convention and associated definitions should 140 be used for transport layer addresses. 142 This memo introduces some ordering constraints in order to achieve 143 the following two goals: 145 1. Enable programs to identify the InetAddressType object which 146 discriminates a certain InetAddress object. This allows tools 147 such as MIB compilers to understand the dependencies and to 148 generate code to e.g. handle some error conditions. 150 2. Provide some rules that prevent MIB module authors from doing 151 certain mistakes which can make future extensions of tables with 152 new objects impossible. 154 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 155 this document are to be interpreted as described in RFC 2119 [1]. 157 2. The SNMP Management Framework 159 The SNMP Management Framework presently consists of five major 160 components: 162 o An overall architecture, described in RFC 2571 [2]. 164 o Mechanisms for describing and naming objects and events for the 165 purpose of management. The first version of this Structure of 166 Management Information (SMI) is called SMIv1 and described in STD 167 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The 168 second version, called SMIv2, is described in STD 58, RFC 2578 169 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. 171 o Message protocols for transferring management information. The 172 first version of the SNMP message protocol is called SNMPv1 and 173 described in STD 15, RFC 1157 [9]. A second version of the SNMP 174 message protocol, which is not an Internet standards track 175 protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 176 1906 [11]. The third version of the message protocol is called 177 SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 178 [13]. 180 o Protocol operations for accessing management information. The 181 first set of protocol operations and associated PDU formats is 182 described in STD 15, RFC 1157 [9]. A second set of protocol 183 operations and associated PDU formats is described in RFC 1905 184 [14]. 186 o A set of fundamental applications described in RFC 2573 [15] and 187 the view-based access control mechanism described in RFC 2575 188 [16]. 190 A more detailed introduction to the current SNMP Management Framework 191 can be found in RFC 2570 [17]. 193 Managed objects are accessed via a virtual information store, termed 194 the Management Information Base or MIB. Objects in the MIB are 195 defined using the mechanisms defined in the SMI. 197 This memo specifies a MIB module that is compliant to the SMIv2. A 198 MIB conforming to the SMIv1 can be produced through the appropriate 199 translations. The resulting translated MIB must be semantically 200 equivalent, except where objects or events are omitted because no 201 translation is possible (use of Counter64). Some machine readable 202 information in SMIv2 will be converted into textual descriptions in 203 SMIv1 during the translation process. However, this loss of machine 204 readable information is not considered to change the semantics of the 205 MIB. 207 3. Definitions 209 INET-ADDRESS-MIB DEFINITIONS ::= BEGIN 211 IMPORTS 212 MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI 213 TEXTUAL-CONVENTION FROM SNMPv2-TC; 215 inetAddressMIB MODULE-IDENTITY 216 LAST-UPDATED "200107130000Z" 217 ORGANIZATION 218 "IETF Operations and Management Area" 219 CONTACT-INFO 220 "Juergen Schoenwaelder (Editor) 221 TU Braunschweig 222 Bueltenweg 74/75 223 38106 Braunschweig, Germany 225 Phone: +49 531 391-3289 226 EMail: schoenw@ibr.cs.tu-bs.de 228 Send comments to ." 230 DESCRIPTION 231 "This MIB module defines textual conventions for 232 representing Internet addresses. An Internet 233 address can be an IPv4 address, an IPv6 address 234 or a DNS domain name." 236 REVISION "200107130000Z" 237 DESCRIPTION 238 "Second version, published as RFC XXXX. This 239 revisions contains several clarifications and it 240 introduces some new textual conventions: 241 InetAddressPrefixLength, InetPortNumber, and 242 InetAutonomousSystemNumber." 244 REVISION "200006080000Z" 245 DESCRIPTION 246 "Initial version, published as RFC 2851." 247 ::= { mib-2 76 } 249 InetAddressType ::= TEXTUAL-CONVENTION 250 STATUS current 251 DESCRIPTION 252 "A value that represents a type of Internet address. 254 unknown(0) An unknown address type. This value MUST 255 be used if the value of the corresponding 256 InetAddress object is a zero-length string. 257 It may also be used to indicate an IP address 258 which is not in one of the formats defined 259 below. 261 ipv4(1) An IPv4 address as defined by the 262 InetAddressIPv4 textual convention. 264 ipv6(2) An IPv6 address as defined by the 265 InetAddressIPv6 textual convention. 267 dns(16) A DNS domain name as defined by the 268 InetAddressDNS textual convention. 270 Each definition of a concrete InetAddressType value must be 271 accompanied by a definition of a textual convention for use 272 with that InetAddressType. 274 The InetAddressType textual convention SHOULD NOT be sub-typed 275 in object type definitions to support future extensions. It 276 MAY be sub-typed in compliance statements in order to require 277 only a subset of these address types for a compliant 278 implementation. 280 Implementations must ensure that InetAddressType objects 281 and any dependent objects (e.g. InetAddress objects) are 282 consistent. An inconsistentValue error must be generated 283 if an attempt to change an InetAddressType object would, 284 for example, lead to an undefined InetAddress value. In 285 particular, InetAddressType/InetAddress pairs must be 286 changed together if the address type changes (e.g. from 287 ipv6(2) to ipv4(1))." 288 SYNTAX INTEGER { 289 unknown(0), 290 ipv4(1), -- these named numbers are aligned 291 ipv6(2), -- with AddressFamilyNumbers from 292 dns(16) -- IANA-ADDRESS-FAMILY-NUMBERS-MIB 293 } 295 InetAddress ::= TEXTUAL-CONVENTION 296 STATUS current 297 DESCRIPTION 298 "Denotes a generic Internet address. 300 An InetAddress value is always interpreted within the 301 context of an InetAddressType value. The InetAddressType 302 object which defines the the format of the InetAddress 303 value MUST be registered immediately before the object(s) 304 which use the InetAddress textual convention. 306 In other words, an (InetAddressType, InetAddress) tuple 307 must be registered in exactly this order while and 308 (InetAddressType, InetAddress, InetAddress) triple 309 must be registered in exactly this order. 311 The value of an InetAddress object must always be 312 consistent with the value of the associated InetAddressType 313 object. Attempts to set an InetAddress object to a value 314 which is inconsistent with the associated InetAddressType 315 must fail with an inconsistentValue error. 317 When this textual convention is used as the syntax of an 318 index object, there may be issues with the limit of 128 319 sub-identifiers specified in SMIv2, STD 58. In this case, 320 the OBJECT-TYPE declaration MUST include a 'SIZE' clause 321 to limit the number of potential instance sub-identifiers." 322 SYNTAX OCTET STRING (SIZE (0..255)) 324 InetAddressIPv4 ::= TEXTUAL-CONVENTION 325 DISPLAY-HINT "1d.1d.1d.1d" 326 STATUS current 327 DESCRIPTION 328 "Represents an IPv4 network address: 330 octets contents encoding 331 1-4 IP address network-byte order 333 The corresponding InetAddressType value is ipv4(1)." 334 SYNTAX OCTET STRING (SIZE (4)) 336 InetAddressIPv6 ::= TEXTUAL-CONVENTION 337 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 338 STATUS current 339 DESCRIPTION 340 "Represents an IPv6 network address: 342 octets contents encoding 343 1-16 IPv6 address network-byte order 344 17-20 scope identifier network-byte order 346 The corresponding InetAddressType value is ipv6(2). 348 The scope identifier (bytes 17-20) MUST NOT be present 349 for global IPv6 addresses. For non-global IPv6 addresses 350 (e.g. link-local or site-local addresses), the scope 351 identifier MUST be present if there is no other way to 352 disambiguate non-global IPv6 addresses. The scope 353 identifier contains a link identifier for link-local 354 and a site identifier for site-local IPv6 addresses. 356 The scope identifier MUST disambiguate identical address 357 values. For link-local addresses, the scope identifier 358 will typically be the interface index (ifIndex as defined 359 in the IF-MIB, RFC 2863) of the interface on which the 360 address is configured. 362 The scope identifier may contain the special value 0 363 which refers to the default scope. The default scope 364 may be used in cases where the valid scope identifier 365 is not known (e.g., a management application needs to 366 write a site-local InetAddressIPv6 address without 367 knowing the site identifier value). The default scope 368 SHOULD NOT be used as an easy way out in cases where 369 the scope identifier for a non-global IPv6 address 370 is known." 371 SYNTAX OCTET STRING (SIZE (16|20)) 373 InetAddressDNS ::= TEXTUAL-CONVENTION 374 DISPLAY-HINT "255a" 375 STATUS current 376 DESCRIPTION 377 "Represents a DNS domain name. The name SHOULD be 378 fully qualified whenever possible. 380 The corresponding InetAddressType is dns(16). 382 The DESCRIPTION clause of InetAddress objects that 383 may have InetAddressDNS values must fully describe 384 how (and when) such names are to be resolved to IP 385 addresses." 386 SYNTAX OCTET STRING (SIZE (1..255)) 388 InetAddressPrefixLength ::= TEXTUAL-CONVENTION 389 STATUS current 390 DESCRIPTION 391 "Denotes the length of a generic Internet network address 392 prefix. A value of n corresponds to an IP address mask 393 which has n contiguous 1-bits from the most significant 394 bit (MSB) and all other bits set to 0. 396 An InetAddressPrefixLength value is always interpreted 397 within the context of an InetAddressType value. The 398 InetAddressType object must be registered before the 399 object which uses the InetAddressPrefixLength textual 400 convention. 402 InetAddressPrefixLength values that are larger than 403 the maximum length of an IP address for a specific 404 InetAddressType are treated as the maximum significant 405 value applicable for the InetAddressType. The maximum 406 significant value is 32 for the InetAddressType 407 'ipv4(1)' and 128 for the InetAddressType 'ipv6(2)'. 409 The maximum significant value for the InetAddressType 410 'dns(16)' is 0. 412 The value zero is object-specific and must be defined as 413 part of the description of any object which uses this 414 syntax. Examples of the usage of zero might include 415 situations where the Internet network address prefix 416 is unknown or does not apply." 417 SYNTAX Unsigned32 419 InetPortNumber ::= TEXTUAL-CONVENTION 420 STATUS current 421 DESCRIPTION 422 "Represents a 16 bit port number of an Internet transport 423 layer protocol. Port numbers are assigned by IANA. A 424 current list of all assignments is available from 425 . 427 The value zero is object-specific and must be defined as 428 part of the description of any object which uses this 429 syntax. Examples of the usage of zero might include 430 situations where a port number is unknown, or when the 431 value zero is used as a wildcard in a filter." 432 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 433 SYNTAX Unsigned32 (0..65535) 435 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 436 STATUS current 437 DESCRIPTION 438 "Represents an autonomous system number which identifies an 439 Autonomous System (AS). An AS is a set of routers under a 440 single technical administration, using an interior gateway 441 protocol and common metrics to route packets within the AS, 442 and using an exterior gateway protocol to route packets to 443 other ASs'. IANA maintains the AS number space and has 444 delegated large parts to the regional registries. 446 Autonomous system numbers are currently limited to 16 bits 447 (0..65535). There is however work in progress to enlarge the 448 autonomous system number space to 32 bits. This textual 449 convention therefore uses an Unsigned32 value without a 450 range restriction in order to support a larger autonomous 451 system number space." 452 REFERENCE "RFC 1771, RFC 1930" 453 SYNTAX Unsigned32 455 END 457 4. Usage Hints 459 One particular usage of InetAddressType/InetAddress pairs is to avoid 460 over-constraining an object definition by the use of the IpAddress 461 SMI base type. An InetAddressType/InetAddress pair allows to 462 represent IP addresses in various formats. 464 The InetAddressType and InetAddress objects SHOULD NOT be sub-typed. 465 Sub-typing binds the MIB module to specific address formats, which 466 may cause serious problems if new address formats need to be 467 introduced. Note that it is possible to write compliance statements 468 in order to express that only a subset of the defined address types 469 must be implemented to be compliant. 471 The InetAddressType object must be registered immediately before the 472 InetAddress object(s) or InetAddressPrefixLength object(s). In other 473 words, the object identifiers for the InetAddressType object and the 474 InetAddress object MUST have the same length and the last sub- 475 identifier of the InetAddressType object MUST be less than the last 476 sub-identifier of the InetAddress object. This rule allows programs 477 such as MIB compilers to identify the InetAddressType of a given 478 InetAddress or InetAddressPrefixLength object by searching for the 479 InetAddressType object which precedes InetAddress or 480 InetAddressPrefixLength registration. 482 4.1 Table Indexing 484 When a generic Internet address is used as an index, both the 485 InetAddressType and InetAddress objects MUST be used. The 486 InetAddressType object MUST be listed immediately before the 487 InetAddress object in the INDEX clause. 489 The IMPLIED keyword MUST NOT be used for an object of type 490 InetAddress in an INDEX clause. Instance sub-identifiers are then of 491 the form T.N.O1.O2...On, where T is the value of the InetAddressType 492 object, O1...On are the octets in the InetAddress object, and N is 493 the number of those octets. 495 There is a meaningful lexicographical ordering to tables indexed in 496 this fashion. Command generator applications may lookup specific 497 addresses of known type and value, issue GetNext requests for 498 addresses of a single type, or issue GetNext requests for a specific 499 type and address prefix. 501 4.2 Uniqueness of Addresses 503 IPv4 addresses were intended to be globally unique, current usage 504 notwithstanding. IPv6 addresses were architected to have different 505 scopes and hence uniqueness [19]. In particular, IPv6 "link-local" 506 and "site-local" addresses are not guaranteed to be unique on any 507 particular node. In such cases, the duplicate addresses must be 508 configured on different interfaces. So the combination of an IPv6 509 address and an interface number is unique. The interface number may 510 therefore be used as a scope identifier. 512 The InetAddressIPv6 textual convention has been defined to represent 513 global and non-global IPv6 addresses. MIB designers who use 514 InetAddressType/InetAddress pairs therefore do not need define 515 additional objects in order to support link-local or site-local 516 addresses. 518 The size of the scope identifier has been chosen so that it matches 519 the sin6_scope_id field of the sockaddr_in6 structure defined in RFC 520 2553 [20]. 522 4.3 Multiple InetAddresses per Host 524 A single host system may be configured with multiple addresses (IPv4 525 or IPv6), and possibly with multiple DNS names. Thus it is possible 526 for a single host system to be accessible by multiple 527 InetAddressType/InetAddress pairs. 529 If this could be an implementation or usage issue, then the 530 DESCRIPTION clause of the relevant objects MUST fully describe 531 required behavior. 533 4.4 Resolving DNS Names 535 DNS names must be resolved to IP addresses when communication with 536 the named host is required. This raises a temporal aspect to 537 defining MIB objects whose value is a DNS name: When is the name 538 translated to an address? 540 For example, consider an object defined to indicate a forwarding 541 destination, and whose value is a DNS name. When does the forwarding 542 entity resolve the DNS name? Each time forwarding occurs or just once 543 when the object was instantiated? 545 The DESCRIPTION clause of such objects SHOULD precisely define how 546 and when any required name to address resolution is done. 548 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 549 define how and when a reverse lookup is being done if an agent has 550 accessed instrumentation that knows about an IP address and the MIB 551 module or implementation requires to map the IP address to a DNS 552 name. 554 5. Table Indexing Example 556 This example shows a table listing communication peers that are 557 identified by either an IPv4 address, an IPv6 address or a DNS name. 558 The table definition also prohibits entries with an empty address 559 (whose type would be "unknown"). The size of a DNS name is limited 560 to 64 characters. 562 peerTable OBJECT-TYPE 563 SYNTAX SEQUENCE OF PeerEntry 564 MAX-ACCESS not-accessible 565 STATUS current 566 DESCRIPTION 567 "A list of communication peers." 568 ::= { somewhere 1 } 570 peerEntry OBJECT-TYPE 571 SYNTAX PeerEntry 572 MAX-ACCESS not-accessible 573 STATUS current 574 DESCRIPTION 575 "An entry containing information about a particular peer." 576 INDEX { peerAddressType, peerAddress } 577 ::= { peerTable 1 } 579 PeerEntry ::= SEQUENCE { 580 peerAddressType InetAddressType, 581 peerAddress InetAddress, 582 peerStatus INTEGER 583 } 585 peerAddressType OBJECT-TYPE 586 SYNTAX InetAddressType 587 MAX-ACCESS not-accessible 588 STATUS current 589 DESCRIPTION 590 "The type of Internet address by which the peer 591 is reachable." 592 ::= { peerEntry 1 } 594 peerAddress OBJECT-TYPE 595 SYNTAX InetAddress (SIZE (1..64)) 596 MAX-ACCESS not-accessible 597 STATUS current 598 DESCRIPTION 599 "The Internet address for the peer. Note that 600 implementations must limit themselves to a single 601 entry in this table per reachable peer. 603 The peerAddress may not be empty due to the SIZE 604 restriction. 606 If a row is created administratively by an SNMP 607 operation and the address type value is dns(16), then 608 the agent stores the DNS name internally. A DNS name 609 lookup must be performed on the internally stored DNS 610 name whenever it is being used to contact the peer. 612 If a row is created by the managed entity itself and 613 the address type value is dns(16), then the agent 614 stores the IP address internally. A DNS reverse lookup 615 must be performed on the internally stored IP address 616 whenever the value is retrieved via SNMP." 617 ::= { peerEntry 2 } 619 The following compliance statement specifies that implementations 620 need only support IPv4 addresses and globally unique IPv6 addresses 621 to be compliant. Support for DNS names or scoped IPv6 addresses is 622 not required. 624 peerCompliance MODULE-COMPLIANCE 625 STATUS current 626 DESCRIPTION 627 "The compliance statement the peer MIB." 629 MODULE -- this module 630 MANDATORY-GROUPS { peerGroup } 632 OBJECT peerAddressType 633 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 634 DESCRIPTION 635 "An implementation is only required to support IPv4 636 and IPv6 addresses." 638 OBJECT peerAddress 639 SYNTAX InetAddress (SIZE(4|16)) 640 DESCRIPTION 641 "An implementation is only required to support IPv4 642 and globally unique IPv6 addresses." 644 ::= { somewhere 2 } 646 Note that the SMIv2 does not permit inclusion of not-accessible 647 objects in an object group (see section 3.1 in STD 58, RFC 2580 [8]). 649 It is therefore not possible to formally refine the syntax of 650 auxiliary objects which are not-accessible. In such a case, it is 651 suggested to express the refinement informally in the DESCRIPTION 652 clause of the MODULE-COMPLIANCE macro invocation. 654 6. Security Considerations 656 This module does not define any management objects. Instead, it 657 defines a set of textual conventions which may be used by other MIB 658 modules to define management objects. 660 Meaningful security considerations can only be written in the MIB 661 modules that define management objects. This document has therefore 662 no impact on the security of the Internet. 664 7. Acknowledgments 666 This document was produced by the Operations and Management Area 667 "IPv6MIB" design team. The authors would like to thank Fred Baker, 668 Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro 669 Hagino, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas 670 Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew 671 Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill for 672 their comments and suggestions. 674 8. Intellectual Property Notice 676 The IETF takes no position regarding the validity or scope of any 677 intellectual property or other rights that might be claimed to 678 pertain to the implementation or use of the technology described in 679 this document or the extent to which any license under such rights 680 might or might not be available; neither does it represent that it 681 has made any effort to identify any such rights. Information on the 682 IETF's procedures with respect to rights in standards-track and 683 standards-related documentation can be found in BCP-11. Copies of 684 claims of rights made available for publication and any assurances of 685 licenses to be made available, or the result of an attempt made to 686 obtain a general license or permission for the use of such 687 proprietary rights by implementors or users of this specification can 688 be obtained from the IETF Secretariat. 690 The IETF invites any interested party to bring to its attention any 691 copyrights, patents or patent applications, or other proprietary 692 rights which may cover technology that may be required to practice 693 this standard. Please address the information to the IETF Executive 694 Director. 696 9. Changes from RFC 2851 698 The following changes have been made relative to RFC 2851: 700 o Added new TCs: InetAddressPrefixLength, InetPortNumber, 701 InetAutonomousSystemNumber 703 o Rewrote the introduction to say clearly that in general, one 704 should define MIB tables that work with all versions of IP. The 705 other approach of multiple tables for different IP versions is 706 strongly discouraged. (kzm) 708 o Added text to the InetAddressType and InetAddress descriptions 709 which requires that implementations must reject set operations 710 with an inconsistentValue error if they lead to inconsistencies. 712 o Relaxed the rules to make it possible to register tuples where 713 multiple objects share an InetAddressType value, which is needed 714 for filters of the form (InetAddressType, InetAddress, 715 InetPortNumber, InetAddress InetPortNumber). 717 o Added a paragraph in the Introduction which explains the 718 motivation for the ordering constraints. 720 10. Open Issues 722 o Check that the document is consistent with draft-ietf-ipngwg- 723 scoping-arch-02.txt and add a reference to it. 725 o Addition of an InetScopeIdentifier TC? (Bill Fenner) 727 References 729 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 730 Levels", BCP 14, RFC 2119, March 1997. 732 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 733 Describing SNMP Management Frameworks", RFC 2571, April 1999. 735 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 736 Management Information for TCP/IP-based Internets", STD 16, RFC 737 1155, May 1990. 739 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 740 RFC 1212, March 1991. 742 [5] Rose, M., "A Convention for Defining Traps for use with the 743 SNMP", RFC 1215, March 1991. 745 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 746 M. and S. Waldbusser, "Structure of Management Information 747 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 749 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 750 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 751 RFC 2579, April 1999. 753 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 754 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 755 58, RFC 2580, April 1999. 757 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 758 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 759 1990. 761 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 762 "Introduction to Community-based SNMPv2", RFC 1901, January 763 1996. 765 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 766 "Transport Mappings for Version 2 of the Simple Network 767 Management Protocol (SNMPv2)", RFC 1906, January 1996. 769 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 770 Processing and Dispatching for the Simple Network Management 771 Protocol (SNMP)", RFC 2572, April 1999. 773 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 774 for version 3 of the Simple Network Management Protocol 775 (SNMPv3)", RFC 2574, April 1999. 777 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol 778 Operations for Version 2 of the Simple Network Management 779 Protocol (SNMPv2)", RFC 1905, January 1996. 781 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 782 2573, April 1999. 784 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 785 Control Model (VACM) for the Simple Network Management Protocol 786 (SNMP)", RFC 2575, April 1999. 788 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 789 to Version 3 of the Internet-standard Network Management 790 Framework", RFC 2570, April 1999. 792 [18] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 793 RFC 2863, June 2000. 795 [19] Hinden, R. and S. Deering, "IP Version 6 Addressing 796 Architecture", RFC 2373, July 1998. 798 [20] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 799 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 801 Authors' Addresses 803 Mike Daniele 804 Consultant 805 19 Pinewood Rd 806 Hudson, NH 03051 807 USA 809 Phone: +1 603 883-6365 810 EMail: mwdaniele@adelphia.net 812 Brian Haberman 813 Nortel Networks 814 4039 Emperor Blvd., Suite 200 815 Durham, NC 27703 816 USA 818 Phone: +1 919 992-4439 819 EMail: haberman@nortelnetworks.com 821 Shawn A. Routhier 822 Wind River Systems, Inc. 823 1 Tara Blvd, Suite 403 824 Nashua, NH 03062 825 USA 827 Phone: +1 603 897-2000 828 EMail: sar@epilogue.com 829 Juergen Schoenwaelder 830 TU Braunschweig 831 Bueltenweg 74/75 832 38106 Braunschweig 833 Germany 835 Phone: +49 531 391-3289 836 EMail: schoenw@ibr.cs.tu-bs.de 838 Full Copyright Statement 840 Copyright (C) The Internet Society (2001). All Rights Reserved. 842 This document and translations of it may be copied and furnished to 843 others, and derivative works that comment on or otherwise explain it 844 or assist in its implementation may be prepared, copied, published 845 and distributed, in whole or in part, without restriction of any 846 kind, provided that the above copyright notice and this paragraph are 847 included on all such copies and derivative works. However, this 848 document itself may not be modified in any way, such as by removing 849 the copyright notice or references to the Internet Society or other 850 Internet organizations, except as needed for the purpose of 851 developing Internet standards in which case the procedures for 852 copyrights defined in the Internet Standards process must be 853 followed, or as required to translate it into languages other than 854 English. 856 The limited permissions granted above are perpetual and will not be 857 revoked by the Internet Society or its successors or assigns. 859 This document and the information contained herein is provided on an 860 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 861 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 862 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 863 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 864 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 866 Acknowledgement 868 Funding for the RFC Editor function is currently provided by the 869 Internet Society.