<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ipsecme-ipv6-ipv4-codes-06"
number="8983" ipr="trust200902" updates="7296"> updates="7296" obsoletes="" submissionType="IETF"
category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4"
symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="IPv4/IPv6 Notification Status Types">IKEv2 Types">Internet Key Exchange Protocol Version 2 (IKEv2) Notification
    Status Types for IPv4/IPv6 Coexistence</title>

    <seriesInfo name="RFC" value="8983"/>
    <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <postal>
          <street></street>
          <street/>
          <city>Rennes</city>
          <code>35000</code>
          <country>France</country>
        </postal>
        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>
    <date day="17" month="December" year="2020" /> month="February" year="2021"/>
    <workgroup>ipsecme</workgroup>
    <keyword>IPv4 service continuity</keyword>
    <keyword>VoLTE</keyword>
    <keyword>Handover</keyword>
    <keyword>Service continuity</keyword>
    <keyword>3GPP</keyword>
    <keyword>IPv6 transition</keyword>
    <keyword>TS.24302</keyword>
    <keyword>PDP context</keyword>
    <keyword>PDP type</keyword>
    <abstract>
      <t>This document specifies new IKEv2 Internet Key Exchange Protocol Version 2 (IKEv2) notification status types to better
      manage IPv4 and IPv6 co-existence coexistence by allowing the responder to signal to
      the initiator which address families are allowed.</t>
      <t>This document updates RFC7296.</t> RFC 7296.</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>As described in <xref target="RFC7849"></xref>, target="RFC7849" format="default"/>, if the subscription
      data or network configuration allows only one IP address family (IPv4 or
      IPv6), the cellular host must not request a second PDP-Context (Section
      3.2 of <xref target="RFC6459"></xref>) (<xref target="RFC6459" sectionFormat="of" section="3.2"/>) to the same Access Point Name
      (APN) for the other IP address family (AF). The Third Generation
      Partnership Project (3GPP) network informs the cellular host about
      allowed Packet Data Protocol (PDP) types by means of Session Management
      (SM) cause codes. In particular, the following cause codes can be
      returned: <list style="symbols">
          <t>cause </t>

<dl>

<dt>cause #50 "PDP type IPv4 only allowed": This
</dt>
<dd>This cause code is used by the network to indicate that only PDP type IPv4
is allowed for the requested Public Data Network (PDN) connectivity.</t>

          <t>cause connectivity.
</dd>

<dt>cause #51 "PDP type IPv6 only allowed": This
</dt>
<dd>This cause code is used by the network to indicate that only PDP type IPv6
is allowed for the requested PDN connectivity.</t>

          <t>cause connectivity.
</dd>

<dt>cause #52 "single address bearers only allowed": This
</dt>
<dd>This cause code is used by the network to indicate that the requested PDN connectivity is accepted with the restriction that only single IP version bearers are allowed.</t>
        </list></t> allowed.
</dd>

</dl>

      <t>If the requested IPv4v6 PDP-Context is not supported by the network
      but IPv4 and IPv6 PDP types are allowed, then the cellular host will be
      configured with an IPv4 address or an IPv6 prefix by the network. It
      must initiate another PDP-Context activation of the other address family
      in addition to the one already activated for a given APN. The purpose of
      initiating a second PDP-Context is to achieve dual-stack connectivity
      (that is, IPv4 and IPv6 connectivity) by means of two PDP-Contexts.</t>
      <t>When the User Equipment (UE) attaches to the 3GPP network using a
      non-3GPP access network (e.g., Wireless Local Area Network (WLAN)),
      there are no equivalent Internet Key Exchange Protocol Version 2 (IKEv2) IKEv2
      capabilities <xref target="RFC7296"></xref> target="RFC7296" format="default"/> notification codes for the
      3GPP network to inform the UE why an IP address family is not assigned
      or whether that UE should retry with another address family.</t>
      <t>This document fills that void by introducing new IKEv2 notification
      status types for the sake of deterministic UE behaviors (<xref
      target="new"></xref>).</t> target="new" format="default"/>).</t>
      <t>These notification status types are not specific to 3GPP
      architectures,
      architectures but can be used in other deployment contexts. Cellular
      networks are provided as an illustration example.</t>
    </section>
    <section anchor="notation" title="Terminology">
      <t>The numbered="true" toc="default">
      <name>Terminology</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and
      "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are
    to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/>
    <xref target="RFC2119"></xref><xref target="RFC8174"></xref> target="RFC8174"/> when, and only when, they appear in all capitals,
    as shown here.</t> here.
        </t>

      <t>This document makes use of the terms defined in <xref
      target="RFC7296"></xref>. target="RFC7296" format="default"/>. In particular, readers should be familiar with
      "initiator" and "responder" terms used in that document.</t>
    </section>
    <section title="Why numbered="true" toc="default">
      <name>Why Not INTERNAL_ADDRESS_FAILURE?"> INTERNAL_ADDRESS_FAILURE?</name>

      <t>The following address assignment failures may be encountered when an
      initiator requests assignment of IP addresses/prefixes:<list
          style="symbols">
          <t>An addresses/prefixes:</t>
      <ul spacing="normal">
        <li>An initiator asks for IPvx, but IPvx address assignment is not
          supported by the responder.</t>

          <t>An responder.</li>
        <li>An initiator requests both IPv4 and IPv6 addresses, but only IPv4
          address assignment is supported by the responder.</t>

          <t>An responder.</li>
        <li>An initiator requests both IPv4 and IPv6 addresses, but only IPv6
          prefix assignment is supported by the responder.</t>

          <t>An responder.</li>
        <li>An initiator asks for both IPv4 and IPv6 addresses, but only one
          address family can be assigned by the responder for policy
          reasons.</t>
        </list></t>

      <t><xref target="RFC7296">Section 3.15.4 of</xref>
          reasons.</li>
      </ul>
      <t>
      <xref target="RFC7296" sectionFormat="of" section="3.15.4"/> defines a
      generic notification error type (INTERNAL_ADDRESS_FAILURE) that is
      related to a failure to handle an address assignment request. The
      responder sends INTERNAL_ADDRESS_FAILURE only if no addresses can be
      assigned. This behavior does not explicitly allow an initiator to
      determine why a given address family is not assigned, nor whether it
      should try using another address family. INTERNAL_ADDRESS_FAILURE is a
      catch-all error type when an address-related issue is encountered by an
      IKEv2 responder.</t>
      <t>INTERNAL_ADDRESS_FAILURE does not provide sufficient hints to the
      IKEv2 initiator to adjust its behavior.</t>
    </section>
    <section anchor="new" title="IP6_ALLOWED numbered="true" toc="default">
      <name>IP6_ALLOWED and IP4_ALLOWED Status Types"> Types</name>
      <t>IP6_ALLOWED and IP4_ALLOWED notification status types (see <xref
      target="sec-IANA"></xref>) target="sec-IANA" format="default"/>) are defined to inform the initiator about the
      responder's address family assignment support capabilities, capabilities and to
      report to the initiator the reason why an address assignment failed.
      These notification status types are used by the initiator to adjust its
      behavior accordingly (<xref target="update"></xref>).</t> target="update" format="default"/>).</t>
      <t>No data is associated with these notifications.</t>
    </section>
    <section anchor="update" title="An Update numbered="true" toc="default">
      <name>Update to RFC7296"> RFC 7296</name>

      <t>If the initiator is dual-stack dual stack (i.e., supports both IPv4 and IPv6),
      it MUST <bcp14>MUST</bcp14> include configuration attributes for both address
      families configuration attributes in its configuration request (absent explicit
      policy/configuration otherwise).  More details about IPv4 and IPv6
      configuration attributes are provided in Section 3.15 of <xref target="RFC7296"></xref>. target="RFC7296"
      sectionFormat="of" section="3.15"/>. These attributes are used to infer
      the requested/assigned AFs listed in Table 1.</t> <xref
      target="notification_status"/>.</t>
      <t>The responder MUST <bcp14>MUST</bcp14> include the IP6_ALLOWED and/or IP4_ALLOWED
      notification status type in a response to an address assignment request
      as indicated in Table 1. <figure>
          <artwork><![CDATA[   +----------------+----------------+---------------+-----------------+
   |                |                |               |     Returned    |
   |   Requested    |   Supported    |    Assigned   | <xref target="notification_status"/>.</t>

<table anchor="notification_status">
  <name>Returned Notification  |
   | Status Types</name>
  <thead>
    <tr>
      <th>Requested AF(s)      | (Initiator)</th>
      <th>Supported AF(s)      | (Responder)</th>
      <th>Assigned AF(s)     | (Responder)</th>
      <th>Returned Notification Status Type(s) |
   |  (Initiator)   |  (Responder)   |  (Responder)  |   (Responder)   |
   +----------------+----------------+---------------+-----------------+
   |      IPv4      |      IPv6      |      None     |   IP6_ALLOWED   |
   |      IPv4      |      IPv4      |      IPv4     |   IP4_ALLOWED   |
   |      IPv4      | IPv4 and IPv6  |      IPv4     |   IP4_ALLOWED,  |
   |                |                |               |   IP6_ALLOWED   |
   |      IPv6      |      IPv6      |      IPv6     |   IP6_ALLOWED   |
   |      IPv6      |      IPv4      |      None     |   IP4_ALLOWED   |
   |      IPv6      | IPv4 and IPv6  |      IPv6     |   IP4_ALLOWED,  |
   |                |                |               |   IP6_ALLOWED   |
   | IPv4 and IPv6  |      IPv4      |      IPv4     |   IP4_ALLOWED   |
   | IPv4 and IPv6  |      IPv6      |      IPv6     |   IP6_ALLOWED   |
   | IPv4 and IPv6  | IPv4 (Responder)</th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>IPv4</td>
      <td>IPv6</td>
      <td>None</td>
      <td>IP6_ALLOWED</td>
    </tr>
    <tr>
      <td>IPv4</td>
      <td>IPv4</td>
      <td>IPv4</td>
      <td>IP4_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv4</td>
      <td>IPv4 and IPv6</td>
      <td>IPv4</td>
      <td>IP4_ALLOWED, IP6_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv6</td>
      <td>IPv6</td>
      <td>IPv6</td>
      <td>IP6_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv6</td>
      <td>IPv4</td>
      <td>None</td>
      <td>IP4_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv6</td>
      <td>IPv4 and IPv6</td>
      <td>IPv6</td>
      <td>IP4_ALLOWED, IP6_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv4 and IPv6</td>
      <td>IPv4</td>
      <td>IPv4</td>
      <td>IP4_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv4 and IPv6</td>
      <td>IPv6</td>
      <td>IPv6</td>
      <td>IP6_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv4 and IPv6</td>
      <td>IPv4 and IPv6</td>
      <td>IPv4 and IPv6</td>
      <td>IP4_ALLOWED, IP6_ALLOWED</td>
    </tr>

    <tr>
      <td>IPv4 and IPv6  | IPv4 and IPv6 |   IP4_ALLOWED,  |
   |                |                |               |   IP6_ALLOWED   |
   | IPv4 and IPv6  |  IPv4 IPv6</td>
      <td>IPv4 or IPv6  |  IPv4 (policy based)</td>
      <td>IPv4 or IPv6 |   IP4_ALLOWED,  |
   |                | (Policy-based) |               |   IP6_ALLOWED   |
   +----------------+----------------+---------------+-----------------+

                Table 1: Returned Notification Status Types]]></artwork>
        </figure></t> IPv6</td>
      <td>IP4_ALLOWED, IP6_ALLOWED</td>
    </tr>

  </tbody>
</table>

	<t>If the initiator only receives one single notification IP4_ALLOWED
	or IP6_ALLOWED notification from the responder, the initiator MUST NOT <bcp14>MUST
	NOT</bcp14> send a subsequent request for an alternate address family
	not supported by the responder.</t>
	<t>If a dual-stack initiator requests only an IPv6 prefix (or an IPv4
	address) but only receives an IP4_ALLOWED (or IP6_ALLOWED)
	notification status type from the responder, the initiator MUST
	<bcp14>MUST</bcp14> send a request for IPv4 address(es) (or IPv6
	prefix(es)).</t>
	<t>If a dual-stack initiator requests both an IPv6 prefix and an IPv4
	address but receives an IPv6 prefix (or an IPv4 address) only with both
	IP4_ALLOWED and IP6_ALLOWED notification status types from the
	responder, the initiator MAY <bcp14>MAY</bcp14> send a request for the other AF (i.e., IPv4
	address (or IPv6 prefix)).

<!-- [rfced] We had trouble understanding the text starting with "and
request..." here. How may we update for clarity?

Original:
   In such case, the initiator MUST
   create a new IKE Security Association (SA) and request that another
   address family using the new IKE SA.

Perhaps:
   In such case, the initiator MUST
   create a new IKE Security Association (SA) and request that another
   address family use the new IKE SA.

Or:
   In such case, the initiator MUST
   create a new IKE Security Association (SA) and request another
   address family using the new IKE SA.
-->

<!-- get clarification on this one from authors-->

In such case, the initiator <bcp14>MUST</bcp14> create a new IKE Security
Association (SA) and request another address family using the new IKE
SA.</t>

	<t>For other address-related error cases that have not been covered by
	the aforementioned notification status types, the responder/initiator
      MUST
	<bcp14>MUST</bcp14> follow the procedure defined in <xref target="RFC7296">Section
      3.15.4 of</xref>.</t>
	target="RFC7296" sectionFormat="of" section="3.15.4"/>.</t>
      </section>
      <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
	<name>Security Considerations</name>
	<t>Since the IPv4/IPv6 capabilities of a node are readily determined
	from the traffic it generates, this document does not introduce any
	new security considerations compared to the ones described in <xref
      target="RFC7296"></xref>,
	target="RFC7296" format="default"/>, which continue to apply.</t>
      </section>
      <section anchor="sec-IANA" title="IANA Considerations">
      <t>This document requests IANA to update numbered="true" toc="default">
	<name>IANA Considerations</name>
	<t>IANA has updated the "IKEv2 Notify Message Types
	- Status Types" registry available at:
      https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml (available at
	<eref brackets="angle" target="https://www.iana.org/assignments/ikev2-parameters/"/>)
	with the following status types:</t>

      <t><figure>
          <artwork><![CDATA[Value           NOTIFY

  <table anchor="iana">
<name>Updates to "IKEv2 Notify Message Types - Status Types" Registry</name>
    <thead>
      <tr>
	<th>Value</th>
	<th>NOTIFY MESSAGES - STATUS TYPES     Reference
 TBD                   IP4_ALLOWED                 [This-Document]
 TBD                   IP6_ALLOWED                 [This-Document]]]></artwork>
        </figure></t> TYPES</th>
	<th>Reference</th>
      </tr>
    </thead>
    <tbody>
      <tr>
	<td>16439</td>
	<td>IP4_ALLOWED</td>
	<td>RFC 8983</td>
      </tr>
      <tr>
	<td>16440</td>
	<td>IP6_ALLOWED</td>
	<td>RFC 8983</td>
      </tr>
    </tbody>
  </table>

    </section>

  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7849.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6459.xml"/>

    </references>
    </references>

    <section title="Acknowledgements"> numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>Many thanks to Christian Jacquenet <contact fullname="Christian Jacquenet"/> for the review.</t>
      <t>Thanks to Paul Wouters, Yaov Nir, Valery Smyslov, Daniel Migault,
      Tero Kivinen, and Michael Richardson <contact fullname="Paul Wouters"/>, <contact fullname="Yaov
      Nir"/>, <contact fullname="Valery Smyslov"/>, <contact fullname="Daniel
      Migault"/>, <contact fullname="Tero Kivinen"/>, and <contact
      fullname="Michael Richardson"/> for the comments and review.</t>
      <t>Thanks to Benjamin Kaduk <contact fullname="Benjamin Kaduk"/> for the AD review.</t>
      <t>Thanks to Murray Kucherawy, &Eacute;ric Vyncke, and Robert Wilton <contact fullname="Murray Kucherawy"/>, <contact fullname="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/> for
      the IESG review.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.7296"?>

      <?rfc include='reference.RFC.2119'?>

      <?rfc include='reference.RFC.8174'?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.7849"?>

      <?rfc include='reference.RFC.6459'?>

      <!---->
    </references>

  </back>
</rfc>