Internet Key Exchange Protocol Version 2 (IKEv2) Notification Status Types for IPv4/IPv6 Coexistence
updates
- rfc-7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
Extracted elements (12)
The existing INTERNAL_ADDRESS_FAILURE error type in RFC 7296 Section 3.15.4 is a catch-all that does not allow an initiator to determine why a given address family was not assigned or whether it should retry with another address family. This gap motivated the introduction of IP4_ALLOWED and IP6_ALLOWED notification status types.
Table 1 fully specifies the notification status types a responder must return for every combination of requested AFs (initiator), supported AFs (responder), and assigned AFs (responder), including policy-based single-family assignment when both families are technically supported.
These notification status types are not specific to 3GPP architectures; they can be used in any IKEv2 deployment context where address family assignment restrictions must be communicated. Cellular networks (3GPP SM cause codes #50, #51, #52) are provided as illustration only.
For address-related error cases not covered by IP4_ALLOWED or IP6_ALLOWED, the responder and initiator MUST follow the procedure defined in Section 3.15.4 of RFC 7296 (INTERNAL_ADDRESS_FAILURE handling).
If a dual-stack initiator requests both IPv6 prefix and IPv4 address but receives only one of the two along with both IP4_ALLOWED and IP6_ALLOWED, it MAY request the other address family. In such a case, the initiator MUST create a new IKE Security Association and request the other address family using the new IKE SA.
If a dual-stack initiator requests only one address family but receives only a notification for the opposite family (e.g., requests IPv6 but receives only IP4_ALLOWED), the initiator MUST send a request for the address family indicated as allowed.
If the initiator is dual stack (supports both IPv4 and IPv6), it MUST include configuration attributes for both address families in its configuration request, absent explicit policy or configuration otherwise.
If the initiator only receives a single IP4_ALLOWED or IP6_ALLOWED notification from the responder, the initiator MUST NOT send a subsequent request for the alternate address family not supported by the responder.
The responder MUST include the IP6_ALLOWED and/or IP4_ALLOWED notification status type in a response to an address assignment request as indicated in Table 1, covering all combinations of requested, supported, and assigned address families.
IP4_ALLOWED and IP6_ALLOWED are new IKEv2 notification status types used by the responder to signal which address families are supported and assignable. No data is associated with these notifications.
IANA updated the 'IKEv2 Notify Message Types - Status Types' registry with two new entries: value 16439 for IP4_ALLOWED and value 16440 for IP6_ALLOWED, both referencing RFC 8983.
Because the IPv4/IPv6 capabilities of a node are readily observable from the traffic it generates, the new IP4_ALLOWED and IP6_ALLOWED notifications do not introduce any new security considerations beyond those already described in RFC 7296.