Network Configuration Protocol (NETCONF)
Extracted elements (30)
NETCONF's RPC paradigm was chosen to closely mirror the native functionality of managed devices, reducing implementation costs and enabling timely access to new device features. Authentication reuses existing device mechanisms (e.g., RADIUS) for the same reason.
NETCONF separates configuration data (writable data required to achieve desired device state) from state data (read-only status, statistics) because mixing them would produce large datasets, nonsensical write attempts, and complications restoring archived configurations. <get-config> retrieves only configuration; <get> retrieves both.
Subtree filtering was designed so the server requires no data-model-specific semantic knowledge during filter processing, enabling simple, centralized implementation. The filter mechanism provides inclusion, exact-match, and selection without requiring content-layer awareness.
Both peers MUST exchange <hello> messages at session establishment to advertise their capabilities before any other NETCONF messages are sent. The client adjusts its behavior to take advantage of server-advertised capabilities; capabilities not advertised by the server MUST NOT be used.
A capability URI MUST sufficiently distinguish the naming authority to avoid naming collisions. To support a capability, a server MUST support all capabilities upon which it depends.
A device MUST support at least one NETCONF session and SHOULD support multiple concurrent sessions. Global configuration changes made in any authorized session are visible across all sessions.
A NETCONF implementation MUST support the SSH transport protocol mapping defined in RFC6242. SSH is the mandatory baseline transport; all other transports are optional.
A server MUST return an <rpc-error> element if any error conditions occur during processing. A server MUST NOT return application-level or data-model-specific error information to clients lacking sufficient access rights.
All NETCONF messages MUST be well-formed XML encoded in UTF-8. A peer receiving a malformed or non-UTF-8 <rpc> SHOULD reply with a 'malformed-message' error; if no reply can be sent, the server MUST terminate the session.
Authentication MUST result in an authenticated client identity (NETCONF username) whose permissions are known to the server. These access permissions MUST be enforced throughout the entire NETCONF session.
Document type declarations (DTDs) MUST NOT appear in NETCONF content. This prevents XML entity expansion and simplifies parsing security.
For subtree filtering, if a filter element is unqualified (xmlns=''), the server MUST evaluate all XML namespaces it supports when processing that filter node. This wildcard mechanism does not apply to XML attributes.
If additional attributes are present in an <rpc> element, a NETCONF peer MUST return them unmodified in the <rpc-reply>, including xmlns attributes. This enables clients to use custom attributes as opaque correlation handles.
NETCONF connections MUST provide authentication, data integrity, confidentiality, and replay protection. NETCONF depends entirely on the transport protocol for these security properties.
NETCONF <rpc> requests MUST be processed serially by the managed device. Responses MUST be sent only in the order requests were received, though clients MAY pipeline additional requests before receiving replies.
The <running> configuration datastore cannot be deleted. A <copy-config> operation where source and target identify the same URL or datastore MUST return an error with error-tag 'invalid-value'.
The transport connection MUST provide reliable, sequenced data delivery. Resources acquired during a connection (e.g., locks) MUST be automatically released when the connection closes, enabling failure recovery without explicit cleanup.
NETCONF capabilities are identified by URIs and advertised in the session-opening <hello> exchange. Capabilities may define new protocol operations, new parameters to existing operations, and new content constraints, and may declare dependencies on other capabilities.
NETCONF defines three standard configuration datastores: <running> (always present, holds active configuration), <candidate> (optional, for staging without affecting running), and <startup> (optional, holds boot configuration). Only <running> exists in the base model; others require capability advertisement.
NETCONF is partitioned into four layers: (1) Secure Transport, (2) Messages (<rpc>, <rpc-reply>, <notification>), (3) Operations (<get-config>, <edit-config>, etc.), and (4) Content (configuration/notification data). Only layers 1–3 are defined by this document.
Subtree filters are comprised of five component types: namespace selection, attribute match expressions (filter by XML attribute value), containment nodes (inner elements specifying hierarchy), selection nodes (empty leaf nodes for explicit subtree selection), and content match nodes (leaf text for exact-match filtering, combined with AND logic).
The <edit-config> 'operation' attribute supports five values: merge (default — merge into existing), replace (overwrite at that level), create (error if already exists with data-exists tag), delete (error if not exists with data-missing tag), and remove (silent no-op if not exists).
The NETCONF base protocol defines nine operations: <get-config>, <edit-config>, <copy-config>, <delete-config>, <lock>, <unlock>, <get>, <close-session>, and <kill-session>. Additional operations are defined by optional capabilities.
The <rpc> element encloses a client-to-server NETCONF request and carries a mandatory 'message-id' attribute — a sender-chosen string (commonly a monotonically increasing integer) that the receiver echoes verbatim in the corresponding <rpc-reply>.
The <rpc-error> element reports processing errors and contains: error-type (transport/rpc/protocol/application), error-tag (error condition string), error-severity (error/warning), optional error-app-tag, error-path (XPath expression), error-message (human-readable), and error-info (protocol/data-model detail).
This document registers a YANG module 'ietf-netconf' (Appendix C) in the 'YANG Module Names' registry. The module formally specifies the NETCONF protocol operations and is the authoritative encoding definition for the Operations layer.
This document registers capability URNs in the 'NETCONF Capability URNs' registry for: writable-running, candidate, confirmed-commit, rollback-on-error, validate (versions 1.0 and 1.1), distinct-startup, url, and xpath capabilities.
This document registers the NETCONF XML namespace 'urn:ietf:params:xml:ns:netconf:base:1.0' in the IETF XML registry (Section 10.1) and an associated XML schema (Appendix B) in the IETF XML schema registry (Section 10.2).
A server MUST NOT return application-level or data-model-specific error information in <rpc-error> to clients lacking sufficient access rights. This prevents unauthorized users from inferring configuration details through error message side-channels.
NETCONF provides management access equivalent to the device's native CLI, which often grants superuser-level privileges. Compromising a NETCONF session gives full control over the device; implementations must ensure strong transport-layer security and careful access control configuration.