idnits 2.17.1 draft-ietf-ops-rfc3291bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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.) ** There are 24 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 RFC3291, 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 331 has weird spacing: '... octets cont...' == Line 348 has weird spacing: '... octets cont...' == Line 366 has weird spacing: '... octets cont...' == Line 391 has weird spacing: '... octets cont...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2003) is 7733 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: 'RFC2863' is defined on line 834, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 MIB Design Team M. Daniele 3 Internet-Draft B. Haberman 4 Expires: August 24, 2003 Consultant 5 S. Routhier 6 Wind River Systems, Inc. 7 J. Schoenwaelder 8 TU Braunschweig 9 February 23, 2003 11 Textual Conventions for Internet Network Addresses 12 draft-ietf-ops-rfc3291bis-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 24, 2003. 37 Copyright Notice 39 Copyright (C) The Internet Society (2003). All Rights Reserved. 41 Abstract 43 This MIB module defines textual conventions to represent commonly 44 used Internet network layer addressing information. The intent is 45 that these textual conventions (TCs) will be imported and used in MIB 46 modules that would otherwise define their own representations. 48 This document obsoletes RFC 3291. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. The Internet-Standard Management Framework . . . . . . . . . . 5 54 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 13 57 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 13 58 4.3 Multiple Addresses per Host . . . . . . . . . . . . . . . . . 14 59 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 14 60 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 14 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 62 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 63 8. Intellectual Property Notice . . . . . . . . . . . . . . . . . 17 64 9. Changes from RFC 3291 . . . . . . . . . . . . . . . . . . . . 17 65 10. Changes from RFC 2851 . . . . . . . . . . . . . . . . . . . . 17 66 Normative References . . . . . . . . . . . . . . . . . . . . . 18 67 Informative References . . . . . . . . . . . . . . . . . . . . 18 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 69 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 21 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 [RFC2373]. 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 for well-known transport domains support 99 scoped Internet addresses. The scope of an Internet address is a 100 topological span within which the address may be used as a unique 101 identifier for an interface or set of interfaces. A scope zone, or 102 simply a zone, is a concrete connected region of topology of a given 103 scope. Note that a zone is a particular instance of a topological 104 region, whereas a scope is the size of a topological region 105 [IPv6Scoped]. Since Internet addresses on devices that connect 106 multiple zones are not necessarily unique, an additional zone index 107 is needed on these devices to select an interface. The textual 108 conventions InetAddressIPv4z and InetAddressIPv6z are provided to 109 support Internet addresses that include a zone index. In order to 110 support arbitrary combinations of scoped Internet addresses, MIB 111 authors SHOULD use a separate InetAddressType object for each 112 InetAddress object. 114 The textual conventions defined in this document can also be used to 115 represent generic Internet subnets and Internet address ranges. A 116 generic Internet subnet is represented by three objects, one whose 117 syntax is InetAddressType, a second one whose syntax is InetAddress 118 and a third one whose syntax is InetAddressPrefixLength. The 119 InetAddressType value again determines the concrete format of the 120 InetAddress value while the InetAddressPrefixLength identifies the 121 Internet network address prefix. 123 A generic range of consecutive Internet addresses is represented by 124 three objects. The first one has the syntax InetAddressType while 125 the remaining objects have the syntax InetAddress and specify the 126 start and end of the address range. The InetAddressType value again 127 determines the format of the InetAddress values. 129 The textual conventions defined in this document can be used to 130 define Internet addresses by using DNS domain names in addition to 131 IPv4 and IPv6 addresses. A MIB designer can write compliance 132 statements to express that only a subset of the possible address 133 types must be supported by a compliant implementation. 135 MIB developers who need to represent Internet addresses SHOULD use 136 these definitions whenever applicable, as opposed to defining their 137 own constructs. Even MIB modules that only need to represent IPv4 or 138 IPv6 addresses SHOULD use the InetAddressType/InetAddress textual 139 conventions defined in this memo. 141 There are many widely deployed MIB modules that use IPv4 addresses 142 and which need to be revised to support IPv6. These MIBs can be 143 categorized as follows: 145 1. MIB modules which define management information that is in 146 principle IP version neutral, but the MIB currently uses 147 addressing constructs specific to a certain IP version. 149 2. MIB modules which define management information that is specific 150 to particular IP version (either IPv4 or IPv6) and which is very 151 unlikely to ever be applicable to another IP version. 153 MIB modules of the first type SHOULD provide object definitions 154 (e.g., tables) that work with all versions of IP. In particular, 155 when revising a MIB module which contains IPv4 specific tables, it is 156 suggested to define new tables using the textual conventions defined 157 in this memo which support all versions of IP. The status of the new 158 tables SHOULD be "current" while the status of the old IP version 159 specific tables SHOULD be changed to "deprecated". The other 160 approach of having multiple similar tables for different IP versions 161 is strongly discouraged. 163 MIB modules of the second type, which are inherently IP version 164 specific, do not need to be redefined. Note that even in this case, 165 any additions to these MIB modules or new IP version specific MIB 166 modules SHOULD use the textual conventions defined in this memo. 168 MIB developers SHOULD NOT use the textual conventions defined in this 169 document to represent generic transport layer addresses. Instead the 170 SMIv2 TAddress textual convention and associated definitions should 171 be used for transport layer addresses. 173 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 174 this document are to be interpreted as described in RFC 2119 175 [RFC2119]. 177 2. The Internet-Standard Management Framework 179 For a detailed overview of the documents that describe the current 180 Internet-Standard Management Framework, please refer to section 7 of 181 RFC 3410 [RFC3410]. 183 Managed objects are accessed via a virtual information store, termed 184 the Management Information Base or MIB. MIB objects are generally 185 accessed through the Simple Network Management Protocol (SNMP). 186 Objects in the MIB are defined using the mechanisms defined in the 187 Structure of Management Information (SMI). This memo specifies a MIB 188 module that is compliant to the SMIv2, which is described in STD 58, 189 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 190 [RFC2580]. 192 3. Definitions 194 INET-ADDRESS-MIB DEFINITIONS ::= BEGIN 196 IMPORTS 197 MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI 198 TEXTUAL-CONVENTION FROM SNMPv2-TC; 200 inetAddressMIB MODULE-IDENTITY 201 LAST-UPDATED "200302230000Z" 202 ORGANIZATION 203 "IETF Operations and Management Area" 204 CONTACT-INFO 205 "Juergen Schoenwaelder (Editor) 206 TU Braunschweig 207 Bueltenweg 74/75 208 38106 Braunschweig, Germany 210 Phone: +49 531 391-3289 211 EMail: schoenw@ibr.cs.tu-bs.de 213 Send comments to ." 214 DESCRIPTION 215 "This MIB module defines textual conventions for 216 representing Internet addresses. An Internet 217 address can be an IPv4 address, an IPv6 address 218 or a DNS domain name. This module also defines 219 textual conventions for Internet port numbers, 220 autonomous system numbers and the length of an 221 Internet address prefix. 223 Copyright (C) The Internet Society (2002). This version 224 of this MIB module is part of RFC XXXX, see the RFC 225 itself for full legal notices." 226 REVISION "200302230000Z" 227 DESCRIPTION 228 "Third version, published as RFC XXXX. This revision 229 introduces the InetZoneIndex textual convention." 230 REVISION "200205090000Z" 231 DESCRIPTION 232 "Second version, published as RFC 3291. This 233 revisions contains several clarifications and it 234 introduces several new textual conventions: 235 InetAddressPrefixLength, InetPortNumber, 236 InetAutonomousSystemNumber, InetAddressIPv4z, 237 and InetAddressIPv6z." 238 REVISION "200006080000Z" 239 DESCRIPTION 240 "Initial version, published as RFC 2851." 241 ::= { mib-2 76 } 243 InetAddressType ::= TEXTUAL-CONVENTION 244 STATUS current 245 DESCRIPTION 246 "A value that represents a type of Internet address. 248 unknown(0) An unknown address type. This value MUST 249 be used if the value of the corresponding 250 InetAddress object is a zero-length string. 251 It may also be used to indicate an IP address 252 which is not in one of the formats defined 253 below. 255 ipv4(1) An IPv4 address as defined by the 256 InetAddressIPv4 textual convention. 258 ipv6(2) A global IPv6 address as defined by the 259 InetAddressIPv6 textual convention. 261 ipv4z(3) A non-global IPv4 address including a zone 262 index as defined by the InetAddressIPv4z 263 textual convention. 265 ipv6z(4) A non-global IPv6 address including a zone 266 index as defined by the InetAddressIPv6z 267 textual convention. 269 dns(16) A DNS domain name as defined by the 270 InetAddressDNS textual convention. 272 Each definition of a concrete InetAddressType value must be 273 accompanied by a definition of a textual convention for use 274 with that InetAddressType. 276 To support future extensions, the InetAddressType textual 277 convention SHOULD NOT be sub-typed in object type definitions. 278 It MAY be sub-typed in compliance statements in order to 279 require only a subset of these address types for a compliant 280 implementation. 282 Implementations must ensure that InetAddressType objects 283 and any dependent objects (e.g. InetAddress objects) are 284 consistent. An inconsistentValue error must be generated 285 if an attempt to change an InetAddressType object would, 286 for example, lead to an undefined InetAddress value. In 287 particular, InetAddressType/InetAddress pairs must be 288 changed together if the address type changes (e.g. from 289 ipv6(2) to ipv4(1))." 290 SYNTAX INTEGER { 291 unknown(0), 292 ipv4(1), 293 ipv6(2), 294 ipv4z(3), 295 ipv6z(4), 296 dns(16) 297 } 299 InetAddress ::= TEXTUAL-CONVENTION 300 STATUS current 301 DESCRIPTION 302 "Denotes a generic Internet address. 304 An InetAddress value is always interpreted within the context 305 of an InetAddressType value. Every usage of the InetAddress 306 textual convention is required to specify the InetAddressType 307 object which provides the context. It is suggested that the 308 InetAddressType object is logically registered before the 309 object(s) which use the InetAddress textual convention if 310 they appear in the same logical row. 312 The value of an InetAddress object must always be 313 consistent with the value of the associated InetAddressType 314 object. Attempts to set an InetAddress object to a value 315 which is inconsistent with the associated InetAddressType 316 must fail with an inconsistentValue error. 318 When this textual convention is used as the syntax of an 319 index object, there may be issues with the limit of 128 320 sub-identifiers specified in SMIv2, STD 58. In this case, 321 the object definition MUST include a 'SIZE' clause to 322 limit the number of potential instance sub-identifiers." 323 SYNTAX OCTET STRING (SIZE (0..255)) 325 InetAddressIPv4 ::= TEXTUAL-CONVENTION 326 DISPLAY-HINT "1d.1d.1d.1d" 327 STATUS current 328 DESCRIPTION 329 "Represents an IPv4 network address: 331 octets contents encoding 332 1-4 IPv4 address network-byte order 334 The corresponding InetAddressType value is ipv4(1). 336 This textual convention SHOULD NOT be used directly in object 337 definitions since it restricts addresses to a specific format. 338 However, if it is used, it MAY be used either on its own or in 339 conjunction with InetAddressType as a pair." 340 SYNTAX OCTET STRING (SIZE (4)) 342 InetAddressIPv6 ::= TEXTUAL-CONVENTION 343 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x" 344 STATUS current 345 DESCRIPTION 346 "Represents an IPv6 network address: 348 octets contents encoding 349 1-16 IPv6 address network-byte order 351 The corresponding InetAddressType value is ipv6(2). 353 This textual convention SHOULD NOT be used directly in object 354 definitions since it restricts addresses to a specific format. 355 However, if it is used, it MAY be used either on its own or in 356 conjunction with InetAddressType as a pair." 357 SYNTAX OCTET STRING (SIZE (16)) 359 InetAddressIPv4z ::= TEXTUAL-CONVENTION 360 DISPLAY-HINT "1d.1d.1d.1d%4d" 361 STATUS current 362 DESCRIPTION 363 "Represents a non-global IPv4 network address together 364 with its zone index: 366 octets contents encoding 367 1-4 IPv4 address network-byte order 368 5-8 zone index network-byte order 370 The corresponding InetAddressType value is ipv4z(3). 372 The zone index (bytes 5-8) is used to disambiguate identical 373 address values on nodes which have interfaces attached to 374 different zones of the same scope. The zone index may contain 375 the special value 0 which refers to the default zone for each 376 scope. 378 This textual convention SHOULD NOT be used directly in object 379 definitions since it restricts addresses to a specific format. 380 However, if it is used, it MAY be used either on its own or in 381 conjunction with InetAddressType as a pair." 382 SYNTAX OCTET STRING (SIZE (8)) 384 InetAddressIPv6z ::= TEXTUAL-CONVENTION 385 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 386 STATUS current 387 DESCRIPTION 388 "Represents a non-global IPv6 network address together 389 with its zone index: 391 octets contents encoding 392 1-16 IPv6 address network-byte order 393 17-20 zone index network-byte order 395 The corresponding InetAddressType value is ipv6z(4). 397 The zone index (bytes 17-20) is used to disambiguate 398 identical address values on nodes which have interfaces 399 attached to different zones of the same scope. The zone index 400 may contain the special value 0 which refers to the default 401 zone for each scope. 403 This textual convention SHOULD NOT be used directly in object 404 definitions since it restricts addresses to a specific format. 405 However, if it is used, it MAY be used either on its own or in 406 conjunction with InetAddressType as a pair." 407 SYNTAX OCTET STRING (SIZE (20)) 409 InetAddressDNS ::= TEXTUAL-CONVENTION 410 DISPLAY-HINT "255a" 411 STATUS current 412 DESCRIPTION 413 "Represents a DNS domain name. The name SHOULD be fully 414 qualified whenever possible. 416 The corresponding InetAddressType is dns(16). 418 The DESCRIPTION clause of InetAddress objects that may have 419 InetAddressDNS values must fully describe how (and when) such 420 names are to be resolved to IP addresses. 422 This textual convention SHOULD NOT be used directly in object 423 definitions since it restricts addresses to a specific format. 424 However, if it is used, it MAY be used either on its own or in 425 conjunction with InetAddressType as a pair." 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 within 437 the context of an InetAddressType value. Every usage of the 438 InetAddressPrefixLength textual convention is required to 439 specify the InetAddressType object which provides the 440 context. It is suggested that the InetAddressType object is 441 logically registered before the object(s) which use the 442 InetAddressPrefixLength textual convention if they appear in 443 the same logical row. 445 InetAddressPrefixLength values that are larger than 446 the maximum length of an IP address for a specific 447 InetAddressType are treated as the maximum significant 448 value applicable for the InetAddressType. The maximum 449 significant value is 32 for the InetAddressType 450 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 451 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value 452 for the InetAddressType 'dns(16)' is 0. 454 The value zero is object-specific and must be defined as 455 part of the description of any object which uses this 456 syntax. Examples of the usage of zero might include 457 situations where the Internet network address prefix 458 is unknown or does not apply." 459 SYNTAX Unsigned32 461 InetPortNumber ::= TEXTUAL-CONVENTION 462 STATUS current 463 DESCRIPTION 464 "Represents a 16 bit port number of an Internet transport 465 layer protocol. Port numbers are assigned by IANA. A 466 current list of all assignments is available from 467 . 469 The value zero is object-specific and must be defined as 470 part of the description of any object which uses this 471 syntax. Examples of the usage of zero might include 472 situations where a port number is unknown, or when the 473 value zero is used as a wildcard in a filter." 474 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 475 SYNTAX Unsigned32 (0..65535) 477 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 478 STATUS current 479 DESCRIPTION 480 "Represents an autonomous system number which identifies an 481 Autonomous System (AS). An AS is a set of routers under a 482 single technical administration, using an interior gateway 483 protocol and common metrics to route packets within the AS, 484 and using an exterior gateway protocol to route packets to 485 other ASs'. IANA maintains the AS number space and has 486 delegated large parts to the regional registries. 488 Autonomous system numbers are currently limited to 16 bits 489 (0..65535). There is however work in progress to enlarge the 490 autonomous system number space to 32 bits. This textual 491 convention therefore uses an Unsigned32 value without a 492 range restriction in order to support a larger autonomous 493 system number space." 494 REFERENCE "RFC 1771, RFC 1930" 495 SYNTAX Unsigned32 497 InetZoneIndex ::= TEXTUAL-CONVENTION 498 STATUS current 499 DESCRIPTION 500 "A zone index identifies an instance of a zone of a 501 specific scope. 503 The zone index MUST disambiguate identical address 504 values. For link-local addresses, the zone index will 505 typically be the interface index (ifIndex as defined in the 506 IF-MIB) of the interface on which the address is configured. 508 The zone index may contain the special value 0 which refers 509 to the default zone. The default zone may be used in cases 510 where the valid zone index is not known (e.g., a management 511 application needs to write a site-local IPv6 address without 512 knowing the site index value). The default zone SHOULD NOT be 513 used as an easy way out in cases where the zone index for a 514 non-global IPv6 address is known." 515 SYNTAX Unsigned32 516 END 518 4. Usage Hints 520 The InetAddressType and InetAddress textual conventions have been 521 introduced to avoid over-constraining an object definition by the use 522 of the IpAddress SMI base type which is IPv4 specific. An 523 InetAddressType/InetAddress pair can represent IP addresses in 524 various formats. 526 The InetAddressType and InetAddress objects SHOULD NOT be sub-typed 527 in object definitions. Sub-typing binds the MIB module to specific 528 address formats, which may cause serious problems if new address 529 formats need to be introduced. Note that it is possible to write 530 compliance statements in order to express that only a subset of the 531 defined address types must be implemented to be compliant. 533 Every usage of the InetAddress or InetAddressPrefixLength textual 534 conventions must specify which InetAddressType object provides the 535 context for the interpretation of the InetAddress or 536 InetAddressPrefixLength textual convention. 538 It is suggested that the InetAddressType object is logically 539 registered before the object(s) which uses the InetAddress or 540 InetAddressPrefixLength textual convention. An InetAddressType 541 object is logically registered before an InetAddress or 542 InetAddressPrefixLength object if it appears before the InetAddress 543 or InetAddressPrefixLength object in the conceptual row (which 544 includes any index objects). This rule allows programs such as MIB 545 compilers to identify the InetAddressType of a given InetAddress or 546 InetAddressPrefixLength object by searching for the InetAddressType 547 object which precedes an InetAddress or InetAddressPrefixLength 548 object. 550 4.1 Table Indexing 552 When a generic Internet address is used as an index, both the 553 InetAddressType and InetAddress objects MUST be used. The 554 InetAddressType object MUST be listed before the InetAddress object 555 in the INDEX clause. 557 The IMPLIED keyword MUST NOT be used for an object of type 558 InetAddress in an INDEX clause. Instance sub-identifiers are then of 559 the form T.N.O1.O2...On, where T is the value of the InetAddressType 560 object, O1...On are the octets in the InetAddress object, and N is 561 the number of those octets. 563 There is a meaningful lexicographical ordering to tables indexed in 564 this fashion. Command generator applications may lookup specific 565 addresses of known type and value, issue GetNext requests for 566 addresses of a single type, or issue GetNext requests for a specific 567 type and address prefix. 569 4.2 Uniqueness of Addresses 571 IPv4 addresses were intended to be globally unique, current usage 572 notwithstanding. IPv6 addresses were architected to have different 573 scopes and hence uniqueness [RFC2373]. In particular, IPv6 "link- 574 local" and "site-local" addresses are not guaranteed to be unique on 575 any particular node. In such cases, the duplicate addresses must be 576 configured on different interfaces. So the combination of an IPv6 577 address and a zone index is unique [IPv6Scoped]. 579 The InetAddressIPv6 textual convention has been defined to represent 580 global IPv6 addresses and non-global IPv6 addresses in cases where no 581 zone index is needed (e.g., on end hosts with a single interface). 582 The InetAddressIPv6z textual convention has been defined to represent 583 non-global IPv6 addresses in cases where a zone index is needed 584 (e.g., a router connecting multiple zones). MIB designers who use 585 InetAddressType/InetAddress pairs therefore do not need to define 586 additional objects in order to support non-global addresses on nodes 587 that connect multiple zones. 589 The InetAddressIPv4z is intended for use in MIBs (like the TCP-MIB) 590 which report addresses in the address family used on the wire, but 591 where the entity instrumented obtains such addresses from 592 applications or administrators in a form which includes a zone index, 593 such as v4-mapped IPv6 addresses. 595 The size of the zone index has been chosen so that it is consistent 596 with (i) the numerical zone index defined in [IPv6Scoped] and (ii) 597 the sin6_scope_id field of the sockaddr_in6 structure defined in RFC 598 2553 [RFC2553]. 600 4.3 Multiple Addresses per Host 602 A single host system may be configured with multiple addresses (IPv4 603 or IPv6), and possibly with multiple DNS names. Thus it is possible 604 for a single host system to be accessible by multiple 605 InetAddressType/InetAddress pairs. 607 If this could be an implementation or usage issue, the DESCRIPTION 608 clause of the relevant objects must fully describe which address is 609 reported in a given InetAddressType/InetAddress pair. 611 4.4 Resolving DNS Names 613 DNS names MUST be resolved to IP addresses when communication with 614 the named host is required. This raises a temporal aspect to 615 defining MIB objects whose value is a DNS name: When is the name 616 translated to an address? 618 For example, consider an object defined to indicate a forwarding 619 destination, and whose value is a DNS name. When does the forwarding 620 entity resolve the DNS name? Each time forwarding occurs or just once 621 when the object was instantiated? 623 The DESCRIPTION clause of such objects SHOULD precisely define how 624 and when any required name to address resolution is done. 626 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 627 define how and when a reverse lookup is being done if an agent has 628 accessed instrumentation that knows about an IP address and the MIB 629 module or implementation requires it to map the IP address to a DNS 630 name. 632 5. Table Indexing Example 634 This example shows a table listing communication peers that are 635 identified by either an IPv4 address, an IPv6 address or a DNS name. 636 The table definition also prohibits entries with an empty address 637 (whose type would be "unknown"). The size of a DNS name is limited 638 to 64 characters in order to satisfy OID length constraints. 640 peerTable OBJECT-TYPE 641 SYNTAX SEQUENCE OF PeerEntry 642 MAX-ACCESS not-accessible 643 STATUS current 644 DESCRIPTION 645 "A list of communication peers." 646 ::= { somewhere 1 } 648 peerEntry OBJECT-TYPE 649 SYNTAX PeerEntry 650 MAX-ACCESS not-accessible 651 STATUS current 652 DESCRIPTION 653 "An entry containing information about a particular peer." 654 INDEX { peerAddressType, peerAddress } 655 ::= { peerTable 1 } 657 PeerEntry ::= SEQUENCE { 658 peerAddressType InetAddressType, 659 peerAddress InetAddress, 660 peerStatus INTEGER 661 } 663 peerAddressType OBJECT-TYPE 664 SYNTAX InetAddressType 665 MAX-ACCESS not-accessible 666 STATUS current 667 DESCRIPTION 668 "The type of Internet address by which the peer 669 is reachable." 670 ::= { peerEntry 1 } 672 peerAddress OBJECT-TYPE 673 SYNTAX InetAddress (SIZE (1..64)) 674 MAX-ACCESS not-accessible 675 STATUS current 676 DESCRIPTION 677 "The Internet address for the peer. The type of this 678 address is determined by the value of the peerAddressType 679 object. Note that implementations must limit themselves 680 to a single entry in this table per reachable peer. 681 The peerAddress may not be empty due to the SIZE 682 restriction. 684 If a row is created administratively by an SNMP 685 operation and the address type value is dns(16), then 686 the agent stores the DNS name internally. A DNS name 687 lookup must be performed on the internally stored DNS 688 name whenever it is being used to contact the peer. 690 If a row is created by the managed entity itself and 691 the address type value is dns(16), then the agent 692 stores the IP address internally. A DNS reverse lookup 693 must be performed on the internally stored IP address 694 whenever the value is retrieved via SNMP." 695 ::= { peerEntry 2 } 697 The following compliance statement specifies that compliant 698 implementations need only support IPv4/IPv6 addresses without a zone 699 indices. Support for DNS names or IPv4/IPv6 addresses with zone 700 indices is not required. 702 peerCompliance MODULE-COMPLIANCE 703 STATUS current 704 DESCRIPTION 705 "The compliance statement of the peer MIB." 707 MODULE -- this module 708 MANDATORY-GROUPS { peerGroup } 710 OBJECT peerAddressType 711 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 712 DESCRIPTION 713 "An implementation is only required to support IPv4 714 and IPv6 addresses without zone indices." 716 ::= { somewhere 2 } 718 Note that the SMIv2 does not permit inclusion of not-accessible 719 objects in an object group (see section 3.1 in STD 58, RFC 2580 720 [RFC2580]). It is therefore not possible to formally refine the 721 syntax of auxiliary objects which are not-accessible. In such a 722 case, it is suggested to express the refinement informally in the 723 DESCRIPTION clause of the MODULE-COMPLIANCE macro invocation. 725 6. Security Considerations 727 This module does not define any management objects. Instead, it 728 defines a set of textual conventions which may be used by other MIB 729 modules to define management objects. 731 Meaningful security considerations can only be written in the MIB 732 modules that define management objects. This document has therefore 733 no impact on the security of the Internet. 735 7. Acknowledgments 737 This document was produced by the Operations and Management Area 738 "IPv6MIB" design team. The authors would like to thank Fred Baker, 739 Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro 740 Hagino, Mike Heard, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, 741 Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, 742 Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill 743 for their comments and suggestions. 745 8. Intellectual Property Notice 747 The IETF takes no position regarding the validity or scope of any 748 intellectual property or other rights that might be claimed to 749 pertain to the implementation or use of the technology described in 750 this document or the extent to which any license under such rights 751 might or might not be available; neither does it represent that it 752 has made any effort to identify any such rights. Information on the 753 IETF's procedures with respect to rights in standards-track and 754 standards-related documentation can be found in BCP 11. Copies of 755 claims of rights made available for publication and any assurances of 756 licenses to be made available, or the result of an attempt made to 757 obtain a general license or permission for the use of such 758 proprietary rights by implementors or users of this specification can 759 be obtained from the IETF Secretariat. 761 The IETF invites any interested party to bring to its attention any 762 copyrights, patents or patent applications, or other proprietary 763 rights which may cover technology that may be required to practice 764 this standard. Please address the information to the IETF Executive 765 Director. 767 9. Changes from RFC 3291 769 The following changes have been made relative to RFC 3291: 771 o Added a new textual convention InetZoneIndex 773 o Updated boilerplate text and references. 775 10. Changes from RFC 2851 777 The following changes have been made relative to RFC 2851: 779 o Added new textual conventions InetAddressPrefixLength, 780 InetPortNumber, and InetAutonomousSystemNumber. 782 o Rewrote the introduction to say clearly that in general, one 783 should define MIB tables that work with all versions of IP. The 784 other approach of multiple tables for different IP versions is 785 strongly discouraged. 787 o Added text to the InetAddressType and InetAddress descriptions 788 which requires that implementations must reject set operations 789 with an inconsistentValue error if they lead to inconsistencies. 791 o Removed the strict ordering constraints. Description clauses now 792 must explain which InetAddressType object provides the context for 793 an InetAddress or InetAddressPrefixLength object. 795 o Aligned wordings with the IPv6 scoping architecture document. 797 o Split the InetAddressIPv6 textual convention into the two textual 798 conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced 799 a new textual convention InetAddressIPv4z. Added ipv4z(3) and 800 ipv6z(4) named numbers to the InetAddressType enumeration. 801 Motivations for this change: (i) enable the introduction of a 802 textual conventions for non-global IPv4 addresses, (ii) alignment 803 with the textual conventions for transport addresses, (iii) 804 simpler compliance statements in cases where support for IPv6 805 addresses with zone indices is not required, (iv) simplify 806 implementations for host systems which will never have to report 807 zone indices. 809 Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 815 Rose, M. and S. Waldbusser, "Structure of Management 816 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 817 1999. 819 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 820 Rose, M. and S. Waldbusser, "Textual Conventions for 821 SMIv2", STD 58, RFC 2579, April 1999. 823 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 824 Rose, M. and S. Waldbusser, "Conformance Statements for 825 SMIv2", STD 58, RFC 2580, April 1999. 827 Informative References 829 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 830 "Introduction and Applicability Statements for the 831 Internet-Standard Management Framework", RFC 3410, 832 December 2002. 834 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 835 MIB", RFC 2863, June 2000. 837 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 838 Architecture", RFC 2373, July 1998. 840 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, 841 "Basic Socket Interface Extensions for IPv6", RFC 2553, 842 March 1999. 844 [IPv6Scoped] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., 845 Onoe, A. and B. Zill, "IPv6 Scoped Address 846 Architecture", draft-ietf-ipngwg-scoping-arch-04.txt, 847 June 2002. 849 Authors' Addresses 851 Mike Daniele 852 Consultant 853 19 Pinewood Rd 854 Hudson, NH 03051 855 USA 857 Phone: +1 603 883-6365 858 EMail: md@world.std.com 860 Brian Haberman 861 Consultant 862 USA 864 Phone: +1 919-949-4828 865 EMail: bkhabs@nc.rr.com 867 Shawn A. Routhier 868 Wind River Systems, Inc. 869 500 Wind River Way 870 Alameda, CA 94501 871 USA 873 Phone: +1 510 749-2095 874 EMail: sar@epilogue.com 875 Juergen Schoenwaelder 876 TU Braunschweig 877 Bueltenweg 74/75 878 38106 Braunschweig 879 Germany 881 Phone: +49 531 391-3289 882 EMail: schoenw@ibr.cs.tu-bs.de 884 Full Copyright Statement 886 Copyright (C) The Internet Society (2003). All Rights Reserved. 888 This document and translations of it may be copied and furnished to 889 others, and derivative works that comment on or otherwise explain it 890 or assist in its implementation may be prepared, copied, published 891 and distributed, in whole or in part, without restriction of any 892 kind, provided that the above copyright notice and this paragraph are 893 included on all such copies and derivative works. However, this 894 document itself may not be modified in any way, such as by removing 895 the copyright notice or references to the Internet Society or other 896 Internet organizations, except as needed for the purpose of 897 developing Internet standards in which case the procedures for 898 copyrights defined in the Internet Standards process must be 899 followed, or as required to translate it into languages other than 900 English. 902 The limited permissions granted above are perpetual and will not be 903 revoked by the Internet Society or its successors or assigns. 905 This document and the information contained herein is provided on an 906 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 907 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 908 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 909 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 910 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 912 Acknowledgement 914 Funding for the RFC Editor function is currently provided by the 915 Internet Society.