idnits 2.17.1 draft-ietf-ops-taddress-mib-01.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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ops-taddress-mib-01', but the file name used is 'draft-ietf-ops-taddress-mib-01' == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 506 has weird spacing: '...address str...' == Line 552 has weird spacing: '...address netw...' == 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). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (September 20, 2001) is 8247 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: '19' is defined on line 697, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 700, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 703, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2571 (ref. '2') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '10') ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (ref. '12') (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (ref. '13') (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (ref. '14') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (ref. '15') (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (ref. '16') (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (ref. '17') (Obsoleted by RFC 3410) == Outdated reference: A later version (-06) exists of draft-ietf-ops-rfc2851-update-03 ** Obsolete normative reference: RFC 2373 (ref. '19') (Obsoleted by RFC 3513) -- Possible downref: Non-RFC (?) normative reference: ref. '20' == Outdated reference: A later version (-04) exists of draft-ietf-ipngwg-scoping-arch-02 -- Possible downref: Normative reference to a draft: ref. '21' Summary: 17 errors (**), 0 flaws (~~), 15 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Daniele 3 Internet-Draft Consultant 4 Expires: March 21, 2002 J. Schoenwaelder 5 TU Braunschweig 6 September 20, 2001 8 Textual Conventions for Transport Addresses 9 draft-ops-taddress-mib-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on March 21, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2001). All Rights Reserved. 38 Abstract 40 This document introduces a MIB module which defines textual 41 conventions to represent commonly used transport layer addressing 42 information. The definitions are compatible with the concept of 43 TAddress/TDomain pairs introduced by the SMIv2 and support the 44 Internet transport protocols over IPv4 and IPv6. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. SNMP Management Framework . . . . . . . . . . . . . . . . . 3 50 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3.1 Relationship to Other MIBs . . . . . . . . . . . . . . . . . 5 52 3.1.1 SNMPv2-TC (TAddress, TDomain) . . . . . . . . . . . . . . . 5 53 3.1.2 SNMPv2-TM . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress) . . . . . . 5 55 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 57 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 14 59 8. Intellectual Property Notice . . . . . . . . . . . . . . . . 14 60 References . . . . . . . . . . . . . . . . . . . . . . . . . 14 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 62 A. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 16 63 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 65 1. Introduction 67 Many MIB modules have the need to represent transport layer addresses 68 in a generic way. Typical examples are MIBs for application 69 protocols that can run over several different transports or 70 application management MIBs that need to model generic communication 71 endpoints. 73 The SMIv2 defines in RFC 2579 [7] the textual conventions TDomain and 74 TAddress to represent generic transports layer endpoints. A generic 75 TAddress value is interpreted in a given transport domain which is 76 identified by a TDomain value. The TDomain is an object identifier 77 which allows MIB authors to extend the set of supported transport 78 domains by providing suitable definitions in enterprise specific MIB 79 modules. 81 A set of TDomain values and concrete TAddress formats has been 82 standardized in RFC 1906 [11]. These definitions are however mixed 83 up with SNMP semantics and definitions for Internet transport 84 protocols over IPv4 and IPv6 are missing. 86 The purpose of this memo is to introduce a set of well-known textual 87 conventions to represent commonly used transport layer addressing 88 information which is compatible with the original TDomain and 89 TAddress approach and which includes definitions for Internet 90 transport protocols over IPv4 and IPv6. This memo also defines a new 91 textual convention which enumerates the well-known transport domains 92 since such an enumeration provides in many cases enough flexibility 93 and is more efficient compared to object identifiers. 95 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in 96 this document are to be interpreted as described in RFC 2119 [1]. 98 2. SNMP Management Framework 100 The SNMP Management Framework presently consists of five major 101 components: 103 o An overall architecture, described in RFC 2571 [2]. 105 o Mechanisms for describing and naming objects and events for the 106 purpose of management. The first version of this Structure of 107 Management Information (SMI) is called SMIv1 and described in STD 108 16, RFC 1155 [3], STD 16, RFC 1212 [4] and RFC 1215 [5]. The 109 second version, called SMIv2, is described in STD 58, RFC 2578 110 [6], STD 58, RFC 2579 [7] and STD 58, RFC 2580 [8]. 112 o Message protocols for transferring management information. The 113 first version of the SNMP message protocol is called SNMPv1 and 114 described in STD 15, RFC 1157 [9]. A second version of the SNMP 115 message protocol, which is not an Internet standards track 116 protocol, is called SNMPv2c and described in RFC 1901 [10] and RFC 117 1906 [11]. The third version of the message protocol is called 118 SNMPv3 and described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 119 [13]. 121 o Protocol operations for accessing management information. The 122 first set of protocol operations and associated PDU formats is 123 described in STD 15, RFC 1157 [9]. A second set of protocol 124 operations and associated PDU formats is described in RFC 1905 125 [14]. 127 o A set of fundamental applications described in RFC 2573 [15] and 128 the view-based access control mechanism described in RFC 2575 129 [16]. 131 A more detailed introduction to the current SNMP Management Framework 132 can be found in RFC 2570 [17]. 134 Managed objects are accessed via a virtual information store, termed 135 the Management Information Base or MIB. Objects in the MIB are 136 defined using the mechanisms defined in the SMI. 138 This memo specifies a MIB module that is compliant to the SMIv2. A 139 MIB conforming to the SMIv1 can be produced through the appropriate 140 translations. The resulting translated MIB must be semantically 141 equivalent, except where objects or events are omitted because no 142 translation is possible (use of Counter64). Some machine readable 143 information in SMIv2 will be converted into textual descriptions in 144 SMIv1 during the translation process. However, this loss of machine 145 readable information is not considered to change the semantics of the 146 MIB. 148 3. Overview 150 This MIB module contains definitions for commonly used transport 151 layer addressing information. In particular, it provides the 152 following definitions: 154 1. Textual conventions for generic transport addresses and generic 155 transport domains. 157 2. Object identifier registrations for well-known transport domains. 159 3. An enumeration of the well-known transport domains, called a 160 transport address type. 162 4. A set of textual conventions for the address formats used by 163 well-known transport domains. 165 It is expected that this MIB module will be updated by subsequent 166 RFCs which register additional well-known transport domains and which 167 introduce new textual conventions for the address formats used by 168 those new transport domains. 170 This module does NOT define the transport mappings of any particular 171 protocol. Rather, it defines a set of common identifiers and textual 172 conventions that are intended to be used within various transport 173 mappings documents. 175 3.1 Relationship to Other MIBs 177 This section discusses how the definitions provided by this memo 178 relate to definitions in related MIB modules. 180 3.1.1 SNMPv2-TC (TAddress, TDomain) 182 The SNMPv2-TC module [7] defines the textual conventions TAddress and 183 TDomain to represent generic transport addresses. 185 A TAddress is an octet string with a size between 1 and 255 octets. 186 Experience has shown that there is sometimes a need to represent 187 unknown transport addresses. This module therefore introduces a new 188 textual convention TransportAddress which is an octet string with a 189 size between 0 and 255 octets and otherwise identical semantics. 191 This module also introduces a new textual convention TransportDomain 192 which is compatible with the TDomain definition so that a complete 193 set of definitions is contained in a single module. 195 3.1.2 SNMPv2-TM 197 The transport domains defined in the SNMPv2-TM module [11] all 198 contain "snmp" as the prefix in their name and are registered under 199 `snmpDomains' (from RFC 2578 [6]). There has been some confusion as 200 to whether these definitions are appropriate for designating 201 transport endpoints for non-SNMP traffic. These definitions are also 202 incomplete since new transport address domains are needed to support 203 (at least) SNMP over IPv6. 205 3.1.3 INET-ADDRESS-MIB (InetAddressType, InetAddress) 207 The INET-ADDRESS-MIB module [18] defines the textual conventions 208 InetAddressType and InetAddress to represent Internet network layer 209 endpoints. Several MIBs use these textual conventions in conjunction 210 with the InetPortNumber textual convention to represent Internet 211 transport layer endpoints. This is approach is fine as long as a MIB 212 models protocols or applications that are specific to the Internet 213 suite of transport protocols. For protocols or applications that can 214 potentially use other transport protocols, the use of the definitions 215 contained in this memo is more appropriate. 217 4. Definitions 219 TRANSPORT-ADDRESS-MIB DEFINITIONS ::= BEGIN 221 IMPORTS 222 MODULE-IDENTITY, OBJECT-IDENTITY, mib-2 FROM SNMPv2-SMI 223 TEXTUAL-CONVENTION FROM SNMPv2-TC; 225 transportAddressMIB MODULE-IDENTITY 226 LAST-UPDATED "200109170000Z" 227 ORGANIZATION 228 "IETF Operations and Management Area" 229 CONTACT-INFO 230 "Juergen Schoenwaelder (Editor) 231 TU Braunschweig 232 Bueltenweg 74/75 233 38106 Braunschweig, Germany 235 Phone: +49 531 391-3289 236 EMail: schoenw@ibr.cs.tu-bs.de 238 Send comments to ." 239 DESCRIPTION 240 "This MIB module provides commonly-used transport 241 address definitions." 242 REVISION "200109170000Z" 243 DESCRIPTION 244 "Initial version, published as RFC XXXX." 245 ::= { mib-2 XXXX } -- to be assigned by IANA 247 transportDomains OBJECT IDENTIFIER ::= { transportAddressMIB 1 } 249 transportDomainUdpIpv4 OBJECT-IDENTITY 250 STATUS current 251 DESCRIPTION 252 "The UDP over IPv4 transport domain. The corresponding 253 transport address is of type TransportAddressIPv4 for 254 global IPv4 addresses." 255 ::= { transportDomains 1 } 257 transportDomainUdpIpv6 OBJECT-IDENTITY 258 STATUS current 259 DESCRIPTION 260 "The UDP over IPv6 transport domain. The corresponding 261 transport address is of type TransportAddressIPv6 for 262 global IPv6 addresses." 263 ::= { transportDomains 2 } 265 transportDomainUdpIpv4z OBJECT-IDENTITY 266 STATUS current 267 DESCRIPTION 268 "The UDP over IPv4 transport domain. The corresponding 269 transport address is of type TransportAddressIPv4z for 270 non-global IPv4 addresses." 271 ::= { transportDomains 3 } 273 transportDomainUdpIpv6z OBJECT-IDENTITY 274 STATUS current 275 DESCRIPTION 276 "The UDP over IPv6 transport domain. The corresponding 277 transport address is of type TransportAddressIPv6z for 278 non-global IPv6 addresses." 279 ::= { transportDomains 4 } 281 transportDomainTcpIpv4 OBJECT-IDENTITY 282 STATUS current 283 DESCRIPTION 284 "The TCP over IPv4 transport domain. The corresponding 285 transport address is of type TransportAddressIPv4 for 286 global IPv4 addresses." 287 ::= { transportDomains 5 } 289 transportDomainTcpIpv6 OBJECT-IDENTITY 290 STATUS current 291 DESCRIPTION 292 "The TCP over IPv6 transport domain. The corresponding 293 transport address is of type TransportAddressIPv6 for 294 global IPv6 addresses." 295 ::= { transportDomains 6 } 297 transportDomainTcpIpv4z OBJECT-IDENTITY 298 STATUS current 299 DESCRIPTION 300 "The TCP over IPv4 transport domain. The corresponding 301 transport address is of type TransportAddressIPv4z for 302 non-global IPv4 addresses." 303 ::= { transportDomains 7 } 305 transportDomainTcpIpv6z OBJECT-IDENTITY 306 STATUS current 307 DESCRIPTION 308 "The TCP over IPv6 transport domain. The corresponding 309 transport address is of type TransportAddressIPv6z for 310 non-global IPv6 addresses." 311 ::= { transportDomains 8 } 313 transportDomainLocal OBJECT-IDENTITY 314 STATUS current 315 DESCRIPTION 316 "The Posix Local IPC transport domain. The corresponding 317 transport address is of type TransportAddressLocal. 319 The Posix Local IPC transport domain incorporates the 320 well known UNIX domain sockets." 321 ::= { transportDomains 9 } 323 transportDomainClns OBJECT-IDENTITY 324 STATUS current 325 DESCRIPTION 326 "The CLNS transport domain. The corresponding 327 transport address is of type TransportAddressOSI." 328 ::= { transportDomains 10 } 330 transportDomainCons OBJECT-IDENTITY 331 STATUS current 332 DESCRIPTION 333 "The CONS transport domain. The corresponding 334 transport address is of type TransportAddressOSI." 335 ::= { transportDomains 11 } 337 transportDomainDdp OBJECT-IDENTITY 338 STATUS current 339 DESCRIPTION 340 "The DDP transport domain. The corresponding 341 transport address is of type TransportAddressNBP." 342 ::= { transportDomains 12 } 344 transportDomainIpx OBJECT-IDENTITY 345 STATUS current 346 DESCRIPTION 347 "The IPX transport domain. The corresponding 348 transport address is of type TransportAddressIPX." 349 ::= { transportDomains 13 } 351 TransportDomain ::= TEXTUAL-CONVENTION 352 STATUS current 353 DESCRIPTION 354 "A value that represents a transport domain. 356 Some possible values, such as transportDomainUdpIpv4, are 357 defined in this module. Other possible values are defined 358 in other MIB modules." 359 SYNTAX OBJECT IDENTIFIER 361 -- 362 -- The enumerated values of the textual convention below SHOULD 363 -- be identical to the last sub-identifier of the OID registered 364 -- for the same domain. 365 -- 367 TransportAddressType ::= TEXTUAL-CONVENTION 368 STATUS current 369 DESCRIPTION 370 "A value that represents a transport domain. This is the 371 enumerated version of the transport domain registrations 372 in this MIB module. The enumerated values have the 373 following meaning: 375 unknown(0) unknown transport address type 376 udpIpv4(1) transportDomainUdpIpv4 377 udpIpv6(2) transportDomainUdpIpv6 378 udpIpv4z(3) transportDomainUdpIpv4z 379 udpIpv6z(4) transportDomainUdpIpv6z 380 tcpIpv4(5) transportDomainTcpIpv4 381 tcpIpv6(6) transportDomainTcpIpv6 382 tcpIpv4z(7) transportDomainTcpIpv4z 383 tcpIpv6z(8) transportDomainTcpIpv6z 384 local(9) transportDomainLocal 385 clns(10) transportDomainClns 386 cons(11) transportDomainCons 387 ddp(12) transportDomainDdp 388 ipx(13) transportDomainIpx 390 This textual convention can be used to represent transport 391 domains in situations where a syntax of TransportDomain is 392 unwieldy (for example, when used as an index)." 393 SYNTAX INTEGER { 394 unknown(0), 395 udpIpv4(1), 396 udpIpv6(2), 397 udpIpv4z(3), 398 udpIpv6z(4), 399 tcpIpv4(5), 400 tcpIpv6(6), 401 tcpIpv4z(7), 402 tcpIpv6z(8), 403 local(9), 404 clns(10), 405 cons(11), 406 ddp(12), 407 ipx(13) 408 } 410 TransportAddress ::= TEXTUAL-CONVENTION 411 STATUS current 412 DESCRIPTION 413 "Denotes a generic transport address. 415 A TransportAddress value is always interpreted within the 416 context of a TransportAddressType or TransportDomain value. 417 The TransportAddressType or TransportDomain object which 418 defines the format of the TransportAddress value MUST be 419 registered before the object(s) which use the 420 TransportAddress textual convention. 422 The value of a TransportAddress object must always be 423 consistent with the value of the associated 424 TransportAddressType or TransportDomain object. Attempts 425 to set a TransportAddress object to a value which is 426 inconsistent with the associated TransportAddressType or 427 TransportDomain must fail with an inconsistentValue error. 429 When this textual convention is used as a syntax of an 430 index object, there may be issues with the limit of 128 431 sub-identifiers specified in SMIv2, STD 58. In this case, 432 the OBJECT-TYPE declaration MUST include a 'SIZE' clause 433 to limit the number of potential instance sub-identifiers." 434 SYNTAX OCTET STRING (SIZE (0..255)) 436 TransportAddressIPv4 ::= TEXTUAL-CONVENTION 437 DISPLAY-HINT "1d.1d.1d.1d:2d" 438 STATUS current 439 DESCRIPTION 440 "Represents a TCP-over-IPv4 or a UDP-over-IPv4 441 transport address: 443 octets contents encoding 444 1-4 IPv4 address network-byte order 445 5-6 TCP or UDP port network-byte order" 446 SYNTAX OCTET STRING (SIZE (6)) 448 TransportAddressIPv6 ::= TEXTUAL-CONVENTION 449 DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x]0a:2d" 450 STATUS current 451 DESCRIPTION 452 "Represents a TCP-over-IPv6 or a UDP-over-IPv6 453 transport address for global IPv6 addresses: 455 octets contents encoding 456 1-16 IPv6 address network-byte order 457 17-18 TCP or UDP port network-byte order 459 This textual convention must not be used for non-global 460 scoped IPv6 addresses." 461 REFERENCE 462 "IP Version 6 Addressing Architecture (RFC 2373)" 463 SYNTAX OCTET STRING (SIZE (18)) 465 TransportAddressIPv4z ::= TEXTUAL-CONVENTION 466 DISPLAY-HINT "1d.1d.1d.1d%4d:2d" 467 STATUS current 468 DESCRIPTION 469 "Represents a TCP-over-IPv4 or a UDP-over-IPv4 470 transport address for scoped IPv6 addresses: 472 octets contents encoding 473 1-4 IPv4 address network-byte order 474 5-8 zone index network-byte order 475 9-10 TCP or UDP port network-byte order 477 This textual convention must not be used for global IPv4 478 addresses." 479 SYNTAX OCTET STRING (SIZE (10)) 481 TransportAddressIPv6z ::= TEXTUAL-CONVENTION 482 DISPLAY-HINT "0a[2x:2x:2x:2x:2x:2x:2x:2x%4d]0a:2d" 483 STATUS current 484 DESCRIPTION 485 "Represents a TCP-over-IPv6 or a UDP-over-IPv6 486 transport address for scoped IPv6 addresses: 488 octets contents encoding 489 1-16 IPv6 address network-byte order 490 17-20 scope identifier network-byte order 491 21-22 TCP or UDP port network-byte order 493 This textual convention must not be used for global IPv6 494 addresses." 495 REFERENCE 496 "IP Version 6 Addressing Architecture (RFC 2373)" 497 SYNTAX OCTET STRING (SIZE (22)) 499 TransportAddressLocal ::= TEXTUAL-CONVENTION 500 DISPLAY-HINT "1a" 501 STATUS current 502 DESCRIPTION 503 "Represents a POSIX Local IPC transport address: 505 octets contents encoding 506 all POSIX Local IPC address string 508 The Posix Local IPC transport domain subsumes UNIX domain 509 sockets." 510 REFERENCE 511 "Protocol Independent Interfaces (IEEE POSIX 1003.1g)" 512 SYNTAX OCTET STRING (SIZE (1..255)) 514 TransportAddressOSI ::= TEXTUAL-CONVENTION 515 DISPLAY-HINT "*1x:/1x:" 516 STATUS current 517 DESCRIPTION 518 "Represents an OSI transport-address: 520 octets contents encoding 521 1 length of NSAP 'n' as an unsigned-integer 522 (either 0 or from 3 to 20) 523 2..(n+1) NSAP concrete binary representation 524 (n+2)..m TSEL string of (up to 64) octets" 525 SYNTAX OCTET STRING (SIZE (1 | 4..85)) 527 TransportAddressNBP ::= TEXTUAL-CONVENTION 528 STATUS current 529 DESCRIPTION 530 "Represents an NBP name: 532 octets contents encoding 533 1 length of object 'n' as an unsigned integer 534 2..(n+1) object string of (up to 32) octets 535 n+2 length of type 'p' as an unsigned integer 536 (n+3)..(n+2+p) type string of (up to 32) octets 537 n+3+p length of zone 'q' as an unsigned integer 538 (n+4+p)..(n+3+p+q) zone string of (up to 32) octets 540 For comparison purposes, strings are case-insensitive. All 541 strings may contain any octet other than 255 (hex ff)." 542 SYNTAX OCTET STRING (SIZE (3..99)) 544 TransportAddressIPX ::= TEXTUAL-CONVENTION 545 DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d" 546 STATUS current 547 DESCRIPTION 548 "Represents an IPX address: 550 octets contents encoding 551 1-4 network-number network-byte order 552 5-10 physical-address network-byte order 553 11-12 socket-number network-byte order" 554 SYNTAX OCTET STRING (SIZE (12)) 556 END 558 5. Examples 560 This section shows some examples how transport addresses are encoded 561 and rendered using some of the initial transport domain and address 562 definitions. 564 Description: Unspecified IPv4 address on port 80. 565 Encoding (hex): 000000000050 566 Display: 0.0.0.0:80 568 Description: Global IPv4 address on port 80. 569 Encoding (hex): 86A922010050 570 Display: 134.169.34.1:80 572 Description: Unspecified IPv6 address on port 80. 573 Encoding (hex): 000000000000000000000000000000000050 574 Display: [0:0:0:0:0:0:0:0]:80 576 Description: Global IPv6 address on port 80. 577 Encoding (hex): 108000000000000000080800200C417A0050 578 Display: [1080:0:0:0:8:800:200C:417A]:80 580 Description: Link-local IPv6 address with zone-index 42 on port 80. 581 Encoding (hex): FE8000000000000000010000000002000000002A0050 582 Display: [FE80:0:0:0:1:0:0:200%42]:80 584 Description: Posix Local IPC address (UNIX domain). 585 Encoding (hex): 2F7661722F6167656E74782F6D6173746572 586 Display: /var/agentx/master 588 6. Security Considerations 590 The MIB module contained in this memo does not define any management 591 objects. Instead, it defines a set of textual conventions which may 592 be used by other MIB modules to define management objects. 594 Meaningful security considerations can only be written for MIB 595 modules that define concrete management objects. This document has 596 therefore no impact on the security of the Internet. 598 7. Acknowledgments 600 This document was produced by the Operations and Management Area 601 "IPv6MIB" design team. Some of the definitions in this module are 602 taken from RFC 1906 [11]. The authors would like to thank Mark 603 Ellison, Brian Haberman, Erik Nordmark, Bill Strahm and Dave Thaler 604 for their comments and suggestions. 606 8. Intellectual Property Notice 608 The IETF takes no position regarding the validity or scope of any 609 intellectual property or other rights that might be claimed to 610 pertain to the implementation or use of the technology described in 611 this document or the extent to which any license under such rights 612 might or might not be available; neither does it represent that it 613 has made any effort to identify any such rights. Information on the 614 IETF's procedures with respect to rights in standards-track and 615 standards-related documentation can be found in BCP-11. Copies of 616 claims of rights made available for publication and any assurances of 617 licenses to be made available, or the result of an attempt made to 618 obtain a general license or permission for the use of such 619 proprietary rights by implementors or users of this specification can 620 be obtained from the IETF Secretariat. 622 The IETF invites any interested party to bring to its attention any 623 copyrights, patents or patent applications, or other proprietary 624 rights which may cover technology that may be required to practice 625 this standard. Please address the information to the IETF Executive 626 Director. 628 References 630 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 631 Levels", BCP 14, RFC 2119, March 1997. 633 [2] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 634 Describing SNMP Management Frameworks", RFC 2571, April 1999. 636 [3] Rose, M. and K. McCloghrie, "Structure and Identification of 637 Management Information for TCP/IP-based Internets", STD 16, RFC 638 1155, May 1990. 640 [4] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, 641 RFC 1212, March 1991. 643 [5] Rose, M., "A Convention for Defining Traps for use with the 644 SNMP", RFC 1215, March 1991. 646 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 647 M. and S. Waldbusser, "Structure of Management Information 648 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 650 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 651 M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, 652 RFC 2579, April 1999. 654 [8] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 655 M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 656 58, RFC 2580, April 1999. 658 [9] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 659 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 660 1990. 662 [10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 663 "Introduction to Community-based SNMPv2", RFC 1901, January 664 1996. 666 [11] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 667 "Transport Mappings for Version 2 of the Simple Network 668 Management Protocol (SNMPv2)", RFC 1906, January 1996. 670 [12] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 671 Processing and Dispatching for the Simple Network Management 672 Protocol (SNMP)", RFC 2572, April 1999. 674 [13] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) 675 for version 3 of the Simple Network Management Protocol 676 (SNMPv3)", RFC 2574, April 1999. 678 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol 679 Operations for Version 2 of the Simple Network Management 680 Protocol (SNMPv2)", RFC 1905, January 1996. 682 [15] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 683 2573, April 1999. 685 [16] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access 686 Control Model (VACM) for the Simple Network Management Protocol 687 (SNMP)", RFC 2575, April 1999. 689 [17] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 690 to Version 3 of the Internet-standard Network Management 691 Framework", RFC 2570, April 1999. 693 [18] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder, 694 "Textual Conventions for Internet Network Addresses", ID draft- 695 ietf-ops-rfc2851-update-03.txt, September 2001. 697 [19] Hinden, R. and S. Deering, "IP Version 6 Addressing 698 Architecture", RFC 2373, July 1998. 700 [20] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, 701 DRAFT 6.6, March 1997. 703 [21] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe, A. 704 and B. Zill, "IPv6 Scoped Address Architecture", draft-ietf- 705 ipngwg-scoping-arch-02.txt, September 2001. 707 Authors' Addresses 709 Mike Daniele 710 Consultant 711 19 Pinewood Rd 712 Hudson, NH 03051 713 USA 715 Phone: +1 603 883-6365 716 EMail: mwdaniele@adelphia.net 718 Juergen Schoenwaelder 719 TU Braunschweig 720 Bueltenweg 74/75 721 38106 Braunschweig 722 Germany 724 Phone: +49 531 391-3289 725 EMail: schoenw@ibr.cs.tu-bs.de 727 Appendix A. Open Issues 729 1. Provide suitable transport domain and address format definitions 730 for DNS names, e.g. www.tu-bs.de:80? 732 2. This version adopts a URL format wherever possible, e.g. 733 10.1.2.3:80 instead of 10.1.2.3/80 for IPv4 and 734 [00:00:00:00:0A:01:02:03]:80 instead of 735 00:00:00:00:0A:01:02:03/80 for IPv6 (RFC 2732). Is this useful? 736 Are the DISPLAY-HINTs to achieve the desired output format 737 acceptable? 739 3. Need to find experts to review the TC definitions for protocols 740 we are not familiar with (TransportAddressOSI, 741 TransportAddressNBP, TransportAddressIPX). Remove the TCs if no 742 expert can be found. 744 4. Add references and REFERENCE clauses for the various address 745 formats? Probably copying stuff from RFC 1906? Are the references 746 in RFC 1906 still valid? 748 5. Shall we add more explicit guidelines and examples for the usage 749 of the TransportAddressType TC, similar to what is in the INET- 750 ADDRESS-MIB document? 752 6. Support for SCTP? How does it work with SCTP failover? 754 7. Should we give guidance when to use the RFC 1906 definitions and 755 when to use the definitions provided by this memo? 757 8. Any ideas for a better descriptor prefix to be used throughout 758 this MIB module? 760 Full Copyright Statement 762 Copyright (C) The Internet Society (2001). All Rights Reserved. 764 This document and translations of it may be copied and furnished to 765 others, and derivative works that comment on or otherwise explain it 766 or assist in its implementation may be prepared, copied, published 767 and distributed, in whole or in part, without restriction of any 768 kind, provided that the above copyright notice and this paragraph are 769 included on all such copies and derivative works. However, this 770 document itself may not be modified in any way, such as by removing 771 the copyright notice or references to the Internet Society or other 772 Internet organizations, except as needed for the purpose of 773 developing Internet standards in which case the procedures for 774 copyrights defined in the Internet Standards process must be 775 followed, or as required to translate it into languages other than 776 English. 778 The limited permissions granted above are perpetual and will not be 779 revoked by the Internet Society or its successors or assigns. 781 This document and the information contained herein is provided on an 782 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 783 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 784 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 785 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 786 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 788 Acknowledgement 790 Funding for the RFC Editor function is currently provided by the 791 Internet Society.