rfc9897v2.txt   rfc9897.txt 
Internet Engineering Task Force (IETF) M. Amend, Ed. Internet Engineering Task Force (IETF) M. Amend, Ed.
Request for Comments: 9897 DT Request for Comments: 9897 DT
Category: Standards Track A. Brunstrom Category: Standards Track A. Brunstrom
ISSN: 2070-1721 A. Kassler ISSN: 2070-1721 A. Kassler
Karlstad University Karlstad University
V. Rakocevic V. Rakocevic
City St George's, University of London City St George's, University of London
S. Johnson S. Johnson
BT BT
December 2025 January 2026
Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Datagram Congestion Control Protocol (DCCP) Extensions for Multipath
Operation with Multiple Addresses Operation with Multiple Addresses
Abstract Abstract
Datagram Congestion Control Protocol (DCCP) communications, as Datagram Congestion Control Protocol (DCCP) communications, as
defined in RFC 4340, are inherently restricted to a single path per defined in RFC 4340, are inherently restricted to a single path per
connection, despite the availability of multiple network paths connection, despite the availability of multiple network paths
between peers. The ability to utilize multiple paths simultaneously between peers. The ability to utilize multiple paths simultaneously
skipping to change at line 57 skipping to change at line 57
received public review and has been approved for publication by the received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841. Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9897. https://www.rfc-editor.org/info/rfc9897.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described Trust Legal Provisions and are provided without warranty as described
skipping to change at line 631 skipping to change at line 631
incorrectly interpret that the priority value was set to 0 without incorrectly interpret that the priority value was set to 0 without
recognizing that the receiver has applied priority value 1. recognizing that the receiver has applied priority value 1.
The length of the MP_CONFIRM option and the path over which the The length of the MP_CONFIRM option and the path over which the
option is sent depend on the confirmed Multipath Options and the option is sent depend on the confirmed Multipath Options and the
received MP_SEQ, which are both copied verbatim and appended as a received MP_SEQ, which are both copied verbatim and appended as a
list of confirmations. The list is structured by first listing the list of confirmations. The list is structured by first listing the
received MP_SEQ followed by the related Multipath Option or options received MP_SEQ followed by the related Multipath Option or options
to confirm. The same rules apply when Multipath Options with to confirm. The same rules apply when Multipath Options with
different MP_SEQs are confirmed at once. This could happen if the different MP_SEQs are confirmed at once. This could happen if the
following are receieved in short succession: a datagram with MP_PRIO following are received in short succession: a datagram with MP_PRIO
and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a and a first MP_SEQ_1 and another datagram with MP_ADDADDR and a
second MP_SEQ_2. In this case, the structure described above is second MP_SEQ_2. In this case, the structure described above is
concatenated resulting in MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO. concatenated resulting in MP_SEQ_2 + MP_ADDADDR + MP_SEQ_1 + MP_PRIO.
The order of the confirmed Multipath Options in the list of The order of the confirmed Multipath Options in the list of
confirmations MUST reflect the incoming order at the host who sends confirmations MUST reflect the incoming order at the host who sends
the MP_CONFIRM, with the most recent suboption received listed first. the MP_CONFIRM, with the most recent suboption received listed first.
This could allow the host receiving the MP_CONFIRM to verify that the This could allow the host receiving the MP_CONFIRM to verify that the
options were applied in the correct order and to take countermeasures options were applied in the correct order and to take countermeasures
if they were not, e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR if they were not, e.g., if an MP_REMOVEADDR overtakes an MP_ADDADDR
that refers to the same dataset. that refers to the same dataset.
 End of changes. 3 change blocks. 
3 lines changed or deleted 3 lines changed or added

This html diff was produced by rfcdiff 1.48.