rfc8983xml2.original.xml   rfc8983.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-ipsecme-ipv6
There has to be one entity for each item to be referenced. -ipv4-codes-06"
An alternate method (rfc include) is described in the references. --> number="8983" ipr="trust200902" updates="7296" obsoletes="" submissionType="IETF
]> "
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="4"
<!-- used by XSLT processors --> symRefs="true" sortRefs="true" version="3">
<!-- 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 -->
<rfc category="std" docName="draft-ietf-ipsecme-ipv6-ipv4-codes-06"
ipr="trust200902" updates="7296">
<front> <front>
<title abbrev="IPv4/IPv6 Notification Status Types">IKEv2 Notification <title abbrev="IPv4/IPv6 Notification Status Types">Internet Key Exchange Pr otocol Version 2 (IKEv2) Notification
Status Types for IPv4/IPv6 Coexistence</title> Status Types for IPv4/IPv6 Coexistence</title>
<seriesInfo name="RFC" value="8983"/>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair"> <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<postal> <postal>
<street></street> <street/>
<city>Rennes</city> <city>Rennes</city>
<code>35000</code> <code>35000</code>
<country>France</country> <country>France</country>
</postal> </postal>
<email>mohamed.boucadair@orange.com</email> <email>mohamed.boucadair@orange.com</email>
</address> </address>
</author> </author>
<date month="February" year="2021"/>
<date day="17" month="December" year="2020" />
<workgroup>ipsecme</workgroup> <workgroup>ipsecme</workgroup>
<keyword>IPv4 service continuity</keyword> <keyword>IPv4 service continuity</keyword>
<keyword>VoLTE</keyword> <keyword>VoLTE</keyword>
<keyword>Handover</keyword> <keyword>Handover</keyword>
<keyword>Service continuity</keyword> <keyword>Service continuity</keyword>
<keyword>3GPP</keyword> <keyword>3GPP</keyword>
<keyword>IPv6 transition</keyword> <keyword>IPv6 transition</keyword>
<keyword>TS.24302</keyword> <keyword>TS.24302</keyword>
<keyword>PDP context</keyword> <keyword>PDP context</keyword>
<keyword>PDP type</keyword> <keyword>PDP type</keyword>
<abstract> <abstract>
<t>This document specifies new IKEv2 notification status types to better <t>This document specifies new Internet Key Exchange Protocol Version 2 (I
manage IPv4 and IPv6 co-existence by allowing the responder to signal to KEv2) notification status types to better
manage IPv4 and IPv6 coexistence by allowing the responder to signal to
the initiator which address families are allowed.</t> the initiator which address families are allowed.</t>
<t>This document updates RFC 7296.</t>
<t>This document updates RFC7296.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction"> <section numbered="true" toc="default">
<t>As described in <xref target="RFC7849"></xref>, if the subscription <name>Introduction</name>
<t>As described in <xref target="RFC7849" format="default"/>, if the subsc
ription
data or network configuration allows only one IP address family (IPv4 or data or network configuration allows only one IP address family (IPv4 or
IPv6), the cellular host must not request a second PDP-Context (Section IPv6), the cellular host must not request a second PDP-Context (<xref targ
3.2 of <xref target="RFC6459"></xref>) to the same Access Point Name et="RFC6459" sectionFormat="of" section="3.2"/>) to the same Access Point Name
(APN) for the other IP address family (AF). The Third Generation (APN) for the other IP address family (AF). The Third Generation
Partnership Project (3GPP) network informs the cellular host about Partnership Project (3GPP) network informs the cellular host about
allowed Packet Data Protocol (PDP) types by means of Session Management allowed Packet Data Protocol (PDP) types by means of Session Management
(SM) cause codes. In particular, the following cause codes can be (SM) cause codes. In particular, the following cause codes can be
returned: <list style="symbols"> returned: </t>
<t>cause #50 "PDP type IPv4 only allowed": 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 #51 "PDP type IPv6 only allowed": This cause code is used <dl>
by the network to indicate that only PDP type IPv6 is allowed for
the requested PDN connectivity.</t>
<t>cause #52 "single address bearers only allowed": This cause code <dt>cause #50 "PDP type IPv4 only allowed":
is used by the network to indicate that the requested PDN </dt>
connectivity is accepted with the restriction that only single IP <dd>This cause code is used by the network to indicate that only PDP type IPv4
version bearers are allowed.</t> is allowed for the requested Public Data Network (PDN) connectivity.
</list></t> </dd>
<dt>cause #51 "PDP type IPv6 only allowed":
</dt>
<dd>This cause code is used by the network to indicate that only PDP type IPv6
is allowed for the requested PDN connectivity.
</dd>
<dt>cause #52 "single address bearers only allowed":
</dt>
<dd>This cause code is used by the network to indicate that the requested PDN co
nnectivity is accepted with the restriction that only single IP version bearers
are allowed.
</dd>
</dl>
<t>If the requested IPv4v6 PDP-Context is not supported by the network <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 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 configured with an IPv4 address or an IPv6 prefix by the network. It
must initiate another PDP-Context activation of the other address family 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 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 initiating a second PDP-Context is to achieve dual-stack connectivity
(that is, IPv4 and IPv6 connectivity) by means of two PDP-Contexts.</t> (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 <t>When the User Equipment (UE) attaches to the 3GPP network using a
non-3GPP access network (e.g., Wireless Local Area Network (WLAN)), non-3GPP access network (e.g., Wireless Local Area Network (WLAN)),
there are no equivalent Internet Key Exchange Protocol Version 2 (IKEv2) there are no equivalent IKEv2
capabilities <xref target="RFC7296"></xref> notification codes for the capabilities <xref target="RFC7296" format="default"/> notification codes
for the
3GPP network to inform the UE why an IP address family is not assigned 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> or whether that UE should retry with another address family.</t>
<t>This document fills that void by introducing new IKEv2 notification <t>This document fills that void by introducing new IKEv2 notification
status types for the sake of deterministic UE behaviors (<xref status types for the sake of deterministic UE behaviors (<xref target="new
target="new"></xref>).</t> " format="default"/>).</t>
<t>These notification status types are not specific to 3GPP <t>These notification status types are not specific to 3GPP
architectures, but can be used in other deployment contexts. Cellular architectures but can be used in other deployment contexts. Cellular
networks are provided as an illustration example.</t> networks are provided as an illustration example.</t>
</section> </section>
<section anchor="notation" numbered="true" toc="default">
<name>Terminology</name>
<section anchor="notation" title="Terminology"> <t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in BCP 14 NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
<xref target="RFC2119"></xref><xref target="RFC8174"></xref> when, and "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals,
as shown here.
</t>
<t>This document makes use of the terms defined in <xref <t>This document makes use of the terms defined in <xref target="RFC7296"
target="RFC7296"></xref>. In particular, readers should be familiar with format="default"/>. In particular, readers should be familiar with
"initiator" and "responder" terms used in that document.</t> "initiator" and "responder" terms used in that document.</t>
</section> </section>
<section numbered="true" toc="default">
<name>Why Not INTERNAL_ADDRESS_FAILURE?</name>
<section title="Why Not INTERNAL_ADDRESS_FAILURE?">
<t>The following address assignment failures may be encountered when an <t>The following address assignment failures may be encountered when an
initiator requests assignment of IP addresses/prefixes:<list initiator requests assignment of IP addresses/prefixes:</t>
style="symbols"> <ul spacing="normal">
<t>An initiator asks for IPvx, but IPvx address assignment is not <li>An initiator asks for IPvx, but IPvx address assignment is not
supported by the responder.</t> supported by the responder.</li>
<li>An initiator requests both IPv4 and IPv6 addresses, but only IPv4
<t>An initiator requests both IPv4 and IPv6 addresses, but only IPv4 address assignment is supported by the responder.</li>
address assignment is supported by the responder.</t> <li>An initiator requests both IPv4 and IPv6 addresses, but only IPv6
prefix assignment is supported by the responder.</li>
<t>An initiator requests both IPv4 and IPv6 addresses, but only IPv6 <li>An initiator asks for both IPv4 and IPv6 addresses, but only one
prefix assignment is supported by the responder.</t>
<t>An initiator asks for both IPv4 and IPv6 addresses, but only one
address family can be assigned by the responder for policy address family can be assigned by the responder for policy
reasons.</t> reasons.</li>
</list></t> </ul>
<t>
<t><xref target="RFC7296">Section 3.15.4 of</xref> defines a generic <xref target="RFC7296" sectionFormat="of" section="3.15.4"/> defines a
notification error type (INTERNAL_ADDRESS_FAILURE) that is related to a generic notification error type (INTERNAL_ADDRESS_FAILURE) that is
failure to handle an address assignment request. The responder sends related to a failure to handle an address assignment request. The
INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned. This responder sends INTERNAL_ADDRESS_FAILURE only if no addresses can be
behavior does not explicitly allow an initiator to determine why a given assigned. This behavior does not explicitly allow an initiator to
address family is not assigned, nor whether it should try using another determine why a given address family is not assigned, nor whether it
address family. INTERNAL_ADDRESS_FAILURE is a catch-all error type when should try using another address family. INTERNAL_ADDRESS_FAILURE is a
an address-related issue is encountered by an IKEv2 responder.</t> 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 <t>INTERNAL_ADDRESS_FAILURE does not provide sufficient hints to the
IKEv2 initiator to adjust its behavior.</t> IKEv2 initiator to adjust its behavior.</t>
</section> </section>
<section anchor="new" numbered="true" toc="default">
<section anchor="new" title="IP6_ALLOWED and IP4_ALLOWED Status Types"> <name>IP6_ALLOWED and IP4_ALLOWED Status Types</name>
<t>IP6_ALLOWED and IP4_ALLOWED notification status types (see <xref <t>IP6_ALLOWED and IP4_ALLOWED notification status types (see <xref target
target="sec-IANA"></xref>) are defined to inform the initiator about the ="sec-IANA" format="default"/>) are defined to inform the initiator about the
responder's address family assignment support capabilities, and to responder's address family assignment support capabilities and to
report to the initiator the reason why an address assignment failed. report to the initiator the reason why an address assignment failed.
These notification status types are used by the initiator to adjust its These notification status types are used by the initiator to adjust its
behavior accordingly (<xref target="update"></xref>).</t> behavior accordingly (<xref target="update" format="default"/>).</t>
<t>No data is associated with these notifications.</t> <t>No data is associated with these notifications.</t>
</section> </section>
<section anchor="update" numbered="true" toc="default">
<name>Update to RFC 7296</name>
<section anchor="update" title="An Update to RFC7296"> <t>If the initiator is dual stack (i.e., supports both IPv4 and IPv6),
<t>If the initiator is dual-stack (i.e., supports both IPv4 and IPv6), it <bcp14>MUST</bcp14> include configuration attributes for both address
it MUST include both address families configuration attributes in its families in its configuration request (absent explicit
configuration request (absent explicit policy/configuration otherwise). policy/configuration otherwise). More details about IPv4 and IPv6
More details about IPv4 and IPv6 configuration attributes are provided configuration attributes are provided in <xref target="RFC7296"
in Section 3.15 of <xref target="RFC7296"></xref>. These attributes are sectionFormat="of" section="3.15"/>. These attributes are used to infer
used to infer the requested/assigned AFs listed in Table 1.</t> the requested/assigned AFs listed in <xref
target="notification_status"/>.</t>
<t>The responder MUST include IP6_ALLOWED and/or IP4_ALLOWED <t>The responder <bcp14>MUST</bcp14> include the IP6_ALLOWED and/or IP4_AL
LOWED
notification status type in a response to an address assignment request notification status type in a response to an address assignment request
as indicated in Table 1. <figure> as indicated in <xref target="notification_status"/>.</t>
<artwork><![CDATA[ +----------------+----------------+--------------
-+-----------------+
| | | | Returned |
| Requested | Supported | Assigned | Notification |
| AF(s) | AF(s) | AF(s) | 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 and IPv6 | IPv4 and IPv6 | IP4_ALLOWED, |
| | | | IP6_ALLOWED |
| IPv4 and IPv6 | IPv4 or IPv6 | IPv4 or IPv6 | IP4_ALLOWED, |
| | (Policy-based) | | IP6_ALLOWED |
+----------------+----------------+---------------+-----------------+
Table 1: Returned Notification Status Types]]></artwork> <table anchor="notification_status">
</figure></t> <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) (Responder)</th>
</tr>
</thead>
<t>If the initiator only receives one single notification IP4_ALLOWED or <tbody>
IP6_ALLOWED from the responder, the initiator MUST NOT send a subsequent <tr>
request for an alternate address family not supported by the <td>IPv4</td>
responder.</t> <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>
<t>If a dual-stack initiator requests only an IPv6 prefix (or an IPv4 <tr>
address) but only receives IP4_ALLOWED (or IP6_ALLOWED) notification <td>IPv4</td>
status type from the responder, the initiator MUST send a request for <td>IPv4 and IPv6</td>
IPv4 address(es) (or IPv6 prefix(es)).</t> <td>IPv4</td>
<td>IP4_ALLOWED, IP6_ALLOWED</td>
</tr>
<t>If a dual-stack initiator requests both an IPv6 prefix and an IPv4 <tr>
address but receives an IPv6 prefix (or an IPv4 address) only with both <td>IPv6</td>
IP4_ALLOWED and IP6_ALLOWED notification status types from the <td>IPv6</td>
responder, the initiator MAY send a request for the other AF (i.e., IPv4 <td>IPv6</td>
address (or IPv6 prefix)). In such case, the initiator MUST create a new <td>IP6_ALLOWED</td>
IKE Security Association (SA) and request that another address family </tr>
using the new IKE SA.</t>
<t>For other address-related error cases that have not been covered by <tr>
the aforementioned notification status types, the responder/initiator <td>IPv6</td>
MUST follow the procedure defined in <xref target="RFC7296">Section <td>IPv4</td>
3.15.4 of</xref>.</t> <td>None</td>
</section> <td>IP4_ALLOWED</td>
</tr>
<section anchor="Security" title="Security Considerations"> <tr>
<t>Since the IPv4/IPv6 capabilities of a node are readily determined <td>IPv6</td>
from the traffic it generates, this document does not introduce any new <td>IPv4 and IPv6</td>
security considerations compared to the ones described in <xref <td>IPv6</td>
target="RFC7296"></xref>, which continue to apply.</t> <td>IP4_ALLOWED, IP6_ALLOWED</td>
</section> </tr>
<section anchor="sec-IANA" title="IANA Considerations"> <tr>
<t>This document requests IANA to update the "IKEv2 Notify Message Types <td>IPv4 and IPv6</td>
- Status Types" registry available at: <td>IPv4</td>
https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml <td>IPv4</td>
with the following status types:</t> <td>IP4_ALLOWED</td>
</tr>
<t><figure> <tr>
<artwork><![CDATA[Value NOTIFY MESSAGES - STATUS TYPES R <td>IPv4 and IPv6</td>
eference <td>IPv6</td>
TBD IP4_ALLOWED [This-Document] <td>IPv6</td>
TBD IP6_ALLOWED [This-Document]]]></artwork> <td>IP6_ALLOWED</td>
</figure></t> </tr>
</section>
<section title="Acknowledgements"> <tr>
<t>Many thanks to Christian Jacquenet for the review.</t> <td>IPv4 and IPv6</td>
<td>IPv4 and IPv6</td>
<td>IPv4 and IPv6</td>
<td>IP4_ALLOWED, IP6_ALLOWED</td>
</tr>
<t>Thanks to Paul Wouters, Yaov Nir, Valery Smyslov, Daniel Migault, <tr>
Tero Kivinen, and Michael Richardson for the comments and review.</t> <td>IPv4 and IPv6</td>
<td>IPv4 or IPv6 (policy based)</td>
<td>IPv4 or IPv6</td>
<td>IP4_ALLOWED, IP6_ALLOWED</td>
</tr>
<t>Thanks to Benjamin Kaduk for the AD review.</t> </tbody>
</table>
<t>Thanks to Murray Kucherawy, &Eacute;ric Vyncke, and Robert Wilton for <t>If the initiator only receives one single IP4_ALLOWED
the IESG review.</t> or IP6_ALLOWED notification from the responder, the initiator <bcp14>MUST
</section> NOT</bcp14> send a subsequent request for an alternate address family
</middle> 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
<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 <bcp14>MAY</bcp14> send a request for the other
AF (i.e., IPv4
address (or IPv6 prefix)).
<!-- *****BACK MATTER ***** --> <!-- [rfced] We had trouble understanding the text starting with "and
request..." here. How may we update for clarity?
<back> Original:
<references title="Normative References"> In such case, the initiator MUST
<?rfc include="reference.RFC.7296"?> create a new IKE Security Association (SA) and request that another
address family using the new IKE SA.
<?rfc include='reference.RFC.2119'?> 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.
<?rfc include='reference.RFC.8174'?> Or:
</references> In such case, the initiator MUST
create a new IKE Security Association (SA) and request another
address family using the new IKE SA.
-->
<references title="Informative References"> <!-- get clarification on this one from authors-->
<?rfc include="reference.RFC.7849"?>
<?rfc include='reference.RFC.6459'?> 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
<bcp14>MUST</bcp14> follow the procedure defined in <xref
target="RFC7296" sectionFormat="of" section="3.15.4"/>.</t>
</section>
<section anchor="Security" 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" format="default"/>, which continue to apply.</t>
</section>
<section anchor="sec-IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>IANA has updated the "IKEv2 Notify Message Types
- Status Types" registry (available at
<eref brackets="angle" target="https://www.iana.org/assignments/ikev2-par
ameters/"/>)
with the following status types:</t>
<table anchor="iana">
<name>Updates to "IKEv2 Notify Message Types - Status Types" Registry</name>
<thead>
<tr>
<th>Value</th>
<th>NOTIFY MESSAGES - STATUS 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.R
FC.7296.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7849.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6459.xml"/>
</references>
</references> </references>
<section numbered="false" toc="default">
<name>Acknowledgements</name>
<t>Many thanks to <contact fullname="Christian Jacquenet"/> for the review
.</t>
<t>Thanks to <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 <contact fullname="Benjamin Kaduk"/> for the AD review.</t>
<t>Thanks to <contact fullname="Murray Kucherawy"/>, <contact fullname="Ér
ic Vyncke"/>, and <contact fullname="Robert Wilton"/> for
the IESG review.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 64 change blocks. 
217 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/