Diameter Network Address and Port Translation Control Application
Extracted elements (30)
DNCA limits per-endpoint NAT bindings primarily to protect against denial-of-service attacks. If one endpoint could consume all bindings for a shared public IP address, it would deny service to co-located endpoints. The optimal per-endpoint maximum varies by endpoint type (e.g., broadband PC vs. mobile phone), motivating active management.
DNCA qualifies as a MIDCOM protocol for NAT middleboxes, extending standard MIDCOM capabilities by maintaining per-endpoint subscriber context. This allows per-endpoint binding limits, address pool selection, and accounting that are unavailable in endpoint-agnostic NAT management approaches like SNMP or NETCONF.
DNCA supports two deployment models: 'integrated' (NAS acts as NAT controller, hiding the NAT device from the AAA-server and producing a single accounting stream) and 'autonomous' (AAA-server acts as NAT controller, producing two separate accounting streams per endpoint). The integrated model minimizes changes to existing AAA infrastructure.
DNCA supports both NAT44 (IPv4-to-IPv4 translation per RFC 2663) and NAT64 (stateful IPv6-to-IPv4 address family translation per RFC 6145 and RFC 6146), allowing the same Diameter application to control both translation types within a unified session management framework.
A DNCA Diameter peer within a NAT device MUST treat an NCR as an atomic operation: either all requested actions within an NCR complete successfully or the entire request fails and no bindings are established or removed.
Diameter nodes conforming to this specification MUST advertise support for DNCA by including the value 12 in the Auth-Application-Id of Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands.
Each DNCA session MUST have a globally unique Session-Id that MUST NOT be changed during the lifetime of the session, and a DNCA session MUST NOT have more than one outstanding request at any given time.
For any given endpoint, only a single DNCA NAT controller MUST be active at any point in time, to prevent conflicting control requests to NAT devices and ambiguous accounting information routing.
Session termination MUST be initiated by the DNCA Diameter peer within the NAT controller via an STR message. Upon termination, all NAT-bindings belonging to the session MUST be removed and session state MUST be cleaned up by the NAT device.
When an INITIAL_REQUEST NCR identifies an already-existing session (matching endpoint identifier), the NAT device MUST return an NCA with Result-Code SESSION_EXISTS and provide the existing Session-Id in the Duplicate-Session-Id AVP.
When an NCR lowers the maximum binding count below the current number of active bindings, the NAT device SHOULD refrain from immediately enforcing the new limit by removing existing bindings; instead, it should disallow new bindings until the active count falls below the new maximum.
When an operator uses multiple methods to configure a NAT device (CLI, SNMP, NETCONF, PCP, or DNCA), the operator MUST ensure configurations from different methods do not conflict, and the NAT device MUST allow the operator to configure a conflict-resolution policy specifying which mechanism takes precedence.
When Max-NAT-Bindings and NAT-Control-Definition are present in an NCR alongside a NAT-Control-Binding-Template, the explicit Max-NAT-Bindings and NAT-Control-Definition values MUST override any conflicting values in the referenced pre-provisioned template.
When the NAT controller is unreachable (detected via Diameter watchdog messages or failed accounting responses), NAT-bindings and NAT device state for that session MUST be cleaned up after a grace period that is operator-configurable on the NAT device (and may be zero).
The Duplicate-Session-Id AVP (AVP Code 603, UTF8String) carries the Session-Id of an already-existing DNCA session when the NAT device returns SESSION_EXISTS, enabling the NAT controller to identify and optionally terminate the conflicting older session via STR.
The Max-NAT-Bindings AVP (AVP Code 601, Unsigned32) defines the maximum number of NAT bindings permitted for the endpoint associated with the session. When present alongside a NAT-Control-Binding-Template, it overrides the template's binding limit.
The NAT-Control-Answer (NCA) command (Command Code 330, 'R' bit cleared) is returned by the NAT device in response to an NCR. It carries Result-Code, zero or more NAT-Control-Definition AVPs reporting active bindings, Current-NAT-Bindings, and Duplicate-Session-Id on SESSION_EXISTS errors.
The NAT-Control-Install AVP (AVP Code 596, Grouped) activates or installs NAT bindings. It contains NAT-Control-Definition AVPs, an optional NAT-Control-Binding-Template reference, Max-NAT-Bindings, and NAT-External-Port-Style. If NAT-External-Port-Style is present, the NAT device MUST select external ports per the specified style for bindings with unspecified external ports.
The NAT-Control-Remove AVP (AVP Code 597, Grouped) deactivates or removes NAT bindings from an existing session. It is used in UPDATE_REQUEST NCRs to remove specific previously installed bindings.
The NAT-Control-Request (NCR) command (Command Code 330, 'R' bit set) is sent from the NAT controller to the NAT device to install, update, query, or remove NAT bindings. Endpoint classifiers (User-Name, Framed-IP-Address, Framed-IPv6-Prefix, EGRESS-VLANID, etc.) identify the endpoint; NAT-Control-Install and NAT-Control-Remove AVPs carry binding instructions.
The NAT-External-Port-Style AVP (AVP Code 604, Enumerated) specifies the style of external port selection (e.g., consecutive or random) for NAT bindings where the external port is unspecified. It applies only to bindings within the same NAT-Control-Install whose NAT-External-Address or Port AVPs are absent.
The NC-Request-Type AVP (AVP Code 595, Enumerated, mandatory in all NCRs) indicates the request type: INITIAL_REQUEST (1) to create a new DNCA session, UPDATE_REQUEST (2) to modify bindings in an existing session, or QUERY_REQUEST (3) to retrieve current binding information.
IANA assigned Application Identifier 12 for DNCA and Command Code 330 for NCR/NCA. AVP Codes 595–607 were assigned for DNCA-defined AVPs: NC-Request-Type (595), NAT-Control-Install (596), NAT-Control-Remove (597), NAT-Control-Definition (598), NAT-Internal-Address (599), NAT-External-Address (600), Max-NAT-Bindings (601), NAT-Control-Binding-Template (602), Duplicate-Session-Id (603), NAT-External-Port-Style (604), NAT-Control-Record (605), NAT-Control-Binding-Status (606), and Current-NAT-Bindings (607).
IANA assigned seven new Result-Code AVP values for DNCA: transient failure RESOURCE_FAILURE (4014); and permanent failures UNKNOWN_BINDING_TEMPLATE_NAME (5042), BINDING_FAILURE (5043), MAX_BINDINGS_SET_FAILURE (5044), MAXIMUM_BINDINGS_REACHED_FOR_ENDPOINT (5045), SESSION_EXISTS (5046), and INSUFFICIENT_CLASSIFIERS (5047). All conforming implementations SHALL support these values.
IANA created three new enumeration registries for DNCA: NC-Request-Type AVP values (INITIAL_REQUEST=1, UPDATE_REQUEST=2, QUERY_REQUEST=3), NAT-External-Port-Style AVP values, and NAT-Control-Binding-Status AVP values.
DNCA Diameter peers SHOULD verify their identity during the Capabilities Exchange Request procedure. A NAT device SHOULD verify that an NCR-issuing peer is authorized based on the peer's identity, the NCR command type, and the NCR content, to prevent unauthorized NAT binding creation or manipulation.
For secure transport of Diameter messages, DNCA follows the recommendations of RFC 6733, requiring TLS or IPsec to protect Diameter messages in transit. Unauthorized control of NAT bindings could allow traffic redirection, session hijacking, or service disruption for endpoints sharing public addresses.
The NAT controller state machine defines four states: Idle (no session), Pending (NCR Initial sent, awaiting NCA), Open (session active, may send Update NCRs), and Discon (STR sent). Key transitions: new endpoint detected triggers NCR (Idle→Pending); successful NCA moves to Open; access session end or ASR triggers STR (Open→Discon); STA receipt completes teardown (Discon→Idle). Any event not in the state table MUST be treated as an error.
The NAT device state machine defines three states: Idle, Open, and Discon. A successful INITIAL_REQUEST NCR moves Idle→Open; a failed NCR keeps Idle. Any STR received in any state causes cleanup and moves to Idle. When unable to maintain a session (resource exhaustion), the device sends ASR (Open→Discon) and retries until an ASA is received. Unplanned loss of connection to the NAT controller causes immediate cleanup (Open→Idle).
All DNCA-defined AVPs (Codes 595–607) use standard Diameter AVP encoding with the 'M' (mandatory) and optionally 'P' (protected) flags set, but MUST NOT have the 'V' (vendor-specific) flag set. Max-NAT-Bindings (601) is Unsigned32; NC-Request-Type (595), NAT-External-Port-Style (604), and NAT-Control-Binding-Status (606) are Enumerated; NAT-Control-Binding-Template (602) is OctetString; Duplicate-Session-Id (603) is UTF8String; remaining new AVPs are Grouped.