idnits 2.17.1 draft-ersue-opsawg-management-fw-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 27, 2011) is 4838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.baker-ietf-core' is mentioned on line 1030, but not defined == Missing Reference: 'I-D.ietf-mpls-tp-oam-framework' is mentioned on line 191, but not defined == Missing Reference: 'I-D.ietf-ipfix-export-per-sctp-stream' is mentioned on line 758, but not defined == Missing Reference: 'I-D.ietf-ipfix-mediators-framework' is mentioned on line 810, but not defined == Missing Reference: 'I-D.ietf-ipfix-flow-selection-tech' is mentioned on line 813, but not defined == Missing Reference: 'I-D.ietf-ipfix-anon' is mentioned on line 814, but not defined == Missing Reference: 'I-D.draft-ietf-netconf-4741bis' is mentioned on line 1006, but not defined == Missing Reference: 'I-D.draft-ietf-netconf-4742bis' is mentioned on line 920, but not defined == Missing Reference: 'I-D.draft-ietf-netmod-dsdl-map' is mentioned on line 969, but not defined == Missing Reference: 'I-D.draft-ietf-netmod-arch' is mentioned on line 984, but not defined == Missing Reference: 'I-D.draft-linowski-netmod-yang-abstract' is mentioned on line 986, but not defined == Missing Reference: 'I-D.draft-ietf-netmod-yang-usage' is mentioned on line 996, but not defined == Missing Reference: 'I-D.draft-ietf-ipfix-configuration-model' is mentioned on line 1003, but not defined == Missing Reference: 'I-D.dekok-radext-radius-extensions' is mentioned on line 1261, but not defined == Missing Reference: 'I-D.ietf-radext-radsec' is mentioned on line 1278, but not defined == Missing Reference: 'I-D.ietf-radext-dtls' is mentioned on line 1281, but not defined == Missing Reference: 'I-D.ietf-radext-dynamic-discovery' is mentioned on line 1287, but not defined == Missing Reference: 'I-D.ietf-radext-design' is mentioned on line 1319, but not defined == Missing Reference: 'I-D.ietf-dime-rfc3588bis' is mentioned on line 1461, but not defined ** Obsolete undefined reference: RFC 3588 (Obsoleted by RFC 6733) == Missing Reference: 'I-D.ietf-dime-extended-naptr' is mentioned on line 1479, but not defined == Missing Reference: 'I-D.ietf-ancp-protocol' is mentioned on line 1554, but not defined == Missing Reference: 'I-D.ietf-dime-diameter-base-protocol-mib' is mentioned on line 2002, but not defined -- Obsolete informational reference (is this intentional?): RFC 2679 (Obsoleted by RFC 7679) -- Obsolete informational reference (is this intentional?): RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 3164 (Obsoleted by RFC 5424) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4005 (Obsoleted by RFC 7155) -- Obsolete informational reference (is this intentional?): RFC 4006 (Obsoleted by RFC 8506) -- Obsolete informational reference (is this intentional?): RFC 4133 (Obsoleted by RFC 6933) -- Obsolete informational reference (is this intentional?): RFC 4148 (Obsoleted by RFC 6248) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 4742 (Obsoleted by RFC 6242) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5539 (Obsoleted by RFC 7589) -- Obsolete informational reference (is this intentional?): RFC 5719 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 5815 (Obsoleted by RFC 6615) -- Obsolete informational reference (is this intentional?): RFC 5953 (Obsoleted by RFC 6353) -- Obsolete informational reference (is this intentional?): RFC 6021 (Obsoleted by RFC 6991) Summary: 1 error (**), 0 flaws (~~), 23 warnings (==), 21 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Ersue, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational January 27, 2011 5 Expires: July 31, 2011 7 An Overview of the IETF Network Management Standards 8 draft-ersue-opsawg-management-fw-03 10 Abstract 12 This document gives an overview of the IETF network management 13 standards and summarizes existing and ongoing development of IETF 14 standards-track network management protocols and data models. The 15 purpose of this document is on the one hand to help system developers 16 and users to select appropriate standard management protocols and 17 data models to address relevant management needs. On the other hand 18 the document can be used as an overview and guideline by other SDOs 19 or bodies planning to use IETF management technologies and data 20 models. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 31, 2011. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1. Scope and Target Audience . . . . . . . . . . . . . . . . 4 58 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 60 2. Core Network Management Protocols . . . . . . . . . . . . . . 7 61 2.1. Simple Network Management Protocol (SNMP) . . . . . . . . 7 62 2.1.1. Architectural Principles of SNMP . . . . . . . . . . . 7 63 2.1.2. SNMP and its Versions . . . . . . . . . . . . . . . . 8 64 2.1.3. Structure of Managed Information (SMI) . . . . . . . . 9 65 2.1.4. SNMP Security and Access Control Models . . . . . . . 10 66 2.1.5. SNMP Transport Subsystem and Transport Models . . . . 13 67 2.2. SYSLOG Protocol . . . . . . . . . . . . . . . . . . . . . 15 68 2.3. IP Flow Information Export (IPFIX) and Packet Sampling 69 (PSAMP) Protocols . . . . . . . . . . . . . . . . . . . . 17 70 2.4. Network Configuration Protocol (NETCONF) . . . . . . . . . 19 71 2.4.1. YANG - NETCONF Data Modeling Language . . . . . . . . 21 72 3. Management Protocols and Mechanisms with specific Focus . . . 22 73 3.1. IP Address Management with Dynamic Host Configuration 74 Protocol (DHCP) . . . . . . . . . . . . . . . . . . . . . 23 75 3.2. IPv6 Network Operations . . . . . . . . . . . . . . . . . 23 76 3.3. Policy-based Management . . . . . . . . . . . . . . . . . 24 77 3.3.1. IETF Policy Framework . . . . . . . . . . . . . . . . 24 78 3.3.2. Common Open Policy Service (COPS) and COPS Usage 79 for Policy Provisioning (COPS-PR) . . . . . . . . . . 25 80 3.4. IP Performance Metrics (IPPM) . . . . . . . . . . . . . . 25 81 3.5. Remote Authentication Dial In User Service (RADIUS) . . . 27 82 3.6. Diameter Base Protocol (DIAMETER) . . . . . . . . . . . . 30 83 3.7. Control And Provisioning of Wireless Access Points 84 (CAPWAP) . . . . . . . . . . . . . . . . . . . . . . . . . 33 85 3.8. Access Node Control Protocol (ANCP) . . . . . . . . . . . 34 86 3.9. Ad-Hoc Network Autoconfiguration . . . . . . . . . . . . . 34 87 3.10. Application Configuration Access Protocol (ACAP) . . . . . 34 88 3.11. XML Configuration Access Protocol (XCAP) . . . . . . . . . 35 89 3.12. Extensible Provision Protocol (EPP) . . . . . . . . . . . 35 90 4. Proposed, Draft and Standard Level Data Models . . . . . . . . 36 91 4.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 36 92 4.2. Configuration Management . . . . . . . . . . . . . . . . . 38 93 4.3. Accounting Management . . . . . . . . . . . . . . . . . . 39 94 4.4. Performance Management . . . . . . . . . . . . . . . . . . 40 95 4.5. Security Management . . . . . . . . . . . . . . . . . . . 42 96 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 43 98 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 100 9. Informative References . . . . . . . . . . . . . . . . . . . . 44 101 Appendix A. New Work related to IETF Management Framework . . . . 59 102 A.1. Energy Management (EMAN) . . . . . . . . . . . . . . . . . 59 103 Appendix B. Open issues . . . . . . . . . . . . . . . . . . . . . 61 104 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 61 105 C.1. 02-03 . . . . . . . . . . . . . . . . . . . . . . . . . . 61 106 C.2. 01-02 . . . . . . . . . . . . . . . . . . . . . . . . . . 61 107 C.3. 00-01 . . . . . . . . . . . . . . . . . . . . . . . . . . 61 109 1. Introduction 111 1.1. Scope and Target Audience 113 This document gives an overview of the IETF network management 114 standards and summarizes existing and ongoing development of IETF 115 standards-track network management protocols and data models. 117 The target audience of the document are on the one hand IETF working 118 groups, which aim to select appropriate standard management protocols 119 and data models to address their management needs. On the other hand 120 the document can be used as an overview and guideline by non-IETF 121 SDOs planning to use IETF management technologies and data models. 122 The document can be also used to initiate a discussion between the 123 bodies with the goal to gather new requirements and to detect 124 possible gaps. Finally, this document is directed to all interested 125 parties, which seek to get an overview of the current set of the IETF 126 management protocols such as network administrators or new comers to 127 IETF. 129 Section 2 gives an overview of the IETF core network management 130 standards with a special focus on Simple Network Management Protocol 131 (SNMP), SYSLOG, IPFIX/PSAMP, and NETCONF. Section 3 discusses IETF 132 management protocols and mechanisms with a specific focus and their 133 use cases. Section 4 discusses Proposed, Draft and Standard Level 134 data models, such as MIBs designed to address specific set of issues 135 and maps them to different management tasks. 137 This document mainly refers to Proposed, Draft or Full Standard 138 documents at IETF (see [RFCSEARCH]). As far as it is valuable Best 139 Current Practice (BCP) documents are referenced. In exceptional 140 cases and if the document provides substantial guideline for standard 141 usage or fills an essential gap, Experimental and Informational RFCs 142 are noticed and ongoing work is mentioned. 144 Note that IETF specifications must have "multiple, independent, and 145 interoperable implementations" before they can be advanced to Draft 146 Standard status. An Internet or Full Standard (also referred as 147 Standard), is characterized by a high degree of technical maturity 148 and by a generally held belief that the specified protocol or service 149 provides significant benefit to the Internet community [RFC2026]. 151 Information on active and concluded IETF working groups (e.g. 152 charters, documents and mail archive) can be found at [IETF-WGS]. 154 Note: The final document will not contain any references to Internet- 155 Drafts. Current references in the document are assumed to be 156 published soon. 158 RFC Editor: Please delete the note above before publication. 160 1.2. Related Work 162 [I-D.baker-ietf-core] identifies the key protocols of the Internet 163 Protocol Suite. In analogy to [I-D.baker-ietf-core] this document 164 gives an overview of the IETF network management standards and its 165 usage scenarios. 167 [RFC3535] "Overview of the 2002 IAB Network Management Workshop" 168 documented strengths and weaknesses of some IETF management 169 protocols. In choosing existing protocol solutions to meet the 170 management requirements, it is recommended that these strengths and 171 weaknesses be considered, even though some of the recommendations 172 from the 2002 IAB workshop have become outdated, some have been 173 standardized, and some are being worked on at the IETF. 175 [RFC5706] "Guidelines for Considering Operations and Management of 176 New Protocols and Extensions" recommends working groups to consider 177 operations and management needs, and then select appropriate 178 management protocols and data models. This document can be used to 179 ease surveying the IETF standards-track network management protocols 180 and management data models. 182 Note: This document uses the expired draft [I-D.ietf-opsawg-survey- 183 management] as a starting point and enhances it with a special focus 184 on the description of the IETF network management standards and 185 management data models developed at IETF. 187 Note: The document does not cover OAM technologies on the data-path, 188 e.g. OAM of tunnels, MPLS-TP OAM, Pseudowire, etc. [I-D.ietf- 189 opsawg-oam-overview] gives an overview on the OAM toolset for 190 detecting and reporting connection failures or measurement of 191 connection performance parameters. [I-D.ietf-mpls-tp-oam-framework] 192 describes the OAM Framework for MPLS-based Transport Networks. 194 1.3. Terminology 196 This document does not describe standard requirements. Therefore key 197 words from RFC2119 are not used in the document. 199 o Agent: A software module that performs the network management 200 functions requested by network management stations. An agent 201 module may be implemented in any network element that is to be 202 managed, such as a host, bridge, or router. The 'management 203 server' in NETCONF terminology. 205 o CLI: Command Line Interface. A management interface that human 206 administrators use to interact with networking equipment. 208 o Data model: A mapping of the contents of an information model into 209 a form that is specific to a particular type of data store or 210 repository (see [RFC3444]). 212 o Event: An occurrence of something in the "real world". Events can 213 be indicated to managers through an event message or notification. 215 o FCAPS: Fault, Configuration, Accounting, Performance, Security. 216 The five categories of management functionality defined by TMN. 218 o Information model: An abstraction and representation of entities 219 in a managed environment, their properties, attributes and 220 operations, and the way they relate to each other. Independent of 221 any specific repository, protocol, or platform (see [RFC3444]). 223 o Managed object: A management abstraction of a resource; a piece of 224 management information in a MIB. In the context of SNMP, a 225 structured set of data variables that represent some resource to 226 be managed or other aspect of a managed device. 228 o Manager: An entity that acts in a manager role, either a user or 229 an application. The counterpart to an agent. A 'management 230 client' in NETCONF terminology. 232 o Management Information Base (MIB): The definition of a related 233 collection of objects that represent a collection of resources to 234 be managed defined by using the modeling language SMI. 236 o MIB module: A MIB definition, typically for a particular network 237 technology feature, that constitutes a subtree in an object 238 identifier tree. A MIB that is provided by a management agent is 239 typically composed of multiple instantiated MIB modules. 241 o Modeling language: A modeling language is any artificial language 242 that can be used to express information or knowledge or systems in 243 a structure that is defined by a consistent set of rules. 244 Examples are SMIv2, XSD, and YANG. 246 o Notification: An event message. 248 o Trap: An unsolicited message sent by an agent to a management 249 station to notify an unusual event. 251 2. Core Network Management Protocols 253 2.1. Simple Network Management Protocol (SNMP) 255 2.1.1. Architectural Principles of SNMP 257 As described in [RFC3410] the SNMPv3 Framework, builds upon both the 258 original SNMPv1 and SNMPv2 framework. The basic structure and 259 components for the SNMP framework did not change between its versions 260 and comprises following components: 262 o managed nodes, each with an SNMP entity providing remote access to 263 management instrumentation (the agent), 265 o at least one SNMP entity with management applications (the 266 manager), and 268 o a management protocol used to convey management information 269 between the SNMP entities, and management information. 271 During its evolution, the fundamental architecture of the SNMP 272 Management Framework remained consistent based on a modular 273 architecture, which consists of: 275 o a generic protocol definition independent of the data it is 276 carrying, and 278 o a protocol-independent data definition language, 280 o a virtual database containing data sets of management information 281 definitions (the Management Information Base, or MIB), and 283 o security and administration. 285 As such following standards build up the basis of the current SNMP 286 Management Framework: 288 o SNMPv3 protocol, 290 o the modeling language SMIv2, and 292 o MIB modules for different management issues. 294 The SNMPv3 Framework extends the architectural principles of SNMPv1 295 and SNMPv2 by: 297 o building on these three basic architectural components, in some 298 cases incorporating them from the SNMPv2 Framework by reference, 299 and 301 o by using the same layering principles in the definition of new 302 capabilities in the security and administration portion of the 303 architecture. 305 2.1.2. SNMP and its Versions 307 SNMP is based on three conceptual entities: Manager, Agent, and the 308 Management Information Base (MIB). In any configuration, at least 309 one manager node runs SNMP management software. Typically, network 310 devices such as bridges, routers, and servers are equipped with an 311 agent. The agent is responsible for providing access to a local MIB 312 of objects that reflects the resources and activity at its node. 313 Following the manager-agent paradigm, an agent can generate 314 notifications and send them as unsolicited messages to the management 315 application. 317 To enhance this basic functionality, a new version of SNMP has been 318 introduced in 1993. SNMPv2 added a Trap PDU, an Inform message, a 319 bulk transfer capability and other functional extensions like an 320 administrative model for access control, security extensions, and 321 Manager-to-Manager communication. SNMPv2 entities can have a dual 322 role as manager and agent. However, neither SNMPv1 nor SNMPv2 offers 323 sufficient security features. To address the security deficiencies 324 of SNMPv1/v2, SNMPv3 was issued as a set of Proposed Standards in 325 January 1998 (see [STD62]). 327 [BCP74][RFC3584] "Coexistence between Version 1, Version 2, and 328 Version 3 of the Internet-standard Network Management Framework" 329 gives an overview of the relevant standard documents on the three 330 SNMP versions. The BCP document furthermore describes how to convert 331 MIB modules from SMIv1 format to SMIv2 format and how to translate 332 notification parameters as well as describes the mapping between the 333 message processing and security models (see [RFC3584]). 335 SNMP utilizes the Management Information Base, a virtual information 336 store of modules of managed objects. Generally, standard MIB modules 337 support common functionality in a device. Based on this fact 338 operators often define additional MIB modules for their enterprise or 339 use other protocols such as a Command Line Interface (CLI) to 340 configure non standard data in managed devices and their interfaces. 342 SNMP traps and informs can alert an operator or an application when 343 some aspect of a protocol fails or encounters an error condition, and 344 the contents of a notification can be used to guide subsequent SNMP 345 polling to gather additional information about an event. 347 SNMP is widely used for monitoring fault and performance data and 348 with its stateless nature SNMP also works well for status polling and 349 determining the operational state of specific functionality. The 350 widespread use of counters in standard MIB modules permits the 351 interoperable comparison of statistics across devices from different 352 vendors. Counters have been especially useful in monitoring bytes 353 and packets going in and out over various protocol interfaces. SNMP 354 is often used to poll a device for sysUpTime, which serves to report 355 the time since the last reinitialization of the device, to check for 356 operational liveliness, and to detect discontinuities in some 357 counters. 359 Some operators use SNMP for configuration in their environment (e.g. 360 for DOCSIS based systems such as cable modems), while others find 361 SNMP has a limited configuration management support. Compared to 362 SNMP, with its data-centric view, CLI has a task-oriented view where 363 NETCONF follows the document-based view for configuration management. 364 SNMP does not separate clearly between configuration data and 365 operational state. SMIv2 has limited support for structured data 366 types and relationships among managed objects. 368 SNMPv1 [RFC1157] is a Full Standard that the IETF has declared 369 Historic and it is not recommended due to its lack of security 370 features. SNMPv2c [RFC1901] is only an Experimental RFC that the 371 IETF has declared Historic and it is not recommended due to its lack 372 of security features. 374 SNMPv3 [STD62] is a Full Standard that is recommended due to its 375 security features, including support for authentication, encryption, 376 message timeliness and integrity checking, and fine-grained data 377 access controls. An overview of the SNMPv3 document set is in 378 [RFC3410]. 380 Standards exist to use SNMP over diverse transport and link layer 381 protocols, including TCP, UDP, Ethernet, OSI, and others (see 382 Section 2.1.5.1). 384 2.1.3. Structure of Managed Information (SMI) 386 SNMP MIB modules are defined with the notation and grammar specified 387 as the Structure of Managed Information (SMI), which uses an adapted 388 subset of Abstract Syntax Notation One (ASN.1). 390 The SMI is divided into three parts: module definitions, object 391 definitions, and, notification definitions. 393 o Module definitions are used when describing information modules. 394 An ASN.1 macro, MODULE-IDENTITY, is used to concisely convey the 395 semantics of an information module. 397 o Object definitions are used when describing managed objects. An 398 ASN.1 macro, OBJECT-TYPE, is used to concisely convey the syntax 399 and semantics of a managed object. 401 o Notification definitions are used when describing unsolicited 402 transmissions of management information. An ASN.1 macro, 403 NOTIFICATION-TYPE, is used to concisely convey the syntax and 404 semantics of a notification. 406 Note that SMIv1 is outdated and shouldn't be used. 408 SMIv2 is the new notation for managed information definition and 409 should be used to define MIB modules. SMIv2 is specified in 410 following RFCs: 412 o [STD58][RFC2578] defines Version 2 of the Structure of Management 413 Information (SMIv2), 415 o [STD58][RFC2579] defines common MIB "Textual Conventions", 417 o [STD58][RFC2580] defines Conformance Statements and requirements 418 for defining agent and manager capabilities, and 420 o [RFC3584] defines the mapping rules for and the conversion of MIB 421 documents between SMIv1 and SMIv2 formats. 423 2.1.4. SNMP Security and Access Control Models 425 2.1.4.1. Security Requirements on the SNMP Management Framework 427 Several of the classical threats to network protocols are applicable 428 to management problem space and therefore applicable to any security 429 model used in an SNMP Management Framework. This section lists 430 principal threats, secondary threats, and threats which are of lesser 431 importance as defined in [RFC3411]. 433 The principal threats against which SNMP Security Models can provide 434 protection are: 436 Modification of Information: 437 Information might be altered by an unauthorized entity, e.g. in- 438 transit SNMP messages can be generated to effect unauthorized 439 management operations, including falsifying the value of an 440 object. 442 Masquerade: 443 The masquerade threat is the danger that management operations not 444 authorized for some principal may be attempted by assuming the 445 identity of another principal that has the appropriate 446 authorizations. 448 Secondary threats against which any Security Model used within this 449 architecture can provide protection are: 451 Message Stream Modification: 452 The SNMP protocol is typically based upon a connectionless 453 transport service which may operate over any subnetwork service. 454 The re-ordering, delay or replay of messages can and does occur 455 through the natural operation of many such subnetwork services. 456 The message stream modification threat is the danger that messages 457 may be maliciously re-ordered, delayed or replayed to an extent 458 which is greater than what can occur through the natural operation 459 of a subnetwork service, in order to effect unauthorized 460 management operations. 462 Disclosure: 463 The disclosure threat is the danger of eavesdropping on the 464 exchanges between SNMP engines. Protecting against this threat 465 may be required as a matter of local policy. 467 There are at least two threats against which a Security Model within 468 this architecture need not protect, since they are deemed to be of 469 lesser importance in this context: 471 Denial of Service: 472 A Security Model need not attempt to address the broad range of 473 attacks by which service on behalf of authorized users is denied. 474 Indeed, such denial-of-service attacks are in many cases 475 indistinguishable from the type of network failures with which any 476 viable management protocol must cope as a matter of course. 478 Traffic Analysis: 479 A Security Model need not attempt to address traffic analysis 480 attacks. Many traffic patterns are predictable - entities may be 481 managed on a regular basis by a relatively small number of 482 management stations - and therefore there is no significant 483 advantage afforded by protecting against traffic analysis. 485 2.1.4.2. User-Based Security Model (USM) 487 The User Security Model (USM) provides authentication and privacy 488 services for SNMP (RFC3414). Specifically, USM is designed to secure 489 against the principal and secondary threats discussed in 490 Section 2.1.4.1. 492 USM does not secure against Denial of Service and attacks based on 493 Traffic Analysis. 495 The security services the SNMP Security Model supports are: 497 o Data Integrity is the provision of the property that data has not 498 been altered or destroyed in an unauthorized manner, nor have data 499 sequences been altered to an extent greater than can occur non- 500 maliciously. 502 o Data Origin Authentication is the provision of the property that 503 the claimed identity of the user on whose behalf received data was 504 originated is supported. 506 o Data Confidentiality is the provision of the property that 507 information is not made available or disclosed to unauthorized 508 individuals, entities, or processes. 510 o Message timeliness and limited replay protection is the provision 511 of the property that a message whose generation time is outside of 512 a specified time window is not accepted. 514 See [RFC3414] in [STD62] for a detailed description of SNMPv3 USM. 516 2.1.4.3. View-Based Access Control Model (VACM) 518 The View-Based Access Control facility of SNMP enables the 519 configuration of agents to provide different levels of access to the 520 agent's MIB. An agent entity can restrict access to its MIB for a 521 particular manager entity in two ways: 523 o It can restrict access to a certain portion of its MIB, e.g., an 524 agent may restrict most manager principals to viewing performance- 525 related statistics and allow only a single designated manager 526 principal to view and update configuration parameters. 528 o The agent can limit the operations that a principal can use on 529 that portion of the MIB. E.g., a particular manager principal 530 could be limited to read-only access to a portion of an agent's 531 MIB. 533 The access control policy to be used by an agent must be pre- 534 configured for each manager. The policy is based on a table that 535 details the access privileges of the various authorized managers. 537 VACM defines five elements that make up the Access Control Model: 539 groups, security level, contexts, MIB views, and access policy. 540 Access to a MIB is controlled by means of a MIB view. The 541 vacmAccessTable maps the group name, security information, the 542 context, and the message type (read, write, or notification) into 543 three MIB views for read, write, or notification access, which are 544 used to determine whether a managed object is allowed to access. 546 See [RFC3415] in [STD62] for a detailed description of SNMPv3 VACM. 548 2.1.5. SNMP Transport Subsystem and Transport Models 550 The User-based Security Model (USM) was designed to be independent of 551 other existing security infrastructures to ensure it could function 552 when third-party authentication services were not available. As a 553 result, USM utilizes a separate user and key-management 554 infrastructure. Operators have reported that having to deploy 555 another user and key-management infrastructure in order to use SNMPv3 556 is costly and hinders the deployment of SNMPv3. 558 SNMP Transport Subsystem [RFC5590] extends the existing SNMP 559 framework and transport model and enables the use of transport 560 protocols to provide message security unifying the administrative 561 security management for SNMP, and other management interfaces. 563 Transport Models are tied into the SNMP framework through the 564 Transport Subsystem. The Transport Security Model has been designed 565 to work on top of lower-layer, secure Transport Models. The 566 Transport Security Model [RFC5591] and the Secure Shell Transport 567 Model [RFC5592] utilize the Transport Subsystem. 569 2.1.5.1. SNMP Transport Security Model 571 The Transport Security Model is an alternative to the existing SNMPv1 572 Security Model [RFC3584], the SNMPv2c Security Model [RFC3584], and 573 the User-based Security Model [RFC3414]. The Secure Shell Transport 574 Model defines furthermore an alternative to existing standard 575 transport mappings described in [RFC3417] such as SNMP over OSI, SNMP 576 over IPX and SNMP over UDP. SNMP over UDP has been so far the most 577 commonly used SNMP transport binding. The Experimental RFC [RFC3430] 578 defines a transport mapping with TCP. 580 The new SNMP Transport Subsystem modifies the Abstract Service 581 Interfaces to pass transport-specific security parameters to other 582 subsystems. This includes transport-specific security parameters 583 that are translated into the transport-independent parameters such as 584 securityName and securityLevel. 586 The SNMP Transport Subsystem utilizes one or more lower-layer 587 security mechanisms to provide message-oriented security services. 588 These include authentication of the sender, encryption, timeliness 589 checking, and data integrity checking. 591 A secure Transport Model establishes an authenticated and possibly 592 encrypted link between the Transport Models of two SNMP engines. 593 After a transport-layer tunnel is established, SNMP messages can be 594 sent through this tunnel from one SNMP engine to the other. The new 595 Transport Model supports sending multiple SNMP messages through the 596 same tunnel to amortize the costs of establishing a security 597 association. 599 The Transport Model on top of a secure transport protocol performs 600 security functions within the Transport Subsystem, including the 601 translation of transport-security parameters to/from Security-Model- 602 independent parameters. To accommodate this, an implementation- 603 specific cache of transport-specific information is introduced and 604 the data flows on this path are extended to pass Security-Model- 605 independent values. For this purpose, the Transport Subsystem 606 extends SNMPv3 Abstract Service Interfaces (ASI). New Security 607 Models can be defined using the modified ASIs and the transport- 608 information cache. 610 [RFC5592] introduces a Transport Model (Secure Shell Transport 611 Model), which makes use of the commonly deployed Secure Shell 612 security infrastructure establishing a channel between itself and the 613 SSH Transport Model of another SNMP engine. 615 Different IETF standards use security layers at the transport or 616 application layer to address security threads (e.g. TLS [RFC5246], 617 Simple Authentication and Security Layer (SASL) [RFC4422], and SSH 618 [RFC4251]). Different management interfaces, e.g. CLI, SYSLOG 619 [RFC5424] and NETCONF [RFC4741], use a secure transport layer to 620 provide secure information and message exchange to build management 621 applications. 623 Detailed description of the Transport Subsystem for SNMP and 624 Transport Security Model for SNMP can be found in [RFC5590] and 625 [RFC5591]. Secure Shell Transport Model for SNMP is specified in 626 [RFC5592] and Transport Layer Security (TLS) Transport Model for SNMP 627 is described in [RFC5953]. 629 2.1.5.2. RADIUS Authentication and Authorization with SNMP Transport 630 Models 632 [RFC5608] describes the use of a RADIUS (Remote Authentication 633 Dial-In User Service) authentication and authorization service by 634 SNMP secure Transport Models for authentication of users and 635 authorization of secure transport session creation. 637 The secure transport protocols selected for use with RADIUS and SNMP 638 need to support user authentication methods that are compatible with 639 those that exist in RADIUS. Transport Models rely upon the 640 underlying secure transport for user authentication services. The 641 SSH protocol provides a secure transport channel with support for 642 channel authentication via local accounts and integration with 643 various external authentication and authorization services such as 644 RADIUS, Kerberos, etc. SSH Server integration with RADIUS 645 traditionally uses the username and password mechanism. 647 Service authorization and access control authorization are the use 648 cases for RADIUS support of management access via SNMP. User 649 authentication needs to be done prior to each of these use cases. 650 Service authorization allows a RADIUS server to authorize an 651 authenticated principal to use SNMP, optionally over a secure 652 transport, typically using an SNMP Transport Model (see [RFC5608]). 654 Access control authorization, i.e. how RADIUS attributes and messages 655 are applied to the specific application area of SNMP Access Control 656 Models, and VACM in particular is currently being specified in the 657 Integrated Security Model for SNMP (ISMS) working group. 659 2.2. SYSLOG Protocol 661 SYSLOG is a mechanism for distribution of logging information 662 initially used on Unix systems. IETF documented the status quo of 663 the BSD SYSLOG protocol in the Informational [RFC3164]. The IETF 664 SYSLOG protocol [RFC5424] obsoletes [RFC3164] and introduces a 665 layered architecture allowing the use of any number of transport 666 protocols, including reliable transports and secure transports, for 667 transmission of SYSLOG messages. 669 The content of BSD SYSLOG messages has traditionally been 670 unstructured natural language text. This content is human-friendly, 671 but difficult for applications to parse and correlate across vendors, 672 or correlate with other event reporting such as SNMP traps. The 673 SYSLOG protocol [RFC5424] includes structured data elements to aid 674 application-parsing. 676 The SYSLOG protocol enables a machine to send system log messages 677 across networks to event message collectors. The protocol is simply 678 designed to transport and distribute these event messages. No 679 acknowledgement of the receipt is made. The SYSLOG protocol and 680 process does not require a stringent coordination between the 681 transmitters and the receivers. Indeed, the transmission of SYSLOG 682 messages may be started on a device without a receiver being 683 configured, or even actually physically present. Conversely, many 684 devices will most likely be able to receive messages without explicit 685 configuration or definitions. This simple approach aided the 686 deployment of SYSLOG. 688 BSD SYSLOG had little uniformity for the message format and the 689 content of SYSLOG messages. The IETF has standardized a new message 690 header format, including timestamp, hostname, application, and 691 message ID, to improve filtering, interoperability and correlation 692 between compliant implementations. 694 The SYSLOG protocol further introduces a mechanism for defining 695 Structured Data Elements (SDEs). The SDEs allow vendors to define 696 their own structured data elements to supplement standardized 697 elements. [RFC5675] defines a mapping from SNMP notifications to 698 SYSLOG messages and [RFC5676] defines the corresponding managed 699 objects for this purpose. [RFC5674] defines the way alarms are sent 700 in SYSLOG, which includes the mapping of ITU perceived severities 701 onto SYSLOG message fields and a number of alarm-specific definitions 702 from ITU-T X.733 and the IETF Alarm MIB. 704 [RFC5848] "Signed Syslog Messages" defines a mechanism to add origin 705 authentication, message integrity, replay resistance, message 706 sequencing, and detection of missing messages to the transmitted 707 SYSLOG messages to be used in conjunction with the SYSLOG protocol. 709 The SYSLOG protocol layered architecture provides for support of any 710 number of transport mappings. However, for interoperability 711 purposes, SYSLOG protocol implementers are required to support the 712 transmission of SYSLOG Messages over UDP as defined in [RFC5426]. 714 [RFC3195] describes mappings of the syslog protocol to TCP 715 connections, useful for reliable delivery of event messages. As such 716 the specification provides robustness and security in message 717 delivery with encryption and authentication over a connection- 718 oriented protocol that is unavailable to the usual UDP-based syslog 719 protocol. 721 IETF furthermore defined the TLS transport mapping for SYSLOG in 722 [RFC5425], which provides a secure connection for the transport of 723 SYSLOG messages and describes the security threats to SYSLOG and how 724 TLS can be used to counter such threats. Datagram Transport Layer 725 Security (DTLS) Transport Mapping for SYSLOG is defined in [RFC6012], 726 which can be used in cases where a connection-less transport is 727 desired. 729 IETF working groups are encouraged to standardize structured data 730 elements, extensible human-friendly text, and consistent facility/ 731 severity values for SYSLOG to report events specific to their 732 protocol. 734 For information on SYSLOG related MIB modules see Section 4.1. 736 2.3. IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) 737 Protocols 739 The IPFIX protocol [RFC5101], IP Flow Information eXport, is a 740 Proposed Standard, which defines a push-based data export mechanism 741 for formatting and transferring IP flow information in a compact 742 binary format from an exporter to a collector. 744 The IPFIX architecture [RFC5470] defines components involved in IP 745 flow measurement and reporting of information on IP flows, 746 particularly, a metering process generating flow records, an 747 exporting process that sends metered flow information using the IPFIX 748 protocol, and a colleting process that receives flow information as 749 IPFIX data records. 751 The IPFIX protocol and the IPFIX architecture have been specified 752 following the collected requirements in [RFC3917]. 754 IPFIX can run over different transport protocols. The IPFIX protocol 755 [RFC5101] specifies SCTP as the mandatory transport protocol to 756 implement. SCTP is used with its Partial Reliability extension (PR- 757 SCTP) specified in [RFC3758]. Optional alternatives are TCP and UDP. 758 [I-D.ietf-ipfix-export-per-sctp-stream] specifies an extension for 759 IPFIX over SCTP. 761 IPFIX transmits IP flow information in data records containing IPFIX 762 Information Elements (IEs) defined by the IPFIX information model 763 [RFC5102]. IPFIX information elements are quantities with unit and 764 semantics defined by the information model. When transmitted over 765 the IPFIX protocol, only their values need to be carried in data 766 records. This compact encoding allows efficient transport of large 767 numbers of measured flow values. Remaining redundancy in data 768 records can be further reduced by methods described in [RFC5473] (for 769 further discussion on IPFIX IEs see Section 4). 771 The IPFIX information model is extensible. New information elements 772 can be registered at IANA (see 'IPFIX Information Elements' in [IANA- 773 PROT]). IPFIX also supports the use of proprietary, i.e. enterprise- 774 specific information elements. 776 The PSAMP protocol [RFC5476] extends the IPFIX protocol by means for 777 formatting and transferring information on individual packets. 778 [RFC5475] specifies a set of sampling and filtering techniques for IP 779 packet selection and the PSAMP information model [RFC5477] provides a 780 set of basic information elements for reporting packet information 781 with the IPFIX/PSAMP protocol. 783 The IPFIX model of an IP traffic flow is uni-directional. [RFC5103] 784 adds means to IPFIX for reporting bi-directional flows, for example 785 both directions of packet flows of a TCP connection. 787 When enterprise-specific information elements are transmitted with 788 IPFIX, a collector receiving data records may not know the type of 789 received data and cannot choose the right format for storing the 790 contained information. [RFC5610] provides means for providing type 791 information of enterprise-specific information Elements from an 792 exporter to a collector. 794 Collectors may store received flow information in files. The IPFIX 795 file format [RFC5655] can be used for storing IP flow information in 796 a way that facilitates exchange of traffic flow information between 797 different systems and applications. 799 At the time of this writing a framework for IPFIX flow mediation is 800 in preparation, which addresses the need for mediation of flow 801 information in IPFIX applications in large operator networks, e.g. 802 for aggregating huge amounts of flow data and for anonymization of 803 flow information (see the problem statement in [RFC5982]). 805 The IPFIX Mediation Framework defines the intermediate device between 806 exporters and collectors, which provides an IPFIX mediation by 807 receiving a record stream from e.g. a collecting process, hosting one 808 or more intermediate processes to transform this stream, and 809 exporting the transformed record stream into IPFIX messages via an 810 exporting process [I-D.ietf-ipfix-mediators-framework]. 812 Examples for mediation functions are flow aggregation, flow selection 813 [I-D.ietf-ipfix-flow-selection-tech], and anonymization of traffic 814 information [I-D.ietf-ipfix-anon]. 816 Privacy, integrity, and authentication of exporter and collector are 817 important security requirements for IPFIX [RFC3917]. The IPFIX and 818 PSAMP protocol do not define any new security mechanisms, but rely on 819 security mechanisms of the underlying protocols, such as, for 820 example, TLS [RFC5246] and DTLS [RFC4347] [I-D.ietf-tsvwg-dtls-for- 821 sctp]. 823 Several applications such as usage-based accounting, traffic 824 profiling, traffic engineering, intrusion detection, and QoS 825 monitoring, that require flow-based traffic measurements can be 826 realized using IPFIX. 828 With further information elements, IPFIX can also be applied to 829 monitoring application-level protocols, for example, SIP [RFC3261] 830 and related media transfer protocols. Requirements to such a 831 monitoring on the application level include measuring signaling 832 quality (e.g., session request delay, session completion ratio, or 833 hops for request), media QoS (e.g., jitter, delay or bit rate), and 834 user experience (e.g., Mean Opinion Score). 836 Note that even if the initial IPFIX focus has been around IP flow 837 information exchange, non IP-related information elements are now 838 specified in IPFIX IANA registration (e.g. MAC address, MPLS labels, 839 etc.). At the time of this writing, there are requests to widen the 840 focus of IPFIX and to export also non-IP related information elements 841 (such as SIP monitoring IEs). 843 For information on IPFIX/PSAMP related data models see Section 4.1 844 and Section 4.2. 846 2.4. Network Configuration Protocol (NETCONF) 848 The IAB workshop on Network Management [RFC3535] determined advanced 849 requirements for configuration management: 851 o Robustness: Minimizing disruptions and maximizing stability, 853 o Support of task-oriented view, 855 o Extensible for new operations, 857 o Standardized error handling, 859 o Clear distinction between configuration data and operational 860 state, 862 o Distribution of configurations to devices under transactional 863 constraints, 865 o Single and multi-system transactions and scalability in the number 866 of transactions and managed devices, 868 o Operations on selected subsets of management data, 870 o Dump and reload a device configuration in a textual format in a 871 standard manner across multiple vendors and device types, 873 o Support a human interface and a programmatic interface, 874 o Data modeling language with a human friendly syntax, 876 o Easy conflict detection and configuration validation, and 878 o Secure transport, authentication, and robust access control. 880 The NETCONF protocol [RFC4741] is a Proposed Standard that provides 881 mechanisms to install, manipulate, and delete the configuration of 882 network devices and aims to address the advanced configuration 883 management requirements pointed in the IAB workshop. It uses an 884 Extensible Markup Language (XML)-based data encoding for the 885 configuration data as well as the protocol messages. The NETCONF 886 protocol operations are realized on top of a simple and reliable 887 Remote Procedure Call (RPC) layer. 889 A key aspect of NETCONF is that it allows the functionality of the 890 management protocol to closely mirror the native command line 891 interface of the device. In addition, applications can access both 892 the syntactic and semantic content of the device's native user 893 interface. 895 NETCONF working group developed the NETCONF Event Notifications 896 Mechanism as an optional capability, which provides an asynchronous 897 message notification delivery service for NETCONF [RFC5277]. NETCONF 898 notification mechanism enables using general purpose notification 899 streams, which can also transport alarms from other sources, where 900 the originator of the notification stream can be any managed device 901 (e.g. SNMP alarms). 903 NETCONF Partial Locking introduces fine-grained locking of the 904 configuration datastore to enhance NETCONF for fine-grained 905 transactions on parts of the datastore [RFC5717]. 907 NETCONF working group also defined the necessary data model to 908 monitor the NETCONF protocol by using YANG [RFC6022] (see 909 Section 4.1). 911 NETCONF working group defined SSH transport binding as the mandatory 912 secure transport of its RPC messages [RFC4742]. Other optional 913 secure transport bindings are available for TLS [RFC5539], BEEP (over 914 TLS) [RFC4744], and SOAP (over HTTP over TLS) [RFC4743]. There is an 915 implementation available using NETCONF over SOAP as a Web Service 916 [RFC5381]. 918 Currently NETCONF working group is focusing on bug fixing of the 919 NETCONF base protocol standard [I-D.draft-ietf-netconf-4741bis] and 920 the SSH transport protocol mapping [I-D.draft-ietf-netconf-4742bis] 921 as well as the specification of the NETCONF Access Control Model 922 (NACM). NACM is going to provide a secure operating environment for 923 NETCONF and proposes standard mechanisms to restrict protocol access 924 to particular users with a pre-configured subset of operations and 925 content. 927 2.4.1. YANG - NETCONF Data Modeling Language 929 Following the guideline and requests of the IAB management workshop 930 [RFC3535], the NETMOD working group developed a data modeling 931 language defining the semantics of operational and configuration 932 data, notifications, and operations [RFC6020]. The new data modeling 933 language maps directly to XML encoded content (on the wire) and will 934 serve as the normative description of NETCONF data models. 936 YANG has following properties addressing specific requirements on a 937 modeling language for configuration management: 939 o YANG provides the means to define hierarchical data models. It 940 supports reusable data types and groupings, i.e., a set of schema 941 nodes that can be reused across module boundaries. 943 o YANG supports the distinction between configuration and state 944 data. In addition, it provides support for modeling event 945 notifications and the specification of operations that extend the 946 base NETCONF operations. 948 o YANG allows to express constraints on data models by means of type 949 restrictions and XPATH 1.0 [XPATH] expressions. XPATH expressions 950 can also be used to make certain portions of a data model 951 conditional. 953 o YANG supports the integration of standard and vendor defined data 954 models. YANG's augmentation mechanism allows to seamlessly 955 augment standard data models with proprietary extensions. 957 o YANG data models can be partitioned into collections of features, 958 allowing low-end devices to only implement the core features of a 959 data model while high-end devices may choose to support all 960 features. The supported features are announced via the NETCONF 961 capability exchange to management applications. 963 o The syntax of the YANG language is compact and optimized for human 964 readers. An associated XML-based syntax called the YANG 965 Independent Notation (YIN) [RFC6020] is available to allow the 966 processing of YANG data models with XML-based tools. The mapping 967 rules for the translation of YANG data models into Document Schema 968 Definition Languages (DSDL), of which Relax NG is a major 969 component, are defined in [I-D.draft-ietf-netmod-dsdl-map]. 971 o Devices implementing standard data models can document deviations 972 from the data model in separate YANG modules. Applications 973 capable of discovering deviations can make allowances that would 974 otherwise not be possible. 976 A collection of common data types for IETF-related standards is 977 provided in [RFC6021]. This standard data type library has been 978 derived to a large extend from common SMIv2 data types, generalizing 979 them to a less constrained NETCONF framework where necessary. 981 The document "An Architecture for Network Management using NETCONF 982 and YANG" describes how NETCONF and YANG can be used to build network 983 management applications that meet the needs of network operators 984 [I-D.draft-ietf-netmod-arch]. 986 The Experimental RFC [I-D.draft-linowski-netmod-yang-abstract] 987 specifies extensions for YANG introducing language abstractions such 988 as class inheritance and recursive data structures. 990 Work is underway to standardize a translation of SMIv2 data models 991 into YANG data models, which preserves investments into SNMP MIB 992 modules, which are widely available for monitoring purposes. 994 Several independent and open source implementations of the YANG data 995 modeling language and associated tools are available. The IETF has 996 also developed guidelines [I-D.draft-ietf-netmod-yang-usage] for the 997 use of YANG within standardization organizations such as the IETF. 999 While YANG is a relatively recent language, some data models have 1000 already been produced. IPFIX working group prepared the normative 1001 model for configuring and monitoring IPFIX and PSAMP compliant 1002 monitoring devices using the YANG modeling language 1003 [I-D.draft-ietf-ipfix-configuration-model]. The specification of the 1004 base NETCONF protocol operations has been revised and uses YANG as 1005 the normative modeling language to specify its operations 1006 [I-D.draft-ietf-netconf-4741bis]. 1008 At the time of this writing NETMOD working group is developing core 1009 system and interface data models. Following the example of IPFIX 1010 configuration model, working groups at IETF will prepare models for 1011 their specific needs. 1013 3. Management Protocols and Mechanisms with specific Focus 1015 This section reviews additional protocols IETF offers for management 1016 and discusses for which applications they were designed and/or 1017 already successfully deployed. These are protocols that have mostly 1018 reached Proposed Standard status or higher within the IETF. 1020 3.1. IP Address Management with Dynamic Host Configuration Protocol 1021 (DHCP) 1023 The Draft Standard Dynamic Host Configuration Protocol (DHCP) 1024 [RFC2131] was defined as an extension to BOOTP (Bootstrap Protocol) 1025 [RFC0951]. DHCP provides a framework for passing configuration 1026 information to hosts on a TCP/IP network and enables as such auto- 1027 configuration in IP networks. In addition to IP address management, 1028 DHCP can also provide other configuration information, particularly 1029 the IP addresses of local caching DNS resolvers or servers providing 1030 servers. As described in [I-D.baker-ietf-core] DHCP can be used for 1031 IPv4 and IPv6 Address Allocation and Assignment as well as Service 1032 Discovery. 1034 There are two versions of DHCP, one for IPv4 [RFC2131] and one for 1035 IPv6 [RFC3315]. While both versions bear the same name and perform 1036 much the same purpose, the details of the protocol for IPv4 and IPv6 1037 are sufficiently different that they can be considered separate 1038 protocols. 1040 Following are examples, where DHCP options have been used to provide 1041 configuration information or access to specific servers. 1043 o [RFC3646] describes two DHCPv6 options for passing a list of 1044 available DNS recursive name servers and a domain search list to a 1045 client. 1047 o [RFC2610] describes how entities using the Service Location 1048 Protocol can find out the address of Directory Agents in order to 1049 transact messages and how the assignment of scope for 1050 configuration of SLP User and Service Agents can be achieved. 1052 o [RFC3319] specifies two DHCPv6 options that allow SIP clients to 1053 locate a local SIP server that is to be used for all outbound SIP 1054 requests, a so-called outbound proxy server. 1056 o [RFC4280] defines new options to discover the Broadcast and 1057 Multicast Service (BCMCS) controller in an IP network. 1059 3.2. IPv6 Network Operations 1061 The IPv6 Operations Working Group (v6ops) develops guidelines for the 1062 operation of a shared IPv4/IPv6 Internet and provides operational 1063 guidance on how to deploy IPv6 into existing IPv4-only networks, as 1064 well as into new network installations. 1066 o The Proposed Standard [RFC4213] specifies IPv4 compatibility 1067 mechanisms for dual stack and configured tunneling that can be 1068 implemented by IPv6 hosts and routers. Dual stack implies 1069 providing complete implementations of both IPv4 and IPv6, and 1070 configured tunneling provides a means to carry IPv6 packets over 1071 unmodified IPv4 routing infrastructures. 1073 o [RFC3574] lists different scenarios in 3GPP defined packet network 1074 that would need IPv6 and IPv4 transition, where [RFC4215] does a 1075 more detailed analysis of the transition scenarios that may come 1076 up in the deployment phase of IPv6 in 3GPP packet networks. 1078 o [RFC4029] describes and analyzes different scenarios for the 1079 introduction of IPv6 into an ISP's existing IPv4 network. 1080 [RFC5181] provides a detailed description of IPv6 deployment, 1081 integration methods and scenarios in wireless broadband access 1082 networks (802.16) in coexistence with deployed IPv4 services. 1083 [RFC4057] describes the scenarios for IPv6 deployment within 1084 enterprise networks. 1086 o [RFC4038] specifies scenarios and application aspects of IPv6 1087 transition considering how to enable IPv6 support in applications 1088 running on IPv6 hosts, and giving guidance for the development of 1089 IP version-independent applications. 1091 NOTE: Additional input needed. 1093 3.3. Policy-based Management 1095 3.3.1. IETF Policy Framework 1097 IETF specified a general policy framework [RFC2753] for managing, 1098 sharing, and reusing policies in a vendor independent, interoperable, 1099 and scalable manner. [RFC3460] specifies the Policy Core Information 1100 Model (PCIM), an object-oriented information model for representing 1101 policy information developed jointly in the IETF Policy Framework 1102 working group and as extensions to the Common Information Model (CIM) 1103 activity in the Distributed Management Task Force (DMTF) [DMTF-CIM]. 1105 The policy framework is based on a policy-based admission control 1106 specifying two main architectural elements, the Policy Enforcement 1107 Point (PEP) and the Policy Decision Point (PDP). For the purpose of 1108 network management, policies allow an operator to specify how the 1109 network is to be configured and monitored by using a descriptive 1110 language. Furthermore, it allows the automation of a number of 1111 management tasks, according to the requirements set out in the policy 1112 module. 1114 IETF Policy Framework has been accepted by the industry as a 1115 standard-based policy approach and has been adopted by different SDOs 1116 e.g. for 3GGP charging standards. 1118 3.3.2. Common Open Policy Service (COPS) and COPS Usage for Policy 1119 Provisioning (COPS-PR) 1121 [RFC3159] defines the Structure of Policy Provisioning Information 1122 (SPPI), an extension to the SMI modeling language used to write 1123 Policy Information Base (PIB) modules. COPS-PR [RFC3084] uses the 1124 Common Open Policy Service (COPS) protocol [RFC2748] for provisioning 1125 of policy information. The COPS-PR specification is independent of 1126 the type of policy being provisioned (QoS, Security, etc.) but 1127 focuses on the mechanisms and conventions used to communicate 1128 provisioned information between policy-decision-points (PDPs) and 1129 policy enforcement points (PEPs). Policy data is modeled using 1130 Policy Information Base modules (PIB modules). 1132 COPS-PR has not been widely deployed, and operators have stated that 1133 its use of binary encoding (BER) for management data makes it 1134 difficult to develop automated scripts for simple configuration 1135 management tasks in most text-based scripting languages. In the IAB 1136 Workshop on Network Management [RFC3535], the consensus of operators 1137 and protocol developers indicated a lack of interest in PIB modules 1138 for use with COPS-PR. 1140 As a result, even if COPS-PR and the Structure of Policy Provisioning 1141 Information (SPPI) were initially approved as Proposed Standards, the 1142 IESG has not approved any policy models (PIB modules) as IETF 1143 standard, and the use of COPS-PR is not recommended. 1145 3.4. IP Performance Metrics (IPPM) 1147 The IPPM working group has defined metrics for accurately measuring 1148 and reporting the quality, performance, and reliability of Internet 1149 data delivery. The metrics include connectivity, one-way delay and 1150 loss, round-trip delay and loss, delay variation, loss patterns, 1151 packet reordering, bulk transport capacity, and link bandwidth 1152 capacity. 1154 These metrics are designed for use by network operators and their 1155 customers, and provide unbiased quantitative measures of performance. 1156 The IPPM metrics have been developed inside an active measurement 1157 context, that is, the devices used to measure the metrics produce 1158 their own traffic. However, most of the metrics can be used inside a 1159 passive context as well. At the time of this writing there is no 1160 work planned in the area of passive measurement. 1162 The main properties of individual IPPM performance and reliability 1163 metrics are that the metrics should be well-defined and concrete thus 1164 implementable, and they should exhibit no bias for IP clouds 1165 implemented with identical technology. In addition, the methodology 1166 used to implement a metric should have the property of being 1167 repeatable with consistent measurements. 1169 IETF IP Performance Metrics have been introduced widely in the 1170 industry and adopted by different SDOs such as the Metro Ethernet 1171 Forum. 1173 Following are examples of essential IPPM documents published as 1174 Proposed Standard: 1176 o IPPM Framework document [RFC2330] defines a general framework for 1177 particular metrics developed by IPPM working group and defines the 1178 fundamental concepts of 'metric' and 'measurement methodology' and 1179 discusses the issue of measurement uncertainties and errors as 1180 well as introduces the notion of empirically defined metrics and 1181 how metrics can be composed. 1183 o One-way Delay Metric for IPPM [RFC2679] defines a metric for one- 1184 way delay of packets across Internet paths. It builds on notions 1185 introduced in the IPPM Framework document. 1187 o Round-trip Delay Metric for IPPM [RFC2681] defines a metric for 1188 round-trip delay of packets across network paths and follows 1189 closely the corresponding metric for One-way Delay. 1191 o IP Packet Delay Variation Metric [RFC3393] refers to a metric for 1192 variation in delay of packets across network paths and is based on 1193 the difference in the One-Way-Delay of selected packets called "IP 1194 Packet Delay Variation (ipdv)". 1196 o One-way Packet Loss Metric for IPPM [RFC2680] defines a metric for 1197 one-way packet loss across Internet paths. 1199 o One-Way Packet Duplication Metric [RFC5560] defines a metric for 1200 the case, where multiple copies of a packet are received and 1201 discusses methods to summarize the results of streams. 1203 o Packet Reordering Metrics [RFC4737] defines metrics to evaluate 1204 whether a network has maintained packet order on a packet-by- 1205 packet basis and discusses the measurement issues, including the 1206 context information required for all metrics. 1208 o IPPM Metrics for Measuring Connectivity [RFC2678] defines a series 1209 of metrics for connectivity between a pair of Internet hosts. 1211 o Framework for Metric Composition [RFC5835] describes a detailed 1212 framework for composing and aggregating metrics. 1214 Next to the metrics, two protocols to measure these metrics have been 1215 standardized: 1217 o A One-way Active Measurement Protocol (OWAMP) [RFC4656] measures 1218 unidirectional characteristics such as one-way delay and one-way 1219 loss between network devices and enables the interoperability of 1220 these measurements. 1222 o A Two-Way Active Measurement Protocol (TWAMP) [RFC5357] adds 1223 round-trip or two-way measurement capabilities to OWAMP. 1225 o [RFC3432] 'Network performance measurement with Periodic Streams' 1226 describes a periodic sampling method and relevant metrics for 1227 assessing the performance of IP networks, as an alternative to the 1228 Poisson sampling method described in [RFC2330]. 1230 For the "Information Model and XML Data Model for Traceroute 1231 Measurements [RFC5388] and [BCP108] "IP Performance Metrics (IPPM) 1232 Metrics Registry" (see Section 4.4). 1234 3.5. Remote Authentication Dial In User Service (RADIUS) 1236 RADIUS [RFC2865], the Remote Authentication Dial In User Service, is 1237 a Draft Standard that describes a client/server protocol for carrying 1238 authentication, authorization, and configuration information between 1239 a Network Access Server (NAS), which desires to authenticate its 1240 links and a shared Authentication Server. The companion document 1241 [RFC2866] 'Radius Accounting' describes a protocol for carrying 1242 accounting information between a network access server and a shared 1243 accounting server. [RFC2867] adds required new RADIUS accounting 1244 attributes and new values designed to support the provision of 1245 tunneling in dial-up networks. 1247 RADIUS protocol is widely implemented and is used in environments 1248 like enterprise networks, where a single administrative authority 1249 manages the network, and protects the privacy of user information. 1250 RADIUS also has a strong position in fixed broadband access provider 1251 networks and well as in certain cellular broadband operators' 1252 networks. 1254 RADIUS is extensible with a known limitation of maximum 255 attribute 1255 codes and 253 octets as attribute content length. RADIUS has Vendor- 1256 Specific Attributes (VSA), which have been used both for vendor- 1257 specific purposes as an addition to standardized attributes as well 1258 as to extend the limited attribute code space. IETF has been working 1259 on for a solution to extend the attribute space beyond 255 and 1260 allowing attributes longer than 253 octets. A recent proposal 1261 [I-D.dekok-radext-radius-extensions] would extend the 'conventional' 1262 attribute space up to ~1000 attributes and add another ~500 'long' 1263 attributes with a length bound by the RADIUS packet size. As side 1264 product, the attribute extension also introduces a new RADIUS 1265 attribute type Type-Length-Value (TLV) in a similar fashion as 1266 Diameter AVPs (see [RFC3588]). TLVs allow grouping and nesting of 1267 attributes in a similar way as Diameter Grouped AVPs. 1269 The RADIUS protocol uses a shared secret along with the MD5 hashing 1270 algorithm to secure passwords. Based on the known threads additional 1271 protection like IPsec tunnels are used to further protect the RADIUS 1272 traffic. However, building and administering large IPsec protected 1273 networks may become a management burden, especially when IPsec 1274 protected RADIUS infrastructure should provide inter-provider 1275 connectivity. A trend has been moving towards TLS-based security 1276 solutions and establishing dynamic trust relationships between RADIUS 1277 servers. Once TCP transport was introduced to RADIUS, it became 1278 natural to have a TLS support for RADIUS [I-D.ietf-radext-radsec]. 1279 In addition to TLS-based security for TCP transport, the UDP 1280 transport also has Datagram TLS (DTLS) based security solution 1281 [I-D.ietf-radext-dtls]. 1283 Once the 'flavors' of different RADIUS servers/proxies increase, a 1284 mechanism to discover RADIUS servers/proxies dynamically in a desired 1285 realm based on their transport and security properties becomes 1286 topical. A DNS based dynamic discovery, equivalent to DIAMETER 1287 [RFC3588], is under development [I-D.ietf-radext-dynamic-discovery]. 1288 Naturally, piggy-packing RADIUS realm information in DNS 1289 infrastructure would add a new area for general management and 1290 administration. This is specifically something new as, for example, 1291 previously RADIUS realm and realm-based routing information has been 1292 completely separate from DNS namespace. 1294 [RFC2868] 'RADIUS Attributes for Tunnel Protocol Support' defines a 1295 number of RADIUS attributes designed to support the provision 1296 compulsory of tunneling in dial-up network access. Some applications 1297 involve compulsory tunneling i.e. the tunnel is created without any 1298 action from the user and without allowing the user any choice in the 1299 matter. In order to provide this functionality, specific RADIUS 1300 attributes are needed to carry the tunneling information from the 1301 RADIUS server to the tunnel end points. RFC 3868 defines those 1302 attributes, attribute values and the required IANA registries. 1304 [RFC3162] 'RADIUS and IPv6' specifies the operation of RADIUS over 1305 IPv6 and the RADIUS attributes used to support the IPv6 network 1306 access. [RFC4818] describes how to transport delegated IPv6 prefix 1307 information over RADIUS 1309 [RFC4675] 'RADIUS Attributes for Virtual LAN and Priority Support' 1310 defines additional attributes for dynamic Virtual LAN assignment and 1311 prioritization, for use in provisioning of access to IEEE 802 local 1312 area networks usable with RADIUS and Diameter. 1314 [RFC5080] 'Common RADIUS Implementation Issues and Suggested Fixes' 1315 describes common issues seen in RADIUS implementations and suggests 1316 some fixes. Where applicable, unclear statements and errors in 1317 previous RADIUS specifications are clarified. People designing 1318 extensions to RADIUS protocol for various deployment cases should get 1319 familiar with RADIUS Design Guidelines [I-D.ietf-radext-design] in 1320 order to avoid e.g. known interoperability challenges. 1322 [RFC5090] 'RADIUS Extension for Digest Authentication' defines an 1323 extension to the RADIUS protocol to enable support of Digest 1324 Authentication, for use with HTTP-style protocols like the Session 1325 Initiation Protocol (SIP) and HTTP. 1327 [RFC5580] 'Carrying Location Objects in RADIUS and Diameter describes 1328 procedures for conveying access-network ownership and location 1329 information based on civic and geospatial location formats in RADIUS 1330 and Diameter. 1332 [RFC5607] specifies required RADIUS attributes and their values for 1333 authorizing a management access to a NAS. Both local and remote 1334 management are supported, with access rights and management 1335 privileges. Specific provisions are made for remote management via 1336 Framed Management protocols, such as SNMP and NETCONF, and for 1337 management access over a secure transport protocols. 1339 [RFC3579] describes how to use RADIUS to convey EAP payload between 1340 the authenticator and the EAP server using RADIUS. RFC3579 is widely 1341 implemented, for example, in WLAN and 802.1X environment. [RFC3580] 1342 describes how to use RADIUS with IEEE 802.1X authenticators. In the 1343 context of 802.1X and EAP-based authentication, the Vendor Specific 1344 Attributes described in [RFC2458] have been widely accepted by the 1345 industry. [RFC2869] 'RADIUS extensions' is another important RFC 1346 related to EAP use. RFC2869 describes additional attributes for 1347 carrying AAA information between a NAS and a shared Accounting Server 1348 using RADIUS. It also defines attributes to encapsulate EAP message 1349 payload. 1351 There are an extensive number of MIB modules defined for multiple 1352 purposes to use with RADIUS (see Section 4.3 and Section 4.5 ). 1354 RADIUS is catching up DIAMETER (see [RFC3588]) functionality wise. 1356 However, it should be noted that newly introduced features such as 1357 TCP-based transport, extended attributes or new security features are 1358 not yet widely implemented, and are unlikely to be upgraded to the 1359 deployed legacy in a near future. 1361 3.6. Diameter Base Protocol (DIAMETER) 1363 DIAMETER [RFC3588] is a Proposed Standard that provides an 1364 Authentication, Authorization and Accounting (AAA) framework for 1365 applications such as network access or IP mobility. DIAMETER is also 1366 intended to work in local Authentication, Authorization, Accounting 1367 situations and in roaming situations. DIAMETER is not directly 1368 backwards compatible, but provides an upgrade path for RADIUS. 1370 DIAMETER is designed to resolve a number of known problems with 1371 RADIUS. DIAMETER supports server failover, reliable transport over 1372 TCP and SCTP, well documented functions for proxy, redirect and relay 1373 agent functions, server-initiated messages, auditability, and 1374 capability negotiation. DIAMETER also provides a larger attribute 1375 space for Attribute-Value Pairs (AVPs) and identifiers than RADIUS. 1376 DIAMETER features make it especially appropriate for environments, 1377 where the providers of services are in different administrative 1378 domains than the maintainer (protector) of confidential user 1379 information. 1381 Other important differences to RADIUS (as defined in [RFC2865]) are: 1383 o Use of reliable transport protocols (TCP or SCTP, not UDP), 1385 o Network and transport layer security (IPsec or TLS), 1387 o Stateful and stateless models, 1389 o Dynamic discovery of peers (using DNS SRV and NAPTR), 1391 o Concept of an application that describes how a specific set of 1392 commands and Attribute-Value Pairs (AVPs) are treated by DIAMETER 1393 nodes. Each application has an IANA assigned unique identifier, 1395 o Supports application layer acknowledgements, defines failover 1396 methods and state machines [RFC3539] ??? , 1398 o Error notification, 1400 o Better roaming support, 1402 o Easier to extend, and 1403 o Basic support for user-sessions and accounting. 1405 The protocol is designed to be extensible to support e.g. proxies, 1406 brokers, mobility and roaming, Network Access Servers (NASREQ), and 1407 Accounting and Resource Management. DIAMETER applications extend the 1408 DIAMETER base protocol by adding new commands and/or attributes. 1409 Each application is defined by an unique IANA assigned application 1410 identifier and can add new command codes and/or new mandatory AVPs. 1412 The DIAMETER application identifier space has been divided into 1413 Standards Track and First Come First Served vendor-specific 1414 applications. Following are the current Standards Track, IETF 1415 defined, DIAMETER applications: 1417 o Diameter Base Protocol Application [RFC3588], 1419 o Diameter Base Accounting Application [RFC3588], 1421 o Diameter Mobile IPv4 Application [RFC4004], 1423 o Diameter Network Access Server Application (NASREQ, [RFC4005]), 1425 o Diameter Extensible Authentication Protocol Application [RFC4072], 1427 o Diameter Credit-Control Application [RFC4006], 1429 o Diameter Session Initiation Protocol Application [RFC4740], and 1431 o Diameter Quality-of-Service Application [RFC5866]. 1433 o Diameter Mobile IPv6 IKE (MIP6I) Application [RFC5778]. 1435 o Diameter Mobile IPv6 Auth (MIP6A) Application [RFC5778]. 1437 o Diameter Relay Agent Application [RFC3588]. 1439 The large majority of DIAMETER applications are vendor-specific and 1440 mainly used in various Standards Development Organizations (SDO) 1441 outside IETF. One example of an important SDO extensively using 1442 DIAMETER is 3GPP. For example the whole 3GPP IP Multimedia Subsystem 1443 (IMS) uses DIAMETER based interfaces (e.g. Cx) [3GPPIMS]. Recently, 1444 during the standardization of the 3GPP Evolved Packet Core, DIAMETER 1445 was chosen as the only AAA signaling protocol. 1447 One part of the DIAMETER extensibility mechanism is an easy and 1448 consistent way of creating new commands for applications need. 1449 RFC3588 proposes 'IETF Consensus' as the IANA policy for the DIAMETER 1450 command code allocations, which requires an RFC to pass through the 1451 IETF publication process. This policy decision caused undesired use 1452 and redefinition of existing Commands Codes within SDOs. Secondly, 1453 diverse RFCs have been published as simple command code allocations 1454 for other SDO purposes (see [RFC3589], [RFC5224], [RFC5431] and 1455 [RFC5516]). Later, the Command Code IANA policy has been changed in 1456 [RFC5719], which added a range for vendor-specific Command Codes with 1457 a First Come First Served policy. 1459 The implementation and deployment experience of DIAMETER has led to 1460 the development of an update of the Base protocol (RFC3588bis) 1461 [I-D.ietf-dime-rfc3588bis]. One of the major changes is making 1462 transport layer security (TLS) as the preferred security mechanism 1463 and deprecating the in-band security negotiation for TLS. 1465 Some DIAMETER extensions and clarifications that logically would fit 1466 better into RFC3588bis are also needed on the existing RFC3588 based 1467 deployments. Therefore, some extensions specifically usable in large 1468 inter-provider roaming network settlements are made available for 1469 both RFC3588 (updates) and RFC3588bis (part of the document set): 1471 o 'Clarifications on the Routing of Diameter Requests Based on the 1472 Username and the Realm' [RFC5729] defines the behavior required 1473 for DIAMETER agents to route requests when the User-Name AVP 1474 contains a Network Access Identifier formatted with multiple 1475 realms. These multi-realm Network Access Identifiers are used in 1476 order to force the routing of request messages through a 1477 predefined list of mediating realms. 1479 o 'Diameter Extended NAPTR' [I-D.ietf-dime-extended-naptr] describes 1480 an improved DNS-based dynamic DIAMETER Agent discovery mechanism. 1481 Using an extended format for the Straightforward-NAPTR (S-NAPTR) 1482 Application Service Tag allows a DNS-based discovery of DIAMETER 1483 agents of the supported applications without doing DIAMETER 1484 capability exchange beforehand with a number of agents. 1486 Experience has shown, that it is hard for IETF to develop DIAMETER 1487 applications that actually get adopted and deployed by other SDOs. 1488 As a result, there has been a growing number of IETF defined DIAMETER 1489 framework documents that basically are just a collection of AVPs for 1490 a specific purpose or system architecture with semantical AVP 1491 descriptions and logic for "imaginary" applications. It is not 1492 entirely clear whether such practice is worthwhile in the long run. 1493 From IETF point of view, this practice allows the development of 1494 larger 'system architecture' documents that do not need to reference 1495 AVPs or application logic outside IETF. Below are examples of few 1496 recent AVP and framework documents: 1498 o 'Diameter Mobile IPv6: Support for Network Access Server to 1499 Diameter Server Interaction' [RFC5447] describes the bootstrapping 1500 of the Mobile IPv6 framework and the support of interworking with 1501 existing Authentication, Authorization, and Accounting (AAA) 1502 infrastructures by using the DIAMETER Network Access Server to 1503 home AAA server interface. 1505 o 'Traffic Classification and Quality of Service (QoS) Attributes 1506 for Diameter' [RFC5777] defines a number of DIAMETER AVPs for 1507 traffic classification with actions for filtering and Quality of 1508 Service (QoS) treatment. 1510 o 'Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local 1511 Mobility Anchor Interaction with Diameter Server' [RFC5779] 1512 defines AAA interactions between Proxy Mobile IPv6 (PMIPv6) 1513 entities (both Mobile Access Gateway and Local Mobility Anchor) 1514 and a AAA server within a PMIPv6 Domain. These AAA interactions 1515 are primarily used to download and update mobile node specific 1516 policy profile information between PMIPv6 entities and a remote 1517 policy store. 1519 For information on DIAMETER related MIB modules see Section 4.5. 1521 3.7. Control And Provisioning of Wireless Access Points (CAPWAP) 1523 Wireless LAN product architectures have evolved from single 1524 autonomous access points to systems consisting of a centralized 1525 Access Controller (AC) and Wireless Termination Points (WTPs). The 1526 general goal of centralized control architectures is to move access 1527 control, including user authentication and authorization, mobility 1528 management, and radio management from the single access point to a 1529 centralized controller. 1531 Based on the CAPWAP Architecture Taxonomy work [RFC4118] CAPWAP 1532 working group developed the CAPWAP protocol to facilitate control, 1533 management and provisioning of WLAN Termination Points (WTPs) 1534 specifying the services, functions and resources relating to 802.11 1535 WLAN Termination Points in order to allow for interoperable 1536 implementations of WTPs and ACs. The protocol defines the CAPWAP 1537 control plane including the primitives to control data access. The 1538 protocol document also specifies how configuration management of WTPs 1539 can be done and defines CAPWAP operations responsible for debugging, 1540 gathering statistics, logging, and firmware management as well as 1541 discusses operational and transport considerations. 1543 CAPWAP protocol is prepared to be independent of Layer 2 1544 technologies, and meets the objectives in "Objectives for Control and 1545 Provisioning of Wireless Access Points (CAPWAP)" [RFC4564]. Separate 1546 binding extensions enable the use with additional wireless 1547 technologies. [RFC5416] defines CAPWAP Protocol Binding for IEEE 1548 802.11. 1550 For information on CAPWAP related MIB modules see Section 4.2. 1552 3.8. Access Node Control Protocol (ANCP) 1554 The Access Node Control Protocol (ANCP) [I-D.ietf-ancp-protocol] 1555 realizes a control plane between a service-oriented layer 3 edge 1556 device (the Network Access Server, NAS) and a layer 2 Access Node 1557 (e.g., Digital Subscriber Line Access Module, DSLAM). As such ANCP 1558 operates in a multi-service reference architecture and communicates 1559 QoS-, service- and subscriber-related configurations and operations 1560 between a NAS and an Access Node. 1562 The main goal of this protocol is to configure and manage access 1563 equipments and allow them to report information to the NAS in order 1564 to enable and optimize configuration. 1566 Framework and Requirements for an Access Node Control Mechanism and 1567 the use cases for ANCP are documented in [RFC5851]. Security Threats 1568 and Security Requirements for ANCP are discussed in [RFC5713]. 1570 3.9. Ad-Hoc Network Autoconfiguration 1572 Ad-hoc nodes need to configure their network interfaces with locally 1573 unique addresses as well as globally routable IPv6 addresses, in 1574 order to communicate with devices on the Internet. AUTOCONF working 1575 group developed [RFC5889], which describes the addressing model for 1576 ad-hoc networks and how nodes in these networks configure their 1577 addresses. 1579 The ad-hoc nodes under consideration are expected to be able to 1580 support multi-hop communication by running MANET routing protocols as 1581 developed by the IETF MANET working group. 1583 From the IP layer perspective, an ad hoc network presents itself as a 1584 layer 3 multi-hop network formed over a collection of links. The 1585 addressing model aims to avoid problems for ad-hoc-unaware parts of 1586 the system, such as standard applications running on an ad-hoc node 1587 or regular Internet nodes attached to the ad-hoc nodes. 1589 3.10. Application Configuration Access Protocol (ACAP) 1591 The Application Configuration Access Protocol (ACAP) [RFC2244] is a 1592 Proposed Standard protocol designed to support remote storage and 1593 access of program option, configuration and preference information. 1595 The data store model is designed to allow a client relatively simple 1596 access to interesting data, to allow new information to be easily 1597 added without server re-configuration, and to promote the use of both 1598 standardized data and custom or proprietary data. Key features 1599 include "inheritance" which can be used to manage default values for 1600 configuration settings and access control lists which allow 1601 interesting personal information to be shared and group information 1602 to be restricted. 1604 ACAP's primary purpose is to allow users access to their 1605 configuration data from multiple network-connected computers. Users 1606 can then use any network-connected computer, run any ACAP-enabled 1607 application and have access to their own configuration data. To 1608 enable wide usage client simplicity has been preferred to server or 1609 protocol simplicity whenever reasonable. 1611 3.11. XML Configuration Access Protocol (XCAP) 1613 The Extensible Markup Language (XML) Configuration Access Protocol 1614 (XCAP) [RFC4825] is a Proposed Standard protocol that allows a client 1615 to read, write, and modify application configuration data stored in 1616 XML format on a server. 1618 XCAP is a protocol that can be used to manipulate per-user data. 1619 XCAP is a set of conventions for mapping XML documents and document 1620 components into HTTP URIs, rules for how the modification of one 1621 resource affects another, data validation constraints, and 1622 authorization policies associated with access to those resources. 1623 Because of this structure, normal HTTP primitives can be used to 1624 manipulate the data. XCAP is meant to support the configuration 1625 needs for a multiplicity of applications, rather than just a single 1626 one. 1628 3.12. Extensible Provision Protocol (EPP) 1630 The Extensible Provision Protocol [RFC5730] is a Full Standard 1631 [STD69] that describes an application layer client-server protocol 1632 for the provisioning and management of objects stored in a shared 1633 central repository. EPP permits multiple service providers to 1634 perform object provisioning operations using a shared central object 1635 repository, and addresses the requirements for a generic registry 1636 registrar protocol. 1638 EPP is specified in XML and defines generic object management 1639 operations and an extensible framework that maps protocol operations 1640 to objects. EPP is a stateful XML protocol that can be layered over 1641 multiple transport protocols. Protected using lower-layer security 1642 protocols, clients exchange identification, authentication, and 1643 option information, and then engage in a series of client-initiated 1644 command-response exchanges. 1646 EPP has been adopted by numerous domain name registries mainly for 1647 the communication between domain name registries and domain name 1648 registrars and for allocating objects within registries over the 1649 Internet. 1651 4. Proposed, Draft and Standard Level Data Models 1653 This section lists management data models standardized at IETF, which 1654 can be reused and applied to different solutions. The different data 1655 models covered in this section are MIB modules, IPFIX Information 1656 Elements, Syslog Structured Data Elements, and YANG modules. 1658 Management data models have a slightly different interpretation for 1659 interoperability. This is discussed in detail in [BCP27] 1660 "Advancement of MIB specifications on the IETF Standards Track" 1661 [RFC2438] with special considerations about the advancement process 1662 for management data models. However most IETF management data models 1663 never advance beyond Proposed Standard. 1665 This section discusses management data models that have reached 1666 Proposed Standard status at the IETF. In exceptional cases important 1667 Informational RFCs are referred. 1669 4.1. Fault Management 1671 Draft Standards: 1673 [RFC3418], part of SNMPv3 standard [STD62], contains objects in the 1674 system group that are often polled to determine if a device is still 1675 operating, and sysUpTime can be used to detect if a system has 1676 rebooted, and counters have been reinitialized. 1678 [RFC3413], part of SNMPv3 standard [STD62], includes objects designed 1679 for managing notifications, including tables for addressing, retry 1680 parameters, security, lists of targets for notifications, and user 1681 customization filters. 1683 An RMON monitor [RFC2819] can be configured to recognize conditions, 1684 most notably error conditions, and continuously to check for them. 1685 When one of these conditions occurs, the event may be logged, and 1686 management stations may be notified in a number of ways (for further 1687 discussion on RMON see Section 4.4). 1689 Proposed Standards: 1691 DISMAN-EVENT-MIB in [RFC2981] and DISMAN-EXPRESSION-MIB in [RFC2982] 1692 provide a superset of the capabilities of the RMON alarm and event 1693 groups. These modules provide mechanisms for thresholding and 1694 reporting anomalous events to management applications. 1696 The ALARM MIB in [RFC3877] and the Alarm Reporting Control MIB in 1697 [RFC3878] specify mechanisms for expressing state transition models 1698 for persistent problem states. 1700 ALARM MIB defines: 1701 - a mechanism for expressing state transition models for persistent 1702 problem states, 1703 - a mechanism to correlate a notification with subsequent state 1704 transition notifications about the same entity/object, and 1705 - a generic alarm reporting mechanism (extends ITU-T work X.733 [ITU- 1706 X733). 1708 [RFC3878] in particular defines objects for controlling the reporting 1709 of alarm conditions and extends ITU-T work M.3100 Amendment 3 [ITU- 1710 M3100]. 1712 Other MIB modules that may be applied to fault management with SNMP 1713 include: 1715 o NOTIFICATION-LOG-MIB [RFC3014] describes managed objects used for 1716 logging SNMP Notifications. 1718 o ENTITY-STATE-MIB [RFC4268] describes extensions to the Entity MIB 1719 to provide information about the state of physical entities. 1721 o ENTITY-SENSOR-MIB [RFC3433] describes managed objects for 1722 extending the Entity MIB to provide generalized access to 1723 information related to physical sensors, which are often found in 1724 networking equipment (such as chassis temperature, fan RPM, power 1725 supply voltage). 1727 The SYSLOG protocol document defines an initial set of Structured 1728 Data Elements (SDEs) that relate to content time quality, content 1729 origin, and meta-information about the message, such as language. 1730 Proprietary SDEs can be used to supplement the IETF-defined SDEs. 1732 The IETF has standardized MIB Textual-Conventions for facility and 1733 severity labels and codes to encourage consistency between SYSLOG and 1734 MIB representations of these event properties [RFC5427]. The intent 1735 is that these textual conventions will be imported and used in MIB 1736 modules that would otherwise define their own representations. 1738 An IPFIX MIB module [RFC5815] has been defined for monitoring IPFIX 1739 meters, exporters and collectors (see Section 2.3). The PSAMP MIB 1740 module (work ongoing) extends the IPFIX MIB modules by managed 1741 objects for monitoring PSAMP implementations. 1743 NETCONF working group defined the necessary data model to monitor the 1744 NETCONF protocol with the modeling language YANG [RFC6022]. The 1745 monitoring data model includes information about NETCONF datastores, 1746 sessions, locks, and statistics, which facilitate the management of a 1747 NETCONF server. NETCONF monitoring RFC also defines methods for 1748 NETCONF clients to discover the data models supported by a NETCONF 1749 server and defines the operation to retrieve them. 1751 4.2. Configuration Management 1753 It is expected that standard XML-based data models will be developed 1754 for use with NETCONF, and working groups might identify specific 1755 NETCONF data models that would be applicable to the new protocol. 1757 MIB modules for monitoring of network configuration (e.g. for 1758 physical and logical network topologies) already exist and provide 1759 some of the desired capabilities. New MIB modules might be developed 1760 for the target functionality to allow operators to monitor and modify 1761 the operational parameters, such as timer granularity, event 1762 reporting thresholds, target addresses, and so on. 1764 Draft standards: 1766 [RFC3418] contains objects in the system group useful e.g. for 1767 identifying the type of device, the location of the device, the 1768 person responsible for the device. [RFC3413], part of STD 62 SNMPv3, 1769 includes objects designed for configuring notification destinations, 1770 and for configuring proxy- forwarding SNMP agents, which can be used 1771 to forward messages through firewalls and NAT devices. 1773 The Interfaces MIB [RFC2863] is used for managing Network Interfaces. 1774 This includes the 'interfaces' group of MIB-II and discusses the 1775 experience gained from the definition of numerous media-specific MIB 1776 modules for use in conjunction with the 'interfaces' group for 1777 managing various sub-layers beneath the internetwork-layer. 1779 Proposed standards: 1781 The Entity MIB [RFC4133] is used for managing multiple logical and 1782 physical entities managed by a single SNMP agent. This module 1783 provides a useful mechanism for identifying the entities comprising a 1784 system. There are also event notifications defined for configuration 1785 changes that may be useful to management applications. 1787 [RFC3165] supports the use of user-written scripts to delegate 1788 management functionality. 1790 Policy Based Management MIB [RFC4011] defines objects that enable 1791 policy-based monitoring using SNMP, using a scripting language, and a 1792 script execution environment. 1794 Few vendors have implemented MIB modules that support scripting. 1795 Some vendors consider running user-developed scripts within the 1796 managed device as a violation of support agreements. 1798 At the time of this writing, only the YANG module for the monitoring 1799 of the NETCONF protocol exists as proposed standard [RFC6022]. 1801 For configuring IPFIX and PSMAP devices, the IPFIX working group has 1802 developed an XML-based configuration data model [I-D.ietf-ipfix- 1803 configuration-model], in close collaboration with the NETMOD working 1804 group. IPFIX configuration data model uses YANG as modeling language 1805 (see Section 2.4.1). The model specifies the necessary data for 1806 configuring and monitoring selection processes, caches, exporting 1807 processes, and collecting processes of IPFIX and PSAMP compliant 1808 monitoring devices. 1810 Non-standard data models: 1812 CAPWAP Base MIB [RFC5833] specifies managed objects for modeling the 1813 CAPWAP Protocol and provides configuration and WTP status-monitoring 1814 aspects of CAPWAP, where CAPWAP Binding MIB [RFC5834] defines managed 1815 objects for modeling of CAPWAP protocol for IEEE 802.11 wireless 1816 binding. 1817 Note: RFC 5833 and RFC 5834 have been published as Informational RFCs 1818 to provide the basis for future work on a SNMP management of the 1819 CAPWAP protocol. 1821 At the time of this writing NETMOD working group is developing core 1822 system and interface models in YANG. 1824 4.3. Accounting Management 1826 Non-standard data models: 1828 [RFC4670] 'RADIUS Accounting Client MIB for IPv6' defines RADIUS 1829 Accounting Client MIB objects that support version-neutral IP 1830 addressing formats. 1832 [RFC4671] 'RADIUS Accounting Server MIB for IPv6' defines RADIUS 1833 Accounting Server MIB objects that support version-neutral IP 1834 addressing formats. 1836 4.4. Performance Management 1838 MIB modules typically contain counters to determine the frequency and 1839 rate of an occurrence. 1841 RMON [RFC2819] has the full standard status [STD59] and defines 1842 objects for managing remote network monitoring devices. An 1843 organization may employ many remote management probes, one per 1844 network segment, to manage its internet. These devices may be used 1845 for a network management service provider to access a client network, 1846 often geographically remote. Most of the objects in the RMON MIB 1847 module are suitable for the management of any type of network, where 1848 some of them are specific to management of Ethernet networks. 1850 RMON allows a probe to be configured to perform diagnostics and to 1851 collect statistics continuously, even when communication with the 1852 management station may not be possible or efficient. The alarm group 1853 periodically takes statistical samples from variables in the probe 1854 and compares them to previously configured thresholds. If the 1855 monitored variable crosses a threshold, an event is generated. 1857 The RMON host group discovers hosts on the network by keeping a list 1858 of source and destination MAC Addresses seen in good packets 1859 promiscuously received from the network, and contains statistics 1860 associated with each host. The hostTopN group is used to prepare 1861 reports that describe the hosts that top a list ordered by one of 1862 their statistics. The available statistics are samples of one of 1863 their base statistics over an interval specified by the management 1864 station. Thus, these statistics are rate based. The management 1865 station also selects how many such hosts are reported. 1867 The RMON matrix group stores statistics for conversations between 1868 sets of two addresses. The filter group allows packets to be matched 1869 by a filter equation. These matched packets form a data stream that 1870 may be captured or may generate events. The Packet Capture group 1871 allows packets to be captured after they flow through a channel. The 1872 event group controls the generation and notification of events from 1873 this device. 1875 Draft standards: 1877 The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up 1878 to the application layer. The SMON MIB [RFC2613] extends RMON by 1879 providing RMON analysis for switched networks. 1881 Proposed standards: 1883 RMON MIB Extensions for High Capacity Alarms [RFC3434] describes 1884 managed objects for extending the alarm thresholding capabilities 1885 found in the RMON MIB and provides similar threshold monitoring of 1886 objects based on the Counter64 data type. 1888 RMON MIB Extensions for High Capacity Networks [RFC3273] defines 1889 objects for managing RMON devices for use on high-speed networks. 1891 RMON MIB Extensions for Interface Parameters Monitoring [RFC3144] 1892 describes an extension to the RMON MIB with a method of sorting the 1893 interfaces of a monitored device according to values of parameters 1894 specific to this interface. 1896 [RFC4710] describes Real-Time Application Quality of Service 1897 Monitoring. RAQMON is part of the RMON protocol family, and supports 1898 end-2-end QoS monitoring for multiple concurrent applications and 1899 does not relate to a specific application transport. RAQMON is 1900 scalable and works well with encrypted payload and signaling. RAQMON 1901 uses TCP to transport RAQMON PDUs. 1903 [RFC4711] proposes an extension to the Remote Monitoring MIB 1904 [RFC2819] and describes managed objects used for real-time 1905 application Quality of Service (QoS) monitoring. [RFC4712] specifies 1906 two transport mappings for the RAQMON information model using TCP as 1907 a native transport and SNMP to carry the RAQMON information from a 1908 RAQMON Data Source (RDS) to a RAQMON Report Collector (RRC). 1910 Application Performance Measurement MIB [RFC3729] uses the 1911 architecture created in the RMON MIB and defines objects by providing 1912 measurement and analysis of the application performance as 1913 experienced by end-users. Application performance measurement 1914 measures the quality of service delivered to end-users by 1915 applications. 1917 Transport Performance Metrics MIB [RFC4150] describes managed objects 1918 used for monitoring selectable performance metrics and statistics 1919 derived from the monitoring of network packets and sub-application 1920 level transactions. The metrics can be defined through reference to 1921 existing IETF, ITU, and other standards organizations' documents. 1923 IPPM working group defined an Information Model and XML Data Model 1924 for Traceroute Measurements [RFC5388], which defines a common 1925 information model dividing the information elements into two 1926 semantically separated groups (configuration elements and results 1927 elements) with an additional element to relate configuration elements 1928 and results elements by means of a common unique identifier. Based 1929 on the information model, an XML data model is provided to store the 1930 results of traceroute measurements. 1932 IPPM working group has defined [BCP108] "IP Performance Metrics 1933 (IPPM) Metrics Registry", which defines a registry for IP Performance 1934 Metrics [RFC4148]. The IANA-assigned registry contains an initial 1935 set of OBJECT IDENTITIES to currently defined metrics in the IETF as 1936 well as defines the rules for adding IP Performance Metrics that are 1937 defined in the future. However, the current registry structure has 1938 been found to be insufficiently detailed to uniquely identify IPPM 1939 metrics. Due to the ambiguities between the current metrics 1940 registrations and the metrics used, and the apparent non-adoption of 1941 the registry in practice, it has been proposed to reclassify 1942 [RFC4148] as Obsolete and to withdraw the current IPPM Metrics 1943 Registry from use. 1945 Note: In case [RFC4148] is declared as Obsolete, IANA will prevent 1946 registering new metrics and actual users can continue to use the 1947 current registry and its contents. 1949 SIP Package for Voice Quality Reporting [RFC6035] defines a SIP event 1950 package that enables the collection and reporting of metrics that 1951 measure the quality for Voice over Internet Protocol (VoIP) sessions. 1953 Traffic Flow Measurement: Meter MIB [RFC2720] defines a MIB for use 1954 in controlling an RTFM Traffic Meter, in particular for specifying 1955 the flows to be measured and provides a mechanism for retrieving flow 1956 data from the meter using SNMP. 1958 4.5. Security Management 1960 Proposed standards: 1962 There are an extensive number of MIB modules defined for multiple 1963 purposes to use with RADIUS: 1965 o [RFC4668] 'RADIUS Authentication Client MIB for IPv6' defines 1966 RADIUS Authentication Client MIB objects that support version- 1967 neutral IP addressing formats and defines a set of extensions for 1968 RADIUS authentication client functions. 1970 o [RFC4669] 'RADIUS Authentication Server MIB for IPv6' defines 1971 RADIUS Authentication Server MIB objects that support version- 1972 neutral IP addressing formats and defines a set of extensions for 1973 RADIUS authentication server functions. 1975 o [RFC4670] 'RADIUS Accounting Client MIB for IPv6' defines RADIUS 1976 Accounting Client MIB that objects that support version-neutral IP 1977 addressing formats. 1979 o [RFC4671] 'RADIUS Accounting Server MIB for IPv6' defines RADIUS 1980 Accounting Server MIB that objects that support version-neutral IP 1981 addressing formats. 1983 o [RFC4672] 'RADIUS Dynamic Authorization Client MIB' defines the 1984 MIB module for entities implementing the client side of the 1985 Dynamic Authorization Extensions to RADIUS [RFC5176]. 1987 o [RFC4673] 'RADIUS Dynamic Authorization Server MIB' defines the 1988 MIB module for entities implementing the server side of the 1989 Dynamic Authorization Extensions to RADIUS [RFC5176]. 1991 The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670], 1992 [RFC4671], [RFC4672], [RFC4673] are intended to be used only for 1993 RADIUS over UDP and therefore do not support RADIUS/TCP. There is 1994 also a recommendation that RADIUS clients and servers implementing 1995 RADIUS/TCP should not re-use earlier listed MIB modules to perform 1996 statistics counting for RADIUS/TCP connections. 1998 Currently there are no standardized MIB modules for DIAMETER 1999 applications, which can be considered as a weakness on the management 2000 side of DIAMETER nodes. There is an ongoing effort to produce a 2001 standard MIB for the [RFC3588] defined 'Diameter Base Protocol' 2002 [I-D.ietf-dime-diameter-base-protocol-mib] and the [RFC4006] defined 2003 'Diameter Credit-Control Application' [I-D.ietf-dime-diameter-cc- 2004 appl-mib]. 2006 5. IANA Considerations 2008 This document does not introduce any new codepoints or name spaces 2009 for registration with IANA. 2011 Note to RFC Editor: this section may be removed on publication as an 2012 RFC. 2014 6. Security Considerations 2016 This document introduces no new security concerns. 2018 7. Contributors 2020 Following persons made significant contributions to this document: 2022 o Benoit Claise - Cisco - edited parts of the section on IPFIX/PSAMP 2023 and contributed the section on Energy Management. 2025 o Dave Harrington - Huawei - edited the expired document 2026 'draft-ietf-opsawg-survey-management-00.txt', which has been used 2027 as a starting point for this document. 2029 o Jouni Korhonen - Nokia Siemens Networks - contributed the sections 2030 on RADIUS and DIAMETER. 2032 o Al Morton - AT&T - contributed to the section on IP Performance 2033 Metrics. 2035 o Juergen Quittek - NEC - contributed the section on IPFIX/PSAMP. 2037 o Juergen Schoenwaelder - Jacobs University Bremen - contributed the 2038 section on YANG. 2040 8. Acknowledgements 2042 The editor would like to thank to Tom Petch, Dan Romascanu and Henk 2043 Uijterwaal for their valuable suggestions and comments in the OPSAWG 2044 session and on its maillist. 2046 9. Informative References 2048 [3GPPIMS] 3GPP, "Release 10, IP Multimedia Subsystem (IMS); Stage 2049 2", September 2010, 2050 . 2052 [BCP108] Emile, S., "IP Performance Metrics (IPPM) Metrics 2053 Registry", August 2005. 2055 [BCP27] D. O'Dell, M., "Advancement of MIB specifications on the 2056 IETF Standards Track", October 1998. 2058 [BCP74] Frye, R., "Coexistence between Version 1, Version 2, and 2059 Version 3 of the Internet-standard Network Management 2060 Framework", August 2003. 2062 [DMTF-CIM] DMTF, "Common Information Model Schema, Version 2.27.0", 2063 November 2010, . 2065 [IANA-PROT] Internet Assigned Numbers Authority, "IANA Protocol 2066 Registries", October 2010, 2067 . 2069 [IETF-WGS] IETF, "IETF Working Groups", 2070 . 2072 [ITU-M3100] International Telecommunication Union, "M.3100: Generic 2073 network information model", January 2006, 2074 . 2076 [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, 2077 September 1985. 2079 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 2080 "Simple Network Management Protocol (SNMP)", STD 15, 2081 RFC 1157, May 1990. 2083 [RFC1901] Case, J., McCloghrie, K., McCloghrie, K., Rose, M., and 2084 S. Waldbusser, "Introduction to Community-based SNMPv2", 2085 RFC 1901, January 1996. 2087 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2088 3", BCP 9, RFC 2026, October 1996. 2090 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2091 RFC 2131, March 1997. 2093 [RFC2244] Newman, C. and J. Myers, "ACAP -- Application 2094 Configuration Access Protocol", RFC 2244, November 1997. 2096 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2097 "Framework for IP Performance Metrics", RFC 2330, 2098 May 1998. 2100 [RFC2438] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner, 2101 "Advancement of MIB specifications on the IETF Standards 2102 Track", BCP 27, RFC 2438, October 1998. 2104 [RFC2458] Lu, H., Krishnaswamy, M., Conroy, L., Bellovin, S., 2105 Burg, F., DeSimone, A., Tewani, K., Davidson, P., 2106 Schulzrinne, H., and K. Vishwanathan, "Toward the PSTN/ 2107 Internet Inter-Networking --Pre-PINT Implementations", 2108 RFC 2458, November 1998. 2110 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2111 Schoenwaelder, Ed., "Structure of Management Information 2112 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2114 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2115 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 2116 STD 58, RFC 2579, April 1999. 2118 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 2119 "Conformance Statements for SMIv2", STD 58, RFC 2580, 2120 April 1999. 2122 [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service 2123 Location Protocol", RFC 2610, June 1999. 2125 [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. 2126 Waldbusser, "Remote Network Monitoring MIB Extensions 2127 for Switched Networks Version 1.0", RFC 2613, June 1999. 2129 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 2130 Connectivity", RFC 2678, September 1999. 2132 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2133 Delay Metric for IPPM", RFC 2679, September 1999. 2135 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2136 Packet Loss Metric for IPPM", RFC 2680, September 1999. 2138 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round- 2139 trip Delay Metric for IPPM", RFC 2681, September 1999. 2141 [RFC2720] Brownlee, N., "Traffic Flow Measurement: Meter MIB", 2142 RFC 2720, October 1999. 2144 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R., 2145 and A. Sastry, "The COPS (Common Open Policy Service) 2146 Protocol", RFC 2748, January 2000. 2148 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A 2149 Framework for Policy-based Admission Control", RFC 2753, 2150 January 2000. 2152 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 2153 Information Base", STD 59, RFC 2819, May 2000. 2155 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 2156 MIB", RFC 2863, June 2000. 2158 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2159 "Remote Authentication Dial In User Service (RADIUS)", 2160 RFC 2865, June 2000. 2162 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 2164 [RFC2867] Zorn, G., Aboba, B., and D. Mitton, "RADIUS Accounting 2165 Modifications for Tunnel Protocol Support", RFC 2867, 2166 June 2000. 2168 [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, 2169 M., and I. Goyret, "RADIUS Attributes for Tunnel 2170 Protocol Support", RFC 2868, June 2000. 2172 [RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS 2173 Extensions", RFC 2869, June 2000. 2175 [RFC2981] Kavasseri, R., "Event MIB", RFC 2981, October 2000. 2177 [RFC2982] Kavasseri, R., "Distributed Management Expression MIB", 2178 RFC 2982, October 2000. 2180 [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, 2181 November 2000. 2183 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 2184 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 2185 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 2186 RFC 3084, March 2001. 2188 [RFC3144] Romascanu, D., "Remote Monitoring MIB Extensions for 2189 Interface Parameters Monitoring", RFC 3144, August 2001. 2191 [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, 2192 S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure 2193 of Policy Provisioning Information (SPPI)", RFC 3159, 2194 August 2001. 2196 [RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", 2197 RFC 3162, August 2001. 2199 [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, 2200 August 2001. 2202 [RFC3165] Levi, D. and J. Schoenwaelder, "Definitions of Managed 2203 Objects for the Delegation of Management Scripts", 2204 RFC 3165, August 2001. 2206 [RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", 2207 RFC 3195, November 2001. 2209 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2210 A., Peterson, J., Sparks, R., Handley, M., and E. 2211 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2212 June 2002. 2214 [RFC3273] Waldbusser, S., "Remote Network Monitoring Management 2215 Information Base for High Capacity Networks", RFC 3273, 2216 July 2002. 2218 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2219 and M. Carney, "Dynamic Host Configuration Protocol for 2220 IPv6 (DHCPv6)", RFC 3315, July 2003. 2222 [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration 2223 Protocol (DHCPv6) Options for Session Initiation 2224 Protocol (SIP) Servers", RFC 3319, July 2003. 2226 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay 2227 Variation Metric for IP Performance Metrics (IPPM)", 2228 RFC 3393, November 2002. 2230 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2231 "Introduction and Applicability Statements for Internet- 2232 Standard Management Framework", RFC 3410, December 2002. 2234 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2235 Architecture for Describing Simple Network Management 2236 Protocol (SNMP) Management Frameworks", STD 62, 2237 RFC 3411, December 2002. 2239 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 2240 Management Protocol (SNMP) Applications", STD 62, 2241 RFC 3413, December 2002. 2243 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2244 (USM) for version 3 of the Simple Network Management 2245 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 2247 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2248 Access Control Model (VACM) for the Simple Network 2249 Management Protocol (SNMP)", STD 62, RFC 3415, 2250 December 2002. 2252 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 2253 Management Protocol (SNMP)", STD 62, RFC 3417, 2254 December 2002. 2256 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 2257 Simple Network Management Protocol (SNMP)", STD 62, 2258 RFC 3418, December 2002. 2260 [RFC3430] Schoenwaelder, J., "Simple Network Management Protocol 2261 Over Transmission Control Protocol Transport Mapping", 2262 RFC 3430, December 2002. 2264 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 2265 performance measurement with periodic streams", 2266 RFC 3432, November 2002. 2268 [RFC3433] Bierman, A., Romascanu, D., and K. Norseth, "Entity 2269 Sensor Management Information Base", RFC 3433, 2270 December 2002. 2272 [RFC3434] Bierman, A. and K. McCloghrie, "Remote Monitoring MIB 2273 Extensions for High Capacity Alarms", RFC 3434, 2274 December 2002. 2276 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference 2277 between Information Models and Data Models", RFC 3444, 2278 January 2003. 2280 [RFC3460] Moore, B., "Policy Core Information Model (PCIM) 2281 Extensions", RFC 3460, January 2003. 2283 [RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network 2284 Management Workshop", RFC 3535, May 2003. 2286 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization 2287 and Accounting (AAA) Transport Profile", RFC 3539, 2288 June 2003. 2290 [RFC3574] Soininen, J., "Transition Scenarios for 3GPP Networks", 2291 RFC 3574, August 2003. 2293 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 2294 Dial In User Service) Support For Extensible 2295 Authentication Protocol (EAP)", RFC 3579, 2296 September 2003. 2298 [RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. 2299 Roese, "IEEE 802.1X Remote Authentication Dial In User 2300 Service (RADIUS) Usage Guidelines", RFC 3580, 2301 September 2003. 2303 [RFC3584] Frye, R., Levi, D., Routhier, S., and B. Wijnen, 2304 "Coexistence between Version 1, Version 2, and Version 3 2305 of the Internet-standard Network Management Framework", 2306 BCP 74, RFC 3584, August 2003. 2308 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 2309 Arkko, "Diameter Base Protocol", RFC 3588, 2310 September 2003. 2312 [RFC3589] Loughney, J., "Diameter Command Codes for Third 2313 Generation Partnership Project (3GPP) Release 5", 2314 RFC 3589, September 2003. 2316 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 2317 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 2318 December 2003. 2320 [RFC3729] Waldbusser, S., "Application Performance Measurement 2321 MIB", RFC 3729, March 2004. 2323 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2324 Conrad, "Stream Control Transmission Protocol (SCTP) 2325 Partial Reliability Extension", RFC 3758, May 2004. 2327 [RFC3877] Chisholm, S. and D. Romascanu, "Alarm Management 2328 Information Base (MIB)", RFC 3877, September 2004. 2330 [RFC3878] Lam, H., Huynh, A., and D. Perkins, "Alarm Reporting 2331 Control Management Information Base (MIB)", RFC 3878, 2332 September 2004. 2334 [RFC3917] Quittek, J., Zseby, T., Claise, B., and S. Zander, 2335 "Requirements for IP Flow Information Export (IPFIX)", 2336 RFC 3917, October 2004. 2338 [RFC4004] Calhoun, P., Johansson, T., Perkins, C., Hiller, T., and 2339 P. McCann, "Diameter Mobile IPv4 Application", RFC 4004, 2340 August 2005. 2342 [RFC4005] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, 2343 "Diameter Network Access Server Application", RFC 4005, 2344 August 2005. 2346 [RFC4006] Hakala, H., Mattila, L., Koskinen, J-P., Stura, M., and 2347 J. Loughney, "Diameter Credit-Control Application", 2348 RFC 4006, August 2005. 2350 [RFC4011] Waldbusser, S., Saperia, J., and T. Hongal, "Policy 2351 Based Management MIB", RFC 4011, March 2005. 2353 [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. 2354 Savola, "Scenarios and Analysis for Introducing IPv6 2355 into ISP Networks", RFC 4029, March 2005. 2357 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 2358 Castro, "Application Aspects of IPv6 Transition", 2359 RFC 4038, March 2005. 2361 [RFC4057] Bound, J., "IPv6 Enterprise Network Scenarios", 2362 RFC 4057, June 2005. 2364 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter 2365 Extensible Authentication Protocol (EAP) Application", 2366 RFC 4072, August 2005. 2368 [RFC4118] Yang, L., Zerfos, P., and E. Sadot, "Architecture 2369 Taxonomy for Control and Provisioning of Wireless Access 2370 Points (CAPWAP)", RFC 4118, June 2005. 2372 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", 2373 RFC 4133, August 2005. 2375 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 2376 Registry", BCP 108, RFC 4148, August 2005. 2378 [RFC4150] Dietz, R. and R. Cole, "Transport Performance Metrics 2379 MIB", RFC 4150, August 2005. 2381 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition 2382 Mechanisms for IPv6 Hosts and Routers", RFC 4213, 2383 October 2005. 2385 [RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third 2386 Generation Partnership Project (3GPP) Networks", 2387 RFC 4215, October 2005. 2389 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2390 Protocol Architecture", RFC 4251, January 2006. 2392 [RFC4268] Chisholm, S. and D. Perkins, "Entity State MIB", 2393 RFC 4268, November 2005. 2395 [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host 2396 Configuration Protocol (DHCP) Options for Broadcast and 2397 Multicast Control Servers", RFC 4280, November 2005. 2399 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2400 Security", RFC 4347, April 2006. 2402 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2403 Security Layer (SASL)", RFC 4422, June 2006. 2405 [RFC4502] Waldbusser, S., "Remote Network Monitoring Management 2406 Information Base Version 2", RFC 4502, May 2006. 2408 [RFC4564] Govindan, S., Cheng, H., Yao, ZH., Zhou, WH., and L. 2409 Yang, "Objectives for Control and Provisioning of 2410 Wireless Access Points (CAPWAP)", RFC 4564, July 2006. 2412 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and 2413 M. Zekauskas, "A One-way Active Measurement Protocol 2414 (OWAMP)", RFC 4656, September 2006. 2416 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", 2417 RFC 4668, August 2006. 2419 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", 2420 RFC 4669, August 2006. 2422 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", 2423 RFC 4670, August 2006. 2425 [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", 2426 RFC 4671, August 2006. 2428 [RFC4672] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS 2429 Dynamic Authorization Client MIB", RFC 4672, 2430 September 2006. 2432 [RFC4673] De Cnodder, S., Jonnala, N., and M. Chiba, "RADIUS 2433 Dynamic Authorization Server MIB", RFC 4673, 2434 September 2006. 2436 [RFC4675] Congdon, P., Sanchez, M., and B. Aboba, "RADIUS 2437 Attributes for Virtual LAN and Priority Support", 2438 RFC 4675, September 2006. 2440 [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- 2441 time Application Quality-of-Service Monitoring (RAQMON) 2442 Framework", RFC 4710, October 2006. 2444 [RFC4711] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- 2445 time Application Quality-of-Service Monitoring (RAQMON) 2446 MIB", RFC 4711, October 2006. 2448 [RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., 2449 and Y. Kim, "Transport Mappings for Real-time 2450 Application Quality-of-Service Monitoring (RAQMON) 2451 Protocol Data Unit (PDU)", RFC 4712, October 2006. 2453 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 2454 S., and J. Perser, "Packet Reordering Metrics", 2455 RFC 4737, November 2006. 2457 [RFC4740] Garcia-Martin, M., Belinchon, M., Pallares-Lopez, M., 2458 Canales-Valenzuela, C., and K. Tammi, "Diameter Session 2459 Initiation Protocol (SIP) Application", RFC 4740, 2460 November 2006. 2462 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 2463 December 2006. 2465 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 2466 Configuration Protocol over Secure SHell (SSH)", 2467 RFC 4742, December 2006. 2469 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object 2470 Access Protocol (SOAP)", RFC 4743, December 2006. 2472 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol 2473 over the Blocks Extensible Exchange Protocol (BEEP)", 2474 RFC 4744, December 2006. 2476 [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix 2477 Attribute", RFC 4818, April 2007. 2479 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 2480 Configuration Access Protocol (XCAP)", RFC 4825, 2481 May 2007. 2483 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication 2484 Dial In User Service (RADIUS) Implementation Issues and 2485 Suggested Fixes", RFC 5080, December 2007. 2487 [RFC5090] Sterman, B., Sadolevsky, D., Schwartz, D., Williams, D., 2488 and W. Beck, "RADIUS Extension for Digest 2489 Authentication", RFC 5090, February 2008. 2491 [RFC5101] Claise, B., "Specification of the IP Flow Information 2492 Export (IPFIX) Protocol for the Exchange of IP Traffic 2493 Flow Information", RFC 5101, January 2008. 2495 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 2496 Meyer, "Information Model for IP Flow Information 2497 Export", RFC 5102, January 2008. 2499 [RFC5103] Trammell, B. and E. Boschi, "Bidirectional Flow Export 2500 Using IP Flow Information Export (IPFIX)", RFC 5103, 2501 January 2008. 2503 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 2504 Aboba, "Dynamic Authorization Extensions to Remote 2505 Authentication Dial In User Service (RADIUS)", RFC 5176, 2506 January 2008. 2508 [RFC5181] Shin, M-K., Han, Y-H., Kim, S-E., and D. Premec, "IPv6 2509 Deployment Scenarios in 802.16 Networks", RFC 5181, 2510 May 2008. 2512 [RFC5224] Brenner, M., "Diameter Policy Processing Application", 2513 RFC 5224, March 2008. 2515 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer 2516 Security (TLS) Protocol Version 1.2", RFC 5246, 2517 August 2008. 2519 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2520 Notifications", RFC 5277, July 2008. 2522 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 2523 Babiarz, "A Two-Way Active Measurement Protocol 2524 (TWAMP)", RFC 5357, October 2008. 2526 [RFC5381] Iijima, T., Atarashi, Y., Kimura, H., Kitani, M., and H. 2527 Okita, "Experience of Implementing NETCONF over SOAP", 2528 RFC 5381, October 2008. 2530 [RFC5388] Niccolini, S., Tartarelli, S., Quittek, J., Dietz, T., 2531 and M. Swany, "Information Model and XML Data Model for 2532 Traceroute Measurements", RFC 5388, December 2008. 2534 [RFC5416] Calhoun, P., Montemurro, M., and D. Stanley, "Control 2535 and Provisioning of Wireless Access Points (CAPWAP) 2536 Protocol Binding for IEEE 802.11", RFC 5416, March 2009. 2538 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, 2539 March 2009. 2541 [RFC5425] Miao, F., Ma, Y., and J. Salowey, "Transport Layer 2542 Security (TLS) Transport Mapping for Syslog", RFC 5425, 2543 March 2009. 2545 [RFC5426] Okmianski, A., "Transmission of Syslog Messages over 2546 UDP", RFC 5426, March 2009. 2548 [RFC5427] Keeni, G., "Textual Conventions for Syslog Management", 2549 RFC 5427, March 2009. 2551 [RFC5431] Sun, D., "Diameter ITU-T Rw Policy Enforcement Interface 2552 Application", RFC 5431, March 2009. 2554 [RFC5447] Korhonen, J., Bournelle, J., Tschofenig, H., Perkins, 2555 C., and K. Chowdhury, "Diameter Mobile IPv6: Support for 2556 Network Access Server to Diameter Server Interaction", 2557 RFC 5447, February 2009. 2559 [RFC5470] Sadasivan, G., Brownlee, N., Claise, B., and J. Quittek, 2560 "Architecture for IP Flow Information Export", RFC 5470, 2561 March 2009. 2563 [RFC5473] Boschi, E., Mark, L., and B. Claise, "Reducing 2564 Redundancy in IP Flow Information Export (IPFIX) and 2565 Packet Sampling (PSAMP) Reports", RFC 5473, March 2009. 2567 [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and 2568 F. Raspall, "Sampling and Filtering Techniques for IP 2569 Packet Selection", RFC 5475, March 2009. 2571 [RFC5476] Claise, B., Johnson, A., and J. Quittek, "Packet 2572 Sampling (PSAMP) Protocol Specifications", RFC 5476, 2573 March 2009. 2575 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 2576 Carle, "Information Model for Packet Sampling Exports", 2577 RFC 5477, March 2009. 2579 [RFC5516] Jones, M. and L. Morand, "Diameter Command Code 2580 Registration for the Third Generation Partnership 2581 Project (3GPP) Evolved Packet System (EPS)", RFC 5516, 2582 April 2009. 2584 [RFC5539] Badra, M., "NETCONF over Transport Layer Security 2585 (TLS)", RFC 5539, May 2009. 2587 [RFC5560] Uijterwaal, H., "A One-Way Packet Duplication Metric", 2588 RFC 5560, May 2009. 2590 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 2591 Aboba, "Carrying Location Objects in RADIUS and 2592 Diameter", RFC 5580, August 2009. 2594 [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport 2595 Subsystem for the Simple Network Management Protocol 2596 (SNMP)", RFC 5590, June 2009. 2598 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security 2599 Model for the Simple Network Management Protocol 2600 (SNMP)", RFC 5591, June 2009. 2602 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 2603 Shell Transport Model for the Simple Network Management 2604 Protocol (SNMP)", RFC 5592, June 2009. 2606 [RFC5607] Nelson, D. and G. Weber, "Remote Authentication Dial-In 2607 User Service (RADIUS) Authorization for Network Access 2608 Server (NAS) Management", RFC 5607, July 2009. 2610 [RFC5608] Narayan, K. and D. Nelson, "Remote Authentication 2611 Dial-In User Service (RADIUS) Usage for Simple Network 2612 Management Protocol (SNMP) Transport Models", RFC 5608, 2613 August 2009. 2615 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 2616 "Exporting Type Information for IP Flow Information 2617 Export (IPFIX) Information Elements", RFC 5610, 2618 July 2009. 2620 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. 2621 Wagner, "Specification of the IP Flow Information Export 2622 (IPFIX) File Format", RFC 5655, October 2009. 2624 [RFC5674] Chisholm, S. and R. Gerhards, "Alarms in Syslog", 2625 RFC 5674, October 2009. 2627 [RFC5675] Marinov, V. and J. Schoenwaelder, "Mapping Simple 2628 Network Management Protocol (SNMP) Notifications to 2629 SYSLOG Messages", RFC 5675, October 2009. 2631 [RFC5676] Schoenwaelder, J., Clemm, A., and A. Karmakar, 2632 "Definitions of Managed Objects for Mapping SYSLOG 2633 Messages to Simple Network Management Protocol (SNMP) 2634 Notifications", RFC 5676, October 2009. 2636 [RFC5706] Harrington, D., "Guidelines for Considering Operations 2637 and Management of New Protocols and Protocol 2638 Extensions", RFC 5706, November 2009. 2640 [RFC5713] Moustafa, H., Tschofenig, H., and S. De Cnodder, 2641 "Security Threats and Security Requirements for the 2642 Access Node Control Protocol (ANCP)", RFC 5713, 2643 January 2010. 2645 [RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote 2646 Procedure Call (RPC) for NETCONF", RFC 5717, 2647 December 2009. 2649 [RFC5719] Romascanu, D. and H. Tschofenig, "Updated IANA 2650 Considerations for Diameter Command Code Allocations", 2651 RFC 5719, January 2010. 2653 [RFC5729] Korhonen, J., Jones, M., Morand, L., and T. Tsou, 2654 "Clarifications on the Routing of Diameter Requests 2655 Based on the Username and the Realm", RFC 5729, 2656 December 2009. 2658 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol 2659 (EPP)", STD 69, RFC 5730, August 2009. 2661 [RFC5777] Korhonen, J., Tschofenig, H., Arumaithurai, M., Jones, 2662 M., and A. Lior, "Traffic Classification and Quality of 2663 Service (QoS) Attributes for Diameter", RFC 5777, 2664 February 2010. 2666 [RFC5778] Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, 2667 G., and M. Nakhjiri, "Diameter Mobile IPv6: Support for 2668 Home Agent to Diameter Server Interaction", RFC 5778, 2669 February 2010. 2671 [RFC5779] Korhonen, J., Bournelle, J., Chowdhury, K., Muhanna, A., 2672 and U. Meyer, "Diameter Proxy Mobile IPv6: Mobile Access 2673 Gateway and Local Mobility Anchor Interaction with 2674 Diameter Server", RFC 5779, February 2010. 2676 [RFC5815] Dietz, T., Kobayashi, A., Claise, B., and G. Muenz, 2677 "Definitions of Managed Objects for IP Flow Information 2678 Export", RFC 5815, April 2010. 2680 [RFC5833] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, 2681 "Control and Provisioning of Wireless Access Points 2682 (CAPWAP) Protocol Base MIB", RFC 5833, May 2010. 2684 [RFC5834] Shi, Y., Perkins, D., Elliott, C., and Y. Zhang, 2685 "Control and Provisioning of Wireless Access Points 2686 (CAPWAP) Protocol Binding MIB for IEEE 802.11", 2687 RFC 5834, May 2010. 2689 [RFC5835] Morton, A. and S. Van den Berghe, "Framework for Metric 2690 Composition", RFC 5835, April 2010. 2692 [RFC5848] Kelsey, J., Callas, J., and A. Clemm, "Signed Syslog 2693 Messages", RFC 5848, May 2010. 2695 [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 2696 Wadhwa, "Framework and Requirements for an Access Node 2697 Control Mechanism in Broadband Multi-Service Networks", 2698 RFC 5851, May 2010. 2700 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, 2701 A., and G. Zorn, "Diameter Quality-of-Service 2702 Application", RFC 5866, May 2010. 2704 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 2705 Hoc Networks", RFC 5889, September 2010. 2707 [RFC5953] Hardaker, W., "Transport Layer Security (TLS) Transport 2708 Model for the Simple Network Management Protocol 2709 (SNMP)", RFC 5953, August 2010. 2711 [RFC5982] Kobayashi, A. and B. Claise, "IP Flow Information Export 2712 (IPFIX) Mediation: Problem Statement", RFC 5982, 2713 August 2010. 2715 [RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, 2716 "Datagram Transport Layer Security (DTLS) Transport 2717 Mapping for Syslog", RFC 6012, October 2010. 2719 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 2720 Network Configuration Protocol (NETCONF)", RFC 6020, 2721 October 2010. 2723 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 2724 October 2010. 2726 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 2727 Monitoring", RFC 6022, October 2010. 2729 [RFC6035] Pendleton, A., Clark, A., Johnston, A., and H. 2730 Sinnreich, "Session Initiation Protocol Event Package 2731 for Voice Quality Reporting", RFC 6035, November 2010. 2733 [RFCSEARCH] IETF, "RFC Index Search Engine", January 2006, 2734 . 2736 [STD58] McCloghrie, K., David, D., and J. Juergen, "Structure of 2737 Management Information Version 2 (SMIv2)", April 1999. 2739 [STD59] Waldbusser, S., "Remote Network Monitoring Management 2740 Information Base", May 2000. 2742 [STD62] Harrington, D., "An Architecture for Describing Simple 2743 Network Management Protocol (SNMP) Management 2744 Frameworks", December 2002. 2746 [STD69] Hollenbeck, S., "Extensible Provisioning Protocol 2747 (EPP)", August 2009. 2749 [XPATH] World Wide Web Consortium, "XML Path Language (XPath) 2750 Version 1.0", November 1999, 2751 . 2753 Appendix A. New Work related to IETF Management Framework 2755 A.1. Energy Management (EMAN) 2757 Energy management is becoming an additional requirement for network 2758 management systems due to several factors including the rising and 2759 fluctuating energy costs, the increased awareness of the ecological 2760 impact of operating networks and devices, and the regulation of 2761 governments on energy consumption and production. 2763 The basic objective of energy management is operating communication 2764 networks and other equipments with a minimal amount of energy while 2765 still providing sufficient performance to meet service level 2766 objectives. Today, most networking and network-attached devices 2767 neither monitor nor allow control energy usage as they are mainly 2768 instrumented for functions such as fault, configuration, accounting, 2769 performance, and security management. These devices are not 2770 instrumented to be aware of energy consumption. There are very few 2771 means specified in IETF documents for energy management, which 2772 includes the areas of power monitoring, energy monitoring, and power 2773 state control. 2775 A particular difference between energy management and other 2776 management tasks is that in some cases energy consumption of a device 2777 is not measured at the device itself but reported by a different 2778 place. For example, at a Power over Ethernet (PoE) sourcing device 2779 or at a smart power strip, in which cases one device is effectively 2780 metering another remote device. This requires a clear definition of 2781 the relationship between the reporting devices and identification of 2782 remote devices for which monitoring information is provided. Similar 2783 considerations will apply to power state control of remote devices, 2784 for example, at a PoE sourcing device that switches on and off power 2785 at its ports. Another example scenario for energy management is a 2786 gateway to low resourced and lossy network devices in wireless a 2787 building network. Here the energy management system talks directly 2788 to the gateway but not necessarily to other devices in the building 2789 network. 2791 At the time of this writing the EMAN working group works on the 2792 management of energy-aware devices, covered by the following items: 2794 o Requirements for energy management, specifying energy management 2795 properties that will allow networks and devices to become energy 2796 aware. In addition to energy awareness requirements, the need for 2797 control functions will be discussed. Specifically the need to 2798 monitor and control properties of devices that are remote to the 2799 reporting device should be discussed. 2801 o Energy management framework, which will describe extensions to 2802 current management framework, required for energy management. 2803 This includes: power and energy monitoring, power states, power 2804 state control, and potential power state transitions. The 2805 framework will focus on energy management for IP-based network 2806 equipment (routers, switches, PCs, IP cameras, phones and the 2807 like). Particularly, the relationships between reporting devices, 2808 remote devices, and monitoring probes (such as might be used in 2809 low-power and lossy networks) need to be elaborated. For the case 2810 of a device reporting on behalf of other devices and controlling 2811 those devices, the framework will address the issues of discovery 2812 and identification of remote devices. 2814 o Energy-aware Networks and Devices MIB document, for monitoring 2815 energy-aware networks and devices, will address devices 2816 identification, context information, and potential relationship 2817 between reporting devices, remote devices, and monitoring probes. 2819 o Power and Energy Monitoring MIB document will document defining 2820 managed objects for monitoring of power states and energy 2821 consumption/production. The monitoring of power states includes: 2822 retrieving power states, properties of power states, current power 2823 state, power state transitions, and power state statistics. The 2824 managed objects will provide means for reporting detailed 2825 properties of the actual energy rate (power) and of accumulated 2826 energy. Further, it will provide information on electrical power 2827 quality. 2829 o Battery MIB document will define managed objects for battery 2830 monitoring, which will provide means for reporting detailed 2831 properties of the actual charge, age, and state of a battery and 2832 of battery statistics. 2834 o Applicability statement will describe the variety of applications 2835 that can use the energy framework and associated MIB modules. 2836 Potential examples are building networks, home energy gateway, 2837 etc. Finally, the document will also discuss relationships of the 2838 framework to other architectures and frameworks (such as Smart 2839 Grid). The applicability statement will explain the relationship 2840 between the work in this WG and the other existing standards such 2841 as those from the IEC, ANSI, DMTF, and others. Note that the EMAN 2842 WG will be looking into existing standards such as those from the 2843 IEC, ANSI, DMTF and others, and reuse existing work as much as 2844 possible. 2846 Appendix B. Open issues 2848 Need additional discussion on usage scenarios for different RFCs. 2850 Appendix C. Change Log 2852 C.1. 02-03 2854 o Rearranged the document structure using a flat structure putting 2855 all protocols onto the same level. 2857 o Incorporated contributions for RADIUS/DIAMETER, IPFIX/PSAMP, YANG, 2858 and EMAN. 2860 o Added diverse references. 2862 o Added Contributors and Acknowledgements sections. 2864 o Bug fixing and issue solving. 2866 C.2. 01-02 2868 o Added terminology section. 2870 o Changed the language for neutral standard description addressing 2871 diverse SDOs. 2873 o Extended NETCONF and NETMOD related text. 2875 o Extended section for 'IPv6 Network Operations'. 2877 o Bug fixing. 2879 C.3. 00-01 2881 o Extended text for SNMP 2883 o Extended RADIUS and DIAMETER sections. 2885 o Added references. 2887 o Bug fixing. 2889 Author's Address 2891 Mehmet Ersue (editor) 2892 Nokia Siemens Networks 2893 St.-Martin-Strasse 53 2894 Munich 81541 2895 Germany 2897 EMail: mehmet.ersue@nsn.com