idnits 2.17.1 draft-ietf-ops-rfc2851-update-02.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 325 has weird spacing: '... octets cont...' == Line 337 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 (August 23, 2001) is 8282 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 787, 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: February 21, 2002 B. Haberman 5 Nortel Networks 6 S. Routhier 7 Wind River Systems, Inc. 8 J. Schoenwaelder 9 TU Braunschweig 10 August 23, 2001 12 Textual Conventions for Internet Network Addresses 13 draft-ietf-ops-rfc2851-update-02.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 February 21, 2002. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 12 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 64 8. Intellectual Property Notice . . . . . . . . . . . . . . . . . 15 65 9. Changes from RFC 2851 . . . . . . . . . . . . . . . . . . . . 15 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 format of the InetAddress 303 value MUST be registered before the object(s) which use 304 the InetAddress textual convention. 306 The value of an InetAddress object must always be 307 consistent with the value of the associated InetAddressType 308 object. Attempts to set an InetAddress object to a value 309 which is inconsistent with the associated InetAddressType 310 must fail with an inconsistentValue error. 312 When this textual convention is used as the syntax of an 313 index object, there may be issues with the limit of 128 314 sub-identifiers specified in SMIv2, STD 58. In this case, 315 the OBJECT-TYPE declaration MUST include a 'SIZE' clause 316 to limit the number of potential instance sub-identifiers." 317 SYNTAX OCTET STRING (SIZE (0..255)) 319 InetAddressIPv4 ::= TEXTUAL-CONVENTION 320 DISPLAY-HINT "1d.1d.1d.1d" 321 STATUS current 322 DESCRIPTION 323 "Represents an IPv4 network address: 325 octets contents encoding 326 1-4 IPv4 address network-byte order 328 The corresponding InetAddressType value is ipv4(1)." 329 SYNTAX OCTET STRING (SIZE (4)) 331 InetAddressIPv6 ::= TEXTUAL-CONVENTION 332 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 333 STATUS current 334 DESCRIPTION 335 "Represents an IPv6 network address: 337 octets contents encoding 338 1-16 IPv6 address network-byte order 339 17-20 scope identifier network-byte order 341 The corresponding InetAddressType value is ipv6(2). 343 The scope identifier (bytes 17-20) MUST NOT be present 344 for global IPv6 addresses. For non-global IPv6 addresses 345 (e.g. link-local or site-local addresses), the scope 346 identifier MUST be present if there is no other way to 347 disambiguate non-global IPv6 addresses. The scope 348 identifier contains a link identifier for link-local 349 and a site identifier for site-local IPv6 addresses. 351 The scope identifier MUST disambiguate identical address 352 values. For link-local addresses, the scope identifier 353 will typically be the interface index (ifIndex as defined 354 in the IF-MIB, RFC 2863) of the interface on which the 355 address is configured. 357 The scope identifier may contain the special value 0 358 which refers to the default scope. The default scope 359 may be used in cases where the valid scope identifier 360 is not known (e.g., a management application needs to 361 write a site-local InetAddressIPv6 address without 362 knowing the site identifier value). The default scope 363 SHOULD NOT be used as an easy way out in cases where 364 the scope identifier for a non-global IPv6 address 365 is known." 366 SYNTAX OCTET STRING (SIZE (16|20)) 368 InetAddressDNS ::= TEXTUAL-CONVENTION 369 DISPLAY-HINT "255a" 370 STATUS current 371 DESCRIPTION 372 "Represents a DNS domain name. The name SHOULD be 373 fully qualified whenever possible. 375 The corresponding InetAddressType is dns(16). 377 The DESCRIPTION clause of InetAddress objects that 378 may have InetAddressDNS values must fully describe 379 how (and when) such names are to be resolved to IP 380 addresses." 381 SYNTAX OCTET STRING (SIZE (1..255)) 383 InetAddressPrefixLength ::= TEXTUAL-CONVENTION 384 STATUS current 385 DESCRIPTION 386 "Denotes the length of a generic Internet network address 387 prefix. A value of n corresponds to an IP address mask 388 which has n contiguous 1-bits from the most significant 389 bit (MSB) and all other bits set to 0. 391 An InetAddressPrefixLength value is always interpreted 392 within the context of an InetAddressType value. The 393 InetAddressType object must be registered before the 394 object which uses the InetAddressPrefixLength textual 395 convention. 397 InetAddressPrefixLength values that are larger than 398 the maximum length of an IP address for a specific 399 InetAddressType are treated as the maximum significant 400 value applicable for the InetAddressType. The maximum 401 significant value is 32 for the InetAddressType 402 'ipv4(1)' and 128 for the InetAddressType 'ipv6(2)'. 403 The maximum significant value for the InetAddressType 404 'dns(16)' is 0. 406 The value zero is object-specific and must be defined as 407 part of the description of any object which uses this 408 syntax. Examples of the usage of zero might include 409 situations where the Internet network address prefix 410 is unknown or does not apply." 411 SYNTAX Unsigned32 413 InetPortNumber ::= TEXTUAL-CONVENTION 414 STATUS current 415 DESCRIPTION 416 "Represents a 16 bit port number of an Internet transport 417 layer protocol. Port numbers are assigned by IANA. A 418 current list of all assignments is available from 419 . 421 The value zero is object-specific and must be defined as 422 part of the description of any object which uses this 423 syntax. Examples of the usage of zero might include 424 situations where a port number is unknown, or when the 425 value zero is used as a wildcard in a filter." 426 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 427 SYNTAX Unsigned32 (0..65535) 429 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 430 STATUS current 431 DESCRIPTION 432 "Represents an autonomous system number which identifies an 433 Autonomous System (AS). An AS is a set of routers under a 434 single technical administration, using an interior gateway 435 protocol and common metrics to route packets within the AS, 436 and using an exterior gateway protocol to route packets to 437 other ASs'. IANA maintains the AS number space and has 438 delegated large parts to the regional registries. 440 Autonomous system numbers are currently limited to 16 bits 441 (0..65535). There is however work in progress to enlarge the 442 autonomous system number space to 32 bits. This textual 443 convention therefore uses an Unsigned32 value without a 444 range restriction in order to support a larger autonomous 445 system number space." 446 REFERENCE "RFC 1771, RFC 1930" 447 SYNTAX Unsigned32 449 END 451 4. Usage Hints 453 One particular usage of InetAddressType/InetAddress pairs is to avoid 454 over-constraining an object definition by the use of the IpAddress 455 SMI base type. An InetAddressType/InetAddress pair allows to 456 represent IP addresses in various formats. 458 The InetAddressType and InetAddress objects SHOULD NOT be sub-typed. 459 Sub-typing binds the MIB module to specific address formats, which 460 may cause serious problems if new address formats need to be 461 introduced. Note that it is possible to write compliance statements 462 in order to express that only a subset of the defined address types 463 must be implemented to be compliant. 465 The InetAddressType object must be registered before the InetAddress 466 object(s) or InetAddressPrefixLength object(s). In other words, the 467 object identifiers for the InetAddressType object and the InetAddress 468 object MUST have the same length and the last sub-identifier of the 469 InetAddressType object MUST be less than the last sub-identifier of 470 the InetAddress object. This rule allows programs such as MIB 471 compilers to identify the InetAddressType of a given InetAddress or 472 InetAddressPrefixLength object by searching for the InetAddressType 473 object which precedes InetAddress or InetAddressPrefixLength 474 registration. 476 4.1 Table Indexing 478 When a generic Internet address is used as an index, both the 479 InetAddressType and InetAddress objects MUST be used. The 480 InetAddressType object MUST be listed before the InetAddress object 481 in the INDEX clause. 483 The IMPLIED keyword MUST NOT be used for an object of type 484 InetAddress in an INDEX clause. Instance sub-identifiers are then of 485 the form T.N.O1.O2...On, where T is the value of the InetAddressType 486 object, O1...On are the octets in the InetAddress object, and N is 487 the number of those octets. 489 There is a meaningful lexicographical ordering to tables indexed in 490 this fashion. Command generator applications may lookup specific 491 addresses of known type and value, issue GetNext requests for 492 addresses of a single type, or issue GetNext requests for a specific 493 type and address prefix. 495 4.2 Uniqueness of Addresses 497 IPv4 addresses were intended to be globally unique, current usage 498 notwithstanding. IPv6 addresses were architected to have different 499 scopes and hence uniqueness [19]. In particular, IPv6 "link-local" 500 and "site-local" addresses are not guaranteed to be unique on any 501 particular node. In such cases, the duplicate addresses must be 502 configured on different interfaces. So the combination of an IPv6 503 address and an interface number is unique. The interface number may 504 therefore be used as a scope identifier. 506 The InetAddressIPv6 textual convention has been defined to represent 507 global and non-global IPv6 addresses. MIB designers who use 508 InetAddressType/InetAddress pairs therefore do not need define 509 additional objects in order to support link-local or site-local 510 addresses. 512 The size of the scope identifier has been chosen so that it matches 513 the sin6_scope_id field of the sockaddr_in6 structure defined in RFC 514 2553 [20]. 516 4.3 Multiple InetAddresses per Host 518 A single host system may be configured with multiple addresses (IPv4 519 or IPv6), and possibly with multiple DNS names. Thus it is possible 520 for a single host system to be accessible by multiple 521 InetAddressType/InetAddress pairs. 523 If this could be an implementation or usage issue, then the 524 DESCRIPTION clause of the relevant objects MUST fully describe 525 required behavior. 527 4.4 Resolving DNS Names 529 DNS names must be resolved to IP addresses when communication with 530 the named host is required. This raises a temporal aspect to 531 defining MIB objects whose value is a DNS name: When is the name 532 translated to an address? 534 For example, consider an object defined to indicate a forwarding 535 destination, and whose value is a DNS name. When does the forwarding 536 entity resolve the DNS name? Each time forwarding occurs or just once 537 when the object was instantiated? 539 The DESCRIPTION clause of such objects SHOULD precisely define how 540 and when any required name to address resolution is done. 542 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 543 define how and when a reverse lookup is being done if an agent has 544 accessed instrumentation that knows about an IP address and the MIB 545 module or implementation requires to map the IP address to a DNS 546 name. 548 5. Table Indexing Example 550 This example shows a table listing communication peers that are 551 identified by either an IPv4 address, an IPv6 address or a DNS name. 552 The table definition also prohibits entries with an empty address 553 (whose type would be "unknown"). The size of a DNS name is limited 554 to 64 characters. 556 peerTable OBJECT-TYPE 557 SYNTAX SEQUENCE OF PeerEntry 558 MAX-ACCESS not-accessible 559 STATUS current 560 DESCRIPTION 561 "A list of communication peers." 562 ::= { somewhere 1 } 564 peerEntry OBJECT-TYPE 565 SYNTAX PeerEntry 566 MAX-ACCESS not-accessible 567 STATUS current 568 DESCRIPTION 569 "An entry containing information about a particular peer." 570 INDEX { peerAddressType, peerAddress } 571 ::= { peerTable 1 } 573 PeerEntry ::= SEQUENCE { 574 peerAddressType InetAddressType, 575 peerAddress InetAddress, 576 peerStatus INTEGER 577 } 579 peerAddressType OBJECT-TYPE 580 SYNTAX InetAddressType 581 MAX-ACCESS not-accessible 582 STATUS current 583 DESCRIPTION 584 "The type of Internet address by which the peer 585 is reachable." 586 ::= { peerEntry 1 } 588 peerAddress OBJECT-TYPE 589 SYNTAX InetAddress (SIZE (1..64)) 590 MAX-ACCESS not-accessible 591 STATUS current 592 DESCRIPTION 593 "The Internet address for the peer. Note that 594 implementations must limit themselves to a single 595 entry in this table per reachable peer. 597 The peerAddress may not be empty due to the SIZE 598 restriction. 600 If a row is created administratively by an SNMP 601 operation and the address type value is dns(16), then 602 the agent stores the DNS name internally. A DNS name 603 lookup must be performed on the internally stored DNS 604 name whenever it is being used to contact the peer. 606 If a row is created by the managed entity itself and 607 the address type value is dns(16), then the agent 608 stores the IP address internally. A DNS reverse lookup 609 must be performed on the internally stored IP address 610 whenever the value is retrieved via SNMP." 611 ::= { peerEntry 2 } 613 The following compliance statement specifies that implementations 614 need only support IPv4 addresses and globally unique IPv6 addresses 615 to be compliant. Support for DNS names or scoped IPv6 addresses is 616 not required. 618 peerCompliance MODULE-COMPLIANCE 619 STATUS current 620 DESCRIPTION 621 "The compliance statement the peer MIB." 623 MODULE -- this module 624 MANDATORY-GROUPS { peerGroup } 626 OBJECT peerAddressType 627 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 628 DESCRIPTION 629 "An implementation is only required to support IPv4 630 and IPv6 addresses." 632 OBJECT peerAddress 633 SYNTAX InetAddress (SIZE(4|16)) 634 DESCRIPTION 635 "An implementation is only required to support IPv4 636 and globally unique IPv6 addresses." 638 ::= { somewhere 2 } 640 Note that the SMIv2 does not permit inclusion of not-accessible 641 objects in an object group (see section 3.1 in STD 58, RFC 2580 [8]). 642 It is therefore not possible to formally refine the syntax of 643 auxiliary objects which are not-accessible. In such a case, it is 644 suggested to express the refinement informally in the DESCRIPTION 645 clause of the MODULE-COMPLIANCE macro invocation. 647 6. Security Considerations 649 This module does not define any management objects. Instead, it 650 defines a set of textual conventions which may be used by other MIB 651 modules to define management objects. 653 Meaningful security considerations can only be written in the MIB 654 modules that define management objects. This document has therefore 655 no impact on the security of the Internet. 657 7. Acknowledgments 659 This document was produced by the Operations and Management Area 660 "IPv6MIB" design team. The authors would like to thank Fred Baker, 661 Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro 662 Hagino, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas 663 Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew 664 Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill for 665 their comments and suggestions. 667 8. Intellectual Property Notice 669 The IETF takes no position regarding the validity or scope of any 670 intellectual property or other rights that might be claimed to 671 pertain to the implementation or use of the technology described in 672 this document or the extent to which any license under such rights 673 might or might not be available; neither does it represent that it 674 has made any effort to identify any such rights. Information on the 675 IETF's procedures with respect to rights in standards-track and 676 standards-related documentation can be found in BCP-11. Copies of 677 claims of rights made available for publication and any assurances of 678 licenses to be made available, or the result of an attempt made to 679 obtain a general license or permission for the use of such 680 proprietary rights by implementors or users of this specification can 681 be obtained from the IETF Secretariat. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights which may cover technology that may be required to practice 686 this standard. Please address the information to the IETF Executive 687 Director. 689 9. Changes from RFC 2851 691 The following changes have been made relative to RFC 2851: 693 o Added new TCs: InetAddressPrefixLength, InetPortNumber, 694 InetAutonomousSystemNumber 696 o Rewrote the introduction to say clearly that in general, one 697 should define MIB tables that work with all versions of IP. The 698 other approach of multiple tables for different IP versions is 699 strongly discouraged. (kzm) 701 o Added text to the InetAddressType and InetAddress descriptions 702 which requires that implementations must reject set operations 703 with an inconsistentValue error if they lead to inconsistencies. 705 o Relaxed the rules to make it possible to register tuples where 706 multiple objects share an InetAddressType value, which is needed 707 for filters of the form (InetAddressType, InetAddress, 708 InetPortNumber, InetAddress InetPortNumber). 710 o Added a paragraph in the Introduction which explains the 711 motivation for the ordering constraints. 713 10. Open Issues 715 o Check that the document is consistent with draft-ietf-ipngwg- 716 scoping-arch-02.txt and add a reference to it. 718 o Addition of an InetScopeIdentifier TC? (Bill Fenner) 720 o Is there a need to represent scoped IPv4 addresses? 722 References 724 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 725 Levels", BCP 14, RFC 2119, March 1997. 727 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 728 Describing SNMP Management Frameworks", RFC 2571, April 1999. 730 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 731 Management Information for TCP/IP-based Internets", STD 16, RFC 732 1155, May 1990. 734 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 735 RFC 1212, March 1991. 737 [5] Rose, M., "A Convention for Defining Traps for use with the 738 SNMP", RFC 1215, March 1991. 740 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 741 M. and S. Waldbusser, "Structure of Management Information 742 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 744 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 745 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 746 RFC 2579, April 1999. 748 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 749 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 750 58, RFC 2580, April 1999. 752 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 753 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 754 1990. 756 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 757 "Introduction to Community-based SNMPv2", RFC 1901, January 758 1996. 760 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 761 "Transport Mappings for Version 2 of the Simple Network 762 Management Protocol (SNMPv2)", RFC 1906, January 1996. 764 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 765 Processing and Dispatching for the Simple Network Management 766 Protocol (SNMP)", RFC 2572, April 1999. 768 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 769 for version 3 of the Simple Network Management Protocol 770 (SNMPv3)", RFC 2574, April 1999. 772 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol 773 Operations for Version 2 of the Simple Network Management 774 Protocol (SNMPv2)", RFC 1905, January 1996. 776 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 777 2573, April 1999. 779 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 780 Control Model (VACM) for the Simple Network Management Protocol 781 (SNMP)", RFC 2575, April 1999. 783 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 784 to Version 3 of the Internet-standard Network Management 785 Framework", RFC 2570, April 1999. 787 [18] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 788 RFC 2863, June 2000. 790 [19] Hinden, R. and S. Deering, "IP Version 6 Addressing 791 Architecture", RFC 2373, July 1998. 793 [20] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 794 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 796 Authors' Addresses 798 Mike Daniele 799 Consultant 800 19 Pinewood Rd 801 Hudson, NH 03051 802 USA 804 Phone: +1 603 883-6365 805 EMail: mwdaniele@adelphia.net 807 Brian Haberman 808 Nortel Networks 809 4039 Emperor Blvd., Suite 200 810 Durham, NC 27703 811 USA 813 Phone: +1 919 992-4439 814 EMail: haberman@nortelnetworks.com 816 Shawn A. Routhier 817 Wind River Systems, Inc. 818 1 Tara Blvd, Suite 403 819 Nashua, NH 03062 820 USA 822 Phone: +1 603 897-2000 823 EMail: sar@epilogue.com 824 Juergen Schoenwaelder 825 TU Braunschweig 826 Bueltenweg 74/75 827 38106 Braunschweig 828 Germany 830 Phone: +49 531 391-3289 831 EMail: schoenw@ibr.cs.tu-bs.de 833 Full Copyright Statement 835 Copyright (C) The Internet Society (2001). All Rights Reserved. 837 This document and translations of it may be copied and furnished to 838 others, and derivative works that comment on or otherwise explain it 839 or assist in its implementation may be prepared, copied, published 840 and distributed, in whole or in part, without restriction of any 841 kind, provided that the above copyright notice and this paragraph are 842 included on all such copies and derivative works. However, this 843 document itself may not be modified in any way, such as by removing 844 the copyright notice or references to the Internet Society or other 845 Internet organizations, except as needed for the purpose of 846 developing Internet standards in which case the procedures for 847 copyrights defined in the Internet Standards process must be 848 followed, or as required to translate it into languages other than 849 English. 851 The limited permissions granted above are perpetual and will not be 852 revoked by the Internet Society or its successors or assigns. 854 This document and the information contained herein is provided on an 855 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 856 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 857 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 858 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 859 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 861 Acknowledgement 863 Funding for the RFC Editor function is currently provided by the 864 Internet Society.