draft-ietf-ippm-ioam-direct-export-05.txt   draft-ietf-ippm-ioam-direct-export-06.txt 
IPPM H. Song IPPM H. Song
Internet-Draft Futurewei Internet-Draft Futurewei
Intended status: Standards Track B. Gafni Intended status: Standards Track B. Gafni
Expires: January 13, 2022 Nvidia Expires: February 9, 2022 Nvidia
T. Zhou T. Zhou
Z. Li Z. Li
Huawei Huawei
F. Brockners F. Brockners
Cisco Cisco
S. Bhandari, Ed. S. Bhandari, Ed.
Thoughtspot Thoughtspot
R. Sivakolundu R. Sivakolundu
Cisco Cisco
T. Mizrahi, Ed. T. Mizrahi, Ed.
Huawei Huawei
July 12, 2021 August 8, 2021
In-situ OAM Direct Exporting In-situ OAM Direct Exporting
draft-ietf-ippm-ioam-direct-export-05 draft-ietf-ippm-ioam-direct-export-06
Abstract Abstract
In-situ Operations, Administration, and Maintenance (IOAM) is used In-situ Operations, Administration, and Maintenance (IOAM) is used
for recording and collecting operational and telemetry information. for recording and collecting operational and telemetry information.
Specifically, IOAM allows telemetry data to be pushed into data Specifically, IOAM allows telemetry data to be pushed into data
packets while they traverse the network. This document introduces a packets while they traverse the network. This document introduces a
new IOAM option type called the Direct Export (DEX) option, which is new IOAM option type called the Direct Export (DEX) option, which is
used as a trigger for IOAM data to be directly exported or locally used as a trigger for IOAM data to be directly exported or locally
aggregated without being pushed into in-flight data packets. The aggregated without being pushed into in-flight data packets. The
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 13, 2022. This Internet-Draft will expire on February 9, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3 3. The Direct Exporting (DEX) IOAM Option Type . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. DEX Packet Selection . . . . . . . . . . . . . . . . 5 3.1.1. DEX Packet Selection . . . . . . . . . . . . . . . . 5
3.1.2. Responding to the DEX Trigger . . . . . . . . . . . . 5 3.1.2. Responding to the DEX Trigger . . . . . . . . . . . . 5
3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 6 3.2. The DEX Option Format . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. IOAM Type . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 8 4.2. IOAM DEX Flags . . . . . . . . . . . . . . . . . . . . . 8
5. Performance Considerations . . . . . . . . . . . . . . . . . 8 4.3. IOAM DEX Extension-Flags . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Performance Considerations . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Hop Limit and Hop Count in Direct Exporting . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Hop Limit in Direct Exporting . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the IOAM [I-D.ietf-ippm-ioam-data] is used for monitoring traffic in the
network, and for incorporating IOAM data fields into in-flight data network, and for incorporating IOAM data fields into in-flight data
packets. packets.
IOAM makes use of four possible IOAM options, defined in IOAM makes use of four possible IOAM options, defined in
[I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental [I-D.ietf-ippm-ioam-data]: Pre-allocated Trace Option, Incremental
Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option. Trace Option, Proof of Transit (POT) Option, and Edge-to-Edge Option.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
to prevent nested exporting and/or exporting loops. to prevent nested exporting and/or exporting loops.
A transit IOAM node that does not support the DEX option SHOULD A transit IOAM node that does not support the DEX option SHOULD
ignore it. A decapsulating node that does not support the DEX option ignore it. A decapsulating node that does not support the DEX option
MUST remove it, along with any other IOAM options carried in the MUST remove it, along with any other IOAM options carried in the
packet if such exist. packet if such exist.
3.2. The DEX Option Format 3.2. The DEX Option Format
The format of the DEX option is depicted in Figure 2. The length of The format of the DEX option is depicted in Figure 2. The length of
the DEX option is either 8 octets or 16 octets, as the Flow ID and the DEX option is at least 8 octets. The DEX option MAY include one
the Sequence Number fields (summing up to 8 octets) are optional. It or more optional fields. The existence of the optional fields is
is assumed that the lower layer protocol indicates the length of the indicated by the corresponding flags in the Extension-Flags field.
DEX option, thus indicating whether the two optional fields are Two optional fields are defined in this document, the Flow ID and the
present. Sequence Number fields. Every optional field MUST be exactly 4
octets long. Thus, the Extension-Flags field explicitly indicates
the length of the DEX option. Defining a new optional field requires
an allocation of a corresponding flag in the Extension-Flags field,
as specified in Section 4.2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Namespace-ID | Flags | | Namespace-ID | Flags |Extension-Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IOAM-Trace-Type | Reserved | | IOAM-Trace-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flow ID (optional) | | Flow ID (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number (Optional) | | Sequence Number (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: DEX Option Format Figure 2: DEX Option Format
Namespace-ID A 16-bit identifier of the IOAM namespace, as defined Namespace-ID A 16-bit identifier of the IOAM namespace, as defined
in [I-D.ietf-ippm-ioam-data]. in [I-D.ietf-ippm-ioam-data].
Flags A 16-bit field, comprised of 16 one-bit subfields. Flags An 8-bit field, comprised of 8 one-bit subfields.
Flags are allocated by IANA, as defined in Flags are allocated by IANA, as defined in
Section 4.2. Section 4.2.
Extension-Flags An 8-bit field, comprised of 8 one-bit subfields.
Extension-Flags are allocated by IANA, as defined in
Section 4.3. Every bit in the Extension-Flag field
that is set to 1 indicates the existence of a
corresponding optional 4-octet field. An IOAM node
that receives a DEX option with an unknown flag set
to 1 MUST ignore the corresponding optional field.
IOAM-Trace-Type A 24-bit identifier which specifies which data fields IOAM-Trace-Type A 24-bit identifier which specifies which data fields
should be exported. The format of this field is as should be exported. The format of this field is as
defined in [I-D.ietf-ippm-ioam-data]. Specifically, defined in [I-D.ietf-ippm-ioam-data]. Specifically,
bit 23, which corresponds to the Checksum Complement the bit that corresponds to the Checksum Complement
data field, should be assigned to be zero by the IOAM data field should be assigned to be zero by the IOAM
encapsulating node, and ignored by transit and encapsulating node, and ignored by transit and
decapsulating nodes. The reason for this is that the decapsulating nodes. The reason for this is that the
Checksum Complement is intended for in-flight packet Checksum Complement is intended for in-flight packet
modifications and is not relevant for direct modifications and is not relevant for direct
exporting. exporting.
Reserved This field SHOULD be ignored by the receiver. Reserved This field SHOULD be ignored by the receiver.
Flow ID A 32-bit flow identifier. If the actual Flow ID is Optional fields The optional fields, if present, reside after the
shorter than 32 bits, it is zero padded in its most Reserved field. The order of the optional fields is
significant bits. The field is set at the according to the respective bits that are enabled in
encapsulating node. The Flow ID can be uniformly the Extension-Flags field. Each optional field is 4
assigned by a central controller or algorithmically octets long.
generated by the encapsulating node. The latter
approach cannot guarantee the uniqueness of Flow ID,
yet the conflict probability is small due to the
large Flow ID space. The Flow ID can be used to
correlate the exported data of the same flow from
multiple nodes and from multiple packets.
Sequence Number A 32-bit sequence number starting from 0 and Flow ID An optional 32-bit field representing the flow
increasing by 1 for each following monitored packet identifier. If the actual Flow ID is shorter than 32
from the same flow at the encapsulating node. The bits, it is zero padded in its most significant bits.
Sequence Number, when combined with the Flow ID, The field is set at the encapsulating node. The Flow
ID can be uniformly assigned by a central controller
or algorithmically generated by the encapsulating
node. The latter approach cannot guarantee the
uniqueness of Flow ID, yet the conflict probability
is small due to the large Flow ID space. The Flow ID
can be used to correlate the exported data of the
same flow from multiple nodes and from multiple
packets.
Sequence Number An optional 32-bit sequence number starting from 0
and increasing by 1 for each following monitored
packet from the same flow at the encapsulating node.
The Sequence Number, when combined with the Flow ID,
provides a convenient approach to correlate the provides a convenient approach to correlate the
exported data from the same user packet. exported data from the same user packet.
4. IANA Considerations 4. IANA Considerations
4.1. IOAM Type 4.1. IOAM Type
The "IOAM Type Registry" was defined in Section 7.2 of The "IOAM Type Registry" was defined in Section 7.2 of
[I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the [I-D.ietf-ippm-ioam-data]. IANA is requested to allocate the
following code point from the "IOAM Type Registry" as follows: following code point from the "IOAM Type Registry" as follows:
TBD-type IOAM Direct Export (DEX) Option Type TBD-type IOAM Direct Export (DEX) Option Type
If possible, IANA is requested to allocate code point 4 (TBD-type). If possible, IANA is requested to allocate code point 4 (TBD-type).
4.2. IOAM DEX Flags 4.2. IOAM DEX Flags
IANA is requested to define an "IOAM DEX Flags" registry. This IANA is requested to define an "IOAM DEX Flags" registry. This
registry includes 16 flag bits. Allocation should be performed based registry includes 8 flag bits. Allocation is based on the "RFC
on the "RFC Required" procedure, as defined in [RFC8126]. Required" procedure, as defined in [RFC8126].
New registration requests MUST use the following template:
Bit: Desired bit to be allocated in the 8 bit Flags field of the DEX
option.
Description: Brief description of the newly registered bit.
Reference: Reference to the document that defines the new bit.
4.3. IOAM DEX Extension-Flags
IANA is requested to define an "IOAM DEX Extension-Flags" registry.
This registry includes 8 flag bits. Bit 0 (the most significant bit)
and bit 1 in the registry are allocated by this document, and
described in Section 3.2. Allocation of the other bits should be
performed based on the "RFC Required" procedure, as defined in
[RFC8126].
Bit 0 "Flow ID [RFC XXXX] [RFC Editor: please replace with the RFC
number of the current document]"
Bit 1 "Sequence Number [RFC XXXX] [RFC Editor: please replace with
the RFC number of the current document]"
New registration requests MUST use the following template:
Bit: Desired bit to be allocated in the 8 bit Extension-Flags field
of the DEX option.
Description: Brief description of the newly registered bit.
Reference: Reference to the document that defines the new bit.
5. Performance Considerations 5. Performance Considerations
The DEX option triggers IOAM data to be collected and/or exported The DEX option triggers IOAM data to be collected and/or exported
packets to be exported to a receiving entity (or entities). In some packets to be exported to a receiving entity (or entities). In some
cases this may impact the receiving entity's performance, or the cases this may impact the receiving entity's performance, or the
performance along the paths leading to it. performance along the paths leading to it.
Therefore, the performance impact of these exported packets is Therefore, the performance impact of these exported packets is
limited by taking two measures: at the encapsulating nodes, by limited by taking two measures: at the encapsulating nodes, by
skipping to change at page 9, line 39 skipping to change at page 10, line 42
thus limiting the scope of the threats above and their affect. This thus limiting the scope of the threats above and their affect. This
is a fundamental assumption with respect to the security aspects of is a fundamental assumption with respect to the security aspects of
IOAM, as further discussed in [I-D.ietf-ippm-ioam-data]. IOAM, as further discussed in [I-D.ietf-ippm-ioam-data].
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.ietf-ippm-ioam-data] [I-D.ietf-ippm-ioam-data]
Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields Brockners, F., Bhandari, S., and T. Mizrahi, "Data Fields
for In-situ OAM", draft-ietf-ippm-ioam-data-12 (work in for In-situ OAM", draft-ietf-ippm-ioam-data-14 (work in
progress), February 2021. progress), June 2021.
[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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F. [RFC5475] Zseby, T., Molina, M., Duffield, N., Niccolini, S., and F.
Raspall, "Sampling and Filtering Techniques for IP Packet Raspall, "Sampling and Filtering Techniques for IP Packet
Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009, Selection", RFC 5475, DOI 10.17487/RFC5475, March 2009,
<https://www.rfc-editor.org/info/rfc5475>. <https://www.rfc-editor.org/info/rfc5475>.
skipping to change at page 10, line 18 skipping to change at page 11, line 23
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-ippm-ioam-flags] [I-D.ietf-ippm-ioam-flags]
Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R., Mizrahi, T., Brockners, F., Bhandari, S., Sivakolundu, R.,
Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J. Pignataro, C., Kfir, A., Gafni, B., Spiegel, M., and J.
Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-04 Lemon, "In-situ OAM Flags", draft-ietf-ippm-ioam-flags-05
(work in progress), February 2021. (work in progress), July 2021.
[I-D.song-ippm-postcard-based-telemetry] [I-D.song-ippm-postcard-based-telemetry]
Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou, Song, H., Mirsky, G., Filsfils, C., Abdelsalam, A., Zhou,
T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path T., Li, Z., Shin, J., and K. Lee, "Postcard-based On-Path
Flow Data Telemetry using Packet Marking", draft-song- Flow Data Telemetry using Packet Marking", draft-song-
ippm-postcard-based-telemetry-09 (work in progress), ippm-postcard-based-telemetry-10 (work in progress), July
February 2021. 2021.
[I-D.spiegel-ippm-ioam-rawexport] [I-D.spiegel-ippm-ioam-rawexport]
Spiegel, M., Brockners, F., Bhandari, S., and R. Spiegel, M., Brockners, F., Bhandari, S., and R.
Sivakolundu, "In-situ OAM raw data export with IPFIX", Sivakolundu, "In-situ OAM raw data export with IPFIX",
draft-spiegel-ippm-ioam-rawexport-04 (work in progress), draft-spiegel-ippm-ioam-rawexport-05 (work in progress),
November 2020. July 2021.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
Appendix A. Hop Limit and Hop Count in Direct Exporting Appendix A. Hop Limit in Direct Exporting
In order to help correlate and order the exported packets, it is In order to help correlate and order the exported packets, it is
possible to include the Hop_Lim/Node_ID data field in exported possible to include the Hop_Lim/Node_ID data field in exported
packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the packets; if the IOAM-Trace-Type [I-D.ietf-ippm-ioam-data] has the
Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/ Hop_Lim/Node_ID bit set, then exported packets include the Hop_Lim/
Node_ID data field, which contains the TTL/Hop Limit value from a Node_ID data field, which contains the TTL/Hop Limit value from a
lower layer protocol. lower layer protocol.
An alternative approach was considered during the design of this An alternative approach was considered during the design of this
document, according to which a 1-octet Hop Count field would be document, according to which a 1-octet Hop Count field would be
included in the DEX header (presumably by claiming some space from included in the DEX header (presumably by claiming some space from
the Flags field). The Hop Limit would starts from 0 at the the Flags field). The Hop Limit would starts from 0 at the
encapsulating node and be incremented by each IOAM transit node that encapsulating node and be incremented by each IOAM transit node that
supports the DEX option. In this approach the Hop Count field value supports the DEX option. In this approach the Hop Count field value
would also be included in the exported packet. would also be included in the exported packet.
The main advantage of the Hop_Lim/Node_ID approach is that it
provides information about the current hop count without requiring
each transit node to modify the DEX option, thus simplifying the data
plane functionality of Direct Exporting. The main advantage of the
Hop Count approach that was considered is that it counts the number
of IOAM-capable nodes without relying on the lower layer TTL,
especially when the lower layer cannot prvide the accurate TTL
information, e.g., Layer 2 Ethernet or hierarchical VPN. The Hop
Count approach would also explicitly allow to detect a case where an
IOAM-capable node fails to export packets. It would also be possible
to use a flag to indicate an optional Hop Count field, which enables
to control the tradeoff. On one hand it would address the use cases
that the Hop_Lim/Node_ID cannot cover, and on the other hand it would
not require transit switches to update the option if it was not
supported or disabled. For the sake of simplicity the Hop Count
approach was not pursued, and this field is not incorporated in the
DEX header.
Authors' Addresses Authors' Addresses
Haoyu Song Haoyu Song
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara 95050 Santa Clara 95050
USA USA
Email: haoyu.song@futurewei.com Email: haoyu.song@futurewei.com
 End of changes. 20 change blocks. 
66 lines changed or deleted 101 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/