draft-ietf-ntp-packet-timestamps-04.txt   draft-ietf-ntp-packet-timestamps-05.txt 
NTP Working Group T. Mizrahi NTP Working Group T. Mizrahi
Internet-Draft Huawei Network.IO Innovation Lab Internet-Draft Huawei Network.IO Innovation Lab
Intended status: Informational J. Fabini Intended status: Informational J. Fabini
Expires: April 12, 2019 TU Wien Expires: June 12, 2019 TU Wien
A. Morton A. Morton
AT&T Labs AT&T Labs
October 9, 2018 December 9, 2018
Guidelines for Defining Packet Timestamps Guidelines for Defining Packet Timestamps
draft-ietf-ntp-packet-timestamps-04 draft-ietf-ntp-packet-timestamps-05
Abstract Abstract
This document specifies guidelines for defining binary packet This document specifies guidelines for defining binary packet
timestamp formats in networking protocols at various layers. It also timestamp formats in networking protocols at various layers. It also
presents three recommended timestamp formats. The target audience of presents three recommended timestamp formats. The target audience of
this memo includes network protocol designers. It is expected that a this memo includes network protocol designers. It is expected that a
new network protocol that requires a packet timestamp will, in most new network protocol that requires a packet timestamp will, in most
cases, use one of the recommended timestamp formats. If none of the cases, use one of the recommended timestamp formats. If none of the
recommended formats fits the protocol requirements, the new protocol recommended formats fits the protocol requirements, the new protocol
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 April 12, 2019. This Internet-Draft will expire on June 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 25 skipping to change at page 2, line 25
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Terms used in this Document . . . . . . . . . . . . . . . 3 2.3. Terms used in this Document . . . . . . . . . . . . . . . 3
3. Packet Timestamp Specification Template . . . . . . . . . . . 4 3. Packet Timestamp Specification Template . . . . . . . . . . . 4
4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5 4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5
4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6 4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6
4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6 4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6
4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6 4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6
4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 7 4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 7
4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 8 4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9
5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10 5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10
6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 10 6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 11
6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 12 7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 13
7.1. High-level Control Field Requirements . . . . . . . . . . 12 7.1. High-level Control Field Requirements . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 15 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Timestamps are widely used in network protocols for various purposes, Timestamps are widely used in network protocols for various purposes,
including delay measurement, clock synchronization, and logging or including delay measurement, clock synchronization, and logging or
reporting the time of an event. reporting the time of an event.
Timestamps are represented in the RFC series in one of two forms: Timestamps are represented in the RFC series in one of two forms:
text-based timestamps, and packet timestamps. Text-based timestamps text-based timestamps, and packet timestamps. Text-based timestamps
[RFC3339] are represented as user-friendly strings, and are widely [RFC3339] are represented as user-friendly strings, and are widely
skipping to change at page 7, line 17 skipping to change at page 7, line 17
+ Size: 32 bits. + Size: 32 bits.
+ Units: the unit is 2^(-32) seconds, which is roughly equal to + Units: the unit is 2^(-32) seconds, which is roughly equal to
233 picoseconds. 233 picoseconds.
Epoch: Epoch:
The epoch is 1 January 1900 at 00:00 UTC. The epoch is 1 January 1900 at 00:00 UTC.
Note: As pointed out in [RFC5905], strictly speaking, UTC did not
exist prior to 1 January 1972, but it is convenient to assume it
has existed for all eternity. The current epoch implies that the
timestamp specifies the number of seconds since 1 January 1972 at
00:00 UTC plus 2272060800 (which is the number of seconds between
1 January 1900 and 1 January 1972).
Leap seconds: Leap seconds:
This timestamp format is affected by leap seconds. The timestamp This timestamp format is affected by leap seconds. The timestamp
represents the number of seconds elapsed since the epoch minus the represents the number of seconds elapsed since the epoch minus the
number of leap seconds. number of leap seconds. Thus, during and possibly after the
occurrence of a leap second, the value of the timestamp may
temporarily be ambiguous, as further discussed in Section 5.
Resolution: Resolution:
The resolution is 2^(-32) seconds. The resolution is 2^(-32) seconds.
Wraparound: Wraparound:
This time format wraps around every 2^32 seconds, which is roughly This time format wraps around every 2^32 seconds, which is roughly
136 years. The next wraparound will occur in the year 2036. 136 years. The next wraparound will occur in the year 2036.
4.2.2. NTP 32-bit Timestamp Format 4.2.2. NTP 32-bit Timestamp Format
The Network Time Protocol (NTP) 32-bit timestamp format is defined in The Network Time Protocol (NTP) 32-bit timestamp format is defined in
[RFC5905]. This timestamp format is used in [RFC5905]. This timestamp format is used in
[I-D.ietf-ippm-initial-registry]. This timestamp format should be [I-D.ietf-ippm-initial-registry] and
[I-D.ietf-sfc-nsh-dc-allocation]. This timestamp format should be
preferred in network protocols that are typically deployed in concert preferred in network protocols that are typically deployed in concert
with NTP. The 32-bit format can be used either when space with NTP. The 32-bit format can be used either when space
constraints do not allow the use of the 64-bit format, or when the constraints do not allow the use of the 64-bit format, or when the
32-bit format satisfies the resolution and wraparound requirements. 32-bit format satisfies the resolution and wraparound requirements.
The format is presented in this section according to the template The format is presented in this section according to the template
defined in Section 3. defined in Section 3.
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
skipping to change at page 8, line 26 skipping to change at page 8, line 37
+ Size: 16 bits. + Size: 16 bits.
+ Units: the unit is 2^(-16) seconds, which is roughly equal to + Units: the unit is 2^(-16) seconds, which is roughly equal to
15.3 microseconds. 15.3 microseconds.
Epoch: Epoch:
The epoch is 1 January 1900 at 00:00 UTC. The epoch is 1 January 1900 at 00:00 UTC.
Note: As pointed out in [RFC5905], strictly speaking, UTC did not
exist prior to 1 January 1972, but it is convenient to assume it
has existed for all eternity. The current epoch implies that the
timestamp specifies the number of seconds since 1 January 1972 at
00:00 UTC plus 2272060800 (which is the number of seconds between
1 January 1900 and 1 January 1972).
Leap seconds: Leap seconds:
This timestamp format is affected by leap seconds. The timestamp This timestamp format is affected by leap seconds. The timestamp
represents the number of seconds elapsed since the epoch minus the represents the number of seconds elapsed since the epoch minus the
number of leap seconds. number of leap seconds. Thus, during and possibly after the
occurrence of a leap second, the value of the timestamp may
temporarily be ambiguous, as further discussed in Section 5.
Resolution: Resolution:
The resolution is 2^(-16) seconds. The resolution is 2^(-16) seconds.
Wraparound: Wraparound:
This time format wraps around every 2^16 seconds, which is roughly This time format wraps around every 2^16 seconds, which is roughly
18 hours. 18 hours.
skipping to change at page 9, line 34 skipping to change at page 10, line 10
Nanoseconds: specifies the fractional portion of the number of Nanoseconds: specifies the fractional portion of the number of
seconds since the epoch. seconds since the epoch.
+ Size: 32 bits. + Size: 32 bits.
+ Units: nanoseconds. The value of this field is in the range 0 + Units: nanoseconds. The value of this field is in the range 0
to (10^9)-1. to (10^9)-1.
Epoch: Epoch:
The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI, which is The PTP [IEEE1588] epoch is 1 January 1970 00:00:00 TAI.
31 December 1969 23:59:51.999918 UTC.
Leap seconds: Leap seconds:
This timestamp format is not affected by leap seconds. This timestamp format is not affected by leap seconds.
Resolution: Resolution:
The resolution is 1 nanosecond. The resolution is 1 nanosecond.
Wraparound: Wraparound:
skipping to change at page 10, line 27 skipping to change at page 10, line 47
reference clock such as an NTP server. If time is assumed to be reference clock such as an NTP server. If time is assumed to be
synchronized to a time standard such as UTC or TAI, it should be synchronized to a time standard such as UTC or TAI, it should be
specified in this section. Further considerations may be discussed specified in this section. Further considerations may be discussed
in this section, such as the required timestamp accuracy. in this section, such as the required timestamp accuracy.
Another aspect that should be discussed in this section is leap Another aspect that should be discussed in this section is leap
second [RFC5905] considerations. The timestamp specification second [RFC5905] considerations. The timestamp specification
template (Section 3) specifies whether the timestamp is affected by template (Section 3) specifies whether the timestamp is affected by
leap seconds. It is often the case that further details about leap leap seconds. It is often the case that further details about leap
seconds will need to be defined in the Synchronization Aspects seconds will need to be defined in the Synchronization Aspects
section. Generally speaking, in a timekeeping system that considers section. Generally speaking, a leap second is a one-second
adjustment that is occasionally applied to UTC in order to keep it
aligned to the solar time. A leap second may be either positive or
negative, i.e., the clock may either be shifted one second forwards
or backwards. All leap seconds that have occurred up to the
publication of this document have been in the backwards direction,
and although forward leap seconds are theoretically possible, the
text throughout this document focuses on the common case, which is
the backward leap second. In a timekeeping system that considers
leap seconds, the system clock may be affected by a leap second in leap seconds, the system clock may be affected by a leap second in
one of three possible ways: one of three possible ways:
o The clock is turned backwards one second at the end of the leap o The clock is turned backwards one second at the end of the leap
second. second.
o The clock is frozen during the duration of the leap second. o The clock is frozen during the duration of the leap second.
o The clock is slowed down during and slightly after the duration of o The clock is slowed down during the leap second and adjacent time
the leap second, until the new time value catches up. intervals until the new time value catches up. The interval for
this process, commonly referred to as leap smear, can range from
several seconds to several hours before, during, and/or after the
occurrence of the leap second.
The way leap seconds are handled depends on the synchronization The way leap seconds are handled depends on the synchronization
protocol, and is thus not specified in this document. However, if a protocol, and is thus not specified in this document. However, if a
timestamp format is defined with respect to a timescale that is timestamp format is defined with respect to a timescale that is
affected by leap seconds, the Synchronization Aspects section should affected by leap seconds, the Synchronization Aspects section should
specify how the use of leap seconds affects the timestamp usage. specify how the use of leap seconds affects the timestamp usage.
6. Timestamp Use Cases 6. Timestamp Use Cases
Packet timestamps are used in various network protocols. Typical Packet timestamps are used in various network protocols. Typical
skipping to change at page 11, line 25 skipping to change at page 12, line 25
| TWAMP [RFC8186] | | | + | | | TWAMP [RFC8186] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| TRILL [RFC7456] | | | + | | | TRILL [RFC7456] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| MPLS [RFC6374] | | | + | | | MPLS [RFC6374] | | | + | |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| TCP [RFC1323] | | | | + | | TCP [RFC1323] | | | | + |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| RTP [RFC3550] | + | | | + | | RTP [RFC3550] | + | | | + |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| IPFIX [RFC7011] | | | | + |
+------------------+-----------+-----------+-----------+-----------+
| [I-D.ietf-ippm- | + | + | | | | [I-D.ietf-ippm- | + | + | | |
| initial-registry]| | | | | | initial-registry]| | | | |
+------------------+-----------+-----------+-----------+-----------+ +------------------+-----------+-----------+-----------+-----------+
| [I-D.ietf-sfc-nsh| | + | + | |
| -dc-allocation] | | | | |
+------------------+-----------+-----------+-----------+-----------+
Figure 4: Protocols that use Packet Timestamps Figure 4: Protocols that use Packet Timestamps
The rest of this section presents two hypothetic examples of network The rest of this section presents two hypothetic examples of network
protocol specifications that use one of the recommended timestamp protocol specifications that use one of the recommended timestamp
formats. The examples include the text that specifies the formats. The examples include the text that specifies the
information related to the timestamp format. information related to the timestamp format.
6.1. Example 1 6.1. Example 1
skipping to change at page 12, line 13 skipping to change at page 13, line 18
an NTP server. Since the NTP time format is affected by leap an NTP server. Since the NTP time format is affected by leap
seconds, the current timestamp format is similarly affected. seconds, the current timestamp format is similarly affected.
Thus, the value of a timestamp during or slightly after a leap Thus, the value of a timestamp during or slightly after a leap
second may be temporarily inaccurate. second may be temporarily inaccurate.
6.2. Example 2 6.2. Example 2
Timestamp: Timestamp:
The timestamp format used in this specification is the PTP The timestamp format used in this specification is the PTP
[IEEE1588] Truncated format, as specified in Section 4.2.3 of [IEEE1588] Truncated format, as specified in Section 4.3 of
[I-D.ietf-ntp-packet-timestamps]. [I-D.ietf-ntp-packet-timestamps].
Synchronization aspects: Synchronization aspects:
It is assumed that nodes that run this protocol are synchronized It is assumed that nodes that run this protocol are synchronized
among themselves. Nodes may be synchronized to a global reference among themselves. Nodes may be synchronized to a global reference
time. Note that if PTP [IEEE1588] is used for synchronization, time. Note that if PTP [IEEE1588] is used for synchronization,
the timestamp may be derived from the PTP-synchronized clock, the timestamp may be derived from the PTP-synchronized clock,
allowing the timestamp to be measured with respect to the clock of allowing the timestamp to be measured with respect to the clock of
an PTP Grandmaster clock. an PTP Grandmaster clock.
skipping to change at page 14, line 43 skipping to change at page 16, line 8
to one of the paths. to one of the paths.
In many cases timestamping relies on an underlying synchronization In many cases timestamping relies on an underlying synchronization
mechanism. Thus, any attack that compromises the synchronization mechanism. Thus, any attack that compromises the synchronization
mechanism can also compromise protocols that use timestamping. mechanism can also compromise protocols that use timestamping.
Attacks on time protocols are discussed in detail in [RFC7384]. Attacks on time protocols are discussed in detail in [RFC7384].
10. Acknowledgments 10. Acknowledgments
The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney
Cummings and other members of the NTP working group for many helpful Cummings, Miroslav Lichvar, Denis Reilly, and other members of the
comments. The authors gratefully acknowledge Harlan Stenn and the NTP working group for many helpful comments. The authors gratefully
people from the Network Time Foundation for sharing their thoughts acknowledge Harlan Stenn and the people from the Network Time
and ideas. Foundation for sharing their thoughts and ideas.
11. References 11. References
11.1. Normative References 11.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,
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>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-ippm-initial-registry] [I-D.ietf-ippm-initial-registry]
Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza, Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
"Initial Performance Metric Registry Entries", draft-ietf- "Initial Performance Metric Registry Entries", draft-ietf-
ippm-initial-registry-07 (work in progress), June 2018. ippm-initial-registry-08 (work in progress), October 2018.
[I-D.ietf-ntp-packet-timestamps] [I-D.ietf-ntp-packet-timestamps]
Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
Defining Packet Timestamps", draft-ietf-ntp-packet- Defining Packet Timestamps", draft-ietf-ntp-packet-
timestamps-03 (work in progress), August 2018. timestamps-04 (work in progress), October 2018.
[I-D.ietf-sfc-nsh-dc-allocation]
Guichard, J., Smith, M., Kumar, S., Majee, S., and T.
Mizrahi, "Network Service Header (NSH) MD Type 1: Context
Header Allocation (Data Center)", draft-ietf-sfc-nsh-dc-
allocation-02 (work in progress), September 2018.
[IEEE1588] [IEEE1588]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems Version 2", 2008. Control Systems Version 2", 2008.
[IEEE1588v1] [IEEE1588v1]
IEEE, "IEEE 1588 Standard for a Precision Clock IEEE, "IEEE 1588 Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems", 2002. Control Systems", 2002.
skipping to change at page 16, line 33 skipping to change at page 17, line 46
[RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay
Measurement for MPLS Networks", RFC 6374, Measurement for MPLS Networks", RFC 6374,
DOI 10.17487/RFC6374, September 2011, DOI 10.17487/RFC6374, September 2011,
<https://www.rfc-editor.org/info/rfc6374>. <https://www.rfc-editor.org/info/rfc6374>.
[RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
RFC 6991, DOI 10.17487/RFC6991, July 2013, RFC 6991, DOI 10.17487/RFC6991, July 2013,
<https://www.rfc-editor.org/info/rfc6991>. <https://www.rfc-editor.org/info/rfc6991>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<https://www.rfc-editor.org/info/rfc7011>.
[RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in [RFC7384] Mizrahi, T., "Security Requirements of Time Protocols in
Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384, Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
October 2014, <https://www.rfc-editor.org/info/rfc7384>. October 2014, <https://www.rfc-editor.org/info/rfc7384>.
[RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and [RFC7456] Mizrahi, T., Senevirathne, T., Salam, S., Kumar, D., and
D. Eastlake 3rd, "Loss and Delay Measurement in D. Eastlake 3rd, "Loss and Delay Measurement in
Transparent Interconnection of Lots of Links (TRILL)", Transparent Interconnection of Lots of Links (TRILL)",
RFC 7456, DOI 10.17487/RFC7456, March 2015, RFC 7456, DOI 10.17487/RFC7456, March 2015,
<https://www.rfc-editor.org/info/rfc7456>. <https://www.rfc-editor.org/info/rfc7456>.
 End of changes. 21 change blocks. 
32 lines changed or deleted 78 lines changed or added

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