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