idnits 2.17.1 draft-ietf-v6ops-ipv4survey-ops-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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2154 lines 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 is 1 instance of lines with control characters in the document. == There is 2 instances of lines with non-RFC6890-compliant IPv4 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 81 has weird spacing: '... vacuum and p...' == Line 82 has weird spacing: '... if the probl...' == Line 186 has weird spacing: '... octets cont...' == Line 872 has weird spacing: '... octets cont...' == Line 881 has weird spacing: '... octets cont...' == (3 more instances...) -- 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 (May 2004) is 7284 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) -- Looks like a reference, but probably isn't: 'RFC1906' on line 878 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv4survey-intro-05 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-intro (ref. '1') Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Philip J. Nesser II 2 draft-ietf-v6ops-ipv4survey-ops-05.txt Nesser & Nesser Consulting 3 Internet Draft Andreas Bergstrom (Ed.) 4 Ostfold University College 5 December 2003 6 Expires May 2004 8 Survey of IPv4 Addresses in Currently Deployed 9 IETF Operations & Management Area Standards 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Status of this Memo 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document seeks to document all usage of IPv4 addresses in currently 34 deployed IETF Operations & Management Area documented standards. In 35 order to successfully transition from an all IPv4 Internet to an all 36 IPv6 Internet, many interim steps will be taken. One of these steps is 37 the evolution of current protocols that have IPv4 dependencies. It is 38 hoped that these protocols (and their implementations) will be 39 redesigned to be network address independent, but failing that will at 40 least dually support IPv4 and IPv6. To this end, all Standards (Full, 41 Draft, and Proposed) as well as Experimental RFCs will be surveyed and 42 any dependencies will be documented. 44 Table of Contents 46 1. Introduction 47 2. Document Organisation 48 3. Full Standards 49 4. Draft Standards 50 5. Proposed Standards 51 6. Experimental RFCs 52 7. Summary of Results 53 7.1 Standards 54 7.2 Draft Standards 55 7.3 Proposed Standards 7.4 Experimental RFCs 56 8. Security Consideration 57 9. Acknowledgements 58 10. References 59 11. Authors' Addresses 60 12. Intellectual Property Statement 61 13. Full Copyright Statement 63 1.0 Introduction 65 This document is part of a document set aiming to document all usage of 66 IPv4 addresses in IETF standards. In an effort to have the information 67 in a manageable form, it has been broken into 7 documents conforming 68 to the current IETF areas (Application, Internet, Management & 69 Operations, Routing, Security, Sub-IP and Transport). 71 For a full introduction, please see the introduction [1]. 73 2.0 Document Organization 75 The document is organized as described below: 77 Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, 78 and Proposed Standards, and Experimental RFCs. Each RFC is discussed in 79 its turn starting with RFC 1 and ending with (around) RFC 3100. 80 The comments for each RFC are "raw" in nature. That is, each RFC is 81 discussed in a vacuum and problems or issues discussed do not 82 "look ahead" to see if the problems have already been fixed. 84 Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 85 6. It is here that all of the results are considered as a whole and the 86 problems that have been resolved in later RFCs are correlated. 88 3.0 Full Standards 90 Full Internet Standards (most commonly simply referred to as 91 "Standards") are fully mature protocol specification that are widely 92 implemented and used throughout the Internet. 94 3.1 RFC 1155 Structure of Management Information 96 Section 3.2.3.2. IpAddress defines the following: 98 This application-wide type represents a 32-bit internet address. It 99 is represented as an OCTET STRING of length 4, in network byte-order. 101 There are several instances of the use of this definition in the rest of 102 the document. 104 3.2 RFC 1212 Concise MIB definitions 106 In section 4.1.6 IpAddress is defined as: 108 (6) IpAddress-valued: 4 sub-identifiers, in the familiar 109 a.b.c.d notation. 111 3.3 RFC 1213 Management Information Base 113 There are far too many instances of IPv4 addresses is this document 114 to enumerate here. The particular object groups that are affected 115 are the IP group, the ICMP group, the TCP group, the UDP group, 116 and the EGP group. 118 3.4 RFC 2578 Structure of Management Information Version 2 (SMIv2) 120 Section 7.1.5 defines the IpAddress data type: 122 The IpAddress type represents a 32-bit internet address. It is 123 represented as an OCTET STRING of length 4, in network byte-order. 125 Note that the IpAddress type is a tagged type for historical reasons. 126 Network addresses should be represented using an invocation of the 127 TEXTUAL-CONVENTION macro. 129 Note the deprecated status of this type; see RFC 3291 for details on 130 the replacement TEXTUAL-CONVENTION definitions. 132 3.5 RFC 2579 Textual Conventions for SMIv2 134 There are no IPv4 dependencies in this specification. 136 3.6 RFC 2580 Conformance Statements for SMIv2 138 There are no IPv4 dependencies in this specification. 140 3.7 RFC 2819 Remote Network Monitoring Management Information Base 142 There are no IPv4 dependencies in this specification. 144 3.8 RFC 3411 An Architecture for Describing SNMP Management Frameworks 146 There are no IPv4 dependencies in this specification. 148 3.9 RFC 3412 Message Processing and Dispatching for the Simple Network 149 Management Protocol (SNMP) 151 There are no IPv4 dependencies in this specification. 153 3.10 RFC 3413 SNMP Applications 155 There are no IPv4 dependencies in this specification. 157 3.11 RFC 3414 User-based Security Model (USM) for version 3 of the 158 Simple Network Management Protocol (SNMPv3) 160 There are no IPv4 dependencies in this specification. 162 3.12 RFC 3415 View-based Access Control Model (VACM) for the Simple 163 Network Management Protocol (SNMP) 165 There are no IPv4 dependencies in this specification. 167 3.13 RFC 3416 Protocol Operations for Version 2 of the Simple Network 168 Management Protocol (SNMP) 170 Section 4.2.2.1. Example of Table Traversal and Section 4.2.3.1. 171 Another Example of Table Traversal both use objects from MIB2 whose 172 data contains IPv4 addresses. Other than their use in these example 173 sections there are no IPv4 dependencies in this specification. 175 3.14 RFC 3417 Transport Mappings for Version 2 of the Simple Network 176 Management Protocol (SNMP) 178 Section 2 Definitions contains the following definition: 180 SnmpUDPAddress ::= TEXTUAL-CONVENTION 181 DISPLAY-HINT "1d.1d.1d.1d/2d" 182 STATUS current 183 DESCRIPTION 184 "Represents a UDP address: 186 octets contents encoding 187 1-4 IP-address network-byte order 188 5-6 UDP-port network-byte order 189 " 190 SYNTAX OCTET STRING (SIZE (6)) 192 Section 8.1, "Usage Example," also contains examples which uses IPv4 193 address, but it has no significance in the operation of the 194 specification. 196 3.15 RFC 3418 Management Information Base for Version 2 of the Simple 197 Network Management Protocol (SNMP) 199 There are no IPv4 dependencies in this specification. 201 4.0 Draft Standards 203 Draft Standards represent the penultimate standard level in the IETF. 204 A protocol can only achieve draft standard when there are multiple, 205 independent, interoperable implementations. Draft Standards are usually 206 quite mature and widely used. 208 4.01 RFC 1493 Definitions of Managed Objects for Bridges 210 There are no IPv4 dependencies in this specification. 212 4.02 RFC 1559 DECnet Phase IV MIB Extensions 214 There are no IPv4 dependencies in this specification. 216 4.03 RFC 1657 Definitions of Managed Objects for the Fourth 217 Version of the Border Gateway Protocol (BGP-4) using SMIv2 219 The MIB defined in this RFC deals with objects in a BGP4 based routing 220 system and therefore contain many objects that are limited by the 221 IpAddress 32-bit value defined in MIB2. Clearly the values of this MIB 222 are limited to IPv4 addresses. No update is needed, although a new MIB 223 should be defined for BGP4+ to allow management of IPv6 addresses and 224 routes. 226 4.04 RFC 1658 Definitions of Managed Objects for Character Stream 227 Devices using SMIv2 229 There are no IPv4 dependencies in this specification. 231 4.05 RFC 1659 Definitions of Managed Objects for RS-232-like Hardware 232 Devices using SMIv2 234 There are no IPv4 dependencies in this specification. 236 4.06 RFC 1660 Definitions of Managed Objects for Parallel-printer-like 237 Hardware Devices using SMIv2 239 There are no IPv4 dependencies in this specification. 241 4.07 RFC 1694 Definitions of Managed Objects for SMDS Interfaces using 242 SMIv2 244 This MIB module definition defines the following subtree: 246 ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 } 248 -- Although the objects in this group are read-only, at the 249 -- agent's discretion they may be made read-write so that the 250 -- management station, when appropriately authorized, may 251 -- change the addressing information related to the 252 -- configuration of a logical IP subnetwork implemented on 253 -- top of SMDS. 255 -- This table is necessary to support RFC1209 (IP-over-SMDS) 256 -- and gives information on the Group Addresses and ARP 257 -- Addresses used in the Logical IP subnetwork. 258 -- One SMDS address may be associated with multiple IP 259 -- addresses. One SNI may be associated with multiple LISs. 261 ipOverSMDSTable OBJECT-TYPE 262 SYNTAX SEQUENCE OF IpOverSMDSEntry 263 MAX-ACCESS not-accessible 264 STATUS current 265 DESCRIPTION 266 "The table of addressing information relevant to 267 this entity's IP addresses." 268 ::= { ipOverSMDS 1 } 270 ipOverSMDSEntry OBJECT-TYPE 271 SYNTAX IpOverSMDSEntry 272 MAX-ACCESS not-accessible 273 STATUS current 274 DESCRIPTION 275 "The addressing information for one of this 276 entity's IP addresses." 277 INDEX { ipOverSMDSIndex, ipOverSMDSAddress } 278 ::= { ipOverSMDSTable 1 } 280 IpOverSMDSEntry ::= 281 SEQUENCE { 282 ipOverSMDSIndex IfIndex, 283 ipOverSMDSAddress IpAddress, 284 ipOverSMDSHA SMDSAddress, 285 ipOverSMDSLISGA SMDSAddress, 286 ipOverSMDSARPReq SMDSAddress 287 } 289 ipOverSMDSIndex OBJECT-TYPE 290 SYNTAX IfIndex 291 MAX-ACCESS read-only 292 STATUS current 293 DESCRIPTION 294 "The value of this object identifies the 295 interface for which this entry contains management 296 information. " 297 ::= { ipOverSMDSEntry 1 } 299 ipOverSMDSAddress OBJECT-TYPE 300 SYNTAX IpAddress 301 MAX-ACCESS read-only 302 STATUS current 303 DESCRIPTION 304 "The IP address to which this entry's addressing 305 information pertains." 306 ::= { ipOverSMDSEntry 2 } 308 ipOverSMDSHA OBJECT-TYPE 309 SYNTAX SMDSAddress 310 MAX-ACCESS read-only 311 STATUS current 312 DESCRIPTION 313 "The SMDS Individual address of the IP station." 314 ::= { ipOverSMDSEntry 3 } 316 ipOverSMDSLISGA OBJECT-TYPE 317 SYNTAX SMDSAddress 318 MAX-ACCESS read-only 319 STATUS current 320 DESCRIPTION 321 "The SMDS Group Address that has been configured 322 to identify the SMDS Subscriber-Network Interfaces 323 (SNIs) of all members of the Logical IP Subnetwork 324 (LIS) connected to the network supporting SMDS." 325 ::= { ipOverSMDSEntry 4 } 327 ipOverSMDSARPReq OBJECT-TYPE 328 SYNTAX SMDSAddress 329 MAX-ACCESS read-only 330 STATUS current 331 DESCRIPTION 332 "The SMDS address (individual or group) to which 333 ARP Requests are to be sent." 334 ::= { ipOverSMDSEntry 5 } 336 Although these object definitions are intended for IPv4 addresses, a 337 similar MIB can be defined for IPv6 addressing. 339 4.08 RFC 1724 RIP Version 2 MIB Extension 341 As might be expected, this RFC is filled with IPv4 dependencies since 342 it defines a MIB module for an IPv4-only routing protocol. A new MIB 343 for RIPng is required. 345 4.09 RFC 1748 IEEE 802.5 MIB using SMIv2 347 There are no IPv4 dependencies in this specification. 349 4.10 RFC 1850 OSPF Version 2 Management Information Base 351 This MIB defines managed objects for OSPFv2 which is a protocol used 352 to exchange IPv4 routing information. Since OSPFv2 is limited to IPv4 353 addresses a new MIB is required to support a new version of OSPF that 354 is IPv6 aware. 356 4.11 RFC 2115 Management Information Base for Frame Relay DTEs 357 Using SMIv2 359 This specification has several examples of how IPv4 addresses might be 360 mapped to Frame Relay DLCIs. Other than those examples there are no 361 IPv4 dependencies in this specification. 363 4.12 RFC 2790 Host Resources MIB 365 There are no IPv4 dependencies in this specification. 367 4.13 RFC 2863 The Interfaces Group MIB 369 There are no IPv4 dependencies in this specification. There is some 370 discussion in one object definition about an interface performing a 371 self test, but the object itself is IP version independent. 373 4.14 RFC 3592 Definitions of Managed Objects for the Synchronous Optical 374 Network/Synchronous Digital Hierarchy (SONET/SDH) 376 There are no IPv4 dependencies in this specification. 378 4.15 RFC 3593 Textual Conventions for MIB Modules Using Performance 379 History Based on 15 Minute Intervals. 381 There are no IPv4 dependencies in this specification. 383 5.0 Proposed Standards 385 Proposed Standards are introductory level documents. There are no 386 requirements for even a single implementation. In many cases Proposed 387 are never implemented or advanced in the IETF standards process. They 388 therefore are often just proposed ideas that are presented to the 389 Internet community. Sometimes flaws are exposed or they are one of 390 many competing solutions to problems. In these later cases, no 391 discussion is presented as it would not serve the purpose of this 392 discussion. 394 5.001 RFC 1239 Reassignment of experimental MIBs to standard MIBs 396 There are no IPv4 dependencies in this specification. 398 5.002 RFC 1269 Definitions of Managed Objects for the Border Gateway 399 Protocol: Version 3 401 The use of BGP3 has been deprecated and is not discussed. 403 5.003 RFC 1285 FDDI Management Information Base 405 There are no IPv4 dependencies in this specification. 407 5.004 RFC 1381 SNMP MIB Extension for X.25 LAPB 409 There are no IPv4 dependencies in this specification. 411 5.005 RFC 1382 SNMP MIB Extension for the X.25 Packet Layer 413 There are no IPv4 dependencies in this specification. 415 5.006 RFC 1414 Identification MIB 417 There are no IPv4 dependencies in this specification. 419 5.007 RFC 1418 SNMP over OSI 421 There are no IPv4 dependencies in this specification. 423 5.008 RFC 1419 SNMP over AppleTalk 425 There are no IPv4 dependencies in this specification. 427 5.009 RFC 1420 SNMP over IPX 429 There are no IPv4 dependencies in this specification. 431 5.010 RFC 1461 SNMP MIB extension for Multiprotocol Interconnect 432 over X.25 434 The following objects are defined in Section 4 "Definitions": 436 mioxPleLastFailedEnAddr OBJECT-TYPE 437 SYNTAX OCTET STRING (SIZE(2..128)) 438 ACCESS read-only 439 STATUS mandatory 440 DESCRIPTION 441 "The last Encapsulated address that failed 442 to find a corresponding X.121 address and 443 caused mioxPleEnAddrToX121LkupFlrs to be 444 incremented. The first octet of this object 445 contains the encapsulation type, the 446 remaining octets contain the address of that 447 type that failed. Thus for an IP address, 448 the length will be five octets, the first 449 octet will contain 204 (hex CC), and the 450 last four octets will contain the IP 451 address. For a snap encapsulation, the 452 first byte would be 128 (hex 80) and the 453 rest of the octet string would have the snap 454 header." 455 ::= { mioxPleEntry 4 } 457 mioxPeerEnAddr OBJECT-TYPE 458 SYNTAX OCTET STRING (SIZE (0..128)) 459 ACCESS read-write 460 STATUS mandatory 461 DESCRIPTION 462 "The Encapsulation address of the remote 463 host mapped by this table entry. A length 464 of zero indicates the remote IP address is 465 unknown or unspecified for use as a PLE 466 default. 468 The first octet of this object contains the 469 encapsulation type, the remaining octets 470 contain an address of that type. Thus for 471 an IP address, the length will be five 472 octets, the first octet will contain 204 473 (hex CC), and the last four octets will 474 contain the IP address. For a snap 475 encapsulation, the first byte would be 128 476 (hex 80) and the rest of the octet string 477 would have the snap header." 478 DEFVAL { ''h } 479 ::= { mioxPeerEntry 7 } 481 mioxPeerEncType OBJECT-TYPE 482 SYNTAX INTEGER (0..256) 483 ACCESS read-write 484 STATUS mandatory 485 DESCRIPTION 486 "The value of the encapsulation type. For 487 IP encapsulation this will have a value of 488 204 (hex CC). For SNAP encapsulated 489 packets, this will have a value of 128 (hex 490 80). For CLNP, ISO 8473, this will have a 491 value of 129 (hex 81). For ES-ES, ISO 9542, 492 this will have a value of 130 (hex 82). A 493 value of 197 (hex C5) identifies the Blacker 494 X.25 encapsulation. A value of 0, 495 identifies the Null encapsulation. 497 This value can only be written when the 498 mioxPeerStatus object with the same 499 mioxPeerIndex has a value of underCreation. 500 Setting this object to a value of 256 501 deletes the entry. When deleting an entry, 502 all other entries in the mioxPeerEncTable 503 with the same mioxPeerIndex and with an 504 mioxPeerEncIndex higher then the deleted 505 entry, will all have their mioxPeerEncIndex 506 values decremented by one." 507 ::= { mioxPeerEncEntry 2 } 509 Updated values of the first byte of these objects can be defined to 510 support IPv6 addresses. 512 5.011 RFC 1471 The Definitions of Managed Objects for the Link 513 Control Protocol of the Point-to-Point Protocol 515 There are no IPv4 dependencies in this specification. 517 5.012 RFC 1472 The Definitions of Managed Objects for the Security 518 Protocols of the Point-to-Point Protocol 520 There are no IPv4 dependencies in this specification. 522 5.013 RFC 1473 The Definitions of Managed Objects for the IP Network 523 Control Protocol of the Point-to-Point Protocol 525 This MIB module is targeted specifically at IPv4 over PPP. A new 526 MIB moduld would need to be defined to support IPv6 over PPP. 528 5.014 RFC 1474 The Definitions of Managed Objects for the Bridge 529 Network Control Protocol of the Point-to-Point Protocol 531 There are no IPv4 dependencies in this specification. 533 5.015 RFC 1512 FDDI Management Information Base 535 There are no IPv4 dependencies in this specification. 537 5.016 RFC 1513 Token Ring Extensions to the Remote Network 538 Monitoring MIB 540 There are no IPv4 dependencies in this specification. 542 5.017 RFC 1525 Definitions of Managed Objects for Source Routing 543 Bridges 545 There are no IPv4 dependencies in this specification. 547 5.018 RFC 1628 UPS Management Information Base 549 There are no IPv4 dependencies in this specification. 551 5.019 RFC 1666 Definitions of Managed Objects for SNA NAUs 552 using SMIv2 554 There are no IPv4 dependencies in this specification. 556 5.020 RFC 1696 Modem Management Information Base (MIB) using SMIv2 558 There are no IPv4 dependencies in this specification. 560 5.021 RFC 1697 Relational Database Management System (RDBMS) 561 Management Information Base (MIB) using SMIv2 563 There are no IPv4 dependencies in this specification. 565 5.022 RFC 1742 AppleTalk Management Information Base II 567 The following OIDs are defined: 569 KipEntry ::= SEQUENCE { 570 kipNetStart ATNetworkNumber, 571 kipNetEnd ATNetworkNumber, 572 kipNextHop IpAddress, 573 kipHopCount INTEGER, 574 kipBCastAddr IpAddress, 575 kipCore INTEGER, 576 kipType INTEGER, 577 kipState INTEGER, 578 kipShare INTEGER, 579 kipFrom IpAddress 580 } 582 kipNextHop OBJECT-TYPE 583 SYNTAX IpAddress 584 ACCESS read-write 585 STATUS mandatory 586 DESCRIPTION 587 "The IP address of the next hop in the route to this 588 entry's destination network." 589 ::= { kipEntry 3 } 591 kipBCastAddr OBJECT-TYPE 592 SYNTAX IpAddress 593 ACCESS read-write 594 STATUS mandatory 595 DESCRIPTION 596 "The form of the IP address used to broadcast on this 597 network." 598 ::= { kipEntry 5 } 600 kipFrom OBJECT-TYPE 601 SYNTAX IpAddress 602 ACCESS read-only 603 STATUS mandatory 604 DESCRIPTION 605 "The IP address from which the routing entry was 606 learned via the AA protocol. If this entry was not 607 created via the AA protocol, it should contain IP 608 address 0.0.0.0." 609 ::= { kipEntry 10 } 611 5.023 RFC 1747 Definitions of Managed Objects for SNA Data Link 612 Control (SDLC) using SMIv2 614 There are no IPv4 dependencies in this specification. 616 5.024 RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2 618 There are no IPv4 dependencies in this specification. 620 5.025 RFC 1759 Printer MIB 622 There are no IPv4 dependencies in this specification. 624 5.026 RFC 2006 The Definitions of Managed Objects for IP Mobility 625 Support using SMIv2 627 This document defines a MIB for the Mobile IPv4. Without enumeration, 628 let it be stated that a new MIB for IPv6 Mobility is required. 630 5.027 RFC 2011 SNMPv2 Management Information Base for the Internet 631 Protocol using SMIv2 633 Approximately 1/3 of the objects defined in this document are 634 IPv4-dependent. New objects need to be defined to support IPv6. 636 5.028 RFC 2012 SNMPv2 Management Information Base for the 637 Transmission Control Protocol using SMIv2 639 A number of object definitions in this MIB assumes IPv4 addresses, as 640 is noted in the note reproduced below: 642 IESG Note: 644 The IP, UDP, and TCP MIB modules currently support only IPv4. These 645 three modules use the IpAddress type defined as an OCTET STRING of 646 length 4 to represent the IPv4 32-bit internet addresses. (See RFC 647 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 648 internet addresses. 650 5.029 RFC 2013 SNMPv2 Management Information Base for the User 651 Datagram Protocol using SMIv2 653 A number of OIDs in this MIB assumes IPv4 addresses, as is noted in 654 the note reproduced below: 656 IESG Note: 658 The IP, UDP, and TCP MIB modules currently support only IPv4. These 659 three modules use the IpAddress type defined as an OCTET STRING of 660 length 4 to represent the IPv4 32-bit internet addresses. (See RFC 661 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 662 internet addresses. 664 5.030 RFC 2020 IEEE 802.12 Interface MIB 666 There are no IPv4 dependencies in this specification. 668 5.031 RFC 2021 Remote Network Monitoring Management Information Base 669 Version 2 using SMIv2 671 The following objects are defined: 673 addressMapNetworkAddress OBJECT-TYPE 674 SYNTAX OCTET STRING 675 MAX-ACCESS not-accessible 676 STATUS current 677 DESCRIPTION 678 "The network address for this relation. 680 This is represented as an octet string with 681 specific semantics and length as identified 682 by the protocolDirLocalIndex component of the 683 index. 685 For example, if the protocolDirLocalIndex indicates an 686 encapsulation of ip, this object is encoded as a length 687 octet of 4, followed by the 4 octets of the ip address, 688 in network byte order." 689 ::= { addressMapEntry 2 } 691 nlHostAddress OBJECT-TYPE 692 SYNTAX OCTET STRING 693 MAX-ACCESS not-accessible 694 STATUS current 695 DESCRIPTION 696 "The network address for this nlHostEntry. 698 This is represented as an octet string with 699 specific semantics and length as identified 700 by the protocolDirLocalIndex component of the index. 702 For example, if the protocolDirLocalIndex indicates an 703 encapsulation of ip, this object is encoded as a length 704 octet of 4, followed by the 4 octets of the ip address, 705 in network byte order." 706 ::= { nlHostEntry 2 } 708 nlMatrixSDSourceAddress OBJECT-TYPE 709 SYNTAX OCTET STRING 710 MAX-ACCESS not-accessible 711 STATUS current 712 DESCRIPTION 713 "The network source address for this nlMatrixSDEntry. 715 This is represented as an octet string with 716 specific semantics and length as identified 717 by the protocolDirLocalIndex component of the index. 719 For example, if the protocolDirLocalIndex indicates an 720 encapsulation of ip, this object is encoded as a length 721 octet of 4, followed by the 4 octets of the ip address, 722 in network byte order." 723 ::= { nlMatrixSDEntry 2 } 725 nlMatrixSDDestAddress OBJECT-TYPE 726 SYNTAX OCTET STRING 727 MAX-ACCESS not-accessible 728 STATUS current 729 DESCRIPTION 730 "The network destination address for this 731 nlMatrixSDEntry. 733 This is represented as an octet string with 734 specific semantics and length as identified 735 by the protocolDirLocalIndex component of the index. 737 For example, if the protocolDirLocalIndex indicates an 738 encapsulation of ip, this object is encoded as a length 739 octet of 4, followed by the 4 octets of the ip address, 740 in network byte order." 741 ::= { nlMatrixSDEntry 3 } 743 nlMatrixDSSourceAddress OBJECT-TYPE 744 SYNTAX OCTET STRING 745 MAX-ACCESS not-accessible 746 STATUS current 747 DESCRIPTION 748 "The network source address for this nlMatrixDSEntry. 750 This is represented as an octet string with 751 specific semantics and length as identified 752 by the protocolDirLocalIndex component of the index. 754 For example, if the protocolDirLocalIndex indicates an 755 encapsulation of ip, this object is encoded as a length 756 octet of 4, followed by the 4 octets of the ip address, 757 in network byte order." 758 ::= { nlMatrixDSEntry 2 } 760 nlMatrixDSDestAddress OBJECT-TYPE 761 SYNTAX OCTET STRING 762 MAX-ACCESS not-accessible 763 STATUS current 764 DESCRIPTION 765 "The network destination address for this 766 nlMatrixDSEntry. 768 This is represented as an octet string with 769 specific semantics and length as identified 770 by the protocolDirLocalIndex component of the index. 772 For example, if the protocolDirLocalIndex indicates an 773 encapsulation of ip, this object is encoded as a length 774 octet of 4, followed by the 4 octets of the ip address, 775 in network byte order." 776 ::= { nlMatrixDSEntry 3 } 778 nlMatrixTopNSourceAddress OBJECT-TYPE 779 SYNTAX OCTET STRING 780 MAX-ACCESS read-only 781 STATUS current 782 DESCRIPTION 783 "The network layer address of the source host in this 784 conversation. 786 This is represented as an octet string with 787 specific semantics and length as identified 788 by the associated nlMatrixTopNProtocolDirLocalIndex. 790 For example, if the protocolDirLocalIndex indicates an 791 encapsulation of ip, this object is encoded as a length 792 octet of 4, followed by the 4 octets of the ip address, 793 in network byte order." 794 ::= { nlMatrixTopNEntry 3 } 796 nlMatrixTopNDestAddress OBJECT-TYPE 797 SYNTAX OCTET STRING 798 MAX-ACCESS read-only 799 STATUS current 800 DESCRIPTION 801 "The network layer address of the destination host in this 802 conversation. 804 This is represented as an octet string with 805 specific semantics and length as identified 806 by the associated nlMatrixTopNProtocolDirLocalIndex. 808 For example, if the nlMatrixTopNProtocolDirLocalIndex 809 indicates an encapsulation of ip, this object is encoded as a 810 length octet of 4, followed by the 4 octets of the ip address, 811 in network byte order." 812 ::= { nlMatrixTopNEntry 4 } 814 alMatrixTopNSourceAddress OBJECT-TYPE 815 SYNTAX OCTET STRING 816 MAX-ACCESS read-only 817 STATUS current 818 DESCRIPTION 819 "The network layer address of the source host in this 820 conversation. 821 This is represented as an octet string with 822 specific semantics and length as identified 823 by the associated alMatrixTopNProtocolDirLocalIndex. 825 For example, if the alMatrixTopNProtocolDirLocalIndex 826 indicates an encapsulation of ip, this object is encoded as a 827 length octet of 4, followed by the 4 octets of the ip address, 828 in network byte order." 829 ::= { alMatrixTopNEntry 3 } 831 alMatrixTopNDestAddress OBJECT-TYPE 832 SYNTAX OCTET STRING 833 MAX-ACCESS read-only 834 STATUS current 835 DESCRIPTION 836 "The network layer address of the destination host in this 837 conversation. 839 This is represented as an octet string with 840 specific semantics and length as identified 841 by the associated alMatrixTopNProtocolDirLocalIndex. 843 For example, if the alMatrixTopNProtocolDirLocalIndex 844 indicates an encapsulation of ip, this object is encoded as a 845 length octet of 4, followed by the 4 octets of the ip address, 846 in network byte order." 847 ::= { alMatrixTopNEntry 4 } 849 trapDestProtocol OBJECT-TYPE 850 SYNTAX INTEGER { 851 ip(1), 852 ipx(2) 853 } 854 MAX-ACCESS read-create 855 STATUS current 856 DESCRIPTION 857 "The protocol with which to send this trap." 858 ::= { trapDestEntry 3 } 860 trapDestAddress OBJECT-TYPE 861 SYNTAX OCTET STRING 862 MAX-ACCESS read-create 863 STATUS current 864 DESCRIPTION 865 "The address to send traps on behalf of this entry. 867 If the associated trapDestProtocol object is equal to ip(1), 868 the encoding of this object is the same as the snmpUDPAddress 869 textual convention in [RFC1906]: 870 -- for a SnmpUDPAddress of length 6: 871 -- 872 -- octets contents encoding 873 -- 1-4 IP-address network-byte order 874 -- 5-6 UDP-port network-byte order 876 If the associated trapDestProtocol object is equal to ipx(2), 877 the encoding of this object is the same as the snmpIPXAddress 878 textual convention in [RFC1906]: 879 -- for a SnmpIPXAddress of length 12: 880 -- 881 -- octets contents encoding 882 -- 1-4 network-number network-byte order 883 -- 5-10 physical-address network-byte order 884 -- 11-12 socket-number network-byte order 886 This object may not be modified if the associated 887 trapDestStatus object is equal to active(1)." 888 ::= { trapDestEntry 4 } 890 All of the object definitions above (except trapDestProtocol) mention 891 only IPv4 addresses but since they use a SYNTAX of OCTET STRING, they 892 should work fine for IPv6 addresses. A new legitimate value of 893 trapDestProtocol (i.e. SYNTAX addition of ipv6(3) should make this 894 specification functional for IPv6. 896 5.032 RFC 2024 Definitions of Managed Objects for Data Link Switching 897 using SMIv2 899 The following textual conventions are defined: 901 TAddress ::= TEXTUAL-CONVENTION 902 STATUS current 903 DESCRIPTION 904 "Denotes a transport service address. 905 For dlswTCPDomain, a TAddress is 4 octets long, 906 containing the IP-address in network-byte order." 907 SYNTAX OCTET STRING (SIZE (0..255)) 909 -- DLSw over TCP 910 dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 } 911 -- for an IP address of length 4: 912 -- 913 -- octets contents encoding 914 -- 1-4 IP-address network-byte order 915 -- 916 DlswTCPAddress ::= TEXTUAL-CONVENTION 917 DISPLAY-HINT "1d.1d.1d.1d" 918 STATUS current 919 DESCRIPTION 920 "Represents the IP address of a DLSw which uses 921 TCP as a transport protocol." 922 SYNTAX OCTET STRING (SIZE (4)) 924 Additionally there are many object definitions that use a SYNTAX of 925 TAddress within the document. Interestingly the SYNTAX for TAddress 926 is an OCTET string of up to 256 characters. It could easily 927 accommodate a similar hybrid format for IPv6 addresses. 929 A new OID to enhance functionality for DlswTCPAddress could be added 930 to support IPv6 addresses. 932 5.033 RFC 2051 Definitions of Managed Objects for APPC using SMIv2 934 There are no IPv4 dependencies in this specification. 936 5.034 RFC 2096 IP Forwarding Table MIB 938 The MIB module's main conceptual table ipCidrRouteTable uses IPv4 939 addresses as index objects and is therefore incapable of 940 representing an IPv6 forwarding information base. A new 941 conceptual table needs to be defined to support IPv6 addresses. 943 5.035 RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater 944 Devices using SMIv2 802 946 There are no IPv4 dependencies in this specification. 948 5.036 RFC 2127 ISDN Management Information Base using SMIv2 950 There are no IPv4 dependencies in this specification. 952 5.037 RFC 2128 Dial Control Management Information Base using 953 SMIv2 955 There are no IPv4 dependencies in this specification. 957 5.038 RFC 2206 RSVP Management Information Base using SMIv2 959 All of the relevant object definitions in this MIB have options for 960 both IPv4 and IPv6. There are no IPv4 dependencies in this 961 specification. 963 5.039 RFC 2213 Integrated Services Management Information 964 Base using SMIv2 966 This MIB is IPv6 aware and therefore there are no IPv4 967 dependencies in this specification. 969 5.040 RFC 2214 Integrated Services Management Information 970 Base Guaranteed Service Extensions using SMIv2 972 There are no IPv4 dependencies in this specification. 974 5.041 RFC 2232 Definitions of Managed Objects for DLUR using 975 SMIv2 977 There are no IPv4 dependencies in this specification. 979 5.042 RFC 2238 Definitions of Managed Objects for HPR using 980 SMIv2 982 There are no IPv4 dependencies in this specification. 984 5.043 RFC 2266 Definitions of Managed Objects for IEEE 802.12 985 Repeater Devices 987 There are no IPv4 dependencies in this specification. 989 5.044 RFC 2287 Definitions of System-Level Managed Objects for 990 Applications 992 There are no IPv4 dependencies in this specification. 994 5.045 RFC 2320 Definitions of Managed Objects for Classical IP 995 and ARP Over ATM Using SMIv2 (IPOA-MIB) 997 This MIB is wholly dependent on IPv4. A new MIB for IPv6 is 998 required to provide the same functionality. 1000 5.046 RFC 2417 Definitions of Managed Objects for Multicast 1001 over UNI 3.0/3.1 based ATM Networks 1003 This MIB is wholly dependent on IPv4. A new MIB for IPv6 is 1004 required to provide the same functionality. 1006 5.047 RFC 2452 IP Version 6 Management Information Base for the 1007 Transmission Control Protocol 1009 This RFC documents a soon to be obsoleted IPv6 MIB and is not 1010 considered in this discussion. 1012 5.048 RFC 2454 IP Version 6 Management Information Base for 1013 the User Datagram Protocol 1015 This RFC documents a soon to be obsoleted IPv6 MIB and is not 1016 considered in this discussion. 1018 5.049 RFC 2455 Definitions of Managed Objects for APPN 1020 There are no IPv4 dependencies in this specification. 1022 5.050 RFC 2456 Definitions of Managed Objects for APPN TRAPS 1024 There are no IPv4 dependencies in this specification. 1026 5.051 RFC 2457 Definitions of Managed Objects for Extended Border 1027 Node 1029 There are no IPv4 dependencies in this specification. 1031 5.052 RFC 2465 Management Information Base for IP Version 6: 1032 Textual Conventions and General Group 1034 This RFC documents a soon to be obsolted IPv6 MIB and is not 1035 considered in this discussion. 1037 5.053 RFC 2466 Management Information Base for IP Version 6: 1038 ICMPv6 Group 1040 This RFC documents a soon to be obsoleted IPv6 MIB and is not 1041 considered in this discussion. 1043 5.054 RFC 2494 Definitions of Managed Objects for the DS0 1044 and DS0 Bundle Interface Type 1046 There are no IPv4 dependencies in this specification. 1048 5.055 RFC 2495 Definitions of Managed Objects for the DS1, E1, 1049 DS2 and E2 Interface Types 1051 There are no IPv4 dependencies in this specification. 1053 5.056 RFC 2496 Definitions of Managed Object for the DS3/E3 1054 Interface Type 1056 There are no IPv4 dependencies in this specification. 1058 5.057 RFC 2512 Accounting Information for ATM Networks 1060 There are no IPv4 dependencies in this specification. 1062 5.058 RFC 2513 Managed Objects for Controlling the Collection 1063 and Storage of Accounting Information for Connection- 1064 Oriented Networks 1066 There are no IPv4 dependencies in this specification. 1068 5.059 RFC 2514 Definitions of Textual Conventions and 1069 OBJECT-IDENTITIES for ATM Management 1071 There are no IPv4 dependencies in this specification. 1073 5.060 RFC 2515 Definitions of Managed Objects for ATM 1074 Management 1076 This MIB defines the following objects: 1078 AtmInterfaceConfEntry ::= SEQUENCE { 1079 atmInterfaceMaxVpcs INTEGER, 1080 atmInterfaceMaxVccs INTEGER, 1081 atmInterfaceConfVpcs INTEGER, 1082 atmInterfaceConfVccs INTEGER, 1083 atmInterfaceMaxActiveVpiBits INTEGER, 1084 atmInterfaceMaxActiveVciBits INTEGER, 1085 atmInterfaceIlmiVpi AtmVpIdentifier, 1086 atmInterfaceIlmiVci AtmVcIdentifier, 1087 atmInterfaceAddressType INTEGER, 1088 atmInterfaceAdminAddress AtmAddr, 1089 atmInterfaceMyNeighborIpAddress IpAddress, 1090 atmInterfaceMyNeighborIfName DisplayString, 1091 atmInterfaceCurrentMaxVpiBits INTEGER, 1092 atmInterfaceCurrentMaxVciBits INTEGER, 1093 atmInterfaceSubscrAddress AtmAddr 1094 } 1096 atmInterfaceMyNeighborIpAddress OBJECT-TYPE 1097 SYNTAX IpAddress 1098 MAX-ACCESS read-write 1099 STATUS current 1100 DESCRIPTION 1101 "The IP address of the neighbor system connected to 1102 the far end of this interface, to which a Network 1103 Management Station can send SNMP messages, as IP 1104 datagrams sent to UDP port 161, in order to access 1105 network management information concerning the 1106 operation of that system. Note that the value 1107 of this object may be obtained in different ways, 1108 e.g., by manual configuration, or through ILMI 1109 interaction with the neighbor system." 1110 ::= { atmInterfaceConfEntry 11 } 1112 atmInterfaceConfGroup2 OBJECT-GROUP 1113 OBJECTS { 1114 atmInterfaceMaxVpcs, atmInterfaceMaxVccs, 1115 atmInterfaceConfVpcs, atmInterfaceConfVccs, 1116 atmInterfaceMaxActiveVpiBits, 1117 atmInterfaceMaxActiveVciBits, 1118 atmInterfaceIlmiVpi, 1119 atmInterfaceIlmiVci, 1120 atmInterfaceMyNeighborIpAddress, 1121 atmInterfaceMyNeighborIfName, 1122 atmInterfaceCurrentMaxVpiBits, 1123 atmInterfaceCurrentMaxVciBits, 1124 atmInterfaceSubscrAddress } 1125 STATUS current 1126 DESCRIPTION 1127 "A collection of objects providing configuration 1128 information about an ATM interface." 1129 ::= { atmMIBGroups 10 } 1131 Clearly a subsequent revision of this MIB module should define 1132 equivalent IPv6 objects. 1134 5.061 RFC 2561 Base Definitions of Managed Objects for TN3270E 1135 Using SMIv2 1137 The document states: 1139 The MIB defined by this memo supports use of both IPv4 and IPv6 1140 addressing. 1142 This specification is both IPv4 and IPv6 aware. 1144 5.062 RFC 2562 Definitions of Protocol and Managed Objects for 1145 TN3270E Response Time Collection Using SMIv2 1147 This MIB module inherits IP version-independence by virtue of 1148 importing the appropriate definitions from RFC 2561. 1150 5.063 RFC 2564 Application Management MIB 1152 The following textual convention is defined: 1154 ApplTAddress ::= TEXTUAL-CONVENTION 1155 STATUS current 1156 DESCRIPTION 1157 "Denotes a transport service address. 1159 For snmpUDPDomain, an ApplTAddress is 6 octets long, 1160 the initial 4 octets containing the IP-address in 1161 network-byte order and the last 2 containing the UDP 1162 port in network-byte order. Consult 'Transport Mappings 1163 for Version 2 of the Simple Network Management Protocol 1164 (SNMPv2)' for further information on snmpUDPDomain." 1165 SYNTAX OCTET STRING (SIZE (0..255)) 1167 A new TC should be defined to handle IPv6 addresses. 1169 5.064 RFC 2584 Definitions of Managed Objects for APPN/HPR in 1170 IP Networks 1172 Many of the object definitions described in this document assume the 1173 use of the IPv4 only TOS header bits. It is therefore IPv4-only in 1174 nature and will not support IPv6. 1176 5.065 RFC 2594 Definitions of Managed Objects for WWW Services 1178 There are no IPv4 dependencies in this specification. 1180 5.066 RFC 2605 Directory Server Monitoring MIB 1182 There are no IPv4 dependencies in this specification. 1184 5.067 RFC 2613 Remote Network Monitoring MIB Extensions for 1185 Switched Networks Version 1.0 1187 There are no IPv4 dependencies in this specification. 1189 5.068 RFC 2618 RADIUS Authentication Client MIB 1191 This RFC defines the following OIDs: 1193 RadiusAuthServerEntry ::= SEQUENCE { 1194 radiusAuthServerIndex Integer32, 1195 radiusAuthServerAddress IpAddress, 1196 radiusAuthClientServerPortNumber Integer32, 1197 radiusAuthClientRoundTripTime TimeTicks, 1198 radiusAuthClientAccessRequests Counter32, 1199 radiusAuthClientAccessRetransmissions Counter32, 1200 radiusAuthClientAccessAccepts Counter32, 1201 radiusAuthClientAccessRejects Counter32, 1202 radiusAuthClientAccessChallenges Counter32, 1203 radiusAuthClientMalformedAccessResponses Counter32, 1204 radiusAuthClientBadAuthenticators Counter32, 1205 radiusAuthClientPendingRequests Gauge32, 1206 radiusAuthClientTimeouts Counter32, 1207 radiusAuthClientUnknownTypes Counter32, 1208 radiusAuthClientPacketsDropped Counter32 1209 } 1211 radiusAuthServerAddress OBJECT-TYPE 1212 SYNTAX IpAddress 1213 MAX-ACCESS read-only 1214 STATUS current 1215 DESCRIPTION 1216 "The IP address of the RADIUS authentication server 1217 referred to in this table entry." 1218 ::= { radiusAuthServerEntry 2 } 1220 There needs to be an update to allow an IPv6 based object for this 1221 value. 1223 5.069 RFC 2619 RADIUS Authentication Server MIB 1225 This MIB defines the followings objects: 1227 RadiusAuthClientEntry ::= SEQUENCE { 1228 radiusAuthClientIndex Integer32, 1229 radiusAuthClientAddress IpAddress, 1230 radiusAuthClientID SnmpAdminString, 1231 radiusAuthServAccessRequests Counter32, 1232 radiusAuthServDupAccessRequests Counter32, 1233 radiusAuthServAccessAccepts Counter32, 1234 radiusAuthServAccessRejects Counter32, 1235 radiusAuthServAccessChallenges Counter32, 1236 radiusAuthServMalformedAccessRequests Counter32, 1237 radiusAuthServBadAuthenticators Counter32, 1238 radiusAuthServPacketsDropped Counter32, 1239 radiusAuthServUnknownTypes Counter32 1240 } 1242 radiusAuthClientAddress OBJECT-TYPE 1243 SYNTAX IpAddress 1244 MAX-ACCESS read-only 1245 STATUS current 1246 DESCRIPTION 1247 "The NAS-IP-Address of the RADIUS authentication client 1248 referred to in this table entry." 1249 ::= { radiusAuthClientEntry 2 } 1251 This object needs to be deprecated and replaced by one that 1252 supports both IPv4 and IPv6 addresses. 1254 5.070 RFC 2622 Routing Policy Specification Language (RPSL) 1256 The only objects in the version of RPSL that deal with IP addresses 1257 are defined as: 1259 An IPv4 address is represented as a sequence of four 1260 integers in the range from 0 to 255 separated by the character dot 1261 ".". For example, 128.9.128.5 represents a valid IPv4 address. 1262 In the rest of this document, we may refer to IPv4 addresses as IP 1263 addresses. 1265 An address prefix is represented as an IPv4 address 1266 followed by the character slash "/" followed by an integer in the 1267 range from 0 to 32. The following are valid address prefixes: 1268 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address 1269 prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not 1270 strings containing four integers. 1272 There seems to be an awareness of IPv6 because of the terminology but 1273 it is not specifically defined. Therefore additional objects for IPv6 1274 addresses and prefixes need to be defined. 1276 5.071 RFC 2662 Definitions of Managed Objects for the ADSL 1277 Lines 1279 There are no IPv4 dependencies in this specification. 1281 5.072 RFC 2667 IP Tunnel MIB 1283 The Abstract of this document says: 1285 This memo defines a Management Information Base (MIB) for use with 1286 network management protocols in the Internet community. In 1287 particular, it describes managed objects used for managing tunnels of 1288 any type over IPv4 networks. Extension MIBs may be designed for 1289 managing protocol-specific objects. Likewise, extension MIBs may be 1290 designed for managing security-specific objects. This MIB does not 1291 support tunnels over non-IPv4 networks (including IPv6 networks). 1292 Management of such tunnels may be supported by other MIBs. 1294 A similar MIB for tunneling over IPv6 should be defined. 1296 5.073 RFC 2669 DOCSIS Cable Device MIB Cable Device Management 1297 Information Base for DOCSIS compliant Cable Modems and 1298 Cable Modem Termination Systems 1300 This document states: 1302 Please note that the DOCSIS 1.0 standard only requires Cable 1303 Modems to implement SNMPv1 and to process IPv4 customer traffic. 1304 Design choices in this MIB reflect those requirements. Future 1305 versions of the DOCSIS standard are expected to require support 1306 for SNMPv3 and IPv6 as well. 1308 5.074 RFC 2670 Radio Frequency (RF) Interface Management Information 1309 Base for MCNS/DOCSIS compliant RF interfaces 1311 This MIB defines the following objects: 1313 DocsIfCmtsCmStatusEntry ::= SEQUENCE { 1314 docsIfCmtsCmStatusIndex Integer32, 1315 docsIfCmtsCmStatusMacAddress MacAddress, 1316 docsIfCmtsCmStatusIpAddress IpAddress, 1317 docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero, 1318 docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero, 1319 docsIfCmtsCmStatusRxPower TenthdBmV, 1320 docsIfCmtsCmStatusTimingOffset Unsigned32, 1321 docsIfCmtsCmStatusEqualizationData OCTET STRING, 1322 docsIfCmtsCmStatusValue INTEGER, 1323 docsIfCmtsCmStatusUnerroreds Counter32, 1324 docsIfCmtsCmStatusCorrecteds Counter32, 1325 docsIfCmtsCmStatusUncorrectables Counter32, 1326 docsIfCmtsCmStatusSignalNoise TenthdB, 1327 docsIfCmtsCmStatusMicroreflections Integer32 1328 } 1330 docsIfCmtsCmStatusIpAddress OBJECT-TYPE 1331 SYNTAX IpAddress 1332 MAX-ACCESS read-only 1333 STATUS current 1334 DESCRIPTION 1335 "IP address of this Cable Modem. If the Cable Modem has no 1336 IP address assigned, or the IP address is unknown, this 1337 object returns a value of 0.0.0.0. If the Cable Modem has 1338 multiple IP addresses, this object returns the IP address 1339 associated with the Cable interface." 1340 ::= { docsIfCmtsCmStatusEntry 3 } 1342 This object needs to be deprecated and replaced by one that 1343 supports both IPv4 and IPv6 addresses. 1345 5.075 RFC 2674 Definitions of Managed Objects for Bridges with 1346 Traffic Classes, Multicast Filtering and Virtual LAN 1347 Extensions 1349 There are no IPv4 dependencies in this specification. 1351 5.076 RFC 2677 Definitions of Managed Objects for the NBMA Next 1352 Hop Resolution Protocol (NHRP) 1354 There are no IPv4 dependencies in this specification. 1356 5.077 RFC 2720 Traffic Flow Measurement: Meter MIB 1358 This specification is both IPv4 and IPv6 aware and needs no changes. 1360 5.078 RFC 2725 Routing Policy System Security 1362 There are no IPv4 dependencies in this specification. 1364 5.079 RFC 2726 PGP Authentication for RIPE Database Updates 1366 There are no IPv4 dependencies in this specification. 1368 5.080 RFC 2737 Entity MIB (Version 2) 1370 There are no IPv4 dependencies in this specification. 1372 5.081 RFC 2741 Agent Extensibility (AgentX) Protocol Version 1 1374 Although the examples in the document are for IPv4 transport 1375 only, there is no IPv4 dependency in the AgentX protocol itself. 1377 5.082 RFC 2742 Definitions of Managed Objects for Extensible SNMP 1378 Agents 1380 There are no IPv4 dependencies in this specification. 1382 5.083 RFC 2748 The COPS (Common Open Policy Service) Protocol 1384 This specification is both IPv4 and IPv6 aware and needs no changes. 1386 5.084 RFC 2749 COPS usage for RSVP 1388 There are no IPv4 dependencies in this specification. 1390 5.085 RFC 2769 Routing Policy System Replication 1392 There are no IPv4 dependencies in this specification. 1394 5.086 RFC 2787 Definitions of Managed Objects for the Virtual 1395 Router Redundancy Protocol 1397 As stated in the Overview section: 1399 Since the VRRP protocol is intended for use with IPv4 routers only, 1400 this MIB uses the SYNTAX for IP addresses which is specific to IPv4. 1401 Thus, changes will be required for this MIB to interoperate in an 1402 IPv6 environment. 1404 5.087 RFC 2788 Network Services Monitoring MIB 1406 There are no IPv4 dependencies in this specification. 1408 5.088 RFC 2789 Mail Monitoring MIB 1410 There are no IPv4 dependencies in this specification. 1412 5.089 RFC 2837 Definitions of Managed Objects for the Fabric Element 1413 in Fibre Channel Standard 1415 There are no IPv4 dependencies in this specification. 1417 5.090 RFC 2856 Textual Conventions for Additional High Capacity 1418 Data Types 1420 There are no IPv4 dependencies in this specification. 1422 5.091 RFC 2864 The Inverted Stack Table Extension to the Interfaces 1423 Group MIB 1425 There are no IPv4 dependencies in this specification. 1427 5.092 RFC 2895 Remote Network Monitoring MIB Protocol Identifier 1428 Reference 1430 This specification is both IPv4 and IPv6 aware and needs no changes. 1432 5.093 RFC 2925 Definitions of Managed Objects for Remote 1433 Ping, Traceroute, and Lookup Operations 1435 This MIB mostly is IPv4 and IPv6 aware. There are a few 1436 assumptions that are problems, though. In the following object 1437 definitions: 1439 pingCtlDataSize OBJECT-TYPE 1440 SYNTAX Unsigned32 (0..65507) 1441 UNITS "octets" 1442 MAX-ACCESS read-create 1443 STATUS current 1444 DESCRIPTION 1445 "Specifies the size of the data portion to be 1446 transmitted in a ping operation in octets. A ping 1447 request is usually an ICMP message encoded 1448 into an IP packet. An IP packet has a maximum size 1449 of 65535 octets. Subtracting the size of the ICMP 1450 or UDP header (both 8 octets) and the size of the IP 1451 header (20 octets) yields a maximum size of 65507 1452 octets." 1453 DEFVAL { 0 } 1454 ::= { pingCtlEntry 5 } 1456 traceRouteCtlDataSize OBJECT-TYPE 1457 SYNTAX Unsigned32 (0..65507) 1458 UNITS "octets" 1459 MAX-ACCESS read-create 1460 STATUS current 1461 DESCRIPTION 1462 "Specifies the size of the data portion of a traceroute 1463 request in octets. A traceroute request is essentially 1464 transmitted by encoding a UDP datagram into a 1465 IP packet. So subtracting the size of a UDP header 1466 (8 octets) and the size of a IP header (20 octets) 1467 yields a maximum of 65507 octets." 1468 DEFVAL { 0 } 1469 ::= { traceRouteCtlEntry 6 } 1471 The DESCRIPTION clauses need to be updated to remove the 1472 IPv4 dependencies. 1474 5.094 RFC 2932 IPv4 Multicast Routing MIB 1476 This specification is only defined for IPv4 and a similar MIB 1477 must be defined for IPv6. 1479 5.095 RFC 2933 Internet Group Management Protocol MIB 1481 As stated in this document: 1483 Since IGMP is specific to IPv4, this MIB does not support management 1484 of equivalent functionality for other address families, such as IPv6. 1486 5.096 RFC 2940 Definitions of Managed Objects for Common 1487 Open Policy Service (COPS) Protocol Clients 1489 This MIB is both IPv4 and IPv6 aware and needs no changes. 1491 5.097 RFC 2954 Definitions of Managed Objects for Frame 1492 Relay Service 1494 There are no IPv4 dependencies in this specification. 1496 5.098 RFC 2955 Definitions of Managed Objects for Monitoring 1497 and Controlling the Frame Relay/ATM PVC Service 1498 Interworking Function 1500 There are no IPv4 dependencies in this specification. 1502 5.099 RFC 2959 Real-Time Transport Protocol Management 1503 Information Base 1505 There are no IPv4 dependencies in this specification. 1507 5.100 RFC 2981 Event MIB 1509 There are no IPv4 dependencies in this specification. 1511 5.101 RFC 2982 Distributed Management Expression MIB 1513 There are no IPv4 dependencies in this specification. 1515 5.102 RFC 3014 Notification Log MIB 1517 There are no IPv4 dependencies in this specification. 1519 5.103 RFC 3019 IP Version 6 Management Information Base for 1520 The Multicast Listener Discovery Protocol 1522 This is an IPv6 related document and is not discussed in this 1523 document. 1525 5.104 RFC 3020 Definitions of Managed Objects for Monitoring 1526 and Controlling the UNI/NNI Multilink Frame Relay Function 1528 There are no IPv4 dependencies in this specification. 1530 5.105 RFC 3055 Management Information Base for the PINT Services 1531 Architecture 1533 There are no IPv4 dependencies in this specification. 1535 5.106 RFC 3060 Policy Core Information Model -- Version 1 1536 Specification (CIM) 1538 There are no IPv4 dependencies in this specification. 1540 5.107 RFC 3084 COPS Usage for Policy Provisioning (COPS-PR) 1542 This specification builds on RFC 2748, and is both IPv4 1543 and IPv6 capable. The specification defines a sample filter in 1544 section 4.3, which has "ipv4" in it; however, it's just an example, 1545 and available to IPv6 as well with a simple replacement of "ipv4" 1546 with "ipv6". 1548 5.108 RFC 3165 Definitions of Managed Objects for the Delegation of 1549 Management Scripts. 1551 There are no IPv4 dependencies in this specification. 1553 5.109 RFC 3231 Definitions of Managed Objects for Scheduling Management 1554 Operations. 1556 There are no IPv4 dependecies in this specification. 1558 5.110 RFC 3291 Textual Conventions for Internet Network Addresses 1560 There are no IPv4 dependencies in this specification. 1562 5.111 RFC 3635 Definitions of Managed Objects for the 1563 Ethernet-like Interface Types 1565 There are no IPv4 dependencies in this specification. 1567 5.112 RFC 3636 Definitions of Managed Objects for IEEE 802.3 Medium 1568 Attachment Units (MAUs) 1570 There are no IPv4 dependencies in this specification. 1572 6.0 Experimental RFCs 1574 Experimental RFCs typically define protocols that do not have widescale 1575 implementation or usage on the Internet. They are often propriety in 1576 nature or used in limited arenas. They are documented to the Internet 1577 community in order to allow potential interoperability or some other 1578 potential useful scenario. In a few cases they are presented as 1579 alternatives to the mainstream solution to an acknowledged problem. 1581 6.01 RFC 1187 Bulk Table Retrieval with the SNMP 1583 There are no IPv4 dependencies in this specification. 1585 6.02 RFC 1224 Techniques for managing asynchronously generated 1586 alerts 1588 There are no IPv4 dependencies in this specification. 1590 6.03 RFC 1238 CLNS MIB for use with Connectionless Network Protocol 1591 (ISO 8473) and End System to Intermediate System (ISO 9542) 1593 There are no IPv4 dependencies in this specification. 1595 6.04 RFC 1592 Simple Network Management Protocol Distributed Protocol 1596 Interface Version 2.0 1598 There are no IPv4 dependencies in this specification. 1600 6.05 RFC 1792 TCP/IPX Connection Mib Specification 1602 There are no IPv4 dependencies in this specification. 1604 6.06 RFC 2724 RTFM: New Attributes for Traffic Flow Measurement 1606 There are no IPv4 dependencies in this specification. 1608 6.07 RFC 2758 Definitions of Managed Objects for Service Level 1609 Agreements Performance Monitoring 1611 This specification is both IPv4 and IPv6 aware and needs no changes. 1613 6.08 RFC 2786 Diffie-Helman USM Key Management Information Base and 1614 Textual Convention 1616 There are no IPv4 dependencies in this specification. 1618 6.09 RFC 2903 Generic AAA Architecture 1620 There are no IPv4 dependencies in this specification. 1622 6.10 RFC 2934 Protocol Independent Multicast MIB for IPv4 1624 This document is specific to IPv4. 1626 6.11 RFC 3179 Script MIB Extensibility Protocol Version 1.1 1628 There are no IPv4 dependencies in this specification. 1630 7.0 Summary of Results 1632 In the initial survey of RFCs 36 positives were identified out of a 1633 total of 153, broken down as follows: 1635 Standards 6 of 15 or 40.00% 1636 Draft Standards 4 of 15 or 26.67% 1637 Proposed Standards 26 of 112 or 23.21% 1638 Experimental RFCs 0 of 11 or 0.00% 1640 Of those identified many require no action because they document 1641 outdated and unused protocols, while others are document protocols 1642 that are actively being updated by the appropriate working groups. 1643 Additionally there are many instances of standards that should be 1644 updated but do not cause any operational impact if they are not 1645 updated. The remaining instances are documented below. 1647 7.1 Standards 1649 7.1.1 STD 16, Structure of Management Information (RFCs 1155 and 1212) 1651 RFCs 1155 and RFCs 1212 (along with the informational document RFC 1652 1215) define SMIv1. These documents have been superseded by RFCs 1653 2578, 2579, and 2580 which define SMIv2. Since SMIv1 is no longer 1654 being used as the basis for new IETF MIB modules, the limitations 1655 identified in this Internet Standard do not require any action. 1657 7.1.2 STD 17 Simple Network Management Protocol (RFC 1213) 1659 The limitations identified have been addressed, because RFC 1213 1660 has been split into multiple modules which are all IPv6 capable. 1662 7.2 Draft Standards 1664 7.2.1 BGP4 MIB (RFC 1657) 1666 This problem is currently being addressed by the Inter Domain Routing 1667 (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-11.txt). 1669 7.2.2 SMDS MIB (RFC 1694) 1671 See Internet Area standards. Once a specification for IPv6 over SMDS 1672 is created a new MIB must be defined. 1674 7.2.3 RIPv2 MIB (RFC 1724) 1676 There is no updated MIB module to cover the problems outlined. A 1677 new MIB module should be defined. 1679 7.2.4 OSPFv2 MIB (RFC 1850) 1681 This problem is currently being addressed by the OSPF WG and an ID 1682 exists (draft-ietf-ospf-ospfv3-mib-07.txt). 1684 7.2.5 Transport MIB (RFC 1906) 1686 RFC 1906 has been obsoleted by RFC 3417, Transport Mappings for 1687 SNMP, and the limitations of this specification have been addressed by 1688 that RFC, which defines TCs that can be used to specify transport 1689 domains in an IP version-independent way. RFC 3419 recommends that 1690 those TCs be used in place of SnmpUDPAddress when IPv6 support is 1691 required and for all new applications that are not SNMP-specific. 1693 7.3 Proposed Standards 1695 7.3.01 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) 1697 This problem has not been addressed. If a user requirement for 1698 IPv6 over X.25 develops (which is thought to be unlikely) then 1699 this MIB module will need to be updated in order to accomodate it. 1701 7.3.02 PPP IPCP MIB (RFC 1473) 1703 There is no updated MIB to cover the problems outlined. A new MIB 1704 should be defined. 1706 7.3.03 Appletalk MIB (RFC 1742) 1708 This problem has not been addressed. If a user requirement for 1709 IPv6 over Appletalk develops (which is thought to be unlikely) 1710 then this MIB module will need to be updated (or a new MIB module 1711 will need to be created) in order to accomodate it. 1713 7.3.04 The Definitions of Managed Objects for IP Mobility 1714 Support using SMIv2 (RFC 2006) 1716 The problems are being resolved by the MIP6 WG and there is 1717 an ID (draft-ietf-mip6-mipv6-mib-00.txt). 1719 7.3.05 SMIv2 IP MIB (RFC 2011) 1721 This issue is being resolved by the IPv6 WG and there is an 1722 ID (draft-ietf-ipv6-rfc2011-update-04.txt). 1724 7.3.06 SNMPv2 TCP MIB (RFC 2012) 1726 This issue is being resolved by the IPv6 WG and there is an 1727 ID (draft-ietf-ipv6-rfc2012-update-04.txt). 1729 7.3.07 SNMPv2 UDP MIB (RFC 2013) 1731 This issue is being resolved by the IPv6 WG and there is an 1732 ID (draft-ietf-ipv6-rfc2013-update-01.txt). 1734 7.3.08 RMON-II MIB (RFC 2021) 1736 This issue has been brought to the attention of the RMONMIB WG. 1737 Currently there is an ID (draft-ietf-rmonmib-rmon2-v2-00.txt) 1738 to update RFC 2021, but it does not address the problems that 1739 have been identified; it is expected that there will be a 1740 resolution in a future version of that ID. 1742 7.3.09 DataLink Switching using SMIv2 MIB (RFC 2024) 1744 The problems have not been addressed and an updated MIB should be 1745 defined. 1747 7.3.10 IP Forwarding Table MIB (RFC 2096) 1749 This issue is being worked on by the IPv6 WG and an ID exists to 1750 address this (draft-ietf-ipngwg-rfc2096-update-05.txt) 1752 7.3.11 Classical IP & ARP over ATM MIB (RFC 2320) 1754 The current version of Classical IP and ARP over ATM (RFC 2225) 1755 does not support IPv6. If and when that protocol specification 1756 is updated to add IPv6 support, then new MIB objects to represent 1757 IPv6 addresses will need to be added to this MIB module. 1759 7.3.12 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) 1761 The current version of Multicast over UNI 3.0/3.1 ATM (RFC 1762 2022) does not support IPv6. If and when that protocol 1763 specification is updated to add IPv6 support, then new MIB 1764 objects to represent IPv6 addresses will need to be added to 1765 this MIB module. 1767 7.3.13 ATM MIB (RFC 2515) 1769 The AToM MIB WG is currently collecting implementation reports for RFC 1770 2515 and is considering whether to advance, revise, or retire this 1771 specification. The problems identified have been brought to the 1772 attention of the WG. 1774 7.3.14 TN3270 MIB (RFC 2562) 1776 The problems identified are not being addressed and a new MIB 1777 module may need to be defined. 1779 7.3.15 Application MIB (RFC 2564) 1781 The problems identified are not being addressed and a new MIB 1782 module may need to be defined. One possible solution might be 1783 to use the RFC 3419 TCs. 1785 7.3.16 Definitions of Managed Objects for APPN/HPR in IP Networks 1786 (RFC 2584) 1788 The problems identified are not addressed and a new MIB may be 1789 defined. 1791 7.3.17 RADIUS MIB (RFC 2618) 1793 The problems have not been addressed and a new MIB should be defined. 1795 7.3.18 RADIUS Authentication Server MIB (RFC 2619) 1797 The problems have not been addressed and a new MIB should be defined. 1799 7.3.19 RPSL (RFC 2622) 1801 Additional objects must be defined for IPv6 addresses and prefixes. 1803 draft-blunk-rpslng-01.txt defines extensions to solve this issue, and 1804 it is being considered for publication. 1806 7.3.20 IPv4 Tunnel MIB (RFC 2667) 1808 The issue is being resolved and and ID exists 1809 (draft-thaler-inet-tunnel-mib-00.txt). 1811 7.3.21 DOCSIS MIB (RFC 2669) 1813 This problem is currently being addressed by the IPCDN WG and an ID 1814 is available (draft-ietf-ipcdn-device-mibv2-05.txt). 1816 7.3.22 RF MIB For DOCSIS (RFC 2670) 1818 This problem is currently being addressed by the IPCDN WG and an ID 1819 is available (draft-ietf-ipcdn-docs-rfmibv2-06.txt). 1821 7.3.23 VRRP MIB (RFC 2787) 1823 The problems have not been addressed and a new MIB may need to be 1824 defined. 1826 7.3.24 MIB For Traceroute, Pings and Lookups (RFC 2925) 1828 The problems have not been addressed and a new MIB may need to be 1829 defined. 1831 7.3.25 IPv4 Multicast Routing MIB (RFC 2932) 1833 The problems have not been addressed a new MIB must be defined. 1835 7.3.26 IGMP MIB (RFC 2933) 1837 This problem is currently being addressed by the MAGMA WG and an ID 1838 exists (draft-ietf-magma-mgmd-mib-01.txt). 1840 7.4 Experimental RFCs 1842 7.4.1 Protocol Independent Multicast MIB for IPv4 (RFC 2934) 1844 The problems have not been addressed and a new MIB may need to be 1845 defined. 1847 8.0 Security Consideration 1849 This memo examines the IPv6-readiness of specifications; this does not 1850 have security considerations in itself. 1852 9.0 Acknowledgements 1854 The authors would like to acknowledge the support of the Internet 1855 Society in the research and production of this document. 1856 Additionally the author, Philip J. Nesser II, would like to thanks 1857 his partner in all ways, Wendy M. Nesser. 1859 The editor, Andreas Bergstrom, would like to thank Pekka Savola 1860 for guidance and collection of comments for the editing of this 1861 document. 1862 He would further like to thank Juergen Schoenwaelder, Brian Carpenter, 1863 Bert Wijnen and especially C. M. Heard for feedback on many points of 1864 this document. 1866 10.0 References 1868 10.1 Normative 1870 [1] Philip J. Nesser II, Andreas Bergstrom. "Introduction to the Survey 1871 of IPv4 Addresses in Currently Deployed IETF Standards", 1872 draft-ietf-v6ops-ipv4survey-intro-05.txt IETF work in progress, 1873 November 2003 1875 11.0 Authors' Addresses 1877 Please contact the author with any questions, comments or suggestions 1878 at: 1880 Philip J. Nesser II 1881 Principal 1882 Nesser & Nesser Consulting 1883 13501 100th Ave NE, #5202 1884 Kirkland, WA 98034 1886 Email: phil@nesser.com 1887 Phone: +1 425 481 4303 1888 Fax: +1 425 48 1890 Andreas Bergstrom (Editor) 1891 Ostfold University College 1892 Email: andreas.bergstrom@hiof.no 1893 Address: Rute 503 Buer 1894 N-1766 Halden 1895 Norway 1897 12.0 Intellectual Property Statement 1899 The IETF takes no position regarding the validity or scope of any 1900 intellectual property or other rights that might be claimed to 1901 pertain to the implementation or use of the technology described in 1902 this document or the extent to which any license under such rights 1903 might or might not be available; neither does it represent that it 1904 has made any effort to identify any such rights. Information on the 1905 IETF's procedures with respect to rights in standards-track and 1906 standards-related documentation can be found in BCP-11. Copies of 1907 claims of rights made available for publication and any assurances of 1908 licenses to be made available, or the result of an attempt made to 1909 obtain a general license or permission for the use of such 1910 proprietary rights by implementors or users of this specification can 1911 be obtained from the IETF Secretariat. 1913 The IETF invites any interested party to bring to its attention any 1914 copyrights, patents or patent applications, or other proprietary 1915 rights which may cover technology that may be required to practice 1916 this standard. Please address the information to the IETF Executive 1917 Director. 1919 13.0 Full Copyright Statement 1921 Copyright (C) The Internet Society (2000). All Rights Reserved. 1923 This document and translations of it may be copied and furnished to 1924 others, and derivative works that comment on or otherwise explain it 1925 or assist in its implementation may be prepared, copied, published 1926 and distributed, in whole or in part, without restriction of any 1927 kind, provided that the above copyright notice and this paragraph are 1928 included on all such copies and derivative works. However, this docu- 1929 ment itself may not be modified in any way, such as by removing the 1930 copyright notice or references to the Internet Society or other 1931 Internet organizations, except as needed for the purpose of develop- 1932 ing Internet standards in which case the procedures for copyrights 1933 defined in the Internet Standards process must be followed, or as 1934 required to translate it into languages other than English. The lim- 1935 ited permissions granted above are perpetual and will not be revoked 1936 by the Internet Society or its successors or assigns. This document 1937 and the information contained herein is provided on an "AS IS" basis 1938 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1939 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1940 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1941 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1942 FITNESS FOR A PARTICULAR PURPOSE.