idnits 2.17.1 draft-ietf-ops-rfc3291bis-03.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 25 instances of too long lines in the document, the longest one being 3 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 334 has weird spacing: '... octets cont...' == Line 351 has weird spacing: '... octets cont...' == Line 369 has weird spacing: '... octets cont...' == Line 394 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 (January 2, 2004) is 7420 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 900, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) == Outdated reference: A later version (-02) exists of draft-ietf-ipv6-scoping-arch-00 -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 MIB Design Team M. Daniele 2 Internet-Draft Consultant 3 Expires: July 2, 2004 B. Haberman 4 Caspian Networks 5 S. Routhier 6 Wind River Systems, Inc. 7 J. Schoenwaelder 8 International University Bremen 9 January 2, 2004 11 Textual Conventions for Internet Network Addresses 12 draft-ietf-ops-rfc3291bis-03.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 other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 2, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This MIB module defines textual conventions to represent commonly 43 used Internet network layer addressing information. The intent is 44 that these textual conventions will be imported and used in MIB 45 modules that would otherwise define their own representations. 47 This document obsoletes RFC 3291. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. The Internet-Standard Management Framework . . . . . . . . . . 5 53 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 13 55 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . . . 14 56 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . . . 14 57 4.3 Multiple Addresses per Host . . . . . . . . . . . . . . . . . 15 58 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . . . 15 59 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 16 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 61 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 62 8. Intellectual Property Notice . . . . . . . . . . . . . . . . . 18 63 9. Changes from RFC 3291 . . . . . . . . . . . . . . . . . . . . 18 64 10. Changes from RFC 2851 . . . . . . . . . . . . . . . . . . . . 19 65 Normative References . . . . . . . . . . . . . . . . . . . . . 19 66 Informative References . . . . . . . . . . . . . . . . . . . . 20 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 68 Intellectual Property and Copyright Statements . . . . . . . . 22 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 [RFC3513]. 78 This document defines multiple textual conventions (TCs) as a 79 mechanism to express generic Internet network layer addresses within 80 MIB module specifications. The solution is compatible with SMIv2 (STD 81 58) and SMIv1 (STD 16). New MIB definitions which need to express 82 network layer Internet addresses SHOULD use the textual conventions 83 defined in this memo. New MIB modules SHOULD NOT use the SMIv2 84 IpAddress 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 for well-known transport domains support 98 scoped Internet addresses. The scope of an Internet address is a 99 topological span within which the address may be used as a unique 100 identifier for an interface or set of interfaces. A scope zone, or 101 simply a zone, is a concrete connected region of topology of a given 102 scope. Note that a zone is a particular instance of a topological 103 region, whereas a scope is the size of a topological region 104 [RFCZZZZ]. Since Internet addresses on devices that connect multiple 105 zones are not necessarily unique, an additional zone index is needed 106 on these devices to select an interface. The textual conventions 107 InetAddressIPv4z and InetAddressIPv6z are provided to support 108 Internet addresses that include a zone index. In order to support 109 arbitrary combinations of scoped Internet addresses, MIB authors 110 SHOULD use a separate InetAddressType object for each InetAddress 111 object. 113 The textual conventions defined in this document can also be used to 114 represent generic Internet subnets and Internet address ranges. A 115 generic Internet subnet is represented by three objects, one whose 116 syntax is InetAddressType, a second one whose syntax is InetAddress 117 and a third one whose syntax is InetAddressPrefixLength. The 118 InetAddressType value again determines the concrete format of the 119 InetAddress value while the InetAddressPrefixLength identifies the 120 Internet network address prefix. 122 A generic range of consecutive Internet addresses is represented by 123 three objects. The first one has the syntax InetAddressType while the 124 remaining objects have the syntax InetAddress and specify the start 125 and end of the address range. The InetAddressType value again 126 determines the format of the InetAddress values. 128 The textual conventions defined in this document can be used to 129 define Internet addresses by using DNS domain names in addition to 130 IPv4 and IPv6 addresses. A MIB designer can write compliance 131 statements to express that only a subset of the possible address 132 types must be supported by a compliant implementation. 134 MIB developers who need to represent Internet addresses SHOULD use 135 these definitions whenever applicable, as opposed to defining their 136 own constructs. Even MIB modules that only need to represent IPv4 or 137 IPv6 addresses SHOULD use the InetAddressType/InetAddress textual 138 conventions defined in this memo. 140 There are many widely deployed MIB modules that use IPv4 addresses 141 and which need to be revised to support IPv6. These MIBs can be 142 categorized as follows: 144 1. MIB modules which define management information that is in 145 principle IP version neutral, but the MIB currently uses 146 addressing constructs specific to a certain IP version. 147 2. MIB modules which define management information that is specific 148 to particular IP version (either IPv4 or IPv6) and which is very 149 unlikely to ever be applicable to another IP version. 151 MIB modules of the first type SHOULD provide object definitions 152 (e.g., tables) that work with all versions of IP. In particular, when 153 revising a MIB module which contains IPv4 specific tables, it is 154 suggested to define new tables using the textual conventions defined 155 in this memo which support all versions of IP. The status of the new 156 tables SHOULD be "current" while the status of the old IP version 157 specific tables SHOULD be changed to "deprecated". The other approach 158 of having multiple similar tables for different IP versions is 159 strongly discouraged. 161 MIB modules of the second type, which are inherently IP version 162 specific, do not need to be redefined. Note that even in this case, 163 any additions to these MIB modules or new IP version specific MIB 164 modules SHOULD use the textual conventions defined in this memo. 166 MIB developers SHOULD NOT use the textual conventions defined in this 167 document to represent generic transport layer addresses. Instead the 168 SMIv2 TAddress textual convention and associated definitions should 169 be used for transport layer addresses. 171 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 172 this document are to be interpreted as described in RFC 2119 173 [RFC2119]. 175 2. The Internet-Standard Management Framework 177 For a detailed overview of the documents that describe the current 178 Internet-Standard Management Framework, please refer to section 7 of 179 RFC 3410 [RFC3410]. 181 Managed objects are accessed via a virtual information store, termed 182 the Management Information Base or MIB. MIB objects are generally 183 accessed through the Simple Network Management Protocol (SNMP). 184 Objects in the MIB are defined using the mechanisms defined in the 185 Structure of Management Information (SMI). This memo specifies a MIB 186 module that is compliant to the SMIv2, which is described in STD 58, 187 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 188 [RFC2580]. 190 3. Definitions 192 INET-ADDRESS-MIB DEFINITIONS ::= BEGIN 194 IMPORTS 195 MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI 196 TEXTUAL-CONVENTION FROM SNMPv2-TC; 198 inetAddressMIB MODULE-IDENTITY 199 LAST-UPDATED "200401020000Z" 200 ORGANIZATION 201 "IETF Operations and Management Area" 202 CONTACT-INFO 203 "Juergen Schoenwaelder (Editor) 204 International University Bremen 205 P.O. Box 750 561 206 28725 Bremen, Germany 208 Phone: +49 421 200-3587 209 EMail: j.schoenwaelder@iu-bremen.de 211 Send comments to ." 212 DESCRIPTION 213 "This MIB module defines textual conventions for 214 representing Internet addresses. An Internet 215 address can be an IPv4 address, an IPv6 address 216 or a DNS domain name. This module also defines 217 textual conventions for Internet port numbers, 218 autonomous system numbers and the length of an 219 Internet address prefix. 221 Copyright (C) The Internet Society (2003). This version 222 of this MIB module is part of RFC XXXX, see the RFC 223 itself for full legal notices." 224 REVISION "200401020000Z" 225 DESCRIPTION 226 "Third version, published as RFC XXXX. This revision 227 introduces the InetZoneIndex, InetScopeType and 228 InetVersion textual conventions." 229 REVISION "200205090000Z" 230 DESCRIPTION 231 "Second version, published as RFC 3291. This 232 revisions contains several clarifications and it 233 introduces several new textual conventions: 234 InetAddressPrefixLength, InetPortNumber, 235 InetAutonomousSystemNumber, InetAddressIPv4z, 236 and InetAddressIPv6z." 237 REVISION "200006080000Z" 238 DESCRIPTION 239 "Initial version, published as RFC 2851." 240 ::= { mib-2 76 } 242 InetAddressType ::= TEXTUAL-CONVENTION 243 STATUS current 244 DESCRIPTION 245 "A value that represents a type of Internet address. 247 unknown(0) An unknown address type. This value MUST 248 be used if the value of the corresponding 249 InetAddress object is a zero-length string. 250 It may also be used to indicate an IP address 251 which is not in one of the formats defined 252 below. 254 ipv4(1) An IPv4 address as defined by the 255 InetAddressIPv4 textual convention. 257 ipv6(2) An IPv6 address as defined by the 258 InetAddressIPv6 textual convention. 260 ipv4z(3) A non-global IPv4 address including a zone 261 index as defined by the InetAddressIPv4z 262 textual convention. 264 ipv6z(4) A non-global IPv6 address including a zone 265 index as defined by the InetAddressIPv6z 266 textual convention. 268 dns(16) A DNS domain name as defined by the 269 InetAddressDNS textual convention. 271 Each definition of a concrete InetAddressType value must be 272 accompanied by a definition of a textual convention for use 273 with that InetAddressType. 275 To support future extensions, the InetAddressType textual 276 convention SHOULD NOT be sub-typed in object type definitions. 277 It MAY be sub-typed in compliance statements in order to 278 require only a subset of these address types for a compliant 279 implementation. 281 Implementations must ensure that InetAddressType objects 282 and any dependent objects (e.g. InetAddress objects) are 283 consistent. An inconsistentValue error must be generated 284 if an attempt to change an InetAddressType object would, 285 for example, lead to an undefined InetAddress value. In 286 particular, InetAddressType/InetAddress pairs must be 287 changed together if the address type changes (e.g. from 288 ipv6(2) to ipv4(1))." 289 SYNTAX INTEGER { 290 unknown(0), 291 ipv4(1), 292 ipv6(2), 293 ipv4z(3), 294 ipv6z(4), 295 dns(16) 296 } 298 InetAddress ::= TEXTUAL-CONVENTION 299 STATUS current 300 DESCRIPTION 301 "Denotes a generic Internet address. 303 An InetAddress value is always interpreted within the context 304 of an InetAddressType value. Every usage of the InetAddress 305 textual convention is required to specify the InetAddressType 306 object which provides the context. It is suggested that the 307 InetAddressType object is logically registered before the 308 object(s) which use the InetAddress textual convention if 309 they appear in the same logical row. 311 The value of an InetAddress object must always be 312 consistent with the value of the associated InetAddressType 313 object. Attempts to set an InetAddress object to a value 314 which is inconsistent with the associated InetAddressType 315 must fail with an inconsistentValue error. 317 When this textual convention is used as the syntax of an 318 index object, there may be issues with the limit of 128 319 sub-identifiers specified in SMIv2, STD 58. In this case, 320 the object definition MUST include a 'SIZE' clause to 321 limit the number of potential instance sub-identifiers 322 or else the applicable constraints MUST be stated in 323 the appropriate conceptual row DESCRIPTION clauses or 324 in the surrounding documentation if there is no single 325 DESCRIPTION clause that is appropriate." 326 SYNTAX OCTET STRING (SIZE (0..255)) 328 InetAddressIPv4 ::= TEXTUAL-CONVENTION 329 DISPLAY-HINT "1d.1d.1d.1d" 330 STATUS current 331 DESCRIPTION 332 "Represents an IPv4 network address: 334 octets contents encoding 335 1-4 IPv4 address network-byte order 337 The corresponding InetAddressType value is ipv4(1). 339 This textual convention SHOULD NOT be used directly in object 340 definitions since it restricts addresses to a specific format. 341 However, if it is used, it MAY be used either on its own or in 342 conjunction with InetAddressType as a pair." 343 SYNTAX OCTET STRING (SIZE (4)) 345 InetAddressIPv6 ::= TEXTUAL-CONVENTION 346 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x" 347 STATUS current 348 DESCRIPTION 349 "Represents an IPv6 network address: 351 octets contents encoding 352 1-16 IPv6 address network-byte order 354 The corresponding InetAddressType value is ipv6(2). 356 This textual convention SHOULD NOT be used directly in object 357 definitions since it restricts addresses to a specific format. 358 However, if it is used, it MAY be used either on its own or in 359 conjunction with InetAddressType as a pair." 360 SYNTAX OCTET STRING (SIZE (16)) 362 InetAddressIPv4z ::= TEXTUAL-CONVENTION 363 DISPLAY-HINT "1d.1d.1d.1d%4d" 364 STATUS current 365 DESCRIPTION 366 "Represents a non-global IPv4 network address together 367 with its zone index: 369 octets contents encoding 370 1-4 IPv4 address network-byte order 371 5-8 zone index network-byte order 373 The corresponding InetAddressType value is ipv4z(3). 375 The zone index (bytes 5-8) is used to disambiguate identical 376 address values on nodes which have interfaces attached to 377 different zones of the same scope. The zone index may contain 378 the special value 0 which refers to the default zone for each 379 scope. 381 This textual convention SHOULD NOT be used directly in object 382 definitions since it restricts addresses to a specific format. 383 However, if it is used, it MAY be used either on its own or in 384 conjunction with InetAddressType as a pair." 385 SYNTAX OCTET STRING (SIZE (8)) 387 InetAddressIPv6z ::= TEXTUAL-CONVENTION 388 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 389 STATUS current 390 DESCRIPTION 391 "Represents a non-global IPv6 network address together 392 with its zone index: 394 octets contents encoding 395 1-16 IPv6 address network-byte order 396 17-20 zone index network-byte order 398 The corresponding InetAddressType value is ipv6z(4). 400 The zone index (bytes 17-20) is used to disambiguate 401 identical address values on nodes which have interfaces 402 attached to different zones of the same scope. The zone index 403 may contain the special value 0 which refers to the default 404 zone for each scope. 406 This textual convention SHOULD NOT be used directly in object 407 definitions since it restricts addresses to a specific format. 408 However, if it is used, it MAY be used either on its own or in 409 conjunction with InetAddressType as a pair." 410 SYNTAX OCTET STRING (SIZE (20)) 412 InetAddressDNS ::= TEXTUAL-CONVENTION 413 DISPLAY-HINT "255a" 414 STATUS current 415 DESCRIPTION 416 "Represents a DNS domain name. The name SHOULD be fully 417 qualified whenever possible. 419 The corresponding InetAddressType is dns(16). 421 The DESCRIPTION clause of InetAddress objects that may have 422 InetAddressDNS values must fully describe how (and when) such 423 names are to be resolved to IP addresses. 425 This textual convention SHOULD NOT be used directly in object 426 definitions since it restricts addresses to a specific format. 427 However, if it is used, it MAY be used either on its own or in 428 conjunction with InetAddressType as a pair." 429 SYNTAX OCTET STRING (SIZE (1..255)) 431 InetAddressPrefixLength ::= TEXTUAL-CONVENTION 432 DISPLAY-HINT "d" 433 STATUS current 434 DESCRIPTION 435 "Denotes the length of a generic Internet network address 436 prefix. A value of n corresponds to an IP address mask 437 which has n contiguous 1-bits from the most significant 438 bit (MSB) and all other bits set to 0. 440 An InetAddressPrefixLength value is always interpreted within 441 the context of an InetAddressType value. Every usage of the 442 InetAddressPrefixLength textual convention is required to 443 specify the InetAddressType object which provides the 444 context. It is suggested that the InetAddressType object is 445 logically registered before the object(s) which use the 446 InetAddressPrefixLength textual convention if they appear in 447 the same logical row. 449 InetAddressPrefixLength values that are larger than 450 the maximum length of an IP address for a specific 451 InetAddressType are treated as the maximum significant 452 value applicable for the InetAddressType. The maximum 453 significant value is 32 for the InetAddressType 454 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 455 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value 456 for the InetAddressType 'dns(16)' is 0. 458 The value zero is object-specific and must be defined as 459 part of the description of any object which uses this 460 syntax. Examples of the usage of zero might include 461 situations where the Internet network address prefix 462 is unknown or does not apply." 463 SYNTAX Unsigned32 465 InetPortNumber ::= TEXTUAL-CONVENTION 466 DISPLAY-HINT "d" 467 STATUS current 468 DESCRIPTION 469 "Represents a 16 bit port number of an Internet transport 470 layer protocol. Port numbers are assigned by IANA. A 471 current list of all assignments is available from 472 . 474 The value zero is object-specific and must be defined as 475 part of the description of any object which uses this 476 syntax. Examples of the usage of zero might include 477 situations where a port number is unknown, or when the 478 value zero is used as a wildcard in a filter." 479 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 480 SYNTAX Unsigned32 (0..65535) 482 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 483 DISPLAY-HINT "d" 484 STATUS current 485 DESCRIPTION 486 "Represents an autonomous system number which identifies an 487 Autonomous System (AS). An AS is a set of routers under a 488 single technical administration, using an interior gateway 489 protocol and common metrics to route packets within the AS, 490 and using an exterior gateway protocol to route packets to 491 other ASs'. IANA maintains the AS number space and has 492 delegated large parts to the regional registries. 494 Autonomous system numbers are currently limited to 16 bits 495 (0..65535). There is however work in progress to enlarge the 496 autonomous system number space to 32 bits. This textual 497 convention therefore uses an Unsigned32 value without a 498 range restriction in order to support a larger autonomous 499 system number space." 500 REFERENCE "RFC 1771, RFC 1930" 501 SYNTAX Unsigned32 503 InetScopeType ::= TEXTUAL-CONVENTION 504 STATUS current 505 DESCRIPTION 506 "Represents a scope type. This textual convention can be used 507 in cases where a MIB has to represent different scope types 508 and there is no context information such as an InetAddress 509 object which implicitely defines the scope type. 511 Note that not all possible values have been assigned yet but 512 they may be assigned in future revisions of this specification. 513 Applications should therefore be able to deal with not yet 514 assigned values." 515 REFERENCE "RFC 3513" 516 SYNTAX INTEGER { 517 -- reserved(0), 518 interfaceLocal(1), 519 linkLocal(2), 520 subnetLocal(3), 521 adminLocal(4), 522 siteLocal(5), 523 -- unassigned(6), 524 -- unassigned(7), 525 organizationLocal(8), 526 -- unassigned(9), 527 -- unassigned(10), 528 -- unassigned(11), 529 -- unassigned(12), 530 -- unassigned(13), 531 global(14) 532 -- reserved(15) 533 } 535 InetZoneIndex ::= TEXTUAL-CONVENTION 536 DISPLAY-HINT "d" 537 STATUS current 538 DESCRIPTION 539 "A zone index identifies an instance of a zone of a 540 specific scope. 542 The zone index MUST disambiguate identical address 543 values. For link-local addresses, the zone index will 544 typically be the interface index (ifIndex as defined in the 545 IF-MIB) of the interface on which the address is configured. 547 The zone index may contain the special value 0 which refers 548 to the default zone. The default zone may be used in cases 549 where the valid zone index is not known (e.g., a management 550 application needs to write a site-local IPv6 address without 551 knowing the site index value). The default zone SHOULD NOT be 552 used as an easy way out in cases where the zone index for a 553 non-global IPv6 address is known." 554 REFERENCE "RFCZZZZ" 555 SYNTAX Unsigned32 557 InetVersion ::= TEXTUAL-CONVENTION 558 STATUS current 559 DESCRIPTION 560 "A value representing a version of the IP protocol. 562 unknown(0) An unknown or unspecified version of the IP 563 protocol. 565 ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5). 567 ipv6(2) The IPv6 protocol as defined in RFC 2460. 569 Note that this textual convention SHOULD NOT be used to 570 distinguish different address types associated with IP 571 protocols. The InetAddressType has been designed for this 572 purpose." 573 REFERENCE "RFC 791, RFC 2460" 574 SYNTAX INTEGER { 575 unknown(0), 576 ipv4(1), 577 ipv6(2) 578 } 579 END 581 4. Usage Hints 583 The InetAddressType and InetAddress textual conventions have been 584 introduced to avoid over-constraining an object definition by the use 585 of the IpAddress SMI base type which is IPv4 specific. An 586 InetAddressType/InetAddress pair can represent IP addresses in 587 various formats. 589 The InetAddressType and InetAddress objects SHOULD NOT be sub-typed 590 in object definitions. Sub-typing binds the MIB module to specific 591 address formats, which may cause serious problems if new address 592 formats need to be introduced. Note that it is possible to write 593 compliance statements in order to express that only a subset of the 594 defined address types must be implemented to be compliant. 596 Every usage of the InetAddress or InetAddressPrefixLength textual 597 conventions must specify which InetAddressType object provides the 598 context for the interpretation of the InetAddress or 599 InetAddressPrefixLength textual convention. 601 It is suggested that the InetAddressType object is logically 602 registered before the object(s) which uses the InetAddress or 603 InetAddressPrefixLength textual convention. An InetAddressType object 604 is logically registered before an InetAddress or 605 InetAddressPrefixLength object if it appears before the InetAddress 606 or InetAddressPrefixLength object in the conceptual row (which 607 includes any index objects). This rule allows programs such as MIB 608 compilers to identify the InetAddressType of a given InetAddress or 609 InetAddressPrefixLength object by searching for the InetAddressType 610 object which precedes an InetAddress or InetAddressPrefixLength 611 object. 613 4.1 Table Indexing 615 When a generic Internet address is used as an index, both the 616 InetAddressType and InetAddress objects MUST be used. The 617 InetAddressType object MUST be listed before the InetAddress object 618 in the INDEX clause. 620 The IMPLIED keyword MUST NOT be used for an object of type 621 InetAddress in an INDEX clause. Instance sub-identifiers are then of 622 the form T.N.O1.O2...On, where T is the value of the InetAddressType 623 object, O1...On are the octets in the InetAddress object, and N is 624 the number of those octets. 626 There is a meaningful lexicographical ordering to tables indexed in 627 this fashion. Command generator applications may lookup specific 628 addresses of known type and value, issue GetNext requests for 629 addresses of a single type, or issue GetNext requests for a specific 630 type and address prefix. 632 4.2 Uniqueness of Addresses 634 IPv4 addresses were intended to be globally unique, current usage 635 notwithstanding. IPv6 addresses were architected to have different 636 scopes and hence uniqueness [RFC3513]. In particular, IPv6 637 "link-local" unicast addresses are not guaranteed to be unique on any 638 particular node. In such cases, the duplicate addresses must be 639 configured on different interfaces. So the combination of an IPv6 640 address and a zone index is unique [RFCZZZZ]. 642 The InetAddressIPv6 textual convention has been defined to represent 643 global IPv6 addresses and non-global IPv6 addresses in cases where no 644 zone index is needed (e.g., on end hosts with a single interface). 645 The InetAddressIPv6z textual convention has been defined to represent 646 non-global IPv6 addresses in cases where a zone index is needed 647 (e.g., a router connecting multiple zones). MIB designers who use 648 InetAddressType/InetAddress pairs therefore do not need to define 649 additional objects in order to support non-global addresses on nodes 650 that connect multiple zones. 652 The InetAddressIPv4z is intended for use in MIBs (like the TCP-MIB) 653 which report addresses in the address family used on the wire, but 654 where the entity instrumented obtains such addresses from 655 applications or administrators in a form which includes a zone index, 656 such as v4-mapped IPv6 addresses. 658 The size of the zone index has been chosen so that it is consistent 659 with (i) the numerical zone index defined in [RFCZZZZ] and (ii) the 660 sin6_scope_id field of the sockaddr_in6 structure defined in RFC 2553 661 [RFC2553]. 663 4.3 Multiple Addresses per Host 665 A single host system may be configured with multiple addresses (IPv4 666 or IPv6), and possibly with multiple DNS names. Thus it is possible 667 for a single host system to be accessible by multiple 668 InetAddressType/InetAddress pairs. 670 If this could be an implementation or usage issue, the DESCRIPTION 671 clause of the relevant objects must fully describe which address is 672 reported in a given InetAddressType/InetAddress pair. 674 4.4 Resolving DNS Names 676 DNS names MUST be resolved to IP addresses when communication with 677 the named host is required. This raises a temporal aspect to defining 678 MIB objects whose value is a DNS name: When is the name translated to 679 an address? 681 For example, consider an object defined to indicate a forwarding 682 destination, and whose value is a DNS name. When does the forwarding 683 entity resolve the DNS name? Each time forwarding occurs or just once 684 when the object was instantiated? 686 The DESCRIPTION clause of such objects SHOULD precisely define how 687 and when any required name to address resolution is done. 689 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 690 define how and when a reverse lookup is being done if an agent has 691 accessed instrumentation that knows about an IP address and the MIB 692 module or implementation requires it to map the IP address to a DNS 693 name. 695 5. Table Indexing Example 697 This example shows a table listing communication peers that are 698 identified by either an IPv4 address, an IPv6 address or a DNS name. 699 The table definition also prohibits entries with an empty address 700 (whose type would be "unknown"). The size of a DNS name is limited to 701 64 characters in order to satisfy OID length constraints. 703 peerTable OBJECT-TYPE 704 SYNTAX SEQUENCE OF PeerEntry 705 MAX-ACCESS not-accessible 706 STATUS current 707 DESCRIPTION 708 "A list of communication peers." 709 ::= { somewhere 1 } 711 peerEntry OBJECT-TYPE 712 SYNTAX PeerEntry 713 MAX-ACCESS not-accessible 714 STATUS current 715 DESCRIPTION 716 "An entry containing information about a particular peer." 717 INDEX { peerAddressType, peerAddress } 718 ::= { peerTable 1 } 720 PeerEntry ::= SEQUENCE { 721 peerAddressType InetAddressType, 722 peerAddress InetAddress, 723 peerStatus INTEGER 724 } 726 peerAddressType OBJECT-TYPE 727 SYNTAX InetAddressType 728 MAX-ACCESS not-accessible 729 STATUS current 730 DESCRIPTION 731 "The type of Internet address by which the peer 732 is reachable." 733 ::= { peerEntry 1 } 735 peerAddress OBJECT-TYPE 736 SYNTAX InetAddress (SIZE (1..64)) 737 MAX-ACCESS not-accessible 738 STATUS current 739 DESCRIPTION 740 "The Internet address for the peer. The type of this 741 address is determined by the value of the peerAddressType 742 object. Note that implementations must limit themselves 743 to a single entry in this table per reachable peer. 744 The peerAddress may not be empty due to the SIZE 745 restriction. 747 If a row is created administratively by an SNMP 748 operation and the address type value is dns(16), then 749 the agent stores the DNS name internally. A DNS name 750 lookup must be performed on the internally stored DNS 751 name whenever it is being used to contact the peer. 753 If a row is created by the managed entity itself and 754 the address type value is dns(16), then the agent 755 stores the IP address internally. A DNS reverse lookup 756 must be performed on the internally stored IP address 757 whenever the value is retrieved via SNMP." 758 ::= { peerEntry 2 } 760 The following compliance statement specifies that compliant 761 implementations need only support IPv4/IPv6 addresses without a zone 762 indices. Support for DNS names or IPv4/IPv6 addresses with zone 763 indices is not required. 765 peerCompliance MODULE-COMPLIANCE 766 STATUS current 767 DESCRIPTION 768 "The compliance statement of the peer MIB." 770 MODULE -- this module 771 MANDATORY-GROUPS { peerGroup } 773 OBJECT peerAddressType 774 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 775 DESCRIPTION 776 "An implementation is only required to support IPv4 777 and IPv6 addresses without zone indices." 779 ::= { somewhere 2 } 781 Note that the SMIv2 does not permit inclusion of not-accessible 782 objects in an object group (see section 3.1 in STD 58, RFC 2580 783 [RFC2580]). It is therefore not possible to formally refine the 784 syntax of auxiliary objects which are not-accessible. In such a 785 case, it is suggested to express the refinement informally in the 786 DESCRIPTION clause of the MODULE-COMPLIANCE macro invocation. 788 6. Security Considerations 790 This module does not define any management objects. Instead, it 791 defines a set of textual conventions which may be used by other MIB 792 modules to define management objects. 794 Meaningful security considerations can only be written in the MIB 795 modules that define management objects. This document has therefore 796 no impact on the security of the Internet. 798 7. Acknowledgments 800 This document was produced by the Operations and Management Area 801 "IPv6MIB" design team. The authors would like to thank Fred Baker, 802 Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro 803 Hagino, Mike Heard, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, 804 Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, 805 Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill 806 for their comments and suggestions. 808 8. Intellectual Property Notice 810 The IETF takes no position regarding the validity or scope of any 811 intellectual property or other rights that might be claimed to 812 pertain to the implementation or use of the technology described in 813 this document or the extent to which any license under such rights 814 might or might not be available; neither does it represent that it 815 has made any effort to identify any such rights. Information on the 816 IETF's procedures with respect to rights in standards-track and 817 standards-related documentation can be found in BCP 11. Copies of 818 claims of rights made available for publication and any assurances of 819 licenses to be made available, or the result of an attempt made to 820 obtain a general license or permission for the use of such 821 proprietary rights by implementors or users of this specification can 822 be obtained from the IETF Secretariat. 824 The IETF invites any interested party to bring to its attention any 825 copyrights, patents or patent applications, or other proprietary 826 rights which may cover technology that may be required to practice 827 this standard. Please address the information to the IETF Executive 828 Director. 830 9. Changes from RFC 3291 832 The following changes have been made relative to RFC 3291: 833 o Added new textual conventions InetZoneIndex, InetScopeType and 834 InetVersion. 836 o Added explicit "d" DISPLAY-HINTs for textual conventions that did 837 not have them. 838 o Updated boilerplate text and references. 840 10. Changes from RFC 2851 842 The following changes have been made relative to RFC 2851: 843 o Added new textual conventions InetAddressPrefixLength, 844 InetPortNumber, and InetAutonomousSystemNumber. 845 o Rewrote the introduction to say clearly that in general, one 846 should define MIB tables that work with all versions of IP. The 847 other approach of multiple tables for different IP versions is 848 strongly discouraged. 849 o Added text to the InetAddressType and InetAddress descriptions 850 which requires that implementations must reject set operations 851 with an inconsistentValue error if they lead to inconsistencies. 852 o Removed the strict ordering constraints. Description clauses now 853 must explain which InetAddressType object provides the context for 854 an InetAddress or InetAddressPrefixLength object. 855 o Aligned wordings with the IPv6 scoping architecture document. 856 o Split the InetAddressIPv6 textual convention into the two textual 857 conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced 858 a new textual convention InetAddressIPv4z. Added ipv4z(3) and 859 ipv6z(4) named numbers to the InetAddressType enumeration. 860 Motivations for this change: (i) enable the introduction of a 861 textual conventions for non-global IPv4 addresses, (ii) alignment 862 with the textual conventions for transport addresses, (iii) 863 simpler compliance statements in cases where support for IPv6 864 addresses with zone indices is not required, (iv) simplify 865 implementations for host systems which will never have to report 866 zone indices. 868 Normative References 870 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 871 Requirement Levels", BCP 14, RFC 2119, March 1997. 873 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 874 Rose, M. and S. Waldbusser, "Structure of Management 875 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 876 1999. 878 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 879 Rose, M. and S. Waldbusser, "Textual Conventions for 880 SMIv2", STD 58, RFC 2579, April 1999. 882 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 883 Rose, M. and S. Waldbusser, "Conformance Statements for 884 SMIv2", STD 58, RFC 2580, April 1999. 886 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 887 (IPv6) Addressing Architecture", RFC 3513, April 2003. 889 [RFCZZZZ] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, 890 A. and B. Zill, "IPv6 Scoped Address Architecture", 891 draft-ietf-ipv6-scoping-arch-00.txt, June 2003. 893 Informative References 895 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 896 "Introduction and Applicability Statements for the 897 Internet-Standard Management Framework", RFC 3410, 898 December 2002. 900 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 901 MIB", RFC 2863, June 2000. 903 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, 904 "Basic Socket Interface Extensions for IPv6", RFC 2553, 905 March 1999. 907 Authors' Addresses 909 Mike Daniele 910 Consultant 911 19 Pinewood Rd 912 Hudson, NH 03051 913 USA 915 Phone: +1 603 883-6365 916 EMail: md@world.std.com 918 Brian Haberman 919 Caspian Networks 920 1 Park Drive, Suite 300 921 Research Triangle Park, NC 27709 922 USA 924 Phone: +1 919-949-4828 925 EMail: brian@innovationslab.net 926 Shawn A. Routhier 927 Wind River Systems, Inc. 928 500 Wind River Way 929 Alameda, CA 94501 930 USA 932 Phone: +1 510 749-2095 933 EMail: sar@epilogue.com 935 Juergen Schoenwaelder 936 International University Bremen 937 P.O. Box 750 561 938 28725 Bremen 939 Germany 941 Phone: +49 421 200-3587 942 EMail: j.schoenwaelder@iu-bremen.de 944 Intellectual Property Statement 946 The IETF takes no position regarding the validity or scope of any 947 intellectual property or other rights that might be claimed to 948 pertain to the implementation or use of the technology described in 949 this document or the extent to which any license under such rights 950 might or might not be available; neither does it represent that it 951 has made any effort to identify any such rights. Information on the 952 IETF's procedures with respect to rights in standards-track and 953 standards-related documentation can be found in BCP-11. Copies of 954 claims of rights made available for publication and any assurances of 955 licenses to be made available, or the result of an attempt made to 956 obtain a general license or permission for the use of such 957 proprietary rights by implementors or users of this specification can 958 be obtained from the IETF Secretariat. 960 The IETF invites any interested party to bring to its attention any 961 copyrights, patents or patent applications, or other proprietary 962 rights which may cover technology that may be required to practice 963 this standard. Please address the information to the IETF Executive 964 Director. 966 Full Copyright Statement 968 Copyright (C) The Internet Society (2004). All Rights Reserved. 970 This document and translations of it may be copied and furnished to 971 others, and derivative works that comment on or otherwise explain it 972 or assist in its implementation may be prepared, copied, published 973 and distributed, in whole or in part, without restriction of any 974 kind, provided that the above copyright notice and this paragraph are 975 included on all such copies and derivative works. However, this 976 document itself may not be modified in any way, such as by removing 977 the copyright notice or references to the Internet Society or other 978 Internet organizations, except as needed for the purpose of 979 developing Internet standards in which case the procedures for 980 copyrights defined in the Internet Standards process must be 981 followed, or as required to translate it into languages other than 982 English. 984 The limited permissions granted above are perpetual and will not be 985 revoked by the Internet Society or its successors or assignees. 987 This document and the information contained herein is provided on an 988 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 989 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 990 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 991 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 992 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 994 Acknowledgment 996 Funding for the RFC Editor function is currently provided by the 997 Internet Society.