diff options
Diffstat (limited to 'doc/rfc/rfc6632.txt')
| -rw-r--r-- | doc/rfc/rfc6632.txt | 4763 |
1 files changed, 4763 insertions, 0 deletions
diff --git a/doc/rfc/rfc6632.txt b/doc/rfc/rfc6632.txt new file mode 100644 index 0000000..8c5ddf2 --- /dev/null +++ b/doc/rfc/rfc6632.txt @@ -0,0 +1,4763 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Ersue, Ed. +Request for Comments: 6632 Nokia Siemens Networks +Category: Informational B. Claise +ISSN: 2070-1721 Cisco Systems, Inc. + June 2012 + + + An Overview of the IETF Network Management Standards + +Abstract + + This document gives an overview of the IETF network management + standards and summarizes existing and ongoing development of IETF + Standards Track network management protocols and data models. The + document refers to other overview documents, where they exist and + classifies the standards for easy orientation. The purpose of this + document is, on the one hand, to help system developers and users to + select appropriate standard management protocols and data models to + address relevant management needs. On the other hand, the document + can be used as an overview and guideline by other Standard + Development Organizations or bodies planning to use IETF management + technologies and data models. This document does not cover + Operations, Administration, and Maintenance (OAM) technologies on the + data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) + OAM, and pseudowire as well as the corresponding management models. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6632. + + + + + + + + + + +Ersue & Claise Informational [Page 1] + +RFC 6632 IETF Management Standards June 2012 + + +Copyright Notice + + Copyright (c) 2012 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Scope and Target Audience ..................................4 + 1.2. Related Work ...............................................5 + 1.3. Terminology ................................................6 + 2. Core Network Management Protocols ...............................8 + 2.1. Simple Network Management Protocol (SNMP) ..................8 + 2.1.1. Architectural Principles of SNMP ....................8 + 2.1.2. SNMP and Its Versions ...............................9 + 2.1.3. Structure of Managed Information (SMI) .............11 + 2.1.4. SNMP Security and Access Control Models ............12 + 2.1.4.1. Security Requirements on the SNMP + Management Framework ......................12 + 2.1.4.2. User-Based Security Model (USM) ...........12 + 2.1.4.3. View-Based Access Control Model (VACM) ....13 + 2.1.5. SNMP Transport Subsystem and Transport Models ......13 + 2.1.5.1. SNMP Transport Security Model .............14 + 2.2. Syslog Protocol ...........................................15 + 2.3. IP Flow Information eXport (IPFIX) and Packet + SAMPling (PSAMP) Protocols ................................16 + 2.4. Network Configuration .....................................19 + 2.4.1. Network Configuration Protocol (NETCONF) ...........19 + 2.4.2. YANG - NETCONF Data Modeling Language ..............21 + 3. Network Management Protocols and Mechanisms with + Specific Focus .................................................23 + 3.1. IP Address Management .....................................23 + 3.1.1. Dynamic Host Configuration Protocol (DHCP) .........23 + 3.1.2. Ad Hoc Network Autoconfiguration ...................24 + 3.2. IPv6 Network Operations ...................................25 + 3.3. Policy-Based Management ...................................26 + 3.3.1. IETF Policy Framework ..............................26 + + + + +Ersue & Claise Informational [Page 2] + +RFC 6632 IETF Management Standards June 2012 + + + 3.3.2. Use of Common Open Policy Service (COPS) + for Policy Provisioning (COPS-PR) ..................26 + 3.4. IP Performance Metrics (IPPM) .............................27 + 3.5. Remote Authentication Dial-In User Service (RADIUS) .......29 + 3.6. Diameter Base Protocol (Diameter) .........................31 + 3.7. Control and Provisioning of Wireless Access Points + (CAPWAP) ..................................................35 + 3.8. Access Node Control Protocol (ANCP) .......................36 + 3.9. Application Configuration Access Protocol (ACAP) ..........36 + 3.10. XML Configuration Access Protocol (XCAP) .................37 + 4. Network Management Data Models .................................38 + 4.1. IETF Network Management Data Models .......................39 + 4.1.1. Generic Infrastructure Data Models .................39 + 4.1.2. Link-Layer Data Models .............................40 + 4.1.3. Network-Layer Data Models ..........................40 + 4.1.4. Transport-Layer Data Models ........................40 + 4.1.5. Application-Layer Data Models ......................41 + 4.1.6. Network Management Infrastructure Data Models ......41 + 4.2. Network Management Data Models - FCAPS View ...............41 + 4.2.1. Fault Management ...................................42 + 4.2.2. Configuration Management ...........................44 + 4.2.3. Accounting Management ..............................45 + 4.2.4. Performance Management .............................46 + 4.2.5. Security Management ................................48 + 5. Security Considerations ........................................49 + 6. Contributors ...................................................51 + 7. Acknowledgements ...............................................52 + 8. Informative References .........................................52 + Appendix A. High-Level Classification of Management Protocols + and Data Models .......................................77 + A.1. Protocols Classified by Standards Maturity in the IETF .....77 + A.2. Protocols Matched to Management Tasks ......................79 + A.3. Push versus Pull Mechanism .................................80 + A.4. Passive versus Active Monitoring ...........................80 + A.5. Supported Data Model Types and Their Extensibility ........81 + Appendix B. New Work Related to IETF Management Standards .........83 + B.1. Energy Management (EMAN) ...................................83 + + + + + + + + + + + + + + +Ersue & Claise Informational [Page 3] + +RFC 6632 IETF Management Standards June 2012 + + +1. Introduction + +1.1. Scope and Target Audience + + This document gives an overview of the IETF network management + standards and summarizes existing and ongoing development of IETF + Standards Track network management protocols and data models. The + document refers to other overview documents where they exist and + classifies the standards for easy orientation. + + The target audience of the document is, on the one hand, IETF working + groups, which aim to select appropriate standard management protocols + and data models to address their needs concerning network management. + On the other hand, the document can be used as an overview and + guideline by non-IETF Standards Development Organizations (SDOs) + planning to use IETF management technologies and data models for the + realization of management applications. The document can also be + used to initiate a discussion between the bodies with the goal to + gather new requirements and to detect possible gaps. Finally, this + document is directed to all interested parties that seek to get an + overview of the current set of the IETF network management protocols + such as network administrators or newcomers to the IETF. + + Section 2 gives an overview of the IETF core network management + standards with a special focus on Simple Network Management Protocol + (SNMP), syslog, IP Flow Information eXport / Packet SAMPling (IPFIX/ + PSAMP), and Network Configuration (NETCONF). Section 3 discusses + IETF management protocols and mechanisms with a specific focus, e.g., + IP address management or IP performance management. Section 4 + discusses IETF data models, such as MIB modules, IPFIX Information + Elements, Syslog Structured Data Elements, and YANG modules designed + to address a specific set of management issues and provides two + complementary overviews for the network management data models + standardized within the IETF. Section 4.1 focuses on a broader view + of models classified into categories such as generic and + infrastructure data models as well as data models matched to + different layers. Whereas Section 4.2 structures the data models + following the management application view and maps them to the + network management tasks fault, configuration, accounting, + performance, and security management. + + Appendix A guides the reader for the high-level selection of + management standards. For this, the section classifies the protocols + according to high-level criteria, such as push versus pull + mechanisms, passive versus active monitoring, as well as categorizes + the protocols concerning the network management task they address and + their data model extensibility. If the reader is interested only in + a subset of the IETF network management protocols and data models + + + +Ersue & Claise Informational [Page 4] + +RFC 6632 IETF Management Standards June 2012 + + + described in this document, Appendix A can be used as a dispatcher to + the corresponding chapter. Appendix B gives an overview of the new + work on Energy Management in the IETF. + + This document mainly refers to Proposed, Draft, or Internet Standard + documents from the IETF (see [RFCSEARCH]). Whenever valuable, Best + Current Practice (BCP) documents are referenced. In exceptional + cases, and if the document provides substantial guideline for + standard usage or fills an essential gap, Experimental and + Informational RFCs are noticed and ongoing work is mentioned. + + Information on active and concluded IETF working groups (e.g., their + charters, published or currently active documents, and mail archives) + can be found at [IETF-WGS]). + + Note that this document does not cover OAM technologies on the data- + path including MPLS forwarding plane and control plane protocols + (e.g., OAM of tunnels, MPLS-TP OAM, and pseudowire) as well as the + corresponding management models and MIB modules. For a list of + related work, see Section 1.2. + +1.2. Related Work + + "Internet Protocols for the Smart Grid" [RFC6272] gives an overview + and guidance on the key protocols of the Internet Protocol Suite. In + analogy to [RFC6272], this document gives an overview of the IETF + network management standards and their usage scenarios. + + "Overview of the 2002 IAB Network Management Workshop" [RFC3535] + documented strengths and weaknesses of some IETF management + protocols. In choosing existing protocol solutions to meet the + management requirements, it is recommended that these strengths and + weaknesses be considered, even though some of the recommendations + from the 2002 IAB workshop have become outdated, some have been + standardized, and some are being worked on within the IETF. + + "Guidelines for Considering Operations and Management of New + Protocols and Extensions" [RFC5706] recommends working groups + consider operations and management needs and then select appropriate + management protocols and data models. This document can be used to + ease surveying the IETF Standards Track network management protocols + and management data models. + + "Multiprotocol Label Switching (MPLS) Management Overview" [RFC4221] + describes the management architecture for MPLS and indicates the + interrelationships between the different MIB modules used for MPLS + + + + + +Ersue & Claise Informational [Page 5] + +RFC 6632 IETF Management Standards June 2012 + + + network management, where "Operations, Administration, and + Maintenance Framework for MPLS-Based Transport Networks" [RFC6371] + describes the OAM Framework for MPLS-based Transport Networks. + + "An Overview of Operations, Administration, and Maintenance (OAM) + Mechanisms" [OAM-OVERVIEW] gives an overview of the OAM toolset for + detecting and reporting connection failures or measuring connection + performance parameters. + + "An Overview of the OAM Tool Set for MPLS-based Transport Networks" + [OAM-ANALYSIS] provides an overview of the OAM toolset for MPLS-based + Transport Networks including a brief summary of MPLS-TP OAM + requirements and functions and of generic mechanisms created in the + MPLS data plane to allow the OAM packets run in-band and share their + fate with data packets. The protocol definitions for each MPLS-TP + OAM tool are listed in separate documents, which are referenced. + + "MPLS-TP MIB-based Management Overview" [MPLSTP-MIB] describes the + MIB-based architecture for MPLS-TP, and indicates the + interrelationships between different existing MIB modules that can be + leveraged for MPLS-TP network management and identifies areas where + additional MIB modules are required. + + Note that so far, the IETF has not developed specific technologies + for the management of sensor networks. IP-based sensors or + constrained devices in such an environment, i.e., with very limited + memory and CPU resources, can use, e.g., application-layer protocols + to do simple resource management and monitoring. + +1.3. Terminology + + This document does not describe standard requirements. Therefore, + key words from RFC 2119 [RFC2119] are not used in the document. + + o 3GPP: 3rd Generation Partnership Project, a collaboration between + groups of telecommunications associations, to prepare the third- + generation (3G) mobile phone system specification. + + o Agent: A software module that performs the network management + functions requested by network management stations. An agent may + be implemented in any network element that is to be managed, such + as a host, bridge, or router. The 'management server' in NETCONF + terminology. + + o BCP: An IETF Best Current Practice document. + + o CLI: Command Line Interface. A management interface that system + administrators can use to interact with networking equipment. + + + +Ersue & Claise Informational [Page 6] + +RFC 6632 IETF Management Standards June 2012 + + + o Data model: A mapping of the contents of an information model into + a form that is specific to a particular type of datastore or + repository (see [RFC3444]). + + o Event: An occurrence of something in the "real world". Events can + be indicated to managers through an event message or notification. + + o IAB: Internet Architecture Board + + o IANA: Internet Assigned Numbers Authority, an organization that + oversees global IP address allocation, autonomous system number + allocation, media types, and other IP-related code point + allocations. + + o Information model: An abstraction and representation of entities + in a managed environment, their properties, attributes, + operations, and the way they relate to each other, independent of + any specific repository, protocol, or platform (see [RFC3444]). + + o ITU-T: International Telecommunication Union - Telecommunication + Standardization Sector + + o Managed object: A management abstraction of a resource; a piece of + management information in a MIB module. In the context of SNMP, a + structured set of data variables that represent some resource to + be managed or other aspect of a managed device. + + o Manager: An entity that acts in a manager role, either a user or + an application. The counterpart to an agent. A 'management + client' in NETCONF terminology. + + o Management Information Base (MIB): An information repository with + a collection of related objects that represent the resources to be + managed. + + o MIB module: MIB modules usually contain object definitions, may + contain definitions of event notifications, and sometimes include + compliance statements in terms of appropriate object and event + notification groups. A MIB that is provided by a management agent + is typically composed of multiple instantiated MIB modules. + + o Modeling language: A modeling language is any artificial language + that can be used to express information or knowledge or systems in + a structure that is defined by a consistent set of rules. + Examples are Structure of Management Information Version 2 (SMIv2) + [STD58], XML Schema Definition (XSD) [XSD-1], and YANG [RFC6020]. + + + + + +Ersue & Claise Informational [Page 7] + +RFC 6632 IETF Management Standards June 2012 + + + o Notification: An unsolicited message sent by an agent to a + management station to notify it of an unusual event. + + o OAM: Operations, Administration, and Maintenance + + o PDU: Protocol Data Unit, a unit of data, which is specified in a + protocol of a given layer consisting protocol-control information + and possibly layer-specific data. + + o Principal: An application, an individual, or a set of individuals + acting in a particular role, on whose behalf access to a service + or MIB is allowed. + + o RELAX NG: REgular LAnguage for XML Next Generation, a schema + language for XML [RELAX-NG]. + + o SDO: Standards Development Organization + + o SMI: Structure of Managed Information, the notation and grammar + for the managed information definition used to define MIB modules + [STD58]. + + o STDnn: An Internet Standard published at IETF, also referred as + Standard, e.g., [STD62]. + + o URI: Uniform Resource Identifier, a string of characters used to + identify a name or a resource on the Internet [STD66]. Can be + classified as locators (URLs), as names (URNs), or as both. + + o XPATH: XML Path Language, a query language for selecting nodes + from an XML document [XPATH]. + +2. Core Network Management Protocols + +2.1. Simple Network Management Protocol (SNMP) + +2.1.1. Architectural Principles of SNMP + + The SNMPv3 Framework [RFC3410], builds upon both the original SNMPv1 + and SNMPv2 Frameworks. The basic structure and components for the + SNMP Framework did not change between its versions and comprises the + following components: + + o managed nodes, each with an SNMP entity providing remote access to + management instrumentation (the agent), + + o at least one SNMP entity with management applications (the + manager), and + + + +Ersue & Claise Informational [Page 8] + +RFC 6632 IETF Management Standards June 2012 + + + o a management protocol used to convey management information + between the SNMP entities and management information. + + During its evolution, the fundamental architecture of the SNMP + Management Framework remained consistent based on a modular + architecture, which consists of: + + o a generic protocol definition independent of the data it is + carrying, + + o a protocol-independent data definition language, + + o an information repository containing a data set of management + information definitions (the Management Information Base, or MIB), + and + + o security and administration. + + As such, the following standards build up the basis of the current + SNMP Management Framework: + + o the SNMPv3 protocol [STD62], + + o the modeling language SMIv2 [STD58], and + + o the MIB modules for different management issues. + + The SNMPv3 Framework extends the architectural principles of SNMPv1 + and SNMPv2 by: + + o building on these three basic architectural components, in some + cases, incorporating them from the SNMPv2 Framework by reference, + and + + o by using the same layering principles in the definition of new + capabilities in the security and administration portion of the + architecture. + +2.1.2. SNMP and Its Versions + + SNMP is based on three conceptual entities: Manager, Agent, and the + Management Information Base (MIB). In any configuration, at least + one manager node runs SNMP management software. Typically, network + devices, such as bridges, routers, and servers, are equipped with an + agent. The agent is responsible for providing access to a local MIB + of objects that reflects the resources and activity at its node. + + + + + +Ersue & Claise Informational [Page 9] + +RFC 6632 IETF Management Standards June 2012 + + + Following the manager-agent paradigm, an agent can generate + notifications and send them as unsolicited messages to the management + application. + + SNMPv2 enhances this basic functionality with an Inform PDU, a bulk + transfer capability and other functional extensions like an + administrative model for access control, security extensions, and + Manager-to-Manager communication. SNMPv2 entities can have a dual + role as manager and agent. However, neither SNMPv1 nor SNMPv2 offers + sufficient security features. To address the security deficiencies + of SNMPv1/v2, SNMPv3 [STD62] has been issued. + + "Coexistence between Version 1, Version 2, and Version 3 of the + Internet-standard Network Management Framework" [BCP074] gives an + overview of the relevant Standard documents on the three SNMP + versions. The BCP document furthermore describes how to convert MIB + modules from SMIv1 to SMIv2 format and how to translate notification + parameters. It also describes the mapping between the message + processing and security models. + + SNMP utilizes the MIB, a virtual information store of modules of + managed objects. Generally, standard MIB modules support common + functionality in a device. Operators often define additional MIB + modules for their enterprise or use the Command Line Interface (CLI) + to configure non-standard data in managed devices and their + interfaces. + + SNMPv2 Trap and Inform PDUs can alert an operator or an application + when some aspects of a protocol fail or encounter an error condition, + and the contents of a notification can be used to guide subsequent + SNMP polling to gather additional information about an event. + + SNMP is widely used for the monitoring of fault and performance data + and with its stateless nature, SNMP also works well for status + polling and determining the operational state of specific + functionality. The widespread use of counters in standard MIB + modules permits the interoperable comparison of statistics across + devices from different vendors. Counters have been especially useful + in monitoring bytes and packets going in and out over various + protocol interfaces. SNMP is often used to poll a basic parameter of + a device (e.g., sysUpTime, which reports the time since the last re- + initialization of the network management portion of the device) to + check for operational liveliness and to detect discontinuities in + counters. Some operators also use SNMP for configuration management + in their environment (e.g., for systems based on Data Over Cable + Service Interface Specification (DOCSIS) such as cable modems). + + + + + +Ersue & Claise Informational [Page 10] + +RFC 6632 IETF Management Standards June 2012 + + + SNMPv1 [RFC1157] has been declared Historic and its use is not + recommended due to its lack of security features. "Introduction to + Community-based SNMPv2" [RFC1901] is an Experimental RFC, which has + been declared Historic, and its use is not recommended due to its + lack of security features. + + Use of SNMPv3 [STD62] is recommended due to its security features, + including support for authentication, encryption, message timeliness + and integrity checking, and fine-grained data access controls. An + overview of the SNMPv3 document set is in [RFC3410]. + + Standards exist to use SNMP over diverse transport and link-layer + protocols, including Transmission Control Protocol (TCP) [STD07], + User Datagram Protocol (UDP) [STD06], Ethernet [RFC4789], and others + (see Section 2.1.5.1). + +2.1.3. Structure of Managed Information (SMI) + + SNMP MIB modules are defined with the notation and grammar specified + as the Structure of Managed Information (SMI). The SMI uses an + adapted subset of Abstract Syntax Notation One (ASN.1) [ITU-X680]. + + The SMI is divided into three parts: module definitions, object + definitions, and notification definitions. + + o Module definitions are used when describing information modules. + An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the + semantics of an information module. + + o Object definitions are used when describing managed objects. An + ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax + and semantics of a managed object. + + o Notification definitions are used when describing unsolicited + transmissions of management information. An ASN.1 macro, + NOTIFICATION-TYPE, is used to concisely convey the syntax and + semantics of a notification. + + SMIv1 is specified in "Structure and Identification of Management + Information for TCP/IP-based Internets" [RFC1155] and "Concise MIB + Definitions" [RFC1212], both part of [STD16]. [RFC1215] specifies + conventions for defining SNMP traps. Note that SMIv1 is outdated and + its use is not recommended. + + SMIv2 is the new notation for managed information definitions and + should be used to define MIB modules. SMIv2 is specified in the + following RFCs. With the exception of BCP 74, they are all part of + [STD58]: + + + +Ersue & Claise Informational [Page 11] + +RFC 6632 IETF Management Standards June 2012 + + + o [RFC2578] defines Version 2 of the Structure of Management + Information (SMIv2), + + o [RFC2579] defines the textual conventions macro for defining new + types and it provides a core set of generally useful textual + convention definitions, + + o [RFC2580] defines conformance statements and requirements for + defining agent and manager capabilities, and + + o [BCP074] defines the mapping rules for and the conversion of MIB + modules between SMIv1 and SMIv2 formats. + +2.1.4. SNMP Security and Access Control Models + +2.1.4.1. Security Requirements on the SNMP Management Framework + + Several of the classical threats to network protocols are applicable + to management problem space and therefore are applicable to any + security model used in an SNMP Management Framework. This section + lists primary and secondary threats, and threats that are of lesser + importance (see [RFC3411] for the detailed description of the + security threats). + + The primary threats against which SNMP Security Models can provide + protection are, "modification of information" by an unauthorized + entity, and "masquerade", i.e., the danger that management operations + not authorized for some principal may be attempted by assuming the + identity of another principal. + + Secondary threats against which SNMP Security Models can provide + protection are "message stream modification", e.g., reordering, + delay, or replay of messages, and "disclosure", i.e., the danger of + eavesdropping on the exchanges between SNMP engines. + + There are two threats against which the SNMP Security Model does not + protect, since they are deemed to be of lesser importance in this + context: Denial of Service and Traffic Analysis (see [RFC3411]). + +2.1.4.2. User-Based Security Model (USM) + + SNMPv3 [STD62] introduced the User-based Security Model (USM). USM + is specified in [RFC3414] and provides authentication and privacy + services for SNMP. Specifically, USM is designed to secure against + the primary and secondary threats discussed in Section 2.1.4.1. USM + does not secure against Denial of Service and attacks based on + Traffic Analysis. + + + + +Ersue & Claise Informational [Page 12] + +RFC 6632 IETF Management Standards June 2012 + + + The USM supports following security services: + + o Data integrity is the provision of the property that data has not + been altered or destroyed in an unauthorized manner, nor have data + sequences been altered to an extent greater than can occur non- + maliciously. + + o Data origin authentication is the provision of the property that + the claimed identity of the user on whose behalf received data was + originated is supported. + + o Data confidentiality is the provision of the property that + information is not made available or disclosed to unauthorized + individuals, entities, or processes. + + o Message timeliness and limited replay protection is the provision + of the property that a message whose generation time is outside of + a specified time window is not accepted. + + See [RFC3414] for a detailed description of SNMPv3 USM. + +2.1.4.3. View-Based Access Control Model (VACM) + + SNMPv3 [STD62] introduced the View-based Access Control (VACM) + facility. The VACM is defined in [RFC3415] and enables the + configuration of agents to provide different levels of access to the + agent's MIB. An agent entity can restrict access to a certain + portion of its MIB, e.g., restrict some principals to view only + performance-related statistics or disallow other principals to read + those performance-related statistics. An agent entity can also + restrict the access to monitoring (read-only) as opposed to + monitoring and configuration (read-write) of a certain portion of its + MIB, e.g., allowing only a single designated principal to update + configuration parameters. + + VACM defines five elements that make up the Access Control Model: + groups, security level, contexts, MIB views, and access policy. + Access to a MIB module is controlled by means of a MIB view. + + See [RFC3415] for a detailed description of SNMPv3 VACM. + +2.1.5. SNMP Transport Subsystem and Transport Models + + The User-based Security Model (USM) was designed to be independent of + other existing security infrastructures to ensure it could function + when third-party authentication services were not available. As a + result, USM utilizes a separate user and key-management + + + + +Ersue & Claise Informational [Page 13] + +RFC 6632 IETF Management Standards June 2012 + + + infrastructure. Operators have reported that the deployment of a + separate user and key-management infrastructure in order to use + SNMPv3 is costly and hinders the deployment of SNMPv3. + + SNMP Transport Subsystem [RFC5590] extends the original SNMP + architecture and Transport Model and enables the use of transport + protocols to provide message security unifying the administrative + security management for SNMP and other management interfaces. + + Transport Models are tied into the SNMP Framework through the + Transport Subsystem. The Transport Security Model [RFC5591] has been + designed to work on top of lower-layer, secure Transport Models. + + The SNMP Transport Model defines an alternative to existing standard + transport mappings described in [RFC3417], e.g., for SNMP over UDP, + in [RFC4789] for SNMP over IEEE 802 networks, and in the Experimental + RFC [RFC3430] defining SNMP over TCP. + +2.1.5.1. SNMP Transport Security Model + + The SNMP Transport Security Model [RFC5591] is an alternative to the + existing SNMPv1 and SNMPv2 Community-based Security Models [BCP074], + and the User-based Security Model [RFC3414], part of [STD62]. + + The Transport Security Model utilizes one or more lower-layer + security mechanisms to provide message-oriented security services. + These include authentication of the sender, encryption, timeliness + checking, and data integrity checking. + + A secure Transport Model sets up an authenticated and possibly + encrypted session between the Transport Models of two SNMP engines. + After a transport-layer session is established, SNMP messages can be + sent through this session from one SNMP engine to the other. The new + Transport Model supports the sending of multiple SNMP messages + through the same session to amortize the costs of establishing a + security association. + + The Secure Shell (SSH) Transport Model [RFC5592] and the Transport + Layer Security (TLS) Transport Model [RFC6353] are current examples + of Transport Security Models. + + The SSH Transport Model makes use of the commonly deployed SSH + security and key-management infrastructure. Furthermore, [RFC5592] + defines MIB objects for monitoring and managing the SSH Transport + Model for SNMP. + + + + + + +Ersue & Claise Informational [Page 14] + +RFC 6632 IETF Management Standards June 2012 + + + The Transport Layer Security (TLS) Transport Model [RFC6353] uses + either the TLS protocol [RFC5246] or the Datagram Transport Layer + Security (DTLS) protocol [RFC6347]. The TLS and DTLS protocols + provide authentication and privacy services for SNMP applications. + The TLS Transport Model supports the sending of SNMP messages over + TLS and TCP and over DTLS and UDP. Furthermore, [RFC6353] defines + MIB objects for managing the TLS Transport Model for SNMP. + + [RFC5608] describes the use of a Remote Authentication Dial-In User + Service (RADIUS) service by SNMP secure Transport Models for + authentication of users and authorization of services. Access + control authorization, i.e., how RADIUS attributes and messages are + applied to the specific application area of SNMP Access Control + Models, and VACM in particular has been specified in [RFC6065]. + +2.2. Syslog Protocol + + Syslog is a mechanism for distribution of logging information + initially used on Unix systems (see [RFC3164] for BSD syslog). The + IETF Syslog Protocol [RFC5424] introduces a layered architecture + allowing the use of any number of transport protocols, including + reliable and secure transports, for transmission of syslog messages. + + The Syslog protocol enables a machine to send system log messages + across networks to event message collectors. The protocol is simply + designed to transport and distribute these event messages. By + default, no acknowledgements of the receipt are made, except the + reliable delivery extensions specified in [RFC3195] are used. The + Syslog protocol and process does not require a stringent coordination + between the transport sender and the receiver. Indeed, the + transmission of syslog messages may be started on a device without a + receiver being configured, or even actually physically present. + Conversely, many devices will most likely be able to receive messages + without explicit configuration or definitions. + + BSD syslog had little uniformity for the message format and the + content of syslog messages. The body of a BSD syslog message has + traditionally been unstructured text. This content is human + friendly, but difficult to parse for applications. With the Syslog + Protocol [RFC5424], the IETF has standardized a new message header + format, including timestamp, hostname, application, and message ID, + to improve filtering, interoperability, and correlation between + compliant implementations. + + The Syslog protocol [RFC5424] also introduces a mechanism for + defining Structured Data Elements (SDEs). The SDEs allow vendors to + define their own structured data elements to supplement standardized + elements. [RFC5675] defines a mapping from SNMP notifications to + + + +Ersue & Claise Informational [Page 15] + +RFC 6632 IETF Management Standards June 2012 + + + syslog messages. [RFC5676] defines an SNMP MIB module to represent + syslog messages for the purpose of sending those syslog messages as + notifications to SNMP notification receivers. [RFC5674] defines the + way alarms are sent in syslog, which includes the mapping of ITU- + perceived severities onto syslog message fields and a number of + alarm-specific definitions from ITU-T X.733 [ITU-X733] and the IETF + Alarm MIB [RFC3877]. + + "Signed Syslog Messages" [RFC5848] defines a mechanism to add origin + authentication, message integrity, replay resistance, message + sequencing, and detection of missing messages to the transmitted + syslog messages to be used in conjunction with the Syslog protocol. + + The Syslog protocol's layered architecture provides support for a + number of transport mappings. For interoperability purposes and + especially in managed networks, where the network path has been + explicitly provisioned for UDP syslog traffic, the Syslog protocol + can be used over UDP [RFC5426]. However, to support congestion + control and reliability, [RFC5426] strongly recommends the use of the + TLS transport. + + Furthermore, the IETF defined the TLS Transport Mapping for syslog in + [RFC5425], which provides a secure connection for the transport of + syslog messages. [RFC5425] describes the security threats to syslog + and how TLS can be used to counter such threats. [RFC6012] defines + the Datagram Transport Layer Security (DTLS) Transport Mapping for + syslog, which can be used if a connectionless transport is desired. + + For information on MIB modules related to syslog, see Section 4.2.1. + +2.3. IP Flow Information eXport (IPFIX) and Packet SAMPling (PSAMP) + Protocols + + "Specification of the IP Flow Information Export (IPFIX) Protocol for + the Exchange of IP Traffic Flow Information" (the IPFIX Protocol) + [RFC5101] defines a push-based data export mechanism for transferring + IP flow information in a compact binary format from an Exporter to a + Collector. + + "Architecture for IP Flow Information Export" (the IPFIX + Architecture) [RFC5470] defines the components involved in IP flow + measurement and reporting of information on IP flows, particularly, a + Metering Process generating Flow Records, an Exporting Process that + sends metered flow information using the IPFIX protocol, and a + Collecting Process that receives flow information as IPFIX Data + Records. + + + + + +Ersue & Claise Informational [Page 16] + +RFC 6632 IETF Management Standards June 2012 + + + After listing the IPFIX requirements in [RFC3917], NetFlow Version 9 + [RFC3954] was taken as the basis for the IPFIX protocol and the IPFIX + architecture. + + IPFIX can run over different transport protocols. The IPFIX Protocol + [RFC5101] specifies Stream Control Transmission Protocol (SCTP) + [RFC4960] as the mandatory transport protocol to implement. Optional + alternatives are TCP [STD07] and UDP [STD06]. + + SCTP is used with its Partial Reliability extension (PR-SCTP) + specified in [RFC3758]. [RFC6526] specifies an extension to + [RFC5101], when using the PR-SCTP [RFC3758]. The extension offers + several advantages over IPFIX export, e.g., the ability to calculate + Data Record losses for PR-SCTP, immediate reuse of Template IDs + within an SCTP stream, reduced likelihood of Data Record loss, and + reduced demands on the Collecting Process. + + IPFIX transmits IP flow information in Data Records containing IPFIX + Information Elements (IEs) defined by the IPFIX Information Model + [RFC5102]. IPFIX IEs are quantities with unit and semantics defined + by the Information Model. When transmitted over the IPFIX protocol, + only their values need to be carried in Data Records. This compact + encoding allows efficient transport of large numbers of measured flow + values. Remaining redundancy in Data Records can be further reduced + by the methods described in [RFC5473] (for further discussion on + IPFIX IEs, see Section 4). + + The IPFIX Information Model is extensible. New IEs can be registered + at IANA (see "IPFIX Information Elements" in [IANA-PROT]). IPFIX + also supports the use of proprietary, i.e., enterprise-specific IEs. + + The PSAMP protocol [RFC5476] extends the IPFIX protocol by means of + transferring information on individual packets. [RFC5475] specifies + a set of sampling and filtering techniques for IP packet selection, + based on the PSAMP Framework [RFC5474]. The PSAMP Information Model + [RFC5477] provides a set of basic IEs for reporting packet + information with the IPFIX/PSAMP protocol. + + The IPFIX model of an IP traffic flow is unidirectional. [RFC5103] + adds means of reporting bidirectional flows to IPFIX, for example, + both directions of packet flows of a TCP connection. + + When enterprise-specific IEs are transmitted with IPFIX, a Collector + receiving Data Records may not know the type of received data and + cannot choose the right format for storing the contained information. + [RFC5610] provides a means of exporting extended type information for + enterprise-specific Information Elements from an Exporter to a + Collector. + + + +Ersue & Claise Informational [Page 17] + +RFC 6632 IETF Management Standards June 2012 + + + Collectors may store received flow information in files. The IPFIX + file format [RFC5655] can be used for storing IP flow information in + a way that facilitates exchange of traffic flow information between + different systems and applications. + + In terms of IPFIX and PSAMP configurations, the Metering and + Exporting Processes are configured out of band. As the IPFIX + protocol is a push mechanism only, IPFIX cannot configure the + Exporter. The actual configuration of selection processes, caches, + Exporting Processes, and Collecting Processes of IPFIX- and PSAMP- + compliant monitoring devices is executed using the NETCONF protocol + [RFC6241] (see Section 2.4.1). The "Configuration Data Model for + IPFIX and PSAMP" (the IPFIX Configuration Data Model) [CONF-MODEL] + has been specified using Unified Modeling Language (UML) class + diagrams. The data model is formally defined using the YANG modeling + language [RFC6020] (see Section 2.4.2). + + At the time of this writing, a framework for IPFIX flow mediation is + in preparation, which addresses the need for mediation of flow + information in IPFIX applications in large operator networks, e.g., + for aggregating huge amounts of flow data and for anonymization of + flow information (see the problem statement in [RFC5982]). + + The IPFIX Mediation Framework [RFC6183] defines the intermediate + device between Exporters and Collectors, which provides an IPFIX + mediation by receiving a record stream from, e.g., a Collecting + Process, hosting one or more Intermediate Processes to transform this + stream, and exporting the transformed record stream into IPFIX + messages via an Exporting Process. + + Examples for mediation functions are flow aggregation, flow + selection, and anonymization of traffic information (see [RFC6235]). + + Privacy, integrity, and authentication of the Exporter and Collector + are important security requirements for IPFIX [RFC3917]. + Confidentiality, integrity, and authenticity of IPFIX data + transferred from an Exporting Process to a Collecting Process must be + ensured. The IPFIX and PSAMP protocols do not define any new + security mechanisms and rely on the security mechanism of the + underlying transport protocol, such as TLS [RFC5246] and DTLS + [RFC6347]. + + The primary goal of IPFIX is the reporting of the flow accounting for + flexible flow definitions and usage-based accounting. As described + in the IPFIX Applicability Statement [RFC5472], there are also other + applications such as traffic profiling, traffic engineering, + intrusion detection, and QoS monitoring, that require flow-based + traffic measurements and can be realized using IPFIX. Furthermore, + + + +Ersue & Claise Informational [Page 18] + +RFC 6632 IETF Management Standards June 2012 + + + the IPFIX Applicability Statement explains the relation of IPFIX to + other framework and protocols such as PSAMP, RMON (Remote Network + Monitoring MIB, Section 4.2.1), and IPPM (IP Performance Metrics, + Section 3.4)). Similar flow information could be also used for + security monitoring. The addition of Performance Metrics in the + IPFIX IANA registry [IANA-IPFIX], will extend the IPFIX use case to + performance management. + + Note that even if the initial IPFIX focus has been around IP flow + information exchange, non-IP-related IEs are now specified in the + IPFIX IANA registration (e.g., MAC (Media Access Control) address, + MPLS (Multiprotocol Label Switching) labels, etc.). At the time of + this writing, there are requests to widen the focus of IPFIX and to + export non-IP related IEs (such as SIP monitoring IEs). + + The IPFIX structured data [RFC6313] is an extension to the IPFIX + protocol, which supports hierarchical structured data and lists + (sequences) of Information Elements in Data Records. This extension + allows the definition of complex data structures such as variable- + length lists and specification of hierarchical containment + relationships between templates. Furthermore, the extension provides + the semantics to express the relationship among multiple list + elements in a structured Data Record. + + For information on data models related to the management of the IPFIX + and PSAMP protocols, see Sections 4.2.1 and 4.2.2. For information + on IPFIX/PSAMP IEs, see Section 4.2.3. + +2.4. Network Configuration + +2.4.1. Network Configuration Protocol (NETCONF) + + The IAB workshop on Network Management [RFC3535] determined advanced + requirements for configuration management: + + o robustness: Minimizing disruptions and maximizing stability, + + o a task-oriented view, + + o extensibility for new operations, + + o standardized error handling, + + o clear distinction between configuration data and operational + state, + + o distribution of configurations to devices under transactional + constraints, + + + +Ersue & Claise Informational [Page 19] + +RFC 6632 IETF Management Standards June 2012 + + + o single- and multi-system transactions and scalability in the + number of transactions and managed devices, + + o operations on selected subsets of management data, + + o dumping and reloading a device configuration in a textual format + in a standard manner across multiple vendors and device types, + + o a human interface and a programmatic interface, + + o a data modeling language with a human-friendly syntax, + + o easy conflict detection and configuration validation, and + + o secure transport, authentication, and robust access control. + + The NETCONF protocol [RFC6241] provides mechanisms to install, + manipulate, and delete the configuration of network devices and aims + to address the configuration management requirements pointed out in + the IAB workshop. It uses an XML-based data encoding for the + configuration data as well as the protocol messages. The NETCONF + protocol operations are realized on top of a simple and reliable + Remote Procedure Call (RPC) layer. A key aspect of NETCONF is that + it allows the functionality of the management protocol to closely + mirror the native command-line interface of the device. + + The NETCONF working group developed the NETCONF Event Notifications + Mechanism as an optional capability, which provides an asynchronous + message notification delivery service for NETCONF [RFC5277]. The + NETCONF notification mechanism enables using general purpose + notification streams, where the originator of the notification stream + can be any managed device (e.g., SNMP notifications). + + The NETCONF Partial Locking specification introduces fine-grained + locking of the configuration datastore to enhance NETCONF for fine- + grained transactions on parts of the datastore [RFC5717]. + + The NETCONF working group also defined the necessary data model to + monitor the NETCONF protocol [RFC6022], by using the modeling + language YANG [RFC6020] (see Section 2.4.2). The monitoring data + model includes information about NETCONF datastores, sessions, locks, + and statistics, which facilitate the management of a NETCONF server. + + NETCONF connections are required to provide authentication, data + integrity, confidentiality, and replay protection. NETCONF depends + on the underlying transport protocol for this capability. For + example, connections can be encrypted in TLS or SSH, depending on the + underlying protocol. + + + +Ersue & Claise Informational [Page 20] + +RFC 6632 IETF Management Standards June 2012 + + + The NETCONF working group defined the SSH transport protocol as the + mandatory transport binding [RFC6242]. Other optional transport + bindings are TLS [RFC5539], Blocks Extensible Exchange Protocol + (BEEP) over TLS [RFC4744], and Simple Object Access Protocol (SOAP) + over HTTP over TLS [RFC4743]. + + The NETCONF Access Control Model (NACM) [RFC6536] provides standard + mechanisms to restrict protocol access to particular users with a + pre-configured subset of operations and content. + +2.4.2. YANG - NETCONF Data Modeling Language + + Following the guidelines of the IAB management workshop [RFC3535], + the NETMOD working group developed a data modeling language defining + the semantics of operational and configuration data, notifications, + and operations [RFC6020]. The new data modeling language, called + YANG, maps directly to XML-encoded content (on the wire) and will + serve as the normative description of NETCONF data models. + + YANG has the following properties addressing specific requirements on + a modeling language for configuration management: + + o YANG provides the means to define hierarchical data models. It + supports reusable data types and groupings, i.e., a set of schema + nodes that can be reused across module boundaries. + + o YANG supports the distinction between configuration and state + data. In addition, it provides support for modeling event + notifications and the specification of operations that extend the + base NETCONF operations. + + o YANG allows the expression of constraints on data models by means + of type restrictions and XML Path Language (XPATH) 1.0 [XPATH] + expressions. XPATH expressions can also be used to make certain + portions of a data model conditional. + + o YANG supports the integration of standard- and vendor-defined data + models. YANG's augmentation mechanism allows the seamless + augmentation of standard data models with proprietary extensions. + + o YANG data models can be partitioned into collections of features, + allowing low-end devices only to implement the core features of a + data model while high-end devices may choose to support all + features. The supported features are announced via the NETCONF + capability exchange to management applications. + + + + + + +Ersue & Claise Informational [Page 21] + +RFC 6632 IETF Management Standards June 2012 + + + o The syntax of the YANG language is compact and optimized for human + readers. An associated XML-based syntax called the YANG + Independent Notation (YIN) [RFC6020] is available to allow the + processing of YANG data models with XML-based tools. The mapping + rules for the translation of YANG data models into Document Schema + Definition Languages (DSDL), of which RELAX NG is a major + component, are defined in [RFC6110]. + + o Devices implementing standard data models can document deviations + from the data model in separate YANG modules. Applications + capable of discovering deviations can make allowances that would + otherwise not be possible. + + A collection of common data types for IETF-related standards is + provided in [RFC6021]. This standard data type library has been + derived to a large extend from common SMIv2 data types, generalizing + them to a less-constrained NETCONF Framework. + + The document "An Architecture for Network Management using NETCONF + and YANG" describes how NETCONF and YANG can be used to build network + management applications that meet the needs of network operators + [RFC6244]. + + The Experimental RFC [RFC6095] specifies extensions for YANG, + introducing language abstractions such as class inheritance and + recursive data structures. + + [RFC6087] gives guidelines for the use of YANG within the IETF and + other standardization organizations. + + Work is underway to standardize a translation of SMIv2 data models + into YANG data models preserving investments into SNMP MIB modules, + which are widely available for monitoring purposes [SMI-YANG]. + + Several independent and open source implementations of the YANG data + modeling language and associated tools are available. + + While YANG is a relatively recent data modeling language, some data + models have already been produced. The specification of the base + NETCONF protocol operations has been revised and uses YANG as the + normative modeling language to specify its operations [RFC6241]. The + IPFIX working group prepared the normative model for configuring and + monitoring IPFIX- and PSAMP-compliant monitoring devices using the + YANG modeling language [CONF-MODEL]. + + + + + + + +Ersue & Claise Informational [Page 22] + +RFC 6632 IETF Management Standards June 2012 + + + At the time of this writing, the NETMOD working group is developing + core system and interface data models. Following the example of the + IPFIX configuration model, IETF working groups will prepare models + for their specific needs. + + For information on data models developed using the YANG modeling + language, see Sections 4.2.1 and 4.2.2. + +3. Network Management Protocols and Mechanisms with Specific Focus + + This section reviews additional protocols the IETF offers for + management and discusses for which applications they were designed + and/or have already been successfully deployed. These are protocols + that have mostly reached Proposed Standard status or higher within + the IETF. + +3.1. IP Address Management + +3.1.1. Dynamic Host Configuration Protocol (DHCP) + + Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a + framework for passing configuration information to hosts on a TCP/IP + network and, as such, enables autoconfiguration in IP networks. In + addition to IP address management, DHCP can also provide other + configuration information, such as default routers, the IP addresses + of recursive DNS servers, and the IP addresses of NTP servers. As + described in [RFC6272], DHCP can be used for IPv4 and IPv6 Address + Allocation and Assignment as well as for Service Discovery. + + There are two versions of DHCP: one for IPv4 (DHCPv4) [RFC2131] and + one for IPv6 (DHCPv6) [RFC3315]. DHCPv4 was defined as an extension + to BOOTP (Bootstrap Protocol) [RFC0951]. DHCPv6 was subsequently + defined to accommodate new functions required by IPv6 such as + assignment of multiple addresses to an interface and to address + limitations in the design of DHCPv4 resulting from its origins in + BOOTP. While both versions bear the same name and perform the same + functionality, the details of DHCPv4 and DHCPv6 are sufficiently + different that they can be considered separate protocols. + + In addition to the assignment of IP addresses and other configuration + information, DHCP options like the Relay Agent Information option + (DHCPv4) [RFC3046] and, the Interface-Id Option (DHCPv6) [RFC3315] + are widely used by ISPs. + + DHCPv6 includes Prefix Delegation [RFC3633], which is used to + provision a router with an IPv6 prefix for use in the subnetwork + supported by the router. + + + + +Ersue & Claise Informational [Page 23] + +RFC 6632 IETF Management Standards June 2012 + + + The following are examples of DHCP options that provide configuration + information or access to specific servers. A complete list of DHCP + options is available at [IANA-PROT]. + + o "DNS Configuration options for Dynamic Host Configuration Protocol + for IPV6 (DHCPv6)" [RFC3646] describes DHCPv6 options for passing + a list of available DNS recursive name servers and a domain search + list to a client. + + o "DHCP Options for Service Location Protocol" [RFC2610] describes + DHCPv4 options and methods through which entities using the + Service Location Protocol can find out the address of Directory + Agents in order to transact messages and how the assignment of + scope for configuration of Service Location Protocol (SLP) User + and Service Agents can be achieved. + + o "Dynamic Host Configuration Protocol (DHCPv6) Options for Session + Initiation Protocol (SIP) Servers" [RFC3319] specifies DHCPv6 + options that allow SIP clients to locate a local SIP server that + is to be used for all outbound SIP requests, a so-called "outbound + proxy server". + + o "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast + and Multicast Control Servers" [RFC4280] defines DHCPv6 options to + discover the Broadcast and Multicast Service (BCMCS) controller in + an IP network. + + Built directly on UDP and IP, DHCP itself has no security provisions. + There are two different classes of potential security issues related + to DHCP: unauthorized DHCP Servers and unauthorized DHCP Clients. + The recommended solutions to these risks generally involve providing + security at lower layers, e.g., careful control over physical access + to the network, security techniques implemented at Layer 2 but also + IPsec at Layer 3 can be used to provide authentication. + +3.1.2. Ad Hoc Network Autoconfiguration + + Ad hoc nodes need to configure their network interfaces with locally + unique addresses as well as globally routable IPv6 addresses, in + order to communicate with devices on the Internet. The IETF AUTOCONF + working group developed [RFC5889], which describes the addressing + model for ad hoc networks and how nodes in these networks configure + their addresses. + + The ad hoc nodes under consideration are expected to be able to + support multi-hop communication by running MANET (Mobile Ad Hoc + Network) routing protocols as developed by the IETF MANET working + group. + + + +Ersue & Claise Informational [Page 24] + +RFC 6632 IETF Management Standards June 2012 + + + From the IP layer perspective, an ad hoc network presents itself as a + Layer 3 multi-hop network formed over a collection of links. The + addressing model aims to avoid problems for parts of the system that + are ad hoc unaware, such as standard applications running on an ad + hoc node or regular Internet nodes attached to the ad hoc nodes. + +3.2. IPv6 Network Operations + + The IPv6 Operations (V6OPS) working group develops guidelines for the + operation of a shared IPv4/IPv6 Internet and provides operational + guidance on how to deploy IPv6 into existing IPv4-only networks, as + well as into new network installations. + + o "Basic Transition Mechanisms for IPv6 Hosts and Routers" [RFC4213] + specifies IPv4 compatibility mechanisms for dual-stack and + configured tunneling that can be implemented by IPv6 hosts and + routers. "Dual stack" implies providing complete implementations + of both IPv4 and IPv6, and configured tunneling provides a means + to carry IPv6 packets over unmodified IPv4 routing + infrastructures. + + o "Transition Scenarios for 3GPP Networks" [RFC3574] lists different + scenarios in 3GPP defined packet network that would need IPv6 and + IPv4 transition, where "Analysis on IPv6 Transition in Third + Generation Partnership Project (3GPP) Networks" [RFC4215] does a + more detailed analysis of the transition scenarios that may come + up in the deployment phase of IPv6 in 3GPP packet networks. + + o "Scenarios and Analysis for Introducing IPv6 into ISP Networks" + [RFC4029] describes and analyzes different scenarios for the + introduction of IPv6 into an ISP's existing IPv4 network. "IPv6 + Deployment Scenarios in 802.16 Networks" [RFC5181] provides a + detailed description of IPv6 deployment, integration methods, and + scenarios in wireless broadband access networks (802.16) in + coexistence with deployed IPv4 services. [RFC4057] describes the + scenarios for IPv6 deployment within enterprise networks. + + o "Application Aspects of IPv6 Transition" [RFC4038] specifies + scenarios and application aspects of IPv6 transition considering + how to enable IPv6 support in applications running on IPv6 hosts, + and giving guidance for the development of IP-version-independent + applications. + + o "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] + updates RFC 5735 and requested the allocation of an IPv4/10 + address block to be used as "Shared Carrier-Grade Network Address + + + + + +Ersue & Claise Informational [Page 25] + +RFC 6632 IETF Management Standards June 2012 + + + Translation (CGN) Space" by Service Providers to number the + interfaces that connect CGN devices to Customer Premises Equipment + (CPE). + +3.3. Policy-Based Management + +3.3.1. IETF Policy Framework + + The IETF specified a general policy framework [RFC2753] for managing, + sharing, and reusing policies in a vendor-independent, interoperable, + and scalable manner. [RFC3460] specifies the Policy Core Information + Model (PCIM) as an object-oriented information model for representing + policy information. PCIM has been developed jointly in the IETF + Policy Framework (POLICY) working group and the Common Information + Model (CIM) activity in the Distributed Management Task Force (DMTF). + PCIM has been published as extensions to CIM [DMTF-CIM]. + + The IETF Policy Framework is based on a policy-based admission + control specifying two main architectural elements: the Policy + Enforcement Point (PEP) and the Policy Decision Point (PDP). For the + purpose of network management, policies allow an operator to specify + how the network is to be configured and monitored by using a + descriptive language. Furthermore, it allows the automation of a + number of management tasks, according to the requirements set out in + the policy module. + + The IETF Policy Framework has been accepted by the industry as a + standard-based policy management approach and has been adopted by + different SDOs, e.g., for 3GGP charging standards. + +3.3.2. Use of Common Open Policy Service (COPS) for Policy Provisioning + (COPS-PR) + + [RFC3159] defines the Structure of Policy Provisioning Information + (SPPI), an extension to the SMIv2 modeling language used to write + Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the + Common Open Policy Service (COPS) protocol [RFC2748] for the + provisioning of policy information. COPS provides a simple client/ + server model for supporting policy control over QoS signaling + protocols. The COPS-PR specification is independent of the type of + policy being provisioned (QoS, security, etc.) but focuses on the + mechanisms and conventions used to communicate provisioned + information between policy-decision-points (PDPs) and policy + enforcement points (PEPs). Policy data is modeled using PIB modules. + + COPS-PR has not been widely deployed, and operators have stated that + its use of binary encoding for management data makes it difficult to + develop automated scripts for simple configuration management tasks + + + +Ersue & Claise Informational [Page 26] + +RFC 6632 IETF Management Standards June 2012 + + + in most text-based scripting languages. In the IAB Workshop on + Network Management [RFC3535], the consensus of operators and protocol + developers indicated a lack of interest in PIB modules for use with + COPS-PR. + + As a result, even if COPS-PR and the Structure of Policy Provisioning + Information (SPPI) were initially approved as Proposed Standards, the + IESG has not approved any PIB modules as Proposed Standard, and the + use of COPS-PR is not recommended. + +3.4. IP Performance Metrics (IPPM) + + The IPPM working group has defined metrics for accurately measuring + and reporting the quality, performance, and reliability of Internet + data delivery. The metrics include connectivity, one-way delay and + loss, round-trip delay and loss, delay variation, loss patterns, + packet reordering, bulk transport capacity, and link bandwidth + capacity. + + These metrics are designed for use by network operators and their + customers, and they provide unbiased quantitative measures of + performance. The IPPM metrics have been developed inside an active + measurement context, that is, the devices used to measure the metrics + produce their own traffic. However, most of the metrics can be used + inside a passive context as well. At the time of this writing, there + is no work planned in the area of passive measurement. + + As a property, individual IPPM performance and reliability metrics + need to be well defined and concrete: thus, implementable. + Furthermore, the methodology used to implement a metric needs to be + repeatable with consistent measurements. + + IPPMs have been adopted by different organizations, e.g., the Metro + Ethernet Forum. + + Note that this document does not aim to cover OAM technologies on the + data-path and, as such, the discussion of IPPM-based active versus + passive monitoring as well as the data plane measurement and its + diagnostics is rather incomplete. For a detailed overview and + discussion of IETF OAM standards and IPPM measurement mechanisms, the + reader is referred to the documents listed at the end of Section 1.2 + ("Related Work") but especially to [OAM-OVERVIEW]. + + + + + + + + + +Ersue & Claise Informational [Page 27] + +RFC 6632 IETF Management Standards June 2012 + + + The following are essential IPPM documents: + + o "Framework for IP Performance Metrics" [RFC2330] defines a general + framework for particular metrics developed by the IPPM working + group, and it defines the fundamental concepts of 'metric' and + 'measurement methodology'. It also discusses the issue of + measurement uncertainties and errors as well as introduces the + notion of empirically defined metrics and how metrics can be + composed. + + o "A One-way Delay Metric for IPPM" [RFC2679] defines a metric for + the one-way delay of packets across Internet paths. It builds on + notions introduced in the IPPM Framework document. + + o "A Round-trip Delay Metric for IPPM" [RFC2681] defines a metric + for the round-trip delay of packets across network paths and + closely follows the corresponding metric for one-way delay. + + o "IP Packet Delay Variation Metric for IP Performance Metrics + (IPPM)" [RFC3393] refers to a metric for variation in the delay of + packets across network paths and is based on the difference in the + one-way-delay of selected packets called "IP Packet Delay + Variation (ipdv)". + + o "A One-way Packet Loss Metric for IPPM" [RFC2680] defines a metric + for one-way packet loss across Internet paths. + + o "A One-Way Packet Duplication Metric" [RFC5560] defines a metric + for the case where multiple copies of a packet are received, and + it discusses methods to summarize the results of streams. + + o "Packet Reordering Metrics" [RFC4737] defines metrics to evaluate + whether a network has maintained packet order on a packet-by- + packet basis and discusses the measurement issues, including the + context information required for all metrics. + + o "IPPM Metrics for Measuring Connectivity" [RFC2678] defines a + series of metrics for connectivity between a pair of Internet + hosts. + + o "Framework for Metric Composition" [RFC5835] describes a detailed + framework for composing and aggregating metrics. + + o "Guidelines for Considering New Performance Metric Development" + [BCP170] describes the framework and process for developing + Performance Metrics of protocols and applications transported over + IETF-specified protocols. + + + + +Ersue & Claise Informational [Page 28] + +RFC 6632 IETF Management Standards June 2012 + + + To measure these metrics, two protocols and a sampling method have + been standardized: + + o "A One-way Active Measurement Protocol (OWAMP)" [RFC4656] measures + unidirectional characteristics such as one-way delay and one-way + loss between network devices and enables the interoperability of + these measurements. OWAMP is discussed in more detail in + [OAM-OVERVIEW]. + + o "A Two-Way Active Measurement Protocol (TWAMP)" [RFC5357] adds + round-trip or two-way measurement capabilities to OWAMP. TWAMP is + discussed in more detail in [OAM-OVERVIEW]. + + o "Network performance measurement with periodic streams" [RFC3432] + describes a periodic sampling method and relevant metrics for + assessing the performance of IP networks, as an alternative to the + Poisson sampling method described in [RFC2330]. + + For information on MIB modules related to IP Performance Metrics see + Section 4.2.4. + +3.5. Remote Authentication Dial-In User Service (RADIUS) + + "Remote Authentication Dial In User Service (RADIUS)" [RFC2865] + describes a client/server protocol for carrying authentication, + authorization, and configuration information between a Network Access + Server (NAS), which desires to authenticate its links, and a shared + authentication server. The companion document "Radius Accounting" + [RFC2866] describes a protocol for carrying accounting information + between a NAS and a shared accounting server. [RFC2867] adds + required new RADIUS accounting attributes and new values designed to + support the provision of tunneling in dial-up networks. + + The RADIUS protocol is widely used in environments like enterprise + networks, where a single administrative authority manages the network + and protects the privacy of user information. RADIUS is deployed in + the networks of fixed broadband access provider as well as cellular + broadband operators. + + RADIUS uses attributes to carry the specific authentication, + authorization, information, and configuration details. RADIUS is + extensible with a known limitation of a maximum of 255 attribute + codes and 253 octets as attribute content length. RADIUS has Vendor- + Specific Attributes (VSAs), which have been used both for vendor- + specific purposes (as an addition to standardized attributes) as well + as to extend the limited attribute code space. + + + + + +Ersue & Claise Informational [Page 29] + +RFC 6632 IETF Management Standards June 2012 + + + The RADIUS protocol uses a shared secret along with the MD5 hash + algorithm to secure passwords [RFC1321]. Based on the known threads, + additional protection like IPsec tunnels [RFC4301] are used to + further protect the RADIUS traffic. However, building and + administering large IPsec-protected networks may become a management + burden, especially when the IPsec-protected RADIUS infrastructure + should provide inter-provider connectivity. Moving towards TLS-based + security solutions [RFC5246] and establishing dynamic trust + relationships between RADIUS servers has become a trend. Since the + introduction of TCP transport for RADIUS [RFC6613], it became natural + to have TLS support for RADIUS. An ongoing work is "Transport Layer + Security (TLS) encryption for RADIUS" [RFC6614]. + + "RADIUS Attributes for Tunnel Protocol Support" [RFC2868] defines a + number of RADIUS attributes designed to support the compulsory + provision of tunneling in dial-up network access. Some applications + involve compulsory tunneling, i.e., the tunnel is created without any + action from the user and without allowing the user any choice in the + matter. In order to provide this functionality, specific RADIUS + attributes are needed to carry the tunneling information from the + RADIUS server to the tunnel end points. "Signalling Connection + Control Part User Adaptation Layer (SUA)" [RFC3868] defines the + necessary attributes, attribute values, and the required IANA + registries. + + "RADIUS and IPv6" [RFC3162] specifies the operation of RADIUS over + IPv6 and the RADIUS attributes used to support the IPv6 network + access. "RADIUS Delegated-IPv6-Prefix Attribute" [RFC4818] describes + how to transport delegated IPv6 prefix information over RADIUS. + + "RADIUS Attributes for Virtual LAN and Priority Support" [RFC4675] + defines additional attributes for dynamic Virtual LAN assignment and + prioritization, for use in provisioning of access to IEEE 802 local + area networks usable with RADIUS and diameter. + + "Common Remote Authentication Dial In User Service (RADIUS) + Implementation Issues and Suggested Fixes" [RFC5080] describes common + issues seen in RADIUS implementations and suggests some fixes. Where + applicable, unclear statements and errors in previous RADIUS + specifications are clarified. People designing extensions to RADIUS + protocol for various deployment cases should get familiar with + "RADIUS Design Guidelines" [RFC6158] in order to avoid, e.g., known + interoperability challenges. + + "RADIUS Extension for Digest Authentication" [RFC5090] defines an + extension to the RADIUS protocol to enable support of Digest + Authentication, for use with HTTP-style protocols like the Session + Initiation Protocol (SIP) and HTTP. + + + +Ersue & Claise Informational [Page 30] + +RFC 6632 IETF Management Standards June 2012 + + + "Carrying Location Objects in RADIUS and DIAMETER" [RFC5580] + describes procedures for conveying access-network ownership and + location information based on civic and geospatial location formats + in RADIUS and diameter. + + "Remote Authentication Dial-In User Service (RADIUS) Authorization + for Network Access Server (NAS) Management" [RFC5607] specifies + required RADIUS attributes and their values for authorizing a + management access to a NAS. Both local and remote management are + supported, with access rights and management privileges. Specific + provisions are made for remote management via Framed Management + protocols, such as SNMP and NETCONF, and for management access over a + secure transport protocol. + + "RADIUS (Remote Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)" [RFC3579] describes how to + use RADIUS to convey an EAP [RFC3748] payload between the + authenticator and the EAP server using RADIUS. RFC 3579 is widely + implemented, for example, in WLAN and 802.1 X environments. "IEEE + 802.1X Remote Authentication Dial In User Service (RADIUS) Usage + Guidelines" [RFC3580] describes how to use RADIUS with IEEE 802.1X + authenticators. In the context of 802.1X and EAP-based + authentication, the VSAs described in [RFC2458] have been widely + accepted by the industry. "RADIUS Extensions" [RFC2869] is another + important RFC related to EAP use. RFC 2869 describes additional + attributes for carrying AAA information between a NAS and a shared + accounting server using RADIUS. It also defines attributes to + encapsulate EAP message payload. + + There are different MIB modules defined for multiple purposes to use + with RADIUS (see Sections 4.2.3 and 4.2.5). + +3.6. Diameter Base Protocol (Diameter) + + Diameter [RFC3588] provides an Authentication, Authorization, and + Accounting (AAA) framework for applications such as network access or + IP mobility. Diameter is also intended to work in local AAA and in + roaming scenarios. Diameter provides an upgrade path for RADIUS but + is not directly backwards compatible. + + Diameter is designed to resolve a number of known problems with + RADIUS. Diameter supports server failover, reliable transport over + TCP and SCTP, well-documented functions for proxy, redirect and relay + agent functions, server-initiated messages, auditability, and + capability negotiation. Diameter also provides a larger attribute + space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS. + Diameter features make it especially appropriate for environments, + + + + +Ersue & Claise Informational [Page 31] + +RFC 6632 IETF Management Standards June 2012 + + + where the providers of services are in different administrative + domains than the maintainer (protector) of confidential user + information. + + Other notable differences to RADIUS are as follows: + + o Network and Transport Layer Security (IPsec or TLS), + + o Stateful and stateless models, + + o Dynamic discovery of peers (using DNS Service Record (SRV) and + Naming Authority Pointer (NAPTR)), + + o Concept of an application that describes how a specific set of + commands and Attribute-Value Pairs (AVPs) are treated by diameter + nodes. Each application has an IANA-assigned unique identifier, + + o Support of application layer acknowledgements, failover methods + and state machines, + + o Basic support for user-sessions and accounting, + + o Better roaming support, + + o Error notification, and + + o Easy extensibility. + + The Diameter protocol is designed to be extensible to support, e.g., + proxies, brokers, mobility and roaming, Network Access Servers + (NASREQ), and Accounting and Resource Management. Diameter + applications extend the Diameter base protocol by adding new commands + and/or attributes. Each application is defined by a unique IANA- + assigned application identifier and can add new command codes and/or + new mandatory AVPs. + + The Diameter application identifier space has been divided into + Standards Track and 'First Come First Served' vendor-specific + applications. The following are examples of Diameter applications + published at IETF: + + o Diameter Base Protocol Application [RFC3588]: Required support + from all Diameter implementations. + + o Diameter Base Accounting Application [RFC3588]: A Diameter + application using an accounting protocol based on a server- + directed model with capabilities for real-time delivery of + accounting information. + + + +Ersue & Claise Informational [Page 32] + +RFC 6632 IETF Management Standards June 2012 + + + o Diameter Mobile IPv4 Application [RFC4004]: A Diameter application + that allows a Diameter server to authenticate, authorize, and + collect accounting information for Mobile IPv4 services rendered + to a mobile node. + + o Diameter Network Access Server Application (NASREQ, [RFC4005]): A + Diameter application used for AAA services in the NAS environment. + + o Diameter Extensible Authentication Protocol Application [RFC4072]: + A Diameter application that carries EAP packets between a NAS and + a back-end authentication server. + + o Diameter Credit-Control Application [RFC4006]: A Diameter + application that can be used to implement real-time credit-control + for a variety of end-user services such as network access, Session + Initiation Protocol (SIP) services, messaging services, and + download services. + + o Diameter Session Initiation Protocol Application [RFC4740]: A + Diameter application designed to be used in conjunction with SIP + and provides a Diameter client co-located with a SIP server, with + the ability to request the authentication of users and + authorization of SIP resources usage from a Diameter server. + + o Diameter Quality-of-Service Application [RFC5866]: A Diameter + application allowing network elements to interact with Diameter + servers when allocating QoS resources in the network. + + o Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]: A Diameter + application that enables the interaction between a Mobile IP home + agent and a Diameter server and is used when the mobile node is + authenticated and authorized using IKEv2 [RFC5996]. + + o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]: A + Diameter application that enables the interaction between a Mobile + IP home agent and a Diameter server and is used when the mobile + node is authenticated and authorized using the Mobile IPv6 + Authentication Protocol [RFC4285]. + + The large majority of Diameter applications are vendor-specific and + mainly used in various SDOs outside the IETF. One example SDO using + diameter extensively is 3GPP (e.g., 3GPP 'IP Multimedia Subsystem' + (IMS) uses diameter-based interfaces (e.g., Cx) [3GPPIMS]). + Recently, during the standardization of the '3GPP Evolved Packet + Core' [3GPPEPC], diameter was chosen as the only AAA signaling + protocol. + + + + + +Ersue & Claise Informational [Page 33] + +RFC 6632 IETF Management Standards June 2012 + + + One part of diameter's extensibility mechanism is an easy and + consistent way of creating new commands for the need of applications. + RFC 3588 proposed to define diameter command code allocations with a + new RFC. This policy decision caused undesired use and redefinition + of existing command codes within SDOs. Diverse RFCs have been + published as simple command code allocations for other SDO purposes + (see [RFC3589], [RFC5224], [RFC5431], and [RFC5516]). [RFC5719] + changed the command code policy and added a range for vendor-specific + command codes to be allocated on a 'First Come First Served' basis by + IANA. + + The implementation and deployment experience of diameter has led to + the ongoing development of an update of the base protocol [DIAMETER], + which introduces TLS as the preferred security mechanism and + deprecates the in-band security negotiation for TLS. + + Some Diameter protocol enhancements and clarifications that logically + fit better into [DIAMETER], are also needed on the existing + deployments based on RFC 3588. Therefore, protocol extensions + specifically usable in large inter-provider roaming network scenarios + are made available for RFC 3588. Two currently existing + specifications are mentioned below: + + o "Clarifications on the Routing of Diameter Requests Based on the + Username and the Realm" [RFC5729] defines the behavior required + for Diameter agents to route requests when the User-Name AVP + contains a NAI formatted with multiple realms. These multi-realm + Network Access Identifiers are used in order to force the routing + of request messages through a predefined list of mediating realms. + + o "Diameter Straightforward-Naming Authority Pointer (S-NAPTR) + Usage" [RFC6408] describes an improved DNS-based dynamic Diameter + agent discovery mechanism without having to do diameter capability + exchange beforehand with a number of agents. + + There have been a growing number of Diameter Framework documents from + the IETF that basically are just a collection of AVPs for a specific + purpose or a system architecture with semantic AVP descriptions and a + logic for "imaginary" applications. From a standardization point of + view, this practice allows the development of larger system + architecture documents that do not need to reference AVPs or + application logic outside the IETF. Below are examples of a few + recent AVP and Framework documents: + + + + + + + + +Ersue & Claise Informational [Page 34] + +RFC 6632 IETF Management Standards June 2012 + + + o "Diameter Mobile IPv6: Support for Network Access Server to + Diameter Server Interaction" [RFC5447] describes the bootstrapping + of the Mobile IPv6 framework and the support of interworking with + existing AAA infrastructures by using the diameter NAS-to-home-AAA + server interface. + + o "Traffic Classification and Quality of Service (QoS) Attributes + for Diameter" [RFC5777] defines a number of Diameter AVPs for + traffic classification with actions for filtering and QoS + treatment. + + o "Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local + Mobility Anchor Interaction with Diameter Server" [RFC5779] + defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) + entities (MAG and LMA) and a AAA server within a PMIPv6 Domain. + + For information on MIB modules related to diameter, see + Section 4.2.5. + +3.7. Control and Provisioning of Wireless Access Points (CAPWAP) + + Wireless LAN (WLAN) product architectures have evolved from single + autonomous Access Points to systems consisting of a centralized + Access Controller (AC) and Wireless Termination Points (WTPs). The + general goal of centralized control architectures is to move access + control, including user authentication and authorization, mobility + management, and radio management from the single access point to a + centralized controller, where an Access Point pulls the information + from the AC. + + Based on "Architecture Taxonomy for Control and Provisioning of + Wireless Access Points (CAPWAP)" [RFC4118], the CAPWAP working group + developed the CAPWAP protocol [RFC5415] to facilitate control, + management, and provisioning of WTPs specifying the services, + functions, and resources relating to 802.11 WLAN Termination Points + in order to allow for interoperable implementations of WTPs and ACs. + The protocol defines the CAPWAP control plane, including the + primitives to control data access. The protocol document also + specifies how configuration management of WTPs can be done and + defines CAPWAP operations responsible for debugging, gathering + statistics, logging, and managing firmware as well as discusses + operational and transport considerations. + + The CAPWAP protocol is prepared to be independent of Layer 2 + technologies, and meets the objectives in "Objectives for Control and + Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate + + + + + +Ersue & Claise Informational [Page 35] + +RFC 6632 IETF Management Standards June 2012 + + + binding extensions enable the use with additional wireless + technologies. [RFC5416] defines the CAPWAP Protocol Binding for IEEE + 802.11. + + CAPWAP Control messages, and optionally CAPWAP Data messages, are + secured using DTLS [RFC6347]. DTLS is used as a tightly integrated, + secure wrapper for the CAPWAP protocol. + + For information on MIB modules related to CAPWAP, see Section 4.2.2. + +3.8. Access Node Control Protocol (ANCP) + + The Access Node Control Protocol (ANCP) [RFC6320] realizes a control + plane between a service-oriented Layer 3 edge device, the NAS and a + Layer 2 Access Node (AN), e.g., Digital Subscriber Line Access Module + (DSLAM). As such, ANCP operates in a multi-service reference + architecture and communicates QoS-, service-, and subscriber-related + configuration and operation information between a NAS and an AN. + + The main goal of this protocol is to configure and manage access + equipment and allow them to report information to the NAS in order to + enable and optimize configuration. + + The framework and requirements for an AN control mechanism and the + use cases for ANCP are documented in [RFC5851]. + + ANCP offers authentication and authorization between AN and NAS nodes + and provides replay protection and data-origin authentication. The + ANCP solution is also robust against Denial-of-Service (DoS) attacks. + Furthermore, the ANCP solution is recommended to offer + confidentiality protection. Security Threats and Security + Requirements for ANCP are discussed in [RFC5713]. + +3.9. Application Configuration Access Protocol (ACAP) + + The Application Configuration Access Protocol (ACAP) [RFC2244] is + designed to support remote storage and access of program option, + configuration, and preference information. The datastore model is + designed to allow a client relatively simple access to interesting + data, to allow new information to be easily added without server + reconfiguration, and to promote the use of both standardized data and + custom or proprietary data. Key features include "inheritance", + which can be used to manage default values for configuration settings + and access control lists that allow interesting personal information + to be shared and group information to be restricted. + + + + + + +Ersue & Claise Informational [Page 36] + +RFC 6632 IETF Management Standards June 2012 + + + ACAP's primary purpose is to allow applications access to their + configuration data from multiple network-connected computers. Users + can then use any network-connected computer, run any ACAP-enabled + application, and have access to their own configuration data. To + enable wide usage client simplicity has been preferred to server or + protocol simplicity whenever reasonable. + + The ACAP 'authenticate' command uses Simple Authentication and + Security Layer (SASL) [RFC4422] to provide basic authentication, + authorization, integrity, and privacy services. All ACAP + implementations are required to implement the CRAM-MD5 (Challenge- + Response Authentication Mechanism) [RFC2195] for authentication, + which can be disabled based on the site security policy. + +3.10. XML Configuration Access Protocol (XCAP) + + The Extensible Markup Language (XML) Configuration Access Protocol + (XCAP) [RFC4825] has been designed for and is commonly used with SIP- + based solutions, in particular, for instant messages, presence, and + SIP conferences. XCAP is a protocol that allows a client to read, + write, and modify application configuration data stored in XML format + on a server, where the main functionality is provided by so-called + "XCAP Application Usages". + + XCAP is a protocol that can be used to manipulate per-user data. + XCAP is a set of conventions for mapping XML documents and document + components into HTTP URIs, rules for how the modification of one + resource affects another, data validation constraints, and + authorization policies associated with access to those resources. + Because of this structure, normal HTTP primitives can be used to + manipulate the data. Like ACAP, XCAP supports the configuration + needs for a multiplicity of applications. + + All XCAP servers are required to implement HTTP Digest Authentication + [RFC2617]. Furthermore, XCAP servers are required to implement HTTP + over TLS (HTTPS) [RFC2818]. It is recommended that administrators + use an HTTPS URI as the XCAP root URI, so that the digest client + authentication occurs over TLS. + + The following list summarizes important XCAP application usages: + + o XCAP server capabilities [RFC4825] can be read by clients to + determine which extensions, application usages, or namespaces a + server supports. + + o A resource lists application is any application that needs access + to a list of resources, identified by a URI, to which operations, + such as subscriptions, can be applied [RFC4826]. + + + +Ersue & Claise Informational [Page 37] + +RFC 6632 IETF Management Standards June 2012 + + + o A Resource List Server (RLS) Services application is a SIP + application, where a server receives SIP SUBSCRIBE requests for + resources and generates subscriptions towards the resource list + [RFC4826]. + + o A Presence Rules application uses authorization policies, also + known as authorization rules, to specify what presence information + can be given to which watchers, and when [RFC4827]. + + o A 'pidf-manipulation' application defines how XCAP is used to + manipulate the contents of PIDF-based presence documents + [RFC4827]. + +4. Network Management Data Models + + This section provides two complementary overviews for the network + management data models standardized at IETF. The first subsection + focuses on a broader view of models classified into categories such + as generic and infrastructure data models as well as data models + matched to different layers. The second subsection is structured + following the management application view and focuses mainly on the + data models for the network management tasks fault, configuration, + accounting, performance, and security management (see [FCAPS]). + + Note that the IETF does not use the FCAPS view as an organizing + principle for its data models. However, the FCAPS view is used + widely outside of the IETF for the realization of management tasks + and applications. Section 4.2 aims to address the FCAPS view to + enable people outside of the IETF to understand the relevant data + models in the IETF. + + The different data models covered in this section are MIB modules, + IPFIX Information Elements, Syslog Structured Data Elements, and YANG + modules. There are many technology-specific IETF data models, such + as transmission and protocol MIBs, which are not mentioned in this + document and can be found at [RFCSEARCH]. + + This section gives an overview of management data models that have + reached Draft or Proposed Standard status at the IETF. In + exceptional cases, important Informational RFCs are referenced. The + advancement process for management data models beyond Proposed + Standard status, has been defined in [BCP027] with a more pragmatic + approach and special considerations on data model specification + interoperability. However, most IETF management data models never + advanced beyond Proposed Standard. + + + + + + +Ersue & Claise Informational [Page 38] + +RFC 6632 IETF Management Standards June 2012 + + +4.1. IETF Network Management Data Models + + The data models defined by the IETF can be broadly classified into + the following categories depicted in Figure 1. + + +-----------+ +-------------------------------+ +-----------+ + | | | application-layer data models | | network | + | generic | +-------------------------------+ | management| + | infra- | | transport-layer data models | | infra- | + | structure | +-------------------------------+ | structure | + | data | | network-layer data models | | data | + | models | +-------------------------------+ | models | + | | | link-layer data models | | | + +-----------+ +-------------------------------+ +-----------+ + + Figure 1: Categories of Network Management Data Models + + Each of the categories is briefly described below. Note that the + classification used here is intended to provide orientation and + reflects how most data models have been developed in the IETF by the + various working groups. This classification does not aim to classify + correctly all data models that have been defined by the IETF so far. + The network layering model in the middle of Figure 1 follows the + four-layer model of the Internet as defined in [RFC1021]. + + The network management object identifiers for use with IETF MIB + modules defined in the IETF can be found under the IANA registry at + [SMI-NUMBERS]. + +4.1.1. Generic Infrastructure Data Models + + Generic infrastructure data models provide core abstractions that + many other data models are built upon. The most important example is + the interfaces data model defined in the IF-MIB [RFC2863]. It + provides the basic notion of network interfaces and allows expressing + stacking/layering relationships between interfaces. The interfaces + data model also provides basic monitoring objects that are widely + used for performance and fault management. + + The second important infrastructure data model is defined in the + Entity MIB [RFC4133]. It exports the containment hierarchy of the + physical entities (slots, modules, ports) that make up a networking + device and, as such, it is a key data model for inventory management. + Physical entities can have pointers to other data models that provide + more specific information about them (e.g., physical ports usually + point to the related network interface). Entity MIB extensions exist + for physical sensors such as temperature sensors embedded on line + cards or sensors that report fan rotation speeds [RFC3433]. The + + + +Ersue & Claise Informational [Page 39] + +RFC 6632 IETF Management Standards June 2012 + + + Entity State MIB [RFC4268] models states and alarms of physical + entities. Some vendors have extended the basic Entity MIB with + several proprietary data models. + +4.1.2. Link-Layer Data Models + + A number of data models exist in the form of MIB modules covering the + link layers IP runs over, such as Asymmetric Bit-Rate DSL (ADSL) + [RFC4706], Very high bit-rate Digital Subscriber Line (VDSL) + [RFC5650], GMPLS [RFC4803], ISDN [RFC2127], ATM [RFC2515] [RFC3606], + Cable Modems [RFC4546], or Ethernet [RFC4188] [RFC4318] [RFC4363]. + These so-called transmission data models typically extend the generic + network interfaces data model with interface type specific + information. Most of the link-layer data models focus on monitoring + capabilities that can be used for performance and fault management + functions and, to some lesser extent, for accounting and security + management functions. Meanwhile, the IEEE has taken over the + responsibility to maintain and further develop data models for the + IEEE 802 family of protocols [RFC4663]. The cable modem industry + consortium DOCSIS is working with the IETF to publish data models for + cable modem networks as IETF Standards Track specifications. + +4.1.3. Network-Layer Data Models + + There are data models in the form of MIB modules covering IP/ICMP + [RFC4293] [RFC4292] network protocols and their extensions (e.g., + Mobile IP), the core protocols of the Internet. In addition, there + are data models covering popular unicast routing protocols (OSPF + [RFC4750], IS-IS [RFC4444], BGP-4 [RFC4273]) and multicast routing + protocols (PIM [RFC5060]). + + Detailed models also exist for performance measurements in the form + of IP Performance Metrics [RFC2330] (see Section 3.4). + + The necessary data model infrastructure for configuration data models + covering network layers are currently being defined using NETCONF + [RFC6242] and YANG [RFC6020]. + +4.1.4. Transport-Layer Data Models + + There are data models for the transport protocols TCP [RFC4022], UDP + [RFC4113], and SCTP [RFC3873]. For TCP, a data model providing + extended statistics is defined in [RFC4898]. + + + + + + + + +Ersue & Claise Informational [Page 40] + +RFC 6632 IETF Management Standards June 2012 + + +4.1.5. Application-Layer Data Models + + Some data models have been developed for specific application + protocols (e.g., SIP [RFC4780]). In addition, there are data models + that provide a generic infrastructure for instrumenting applications + in order to obtain data useful primarily for performance management + and fault management [RFC2287] [RFC2564]. In general, however, + generic application MIB modules have been less successful in gaining + widespread deployment. + +4.1.6. Network Management Infrastructure Data Models + + A number of data models are concerned with the network management + system itself. This includes, in addition to a set of SNMP MIB + modules for monitoring and configuring SNMP itself [RFC3410], some + MIB modules providing generic functions such as the calculation of + expressions over MIB objects, generic functions for thresholding and + event generation, event notification logging functions, and data + models to represent alarms [RFC2981] [RFC2982] [RFC3014] [RFC3877]. + + In addition, there are data models that allow the execution of basic + reachability and path discovery tests [RFC4560]. Another collection + of MIB modules provides remote monitoring functions, ranging from the + data link layer up to the application layer. This is known as the + "RMON family of MIB modules" [RFC3577]. + + The IPFIX Protocol [RFC5101] (Section 2.3) is used to export + information about network flows collected at so-called Observation + Points (typically, a network interface). The IEs [RFC5102] carried + in IPFIX cover the majority of the network and transport layer header + fields and a few link-layer-specific fields. Work is underway to + further extend the standardized information that can be carried in + IPFIX. + + The Syslog Protocol document [RFC5424] (Section 2.2) defines an + initial set of Structured Data Elements (SDEs) that relate to content + time quality, content origin, and meta-information about the message, + such as language. Proprietary SDEs can be used to supplement the + IETF-defined SDEs. + +4.2. Network Management Data Models - FCAPS View + + This subsection follows the management application view and aims to + match the data models to network management tasks for fault, + configuration, accounting, performance, and security management + ([FCAPS]). As OAM is a general term that refers to a toolset, which + can be used for fault detection, isolation, and performance + measurement, aspects of FCAPS in the context of the data path, such + + + +Ersue & Claise Informational [Page 41] + +RFC 6632 IETF Management Standards June 2012 + + + as fault and performance management, are also discussed in "An + Overview of Operations, Administration, and Maintenance (OAM) + Mechanisms" [OAM-OVERVIEW]. + + Some of the data models do not fit into one single FCAPS category per + design but span multiple areas. For example, there are many + technology-specific IETF data models, such as transmission and + protocol MIBs, which cover multiple FCAPS categories, and therefore + are not mentioned in this subsection and can be found at [RFCSEARCH]. + +4.2.1. Fault Management + + Fault management encloses a set of functions to detect, isolate, + notify, and correct faults encountered in a network as well as to + maintain and examine error logs. The data models below can be + utilized to realize a fault management application. + + [RFC3418], part of SNMPv3 standard [STD62], is a MIB module + containing objects in the system group that are often polled to + determine if a device is still operating, and sysUpTime can be used + to detect if the network management portion of the system has + restarted and counters have been re-initialized. + + [RFC3413], part of SNMPv3 standard [STD62], is a MIB module including + objects designed for managing notifications, including tables for + addressing, retry parameters, security, lists of targets for + notifications, and user customization filters. + + The Interfaces Group MIB [RFC2863] builds on the old standard for MIB + II [STD17] and is used as a primary MIB module for managing and + monitoring the status of network interfaces. The Interfaces Group + MIB defines a generic set of managed objects for network interfaces, + and it provides the infrastructure for additional managed objects + specific to particular types of network interfaces, such as Ethernet. + + [RFC4560] defines a MIB module for performing ping, traceroute, and + lookup operations at a host. For troubleshooting purposes, it is + useful to be able to initiate and retrieve the results of ping or + traceroute operations when they are performed at a remote host. + + The RMON (Remote Network Monitoring) MIB [STD59] can be configured to + recognize conditions on existing MIB variables (most notably error + conditions) and continuously check for them. When one of these + conditions occurs, the event may be logged, and management stations + may be notified in a number of ways (for further discussion on RMON, + see Section 4.2.4). + + + + + +Ersue & Claise Informational [Page 42] + +RFC 6632 IETF Management Standards June 2012 + + + DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] + provide a superset of the capabilities of the RMON alarm and event + groups. These modules provide mechanisms for thresholding and + reporting anomalous events to management applications. + + The Alarm MIB in [RFC3877] and the Alarm Reporting Control MIB in + [RFC3878] specify mechanisms for expressing state transition models + for persistent problem states. Alarm MIB defines the following: + + o a mechanism for expressing state transition models for persistent + problem states, + + o a mechanism to correlate a notification with subsequent state + transition notifications about the same entity/object, and + + o a generic alarm reporting mechanism (extends ITU-T work on X.733 + [ITU-X733]). + + In particular, [RFC3878] defines objects for controlling the + reporting of alarm conditions and extends ITU-T work on M.3100 + Amendment 3 [ITU-M3100]. + + Other MIB modules that may be applied to fault management with SNMP + include: + + o NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for + logging SNMP Notifications. + + o ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB + to provide information about the state of physical entities. + + o ENTITY-SENSOR-MIB [RFC3433] describes managed objects for + extending the Entity MIB to provide generalized access to + information related to physical sensors, which are often found in + networking equipment (such as chassis temperature, fan RPM, power + supply voltage). + + The Syslog protocol document [RFC5424] defines an initial set of SDEs + that relate to content time quality, content origin, and meta- + information about the message, such as language. Proprietary SDEs + can be used to supplement the IETF-defined SDEs. + + The IETF has standardized MIB Textual-Conventions for facility and + severity labels and codes to encourage consistency between syslog and + MIB representations of these event properties [RFC5427]. The intent + is that these textual conventions will be imported and used in MIB + modules that would otherwise define their own representations. + + + + +Ersue & Claise Informational [Page 43] + +RFC 6632 IETF Management Standards June 2012 + + + An IPFIX MIB module [RFC5815] has been defined for monitoring IPFIX + Meters, Exporters, and Collectors (see Section 2.3). The ongoing + work on the PSAMP MIB module extends the IPFIX MIB modules by managed + objects for monitoring PSAMP implementations [PSAMP-MIB]. + + The NETCONF working group defined the data model necessary to monitor + the NETCONF protocol [RFC6022] with the modeling language YANG. The + monitoring data model includes information about NETCONF datastores, + sessions, locks, and statistics, which facilitate the management of a + NETCONF server. The NETCONF monitoring document also defines methods + for NETCONF clients to discover the data models supported by a + NETCONF server and defines the operation <get-schema> to retrieve + them. + +4.2.2. Configuration Management + + Configuration management focuses on establishing and maintaining + consistency of a system and defines the functionality to configure + its functional and physical attributes as well as operational + information throughout its life. Configuration management includes + configuration of network devices, inventory management, and software + management. The data models below can be used to utilize + configuration management. + + MIB modules for monitoring of network configuration (e.g., for + physical and logical network topologies) already exist and provide + some of the desired capabilities. New MIB modules might be developed + for the target functionality to allow operators to monitor and modify + the operational parameters, such as timer granularity, event + reporting thresholds, target addresses, etc. + + [RFC3418], part of [STD62], contains objects in the system group + useful, e.g., for identifying the type of device and the location of + the device, the person responsible for the device. The SNMPv3 + standard [STD62] furthermore includes objects designed for + configuring principals, access control rules, notification + destinations, and for configuring proxy-forwarding SNMP agents, which + can be used to forward messages through firewalls and NAT devices. + + The Entity MIB [RFC4133] supports mainly inventory management and is + used for managing multiple logical and physical entities matched to a + single SNMP agent. This module provides a useful mechanism for + identifying the entities comprising a system and defines event + notifications for configuration changes that may be useful to + management applications. + + [RFC3165] defines a set of managed objects that enable the delegation + of management scripts to distributed managers. + + + +Ersue & Claise Informational [Page 44] + +RFC 6632 IETF Management Standards June 2012 + + + For configuring IPFIX and PSAMP devices, the IPFIX working group + developed the IPFIX Configuration Data Model [CONF-MODEL], by using + the YANG modeling language and in close collaboration with the NETMOD + working group (see Section 2.4.2). The model specifies the necessary + data for configuring and monitoring Selection Processes, caches, + Exporting Processes, and Collecting Processes of IPFIX- and PSAMP- + compliant monitoring devices. + + At the time of this writing, the NETMOD working group is developing + core system and interface models in YANG. + + The CAPWAP protocol exchanges message elements using the Type-Length- + Value (TLV) format. The base TLVs are specified in [RFC5415], while + the TLVs for IEEE 802.11 are specified in [RFC5416]. The CAPWAP Base + MIB [RFC5833] specifies managed objects for the modeling the CAPWAP + protocol and provides configuration and WTP status-monitoring aspects + of CAPWAP, where the CAPWAP Binding MIB [RFC5834] defines managed + objects for the modeling of the CAPWAP protocol for IEEE 802.11 + wireless binding. + Note: RFC 5833 and RFC 5834 have been published as Informational RFCs + to provide the basis for future work on a SNMP management of the + CAPWAP protocol. + +4.2.3. Accounting Management + + Accounting management collects usage information of network + resources. Note that the IETF does not define any mechanisms related + to billing and charging. Many technology-specific MIBs (link layer, + network layer, transport layer, or application layer) contain + counters but are not primarily targeted for accounting and, + therefore, are not included in this section. + + "RADIUS Accounting Client MIB for IPv6" [RFC4670] defines RADIUS + Accounting Client MIB objects that support version-neutral IP + addressing formats. + + "RADIUS Accounting Server MIB for IPv6" [RFC4671] defines RADIUS + Accounting Server MIB objects that support version-neutral IP + addressing formats. + + IPFIX/PSAMP Information Elements: + + As expressed in Section 2.3, the IPFIX Architecture [RFC5470] defines + components involved in IP flow measurement and reporting of + information on IP flows. As such, IPFIX records provide fine-grained + measurement data for flexible and detailed usage reporting and enable + usage-based accounting. + + + + +Ersue & Claise Informational [Page 45] + +RFC 6632 IETF Management Standards June 2012 + + + The IPFIX Information Elements (IEs) have been initially defined in + the IPFIX Information Model [RFC5102] and registered with IANA + [IANA-IPFIX]. The IPFIX IEs are composed of two types: + + o IEs related to identification of IP flows such as header + information, derived packet properties, IGP and BGP next-hop IP + address, BGP AS, etc., and + + o IEs related to counter and timestamps, such as per-flow counters + (e.g., octet count, packet count), flow start times, flow end + times, and flow duration, etc. + + The Information Elements specified in the IPFIX Information Model + [RFC5102] are used by the PSAMP protocol where applicable. PSAMP + Parameters defined in the PSAMP protocol specification are registered + at [IANA-PSAMP]. An additional set of PSAMP Information Elements for + reporting packet information with the IPFIX/PSAMP protocol such as + Sampling-related IEs are specified in the PSAMP Information Model + [RFC5477]. These IEs fulfill the requirements on reporting of + different sampling and filtering techniques specified in [RFC5475]. + +4.2.4. Performance Management + + Performance management covers a set of functions that evaluate and + report the performance of network elements and the network, with the + goal to maintain the overall network performance at a defined level. + Performance management functionality includes monitoring and + measurement of network performance parameters, gathering statistical + information, maintaining and examining activity logs. The data + models below can be used for performance management tasks. + + The RMON (Remote Network Monitoring) MIB [STD59] defines objects for + collecting data related to network performance and traffic from + remote monitoring devices. An organization may employ many remote + monitoring probes, one per network segment, to monitor its network. + These devices may be used by a network service provider to access a + (distant) client network. Most of the objects in the RMON MIB module + are suitable for the monitoring of any type of network, while some of + them are specific to the monitoring of Ethernet networks. + + RMON allows a probe to be configured to perform diagnostics and to + collect network statistics continuously, even when communication with + the management station may not be possible or efficient. The alarm + group periodically takes statistical samples from variables in the + probe and compares them to previously configured thresholds. If the + monitored variable crosses a threshold, an event is generated. + + + + + +Ersue & Claise Informational [Page 46] + +RFC 6632 IETF Management Standards June 2012 + + + "Introduction to the Remote Monitoring (RMON) Family of MIB Modules" + [RFC3577] describes the documents associated with the RMON Framework + and how they relate to each other. + + The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up + to the application layer and defines performance data to monitor. + The SMON MIB [RFC2613] extends RMON by providing RMON analysis for + switched networks. + + "Remote Monitoring MIB Extensions for High Capacity Alarms" [RFC3434] + describes managed objects for extending the alarm thresholding + capabilities found in the RMON MIB and provides similar threshold + monitoring of objects based on the Counter64 data type. + + "Remote Network Monitoring Management Information Base for High + Capacity Networks" [RFC3273] defines objects for managing RMON + devices for use on high-speed networks. + + "Remote Monitoring MIB Extensions for Interface Parameters + Monitoring" [RFC3144] describes an extension to the RMON MIB with a + method of sorting the interfaces of a monitored device according to + values of parameters specific to this interface. + + [RFC4710] describes Real-Time Application Quality of Service + Monitoring (RAQMON), which is part of the RMON protocol family. + RAQMON supports end-to-end QoS monitoring for multiple concurrent + applications and does not relate to a specific application transport. + RAQMON is scalable and works well with encrypted payload and + signaling. RAQMON uses TCP to transport RAQMON PDUs. + + [RFC4711] proposes an extension to the Remote Monitoring MIB [STD59] + and describes managed objects used for RAQMON. [RFC4712] specifies + two transport mappings for the RAQMON information model using TCP as + a native transport and SNMP to carry the RAQMON information from a + RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). + + "Application Performance Measurement MIB" [RFC3729] uses the + architecture created in the RMON MIB and defines objects by providing + measurement and analysis of the application performance as + experienced by end-users. [RFC3729] enables the measurement of the + quality of service delivered to end-users by applications. + + "Transport Performance Metrics MIB" [RFC4150] describes managed + objects used for monitoring selectable Performance Metrics and + statistics derived from the monitoring of network packets and sub- + application level transactions. The metrics can be defined through + reference to existing IETF, ITU, and other SDOs' documents. + + + + +Ersue & Claise Informational [Page 47] + +RFC 6632 IETF Management Standards June 2012 + + + The IPPM working group has defined "IP Performance Metrics (IPPM) + Metrics Registry" [RFC4148]. Note that with the publication of + [RFC6248], [RFC4148] and the corresponding IANA registry for IPPM + metrics have been declared Obsolete and shouldn't be used. + + The IPPM working group defined the "Information Model and XML Data + Model for Traceroute Measurements" [RFC5388], which defines a common + information model dividing the IEs into two semantically separated + groups (configuration elements and results elements) with an + additional element to relate configuration elements and results + elements by means of a common unique identifier. Based on the + information model, an XML data model is provided to store the results + of traceroute measurements. + + "Session Initiation Protocol Event Package for Voice Quality + Reporting" [RFC6035] defines a SIP event package that enables the + collection and reporting of metrics that measure the quality for + Voice over Internet Protocol (VoIP) sessions. + +4.2.5. Security Management + + Security management provides the set of functions to protect the + network and system from unauthorized access and includes functions + such as creating, deleting, and controlling security services and + mechanisms, key management, reporting security-relevant events, and + authorizing user access and privileges. Based on their support for + authentication and authorization, RADIUS and diameter are seen as + security management protocols. The data models below can be used to + utilize security management. + + [RFC3414], part of [STD62], specifies the procedures for providing + SNMPv3 message-level security and includes a MIB module for remotely + monitoring and managing the configuration parameters for the USM. + + [RFC3415], part of [STD62], describes the procedures for controlling + access to management information in the SNMPv3 architecture and + includes a MIB module, which defines managed objects to access + portions of an SNMP engine's Local Configuration Datastore (LCD). As + such, this MIB module enables remote management of the configuration + parameters of the VACM. + + The NETCONF Access Control Model (NACM) [RFC6536] addresses the need + for access control mechanisms for the operation and content layers of + NETCONF, as defined in [RFC6241]. As such, the NACM proposes + standard mechanisms to restrict NETCONF protocol access for + particular users to a pre-configured subset of all available NETCONF + protocol operations and content within a particular server. + + + + +Ersue & Claise Informational [Page 48] + +RFC 6632 IETF Management Standards June 2012 + + + There are numerous MIB modules defined for multiple purposes to use + with RADIUS: + + o "RADIUS Authentication Client MIB for IPv6" [RFC4668] defines + RADIUS Authentication Client MIB objects that support version- + neutral IP addressing formats and defines a set of extensions for + RADIUS authentication client functions. + + o "RADIUS Authentication Server MIB for IPv6" [RFC4669] defines + RADIUS Authentication Server MIB objects that support version- + neutral IP addressing formats and defines a set of extensions for + RADIUS authentication server functions. + + o "RADIUS Dynamic Authorization Client MIB" [RFC4672] defines the + MIB module for entities implementing the client side of the + Dynamic Authorization Extensions to RADIUS [RFC5176]. + + o "RADIUS Dynamic Authorization Server MIB" [RFC4673] defines the + MIB module for entities implementing the server side of the + Dynamic Authorization Extensions to RADIUS [RFC5176]. + + The MIB Module definitions in [RFC4668], [RFC4669], [RFC4672], + [RFC4673] are intended to be used only for RADIUS over UDP and do not + support RADIUS over TCP. There is also a recommendation that RADIUS + clients and servers implementing RADIUS over TCP should not reuse + earlier listed MIB modules to perform statistics counting for RADIUS- + over-TCP connections. + + Currently, there are no standardized MIB modules for diameter + applications, which can be considered as a lack on the management + side of diameter nodes. + +5. Security Considerations + + This document gives an overview of IETF network management standards + and summarizes existing and ongoing development of IETF Standards + Track network management protocols and data models. As such, it does + not have any security implications in or of itself. + + For each specific technology discussed in the document a summary of + its security usage has been given in corresponding chapters. In a + few cases, e.g., for SNMP, a detailed description of developed + security mechanisms has been provided. + + The attention of the reader is particularly drawn to the security + discussion in following document sections: + + o SNMP Security and Access Control Models in Section 2.1.4.1, + + + +Ersue & Claise Informational [Page 49] + +RFC 6632 IETF Management Standards June 2012 + + + o User-based Security Model (USM) in Section 2.1.4.2, + + o View-based Access Control Model (VACM) in Section 2.1.4.3, + + o SNMP Transport Security Model in Section 2.1.5.1, + + o Secure syslog message delivery in Section 2.2, + + o Use of secure NETCONF message transport and the NETCONF Access + Control Model (NACM) in Section 2.4.1, + + o Message authentication for Dynamic Host Configuration Protocol + (DHCP) in Section 3.1.1, + + o Security for Remote Authentication Dial-In User Service (RADIUS) + in conjunction with EAP and IEEE 802.1X authenticators in + Section 3.5, + + o Built-in and transport security for the Diameter Base Protocol in + Section 3.6, + + o Transport security for Control And Provisioning of Wireless Access + Points (CAPWAP) in Section 3.7, + + o Built-in security for Access Node Control Protocol (ANCP) in + Section 3.8, + + o Security for Application Configuration Access Protocol (ACAP) in + Section 3.9, + + o Security for XML Configuration Access Protocol (XCAP) in + Section 3.10, and + + o Data models for Security Management in Section 4.2.5. + + The authors would also like to refer to detailed security + consideration sections for specific management standards described in + this document, which contain comprehensive discussion of security + implications of the particular management protocols and mechanisms. + Among others, security consideration sections of following documents + should be carefully read before implementing the technology. + + o For SNMP security in general, subsequent security consideration + sections in [STD62], which includes RFCs 3411-3418, + + o Security considerations section in Section 8 of [BCP074] for the + coexistence of SNMP versions 1, 2, and 3, + + + + +Ersue & Claise Informational [Page 50] + +RFC 6632 IETF Management Standards June 2012 + + + o Security considerations for the SNMP Transport Security Model in + Section 8 of [RFC5591], + + o Security considerations for the Secure Shell Transport Model for + SNMP in Section 9 of [RFC5592], + + o Security considerations for the TLS Transport Model for SNMP in + Section 9 of [RFC6353], + + o Security considerations for the TLS Transport Mapping for syslog + in Section 6 of [RFC5425], + + o Security considerations for the IPFIX Protocol Specification in + Section 11 of [RFC5101], + + o Security considerations for the NETCONF protocol in Section 9 of + [RFC6241] and the SSH transport in Section 6 of [RFC6242], + + o Security considerations for the NETCONF Access Control Model + (NACM) in Section 3.7 of [RFC6536], + + o Security considerations for DHCPv4 and DHCPv6 in Section 7 of + [RFC2131] and Section 23. of [RFC3315], + + o Security considerations for RADIUS in Section 8 of [RFC2865], + + o Security considerations for diameter in Section 13 of [RFC3588], + + o Security considerations for the CAPWAP protocol in Section 12 of + [RFC5415], + + o Security considerations for the ANCP protocol in Section 11 of + [RFC6320], and + + o Security considerations for the XCAP protocol in Section 14 of + [RFC4825]. + +6. Contributors + + Following persons made significant contributions to and reviewed this + document: + + o Ralph Droms (Cisco) - revised the section on IP Address Management + and DHCP. + + o Jouni Korhonen (Nokia Siemens Networks) - contributed the sections + on RADIUS and diameter. + + + + +Ersue & Claise Informational [Page 51] + +RFC 6632 IETF Management Standards June 2012 + + + o Al Morton (AT&T) - contributed to the section on IP Performance + Metrics. + + o Juergen Quittek (NEC) - contributed the section on IPFIX/PSAMP. + + o Juergen Schoenwaelder (Jacobs University Bremen) - contributed the + sections on IETF Network Management Data Models and YANG. + +7. Acknowledgements + + The editor would like to thank Fred Baker, Alex Clemm, Miguel A. + Garcia, Simon Leinen, Christopher Liljenstolpe, Tom Petch, Randy + Presuhn, Dan Romascanu, Juergen Schoenwaelder, Tina Tsou, and Henk + Uijterwaal for their valuable suggestions and comments in the OPSAWG + sessions and on the mailing list. + + The editor would like to especially thank Dave Harrington, who + created the document "Survey of IETF Network Management Standards" a + few years ago, which has been used as a starting point and enhanced + with a special focus on the description of the IETF network + management standards and management data models. + +8. Informative References + + [3GPPEPC] 3GPP, "Access to the 3GPP Evolved Packet Core (EPC) + via non-3GPP access networks", December 2010, + <http://www.3gpp.org/ftp/Specs/html-info/24302.htm>. + + [3GPPIMS] 3GPP, "Release 10, IP Multimedia Subsystem (IMS); + Stage 2", September 2010, + <http://www.3gpp.org/ftp/Specs/html-info/23228.htm>. + + [BCP027] O'Dell, M., Alvestrand, H., Wijnen, B., and S. + Bradner, "Advancement of MIB specifications on the + IETF Standards Track", BCP 27, RFC 2438, + October 1998. + + [BCP074] Frye, R., Levi, D., Routhier, S., and B. Wijnen, + "Coexistence between Version 1, Version 2, and + Version 3 of the Internet-standard Network Management + Framework", BCP 74, RFC 3584, August 2003. + + [BCP170] Clark, A. and B. Claise, "Guidelines for Considering + New Performance Metric Development", BCP 170, + RFC 6390, October 2011. + + + + + + +Ersue & Claise Informational [Page 52] + +RFC 6632 IETF Management Standards June 2012 + + + [CONF-MODEL] Muenz, G., Claise, B., and P. Aitken, "Configuration + Data Model for IPFIX and PSAMP", Work in Progress, + July 2011. + + [DIAMETER] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, + "Diameter Base Protocol", Work in Progress, + April 2012. + + [DMTF-CIM] DMTF, "Common Information Model Schema, Version + 2.27.0", November 2010, + <http://www.dmtf.org/standards/cim>. + + [EMAN-WG] IETF, "EMAN Working Group", + <http://datatracker.ietf.org/wg/eman>. + + [FCAPS] International Telecommunication Union, "X.700: + Management Framework For Open Systems Interconnection + (OSI) For CCITT Applications", September 1992, + <http://www.itu.int/rec/T-REC-X.700-199209-I/en>. + + [IANA-AAA] Internet Assigned Numbers Authority, "Authentication, + Authorization, and Accounting (AAA) Parameters", + February 2012, + <http://www.iana.org/assignments/aaa-parameters>. + + [IANA-IPFIX] Internet Assigned Numbers Authority, "IP Flow + Information Export (IPFIX) Entities", May 2012, + <http://www.iana.org/assignments/ipfix>. + + [IANA-PROT] Internet Assigned Numbers Authority, "Protocol + Registries", <http://www.iana.org/protocols/>. + + [IANA-PSAMP] Internet Assigned Numbers Authority, "Packet Sampling + (PSAMP) Parameters", April 2009, + <http://www.iana.org/assignments/psamp-parameters>. + + [IETF-WGS] IETF, "IETF Working Groups", + <http://datatracker.ietf.org/wg/>. + + [ITU-M3100] International Telecommunication Union, "M.3100: + Generic network information model", January 2006, + <http://www.itu.int/rec/T-REC-M.3100-200504-I>. + + [ITU-X680] International Telecommunication Union, "X.680: + Abstract Syntax Notation One (ASN.1): Specification + of basic notation", July 2002, <http://www.itu.int/ + ITU-T/studygroups/com17/languages/X.680-0207.pdf>. + + + + +Ersue & Claise Informational [Page 53] + +RFC 6632 IETF Management Standards June 2012 + + + [ITU-X733] International Telecommunication Union, "X.733: + Systems Management: Alarm Reporting Function", + October 1992, + <http://www.itu.int/rec/T-REC-X.733-199202-I/en>. + + [MPLSTP-MIB] King, D. and V. Mahalingam, "Multiprotocol Label + Switching Transport Profile (MPLS-TP) MIB-based + Management Overview", Work in Progress, April 2012. + + [OAM-ANALYSIS] Sprecher, N. and L. Fang, "An Overview of the OAM + Tool Set for MPLS based Transport Networks", Work + in Progress, April 2012. + + [OAM-OVERVIEW] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. + Weingarten, "An Overview of Operations, + Administration, and Maintenance (OAM) Mechanisms", + Work in Progress, March 2012. + + [PSAMP-MIB] Dietz, T., Claise, B., and J. Quittek, "Definitions + of Managed Objects for Packet Sampling", Work + in Progress, October 2011. + + [RELAX-NG] OASIS, "RELAX NG Specification, Committee + Specification 3 December 2001", December 2001, <http: + //www.oasis-open.org/committees/relax-ng/ + spec-20011203.html>. + + [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", + RFC 951, September 1985. + + [RFC1021] Partridge, C. and G. Trewitt, "High-level Entity + Management System (HEMS)", RFC 1021, October 1987. + + [RFC1155] Rose, M. and K. McCloghrie, "Structure and + identification of management information for TCP/ + IP-based internets", STD 16, RFC 1155, May 1990. + + [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, + "Simple Network Management Protocol (SNMP)", STD 15, + RFC 1157, May 1990. + + [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB + definitions", STD 16, RFC 1212, March 1991. + + [RFC1215] Rose, M., "Convention for defining traps for use with + the SNMP", RFC 1215, March 1991. + + + + + +Ersue & Claise Informational [Page 54] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", + RFC 1321, April 1992. + + [RFC1470] Enger, R. and J. Reynolds, "FYI on a Network + Management Tool Catalog: Tools for Monitoring and + Debugging TCP/IP Internets and Interconnected + Devices", RFC 1470, June 1993. + + [RFC1901] Case, J., McCloghrie, K., McCloghrie, K., Rose, M., + and S. Waldbusser, "Introduction to Community-based + SNMPv2", RFC 1901, January 1996. + + [RFC2026] Bradner, S., "The Internet Standards Process -- + Revision 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2127] Roeck, G., "ISDN Management Information Base using + SMIv2", RFC 2127, March 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2195] Klensin, J., Catoe, R., and P. Krumviede, "IMAP/POP + AUTHorize Extension for Simple Challenge/Response", + RFC 2195, September 1997. + + [RFC2244] Newman, C. and J. Myers, "ACAP -- Application + Configuration Access Protocol", RFC 2244, + November 1997. + + [RFC2287] Krupczak, C. and J. Saperia, "Definitions of System- + Level Managed Objects for Applications", RFC 2287, + February 1998. + + [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, + "Framework for IP Performance Metrics", RFC 2330, + May 1998. + + [RFC2458] Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., + Burg, F., DeSimone, A., Tewani, K., Davidson, P., + Schulzrinne, H., and K. Vishwanathan, "Toward the + PSTN/Internet Inter-Networking --Pre-PINT + Implementations", RFC 2458, November 1998. + + [RFC2515] Tesink, K., "Definitions of Managed Objects for ATM + Management", RFC 2515, February 1999. + + + +Ersue & Claise Informational [Page 55] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC2564] Kalbfleisch, C., Krupczak, C., Presuhn, R., and J. + Saperia, "Application Management MIB", RFC 2564, + May 1999. + + [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, + April 1999. + + [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, + "Conformance Statements for SMIv2", STD 58, RFC 2580, + April 1999. + + [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service + Location Protocol", RFC 2610, June 1999. + + [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. + Waldbusser, "Remote Network Monitoring MIB Extensions + for Switched Networks Version 1.0", RFC 2613, + June 1999. + + [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., + Lawrence, S., Leach, P., Luotonen, A., and L. + Stewart, "HTTP Authentication: Basic and Digest + Access Authentication", RFC 2617, June 1999. + + [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for + Measuring Connectivity", RFC 2678, September 1999. + + [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One- + way Delay Metric for IPPM", RFC 2679, September 1999. + + [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One- + way Packet Loss Metric for IPPM", RFC 2680, + September 1999. + + [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round- + trip Delay Metric for IPPM", RFC 2681, + September 1999. + + [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, + R., and A. Sastry, "The COPS (Common Open Policy + Service) Protocol", RFC 2748, January 2000. + + + + +Ersue & Claise Informational [Page 56] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A + Framework for Policy-based Admission Control", + RFC 2753, January 2000. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces + Group MIB", RFC 2863, June 2000. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service + (RADIUS)", RFC 2865, June 2000. + + [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS + Accounting Modifications for Tunnel Protocol + Support", RFC 2867, June 2000. + + [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., + Holdrege, M., and I. Goyret, "RADIUS Attributes for + Tunnel Protocol Support", RFC 2868, June 2000. + + [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS + Extensions", RFC 2869, June 2000. + + [RFC2981] Kavasseri, R., "Event MIB", RFC 2981, October 2000. + + [RFC2982] Kavasseri, R., "Distributed Management Expression + MIB", RFC 2982, October 2000. + + [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, + November 2000. + + [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", + RFC 3046, January 2001. + + [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., + McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, + R., and A. Smith, "COPS Usage for Policy Provisioning + (COPS-PR)", RFC 3084, March 2001. + + [RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for + Interface Parameters Monitoring", RFC 3144, + August 2001. + + + + + + +Ersue & Claise Informational [Page 57] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., + Hahn, S., Sahita, R., Smith, A., and F. Reichmeyer, + "Structure of Policy Provisioning Information + (SPPI)", RFC 3159, August 2001. + + [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and + IPv6", RFC 3162, August 2001. + + [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, + August 2001. + + [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of + Managed Objects for the Delegation of Management + Scripts", RFC 3165, August 2001. + + [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", + RFC 3195, November 2001. + + [RFC3273] Waldbusser, S., "Remote Network Monitoring Management + Information Base for High Capacity Networks", + RFC 3273, July 2002. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host + Configuration Protocol (DHCPv6) Options for Session + Initiation Protocol (SIP) Servers", RFC 3319, + July 2003. + + [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay + Variation Metric for IP Performance Metrics (IPPM)", + RFC 3393, November 2002. + + [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, + "Introduction and Applicability Statements for + Internet-Standard Management Framework", RFC 3410, + December 2002. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, + RFC 3411, December 2002. + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, + RFC 3413, December 2002. + + + +Ersue & Claise Informational [Page 58] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security + Model (USM) for version 3 of the Simple Network + Management Protocol (SNMPv3)", STD 62, RFC 3414, + December 2002. + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View- + based Access Control Model (VACM) for the Simple + Network Management Protocol (SNMP)", STD 62, + RFC 3415, December 2002. + + [RFC3417] Presuhn, R., "Transport Mappings for the Simple + Network Management Protocol (SNMP)", STD 62, + RFC 3417, December 2002. + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for + the Simple Network Management Protocol (SNMP)", + STD 62, RFC 3418, December 2002. + + [RFC3430] Schoenwaelder, J., "Simple Network Management + Protocol Over Transmission Control Protocol Transport + Mapping", RFC 3430, December 2002. + + [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network + performance measurement with periodic streams", + RFC 3432, November 2002. + + [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity + Sensor Management Information Base", RFC 3433, + December 2002. + + [RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB + Extensions for High Capacity Alarms", RFC 3434, + December 2002. + + [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference + between Information Models and Data Models", + RFC 3444, January 2003. + + [RFC3460] Moore, B., "Policy Core Information Model (PCIM) + Extensions", RFC 3460, January 2003. + + [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network + Management Workshop", RFC 3535, May 2003. + + [RFC3574] Soininen, J., "Transition Scenarios for 3GPP + Networks", RFC 3574, August 2003. + + + + + +Ersue & Claise Informational [Page 59] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC3577] Waldbusser, S., Cole, R., Kalbfleisch, C., and D. + Romascanu, "Introduction to the Remote Monitoring + (RMON) Family of MIB Modules", RFC 3577, August 2003. + + [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote + Authentication Dial In User Service) Support For + Extensible Authentication Protocol (EAP)", RFC 3579, + September 2003. + + [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. + Roese, "IEEE 802.1X Remote Authentication Dial In + User Service (RADIUS) Usage Guidelines", RFC 3580, + September 2003. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and + J. Arkko, "Diameter Base Protocol", RFC 3588, + September 2003. + + [RFC3589] Loughney, J., "Diameter Command Codes for Third + Generation Partnership Project (3GPP) Release 5", + RFC 3589, September 2003. + + [RFC3606] Ly, F., Noto, M., Smith, A., Spiegel, E., and K. + Tesink, "Definitions of Supplemental Managed Objects + for ATM Interface", RFC 3606, November 2003. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for + Dynamic Host Configuration Protocol (DHCP) version + 6", RFC 3633, December 2003. + + [RFC3646] Droms, R., "DNS Configuration options for Dynamic + Host Configuration Protocol for IPv6 (DHCPv6)", + RFC 3646, December 2003. + + [RFC3729] Waldbusser, S., "Application Performance Measurement + MIB", RFC 3729, March 2004. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., + and H. Levkowetz, "Extensible Authentication Protocol + (EAP)", RFC 3748, June 2004. + + [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. + Conrad, "Stream Control Transmission Protocol (SCTP) + Partial Reliability Extension", RFC 3758, May 2004. + + + + + + + +Ersue & Claise Informational [Page 60] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC3868] Loughney, J., Sidebottom, G., Coene, L., Verwimp, G., + Keller, J., and B. Bidulock, "Signalling Connection + Control Part User Adaptation Layer (SUA)", RFC 3868, + October 2004. + + [RFC3873] Pastor, J. and M. Belinchon, "Stream Control + Transmission Protocol (SCTP) Management Information + Base (MIB)", RFC 3873, September 2004. + + [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management + Information Base (MIB)", RFC 3877, September 2004. + + [RFC3878] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting + Control Management Information Base (MIB)", RFC 3878, + September 2004. + + [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, + "Requirements for IP Flow Information Export + (IPFIX)", RFC 3917, October 2004. + + [RFC3954] Claise, B., "Cisco Systems NetFlow Services Export + Version 9", RFC 3954, October 2004. + + [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., + and P. McCann, "Diameter Mobile IPv4 Application", + RFC 4004, August 2005. + + [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, + "Diameter Network Access Server Application", + RFC 4005, August 2005. + + [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., + and J. Loughney, "Diameter Credit-Control + Application", RFC 4006, August 2005. + + [RFC4022] Raghunarayan, R., "Management Information Base for + the Transmission Control Protocol (TCP)", RFC 4022, + March 2005. + + [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. + Savola, "Scenarios and Analysis for Introducing IPv6 + into ISP Networks", RFC 4029, March 2005. + + [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and + E. Castro, "Application Aspects of IPv6 Transition", + RFC 4038, March 2005. + + + + + +Ersue & Claise Informational [Page 61] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", + RFC 4057, June 2005. + + [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter + Extensible Authentication Protocol (EAP) + Application", RFC 4072, August 2005. + + [RFC4113] Fenner, B. and J. Flick, "Management Information Base + for the User Datagram Protocol (UDP)", RFC 4113, + June 2005. + + [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture + Taxonomy for Control and Provisioning of Wireless + Access Points (CAPWAP)", RFC 4118, June 2005. + + [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version + 3)", RFC 4133, August 2005. + + [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics + Registry", BCP 108, RFC 4148, August 2005. + + [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics + MIB", RFC 4150, August 2005. + + [RFC4188] Norseth, K. and E. Bell, "Definitions of Managed + Objects for Bridges", RFC 4188, September 2005. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third + Generation Partnership Project (3GPP) Networks", + RFC 4215, October 2005. + + [RFC4221] Nadeau, T., Srinivasan, C., and A. Farrel, + "Multiprotocol Label Switching (MPLS) Management + Overview", RFC 4221, November 2005. + + [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", + RFC 4268, November 2005. + + [RFC4273] Haas, J. and S. Hares, "Definitions of Managed + Objects for BGP-4", RFC 4273, January 2006. + + + + + + + +Ersue & Claise Informational [Page 62] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic + Host Configuration Protocol (DHCP) Options for + Broadcast and Multicast Control Servers", RFC 4280, + November 2005. + + [RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. + Chowdhury, "Authentication Protocol for Mobile IPv6", + RFC 4285, January 2006. + + [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, + April 2006. + + [RFC4293] Routhier, S., "Management Information Base for the + Internet Protocol (IP)", RFC 4293, April 2006. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4318] Levi, D. and D. Harrington, "Definitions of Managed + Objects for Bridges with Rapid Spanning Tree + Protocol", RFC 4318, December 2005. + + [RFC4363] Levi, D. and D. Harrington, "Definitions of Managed + Objects for Bridges with Traffic Classes, Multicast + Filtering, and Virtual LAN Extensions", RFC 4363, + January 2006. + + [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication + and Security Layer (SASL)", RFC 4422, June 2006. + + [RFC4444] Parker, J., "Management Information Base for + Intermediate System to Intermediate System (IS-IS)", + RFC 4444, April 2006. + + [RFC4502] Waldbusser, S., "Remote Network Monitoring Management + Information Base Version 2", RFC 4502, May 2006. + + [RFC4546] Raftus, D. and E. Cardona, "Radio Frequency (RF) + Interface Management Information Base for Data over + Cable Service Interface Specifications (DOCSIS) 2.0 + Compliant RF Interfaces", RFC 4546, June 2006. + + [RFC4560] Quittek, J. and K. White, "Definitions of Managed + Objects for Remote Ping, Traceroute, and Lookup + Operations", RFC 4560, June 2006. + + + + + + +Ersue & Claise Informational [Page 63] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. + Yang, "Objectives for Control and Provisioning of + Wireless Access Points (CAPWAP)", RFC 4564, + July 2006. + + [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., + and M. Zekauskas, "A One-way Active Measurement + Protocol (OWAMP)", RFC 4656, September 2006. + + [RFC4663] Harrington, D., "Transferring MIB Work from IETF + Bridge MIB WG to IEEE 802.1 WG", RFC 4663, + September 2006. + + [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for + IPv6", RFC 4668, August 2006. + + [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for + IPv6", RFC 4669, August 2006. + + [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", + RFC 4670, August 2006. + + [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", + RFC 4671, August 2006. + + [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS + Dynamic Authorization Client MIB", RFC 4672, + September 2006. + + [RFC4673] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS + Dynamic Authorization Server MIB", RFC 4673, + September 2006. + + [RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS + Attributes for Virtual LAN and Priority Support", + RFC 4675, September 2006. + + [RFC4706] Morgenstern, M., Dodge, M., Baillie, S., and U. + Bonollo, "Definitions of Managed Objects for + Asymmetric Digital Subscriber Line 2 (ADSL2)", + RFC 4706, November 2006. + + [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, + "Real-time Application Quality-of-Service Monitoring + (RAQMON) Framework", RFC 4710, October 2006. + + + + + + +Ersue & Claise Informational [Page 64] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, + "Real-time Application Quality-of-Service Monitoring + (RAQMON) MIB", RFC 4711, October 2006. + + [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, + M., and Y. Kim, "Transport Mappings for Real-time + Application Quality-of-Service Monitoring (RAQMON) + Protocol Data Unit (PDU)", RFC 4712, October 2006. + + [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., + Shalunov, S., and J. Perser, "Packet Reordering + Metrics", RFC 4737, November 2006. + + [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., + Canales-Valenzuela, C., and K. Tammi, "Diameter + Session Initiation Protocol (SIP) Application", + RFC 4740, November 2006. + + [RFC4743] Goddard, T., "Using NETCONF over the Simple Object + Access Protocol (SOAP)", RFC 4743, December 2006. + + [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol + over the Blocks Extensible Exchange Protocol (BEEP)", + RFC 4744, December 2006. + + [RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., + and F. Baker, "OSPF Version 2 Management Information + Base", RFC 4750, December 2006. + + [RFC4780] Lingle, K., Mule, J-F., Maeng, J., and D. Walker, + "Management Information Base for the Session + Initiation Protocol (SIP)", RFC 4780, April 2007. + + [RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network + Management Protocol (SNMP) over IEEE 802 Networks", + RFC 4789, November 2006. + + [RFC4803] Nadeau, T. and A. Farrel, "Generalized Multiprotocol + Label Switching (GMPLS) Label Switching Router (LSR) + Management Information Base", RFC 4803, + February 2007. + + [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6- + Prefix Attribute", RFC 4818, April 2007. + + [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) + Configuration Access Protocol (XCAP)", RFC 4825, + May 2007. + + + +Ersue & Claise Informational [Page 65] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) + Formats for Representing Resource Lists", RFC 4826, + May 2007. + + [RFC4827] Isomaki, M. and E. Leppanen, "An Extensible Markup + Language (XML) Configuration Access Protocol (XCAP) + Usage for Manipulating Presence Document Contents", + RFC 4827, May 2007. + + [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP + Extended Statistics MIB", RFC 4898, May 2007. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + [RFC5060] Sivaramu, R., Lingard, J., McWalter, D., Joshi, B., + and A. Kessler, "Protocol Independent Multicast MIB", + RFC 5060, January 2008. + + [RFC5080] Nelson, D. and A. DeKok, "Common Remote + Authentication Dial In User Service (RADIUS) + Implementation Issues and Suggested Fixes", RFC 5080, + December 2007. + + [RFC5085] Nadeau, T. and C. Pignataro, "Pseudowire Virtual + Circuit Connectivity Verification (VCCV): A Control + Channel for Pseudowires", RFC 5085, December 2007. + + [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, + D., and W. Beck, "RADIUS Extension for Digest + Authentication", RFC 5090, February 2008. + + [RFC5101] Claise, B., "Specification of the IP Flow Information + Export (IPFIX) Protocol for the Exchange of IP + Traffic Flow Information", RFC 5101, January 2008. + + [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and + J. Meyer, "Information Model for IP Flow Information + Export", RFC 5102, January 2008. + + [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow + Export Using IP Flow Information Export (IPFIX)", + RFC 5103, January 2008. + + [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and + B. Aboba, "Dynamic Authorization Extensions to Remote + Authentication Dial In User Service (RADIUS)", + RFC 5176, January 2008. + + + +Ersue & Claise Informational [Page 66] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, + "IPv6 Deployment Scenarios in 802.16 Networks", + RFC 5181, May 2008. + + [RFC5224] Brenner, M., "Diameter Policy Processing + Application", RFC 5224, March 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event + Notifications", RFC 5277, July 2008. + + [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and + J. Babiarz, "A Two-Way Active Measurement Protocol + (TWAMP)", RFC 5357, October 2008. + + [RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, + T., and M. Swany, "Information Model and XML Data + Model for Traceroute Measurements", RFC 5388, + December 2008. + + [RFC5415] Calhoun, P., Montemurro, M., and D. Stanley, "Control + And Provisioning of Wireless Access Points (CAPWAP) + Protocol Specification", RFC 5415, March 2009. + + [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control + and Provisioning of Wireless Access Points (CAPWAP) + Protocol Binding for IEEE 802.11", RFC 5416, + March 2009. + + [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, + March 2009. + + [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer + Security (TLS) Transport Mapping for Syslog", + RFC 5425, March 2009. + + [RFC5426] Okmianski, A., "Transmission of Syslog Messages over + UDP", RFC 5426, March 2009. + + [RFC5427] Keeni, G., "Textual Conventions for Syslog + Management", RFC 5427, March 2009. + + [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement + Interface Application", RFC 5431, March 2009. + + + + +Ersue & Claise Informational [Page 67] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, + C., and K. Chowdhury, "Diameter Mobile IPv6: Support + for Network Access Server to Diameter Server + Interaction", RFC 5447, February 2009. + + [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. + Quittek, "Architecture for IP Flow Information + Export", RFC 5470, March 2009. + + [RFC5472] Zseby, T., Boschi, E., Brownlee, N., and B. Claise, + "IP Flow Information Export (IPFIX) Applicability", + RFC 5472, March 2009. + + [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing + Redundancy in IP Flow Information Export (IPFIX) and + Packet Sampling (PSAMP) Reports", RFC 5473, + March 2009. + + [RFC5474] Duffield, N., Chiou, D., Claise, B., Greenberg, A., + Grossglauser, M., and J. Rexford, "A Framework for + Packet Selection and Reporting", RFC 5474, + March 2009. + + [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., + and F. Raspall, "Sampling and Filtering Techniques + for IP Packet Selection", RFC 5475, March 2009. + + [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet + Sampling (PSAMP) Protocol Specifications", RFC 5476, + March 2009. + + [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and + G. Carle, "Information Model for Packet Sampling + Exports", RFC 5477, March 2009. + + [RFC5516] Jones, M. and L. Morand, "Diameter Command Code + Registration for the Third Generation Partnership + Project (3GPP) Evolved Packet System (EPS)", + RFC 5516, April 2009. + + [RFC5539] Badra, M., "NETCONF over Transport Layer Security + (TLS)", RFC 5539, May 2009. + + [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication + Metric", RFC 5560, May 2009. + + + + + + +Ersue & Claise Informational [Page 68] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and + B. Aboba, "Carrying Location Objects in RADIUS and + Diameter", RFC 5580, August 2009. + + [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport + Subsystem for the Simple Network Management Protocol + (SNMP)", RFC 5590, June 2009. + + [RFC5591] Harrington, D. and W. Hardaker, "Transport Security + Model for the Simple Network Management Protocol + (SNMP)", RFC 5591, June 2009. + + [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure + Shell Transport Model for the Simple Network + Management Protocol (SNMP)", RFC 5592, June 2009. + + [RFC5607] Nelson, D. and G. Weber, "Remote Authentication + Dial-In User Service (RADIUS) Authorization for + Network Access Server (NAS) Management", RFC 5607, + July 2009. + + [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication + Dial-In User Service (RADIUS) Usage for Simple + Network Management Protocol (SNMP) Transport Models", + RFC 5608, August 2009. + + [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, + "Exporting Type Information for IP Flow Information + Export (IPFIX) Information Elements", RFC 5610, + July 2009. + + [RFC5650] Morgenstern, M., Baillie, S., and U. Bonollo, + "Definitions of Managed Objects for Very High Speed + Digital Subscriber Line 2 (VDSL2)", RFC 5650, + September 2009. + + [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. + Wagner, "Specification of the IP Flow Information + Export (IPFIX) File Format", RFC 5655, October 2009. + + [RFC5674] Chisholm, S. and R. Gerhards, "Alarms in Syslog", + RFC 5674, October 2009. + + [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple + Network Management Protocol (SNMP) Notifications to + SYSLOG Messages", RFC 5675, October 2009. + + + + + +Ersue & Claise Informational [Page 69] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, + "Definitions of Managed Objects for Mapping SYSLOG + Messages to Simple Network Management Protocol (SNMP) + Notifications", RFC 5676, October 2009. + + [RFC5706] Harrington, D., "Guidelines for Considering + Operations and Management of New Protocols and + Protocol Extensions", RFC 5706, November 2009. + + [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, + "Security Threats and Security Requirements for the + Access Node Control Protocol (ANCP)", RFC 5713, + January 2010. + + [RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote + Procedure Call (RPC) for NETCONF", RFC 5717, + December 2009. + + [RFC5719] Romascanu, D. and H. Tschofenig, "Updated IANA + Considerations for Diameter Command Code + Allocations", RFC 5719, January 2010. + + [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, + "Clarifications on the Routing of Diameter Requests + Based on the Username and the Realm", RFC 5729, + December 2009. + + [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., + Jones, M., and A. Lior, "Traffic Classification and + Quality of Service (QoS) Attributes for Diameter", + RFC 5777, February 2010. + + [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., + Giaretta, G., and M. Nakhjiri, "Diameter Mobile IPv6: + Support for Home Agent to Diameter Server + Interaction", RFC 5778, February 2010. + + [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, + A., and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile + Access Gateway and Local Mobility Anchor Interaction + with Diameter Server", RFC 5779, February 2010. + + [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, + "Definitions of Managed Objects for IP Flow + Information Export", RFC 5815, April 2010. + + + + + + +Ersue & Claise Informational [Page 70] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC5833] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, + "Control and Provisioning of Wireless Access Points + (CAPWAP) Protocol Base MIB", RFC 5833, May 2010. + + [RFC5834] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, + "Control and Provisioning of Wireless Access Points + (CAPWAP) Protocol Binding MIB for IEEE 802.11", + RFC 5834, May 2010. + + [RFC5835] Morton, A. and S. Van den Berghe, "Framework for + Metric Composition", RFC 5835, April 2010. + + [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog + Messages", RFC 5848, May 2010. + + [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. + Wadhwa, "Framework and Requirements for an Access + Node Control Mechanism in Broadband Multi-Service + Networks", RFC 5851, May 2010. + + [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, + A., and G. Zorn, "Diameter Quality-of-Service + Application", RFC 5866, May 2010. + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding + Detection (BFD)", RFC 5880, June 2010. + + [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in + Ad Hoc Networks", RFC 5889, September 2010. + + [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information + Export (IPFIX) Mediation: Problem Statement", + RFC 5982, August 2010. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 5996, September 2010. + + [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, + "Datagram Transport Layer Security (DTLS) Transport + Mapping for Syslog", RFC 6012, October 2010. + + [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for + the Network Configuration Protocol (NETCONF)", + RFC 6020, October 2010. + + [RFC6021] Schoenwaelder, J., "Common YANG Data Types", + RFC 6021, October 2010. + + + +Ersue & Claise Informational [Page 71] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF + Monitoring", RFC 6022, October 2010. + + [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. + Sinnreich, "Session Initiation Protocol Event Package + for Voice Quality Reporting", RFC 6035, + November 2010. + + [RFC6065] Narayan, K., Nelson, D., and R. Presuhn, "Using + Authentication, Authorization, and Accounting + Services to Dynamically Provision View-Based Access + Control Model User-to-Group Mappings", RFC 6065, + December 2010. + + [RFC6087] Bierman, A., "Guidelines for Authors and Reviewers of + YANG Data Model Documents", RFC 6087, January 2011. + + [RFC6095] Linowski, B., Ersue, M., and S. Kuryla, "Extending + YANG with Language Abstractions", RFC 6095, + March 2011. + + [RFC6110] Lhotka, L., "Mapping YANG to Document Schema + Definition Languages and Validating NETCONF Content", + RFC 6110, February 2011. + + [RFC6158] DeKok, A. and G. Weber, "RADIUS Design Guidelines", + BCP 158, RFC 6158, March 2011. + + [RFC6183] Kobayashi, A., Claise, B., Muenz, G., and K. + Ishibashi, "IP Flow Information Export (IPFIX) + Mediation: Framework", RFC 6183, April 2011. + + [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization + Support", RFC 6235, May 2011. + + [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. + Bierman, "Network Configuration Protocol (NETCONF)", + RFC 6241, June 2011. + + [RFC6242] Wasserman, M., "Using the NETCONF Protocol over + Secure Shell (SSH)", RFC 6242, June 2011. + + [RFC6244] Shafer, P., "An Architecture for Network Management + Using NETCONF and YANG", RFC 6244, June 2011. + + [RFC6248] Morton, A., "RFC 4148 and the IP Performance Metrics + (IPPM) Registry of Metrics Are Obsolete", RFC 6248, + April 2011. + + + +Ersue & Claise Informational [Page 72] + +RFC 6632 IETF Management Standards June 2012 + + + [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the + Smart Grid", RFC 6272, June 2011. + + [RFC6313] Claise, B., Dhandapani, G., Aitken, P., and S. Yates, + "Export of Structured Data in IP Flow Information + Export (IPFIX)", RFC 6313, July 2011. + + [RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. + Taylor, "Protocol for Access Node Control Mechanism + in Broadband Networks", RFC 6320, October 2011. + + [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security Version 1.2", RFC 6347, January 2012. + + [RFC6353] Hardaker, W., "Transport Layer Security (TLS) + Transport Model for the Simple Network Management + Protocol (SNMP)", RFC 6353, July 2011. + + [RFC6371] Busi, I. and D. Allan, "Operations, Administration, + and Maintenance Framework for MPLS-Based Transport + Networks", RFC 6371, September 2011. + + [RFC6408] Jones, M., Korhonen, J., and L. Morand, "Diameter + Straightforward-Naming Authority Pointer (S-NAPTR) + Usage", RFC 6408, November 2011. + + [RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing + the Standards Track to Two Maturity Levels", BCP 9, + RFC 6410, October 2011. + + [RFC6526] Claise, B., Aitken, P., Johnson, A., and G. Muenz, + "IP Flow Information Export (IPFIX) Per Stream + Control Transmission Protocol (SCTP) Stream", + RFC 6526, March 2012. + + [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration + Protocol (NETCONF) Access Control Model", RFC 6536, + March 2012. + + [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, + C., and M. Azinger, "IANA-Reserved IPv4 Prefix for + Shared Address Space", BCP 153, RFC 6598, April 2012. + + [RFC6613] DeKok, A., "RADIUS over TCP", RFC 6613, May 2012. + + [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. + Wierenga, "Transport Layer Security (TLS) Encryption + for RADIUS", RFC 6614, May 2012. + + + +Ersue & Claise Informational [Page 73] + +RFC 6632 IETF Management Standards June 2012 + + + [RFCSEARCH] RFC Editor, "RFC Index Search Engine", + <http://www.rfc-editor.org/rfcsearch.html>. + + [SMI-NUMBERS] IANA, "Network Management Parameters - SMI OID List", + May 2012, + <http://www.iana.org/assignments/smi-numbers>. + + [SMI-YANG] Schoenwaelder, J., "Translation of SMIv2 MIB Modules + to YANG Modules", Work in Progress, April 2012. + + [STD06] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [STD07] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [STD16] Rose, M. and K. McCloghrie, "Structure and + identification of management information for TCP/ + IP-based internets", STD 16, RFC 1155, May 1990. + + Rose, M. and K. McCloghrie, "Concise MIB + definitions", STD 16, RFC 1212, March 1991. + + [STD17] McCloghrie, K. and M. Rose, "Management Information + Base for Network Management of TCP/IP-based + internets:MIB-II", STD 17, RFC 1213, March 1991. + + [STD58] McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Structure of Management + Information Version 2 (SMIv2)", STD 58, RFC 2578, + April 1999. + + McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Textual Conventions for SMIv2", + STD 58, RFC 2579, April 1999. + + McCloghrie, K., Ed., Perkins, D., Ed., and J. + Schoenwaelder, Ed., "Conformance Statements for + SMIv2", STD 58, RFC 2580, April 1999. + + [STD59] Waldbusser, S., "Remote Network Monitoring Management + Information Base", STD 59, RFC 2819, May 2000. + + + + + + + + + +Ersue & Claise Informational [Page 74] + +RFC 6632 IETF Management Standards June 2012 + + + [STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network Management + Protocol (SNMP) Management Frameworks", STD 62, + RFC 3411, December 2002. + + Case, J., Harrington, D., Presuhn, R., and B. Wijnen, + "Message Processing and Dispatching for the Simple + Network Management Protocol (SNMP)", STD 62, RFC + 3412, December 2002. + + Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, RFC + 3413, December 2002. + + Blumenthal, U. and B. Wijnen, "User-based Security + Model (USM) for version 3 of the Simple Network + Management Protocol (SNMPv3)", STD 62, RFC 3414, + December 2002. + + Wijnen, B., Presuhn, R., and K. McCloghrie, "View- + based Access Control Model (VACM) for the Simple + Network Management Protocol (SNMP)", STD 62, RFC + 3415, December 2002. + + Presuhn, R., Ed., "Version 2 of the Protocol + Operations for the Simple Network Management Protocol + (SNMP)", STD 62, RFC 3416, December 2002. + + Presuhn, R., Ed., "Transport Mappings for the Simple + Network Management Protocol (SNMP)", STD 62, RFC + 3417, December 2002. + + Presuhn, R., Ed., "Management Information Base (MIB) + for the Simple Network Management Protocol (SNMP)", + STD 62, RFC 3418, December 2002. + + [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, + "Uniform Resource Identifier (URI): Generic Syntax", + STD 66, RFC 3986, January 2005. + + [XPATH] World Wide Web Consortium, "XML Path Language (XPath) + Version 1.0", November 1999, + <http://www.w3.org/TR/1999/REC-xpath-19991116>. + + + + + + + + +Ersue & Claise Informational [Page 75] + +RFC 6632 IETF Management Standards June 2012 + + + [XSD-1] Beech, D., Thompson, H., Maloney, M., Mendelsohn, N., + and World Wide Web Consortium Recommendation REC- + xmlschema-1-20041028, "XML Schema Part 1: Structures + Second Edition", October 2004, + <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Ersue & Claise Informational [Page 76] + +RFC 6632 IETF Management Standards June 2012 + + +Appendix A. High-Level Classification of Management Protocols and Data + Models + + The following subsections aim to guide the reader for the fast + selection of the management standard in interest and can be used as a + dispatcher to forward to the appropriate chapter. The subsections + below classify the protocols on one hand according to high-level + criteria such as push versus pull mechanism, and passive versus + active monitoring. On the other hand, the protocols are categorized + concerning the network management task they address or the data model + extensibility they provide. Based on the reader's requirements, a + reduced set of standard protocols and associated data models can be + selected for further reading. + + As an example, someone outside of IETF typically would look for the + TWAMP protocol in the Operations and Management Area working groups + as it addresses performance management. However, the protocol TWAMP + has been developed by the IPPM working group in the Transport Area. + + Note that not all protocols have been listed in all classification + sections. Some of the protocols, especially the protocols with + specific focus in Section 3 cannot be clearly classified. Note also + that COPS and COPS-PR are not listed in the tables, as COPS-PR is not + recommended to use (see Section 3.3). + +A.1. Protocols Classified by Standards Maturity in the IETF + + This section classifies the management protocols according their + standard maturity in the IETF. The IETF standard maturity levels + Proposed, Draft, or Internet Standard, are defined in [RFC2026] (as + amended by [RFC6410]). An Internet Standard is characterized by a + high degree of technical maturity and by a generally held belief that + the specified protocol or service provides significant benefit to the + Internet community. + + The table below covers the standard maturity of the different + protocols listed in this document. Note that only the main protocols + (and not their extensions) are noted. An RFC search tool listing the + current document status is available at [RFCSEARCH]. + + + + + + + + + + + + +Ersue & Claise Informational [Page 77] + +RFC 6632 IETF Management Standards June 2012 + + + +---------------------------------------------+---------------------+ + | Protocol | Maturity Level | + +---------------------------------------------+---------------------+ + | SNMP [STD62][RFC3411] (Section 2.1) | Internet Standard | + | | | + | Syslog [RFC5424] (Section 2.2) | Proposed Standard | + | | | + | IPFIX [RFC5101] (Section 2.3) | Proposed Standard | + | | | + | PSAMP [RFC5476] (Section 2.3) | Proposed Standard | + | | | + | NETCONF [RFC6241] (Section 2.4.1) | Proposed Standard | + | | | + | DHCP for IPv4 [RFC2131] (Section 3.1.1) | Draft Standard | + | | | + | DHCP for IPv6 [RFC3315] (Section 3.1.1) | Proposed Standard | + | | | + | OWAMP [RFC4656] (Section 3.4) | Proposed Standard | + | | | + | TWAMP [RFC5357] (Section 3.4) | Proposed Standard | + | | | + | RADIUS [RFC2865] (Section 3.5) | Draft Standard | + | | | + | Diameter [RFC3588] (Section 3.6) | Proposed Standard | + | | | + | CAPWAP [RFC5416] (Section 3.7) | Proposed Standard | + | | | + | ANCP [RFC6320] (Section 3.8) | Proposed Standard | + | | | + | Ad hoc network configuration [RFC5889] | Informational | + | (Section 3.1.2) | | + | | | + | ACAP [RFC2244] (Section 3.9) | Proposed Standard | + | | | + | XCAP [RFC4825] (Section 3.10) | Proposed Standard | + +---------------------------------------------+---------------------+ + + Table 1: Protocols Classified by Standard Maturity in the IETF + + + + + + + + + + + + + +Ersue & Claise Informational [Page 78] + +RFC 6632 IETF Management Standards June 2012 + + +A.2. Protocols Matched to Management Tasks + + This subsection classifies the management protocols matching to the + management tasks for fault, configuration, accounting, performance, + and security management. + + +------------+------------+-------------+--------------+------------+ + | Fault Mgmt | Config. | Accounting | Performance | Security | + | | Mgmt | Mgmt | Mgmt | Mgmt | + +------------+------------+-------------+--------------+------------+ + | SNMP | SNMP | SNMP | SNMP | | + | notif. | config. | monitoring | monitoring | | + | with trap | with set | with get | with get | | + | operation | operation | operation | operation | | + | (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1) | (S. 2.1.1) | | + | | | | | | + | IPFIX | CAPWAP | IPFIX | IPFIX | | + | (S. 2.3) | (S. 3.7) | (S. 2.3) | (S. 2.3) | | + | | | | | | + | PSAMP | NETCONF | PSAMP | PSAMP | | + | (S. 2.3) | (S. 2.4.1) | (S. 2.3) | (S. 2.3) | | + | | | | | | + | Syslog | ANCP | RADIUS | | RADIUS | + | (S. 2.2) | (S. 3.8) | Accounting | | Authent.& | + | | | (S. 3.5) | | Authoriz. | + | | | | | (S. 3.5) | + | | | | | | + | | AUTOCONF | Diameter | | Diameter | + | | (S. 3.1.2) | Accounting | | Authent.& | + | | | (S. 3.6) | | Authoriz. | + | | | | | (S. 3.6) | + | | | | | | + | | ACAP | | | | + | | (S. 3.9) | | | | + | | | | | | + | | XCAP | | | | + | | (S. 3.10) | | | | + | | | | | | + | | DHCP | | | | + | | (S. 3.1.1) | | | | + +------------+------------+-------------+--------------+------------+ + + Table 2: Protocols Matched to Management Tasks + + Note: Corresponding section numbers are given in parentheses. + + + + + + +Ersue & Claise Informational [Page 79] + +RFC 6632 IETF Management Standards June 2012 + + +A.3. Push versus Pull Mechanism + + A pull mechanism is characterized by the Network Management System + (NMS) pulling the management information out of network elements, + when needed. A push mechanism is characterized by the network + elements pushing the management information to the NMS, either when + the information is available or on a regular basis. + + Client/Server protocols, such as DHCP, ANCP, ACAP, and XCAP are not + listed in Table 3. + + +---------------------------------+---------------------------------+ + | Protocols supporting the Pull | Protocols supporting the Push | + | mechanism | mechanism | + +---------------------------------+---------------------------------+ + | SNMP (except notifications) | SNMP notifications | + | (Section 2.1) | (Section 2.1) | + | NETCONF (except notifications) | NETCONF notifications | + | (Section 2.4.1) | (Section 2.4.1) | + | CAPWAP (Section 3.7) | Syslog (Section 2.2) | + | | IPFIX (Section 2.3) | + | | PSAMP (Section 2.3) | + | | RADIUS accounting | + | | (Section 3.5) | + | | Diameter accounting | + | | (Section 3.6) | + +---------------------------------+---------------------------------+ + + Table 3: Protocol Classification by Push versus Pull Mechanism + +A.4. Passive versus Active Monitoring + + Monitoring can be divided into two categories: passive and active + monitoring. Passive monitoring can perform the network traffic + monitoring, monitoring of a device, or the accounting of network + resource consumption by users. Active monitoring, as used in this + document, focuses mainly on active network monitoring and relies on + the injection of specific traffic (also called "synthetic traffic"), + which is then monitored. The monitoring focus is indicated in the + table below as "network", "device", or "accounting". + + This classification excludes non-monitoring protocols, such as + configuration protocols: Ad hoc network autoconfiguration, ANCP, and + XCAP. Note that some of the active monitoring protocols, in the + context of the data path, e.g., ICMP Ping and Traceroute [RFC1470], + Bidirectional Forwarding Detection (BFD) [RFC5880], and PWE3 Virtual + Circuit Connectivity Verification (VCCV) [RFC5085] are covered in + [OAM-OVERVIEW]. + + + +Ersue & Claise Informational [Page 80] + +RFC 6632 IETF Management Standards June 2012 + + + +---------------------------------+---------------------------------+ + | Protocols supporting passive | Protocols supporting active | + | monitoring | monitoring | + +---------------------------------+---------------------------------+ + | IPFIX (network) (Section 2.3) | OWAMP (network) (Section 3.4) | + | PSAMP (network) (Section 2.3) | TWAMP (network) (Section 3.4) | + | SNMP (network and device) | | + | (Section 2.1) | | + | NETCONF (device) | | + | (Section 2.4.1) | | + | RADIUS (accounting) | | + | (Section 3.5) | | + | Diameter (accounting) | | + | (Section 3.6) | | + | CAPWAP (device) (Section 3.7) | | + +---------------------------------+---------------------------------+ + + Table 4: Protocols for Passive and Active Monitoring and Their + Monitoring Focus + + The application of SNMP to passive traffic monitoring (e.g., with + RMON-MIB) or active monitoring (with IPPM MIB) depends on the MIB + modules used. However, the SNMP protocol itself does not have + operations, which support active monitoring. NETCONF can be used for + passive monitoring, e.g., with the NETCONF Monitoring YANG module + [RFC6022] for the monitoring of the NETCONF protocol. CAPWAP + monitors the status of a Wireless Termination Point. + + RADIUS and diameter are considered passive monitoring protocols as + they perform accounting, i.e., counting the number of packets/bytes + for a specific user. + +A.5. Supported Data Model Types and Their Extensibility + + The following table matches the protocols to the associated data + model types. Furthermore, the table indicates how the data model can + be extended based on the available content today and whether the + protocol contains a built-in mechanism for proprietary extensions of + the data model. + + + + + + + + + + + + +Ersue & Claise Informational [Page 81] + +RFC 6632 IETF Management Standards June 2012 + + + +-------------+---------------+------------------+------------------+ + | Protocol | Data Modeling | Data Model | Proprietary Data | + | | | Extensions | Modeling | + | | | | Extensions | + +-------------+---------------+------------------+------------------+ + | SNMP | MIB modules | New MIB modules | Enterprise- | + | (S. 2.1) | defined with | specified in new | specific MIB | + | | SMI | RFCs | modules | + | | (S. 2.1.3) | | | + | | | | | + | Syslog | Structured | With the | Enterprise- | + | (S. 2.2) | Data Elements | procedure to add | specific SDEs | + | | (SDEs) | Structured Data | | + | | (S. 4.2.1) | ID in [RFC5424] | | + | | | | | + | IPFIX | IPFIX | With the | Enterprise- | + | (S. 2.3) | Information | procedure to add | specific | + | | Elements, | Information | Information | + | | IPFIX IANA | Elements | Elements | + | | registry at | specified in | [RFC5101] | + | | [IANA-IPFIX] | [RFC5102] | | + | | (S. 2.3) | | | + | | | | | + | PSAMP | PSAMP | With the | Enterprise- | + | (S. 2.3) | Information | procedure to add | specific | + | | Elements, as | Information | Information | + | | an extension | Elements | Elements | + | | to IPFIX | specified in | [RFC5101] | + | | [IANA-IPFIX], | [RFC5102] | | + | | and PSAMP | | | + | | IANA registry | | | + | | at | | | + | | [IANA-PSAMP] | | | + | | (S. 2.3) | | | + | | | | | + | NETCONF | YANG modules | New YANG modules | Enterprise- | + | (S. 2.4.1) | (S. 2.4.2) | specified in new | specific YANG | + | | | RFCs following | modules | + | | | the guideline in | | + | | | [RFC6087] | | + | | | | | + | IPPM OWAMP/ | IPPM metrics | New IPPM metrics | Not applicable | + | TWAMP | (*) (S. 3.4) | (S. 3.4) | | + | (S. 3.4) | | | | + + + + + + + +Ersue & Claise Informational [Page 82] + +RFC 6632 IETF Management Standards June 2012 + + + | | | | | + | RADIUS | TLVs | RADIUS-related | Vendor-Specific | + | (S. 3.5) | | registries at | Attributes | + | | | [IANA-AAA] and | [RFC2865] | + | | | [IANA-PROT] | | + | | | | | + | Diameter | AVPs | Diameter-related | Vendor-Specific | + | (S. 3.6) | | registry at | Attributes | + | | | [IANA-AAA] | [RFC2865] | + | | | | | + | CAPWAP | TLVs | New bindings | Vendor-specific | + | (S. 3.7) | | specified in new | TLVs | + | | | RFCs | | + +-------------+---------------+------------------+------------------+ + + Table 5: Data Models and Their Extensibility + + (*): With the publication of [RFC6248], the latest IANA registry for + IPFIX metrics has been declared Obsolete. + +Appendix B. New Work Related to IETF Management Standards + +B.1. Energy Management (EMAN) + + Energy management is becoming an additional requirement for network + management systems due to several factors including the rising and + fluctuating energy costs, the increased awareness of the ecological + impact of operating networks and devices, and government regulation + on energy consumption and production. + + The basic objective of energy management is operating communication + networks and other equipment with a minimal amount of energy while + still providing sufficient performance to meet service-level + objectives. Today, most networking and network-attached devices + neither monitor nor allow controlled energy usage as they are mainly + instrumented for functions such as fault, configuration, accounting, + performance, and security management. These devices are not + instrumented to be aware of energy consumption. There are very few + means specified in IETF documents for energy management, which + includes the areas of power monitoring, energy monitoring, and power + state control. + + A particular difference between energy management and other + management tasks is that in some cases energy consumption of a device + is not measured at the device itself but reported by a different + place. For example, at a Power over Ethernet (PoE) sourcing device + or at a smart power strip, where one device is effectively metering + another remote device. This requires a clear definition of the + + + +Ersue & Claise Informational [Page 83] + +RFC 6632 IETF Management Standards June 2012 + + + relationship between the reporting devices and identification of + remote devices for which monitoring information is provided. Similar + considerations will apply to power state control of remote devices, + for example, at a PoE sourcing device that switches on and off power + at its ports. Another example scenario for energy management is a + gateway to low resourced and lossy network devices in wireless a + building network. Here the energy management system talks directly + to the gateway but not necessarily to other devices in the building + network. + + At the time of this writing, the EMAN working group is working on the + management of energy-aware devices, covered by the following items: + + o The requirements for energy management, specifying energy + management properties that will allow networks and devices to + become energy aware. In addition to energy awareness + requirements, the need for control functions will be discussed. + Specifically, the need to monitor and control properties of + devices that are remote to the reporting device should be + discussed. + + o The energy management framework, which will describe extensions to + the current management framework, required for energy management. + This includes: power and energy monitoring, power states, power + state control, and potential power state transitions. The + framework will focus on energy management for IP-based network + equipment (routers, switches, PCs, IP cameras, phones and the + like). Particularly, the relationships between reporting devices, + remote devices, and monitoring probes (such as might be used in + low-power and lossy networks) need to be elaborated. For the case + of a device reporting on behalf of other devices and controlling + those devices, the framework will address the issues of discovery + and identification of remote devices. + + o The Energy-aware Networks and Devices MIB document, for monitoring + energy-aware networks and devices, will address devices + identification, context information, and potential relationship + between reporting devices, remote devices, and monitoring probes. + + o The Power and Energy Monitoring MIB document will document + defining managed objects for the monitoring of power states and + energy consumption/production. The monitoring of power states + includes the following: retrieving power states, properties of + power states, current power state, power state transitions, and + power state statistics. The managed objects will provide means of + reporting detailed properties of the actual energy rate (power) + and of accumulated energy. Further, they will provide information + on electrical power quality. + + + +Ersue & Claise Informational [Page 84] + +RFC 6632 IETF Management Standards June 2012 + + + o The Battery MIB document will define managed objects for battery + monitoring, which will provide means of reporting detailed + properties of the actual charge, age, and state of a battery and + of battery statistics. + + o The applicability statement will describe the variety of + applications that can use the energy framework and associated MIB + modules. Potential examples are building networks, home energy + gateway, etc. Finally, the document will also discuss + relationships of the framework to other architectures and + frameworks (such as Smart Grid). The applicability statement will + explain the relationship between the work in this WG and other + existing standards, e.g., from the IEC, ANSI, DMTF, etc. Note + that the EMAN WG will be looking into existing standards such as + those from the IEC, ANSI, DMTF and others, and reuse existing work + as much as possible. + + The documents of the EMAN working group can be found at [EMAN-WG]. + +Authors' Addresses + + Mehmet Ersue (editor) + Nokia Siemens Networks + St.-Martin-Strasse 53 + Munich 81541 + Germany + + EMail: mehmet.ersue@nsn.com + + + Benoit Claise + Cisco Systems, Inc. + De Kleetlaan 6a b1 + Diegem 1831 + Belgium + + EMail: bclaise@cisco.com + + + + + + + + + + + + + + +Ersue & Claise Informational [Page 85] + |