rfc9395.original   rfc9395.txt 
Network P. Wouters, Ed. Internet Engineering Task Force (IETF) P. Wouters, Ed.
Internet-Draft Aiven Request for Comments: 9395 Aiven
Updates: 8221, 8247 (if approved) 19 December 2022 Updates: 8221, 8247 April 2023
Intended status: Standards Track Category: Standards Track
Expires: 22 June 2023 ISSN: 2070-1721
Deprecation of IKEv1 and obsoleted algorithms Deprecation of the Internet Key Exchange Version 1 (IKEv1) Protocol and
draft-ietf-ipsecme-ikev1-algo-to-historic-09 Obsoleted Algorithms
Abstract Abstract
Internet Key Exchange version 1 (IKEv1) has been deprecated and its Internet Key Exchange Version 1 (IKEv1) has been deprecated, and RFCs
specification in RFC2407, RFC2408 and RFC2409 have been moved to 2407, 2408, and 2409 have been moved to Historic status. This
Historic status. This document updates RFC 8221 and RFC 8247 to document updates RFCs 8221 and 8247 to reflect the usage guidelines
reflect the usage guidelines of old algorithms that are associated of old algorithms that are associated with IKEv1 and are not
with IKEv1, and are not specified or commonly implemented for IKEv2. specified or commonly implemented for IKEv2. This document further
This document further updates the IANA IKEv2 Transform Type updates the IANA registries for IKEv2 "Transform Type Values" by
registries to add a Status column where deprecation status can be adding a "Status" column where the deprecation status can be listed.
listed.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 June 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9395.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. RFC2407, RFC2408 and RFC2409 are Historic . . . . . . . . . . 3 3. RFCs 2407, 2408, and 2409 Are Historic
4. IKEv1 feature equivalents for IKEv2 . . . . . . . . . . . . . 4 4. IKEv1 Feature Equivalents for IKEv2
4.1. IKEv2 postquantum support . . . . . . . . . . . . . . . . 4 4.1. IKEv2 Post-Quantum Support
4.2. IKEv2 Labeled IPsec support . . . . . . . . . . . . . . . 4 4.2. IKEv2 Labeled IPsec Support
4.3. IKEv2 Group SA / Multicast support . . . . . . . . . . . 4 4.3. IKEv2 Group SA and Multicast Support
5. Deprecating obsolete algorithms . . . . . . . . . . . . . . . 4 5. Deprecating Obsolete Algorithms
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References
8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.1. Normative References
8.2. Informative References . . . . . . . . . . . . . . . . . 6 8.2. Informative References
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address
1. Introduction 1. Introduction
IKEv1 has been moved to Historic status. IKEv1 [RFC2409] and its IKEv1 has been moved to Historic status. IKEv1 [RFC2409] and its
related documents for ISAKMP [RFC2408] and IPsec DOI [RFC2407] were related documents for the Internet Security Association and Key
Management Protocol (ISAKMP) [RFC2408] and IPsec DOI [RFC2407] were
obsoleted by IKEv2 [RFC4306] in December 2005. The latest version of obsoleted by IKEv2 [RFC4306] in December 2005. The latest version of
IKEv2 at the time of writing was published in 2014 in [RFC7296]. The IKEv2 at the time of writing was published in 2014 [RFC7296]. Since
Internet Key Exchange (IKE) version 2 has replaced version 1 over 15 IKEv2 replaced IKEv1 over 15 years ago, IKEv2 has now seen wide
years ago. IKEv2 has now seen wide deployment and provides a full deployment, and it provides a full replacement for all IKEv1
replacement for all IKEv1 functionality. No new modifications or new functionality. No new modifications or new algorithms have been
algorithms have been accepted for IKEv1 for at least a decade. IKEv2 accepted for IKEv1 for at least a decade. IKEv2 addresses various
addresses various issues present in IKEv1, such as IKEv1 being issues present in IKEv1, such as IKEv1 being vulnerable to
vulnerable to amplification attacks. amplification attacks.
Algorithm implementation requirements and usage guidelines for IKEv2 Algorithm implementation requirements and usage guidelines for IKEv2
[RFC8247] and ESP/AH [RFC8221] gives guidance to implementors but [RFC8247] and Encapsulating Security Payload (ESP) and Authentication
limits that guidance to avoid broken or weak algorithms. These two Header (AH) [RFC8221] gives guidance to implementors but limits that
RFCs do not deprecate algorithms that have aged and are not in use, guidance to avoid broken or weak algorithms. These two RFCs do not
but leave these algorithms in a state of "MAY be used" by not deprecate algorithms that have aged and are not in use. Instead,
they leave these algorithms in a state of "MAY be used" by not
mentioning them. This document deprecates those unmentioned mentioning them. This document deprecates those unmentioned
algorithms that are no longer advised but for which there are no algorithms that are no longer advised but for which there are no
known attacks resulting in their earlier deprecation. known attacks resulting in their earlier deprecation.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. RFC2407, RFC2408 and RFC2409 are Historic 3. RFCs 2407, 2408, and 2409 Are Historic
IKEv1 is deprecated. Systems running IKEv1 should be upgraded and As IKEv1 is deprecated, systems running IKEv1 should be upgraded and
reconfigured to run IKEv2. Systems that support IKEv1 but not IKEv2 reconfigured to run IKEv2. Systems that support IKEv1 but not IKEv2
are most likely also unsuitable candidates for continued operation: are most likely also unsuitable candidates for continued operation
for the following reasons:
* IKEv1 development ceased over a decade ago and no new work will * IKEv1 development ceased over a decade ago, and no new work will
happen. This poses the risk of unmaintained code in an otherwise happen. This poses the risk of unmaintained code in an otherwise
supported product which can result in security vulnerabilities. supported product, which can result in security vulnerabilities.
* A number of IKEv1 systems have reached their End of Life and * A number of IKEv1 systems have reached their End of Life and,
therefor will never be patched by the vendor if a vulnerability is therefore, will never be patched by the vendor if a vulnerability
found. is found.
* There are vendors that still provide updates for their equipment * There are vendors that still provide updates for their equipment
that supports IKEv1 and IKEv2, but have "frozen" their IKEv1 that supports IKEv1 and IKEv2 but have "frozen" their IKEv1
implementation. Such users might not be aware that they are implementation. Such users might not be aware that they are
running unmaintained code with its associated security risks. running unmaintained code with its associated security risks.
* IKEv1 systems can be abused for packet amplification attacks, as * IKEv1 systems can be abused for packet amplification attacks, as
documented in the Security Bulletin [CVE-2016-5361]. documented in the Security Bulletin [CVE-2016-5361].
* Great strides have been made in cryptography since IKEv1 * Great strides have been made in cryptography since IKEv1
development ceased. While some modern cryptographic algorithms development ceased. While some modern cryptographic algorithms
were added to IKEv1, interoperability concerns mean that the were added to IKEv1, interoperability concerns mean that the
defacto algorithms negotiated by IKEv1 will consist of dated or defacto algorithms negotiated by IKEv1 will consist of dated or
deprecated algorithms like AES-CBC, SHA1, and Diffie-Hellman deprecated algorithms, like AES-CBC, SHA1, and Diffie-Hellman
groups 1 or 2. IKEv2 provides state-of-the-art suite of groups 1 or 2. IKEv2 provides a state-of-the-art suite of
cryptographic algorithms that IKEv1 lacks. cryptographic algorithms that IKEv1 lacks.
IKEv2 is a more secure protocol than IKEv1. For example, IKEv2 IKEv2 is a more secure protocol than IKEv1. For example, IKEv2
offers more modern cryptographic primitives, proper defense against offers more modern cryptographic primitives, proper defense against
denial of service attacks, improved authentication via EAP methods, denial-of-service attacks, improved authentication via Extensible
PAKE support and is actively worked on with respect to defending Authentication Protocol (EAP) methods, and password-authenticated key
against quantum computer attacks. exchange (PAKE) support. Also, IKEv2 is actively worked on with
respect to defending against quantum-computer attacks.
IKEv1-only systems should be upgraded or replaced by systems IKEv1-only systems should be upgraded or replaced by systems
supporting IKEv2. IKEv2 implementations SHOULD NOT directly import supporting IKEv2. IKEv2 implementations SHOULD NOT directly import
IKEv1 configurations without updating the cryptographic algorithms IKEv1 configurations without updating the cryptographic algorithms
used. used.
4. IKEv1 feature equivalents for IKEv2 4. IKEv1 Feature Equivalents for IKEv2
A few notable IKEv1 features are not present in the IKEv2 core A few notable IKEv1 features are not present in the IKEv2 core
specification [RFC7296] but are available for IKEv2 via an additional specification [RFC7296] but are available for IKEv2 via an additional
specification: specification.
4.1. IKEv2 postquantum support 4.1. IKEv2 Post-Quantum Support
IKEv1 and its way of using Preshared Keys (PSKs) protects against IKEv1 and its way of using Preshared Keys (PSKs) protects against
quantum computer based attacks. IKEv2 updated its use of PSK to quantum-computer-based attacks. IKEv2 updated its use of PSKs to
improve the error reporting, but at the expense of post-quantum improve the error reporting but at the expense of post-quantum
security. If post-quantum security is required, these systems should security. If post-quantum security is required, these systems should
be migrated to use IKEv2 Postquantum Preshared Keys (PPK) [RFC8784] be migrated to use IKEv2 Post-quantum Preshared Keys (PPKs)
[RFC8784].
4.2. IKEv2 Labeled IPsec support 4.2. IKEv2 Labeled IPsec Support
Some IKEv1 implementations support Labeled IPsec, a method to Some IKEv1 implementations support Labeled IPsec, a method to
negotiate an additional Security Context selector to the SPD, but negotiate an additional Security Context selector to the Security
this method was never standardized in IKEv1. Those IKEv1 systems Policy Database (SPD), but this method was never standardized in
that require Labeled IPsec should migrate to an IKEv2 system IKEv1. Those IKEv1 systems that require Labeled IPsec should migrate
supporting Labeled IPsec as specified in to an IKEv2 system supporting Labeled IPsec as specified in
[draft-ietf-ipsecme-labeled-ipsec]. [LABELED-IPSEC].
4.3. IKEv2 Group SA / Multicast support 4.3. IKEv2 Group SA and Multicast Support
The Group Domain of Interpretation (GDOI, [RFC6407]) protocol, based The Group Domain of Interpretation (GDOI) protocol [RFC6407], which
on IKEv1 defines the support for Multicast Group SAs. For IKEv2, is based on IKEv1, defines the support for Multicast Group SAs. For
this work is currently in progress via [draft-ietf-ipsecme-g-ikev2] IKEv2, this work is currently in progress via [G-IKEV2].
5. Deprecating obsolete algorithms 5. Deprecating Obsolete Algorithms
This document deprecates the following algorithms: This document deprecates the following algorithms:
* Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the * Encryption Algorithms: RC5, IDEA, CAST, Blowfish, and the
unspecified 3IDEA, ENCR_DES_IV64 and ENCR_DES_IV32 unspecified 3IDEA, ENCR_DES_IV64, and ENCR_DES_IV32
* PRF Algorithms: the unspecified PRF_HMAC_TIGER * PRF Algorithms: the unspecified PRF_HMAC_TIGER
* Integrity Algorithms: HMAC-MD5-128 * Integrity Algorithms: HMAC-MD5-128
* Diffie-Hellman groups: none * Diffie-Hellman groups: none
6. Security Considerations 6. Security Considerations
There are only security benefits by deprecating IKEv1 for IKEv2. There are only security benefits if IKEv1 is deprecated and IKEv2 is
used.
The deprecated algorithms have long been in disuse and are no longer The deprecated algorithms have long been in disuse and are no longer
actively deployed or researched. It presents an unknown security actively deployed or researched; this presents an unknown security
risk that is best avoided. Additionally, these algorithms not being risk that is best avoided. Additionally, these algorithms not being
supported in implementations simplifies those implementations and supported in implementations simplifies those implementations and
reduces the accidental use of these deprecated algorithms through reduces the accidental use of deprecated algorithms through
misconfiguration or downgrade attacks. misconfiguration or downgrade attacks.
7. IANA Considerations 7. IANA Considerations
This document instructs IANA to insert the following line at the top IANA has added the following line at the top of the Notes section of
of the Notes section of the 'Internet Key Exchange (IKE) Attributes' the "Internet Key Exchange (IKE) Attributes" and '"Magic Numbers" for
registry and the '"Magic Numbers" for ISAKMP Protocol' registry: All ISAKMP Protocol' registries: "All registries listed below have been
registries listed below have been closed, see RFCxxxx. [Note to RFC closed. See RFC 9395." In addition, this document has been added to
Editor: change RFCxxx to this document's RFC number] the "Reference" column in these two registries, and their
registration procedures have been changed to "Registry closed".
This document further instructs IANA to add an additional Status
column to the IKEv2 Transform Type registries and mark the following
entries as DEPRECATED:
Transform Type 1 - Encryption Algorithm IDs
Number Name Status IANA has added a "Status" column to the following IKEv2 "Transform
------ --------------- ------ Type Values" registries:
1 ENCR_DES_IV64 DEPRECATED [this document]
2 ENCR_DES DEPRECATED [RFC8247]
4 ENCR_RC5 DEPRECATED [this document]
5 ENCR_IDEA DEPRECATED [this document]
6 ENCR_CAST DEPRECATED [this document]
7 ENCR_BLOWFISH DEPRECATED [this document]
8 ENCR_3IDEA DEPRECATED [this document]
9 ENCR_DES_IV32 DEPRECATED [this document]
Figure 1 Transform Type 1 - Encryption Algorithm Transform IDs
Transform Type 2 - Pseudorandom Function Transform IDs
Transform Type 3 - Integrity Algorithm Transform IDs
Transform Type 4 - Key Exchange Method Transform IDs
Transform Type 2 - Pseudorandom Function Transform IDs Also, the following entries have been marked as DEPRECATED:
Number Name Status +========+===============+=======================+
------ ------------ ---------- | Number | Name | Status |
1 PRF_HMAC_MD5 DEPRECATED [RFC8247] +========+===============+=======================+
3 PRF_HMAC_TIGER DEPRECATED [this document] | 1 | ENCR_DES_IV64 | DEPRECATED (RFC 9395) |
+--------+---------------+-----------------------+
| 2 | ENCR_DES | DEPRECATED [RFC8247] |
+--------+---------------+-----------------------+
| 4 | ENCR_RC5 | DEPRECATED (RFC 9395) |
+--------+---------------+-----------------------+
| 5 | ENCR_IDEA | DEPRECATED (RFC 9395) |
+--------+---------------+-----------------------+
| 6 | ENCR_CAST | DEPRECATED (RFC 9395) |
+--------+---------------+-----------------------+
| 7 | ENCR_BLOWFISH | DEPRECATED (RFC 9395) |
+--------+---------------+-----------------------+
| 8 | ENCR_3IDEA | DEPRECATED (RFC 9395) |
+--------+---------------+-----------------------+
| 9 | ENCR_DES_IV32 | DEPRECATED (RFC 9395) |
+--------+---------------+-----------------------+
Figure 2 Table 1: Transform Type 1 - Encryption
Algorithm Transform IDs
Transform Type 3 - Integrity Algorithm Transform IDs +========+================+=======================+
| Number | Name | Status |
+========+================+=======================+
| 1 | PRF_HMAC_MD5 | DEPRECATED [RFC8247] |
+--------+----------------+-----------------------+
| 3 | PRF_HMAC_TIGER | DEPRECATED (RFC 9395) |
+--------+----------------+-----------------------+
Number Name Status Table 2: Transform Type 2 - Pseudorandom
------ ----------------- ---------- Function Transform IDs
1 AUTH_HMAC_MD5_96 DEPRECATED [RFC8247]
3 AUTH_DES_MAC DEPRECATED [RFC8247]
4 AUTH_KPDK_MD5 DEPRECATED [RFC8247]
6 AUTH_HMAC_MD5_128 DEPRECATED [this document]
7 AUTH_HMAC_SHA1_160 DEPRECATED [this document]
Figure 3 +========+====================+=======================+
| Number | Name | Status |
+========+====================+=======================+
| 1 | AUTH_HMAC_MD5_96 | DEPRECATED [RFC8247] |
+--------+--------------------+-----------------------+
| 3 | AUTH_DES_MAC | DEPRECATED [RFC8247] |
+--------+--------------------+-----------------------+
| 4 | AUTH_KPDK_MD5 | DEPRECATED [RFC8247] |
+--------+--------------------+-----------------------+
| 6 | AUTH_HMAC_MD5_128 | DEPRECATED (RFC 9395) |
+--------+--------------------+-----------------------+
| 7 | AUTH_HMAC_SHA1_160 | DEPRECATED (RFC 9395) |
+--------+--------------------+-----------------------+
Transform Type 4 - Diffie Hellman Group Transform IDs Table 3: Transform Type 3 - Integrity Algorithm
Transform IDs
Number Name Status +========+==============================+======================+
------ ---------------------------- ---------- | Number | Name | Status |
1 768-bit MODP Group DEPRECATED [RFC8247] +========+==============================+======================+
22 1024-bit MODP Group with | 1 | 768-bit MODP Group | DEPRECATED [RFC8247] |
160-bit Prime Order Subgroup DEPRECATED [RFC8247] +--------+------------------------------+----------------------+
| 22 | 1024-bit MODP Group with | DEPRECATED [RFC8247] |
| | 160-bit Prime Order Subgroup | |
+--------+------------------------------+----------------------+
Figure 4 Table 4: Transform Type 4 - Key Exchange Method Transform IDs
All entries not mentioned here should receive no value in the new All entries not mentioned here should receive no value in the new
Status field. Status field.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 7, line 6 skipping to change at line 303
[RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault, [RFC8247] Nir, Y., Kivinen, T., Wouters, P., and D. Migault,
"Algorithm Implementation Requirements and Usage Guidance "Algorithm Implementation Requirements and Usage Guidance
for the Internet Key Exchange Protocol Version 2 (IKEv2)", for the Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 8247, DOI 10.17487/RFC8247, September 2017, RFC 8247, DOI 10.17487/RFC8247, September 2017,
<https://www.rfc-editor.org/info/rfc8247>. <https://www.rfc-editor.org/info/rfc8247>.
8.2. Informative References 8.2. Informative References
[CVE-2016-5361] [CVE-2016-5361]
National Institute of Science and Technology (NIST), NIST National Vulnerability Database, "CVE-2016-5361
"National Vulnerability Database - CVE-2016-5361", 16 June Detail", 16 June 2016,
2016, <https://nvd.nist.gov/vuln/detail/CVE-2016-5361>. <https://nvd.nist.gov/vuln/detail/CVE-2016-5361>.
[draft-ietf-ipsecme-g-ikev2] [G-IKEV2] Smyslov, V. and B. Weis, "Group Key Management using
Smyslov, V. and B. Weis, "Group Key Management using
IKEv2", Work in Progress, Internet-Draft, draft-ietf- IKEv2", Work in Progress, Internet-Draft, draft-ietf-
ipsecme-g-ikev2, 11 January 2021, ipsecme-g-ikev2-09, 19 April 2023,
<https://www.ietf.org/archive/id/draft-ietf-ipsecme- <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
g-ikev2-03.txt>. g-ikev2-09>.
[draft-ietf-ipsecme-labeled-ipsec] [LABELED-IPSEC]
Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector
support for IKEv2", Work in Progress, Internet-Draft, support for IKEv2", Work in Progress, Internet-Draft,
draft-ietf-ipsecme-labeled-ipsec, 25 October 2021, draft-ietf-ipsecme-labeled-ipsec-11, 10 April 2023,
<https://tools.ietf.org/id/draft-ietf-ipsecme-labeled- <https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
ipsec-06.txt>. labeled-ipsec-11>.
[RFC2407] Piper, D., "The Internet IP Security Domain of [RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, Interpretation for ISAKMP", RFC 2407,
DOI 10.17487/RFC2407, November 1998, DOI 10.17487/RFC2407, November 1998,
<https://www.rfc-editor.org/info/rfc2407>. <https://www.rfc-editor.org/info/rfc2407>.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner, [RFC2408] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol "Internet Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998,
<https://www.rfc-editor.org/info/rfc2408>. <https://www.rfc-editor.org/info/rfc2408>.
 End of changes. 53 change blocks. 
154 lines changed or deleted 179 lines changed or added

This html diff was produced by rfcdiff 1.48.