idnits 2.17.1 draft-ietf-ops-rfc3291bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 (June 7, 2004) is 7256 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 889, 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 Obsoletes: 3291 (if approved) B. Haberman 4 Expires: December 6, 2004 Caspian Networks 5 S. Routhier 6 Wind River Systems, Inc. 7 J. Schoenwaelder 8 International University Bremen 9 June 7, 2004 11 Textual Conventions for Internet Network Addresses 12 draft-ietf-ops-rfc3291bis-05.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 December 6, 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 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. The Internet-Standard Management Framework . . . . . . . . . . 5 51 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 13 53 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . 14 54 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . 14 55 4.3 Multiple Addresses per Host . . . . . . . . . . . . . . . 15 56 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . 15 57 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 16 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 59 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 60 8. Changes from RFC 3291 to RFC XXXX . . . . . . . . . . . . . . 18 61 9. Changes from RFC 2851 to RFC 3291 . . . . . . . . . . . . . . 18 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 64 10.2 Informative References . . . . . . . . . . . . . . . . . . . 20 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 66 Intellectual Property and Copyright Statements . . . . . . . . 22 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 "200406040000Z" 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 "200406040000Z" 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 The resolution of an InetAddressDNS value may require to 424 query multiple DNS records (e.g., A for IPv4 and AAAA for 425 IPv6). The order of the resolution process and which DNS 426 record takes precedence depends on the configuration of the 427 resolver. 429 This textual convention SHOULD NOT be used directly in object 430 definitions since it restricts addresses to a specific format. 431 However, if it is used, it MAY be used either on its own or in 432 conjunction with InetAddressType as a pair." 433 SYNTAX OCTET STRING (SIZE (1..255)) 435 InetAddressPrefixLength ::= TEXTUAL-CONVENTION 436 DISPLAY-HINT "d" 437 STATUS current 438 DESCRIPTION 439 "Denotes the length of a generic Internet network address 440 prefix. A value of n corresponds to an IP address mask 441 which has n contiguous 1-bits from the most significant 442 bit (MSB) and all other bits set to 0. 444 An InetAddressPrefixLength value is always interpreted within 445 the context of an InetAddressType value. Every usage of the 446 InetAddressPrefixLength textual convention is required to 447 specify the InetAddressType object which provides the 448 context. It is suggested that the InetAddressType object is 449 logically registered before the object(s) which use the 450 InetAddressPrefixLength textual convention if they appear in 451 the same logical row. 453 InetAddressPrefixLength values that are larger than 454 the maximum length of an IP address for a specific 455 InetAddressType are treated as the maximum significant 456 value applicable for the InetAddressType. The maximum 457 significant value is 32 for the InetAddressType 458 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 459 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value 460 for the InetAddressType 'dns(16)' is 0. 462 The value zero is object-specific and must be defined as 463 part of the description of any object which uses this 464 syntax. Examples of the usage of zero might include 465 situations where the Internet network address prefix 466 is unknown or does not apply. 468 The upper bound of the prefix length has been choosen to 469 be consistent with the maximum size of an InetAddress." 470 SYNTAX Unsigned32 (0..2040) 472 InetPortNumber ::= TEXTUAL-CONVENTION 473 DISPLAY-HINT "d" 474 STATUS current 475 DESCRIPTION 476 "Represents a 16 bit port number of an Internet transport 477 layer protocol. Port numbers are assigned by IANA. A 478 current list of all assignments is available from 479 . 481 The value zero is object-specific and must be defined as 482 part of the description of any object which uses this 483 syntax. Examples of the usage of zero might include 484 situations where a port number is unknown, or when the 485 value zero is used as a wildcard in a filter." 486 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 487 SYNTAX Unsigned32 (0..65535) 489 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 490 DISPLAY-HINT "d" 491 STATUS current 492 DESCRIPTION 493 "Represents an autonomous system number which identifies an 494 Autonomous System (AS). An AS is a set of routers under a 495 single technical administration, using an interior gateway 496 protocol and common metrics to route packets within the AS, 497 and using an exterior gateway protocol to route packets to 498 other ASs'. IANA maintains the AS number space and has 499 delegated large parts to the regional registries. 501 Autonomous system numbers are currently limited to 16 bits 502 (0..65535). There is however work in progress to enlarge the 503 autonomous system number space to 32 bits. This textual 504 convention therefore uses an Unsigned32 value without a 505 range restriction in order to support a larger autonomous 506 system number space." 507 REFERENCE "RFC 1771, RFC 1930" 508 SYNTAX Unsigned32 510 InetScopeType ::= TEXTUAL-CONVENTION 511 STATUS current 512 DESCRIPTION 513 "Represents a scope type. This textual convention can be used 514 in cases where a MIB has to represent different scope types 515 and there is no context information such as an InetAddress 516 object which implicitely defines the scope type. 518 Note that not all possible values have been assigned yet but 519 they may be assigned in future revisions of this specification. 520 Applications should therefore be able to deal with not yet 521 assigned values." 522 REFERENCE "RFC 3513" 523 SYNTAX INTEGER { 524 -- reserved(0), 525 interfaceLocal(1), 526 linkLocal(2), 527 subnetLocal(3), 528 adminLocal(4), 529 siteLocal(5), 530 -- unassigned(6), 531 -- unassigned(7), 532 organizationLocal(8), 533 -- unassigned(9), 534 -- unassigned(10), 535 -- unassigned(11), 536 -- unassigned(12), 537 -- unassigned(13), 538 global(14) 539 -- reserved(15) 540 } 542 InetZoneIndex ::= TEXTUAL-CONVENTION 543 DISPLAY-HINT "d" 544 STATUS current 545 DESCRIPTION 546 "A zone index identifies an instance of a zone of a 547 specific scope. 549 The zone index MUST disambiguate identical address 550 values. For link-local addresses, the zone index will 551 typically be the interface index (ifIndex as defined in the 552 IF-MIB) of the interface on which the address is configured. 554 The zone index may contain the special value 0 which refers 555 to the default zone. The default zone may be used in cases 556 where the valid zone index is not known (e.g., a management 557 application needs to write a site-local IPv6 address without 558 knowing the site index value). The default zone SHOULD NOT be 559 used as an easy way out in cases where the zone index for a 560 non-global IPv6 address is known." 561 REFERENCE "RFCZZZZ" 562 SYNTAX Unsigned32 564 InetVersion ::= TEXTUAL-CONVENTION 565 STATUS current 566 DESCRIPTION 567 "A value representing a version of the IP protocol. 569 unknown(0) An unknown or unspecified version of the IP 570 protocol. 572 ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5). 574 ipv6(2) The IPv6 protocol as defined in RFC 2460. 576 Note that this textual convention SHOULD NOT be used to 577 distinguish different address types associated with IP 578 protocols. The InetAddressType has been designed for this 579 purpose." 580 REFERENCE "RFC 791, RFC 2460" 581 SYNTAX INTEGER { 582 unknown(0), 583 ipv4(1), 584 ipv6(2) 585 } 586 END 588 4. Usage Hints 590 The InetAddressType and InetAddress textual conventions have been 591 introduced to avoid over-constraining an object definition by the use 592 of the IpAddress SMI base type which is IPv4 specific. An 593 InetAddressType/InetAddress pair can represent IP addresses in 594 various formats. 596 The InetAddressType and InetAddress objects SHOULD NOT be sub-typed 597 in object definitions. Sub-typing binds the MIB module to specific 598 address formats, which may cause serious problems if new address 599 formats need to be introduced. Note that it is possible to write 600 compliance statements in order to express that only a subset of the 601 defined address types must be implemented to be compliant. 603 Every usage of the InetAddress or InetAddressPrefixLength textual 604 conventions must specify which InetAddressType object provides the 605 context for the interpretation of the InetAddress or 606 InetAddressPrefixLength textual convention. 608 It is suggested that the InetAddressType object is logically 609 registered before the object(s) which uses the InetAddress or 610 InetAddressPrefixLength textual convention. An InetAddressType object 611 is logically registered before an InetAddress or 612 InetAddressPrefixLength object if it appears before the InetAddress 613 or InetAddressPrefixLength object in the conceptual row (which 614 includes any index objects). This rule allows programs such as MIB 615 compilers to identify the InetAddressType of a given InetAddress or 616 InetAddressPrefixLength object by searching for the InetAddressType 617 object which precedes an InetAddress or InetAddressPrefixLength 618 object. 620 4.1 Table Indexing 622 When a generic Internet address is used as an index, both the 623 InetAddressType and InetAddress objects MUST be used. The 624 InetAddressType object MUST be listed before the InetAddress object 625 in the INDEX clause. 627 The IMPLIED keyword MUST NOT be used for an object of type 628 InetAddress in an INDEX clause. Instance sub-identifiers are then of 629 the form T.N.O1.O2...On, where T is the value of the InetAddressType 630 object, O1...On are the octets in the InetAddress object, and N is 631 the number of those octets. 633 There is a meaningful lexicographical ordering to tables indexed in 634 this fashion. Command generator applications may lookup specific 635 addresses of known type and value, issue GetNext requests for 636 addresses of a single type, or issue GetNext requests for a specific 637 type and address prefix. 639 4.2 Uniqueness of Addresses 641 IPv4 addresses were intended to be globally unique, current usage 642 notwithstanding. IPv6 addresses were architected to have different 643 scopes and hence uniqueness [RFC3513]. In particular, IPv6 644 "link-local" unicast addresses are not guaranteed to be unique on any 645 particular node. In such cases, the duplicate addresses must be 646 configured on different interfaces. So the combination of an IPv6 647 address and a zone index is unique [RFCZZZZ]. 649 The InetAddressIPv6 textual convention has been defined to represent 650 global IPv6 addresses and non-global IPv6 addresses in cases where no 651 zone index is needed (e.g., on end hosts with a single interface). 652 The InetAddressIPv6z textual convention has been defined to represent 653 non-global IPv6 addresses in cases where a zone index is needed 654 (e.g., a router connecting multiple zones). MIB designers who use 655 InetAddressType/InetAddress pairs therefore do not need to define 656 additional objects in order to support non-global addresses on nodes 657 that connect multiple zones. 659 The InetAddressIPv4z is intended for use in MIBs (like the TCP-MIB) 660 which report addresses in the address family used on the wire, but 661 where the entity instrumented obtains such addresses from 662 applications or administrators in a form which includes a zone index, 663 such as v4-mapped IPv6 addresses. 665 The size of the zone index has been chosen so that it is consistent 666 with (i) the numerical zone index defined in [RFCZZZZ] and (ii) the 667 sin6_scope_id field of the sockaddr_in6 structure defined in RFC 2553 668 [RFC2553]. 670 4.3 Multiple Addresses per Host 672 A single host system may be configured with multiple addresses (IPv4 673 or IPv6), and possibly with multiple DNS names. Thus it is possible 674 for a single host system to be accessible by multiple 675 InetAddressType/InetAddress pairs. 677 If this could be an implementation or usage issue, the DESCRIPTION 678 clause of the relevant objects must fully describe which address is 679 reported in a given InetAddressType/InetAddress pair. 681 4.4 Resolving DNS Names 683 DNS names MUST be resolved to IP addresses when communication with 684 the named host is required. This raises a temporal aspect to defining 685 MIB objects whose value is a DNS name: When is the name translated to 686 an address? 688 For example, consider an object defined to indicate a forwarding 689 destination, and whose value is a DNS name. When does the forwarding 690 entity resolve the DNS name? Each time forwarding occurs or just once 691 when the object was instantiated? 692 The DESCRIPTION clause of such objects SHOULD precisely define how 693 and when any required name to address resolution is done. 695 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 696 define how and when a reverse lookup is being done if an agent has 697 accessed instrumentation that knows about an IP address and the MIB 698 module or implementation requires it to map the IP address to a DNS 699 name. 701 5. Table Indexing Example 703 This example shows a table listing communication peers that are 704 identified by either an IPv4 address, an IPv6 address or a DNS name. 705 The table definition also prohibits entries with an empty address 706 (whose type would be "unknown"). The size of a DNS name is limited to 707 64 characters in order to satisfy OID length constraints. 709 peerTable OBJECT-TYPE 710 SYNTAX SEQUENCE OF PeerEntry 711 MAX-ACCESS not-accessible 712 STATUS current 713 DESCRIPTION 714 "A list of communication peers." 715 ::= { somewhere 1 } 717 peerEntry OBJECT-TYPE 718 SYNTAX PeerEntry 719 MAX-ACCESS not-accessible 720 STATUS current 721 DESCRIPTION 722 "An entry containing information about a particular peer." 723 INDEX { peerAddressType, peerAddress } 724 ::= { peerTable 1 } 726 PeerEntry ::= SEQUENCE { 727 peerAddressType InetAddressType, 728 peerAddress InetAddress, 729 peerStatus INTEGER 730 } 732 peerAddressType OBJECT-TYPE 733 SYNTAX InetAddressType 734 MAX-ACCESS not-accessible 735 STATUS current 736 DESCRIPTION 737 "The type of Internet address by which the peer 738 is reachable." 740 ::= { peerEntry 1 } 742 peerAddress OBJECT-TYPE 743 SYNTAX InetAddress (SIZE (1..64)) 744 MAX-ACCESS not-accessible 745 STATUS current 746 DESCRIPTION 747 "The Internet address for the peer. The type of this 748 address is determined by the value of the peerAddressType 749 object. Note that implementations must limit themselves 750 to a single entry in this table per reachable peer. 751 The peerAddress may not be empty due to the SIZE 752 restriction. 754 If a row is created administratively by an SNMP 755 operation and the address type value is dns(16), then 756 the agent stores the DNS name internally. A DNS name 757 lookup must be performed on the internally stored DNS 758 name whenever it is being used to contact the peer. 760 If a row is created by the managed entity itself and 761 the address type value is dns(16), then the agent 762 stores the IP address internally. A DNS reverse lookup 763 must be performed on the internally stored IP address 764 whenever the value is retrieved via SNMP." 765 ::= { peerEntry 2 } 767 The following compliance statement specifies that compliant 768 implementations need only support IPv4/IPv6 addresses without a zone 769 indices. Support for DNS names or IPv4/IPv6 addresses with zone 770 indices is not required. 772 peerCompliance MODULE-COMPLIANCE 773 STATUS current 774 DESCRIPTION 775 "The compliance statement of the peer MIB." 777 MODULE -- this module 778 MANDATORY-GROUPS { peerGroup } 780 OBJECT peerAddressType 781 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 782 DESCRIPTION 783 "An implementation is only required to support IPv4 784 and IPv6 addresses without zone indices." 786 ::= { somewhere 2 } 788 Note that the SMIv2 does not permit inclusion of not-accessible 789 objects in an object group (see section 3.1 in STD 58, RFC 2580 790 [RFC2580]). It is therefore not possible to formally refine the 791 syntax of auxiliary objects which are not-accessible. In such a 792 case, it is suggested to express the refinement informally in the 793 DESCRIPTION clause of the MODULE-COMPLIANCE macro invocation. 795 6. Security Considerations 797 This module does not define any management objects. Instead, it 798 defines a set of textual conventions which may be used by other MIB 799 modules to define management objects. 801 Meaningful security considerations can only be written in the MIB 802 modules that define management objects. This document has therefore 803 no impact on the security of the Internet. 805 7. Acknowledgments 807 This document was produced by the Operations and Management Area 808 "IPv6MIB" design team. The authors would like to thank Fred Baker, 809 Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro 810 Hagino, Mike Heard, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, 811 Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, 812 Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill 813 for their comments and suggestions. 815 8. Changes from RFC 3291 to RFC XXXX 817 The following changes have been made relative to RFC 3291: 818 o Added a range restriction to the InetAddressPrefixLength textual 819 convention. 820 o Added new textual conventions InetZoneIndex, InetScopeType and 821 InetVersion. 822 o Added explicit "d" DISPLAY-HINTs for textual conventions that did 823 not have them. 824 o Updated boilerplate text and references. 826 9. Changes from RFC 2851 to RFC 3291 828 The following changes have been made relative to RFC 2851: 829 o Added new textual conventions InetAddressPrefixLength, 830 InetPortNumber, and InetAutonomousSystemNumber. 831 o Rewrote the introduction to say clearly that in general, one 832 should define MIB tables that work with all versions of IP. The 833 other approach of multiple tables for different IP versions is 834 strongly discouraged. 836 o Added text to the InetAddressType and InetAddress descriptions 837 which requires that implementations must reject set operations 838 with an inconsistentValue error if they lead to inconsistencies. 839 o Removed the strict ordering constraints. Description clauses now 840 must explain which InetAddressType object provides the context for 841 an InetAddress or InetAddressPrefixLength object. 842 o Aligned wordings with the IPv6 scoping architecture document. 843 o Split the InetAddressIPv6 textual convention into the two textual 844 conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced 845 a new textual convention InetAddressIPv4z. Added ipv4z(3) and 846 ipv6z(4) named numbers to the InetAddressType enumeration. 847 Motivations for this change: (i) enable the introduction of a 848 textual conventions for non-global IPv4 addresses, (ii) alignment 849 with the textual conventions for transport addresses, (iii) 850 simpler compliance statements in cases where support for IPv6 851 addresses with zone indices is not required, (iv) simplify 852 implementations for host systems which will never have to report 853 zone indices. 855 10. References 857 10.1 Normative References 859 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 860 Requirement Levels", BCP 14, RFC 2119, March 1997. 862 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 863 Rose, M. and S. Waldbusser, "Structure of Management 864 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 865 1999. 867 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 868 Rose, M. and S. Waldbusser, "Textual Conventions for 869 SMIv2", STD 58, RFC 2579, April 1999. 871 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 872 Rose, M. and S. Waldbusser, "Conformance Statements for 873 SMIv2", STD 58, RFC 2580, April 1999. 875 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 876 (IPv6) Addressing Architecture", RFC 3513, April 2003. 878 [RFCZZZZ] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, 879 A. and B. Zill, "IPv6 Scoped Address Architecture", 880 draft-ietf-ipv6-scoping-arch-00.txt, June 2003. 882 10.2 Informative References 884 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 885 "Introduction and Applicability Statements for the 886 Internet-Standard Management Framework", RFC 3410, 887 December 2002. 889 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 890 MIB", RFC 2863, June 2000. 892 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, 893 "Basic Socket Interface Extensions for IPv6", RFC 2553, 894 March 1999. 896 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 897 Transport Addresses", RFC 3419, December 2002. 899 Authors' Addresses 901 Mike Daniele 902 Consultant 903 19 Pinewood Rd 904 Hudson, NH 03051 905 USA 907 Phone: +1 603 883-6365 908 EMail: md@world.std.com 910 Brian Haberman 911 Caspian Networks 912 1 Park Drive, Suite 300 913 Research Triangle Park, NC 27709 914 USA 916 Phone: +1 919-949-4828 917 EMail: brian@innovationslab.net 919 Shawn A. Routhier 920 Wind River Systems, Inc. 921 500 Wind River Way 922 Alameda, CA 94501 923 USA 925 Phone: +1 510 749-2095 926 EMail: shawn.routhier@windriver.com 927 Juergen Schoenwaelder 928 International University Bremen 929 P.O. Box 750 561 930 28725 Bremen 931 Germany 933 Phone: +49 421 200-3587 934 EMail: j.schoenwaelder@iu-bremen.de 936 Intellectual Property Statement 938 The IETF takes no position regarding the validity or scope of any 939 intellectual property or other rights that might be claimed to 940 pertain to the implementation or use of the technology described in 941 this document or the extent to which any license under such rights 942 might or might not be available; neither does it represent that it 943 has made any effort to identify any such rights. Information on the 944 IETF's procedures with respect to rights in standards-track and 945 standards-related documentation can be found in BCP-11. Copies of 946 claims of rights made available for publication and any assurances of 947 licenses to be made available, or the result of an attempt made to 948 obtain a general license or permission for the use of such 949 proprietary rights by implementors or users of this specification can 950 be obtained from the IETF Secretariat. 952 The IETF invites any interested party to bring to its attention any 953 copyrights, patents or patent applications, or other proprietary 954 rights which may cover technology that may be required to practice 955 this standard. Please address the information to the IETF Executive 956 Director. 958 Full Copyright Statement 960 Copyright (C) The Internet Society (2004). All Rights Reserved. 962 This document and translations of it may be copied and furnished to 963 others, and derivative works that comment on or otherwise explain it 964 or assist in its implementation may be prepared, copied, published 965 and distributed, in whole or in part, without restriction of any 966 kind, provided that the above copyright notice and this paragraph are 967 included on all such copies and derivative works. However, this 968 document itself may not be modified in any way, such as by removing 969 the copyright notice or references to the Internet Society or other 970 Internet organizations, except as needed for the purpose of 971 developing Internet standards in which case the procedures for 972 copyrights defined in the Internet Standards process must be 973 followed, or as required to translate it into languages other than 974 English. 976 The limited permissions granted above are perpetual and will not be 977 revoked by the Internet Society or its successors or assignees. 979 This document and the information contained herein is provided on an 980 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 981 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 982 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 983 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 984 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 986 Acknowledgment 988 Funding for the RFC Editor function is currently provided by the 989 Internet Society.