draft-ietf-tsvwg-rfc4960-errata-06.txt   draft-ietf-tsvwg-rfc4960-errata-07.txt 
Network Working Group R. Stewart Network Working Group R. Stewart
Internet-Draft Netflix, Inc. Internet-Draft Netflix, Inc.
Intended status: Informational M. Tuexen Intended status: Informational M. Tuexen
Expires: November 22, 2018 Muenster Univ. of Appl. Sciences Expires: January 17, 2019 Muenster Univ. of Appl. Sciences
M. Proshin M. Proshin
Ericsson Ericsson
May 21, 2018 July 16, 2018
RFC 4960 Errata and Issues RFC 4960 Errata and Issues
draft-ietf-tsvwg-rfc4960-errata-06.txt draft-ietf-tsvwg-rfc4960-errata-07.txt
Abstract Abstract
This document is a compilation of issues found since the publication This document is a compilation of issues found since the publication
of RFC4960 in September 2007 based on experience with implementing, of RFC4960 in September 2007 based on experience with implementing,
testing, and using SCTP along with the suggested fixes. This testing, and using SCTP along with the suggested fixes. This
document provides deltas to RFC4960 and is organized in a time document provides deltas to RFC4960 and is organized in a time
ordered way. The issues are listed in the order they were brought ordered way. The issues are listed in the order they were brought
up. Because some text is changed several times the last delta in the up. Because some text is changed several times the last delta in the
text is the one which should be applied. In addition to the delta a text is the one which should be applied. In addition to the delta a
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 November 22, 2018. This Internet-Draft will expire on January 17, 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 3, line 23 skipping to change at page 3, line 23
3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 67 3.44. Integration of RFC 6335 . . . . . . . . . . . . . . . . . 67
3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 69 3.45. Integration of RFC 7053 . . . . . . . . . . . . . . . . . 69
3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 72 3.46. CRC32c Code Improvements . . . . . . . . . . . . . . . . 72
3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 82 3.47. Clarification of Gap Ack Blocks in SACK Chunks . . . . . 82
3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 84 3.48. Handling of SSN Wrap Arounds . . . . . . . . . . . . . . 84
3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 85 3.49. Update RFC 2119 Boilerplate . . . . . . . . . . . . . . . 85
3.50. Missed Text Removal . . . . . . . . . . . . . . . . . . . 85 3.50. Missed Text Removal . . . . . . . . . . . . . . . . . . . 85
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 86
5. Security Considerations . . . . . . . . . . . . . . . . . . . 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . 86
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 86
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 86 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.1. Normative References . . . . . . . . . . . . . . . . . . 87 7.1. Normative References . . . . . . . . . . . . . . . . . . 87
7.2. Informative References . . . . . . . . . . . . . . . . . 87 7.2. Informative References . . . . . . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
the publication of this document for [RFC4960] specifying the Stream the publication of this document for [RFC4960] specifying the Stream
Control Transmission Protocol (SCTP). These defects may be of an Control Transmission Protocol (SCTP). These defects may be of an
editorial or technical nature. This document may be thought of as a editorial or technical nature. This document may be thought of as a
skipping to change at page 12, line 41 skipping to change at page 12, line 41
Change the figure such that the T1-cookie timer is used instead of Change the figure such that the T1-cookie timer is used instead of
the T1-init timer. the T1-init timer.
3.9. Miscellaneous Typos 3.9. Miscellaneous Typos
3.9.1. Description of the Problem 3.9.1. Description of the Problem
While processing [RFC4960] some typos were not caught. While processing [RFC4960] some typos were not caught.
One typo was reported as an Errata for [RFC4960] with Errata ID 5003.
3.9.2. Text Changes to the Document 3.9.2. Text Changes to the Document
--------- ---------
Old text: (Section 1.6) Old text: (Section 1.6)
--------- ---------
Transmission Sequence Numbers wrap around when they reach 2**32 - 1. Transmission Sequence Numbers wrap around when they reach 2**32 - 1.
That is, the next TSN a DATA chunk MUST use after transmitting TSN = That is, the next TSN a DATA chunk MUST use after transmitting TSN =
2*32 - 1 is TSN = 0. 2*32 - 1 is TSN = 0.
--------- ---------
skipping to change at page 21, line 9 skipping to change at page 21, line 9
3.11.3. Solution Description 3.11.3. Solution Description
Specify that partial_bytes_acked should be reset to 0 after T3-rtx Specify that partial_bytes_acked should be reset to 0 after T3-rtx
timer expiration. timer expiration.
3.12. Order of Adjustments of partial_bytes_acked and cwnd 3.12. Order of Adjustments of partial_bytes_acked and cwnd
3.12.1. Description of the Problem 3.12.1. Description of the Problem
Section 7.2.2 of [RFC4960] likely implies the wrong order of of Section 7.2.2 of [RFC4960] likely implies the wrong order of
adjustments applied to partial_bytes_acked and cwnd in the congestion adjustments applied to partial_bytes_acked and cwnd in the congestion
avoidance phase. avoidance phase.
3.12.2. Text Changes to the Document 3.12.2. Text Changes to the Document
--------- ---------
Old text: (Section 7.2.2) Old text: (Section 7.2.2)
--------- ---------
o When partial_bytes_acked is equal to or greater than cwnd and o When partial_bytes_acked is equal to or greater than cwnd and
skipping to change at page 23, line 42 skipping to change at page 23, line 42
--------- ---------
Furthermore, when its peer is multi-homed, an endpoint SHOULD try to Furthermore, when its peer is multi-homed, an endpoint SHOULD try to
retransmit a chunk that timed out to an active destination transport retransmit a chunk that timed out to an active destination transport
address that is different from the last destination address to which address that is different from the last destination address to which
the DATA chunk was sent. the DATA chunk was sent.
When its peer is multi-homed, an endpoint SHOULD send fast When its peer is multi-homed, an endpoint SHOULD send fast
retransmissions to the same destination transport address where the retransmissions to the same destination transport address where the
original data was sent to. If the primary path has been changed and the original data was sent to. If the primary path has been changed and the
original data was sent there before the fast retransmit, the original data was sent to the old primary path before the fast
implementation MAY send it to the new primary path. retransmit, the implementation MAY send it to the new primary path.
3.14.3. Solution Description 3.14.3. Solution Description
The new text clarifies where to send fast retransmissions. The new text clarifies where to send fast retransmissions.
3.15. Transmittal in Fast Recovery 3.15. Transmittal in Fast Recovery
3.15.1. Description of the Problem 3.15.1. Description of the Problem
The Fast Retransmit on Gap Reports algorithm intends that only the The Fast Retransmit on Gap Reports algorithm intends that only the
skipping to change at page 44, line 33 skipping to change at page 44, line 33
Old text: (Section 7.2.1) Old text: (Section 7.2.1)
--------- ---------
o When the endpoint does not transmit data on a given transport o When the endpoint does not transmit data on a given transport
address, the cwnd of the transport address should be adjusted to address, the cwnd of the transport address should be adjusted to
max(cwnd/2, 4*MTU) per RTO. max(cwnd/2, 4*MTU) per RTO.
--------- ---------
New text: (Section 7.2.1) New text: (Section 7.2.1)
--------- ---------
o When the endpoint does not transmit data on a given transport o While the endpoint does not transmit data on a given transport
address, the cwnd of the transport address SHOULD be adjusted to address, the cwnd of the transport address SHOULD be adjusted to
max(cwnd/2, 4*MTU) per RTO. At the first cwnd adjustment, the max(cwnd/2, 4*MTU) once per RTO. Before the first cwnd adjustment,
ssthresh of the transport address SHOULD be adjusted to the cwnd. the ssthresh of the transport address SHOULD be set to the cwnd.
3.27.3. Solution Description 3.27.3. Solution Description
A rule about cwnd adjustment after a sufficiently long idle period is A rule about cwnd adjustment after a sufficiently long idle period is
removed. removed.
The text is updated to refresh ssthresh after the idle period. When The text is updated to describe the ssthresh handling. When the idle
the idle period is detected, the cwnd value is stored to the ssthresh period is detected, the cwnd value is stored to the ssthresh value.
value.
3.28. Window Updates After Receiver Window Opens Up 3.28. Window Updates After Receiver Window Opens Up
3.28.1. Description of the Problem 3.28.1. Description of the Problem
The sending of SACK chunks for window updates is only indirectly The sending of SACK chunks for window updates is only indirectly
referenced in [RFC4960], Section 6.2, where it is stated that an SCTP referenced in [RFC4960], Section 6.2, where it is stated that an SCTP
receiver must not generate more than one SACK for every incoming receiver must not generate more than one SACK for every incoming
packet, other than to update the offered window. packet, other than to update the offered window.
However, the sending of window updates when the receiver window opens However, the sending of window updates when the receiver window opens
up is necessary to avoid performance problems. up is necessary to avoid performance problems.
skipping to change at page 45, line 32 skipping to change at page 45, line 28
receiving application consumes new data. receiving application consumes new data.
--------- ---------
New text: (Section 6.2) New text: (Section 6.2)
--------- ---------
An SCTP receiver MUST NOT generate more than one SACK for every An SCTP receiver MUST NOT generate more than one SACK for every
incoming packet, other than to update the offered window as the incoming packet, other than to update the offered window as the
receiving application consumes new data. When the window opens receiving application consumes new data. When the window opens
up, an SCTP receiver SHOULD send additional SACK chunks to update up, an SCTP receiver SHOULD send additional SACK chunks to update
the window even if no new data is received. The receiver MUST avoid the window even if no new data is received.
sending large bursts of window updates. The receiver MUST avoid sending a large number of window updates,
in particular large bursts of them.
One way to achieve this is to send a window update only if the
window can be increased by at least a quarter of the receive
buffer size.
3.28.3. Solution Description 3.28.3. Solution Description
The new text makes clear that additional SACK chunks for window The new text makes clear that additional SACK chunks for window
updates should be sent as long as excessive bursts are avoided. updates should be sent as long as excessive bursts are avoided.
3.29. Path of DATA and Reply Chunks 3.29. Path of DATA and Reply Chunks
3.29.1. Description of the Problem 3.29.1. Description of the Problem
skipping to change at page 53, line 7 skipping to change at page 53, line 7
3.35.1. Description of the Problem 3.35.1. Description of the Problem
The upper layer can change the Differentiated Services Code Point The upper layer can change the Differentiated Services Code Point
(DSCP) used for packets being sent. A change of the DSCP can result (DSCP) used for packets being sent. A change of the DSCP can result
in packets hitting different queues on the path and, therefore, the in packets hitting different queues on the path and, therefore, the
congestion control should be initialized when the DSCP is changed by congestion control should be initialized when the DSCP is changed by
the upper layer. This is not described in [RFC4960]. the upper layer. This is not described in [RFC4960].
3.35.2. Text Changes to the Document 3.35.2. Text Changes to the Document
--------- ---------
New text: (Section 7.2.5) New text: (Section 7.2.5)
--------- ---------
7.2.5. Change of Differentiated Services Code Points
SCTP implementations MAY allow an application to configure the SCTP implementations MAY allow an application to configure the
Differentiated Services Code Point (DSCP) used for sending packets. Differentiated Services Code Point (DSCP) used for sending packets.
If a DSCP change might result in outgoing packets being queued in If a DSCP change might result in outgoing packets being queued in
different queues, the congestion control parameters for all affected different queues, the congestion control parameters for all affected
destination addresses MUST be reset to their initial values. destination addresses MUST be reset to their initial values.
--------- ---------
Old text: (Section 10.1) Old text: (Section 10.1)
--------- ---------
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,] [,destination transport address,]
protocol parameter list) protocol parameter list)
-> result -> result
This primitive allows the local SCTP to customize the protocol This primitive allows the local SCTP to customize the protocol
parameters. parameters.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association. o association id - local handle to the SCTP association.
o protocol parameter list - the specific names and values of the o protocol parameter list - the specific names and values of the
protocol parameters (e.g., Association.Max.Retrans; see Section protocol parameters (e.g., Association.Max.Retrans; see Section
15) that the SCTP user wishes to customize. 15) that the SCTP user wishes to customize.
--------- ---------
Old text: (Section 10.1) New text: (Section 10.1)
--------- ---------
M) Set Protocol Parameters M) Set Protocol Parameters
Format: SETPROTOCOLPARAMETERS(association id, Format: SETPROTOCOLPARAMETERS(association id,
[,destination transport address,] [,destination transport address,]
protocol parameter list) protocol parameter list)
-> result -> result
This primitive allows the local SCTP to customize the protocol This primitive allows the local SCTP to customize the protocol
parameters. parameters.
Mandatory attributes: Mandatory attributes:
o association id - local handle to the SCTP association. o association id - local handle to the SCTP association.
o protocol parameter list - the specific names and values of the o protocol parameter list - the specific names and values of the
protocol parameters (e.g., Association.Max.Retrans; see Section protocol parameters (e.g., Association.Max.Retrans; see Section
15, or other parameters like the DSCP) that the SCTP user wishes 15, or other parameters like the DSCP) that the SCTP user wishes
to customize. to customize.
3.35.3. Solution Description 3.35.3. Solution Description
Text describing the required action on DSCP changes has been added. Text describing the required action on DSCP changes has been added.
3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages 3.36. Inconsistent Handling of ICMPv4 and ICMPv6 Messages
3.36.1. Description of the Problem 3.36.1. Description of the Problem
Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6 Appendix C of [RFC4960] describes the handling of ICMPv4 and ICMPv6
messages. The text explicitly describes the handling of ICMPv6 messages. The handling of ICMP messages indicating that the port
number is unreachable described in the enumeration is not consistent
with the description given in [RFC4960] after the enumeration.
Furthermore, the text explicitly describes the handling of ICMPv6
packets indicating reachability problems, but does not do the same packets indicating reachability problems, but does not do the same
for the corresponding ICMPv4 packets. for the corresponding ICMPv4 packets.
3.36.2. Text Changes to the Document 3.36.2. Text Changes to the Document
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
ICMP3) An implementation MAY ignore any ICMPv4 messages where the ICMP3) An implementation MAY ignore any ICMPv4 messages where the
code does not indicate "Protocol Unreachable" or code does not indicate "Protocol Unreachable" or
"Fragmentation Needed". "Fragmentation Needed".
--------- ---------
New text: New text: (Appendix C)
--------- ---------
ICMP3) An implementation SHOULD ignore any ICMPv4 messages where the ICMP3) An implementation SHOULD ignore any ICMP messages where the
code indicates "Port Unreachable". code indicates "Port Unreachable".
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
ICMP9) If the ICMPv6 code is "Destination Unreachable", the ICMP9) If the ICMPv6 code is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
--------- ---------
New text: New text: (Appendix C)
--------- ---------
ICMP9) If the ICMP type is "Destination Unreachable", the ICMP9) If the ICMP type is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
3.36.3. Solution Description 3.36.3. Solution Description
The text has been changed to not limit the processing of ICMPv4 The text has been changed to describe the intended handling of ICMP
packets with type "Destination Unreachable" by rewording the third messages indicating that the port number is unreachable by replacing
rule. Furthermore, remove the limitation to ICMPv6 in the ninth the third rule. Furthermore, remove the limitation to ICMPv6 in the
rule. ninth rule.
3.37. Handling of Soft Errors 3.37. Handling of Soft Errors
3.37.1. Description of the Problem 3.37.1. Description of the Problem
[RFC1122] defines the handling of soft errors and hard errors for [RFC1122] defines the handling of soft errors and hard errors for
TCP. Appendix C of [RFC4960] only deals with hard errors. TCP. Appendix C of [RFC4960] only deals with hard errors.
3.37.2. Text Changes to the Document 3.37.2. Text Changes to the Document
--------- ---------
Old text: (Appendix C) Old text: (Appendix C)
--------- ---------
ICMP8) If the ICMP type is "Destination Unreachable", the ICMP9) If the ICMP type is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
--------- ---------
New text: (Appendix C) New text: (Appendix C)
--------- ---------
ICMP8) If the ICMP type is "Destination Unreachable", the ICMP9) If the ICMP type is "Destination Unreachable", the
implementation MAY mark the destination into the unreachable implementation MAY mark the destination into the unreachable
state or alternatively increment the path error counter. state or alternatively increment the path error counter.
SCTP MAY provide information to the upper layer indicating SCTP MAY provide information to the upper layer indicating
the reception of ICMP messages when reporting a network status the reception of ICMP messages when reporting a network status
change. change.
3.37.3. Solution Description 3.37.3. Solution Description
Text has been added allowing SCTP to notify the application in case Text has been added allowing SCTP to notify the application in case
of soft errors. of soft errors.
skipping to change at page 59, line 14 skipping to change at page 59, line 14
3.40. Updating References Regarding ECN 3.40. Updating References Regarding ECN
3.40.1. Description of the Problem 3.40.1. Description of the Problem
[RFC4960] refers for ECN only to [RFC3168], which will be updated by [RFC4960] refers for ECN only to [RFC3168], which will be updated by
[RFC8311]. This needs to be reflected when referring to ECN. [RFC8311]. This needs to be reflected when referring to ECN.
3.40.2. Text Changes to the Document 3.40.2. Text Changes to the Document
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
ECN [RFC3168] describes a proposed extension to IP that details a ECN [RFC3168] describes a proposed extension to IP that details a
method to become aware of congestion outside of datagram loss. method to become aware of congestion outside of datagram loss.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
ECN as specified in [RFC3168] updated by [RFC8311] describes a proposed ECN as specified in [RFC3168] updated by [RFC8311] describes an
extension to IP that details a method to become aware of congestion extension to IP that details a method to become aware of congestion
outside of datagram loss. outside of datagram loss.
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
In general, [RFC3168] should be followed with the following In general, [RFC3168] should be followed with the following
exceptions. exceptions.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the In general, [RFC3168] updated by [RFC8311] SHOULD be followed with the
following exceptions. following exceptions.
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK [RFC3168] details negotiation of ECN during the SYN and SYN-ACK
stages of a TCP connection. stages of a TCP connection.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
[RFC3168] updated by [RFC8311] details negotiation of ECN during the [RFC3168] updated by [RFC8311] details negotiation of ECN during the
SYN and SYN-ACK stages of a TCP connection. SYN and SYN-ACK stages of a TCP connection.
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
[RFC3168] details a specific bit for a receiver to send back in its [RFC3168] details a specific bit for a receiver to send back in its
TCP acknowledgements to notify the sender of the Congestion TCP acknowledgements to notify the sender of the Congestion
Experienced (CE) bit having arrived from the network. Experienced (CE) bit having arrived from the network.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
[RFC3168] updated by [RFC8311] details a specific bit for a receiver [RFC3168] updated by [RFC8311] details a specific bit for a receiver
to send back in its TCP acknowledgements to notify the sender of the to send back in its TCP acknowledgements to notify the sender of the
Congestion Experienced (CE) bit having arrived from the network. Congestion Experienced (CE) bit having arrived from the network.
--------- ---------
Old text: (Appendix A) Old text: (Appendix A)
--------- ---------
[RFC3168] details a specific bit for a sender to send in the header [RFC3168] details a specific bit for a sender to send in the header
of its next outbound TCP segment to indicate to its peer that it has of its next outbound TCP segment to indicate to its peer that it has
reduced its congestion window. reduced its congestion window.
--------- ---------
New text: (Appendix A) New text: (Appendix A)
--------- ---------
[RFC3168] updated by [RFC8311] details a specific bit for a sender [RFC3168] updated by [RFC8311] details a specific bit for a sender
to send in the header of its next outbound TCP segment to indicate to to send in the header of its next outbound TCP segment to indicate to
its peer that it has reduced its congestion window. its peer that it has reduced its congestion window.
3.40.3. Solution Description 3.40.3. Solution Description
References to [RFC8311] have been added. References to [RFC8311] have been added. While there, some
wordsmithing has been performed.
3.41. Host Name Address Parameter Deprecated 3.41. Host Name Address Parameter Deprecated
3.41.1. Description of the Problem 3.41.1. Description of the Problem
[RFC4960] defines three types of address parameters to be used with [RFC4960] defines three types of address parameters to be used with
INIT and INIT ACK chunks: INIT and INIT ACK chunks:
1. IPv4 Address parameters. 1. IPv4 Address parameters.
2. IPv6 Address parameters. 2. IPv6 Address parameters.
skipping to change at page 83, line 9 skipping to change at page 83, line 9
3.46.3. Solution Description 3.46.3. Solution Description
The code was changed to use platform independent types. The code was changed to use platform independent types.
3.47. Clarification of Gap Ack Blocks in SACK Chunks 3.47. Clarification of Gap Ack Blocks in SACK Chunks
3.47.1. Description of the Problem 3.47.1. Description of the Problem
The Gap Ack Blocks in the SACK chunk are intended to be isolated. The Gap Ack Blocks in the SACK chunk are intended to be isolated.
However, this is not mentioned with normative text. However, this is not mentioned with normative text.
This issue was reported as part of an Errata for [RFC4960] with
Errata ID 5202.
3.47.2. Text Changes to the Document 3.47.2. Text Changes to the Document
--------- ---------
Old text: (Section 3.3.4) Old text: (Section 3.3.4)
--------- ---------
The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack The SACK also contains zero or more Gap Ack Blocks. Each Gap Ack
Block acknowledges a subsequence of TSNs received following a break Block acknowledges a subsequence of TSNs received following a break
in the sequence of received TSNs. By definition, all TSNs in the sequence of received TSNs. By definition, all TSNs
acknowledged by Gap Ack Blocks are greater than the value of the acknowledged by Gap Ack Blocks are greater than the value of the
skipping to change at page 86, line 33 skipping to change at page 86, line 33
3.50.3. Solution Description 3.50.3. Solution Description
The text has finally been removed. The text has finally been removed.
4. IANA Considerations 4. IANA Considerations
Section 3.44 of this document updates the port number registry for Section 3.44 of this document updates the port number registry for
SCTP to be consistent with [RFC6335]. IANA is requested to review SCTP to be consistent with [RFC6335]. IANA is requested to review
Section 3.44. Section 3.44.
IANA is only requested to check if it is OK to make the proposed text
change in an upcoming standards track document that updates[RFC4960].
IANA is not asked to perform any other action and this document does
not request IANA to make a change to any registry.
5. Security Considerations 5. Security Considerations
This document does not add any security considerations to those given This document does not add any security considerations to those given
in [RFC4960]. in [RFC4960].
6. Acknowledgments 6. Acknowledgments
The authors wish to thank Pontus Andersson, Eric W. Biederman, The authors wish to thank Pontus Andersson, Eric W. Biederman,
Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Peter Lei, Gyula Cedric Bonnet, Spencer Dawkins, Gorry Fairhurst, Benjamin Kaduk,
Marosi, Lionel Morand, Jeff Morriss, Karen E. E. Nielsen, Tom Mirja Kuehlewind, Peter Lei, Gyula Marosi, Lionel Morand, Jeff
Petch, Kacheong Poon, Julien Pourtet, Irene Ruengeler, Michael Welzl, Morriss, Karen E. E. Nielsen, Tom Petch, Kacheong Poon, Julien
and Qiaobing Xie for their invaluable comments. Pourtet, Irene Ruengeler, Michael Welzl, and Qiaobing Xie for their
invaluable comments.
7. References 7. References
7.1. Normative References 7.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>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<https://www.rfc-editor.org/info/rfc4960>. <https://www.rfc-editor.org/info/rfc4960>.
 End of changes. 60 change blocks. 
125 lines changed or deleted 146 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/