idnits 2.17.1 draft-ietf-ops-rfc2851-update-05.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 is 1 instance 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 353 has weird spacing: '... octets cont...' == Line 365 has weird spacing: '... octets cont...' == Line 378 has weird spacing: '... octets cont...' == Line 399 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 (October 31, 2001) is 8214 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 841, 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) == Outdated reference: A later version (-04) exists of draft-ietf-ipngwg-scoping-arch-02 -- Possible downref: Normative reference to a draft: ref. '21' Summary: 17 errors (**), 0 flaws (~~), 9 warnings (==), 4 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: May 1, 2002 B. Haberman 5 Nortel Networks 6 S. Routhier 7 Wind River Systems, Inc. 8 J. Schoenwaelder 9 TU Braunschweig 10 October 31, 2001 12 Textual Conventions for Internet Network Addresses 13 draft-ietf-ops-rfc2851-update-05.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 May 1, 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 . . . . . . . . . . . . . . . . 5 55 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 11 57 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 12 58 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 12 59 4.3 Multiple Addresses per Host . . . . . . . . . . . . . . . . . 13 60 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 13 61 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 14 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 64 8. Intellectual Property Notice . . . . . . . . . . . . . . . . . 16 65 9. Changes from RFC 2851 . . . . . . . . . . . . . . . . . . . . 16 66 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 68 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 70 1. Introduction 72 Several standard-track MIB modules use the IpAddress SMIv2 base type. 73 This limits the applicability of these MIB modules to IP Version 4 74 (IPv4) since the IpAddress SMIv2 base type can only contain 4 byte 75 IPv4 addresses. The IpAddress SMIv2 base type has become problematic 76 with the introduction of IP Version 6 (IPv6) 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 MIB modules SHOULD NOT use the SMIv2 IpAddress 84 base type 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 also be used to 98 represent generic Internet subnets and Internet address ranges. A 99 generic Internet subnet is represented by three objects, one whose 100 syntax is InetAddressType, a second one whose syntax is InetAddress 101 and a third one whose syntax is InetAddressPrefixLength. The 102 InetAddressType value again determines the concrete format of the 103 InetAddress value while the InetAddressPrefixLength identifies the 104 Internet network address prefix. 106 A generic range of consecutive Internet addresses is represented by 107 three objects. The first one has the syntax InetAddressType while 108 the remaining objects have the syntax InetAddress and specify the 109 start and end of the address range. The InetAddressType value again 110 determines the format of the InetAddress values. 112 The textual conventions defined in this document can be used to 113 define Internet addresses by using DNS domain names in addition to 114 IPv4 and IPv6 addresses. A MIB designer can write compliance 115 statements to express that only a subset of the possible address 116 types must be supported by a compliant implementation. 118 MIB developers who need to represent Internet addresses SHOULD use 119 these definitions whenever applicable, as opposed to defining their 120 own constructs. Even MIB modules that only need to represent IPv4 or 121 IPv6 addresses SHOULD use the textual conventions defined in this 122 memo. 124 There are many widely deployed MIB modules that use IPv4 addresses 125 and which need to be revised to support IPv6. These MIBs can be 126 categorized as follows: 128 1. MIB modules which define management information that is in 129 principle IP version neutral, but the MIB currently uses 130 addressing constructs specific to a certain IP version. 132 2. MIB modules which define management information that is specific 133 to particular IP version (either IPv4 or IPv6) and which is very 134 unlikely to be ever applicable to another IP version. 136 MIB modules of the first type SHOULD provide object definitions 137 (e.g., tables) that work with all versions of IP. In particular, 138 when revising a MIB module which contains IPv4 specific tables, it is 139 suggested to define new tables using the textual conventions defined 140 in this memo which support all versions of IP. The status of the new 141 tables SHOULD be "current" while the status of the old IP version 142 specific tables SHOULD be changed to "deprecated". The other 143 approach of having multiple similar tables for different IP versions 144 is strongly discouraged. 146 MIB modules of the second type, which are inherently IP version 147 specific, do not need to be redefined. Note that even in this case, 148 any additions to these MIB modules or new IP version specific MIB 149 modules SHOULD use the textual conventions defined in this memo. 151 MIB developers SHOULD NOT use the textual conventions defined in this 152 document to represent generic transport layer addresses. Instead the 153 SMIv2 TAddress textual convention and associated definitions should 154 be used for transport layer addresses. 156 This memo introduces some ordering constraints in order to achieve 157 the following two goals: 159 1. Enable programs to identify the InetAddressType object which 160 discriminates a certain InetAddress object. This allows tools 161 such as MIB compilers to understand the dependencies and to 162 generate code to handle some error conditions. 164 2. Provide some rules that prevent MIB module authors from doing 165 certain mistakes which can make future extensions of tables with 166 new objects impossible. 168 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 169 this document are to be interpreted as described in RFC 2119 [1]. 171 2. The SNMP Management Framework 173 The SNMP Management Framework presently consists of five major 174 components: 176 o An overall architecture, described in RFC 2571 [2]. 178 o Mechanisms for describing and naming objects and events for the 179 purpose of management. The first version of this Structure of 180 Management Information (SMI) is called SMIv1 and described in STD 181 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The 182 second version, called SMIv2, is described in STD 58, RFC 2578 183 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. 185 o Message protocols for transferring management information. The 186 first version of the SNMP message protocol is called SNMPv1 and 187 described in STD 15, RFC 1157 [9]. A second version of the SNMP 188 message protocol, which is not an Internet standards track 189 protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 190 1906 [11]. The third version of the message protocol is called 191 SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 192 [13]. 194 o Protocol operations for accessing management information. The 195 first set of protocol operations and associated PDU formats is 196 described in STD 15, RFC 1157 [9]. A second set of protocol 197 operations and associated PDU formats is described in RFC 1905 198 [14]. 200 o A set of fundamental applications described in RFC 2573 [15] and 201 the view-based access control mechanism described in RFC 2575 202 [16]. 204 A more detailed introduction to the current SNMP Management Framework 205 can be found in RFC 2570 [17]. 207 Managed objects are accessed via a virtual information store, termed 208 the Management Information Base or MIB. Objects in the MIB are 209 defined using the mechanisms defined in the SMI. 211 This memo specifies a MIB module that is compliant to the SMIv2. A 212 MIB conforming to the SMIv1 can be produced through the appropriate 213 translations. The resulting translated MIB must be semantically 214 equivalent, except where objects or events are omitted because no 215 translation is possible (use of Counter64). Some machine readable 216 information in SMIv2 will be converted into textual descriptions in 217 SMIv1 during the translation process. However, this loss of machine 218 readable information is not considered to change the semantics of the 219 MIB. 221 3. Definitions 223 INET-ADDRESS-MIB DEFINITIONS ::= BEGIN 225 IMPORTS 226 MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI 227 TEXTUAL-CONVENTION FROM SNMPv2-TC; 229 inetAddressMIB MODULE-IDENTITY 230 LAST-UPDATED "200109200000Z" 231 ORGANIZATION 232 "IETF Operations and Management Area" 233 CONTACT-INFO 234 "Juergen Schoenwaelder (Editor) 235 TU Braunschweig 236 Bueltenweg 74/75 237 38106 Braunschweig, Germany 239 Phone: +49 531 391-3289 240 EMail: schoenw@ibr.cs.tu-bs.de 242 Send comments to ." 243 DESCRIPTION 244 "This MIB module defines textual conventions for 245 representing Internet addresses. An Internet 246 address can be an IPv4 address, an IPv6 address 247 or a DNS domain name. This module also defines 248 textual conventions for Internet port numbers, 249 autonomous system numbers and the length of an 250 Internet address prefix." 251 REVISION "200109200000Z" 252 DESCRIPTION 253 "Second version, published as RFC XXXX. This 254 revisions contains several clarifications and it 255 introduces several new textual conventions: 256 InetAddressPrefixLength, InetPortNumber, 257 InetAutonomousSystemNumber, InetAddressIPv4z, 258 and InetAddressIPv6z." 259 REVISION "200006080000Z" 260 DESCRIPTION 261 "Initial version, published as RFC 2851." 263 ::= { mib-2 76 } 265 InetAddressType ::= TEXTUAL-CONVENTION 266 STATUS current 267 DESCRIPTION 268 "A value that represents a type of Internet address. 270 unknown(0) An unknown address type. This value MUST 271 be used if the value of the corresponding 272 InetAddress object is a zero-length string. 273 It may also be used to indicate an IP address 274 which is not in one of the formats defined 275 below. 277 ipv4(1) An IPv4 address as defined by the 278 InetAddressIPv4 textual convention. 280 ipv6(2) A global IPv6 address as defined by the 281 InetAddressIPv6 textual convention. 283 ipv4z(3) A non-global IPv4 address including a zone 284 index as defined by the InetAddressIPv4z 285 textual convention. 287 ipv6z(4) A non-global IPv6 address including a zone 288 index as defined by the InetAddressIPv6z 289 textual convention. 291 dns(16) A DNS domain name as defined by the 292 InetAddressDNS textual convention. 294 Each definition of a concrete InetAddressType value must be 295 accompanied by a definition of a textual convention for use 296 with that InetAddressType. 298 To support future extensions, the InetAddressType textual 299 convention SHOULD NOT be sub-typed in object type definitions. 300 It MAY be sub-typed in compliance statements in order to 301 require only a subset of these address types for a compliant 302 implementation. 304 Implementations must ensure that InetAddressType objects 305 and any dependent objects (e.g. InetAddress objects) are 306 consistent. An inconsistentValue error must be generated 307 if an attempt to change an InetAddressType object would, 308 for example, lead to an undefined InetAddress value. In 309 particular, InetAddressType/InetAddress pairs must be 310 changed together if the address type changes (e.g. from 311 ipv6(2) to ipv4(1))." 312 SYNTAX INTEGER { 313 unknown(0), 314 ipv4(1), 315 ipv6(2), 316 ipv4z(3), 317 ipv6z(4), 318 dns(16) 319 } 321 InetAddress ::= TEXTUAL-CONVENTION 322 STATUS current 323 DESCRIPTION 324 "Denotes a generic Internet address. 326 An InetAddress value is always interpreted within the 327 context of an InetAddressType value. The InetAddressType 328 object which defines the format of the InetAddress 329 value MUST be registered before the object(s) which use 330 the InetAddress textual convention. If multiple 331 InetAddressType objects are registered before the 332 InetAddress object(s), the closest one applies. 334 The value of an InetAddress object must always be 335 consistent with the value of the associated InetAddressType 336 object. Attempts to set an InetAddress object to a value 337 which is inconsistent with the associated InetAddressType 338 must fail with an inconsistentValue error. 340 When this textual convention is used as the syntax of an 341 index object, there may be issues with the limit of 128 342 sub-identifiers specified in SMIv2, STD 58. In this case, 343 the OBJECT-TYPE declaration MUST include a 'SIZE' clause 344 to limit the number of potential instance sub-identifiers." 345 SYNTAX OCTET STRING (SIZE (0..255)) 347 InetAddressIPv4 ::= TEXTUAL-CONVENTION 348 DISPLAY-HINT "1d.1d.1d.1d" 349 STATUS current 350 DESCRIPTION 351 "Represents an IPv4 network address: 353 octets contents encoding 354 1-4 IPv4 address network-byte order 356 The corresponding InetAddressType value is ipv4(1)." 357 SYNTAX OCTET STRING (SIZE (4)) 359 InetAddressIPv6 ::= TEXTUAL-CONVENTION 360 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x" 361 STATUS current 362 DESCRIPTION 363 "Represents an IPv6 network address: 365 octets contents encoding 366 1-16 IPv6 address network-byte order 368 The corresponding InetAddressType value is ipv6(2)." 369 SYNTAX OCTET STRING (SIZE (16)) 371 InetAddressIPv4z ::= TEXTUAL-CONVENTION 372 DISPLAY-HINT "1d.1d.1d.1d%4d" 373 STATUS current 374 DESCRIPTION 375 "Represents a non-global IPv4 network address together 376 with its zone index: 378 octets contents encoding 379 1-4 IPv4 address network-byte order 380 5-8 zone index network-byte order 382 The corresponding InetAddressType value is ipv4z(3). 384 The zone index (bytes 5-8) is used to disambiguate 385 identical address values on nodes which have interfaces 386 attached to different zones of the same scope. 388 The zone index may contain the special value 0 which 389 refers to the default zone for each scope." 390 SYNTAX OCTET STRING (SIZE (8)) 392 InetAddressIPv6z ::= TEXTUAL-CONVENTION 393 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 394 STATUS current 395 DESCRIPTION 396 "Represents a non-global IPv6 network address together 397 with its zone index: 399 octets contents encoding 400 1-16 IPv6 address network-byte order 401 17-20 zone index network-byte order 403 The corresponding InetAddressType value is ipv6z(4). 405 The zone index (bytes 17-20) is used to disambiguate 406 identical address values on nodes which have interfaces 407 attached to different zones of the same scope. 409 The zone index may contain the special value 0 which 410 refers to the default zone for each scope." 411 SYNTAX OCTET STRING (SIZE (20)) 413 InetAddressDNS ::= TEXTUAL-CONVENTION 414 DISPLAY-HINT "255a" 415 STATUS current 416 DESCRIPTION 417 "Represents a DNS domain name. The name SHOULD be 418 fully qualified whenever possible. 420 The corresponding InetAddressType is dns(16). 422 The DESCRIPTION clause of InetAddress objects that 423 may have InetAddressDNS values must fully describe 424 how (and when) such names are to be resolved to IP 425 addresses." 426 SYNTAX OCTET STRING (SIZE (1..255)) 428 InetAddressPrefixLength ::= TEXTUAL-CONVENTION 429 STATUS current 430 DESCRIPTION 431 "Denotes the length of a generic Internet network address 432 prefix. A value of n corresponds to an IP address mask 433 which has n contiguous 1-bits from the most significant 434 bit (MSB) and all other bits set to 0. 436 An InetAddressPrefixLength value is always interpreted 437 within the context of an InetAddressType value. The 438 InetAddressType object must be registered before the 439 object which uses the InetAddressPrefixLength textual 440 convention. 442 InetAddressPrefixLength values that are larger than 443 the maximum length of an IP address for a specific 444 InetAddressType are treated as the maximum significant 445 value applicable for the InetAddressType. The maximum 446 significant value is 32 for the InetAddressType 447 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 448 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value 449 for the InetAddressType 'dns(16)' is 0. 451 The value zero is object-specific and must be defined as 452 part of the description of any object which uses this 453 syntax. Examples of the usage of zero might include 454 situations where the Internet network address prefix 455 is unknown or does not apply." 456 SYNTAX Unsigned32 458 InetPortNumber ::= TEXTUAL-CONVENTION 459 STATUS current 460 DESCRIPTION 461 "Represents a 16 bit port number of an Internet transport 462 layer protocol. Port numbers are assigned by IANA. A 463 current list of all assignments is available from 464 . 466 The value zero is object-specific and must be defined as 467 part of the description of any object which uses this 468 syntax. Examples of the usage of zero might include 469 situations where a port number is unknown, or when the 470 value zero is used as a wildcard in a filter." 471 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 472 SYNTAX Unsigned32 (0..65535) 474 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 475 STATUS current 476 DESCRIPTION 477 "Represents an autonomous system number which identifies an 478 Autonomous System (AS). An AS is a set of routers under a 479 single technical administration, using an interior gateway 480 protocol and common metrics to route packets within the AS, 481 and using an exterior gateway protocol to route packets to 482 other ASs'. IANA maintains the AS number space and has 483 delegated large parts to the regional registries. 485 Autonomous system numbers are currently limited to 16 bits 486 (0..65535). There is however work in progress to enlarge the 487 autonomous system number space to 32 bits. This textual 488 convention therefore uses an Unsigned32 value without a 489 range restriction in order to support a larger autonomous 490 system number space." 491 REFERENCE "RFC 1771, RFC 1930" 492 SYNTAX Unsigned32 494 END 496 4. Usage Hints 498 One particular usage of InetAddressType/InetAddress pairs is to avoid 499 over-constraining an object definition by the use of the IpAddress 500 SMI base type. An InetAddressType/InetAddress pair allows to 501 represent IP addresses in various formats. 503 The InetAddressType and InetAddress objects SHOULD NOT be sub-typed. 504 Sub-typing binds the MIB module to specific address formats, which 505 may cause serious problems if new address formats need to be 506 introduced. Note that it is possible to write compliance statements 507 in order to express that only a subset of the defined address types 508 must be implemented to be compliant. 510 The InetAddressType object must be registered before the InetAddress 511 object(s) or InetAddressPrefixLength object(s). In other words, the 512 object identifiers for the InetAddressType object and the InetAddress 513 object MUST have the same length and the last sub-identifier of the 514 InetAddressType object MUST be less than the last sub-identifier of 515 the InetAddress object. This rule allows programs such as MIB 516 compilers to identify the InetAddressType of a given InetAddress or 517 InetAddressPrefixLength object by searching for the InetAddressType 518 object which precedes InetAddress or InetAddressPrefixLength 519 registration. 521 4.1 Table Indexing 523 When a generic Internet address is used as an index, both the 524 InetAddressType and InetAddress objects MUST be used. The 525 InetAddressType object MUST be listed before the InetAddress object 526 in the INDEX clause. 528 The IMPLIED keyword MUST NOT be used for an object of type 529 InetAddress in an INDEX clause. Instance sub-identifiers are then of 530 the form T.N.O1.O2...On, where T is the value of the InetAddressType 531 object, O1...On are the octets in the InetAddress object, and N is 532 the number of those octets. 534 There is a meaningful lexicographical ordering to tables indexed in 535 this fashion. Command generator applications may lookup specific 536 addresses of known type and value, issue GetNext requests for 537 addresses of a single type, or issue GetNext requests for a specific 538 type and address prefix. 540 4.2 Uniqueness of Addresses 542 IPv4 addresses were intended to be globally unique, current usage 543 notwithstanding. IPv6 addresses were architected to have different 544 scopes and hence uniqueness [19]. In particular, IPv6 "link-local" 545 and "site-local" addresses are not guaranteed to be unique on any 546 particular node. In such cases, the duplicate addresses must be 547 configured on different interfaces. So the combination of an IPv6 548 address and a zone index is unique [21]. 550 The InetAddressIPv6 textual convention has been defined to represent 551 global IPv6 address and non-global IPv6 addresses in cases where no 552 zone index is needed (e.g., on end hosts with a single interface). 553 The InetAddressIPv6z textual convention has been defined to represent 554 non-global IPv6 addresses in cases where a zone index is needed 555 (e.g., a router connecting multiple zones). MIB designers who use 556 InetAddressType/InetAddress pairs therefore do not need define 557 additional objects in order to support non-global addresses on nodes 558 that connect multiple zones. 560 The InetAddressIPv4z is intended for use in MIBs (like the TCP-MIB) 561 which report addresses in the address family used on the wire, but 562 where the entity instrumented obtains such addresses from 563 applications or administrators in a form which includes a zone index, 564 such as v4-mapped IPv6 addresses. 566 The size of the zone index has been chosen so that it is consistent 567 with (i) the numerical zone index defined in [21] and (ii) the 568 sin6_scope_id field of the sockaddr_in6 structure defined in RFC 2553 569 [20]. 571 4.3 Multiple Addresses per Host 573 A single host system may be configured with multiple addresses (IPv4 574 or IPv6), and possibly with multiple DNS names. Thus it is possible 575 for a single host system to be accessible by multiple 576 InetAddressType/InetAddress pairs. 578 If this could be an implementation or usage issue, then the 579 DESCRIPTION clause of the relevant objects must fully describe which 580 address is reported in a given InetAddressType/InetAddress pair. 582 4.4 Resolving DNS Names 584 DNS names must be resolved to IP addresses when communication with 585 the named host is required. This raises a temporal aspect to 586 defining MIB objects whose value is a DNS name: When is the name 587 translated to an address? 589 For example, consider an object defined to indicate a forwarding 590 destination, and whose value is a DNS name. When does the forwarding 591 entity resolve the DNS name? Each time forwarding occurs or just once 592 when the object was instantiated? 594 The DESCRIPTION clause of such objects SHOULD precisely define how 595 and when any required name to address resolution is done. 597 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 598 define how and when a reverse lookup is being done if an agent has 599 accessed instrumentation that knows about an IP address and the MIB 600 module or implementation requires to map the IP address to a DNS 601 name. 603 5. Table Indexing Example 605 This example shows a table listing communication peers that are 606 identified by either an IPv4 address, an IPv6 address or a DNS name. 607 The table definition also prohibits entries with an empty address 608 (whose type would be "unknown"). The size of a DNS name is limited 609 to 64 characters. 611 peerTable OBJECT-TYPE 612 SYNTAX SEQUENCE OF PeerEntry 613 MAX-ACCESS not-accessible 614 STATUS current 615 DESCRIPTION 616 "A list of communication peers." 617 ::= { somewhere 1 } 619 peerEntry OBJECT-TYPE 620 SYNTAX PeerEntry 621 MAX-ACCESS not-accessible 622 STATUS current 623 DESCRIPTION 624 "An entry containing information about a particular peer." 625 INDEX { peerAddressType, peerAddress } 626 ::= { peerTable 1 } 628 PeerEntry ::= SEQUENCE { 629 peerAddressType InetAddressType, 630 peerAddress InetAddress, 631 peerStatus INTEGER 632 } 634 peerAddressType OBJECT-TYPE 635 SYNTAX InetAddressType 636 MAX-ACCESS not-accessible 637 STATUS current 638 DESCRIPTION 639 "The type of Internet address by which the peer 640 is reachable." 641 ::= { peerEntry 1 } 643 peerAddress OBJECT-TYPE 644 SYNTAX InetAddress (SIZE (1..64)) 645 MAX-ACCESS not-accessible 646 STATUS current 647 DESCRIPTION 648 "The Internet address for the peer. Note that 649 implementations must limit themselves to a single 650 entry in this table per reachable peer. 652 The peerAddress may not be empty due to the SIZE 653 restriction. 655 If a row is created administratively by an SNMP 656 operation and the address type value is dns(16), then 657 the agent stores the DNS name internally. A DNS name 658 lookup must be performed on the internally stored DNS 659 name whenever it is being used to contact the peer. 661 If a row is created by the managed entity itself and 662 the address type value is dns(16), then the agent 663 stores the IP address internally. A DNS reverse lookup 664 must be performed on the internally stored IP address 665 whenever the value is retrieved via SNMP." 666 ::= { peerEntry 2 } 668 The following compliance statement specifies that compliant 669 implementations need only support IPv4/IPv6 addresses without a zone 670 indices. Support for DNS names or IPv4/IPv6 addresses with zone 671 indices is not required. 673 peerCompliance MODULE-COMPLIANCE 674 STATUS current 675 DESCRIPTION 676 "The compliance statement of the peer MIB." 678 MODULE -- this module 679 MANDATORY-GROUPS { peerGroup } 681 OBJECT peerAddressType 682 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 683 DESCRIPTION 684 "An implementation is only required to support IPv4 685 and IPv6 addresses without zone indices." 687 ::= { somewhere 2 } 689 Note that the SMIv2 does not permit inclusion of not-accessible 690 objects in an object group (see section 3.1 in STD 58, RFC 2580 [8]). 691 It is therefore not possible to formally refine the syntax of 692 auxiliary objects which are not-accessible. In such a case, it is 693 suggested to express the refinement informally in the DESCRIPTION 694 clause of the MODULE-COMPLIANCE macro invocation. 696 6. Security Considerations 698 This module does not define any management objects. Instead, it 699 defines a set of textual conventions which may be used by other MIB 700 modules to define management objects. 702 Meaningful security considerations can only be written in the MIB 703 modules that define management objects. This document has therefore 704 no impact on the security of the Internet. 706 7. Acknowledgments 708 This document was produced by the Operations and Management Area 709 "IPv6MIB" design team. The authors would like to thank Fred Baker, 710 Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro 711 Hagino, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas 712 Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew 713 Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill for 714 their comments and suggestions. 716 8. Intellectual Property Notice 718 The IETF takes no position regarding the validity or scope of any 719 intellectual property or other rights that might be claimed to 720 pertain to the implementation or use of the technology described in 721 this document or the extent to which any license under such rights 722 might or might not be available; neither does it represent that it 723 has made any effort to identify any such rights. Information on the 724 IETF's procedures with respect to rights in standards-track and 725 standards-related documentation can be found in BCP-11. Copies of 726 claims of rights made available for publication and any assurances of 727 licenses to be made available, or the result of an attempt made to 728 obtain a general license or permission for the use of such 729 proprietary rights by implementors or users of this specification can 730 be obtained from the IETF Secretariat. 732 The IETF invites any interested party to bring to its attention any 733 copyrights, patents or patent applications, or other proprietary 734 rights which may cover technology that may be required to practice 735 this standard. Please address the information to the IETF Executive 736 Director. 738 9. Changes from RFC 2851 740 The following changes have been made relative to RFC 2851: 742 o Added new textual conventions InetAddressPrefixLength, 743 InetPortNumber, and InetAutonomousSystemNumber. 745 o Rewrote the introduction to say clearly that in general, one 746 should define MIB tables that work with all versions of IP. The 747 other approach of multiple tables for different IP versions is 748 strongly discouraged. (kzm) 750 o Added text to the InetAddressType and InetAddress descriptions 751 which requires that implementations must reject set operations 752 with an inconsistentValue error if they lead to inconsistencies. 754 o Relaxed the rules to make it possible to register tuples where 755 multiple objects share an InetAddressType value, which is useful 756 for filters of the form (InetAddressType, InetAddress, 757 InetPortNumber, InetAddress InetPortNumber). 759 o Added a paragraph in the Introduction which explains the 760 motivation behind the ordering constraints. 762 o Aligned wordings with the IPv6 scoping architecture document. 764 o Split the InetAddressIPv6 textual convention into the two textual 765 conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced 766 a new textual convention InetAddressIPv4z. Added ipv4z(3) and 767 ipv6z(4) named numbers to the InetAddressType enumeration. 768 Motivations for this change: (i) enable the introduction of a 769 textual conventions for non-global IPv4 addresses, (ii) alignment 770 with the textual conventions for transport addresses, (iii) 771 simpler compliance statements in cases where support for IPv6 772 addresses with zone indices is not required, (iv) simplify 773 implementations for host systems which will never have to report 774 zone indices. 776 References 778 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 779 Levels", BCP 14, RFC 2119, March 1997. 781 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 782 Describing SNMP Management Frameworks", RFC 2571, April 1999. 784 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 785 Management Information for TCP/IP-based Internets", STD 16, RFC 786 1155, May 1990. 788 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 789 RFC 1212, March 1991. 791 [5] Rose, M., "A Convention for Defining Traps for use with the 792 SNMP", RFC 1215, March 1991. 794 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 795 M. and S. Waldbusser, "Structure of Management Information 796 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 798 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 799 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 800 RFC 2579, April 1999. 802 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 803 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 804 58, RFC 2580, April 1999. 806 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 807 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 808 1990. 810 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 811 "Introduction to Community-based SNMPv2", RFC 1901, January 812 1996. 814 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 815 "Transport Mappings for Version 2 of the Simple Network 816 Management Protocol (SNMPv2)", RFC 1906, January 1996. 818 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 819 Processing and Dispatching for the Simple Network Management 820 Protocol (SNMP)", RFC 2572, April 1999. 822 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 823 for version 3 of the Simple Network Management Protocol 824 (SNMPv3)", RFC 2574, April 1999. 826 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol 827 Operations for Version 2 of the Simple Network Management 828 Protocol (SNMPv2)", RFC 1905, January 1996. 830 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 831 2573, April 1999. 833 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 834 Control Model (VACM) for the Simple Network Management Protocol 835 (SNMP)", RFC 2575, April 1999. 837 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 838 to Version 3 of the Internet-standard Network Management 839 Framework", RFC 2570, April 1999. 841 [18] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", 842 RFC 2863, June 2000. 844 [19] Hinden, R. and S. Deering, "IP Version 6 Addressing 845 Architecture", RFC 2373, July 1998. 847 [20] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic 848 Socket Interface Extensions for IPv6", RFC 2553, March 1999. 850 [21] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A. 851 and B. Zill, "IPv6 Scoped Address Architecture", draft-ietf- 852 ipngwg-scoping-arch-02.txt, September 2001. 854 Authors' Addresses 856 Mike Daniele 857 Consultant 858 19 Pinewood Rd 859 Hudson, NH 03051 860 USA 862 Phone: +1 603 883-6365 863 EMail: mwdaniele@adelphia.net 865 Brian Haberman 866 Nortel Networks 867 4039 Emperor Blvd., Suite 200 868 Durham, NC 27703 869 USA 871 Phone: +1 919 992-4439 872 EMail: haberman@nortelnetworks.com 874 Shawn A. Routhier 875 Wind River Systems, Inc. 876 1 Tara Blvd, Suite 403 877 Nashua, NH 03062 878 USA 880 Phone: +1 603 897-2000 881 EMail: sar@epilogue.com 882 Juergen Schoenwaelder 883 TU Braunschweig 884 Bueltenweg 74/75 885 38106 Braunschweig 886 Germany 888 Phone: +49 531 391-3289 889 EMail: schoenw@ibr.cs.tu-bs.de 891 Full Copyright Statement 893 Copyright (C) The Internet Society (2001). All Rights Reserved. 895 This document and translations of it may be copied and furnished to 896 others, and derivative works that comment on or otherwise explain it 897 or assist in its implementation may be prepared, copied, published 898 and distributed, in whole or in part, without restriction of any 899 kind, provided that the above copyright notice and this paragraph are 900 included on all such copies and derivative works. However, this 901 document itself may not be modified in any way, such as by removing 902 the copyright notice or references to the Internet Society or other 903 Internet organizations, except as needed for the purpose of 904 developing Internet standards in which case the procedures for 905 copyrights defined in the Internet Standards process must be 906 followed, or as required to translate it into languages other than 907 English. 909 The limited permissions granted above are perpetual and will not be 910 revoked by the Internet Society or its successors or assigns. 912 This document and the information contained herein is provided on an 913 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 914 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 915 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 916 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 917 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 919 Acknowledgement 921 Funding for the RFC Editor function is currently provided by the 922 Internet Society.