idnits 2.17.1 draft-ietf-ops-rfc3291bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 966. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 982), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 338 has weird spacing: '... octets cont...' == Line 355 has weird spacing: '... octets cont...' == Line 373 has weird spacing: '... octets cont...' == Line 398 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 (August 16, 2004) is 7186 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 897, 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-01 -- Obsolete informational reference (is this intentional?): RFC 2553 (Obsoleted by RFC 3493) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Daniele 2 Internet-Draft Consultant 3 Obsoletes: 3291 (if approved) B. Haberman 4 Expires: February 14, 2005 Caspian Networks 5 S. Routhier 6 Wind River Systems, Inc. 7 J. Schoenwaelder 8 International University Bremen 9 August 16, 2004 11 Textual Conventions for Internet Network Addresses 12 draft-ietf-ops-rfc3291bis-06.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on February 14, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 This MIB module defines textual conventions to represent commonly 46 used Internet network layer addressing information. The intent is 47 that these textual conventions will be imported and used in MIB 48 modules that would otherwise define their own representations. 50 This document obsoletes RFC 3291. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. The Internet-Standard Management Framework . . . . . . . . . . 5 56 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4. Usage Hints . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 4.1 Table Indexing . . . . . . . . . . . . . . . . . . . . . . 14 59 4.2 Uniqueness of Addresses . . . . . . . . . . . . . . . . . 14 60 4.3 Multiple Addresses per Host . . . . . . . . . . . . . . . 15 61 4.4 Resolving DNS Names . . . . . . . . . . . . . . . . . . . 15 62 5. Table Indexing Example . . . . . . . . . . . . . . . . . . . . 16 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 66 9. Changes from RFC 3291 to RFC XXXX . . . . . . . . . . . . . . 18 67 10. Changes from RFC 2851 to RFC 3291 . . . . . . . . . . . . . 18 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 69 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 70 11.2 Informative References . . . . . . . . . . . . . . . . . . . 20 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 72 Intellectual Property and Copyright Statements . . . . . . . . 22 74 1. Introduction 76 Several standard-track MIB modules use the IpAddress SMIv2 base type. 77 This limits the applicability of these MIB modules to IP Version 4 78 (IPv4) since the IpAddress SMIv2 base type can only contain 4 byte 79 IPv4 addresses. The IpAddress SMIv2 base type has become problematic 80 with the introduction of IP Version 6 (IPv6) addresses [RFC3513]. 82 This document defines multiple textual conventions (TCs) as a 83 mechanism to express generic Internet network layer addresses within 84 MIB module specifications. The solution is compatible with SMIv2 85 (STD 58) and SMIv1 (STD 16). New MIB definitions which need to 86 express network layer Internet addresses SHOULD use the textual 87 conventions defined in this memo. New MIB modules SHOULD NOT use the 88 SMIv2 IpAddress base type anymore. 90 A generic Internet address consists of two objects, one whose syntax 91 is InetAddressType, and another whose syntax is InetAddress. The 92 value of the first object determines how the value of the second 93 object is encoded. The InetAddress textual convention represents an 94 opaque Internet address value. The InetAddressType enumeration is 95 used to "cast" the InetAddress value into a concrete textual 96 convention for the address type. This usage of multiple textual 97 conventions allows expression of the display characteristics of each 98 address type and makes the set of defined Internet address types 99 extensible. 101 The textual conventions for well-known transport domains support 102 scoped Internet addresses. The scope of an Internet address is a 103 topological span within which the address may be used as a unique 104 identifier for an interface or set of interfaces. A scope zone, or 105 simply a zone, is a concrete connected region of topology of a given 106 scope. Note that a zone is a particular instance of a topological 107 region, whereas a scope is the size of a topological region 108 [RFCZZZZ]. Since Internet addresses on devices that connect multiple 109 zones are not necessarily unique, an additional zone index is needed 110 on these devices to select an interface. The textual conventions 111 InetAddressIPv4z and InetAddressIPv6z are provided to support 112 Internet addresses that include a zone index. In order to support 113 arbitrary combinations of scoped Internet addresses, MIB authors 114 SHOULD use a separate InetAddressType object for each InetAddress 115 object. 117 The textual conventions defined in this document can also be used to 118 represent generic Internet subnets and Internet address ranges. A 119 generic Internet subnet is represented by three objects, one whose 120 syntax is InetAddressType, a second one whose syntax is InetAddress 121 and a third one whose syntax is InetAddressPrefixLength. The 122 InetAddressType value again determines the concrete format of the 123 InetAddress value while the InetAddressPrefixLength identifies the 124 Internet network address prefix. 126 A generic range of consecutive Internet addresses is represented by 127 three objects. The first one has the syntax InetAddressType while 128 the remaining objects have the syntax InetAddress and specify the 129 start and end of the address range. The InetAddressType value again 130 determines the format of the InetAddress values. 132 The textual conventions defined in this document can be used to 133 define Internet addresses by using DNS domain names in addition to 134 IPv4 and IPv6 addresses. A MIB designer can write compliance 135 statements to express that only a subset of the possible address 136 types must be supported by a compliant implementation. 138 MIB developers who need to represent Internet addresses SHOULD use 139 these definitions whenever applicable, as opposed to defining their 140 own constructs. Even MIB modules that only need to represent IPv4 or 141 IPv6 addresses SHOULD use the InetAddressType/InetAddress textual 142 conventions defined in this memo. 144 There are many widely deployed MIB modules that use IPv4 addresses 145 and which need to be revised to support IPv6. These MIBs can be 146 categorized as follows: 148 1. MIB modules which define management information that is in 149 principle IP version neutral, but the MIB currently uses 150 addressing constructs specific to a certain IP version. 151 2. MIB modules which define management information that is specific 152 to particular IP version (either IPv4 or IPv6) and which is very 153 unlikely to ever be applicable to another IP version. 155 MIB modules of the first type SHOULD provide object definitions 156 (e.g., tables) that work with all versions of IP. In particular, 157 when revising a MIB module which contains IPv4 specific tables, it is 158 suggested to define new tables using the textual conventions defined 159 in this memo which support all versions of IP. The status of the new 160 tables SHOULD be "current" while the status of the old IP version 161 specific tables SHOULD be changed to "deprecated". The other 162 approach of having multiple similar tables for different IP versions 163 is strongly discouraged. 165 MIB modules of the second type, which are inherently IP version 166 specific, do not need to be redefined. Note that even in this case, 167 any additions to these MIB modules or new IP version specific MIB 168 modules SHOULD use the textual conventions defined in this memo. 170 MIB developers SHOULD NOT use the textual conventions defined in this 171 document to represent generic transport layer addresses. A special 172 set of textual conventions for this purpose is defined in RFC 3419 173 [RFC3419]. 175 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 176 this document are to be interpreted as described in RFC 2119 177 [RFC2119]. 179 2. The Internet-Standard Management Framework 181 For a detailed overview of the documents that describe the current 182 Internet-Standard Management Framework, please refer to section 7 of 183 RFC 3410 [RFC3410]. 185 Managed objects are accessed via a virtual information store, termed 186 the Management Information Base or MIB. MIB objects are generally 187 accessed through the Simple Network Management Protocol (SNMP). 188 Objects in the MIB are defined using the mechanisms defined in the 189 Structure of Management Information (SMI). This memo specifies a MIB 190 module that is compliant to the SMIv2, which is described in STD 58, 191 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 192 [RFC2580]. 194 3. Definitions 196 INET-ADDRESS-MIB DEFINITIONS ::= BEGIN 198 IMPORTS 199 MODULE-IDENTITY, mib-2, Unsigned32 FROM SNMPv2-SMI 200 TEXTUAL-CONVENTION FROM SNMPv2-TC; 202 inetAddressMIB MODULE-IDENTITY 203 LAST-UPDATED "200408110000Z" 204 ORGANIZATION 205 "IETF Operations and Management Area" 206 CONTACT-INFO 207 "Juergen Schoenwaelder (Editor) 208 International University Bremen 209 P.O. Box 750 561 210 28725 Bremen, Germany 212 Phone: +49 421 200-3587 213 EMail: j.schoenwaelder@iu-bremen.de 215 Send comments to ." 216 DESCRIPTION 217 "This MIB module defines textual conventions for 218 representing Internet addresses. An Internet 219 address can be an IPv4 address, an IPv6 address 220 or a DNS domain name. This module also defines 221 textual conventions for Internet port numbers, 222 autonomous system numbers and the length of an 223 Internet address prefix. 225 Copyright (C) The Internet Society (2004). This version 226 of this MIB module is part of RFC XXXX, see the RFC 227 itself for full legal notices." 228 REVISION "200408110000Z" 229 DESCRIPTION 230 "Third version, published as RFC XXXX. This revision 231 introduces the InetZoneIndex, InetScopeType and 232 InetVersion textual conventions." 233 REVISION "200205090000Z" 234 DESCRIPTION 235 "Second version, published as RFC 3291. This 236 revisions contains several clarifications and it 237 introduces several new textual conventions: 238 InetAddressPrefixLength, InetPortNumber, 239 InetAutonomousSystemNumber, InetAddressIPv4z, 240 and InetAddressIPv6z." 241 REVISION "200006080000Z" 242 DESCRIPTION 243 "Initial version, published as RFC 2851." 244 ::= { mib-2 76 } 246 InetAddressType ::= TEXTUAL-CONVENTION 247 STATUS current 248 DESCRIPTION 249 "A value that represents a type of Internet address. 251 unknown(0) An unknown address type. This value MUST 252 be used if the value of the corresponding 253 InetAddress object is a zero-length string. 254 It may also be used to indicate an IP address 255 which is not in one of the formats defined 256 below. 258 ipv4(1) An IPv4 address as defined by the 259 InetAddressIPv4 textual convention. 261 ipv6(2) An IPv6 address as defined by the 262 InetAddressIPv6 textual convention. 264 ipv4z(3) A non-global IPv4 address including a zone 265 index as defined by the InetAddressIPv4z 266 textual convention. 268 ipv6z(4) A non-global IPv6 address including a zone 269 index as defined by the InetAddressIPv6z 270 textual convention. 272 dns(16) A DNS domain name as defined by the 273 InetAddressDNS textual convention. 275 Each definition of a concrete InetAddressType value must be 276 accompanied by a definition of a textual convention for use 277 with that InetAddressType. 279 To support future extensions, the InetAddressType textual 280 convention SHOULD NOT be sub-typed in object type definitions. 281 It MAY be sub-typed in compliance statements in order to 282 require only a subset of these address types for a compliant 283 implementation. 285 Implementations must ensure that InetAddressType objects 286 and any dependent objects (e.g. InetAddress objects) are 287 consistent. An inconsistentValue error must be generated 288 if an attempt to change an InetAddressType object would, 289 for example, lead to an undefined InetAddress value. In 290 particular, InetAddressType/InetAddress pairs must be 291 changed together if the address type changes (e.g. from 292 ipv6(2) to ipv4(1))." 293 SYNTAX INTEGER { 294 unknown(0), 295 ipv4(1), 296 ipv6(2), 297 ipv4z(3), 298 ipv6z(4), 299 dns(16) 300 } 302 InetAddress ::= TEXTUAL-CONVENTION 303 STATUS current 304 DESCRIPTION 305 "Denotes a generic Internet address. 307 An InetAddress value is always interpreted within the context 308 of an InetAddressType value. Every usage of the InetAddress 309 textual convention is required to specify the InetAddressType 310 object which provides the context. It is suggested that the 311 InetAddressType object is logically registered before the 312 object(s) which use the InetAddress textual convention if 313 they appear in the same logical row. 315 The value of an InetAddress object must always be 316 consistent with the value of the associated InetAddressType 317 object. Attempts to set an InetAddress object to a value 318 which is inconsistent with the associated InetAddressType 319 must fail with an inconsistentValue error. 321 When this textual convention is used as the syntax of an 322 index object, there may be issues with the limit of 128 323 sub-identifiers specified in SMIv2, STD 58. In this case, 324 the object definition MUST include a 'SIZE' clause to 325 limit the number of potential instance sub-identifiers 326 or else the applicable constraints MUST be stated in 327 the appropriate conceptual row DESCRIPTION clauses or 328 in the surrounding documentation if there is no single 329 DESCRIPTION clause that is appropriate." 330 SYNTAX OCTET STRING (SIZE (0..255)) 332 InetAddressIPv4 ::= TEXTUAL-CONVENTION 333 DISPLAY-HINT "1d.1d.1d.1d" 334 STATUS current 335 DESCRIPTION 336 "Represents an IPv4 network address: 338 octets contents encoding 339 1-4 IPv4 address network-byte order 341 The corresponding InetAddressType value is ipv4(1). 343 This textual convention SHOULD NOT be used directly in object 344 definitions since it restricts addresses to a specific format. 345 However, if it is used, it MAY be used either on its own or in 346 conjunction with InetAddressType as a pair." 347 SYNTAX OCTET STRING (SIZE (4)) 349 InetAddressIPv6 ::= TEXTUAL-CONVENTION 350 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x" 351 STATUS current 352 DESCRIPTION 353 "Represents an IPv6 network address: 355 octets contents encoding 356 1-16 IPv6 address network-byte order 358 The corresponding InetAddressType value is ipv6(2). 360 This textual convention SHOULD NOT be used directly in object 361 definitions since it restricts addresses to a specific format. 362 However, if it is used, it MAY be used either on its own or in 363 conjunction with InetAddressType as a pair." 364 SYNTAX OCTET STRING (SIZE (16)) 366 InetAddressIPv4z ::= TEXTUAL-CONVENTION 367 DISPLAY-HINT "1d.1d.1d.1d%4d" 368 STATUS current 369 DESCRIPTION 370 "Represents a non-global IPv4 network address together 371 with its zone index: 373 octets contents encoding 374 1-4 IPv4 address network-byte order 375 5-8 zone index network-byte order 377 The corresponding InetAddressType value is ipv4z(3). 379 The zone index (bytes 5-8) is used to disambiguate identical 380 address values on nodes which have interfaces attached to 381 different zones of the same scope. The zone index may contain 382 the special value 0 which refers to the default zone for each 383 scope. 385 This textual convention SHOULD NOT be used directly in object 386 definitions since it restricts addresses to a specific format. 387 However, if it is used, it MAY be used either on its own or in 388 conjunction with InetAddressType as a pair." 389 SYNTAX OCTET STRING (SIZE (8)) 391 InetAddressIPv6z ::= TEXTUAL-CONVENTION 392 DISPLAY-HINT "2x:2x:2x:2x:2x:2x:2x:2x%4d" 393 STATUS current 394 DESCRIPTION 395 "Represents a non-global IPv6 network address together 396 with its zone index: 398 octets contents encoding 399 1-16 IPv6 address network-byte order 400 17-20 zone index network-byte order 402 The corresponding InetAddressType value is ipv6z(4). 404 The zone index (bytes 17-20) is used to disambiguate 405 identical address values on nodes which have interfaces 406 attached to different zones of the same scope. The zone index 407 may contain the special value 0 which refers to the default 408 zone for each scope. 410 This textual convention SHOULD NOT be used directly in object 411 definitions since it restricts addresses to a specific format. 412 However, if it is used, it MAY be used either on its own or in 413 conjunction with InetAddressType as a pair." 414 SYNTAX OCTET STRING (SIZE (20)) 416 InetAddressDNS ::= TEXTUAL-CONVENTION 417 DISPLAY-HINT "255a" 418 STATUS current 419 DESCRIPTION 420 "Represents a DNS domain name. The name SHOULD be fully 421 qualified whenever possible. 423 The corresponding InetAddressType is dns(16). 425 The DESCRIPTION clause of InetAddress objects that may have 426 InetAddressDNS values MUST fully describe how (and when) such 427 names are to be resolved to IP addresses. 429 The resolution of an InetAddressDNS value may require to 430 query multiple DNS records (e.g., A for IPv4 and AAAA for 431 IPv6). The order of the resolution process and which DNS 432 record takes precedence depends on the configuration of the 433 resolver. 435 This textual convention SHOULD NOT be used directly in object 436 definitions since it restricts addresses to a specific format. 437 However, if it is used, it MAY be used either on its own or in 438 conjunction with InetAddressType as a pair." 439 SYNTAX OCTET STRING (SIZE (1..255)) 441 InetAddressPrefixLength ::= TEXTUAL-CONVENTION 442 DISPLAY-HINT "d" 443 STATUS current 444 DESCRIPTION 445 "Denotes the length of a generic Internet network address 446 prefix. A value of n corresponds to an IP address mask 447 which has n contiguous 1-bits from the most significant 448 bit (MSB) and all other bits set to 0. 450 An InetAddressPrefixLength value is always interpreted within 451 the context of an InetAddressType value. Every usage of the 452 InetAddressPrefixLength textual convention is required to 453 specify the InetAddressType object which provides the 454 context. It is suggested that the InetAddressType object is 455 logically registered before the object(s) which use the 456 InetAddressPrefixLength textual convention if they appear in 457 the same logical row. 459 InetAddressPrefixLength values that are larger than 460 the maximum length of an IP address for a specific 461 InetAddressType are treated as the maximum significant 462 value applicable for the InetAddressType. The maximum 463 significant value is 32 for the InetAddressType 464 'ipv4(1)' and 'ipv4z(3)' and 128 for the InetAddressType 465 'ipv6(2)' and 'ipv6z(4)'. The maximum significant value 466 for the InetAddressType 'dns(16)' is 0. 468 The value zero is object-specific and must be defined as 469 part of the description of any object which uses this 470 syntax. Examples of the usage of zero might include 471 situations where the Internet network address prefix 472 is unknown or does not apply. 474 The upper bound of the prefix length has been choosen to 475 be consistent with the maximum size of an InetAddress." 476 SYNTAX Unsigned32 (0..2040) 478 InetPortNumber ::= TEXTUAL-CONVENTION 479 DISPLAY-HINT "d" 480 STATUS current 481 DESCRIPTION 482 "Represents a 16 bit port number of an Internet transport 483 layer protocol. Port numbers are assigned by IANA. A 484 current list of all assignments is available from 485 . 487 The value zero is object-specific and must be defined as 488 part of the description of any object which uses this 489 syntax. Examples of the usage of zero might include 490 situations where a port number is unknown, or when the 491 value zero is used as a wildcard in a filter." 492 REFERENCE "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960" 493 SYNTAX Unsigned32 (0..65535) 495 InetAutonomousSystemNumber ::= TEXTUAL-CONVENTION 496 DISPLAY-HINT "d" 497 STATUS current 498 DESCRIPTION 499 "Represents an autonomous system number which identifies an 500 Autonomous System (AS). An AS is a set of routers under a 501 single technical administration, using an interior gateway 502 protocol and common metrics to route packets within the AS, 503 and using an exterior gateway protocol to route packets to 504 other ASs'. IANA maintains the AS number space and has 505 delegated large parts to the regional registries. 507 Autonomous system numbers are currently limited to 16 bits 508 (0..65535). There is however work in progress to enlarge the 509 autonomous system number space to 32 bits. This textual 510 convention therefore uses an Unsigned32 value without a 511 range restriction in order to support a larger autonomous 512 system number space." 513 REFERENCE "RFC 1771, RFC 1930" 514 SYNTAX Unsigned32 516 InetScopeType ::= TEXTUAL-CONVENTION 517 STATUS current 518 DESCRIPTION 519 "Represents a scope type. This textual convention can be used 520 in cases where a MIB has to represent different scope types 521 and there is no context information such as an InetAddress 522 object which implicitely defines the scope type. 524 Note that not all possible values have been assigned yet but 525 they may be assigned in future revisions of this specification. 526 Applications should therefore be able to deal with not yet 527 assigned values." 528 REFERENCE "RFC 3513" 529 SYNTAX INTEGER { 530 -- reserved(0), 531 interfaceLocal(1), 532 linkLocal(2), 533 subnetLocal(3), 534 adminLocal(4), 535 siteLocal(5), 536 -- unassigned(6), 537 -- unassigned(7), 538 organizationLocal(8), 539 -- unassigned(9), 540 -- unassigned(10), 541 -- unassigned(11), 542 -- unassigned(12), 543 -- unassigned(13), 544 global(14) 545 -- reserved(15) 546 } 548 InetZoneIndex ::= TEXTUAL-CONVENTION 549 DISPLAY-HINT "d" 550 STATUS current 551 DESCRIPTION 552 "A zone index identifies an instance of a zone of a 553 specific scope. 555 The zone index MUST disambiguate identical address 556 values. For link-local addresses, the zone index will 557 typically be the interface index (ifIndex as defined in the 558 IF-MIB) of the interface on which the address is configured. 560 The zone index may contain the special value 0 which refers 561 to the default zone. The default zone may be used in cases 562 where the valid zone index is not known (e.g., a management 563 application needs to write a link-local IPv6 address without 564 knowing the interface index value). The default zone SHOULD 565 NOT be used as an easy way out in cases where the zone index 566 for a non-global IPv6 address is known." 567 REFERENCE "RFCZZZZ" 568 SYNTAX Unsigned32 570 InetVersion ::= TEXTUAL-CONVENTION 571 STATUS current 572 DESCRIPTION 573 "A value representing a version of the IP protocol. 575 unknown(0) An unknown or unspecified version of the IP 576 protocol. 578 ipv4(1) The IPv4 protocol as defined in RFC 791 (STD 5). 580 ipv6(2) The IPv6 protocol as defined in RFC 2460. 582 Note that this textual convention SHOULD NOT be used to 583 distinguish different address types associated with IP 584 protocols. The InetAddressType has been designed for this 585 purpose." 586 REFERENCE "RFC 791, RFC 2460" 587 SYNTAX INTEGER { 588 unknown(0), 589 ipv4(1), 590 ipv6(2) 591 } 592 END 594 4. Usage Hints 596 The InetAddressType and InetAddress textual conventions have been 597 introduced to avoid over-constraining an object definition by the use 598 of the IpAddress SMI base type which is IPv4 specific. An 599 InetAddressType/InetAddress pair can represent IP addresses in 600 various formats. 602 The InetAddressType and InetAddress objects SHOULD NOT be sub-typed 603 in object definitions. Sub-typing binds the MIB module to specific 604 address formats, which may cause serious problems if new address 605 formats need to be introduced. Note that it is possible to write 606 compliance statements in order to express that only a subset of the 607 defined address types must be implemented to be compliant. 609 Every usage of the InetAddress or InetAddressPrefixLength textual 610 conventions must specify which InetAddressType object provides the 611 context for the interpretation of the InetAddress or 612 InetAddressPrefixLength textual convention. 614 It is suggested that the InetAddressType object is logically 615 registered before the object(s) which uses the InetAddress or 616 InetAddressPrefixLength textual convention. An InetAddressType 617 object is logically registered before an InetAddress or 618 InetAddressPrefixLength object if it appears before the InetAddress 619 or InetAddressPrefixLength object in the conceptual row (which 620 includes any index objects). This rule allows programs such as MIB 621 compilers to identify the InetAddressType of a given InetAddress or 622 InetAddressPrefixLength object by searching for the InetAddressType 623 object which precedes an InetAddress or InetAddressPrefixLength 624 object. 626 4.1 Table Indexing 628 When a generic Internet address is used as an index, both the 629 InetAddressType and InetAddress objects MUST be used. The 630 InetAddressType object MUST be listed before the InetAddress object 631 in the INDEX clause. 633 The IMPLIED keyword MUST NOT be used for an object of type 634 InetAddress in an INDEX clause. Instance sub-identifiers are then of 635 the form T.N.O1.O2...On, where T is the value of the InetAddressType 636 object, O1...On are the octets in the InetAddress object, and N is 637 the number of those octets. 639 There is a meaningful lexicographical ordering to tables indexed in 640 this fashion. Command generator applications may lookup specific 641 addresses of known type and value, issue GetNext requests for 642 addresses of a single type, or issue GetNext requests for a specific 643 type and address prefix. 645 4.2 Uniqueness of Addresses 647 IPv4 addresses were intended to be globally unique, current usage 648 notwithstanding. IPv6 addresses were architected to have different 649 scopes and hence uniqueness [RFC3513]. In particular, IPv6 650 "link-local" unicast addresses are not guaranteed to be unique on any 651 particular node. In such cases, the duplicate addresses must be 652 configured on different interfaces. So the combination of an IPv6 653 address and a zone index is unique [RFCZZZZ]. 655 The InetAddressIPv6 textual convention has been defined to represent 656 global IPv6 addresses and non-global IPv6 addresses in cases where no 657 zone index is needed (e.g., on end hosts with a single interface). 658 The InetAddressIPv6z textual convention has been defined to represent 659 non-global IPv6 addresses in cases where a zone index is needed 660 (e.g., a router connecting multiple zones). MIB designers who use 661 InetAddressType/InetAddress pairs therefore do not need to define 662 additional objects in order to support non-global addresses on nodes 663 that connect multiple zones. 665 The InetAddressIPv4z is intended for use in MIBs (like the TCP-MIB) 666 which report addresses in the address family used on the wire, but 667 where the entity instrumented obtains such addresses from 668 applications or administrators in a form which includes a zone index, 669 such as v4-mapped IPv6 addresses. 671 The size of the zone index has been chosen so that it is consistent 672 with (i) the numerical zone index defined in [RFCZZZZ] and (ii) the 673 sin6_scope_id field of the sockaddr_in6 structure defined in RFC 2553 674 [RFC2553]. 676 4.3 Multiple Addresses per Host 678 A single host system may be configured with multiple addresses (IPv4 679 or IPv6), and possibly with multiple DNS names. Thus it is possible 680 for a single host system to be accessible by multiple 681 InetAddressType/InetAddress pairs. 683 If this could be an implementation or usage issue, the DESCRIPTION 684 clause of the relevant objects must fully describe which address is 685 reported in a given InetAddressType/InetAddress pair. 687 4.4 Resolving DNS Names 689 DNS names MUST be resolved to IP addresses when communication with 690 the named host is required. This raises a temporal aspect to 691 defining MIB objects whose value is a DNS name: When is the name 692 translated to an address? 694 For example, consider an object defined to indicate a forwarding 695 destination, and whose value is a DNS name. When does the forwarding 696 entity resolve the DNS name? Each time forwarding occurs or just once 697 when the object was instantiated? 698 The DESCRIPTION clause of such objects SHOULD precisely define how 699 and when any required name to address resolution is done. 701 Similarly, the DESCRIPTION clause of such objects SHOULD precisely 702 define how and when a reverse lookup is being done if an agent has 703 accessed instrumentation that knows about an IP address and the MIB 704 module or implementation requires it to map the IP address to a DNS 705 name. 707 5. Table Indexing Example 709 This example shows a table listing communication peers that are 710 identified by either an IPv4 address, an IPv6 address or a DNS name. 711 The table definition also prohibits entries with an empty address 712 (whose type would be "unknown"). The size of a DNS name is limited 713 to 64 characters in order to satisfy OID length constraints. 715 peerTable OBJECT-TYPE 716 SYNTAX SEQUENCE OF PeerEntry 717 MAX-ACCESS not-accessible 718 STATUS current 719 DESCRIPTION 720 "A list of communication peers." 721 ::= { somewhere 1 } 723 peerEntry OBJECT-TYPE 724 SYNTAX PeerEntry 725 MAX-ACCESS not-accessible 726 STATUS current 727 DESCRIPTION 728 "An entry containing information about a particular peer." 729 INDEX { peerAddressType, peerAddress } 730 ::= { peerTable 1 } 732 PeerEntry ::= SEQUENCE { 733 peerAddressType InetAddressType, 734 peerAddress InetAddress, 735 peerStatus INTEGER 736 } 738 peerAddressType OBJECT-TYPE 739 SYNTAX InetAddressType 740 MAX-ACCESS not-accessible 741 STATUS current 742 DESCRIPTION 743 "The type of Internet address by which the peer 744 is reachable." 746 ::= { peerEntry 1 } 748 peerAddress OBJECT-TYPE 749 SYNTAX InetAddress (SIZE (1..64)) 750 MAX-ACCESS not-accessible 751 STATUS current 752 DESCRIPTION 753 "The Internet address for the peer. The type of this 754 address is determined by the value of the peerAddressType 755 object. Note that implementations must limit themselves 756 to a single entry in this table per reachable peer. 757 The peerAddress may not be empty due to the SIZE 758 restriction. 760 If a row is created administratively by an SNMP 761 operation and the address type value is dns(16), then 762 the agent stores the DNS name internally. A DNS name 763 lookup must be performed on the internally stored DNS 764 name whenever it is being used to contact the peer. 766 If a row is created by the managed entity itself and 767 the address type value is dns(16), then the agent 768 stores the IP address internally. A DNS reverse lookup 769 must be performed on the internally stored IP address 770 whenever the value is retrieved via SNMP." 771 ::= { peerEntry 2 } 773 The following compliance statement specifies that compliant 774 implementations need only support IPv4/IPv6 addresses without a zone 775 indices. Support for DNS names or IPv4/IPv6 addresses with zone 776 indices is not required. 778 peerCompliance MODULE-COMPLIANCE 779 STATUS current 780 DESCRIPTION 781 "The compliance statement of the peer MIB." 783 MODULE -- this module 784 MANDATORY-GROUPS { peerGroup } 786 OBJECT peerAddressType 787 SYNTAX InetAddressType { ipv4(1), ipv6(2) } 788 DESCRIPTION 789 "An implementation is only required to support IPv4 790 and IPv6 addresses without zone indices." 792 ::= { somewhere 2 } 794 Note that the SMIv2 does not permit inclusion of not-accessible 795 objects in an object group (see section 3.1 in STD 58, RFC 2580 796 [RFC2580]). It is therefore not possible to formally refine the 797 syntax of auxiliary objects which are not-accessible. In such a 798 case, it is suggested to express the refinement informally in the 799 DESCRIPTION clause of the MODULE-COMPLIANCE macro invocation. 801 6. Security Considerations 803 This module does not define any management objects. Instead, it 804 defines a set of textual conventions which may be used by other MIB 805 modules to define management objects. 807 Meaningful security considerations can only be written in the MIB 808 modules that define management objects. This document has therefore 809 no impact on the security of the Internet. 811 7. IANA Considerations 813 This document has no actions for IANA. 815 8. Acknowledgments 817 This document was produced by the Operations and Management Area 818 "IPv6MIB" design team. The authors would like to thank Fred Baker, 819 Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro 820 Hagino, Mike Heard, Tim Jenkins, Allison Mankin, Glenn Mansfield, 821 Keith McCloghrie, Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, 822 Randy Presuhn, Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, 823 and Brian Zill for their comments and suggestions. 825 9. Changes from RFC 3291 to RFC XXXX 827 The following changes have been made relative to RFC 3291: 828 o Added a range restriction to the InetAddressPrefixLength textual 829 convention. 830 o Added new textual conventions InetZoneIndex, InetScopeType and 831 InetVersion. 832 o Added explicit "d" DISPLAY-HINTs for textual conventions that did 833 not have them. 834 o Updated boilerplate text and references. 836 10. Changes from RFC 2851 to RFC 3291 838 The following changes have been made relative to RFC 2851: 839 o Added new textual conventions InetAddressPrefixLength, 840 InetPortNumber, and InetAutonomousSystemNumber. 842 o Rewrote the introduction to say clearly that in general, one 843 should define MIB tables that work with all versions of IP. The 844 other approach of multiple tables for different IP versions is 845 strongly discouraged. 846 o Added text to the InetAddressType and InetAddress descriptions 847 which requires that implementations must reject set operations 848 with an inconsistentValue error if they lead to inconsistencies. 849 o Removed the strict ordering constraints. Description clauses now 850 must explain which InetAddressType object provides the context for 851 an InetAddress or InetAddressPrefixLength object. 852 o Aligned wordings with the IPv6 scoping architecture document. 853 o Split the InetAddressIPv6 textual convention into the two textual 854 conventions (InetAddressIPv6 and InetAddressIPv6z) and introduced 855 a new textual convention InetAddressIPv4z. Added ipv4z(3) and 856 ipv6z(4) named numbers to the InetAddressType enumeration. 857 Motivations for this change: (i) enable the introduction of a 858 textual conventions for non-global IPv4 addresses, (ii) alignment 859 with the textual conventions for transport addresses, (iii) 860 simpler compliance statements in cases where support for IPv6 861 addresses with zone indices is not required, (iv) simplify 862 implementations for host systems which will never have to report 863 zone indices. 865 11. References 867 11.1 Normative References 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 873 "Structure of Management Information Version 2 (SMIv2)", 874 STD 58, RFC 2578, April 1999. 876 [RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual 877 Conventions for SMIv2", STD 58, RFC 2579, April 1999. 879 [RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, 880 "Conformance Statements for SMIv2", STD 58, RFC 2580, 881 April 1999. 883 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 884 (IPv6) Addressing Architecture", RFC 3513, April 2003. 886 [RFCZZZZ] Deering, S., Haberman, B., Jinmei, T., Nordmark, E. and B. 887 Zill, "IPv6 Scoped Address Architecture", 888 draft-ietf-ipv6-scoping-arch-01.txt, February 2004. 890 11.2 Informative References 892 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 893 "Introduction and Applicability Statements for the 894 Internet-Standard Management Framework", RFC 3410, 895 December 2002. 897 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 898 MIB", RFC 2863, June 2000. 900 [RFC2553] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, 901 "Basic Socket Interface Extensions for IPv6", RFC 2553, 902 March 1999. 904 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 905 Transport Addresses", RFC 3419, December 2002. 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 927 Shawn A. Routhier 928 Wind River Systems, Inc. 929 500 Wind River Way 930 Alameda, CA 94501 931 USA 933 Phone: +1 510 749-2095 934 EMail: shawn.routhier@windriver.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 Rights 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; nor does it represent that it has 951 made any independent effort to identify any such rights. Information 952 on the procedures with respect to rights in RFC documents can be 953 found in BCP 78 and BCP 79. 955 Copies of IPR disclosures made to the IETF Secretariat and any 956 assurances of licenses to be made available, or the result of an 957 attempt made to obtain a general license or permission for the use of 958 such proprietary rights by implementers or users of this 959 specification can be obtained from the IETF on-line IPR repository at 960 http://www.ietf.org/ipr. 962 The IETF invites any interested party to bring to its attention any 963 copyrights, patents or patent applications, or other proprietary 964 rights that may cover technology that may be required to implement 965 this standard. Please address the information to the IETF at 966 ietf-ipr@ietf.org. 968 Disclaimer of Validity 970 This document and the information contained herein are provided on an 971 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 972 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 973 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 974 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 975 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 976 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 978 Copyright Statement 980 Copyright (C) The Internet Society (2004). This document is subject 981 to the rights, licenses and restrictions contained in BCP 78, and 982 except as set forth therein, the authors retain all their rights. 984 Acknowledgment 986 Funding for the RFC Editor function is currently provided by the 987 Internet Society.